¿Por qué los LLM fallan con la lógica de escalera (Ladder Logic)? La ventaja gráfica en OLLA Lab

Los modelos de lenguaje extenso (LLM) tienen dificultades con la lógica de escalera (Ladder Logic) porque predicen texto unidimensional, mientras que el diagrama de escalera (LD) y el SFC dependen de relaciones espaciales bidimensionales, ejecución en paralelo y el orden del ciclo de escaneo. OLLA Lab proporciona un entorno de simulación visual donde los ingenieros pueden validar el flujo de potencia, el comportamiento de E/S y los errores de temporización antes de que la lógica llegue a un proceso real.

La IA no falla principalmente en la lógica de escalera porque la sintaxis sea oscura. Falla porque el control de PLC no es solo sintaxis; es ejecución espacial bajo una temporización de escaneo determinista. Esa distinción es más importante de lo que admite la mayoría de los consejos sobre ingeniería de prompts.

Durante una evaluación comparativa interna reciente de 50 circuitos de control de motores generados por IA e importados al motor de simulación de OLLA Lab, el 68% de las secuencias sugeridas por la IA fallaron durante el primer ciclo de escaneo virtual, debido principalmente a errores en el orden de los peldaños y en la dependencia de estados, más que a fallos de sintaxis. Metodología: tamaño de la muestra = 50 tareas de control de motores generadas; definición de la tarea = importar y simular patrones de arranque/parada, autoenclavamiento, permisivos y reinicio de fallos generados por IA; comparador de referencia = implementaciones de referencia revisadas manualmente y aceptadas por la revisión de ingeniería de Ampergon Vallis; ventana temporal = Q1 2026. Esta métrica respalda un punto concreto: la lógica de escalera generada por IA a menudo falla en el momento de la ejecución, incluso cuando parece estructuralmente plausible. No respalda la afirmación general de que toda la lógica de PLC generada por IA es inutilizable.

Ese es el verdadero problema: la plausibilidad del texto frente al comportamiento de control desplegable. Los PLCs no califican ensayos.

La lógica de escalera es difícil para los LLM porque el modelo predice texto serializado, mientras que el diagrama de escalera representa la intención de control a través de una topología bidimensional. La falta de coincidencia es arquitectónica, no cosmética.

La norma IEC 61131-3 define el diagrama de escalera (LD) y el diagrama de funciones secuenciales (SFC) como lenguajes gráficos utilizados para expresar relaciones de control que son más fáciles de razonar visualmente que mediante texto plano (IEC, 2013). En LD, la estructura de las ramas, el flujo de potencia, el orden de los peldaños y las condiciones paralelas son parte del significado. En SFC, la divergencia, la convergencia, los pasos activos y la propiedad de las transiciones también forman parte del significado. Cuando esa estructura se aplana en XML, JSON o texto de prompt, parte del contexto de ejecución se vuelve más fácil de perder o malinterpretar.

La brecha de ejecución 1D vs. 2D

Serializan principalmente la intención en un orden lineal. Incluso cuando expresan ramificaciones o concurrencia, la representación sigue siendo secuencial por tokens y explícita.

• Lenguajes de texto como Python o C

Codifica la lógica como una red de estilo eléctrico con flujo de potencia de izquierda a derecha y evaluación de arriba a abajo. Las ramas paralelas no son decorativas; definen relaciones de ejecución.

• Diagrama de escalera (LD)

Codifica la progresión de estados espacialmente. La divergencia y la convergencia indican rutas simultáneas o alternativas que son más difíciles de preservar cuando se reducen a estructuras de texto plano.

• Diagrama de funciones secuenciales (SFC)

Predicen los siguientes tokens probables a partir de patrones de entrenamiento. Pueden imitar la notación de escalera, pero la imitación no es lo mismo que mantener invariantes topológicos a través de un grafo de control.

• LLMs

La investigación sobre el razonamiento de los LLM ha demostrado repetidamente que la predicción de tokens no preserva de forma fiable la estructura espacial o topológica, especialmente cuando la tarea requiere un mapeo consistente a través de representaciones no lineales (Bubeck et al., 2023; Bang et al., 2023). Los detalles varían según el benchmark, pero la dirección es estable: los modelos de secuencia son mejores en la continuación plausible que en la contabilidad espacial determinista.

Una corrección útil es esta: la lógica de escalera no es "fácil para la IA porque es simple". A menudo es difícil para la IA precisamente porque es gráfica, tiene estado y está ligada al escaneo. La simplicidad en la pantalla puede ocultar una temporización difícil debajo.

La lógica de escalera generada por IA a menudo falla porque los PLC se ejecutan en un ciclo de escaneo determinista, y muchas secuencias generadas ignoran ese orden de ejecución. Un peldaño que parece razonable de forma aislada puede fallar cuando el controlador lee las entradas, resuelve la lógica y escribe las salidas en secuencia.

El modelo de escaneo estándar es sencillo:

1. Leer entradas
2. Ejecutar lógica
3. Actualizar salidas
4. Repetir

Ese ciclo puede ejecutarse en milisegundos, pero la temporización es lo suficientemente real como para crear condiciones de carrera, lecturas de estado obsoletas y permisivos falsos si la lógica está mal ordenada. Este es un comportamiento básico de PLC, pero es exactamente donde la generación basada solo en texto tiende a desviarse.

La falacia de "parece correcto"

El error más común de la IA no es una sintaxis inválida. Es una lógica que parece válida pero tiene un comportamiento de ejecución inválido.

Los ejemplos incluyen:

Un bit permisivo se verifica en el peldaño 2, pero la lógica que lo establece no se ejecuta hasta el peldaño 5.

• Orden de peldaños invertido

Una rama lee un estado de salida como si ya estuviera actualizado, a pesar de que el peldaño relevante aún no se ha resuelto en ese escaneo.

• Dependencia de salida prematura

El patrón generado se asemeja a un arrancador de motor estándar, pero no mantiene el estado correctamente cuando ocurre una transición de parada o fallo.

• Lógica de autoenclavamiento rota

La lógica de reinicio de fallos borra un disparo antes de que se revaliden las condiciones de prueba, creando una secuencia que es ordenada en texto pero potencialmente insegura en la operación.

• Secuenciación de reinicio inadecuada

El modelo inventa combinaciones de ramas que parecen expresivas en XML pero que no se asignan limpiamente a una red de escalera legal.

• Estructuras de rama ilegales o no compilables

Aquí es donde la validación visual se vuelve operativamente útil. Necesita ver la ruta activa, alternar la entrada, inspeccionar la etiqueta y ver cómo falla la secuencia en orden. Una exportación de texto no revelará eso por sí sola.

La IA tiene dificultades con SFC porque SFC es una máquina de estados visual cuyo significado depende de la propiedad de las ramas, la activación simultánea de pasos y la disciplina de transición. Si se aplana el gráfico descuidadamente, la lógica de la máquina se vuelve ambigua.

SFC suele ser más difícil para los LLM que la escalera básica porque el modelo debe preservar:

• qué pasos están activos al mismo tiempo,
• qué transición pertenece a qué rama,
• dónde comienza la divergencia,
• dónde se resuelve legalmente la convergencia,
• qué debe suceder cuando una ruta paralela se completa antes que otra.

Estos no son detalles menores. En procesos por lotes, empaquetado, servicios públicos y patines de proceso, definen si una secuencia espera, avanza, se bloquea o se dispara.

La representación gráfica es importante porque la corrección del control no es solo corrección lógica. También es la corrección de la secuencia observable bajo un comportamiento real de la planta.

En la automatización industrial, la pregunta rara vez es solo "¿se compila el peldaño?". La pregunta real es más parecida a esta:

• ¿La bomba arranca solo cuando los permisivos son verdaderos?
• ¿La retroalimentación de prueba llega dentro del tiempo esperado?
• ¿La alarma se enclava correctamente?
• ¿El disparo se reinicia solo bajo condiciones válidas?
• ¿La secuencia se recupera de forma segura después de un estado anormal?
• ¿El comportamiento del equipo simulado coincide con la filosofía de control prevista?

Es por eso que los estándares y las prácticas de seguridad enfatizan la validación, la verificación y la disciplina del ciclo de vida en lugar de confiar en el código generado al pie de la letra. La norma IEC 61508, por ejemplo, es explícita sobre la integridad sistemática, la calidad de la especificación, el rigor de la verificación y el peligro de fallos de diseño latentes en sistemas programables (IEC, 2010). No contiene una exención especial para el código que parecía convincente en una ventana de chat.

La simulación y la validación basada en gemelos digitales son cada vez más relevantes aquí porque permiten a los ingenieros probar el comportamiento antes de la exposición en el sitio. La literatura es amplia y desigual, pero el resultado central es consistente: la formación basada en simulación y la puesta en marcha virtual pueden mejorar el descubrimiento de fallos, la comprensión de secuencias y la preparación del operador o ingeniero cuando la simulación está vinculada a un comportamiento de proceso realista en lugar de solo a una visualización genérica (Tao et al., 2019; Negri et al., 2017; Uhlemann et al., 2017).

OLLA Lab cierra la brecha de la IA al brindar a los ingenieros un entorno visual acotado para construir, simular, inspeccionar y revisar la lógica de control antes de que toque el equipo físico. No es un reemplazo de la IA y no es una garantía de competencia en el campo. Es una capa de validación y ensayo.

Ese posicionamiento importa. Un simulador debe reducir el riesgo de puesta en marcha, no fabricar una falsa confianza.

Qué hace OLLA Lab en este flujo de trabajo

Dentro del alcance del producto, OLLA Lab proporciona:

• un editor de lógica de escalera basado en web para construir y revisar peldaños,
• modo de simulación para ejecutar y detener la lógica de forma segura,
• un panel de variables para monitorear entradas, salidas, etiquetas, valores analógicos y estados relacionados con PID,
• vistas de equipo 3D/WebXR/VR donde estén disponibles,
• laboratorios basados en escenarios que conectan la lógica de escalera con el comportamiento realista de una máquina o proceso.

Utilizado correctamente, esto respalda un flujo de trabajo disciplinado:

1. Tome la sugerencia generada por la IA como un borrador, no como una prueba.
2. Reconstruya o importe la lógica en un entorno de escalera visual.
3. Defina la secuencia esperada y los permisivos.
4. Alterne las entradas y observe las salidas en la simulación.
5. Compare el estado de la escalera con el estado del equipo simulado.
6. Inyecte un fallo o condición anormal.
7. Revise la lógica y vuelva a probar.

Aquí es donde OLLA Lab se vuelve operativamente útil. Convierte "el modelo me dio código" en "el ingeniero observó la secuencia, encontró el fallo y lo corrigió".

Los ingenieros deben validar la lógica de escalera generada por IA como si fuera un borrador no confiable de un colaborador junior: útil para la aceleración, inseguro como autoridad final y solo aceptable después de una revisión determinista.

Una secuencia de validación viable es:

1. Defina la intención de control antes de revisar el código

Anote:

• condiciones de arranque,
• condiciones de parada,
• permisivos,
• disparos,
• reglas de reinicio,
• expectativas de retroalimentación de prueba,
• comportamiento de la alarma,
• estados a prueba de fallos.

Si la filosofía de control es vaga, la revisión del código también lo será. La máquina suele notarlo.

2. Verifique el orden de ejecución, no solo la sintaxis

Revise:

• orden de los peldaños,
• legalidad de las ramas,
• dependencias de estado,
• comportamiento de enclavamiento/desenclavamiento,
• secuenciación de reinicio,
• ordenamiento de umbrales analógicos,
• si alguna salida se referencia antes de que se resuelva su lógica gobernante.

3. Simule casos nominales y anormales

Como mínimo, pruebe:

• arranque normal,
• parada normal,
• pérdida de permisivo,
• prueba fallida,
• desacuerdo del sensor,
• estado de encendido o reinicio,
• reconocimiento de alarma,
• recuperación después de un fallo.

4. Compare el estado del controlador con el estado del equipo

Un peldaño que parece correcto no es suficiente. El motor, válvula, bomba, ventilador o patín simulado debe comportarse de una manera que coincida con la secuencia prevista.

5. Revise y vuelva a probar hasta que la secuencia sea estable

Una ejecución exitosa no es validación. Es una primera pasada.

Un cuerpo creíble de evidencia de ingeniería no es una galería de capturas de pantalla. Es un registro compacto que muestra que el ingeniero definió la corrección, probó el fallo, revisó la lógica y aprendió algo específico.

Utilice esta estructura:

1) Descripción del sistema

Indique qué es el sistema y qué se supone que debe hacer.

2) Definición operativa de "correcto"

Defina criterios de éxito observables.

3) Lógica de escalera y estado del equipo simulado

Muestre la escalera y el comportamiento de la máquina simulada juntos.

4) El caso de fallo inyectado

Introduzca una condición anormal deliberadamente.

5) La revisión realizada

Registre el cambio de lógica.

6) Lecciones aprendidas

Indique qué enseñó el fallo.

Este tipo de evidencia es mucho más útil que un conjunto de imágenes pulidas. Demuestra juicio de ingeniería, no solo acceso al software.

La IA puede seguir siendo útil para la programación de PLC, pero principalmente como una capa de redacción y asistencia en lugar de una autoridad de ejecución. Es buena en el recuerdo de patrones, generación de texto repetitivo, explicación y soporte de traducción. Es más débil para preservar el comportamiento determinista a través de la semántica de control gráfico.

Los casos de uso razonables incluyen:

• generar patrones de peldaños de primer borrador,
• explicar temporizadores, contadores, comparadores y bloques PID,
• traducir comentarios o descripciones de etiquetas,
• proponer casos de prueba,
• resumir el texto de la filosofía de control,
• ayudar a los alumnos a entender por qué falló una secuencia.

Los casos de uso menos razonables incluyen:

• confiar en la lógica generada sin simulación,
• asumir que la exportación XML preserva la topología correctamente,
• usar la salida de la IA como prueba de preparación para la puesta en marcha,
• tratar la calidad del prompt como un sustituto de la revisión de ejecución.

La distinción práctica es simple: generación de borradores frente a veto determinista. La IA puede ayudar a escribir el borrador. La simulación y la revisión de ingeniería tienen el veto.

La evidencia actual respalda una conclusión estrecha pero importante: los LLM tienen dificultades con la lógica de escalera y SFC no porque el control industrial sea demasiado especializado para describirlo, sino porque estos lenguajes codifican el significado a través de la estructura espacial, las relaciones paralelas y la ejecución del ciclo de escaneo que no se preservan naturalmente mediante la predicción de tokens unidimensionales.

Esa conclusión no significa que la IA sea irrelevante para la automatización. Significa que la carga de validación sigue recayendo firmemente en el ingeniero.

Para la lógica de escalera, la pregunta decisiva no es si el texto generado parece familiar. Es si la secuencia puede observarse, fallarse, corregirse y volver a ejecutarse frente a un comportamiento realista antes de la implementación. Ese es el estándar que importa en la práctica, y es el estándar que OLLA Lab está diseñado para respaldar como un entorno de simulación acotado.

La sintaxis es barata. El determinismo es la parte costosa.

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - Familia de normas de seguridad funcional IEC 61508 - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Antecedentes de la política de Industria 5.0 de la UE - Descripción general del gemelo digital (NIST)

El equipo de ingeniería de OLLA Lab se especializa en la intersección de la automatización industrial, la simulación de gemelos digitales y la validación de sistemas de control.

Este artículo ha sido revisado por ingenieros de control de Ampergon Vallis para garantizar la precisión técnica respecto a la ejecución del ciclo de escaneo de PLC y los estándares de seguridad funcional IEC.