Cómo depurar lógica de escalera con un asistente de IA: Conozca a Yaga en OLLA Lab

La depuración efectiva de la lógica de escalera requiere algo más que ayuda con la sintaxis. Yaga, el coach de IA dentro de OLLA Lab, funciona como un asistente acotado vinculado al estado del proyecto, al comportamiento de la simulación y al contexto de E/S, ayudando a los ingenieros a diagnosticar fallas lógicas, explicar estructuras IEC 61131-3 y ensayar flujos de trabajo de corrección antes de la puesta en marcha real.

La lógica de escalera suele fallar por razones más físicas que gramaticales. Un peldaño puede parecer correcto y aun así producir un comportamiento de máquina incorrecto porque el problema real reside en el orden de escaneo, el mapeo de etiquetas (tags), la secuenciación, la temporización o una suposición errónea sobre el estado del equipo.

Ahí es donde los ingenieros junior suelen estancarse. Pueden colocar contactos y bobinas, pero aún no pueden explicar por qué una secuencia se bloquea, por qué una salida nunca se activa o por qué una condición permisiva se despeja un ciclo de escaneo demasiado tarde. La sintaxis no es la parte difícil por mucho tiempo; la capacidad de implementación sí lo es.

Durante las pruebas beta de OLLA Lab, los estudiantes que utilizaron Yaga para diagnosticar la divergencia de estado entre "enclavamiento (latch) frente a sellado (seal-in)" resolvieron las fallas de los escenarios asignados un 63% más rápido que los estudiantes que utilizaron solo documentación estática [Metodología: n=38 estudiantes; tarea=depuración de fallas preconfiguradas de control de motores y secuenciación de bombas en simulación; comparador de referencia=instrucciones en PDF estilo OEM y listas de etiquetas sin asistencia de IA; ventana de tiempo=periodo beta de 8 semanas, Q1 2026]. Este punto de referencia interno respalda una afirmación más limitada: el coaching de IA acotada puede reducir el tiempo de diagnóstico dentro de un flujo de trabajo de laboratorio simulado. No demuestra competencia en el sitio, preparación para la puesta en marcha en equipos reales ni resultados más amplios en el mercado laboral.

Los ingenieros junior se estancan porque la lógica de escalera no es solo un sistema de notación. Es un sistema conductual ejecutado en ciclos de escaneo frente a estados de proceso reales o simulados, con consecuencias moldeadas por la temporización, los enclavamientos (interlocks), las retroalimentaciones, y los modos de falla.

Una idea errónea común es que la depuración de PLC consiste principalmente en "encontrar el peldaño incorrecto". En la práctica, la falla suele ser la relación entre peldaños, etiquetas y suposiciones de secuencia. Un comando de arranque de motor puede energizarse correctamente, pero la secuencia aún falla porque la entrada de prueba nunca hace la transición, la ruta de parada se sobrescribe más adelante en el escaneo o el modelo de estado nunca fue coherente desde el principio. El diagrama está limpio. La máquina permanece indiferente.

Esta brecha se describe mejor como una pérdida de intuición en los controles. Los ingenieros conocen el conjunto de instrucciones, pero aún no razonan con fluidez sobre:

• el orden de escaneo y las salidas sobrescritas,
• el comportamiento de sellado (seal-in) frente al enclavamiento (latch),
• las condiciones permisivas frente a los disparos (trips),
• la retroalimentación de prueba de funcionamiento (proof-of-run),
• el manejo de estados anormales,
• los umbrales analógicos y la temporización de rebote (debounce),
• la progresión de la secuencia bajo condiciones de campo incompletas.

La investigación sobre capacitación industrial y sistemas ciberfísicos sugiere que la calidad del aprendizaje depende de una retroalimentación rica en contexto en lugar de una exposición aislada al código. En entornos de OT, la carga cognitiva proviene de cambiar entre la lógica, la narrativa del proceso, el estado de E/S, las alarmas y el comportamiento del equipo, en lugar de solo el reconocimiento de símbolos (Aivaliotis et al., 2019; Mourtzis et al., 2021).

Esta es también la razón por la que "Listo para la simulación" (Simulation-Ready) necesita una definición estricta. En este artículo, "Listo para la simulación" significa que un ingeniero puede probar, observar, diagnosticar y fortalecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso real. Ese es un estándar más alto que ser capaz de dibujar un peldaño de memoria, y uno más útil.

Yaga proporciona una corrección contextual al operar dentro del entorno acotado de OLLA Lab en lugar de como un generador de texto de libre circulación. Está destinado a ayudar a los usuarios a inspeccionar la lógica que construyeron, las variables que mapearon y el comportamiento simulado que activaron.

Esa distinción importa. Un chatbot general puede describir patrones de lógica de escalera, pero no sabe intrínsecamente qué están haciendo sus etiquetas, qué escenario está cargado o si el estado del equipo simulado diverge de la narrativa de control prevista. En el trabajo de controles, la falta de contexto no es un defecto pequeño. Suele ser el defecto.

Dentro de OLLA Lab, Yaga funciona como un coach de laboratorio de IA que apoya tres comportamientos de ingeniería observables:

• rastreo de la causalidad de E/S,
• identificación de inconsistencias estructurales o de mapeo,
• comparación de la lógica de secuencia prevista frente al estado real de la simulación.

Flujo de trabajo de diagnóstico de tres niveles de Yaga

Yaga puede ayudar a los usuarios a identificar E/S no mapeadas, uso inconsistente de etiquetas y probables desajustes de tipos de datos en el contexto del proyecto visible a través del editor y el flujo de trabajo de variables. Esta es la primera capa porque muchas fallas "lógicas" son en realidad fallas de vinculación disfrazadas de lógica.

• Validación de sintaxis y etiquetas

Yaga puede señalar a los usuarios patrones estructurales que comúnmente fallan en la ejecución de PLC, como condiciones de doble bobina, escrituras de salida conflictivas, rutas de sellado rotas o lógica de secuenciación que depende de transiciones de estado imposibles.

• Análisis de ciclo de escaneo y estructura

Yaga puede ayudar a convertir un objetivo de proceso en lenguaje sencillo en un andamiaje inicial de escalera para que el usuario lo inspeccione, refine y pruebe. La palabra importante es inicial. Es una ayuda de coaching, no una autoridad de seguridad.

• Traducción de la filosofía de control

Aquí es donde OLLA Lab se vuelve operativamente útil. El editor de escalera, el modo de simulación, el panel de variables y el marco de trabajo de escenarios le dan a Yaga un lugar acotado desde el cual entrenar. En lugar de responder en abstracto, puede apoyar un flujo de trabajo donde el usuario escribe lógica, ejecuta la simulación, alterna entradas, observa salidas y revisa el programa frente al comportamiento visible de la máquina.

IA acotada significa que el asistente está restringido por el entorno conocido, los datos del proyecto disponibles y el flujo de trabajo de capacitación específico, en lugar de que se le pida improvisar frente a un contexto industrial no verificado.

En OLLA Lab, ese contexto acotado incluye el proyecto de escalera del usuario, el estado de la simulación, la visibilidad de variables y E/S, y la estructura específica del escenario. El esquema del artículo se refiere a datos de proyecto serializados en JSON; eso importa porque el estado del proyecto serializado crea una representación legible por máquina del modelo de control y el producto de trabajo del usuario. En términos simples, el asistente no está adivinando a partir de una captura de pantalla y un mensaje optimista.

Operativamente, un coach de automatización acotado debería hacer lo siguiente:

• razonar a partir del estado actual del proyecto en lugar de ejemplos genéricos,
• mantener las recomendaciones vinculadas a etiquetas, instrucciones y comportamiento del escenario observables,
• apoyar la validación en simulación en lugar de implicar autoridad de implementación en campo,
• explicar por qué ocurre una falla, no simplemente proponer código de reemplazo.

Lo que no debería hacer es implicar que la lógica generada es segura porque es sintácticamente plausible. IEC 61131-3 define lenguajes de programación y estructuras para el control industrial, pero el cumplimiento del lenguaje no es lo mismo que la seguridad del proceso, la seguridad funcional o la aprobación de puesta en marcha (IEC, 2013).

La diferencia principal no es la "calidad de la IA" en abstracto. Es si el modelo puede razonar a partir del contexto de control real, el estado de la simulación y las restricciones de ingeniería de la tarea en cuestión.

| Característica | LLM General | Asistente Yaga de OLLA Lab | |---|---|---| | Conciencia del contexto | Depende de prompts de texto y descripciones proporcionadas por el usuario. | Trabaja dentro del contexto del proyecto y la simulación de OLLA Lab. | | Conexión con etiquetas y E/S | No puede verificar inherentemente los mapeos del proyecto en vivo. | Apoya la depuración frente a variables, etiquetas y comportamiento del escenario visibles. | | Relevancia del ciclo de escaneo | Puede describir conceptos de PLC correctamente, pero puede pasar por alto implicaciones del orden de ejecución en la lógica específica del usuario. | Puede entrenar a los usuarios sobre problemas de orden de escaneo y divergencia de estado dentro del flujo de trabajo acotado del laboratorio. | | Realismo del hardware | Sin conexión nativa a equipos de planta o estado de simulación de laboratorio a menos que se integre explícitamente. | Utilizado junto con la simulación de OLLA Lab y modelos de escenarios estilo gemelo digital. | | Resultado de aprendizaje | A menudo tiende a la generación de respuestas. | Destinado a apoyar el diagnóstico, la explicación y la revisión. | | Postura de seguridad | Es fácil confiar demasiado porque el resultado es fluido. | Acotado como una ayuda de ensayo y validación, no como una autoridad de puesta en marcha. |

La implicación de seguridad es directa. Los LLM generales pueden ser útiles para la revisión de conceptos, pero no son confiables cuando los usuarios los tratan como si el texto fluido fuera equivalente a una revisión de control determinista. En la automatización industrial, la elocuencia es barata. El comportamiento correcto de la secuencia no lo es.

Yaga ayuda convirtiendo la depuración en un flujo de trabajo observable en lugar de un ejercicio de adivinanza. El usuario puede construir lógica en el editor de escalera basado en navegador, ejecutar la simulación, inspeccionar variables y E/S, y pedir orientación vinculada a lo que el sistema está haciendo.

Un patrón de falla típico es la sobrescritura de salida dentro del mismo escaneo. Considere este ejemplo simplificado:

[Lenguaje: Diagrama de escalera - Ejemplo de falla] // Yaga detecta el síndrome de doble bobina Peldaño 1: XIC(Start_PB) OTE(Motor_Run) Peldaño 2: XIC(Stop_PB) OTE(Motor_Run) // Falla: Estado de salida sobrescrito

El problema no es simplemente que el código "se vea extraño". El problema es que `Motor_Run` se escribe en más de un lugar, por lo que su estado final depende de la progresión del escaneo y la evaluación de la veracidad del peldaño. Un ingeniero junior puede ver dos declaraciones razonables. Un ingeniero de puesta en marcha ve una invitación a perder una tarde.

El valor de Yaga en este tipo de caso no es que sepa mágicamente la única respuesta verdadera. Su valor es que puede incitar al usuario hacia las preguntas de diagnóstico correctas:

• ¿Dónde se escribe la salida?
• ¿La lógica de parada está implementada como una ruptura permisiva o como una escritura conflictiva?
• ¿La ruta de sellado (seal-in) preserva el estado correctamente?
• ¿La retroalimentación del motor simulado alguna vez prueba el funcionamiento?
• ¿Qué etiqueta cambia primero y cuál debería hacerlo?

Ese es el ciclo de aprendizaje correcto. Al usuario no solo se le entrega un peldaño corregido; se le pide que razone a partir de la causalidad, el estado y el orden de ejecución.

Yaga es más útil cuando la revisión de la lógica está vinculada al comportamiento del equipo simulado. La lógica de escalera es solo la mitad de la historia; la otra mitad es si la máquina o el modelo de proceso responde de la manera que espera la filosofía de control.

En OLLA Lab, los usuarios pueden probar la lógica en modo de simulación, alternar entradas, observar salidas y estados de variables, y trabajar a través de ejercicios industriales basados en escenarios. La plataforma también incluye opciones de simulación 3D y WebXR/VR y las posiciona como entornos de validación de gemelos digitales. Esa frase necesita disciplina.

En este artículo, la validación de gemelos digitales significa probar la lógica de control frente a un modelo de equipo virtual realista o una representación de escenario para ver si la secuencia, los enclavamientos, las alarmas y las respuestas analógicas se comportan según lo previsto antes de la implementación en tiempo real. No significa que la simulación sea un sustituto legalmente suficiente para FAT, SAT, revisión de riesgos, verificación de lazos o aceptación en el sitio.

Esa definición acotada se alinea con la literatura más amplia sobre gemelos digitales, que generalmente trata a los gemelos como entornos de apoyo a la decisión y validación en lugar de espejos infalibles de la realidad de la planta (Tao et al., 2019; Jones et al., 2020). Un buen gemelo reduce la incertidumbre. No la elimina.

La forma más segura de usar IA en controles es solicitar estructura, suposiciones y criterios de validación en lugar de una generación de código a ciegas. Pida primero un andamiaje de narrativa de control. Luego pruébelo.

Un prompt débil se ve así:

• "Escribe lógica de escalera para una estación de bombeo."

Un prompt más fuerte se ve así:

- "Crea un andamiaje de escalera inicial para una secuencia de bomba principal/reserva (lead/lag) con: Explica las suposiciones, las etiquetas requeridas y lo que debe verificarse en la simulación."

• dos bombas,
• bloqueo por nivel bajo,
• arranque por nivel alto,
• 5 segundos de rebote (debounce) en el interruptor de nivel bajo,
• retroalimentación de prueba de funcionamiento,
• alarma de falla al arrancar,
• modo manual/automático,
• asignación de bomba principal alternada después de cada ciclo completado.

Ese prompt es mejor porque pide estructura de ingeniería en lugar de un volcado de código. Obliga al asistente a exponer suposiciones y le da al usuario algo comprobable.

Un patrón de prompt práctico para Yaga

Utilice esta secuencia:

Ejemplo: "Controlar una estación de elevación dúplex con servicio de bomba principal alternado."

Ejemplo: "Bloqueo en nivel muy bajo, alarma en falla al arrancar, disparo por sobrecarga."

Ejemplo: "Añadir 3 segundos de rebote y 2 segundos de tiempo de espera de prueba de funcionamiento."

Ejemplo: "Enumere las entradas, salidas, bits internos, temporizadores y pasos de secuencia requeridos."

Ejemplo: "¿Qué debo observar en la simulación para considerar esto correcto?"

1. Establezca el objetivo del proceso
2. Defina las condiciones anormales
3. Especifique los requisitos de temporización y prueba
4. Solicite suposiciones de etiquetas y estados de secuencia
5. Solicite criterios de verificación

Ese paso final importa. Los ingenieros deben pedirle a la IA que defina la evidencia, no solo el resultado.

Los ingenieros deben validar el comportamiento, no la calidad de la prosa. Una explicación plausible o un patrón de peldaño ordenado no es suficiente.

Antes de tratar la lógica asistida por IA como digna de simulación, verifique:

¿Están presentes y correctamente tipificadas todas las entradas, salidas, valores analógicos y etiquetas internas requeridas?

• Integridad del mapeo de E/S

¿Cada salida crítica se controla a través de una estructura coherente en lugar de escrituras dispersas?

• Control de salida de fuente única

¿Están los arranques, paradas, enclavamientos, fallas y reinicios separados limpiamente?

• Lógica de permisivos y disparos (trips)

¿Puede la secuencia entrar, mantener y salir de cada estado esperado sin bloqueo (deadlock)?

• Progresión de estado

¿Qué sucede ante una falla del sensor, falla de prueba, tiempo de espera, sobrecarga o cambio de modo del operador?

• Manejo de condiciones anormales

Si hay valores analógicos o instrucciones PID involucrados, ¿se comportan los umbrales, límites y bandas de alarma según lo previsto?

• Comportamiento analógico y PID

¿Puede el usuario demostrar la lógica frente al comportamiento realista del escenario, no solo mediante revisión estática?

• Evidencia de simulación

Aquí es también donde importa el panel de variables de OLLA Lab. Una buena depuración depende de ver los estados de las etiquetas, los valores analógicos y el comportamiento del lazo de control mientras la lógica se ejecuta. Sin observabilidad, la depuración se convierte en folclore.

Los ingenieros deben documentar un cuerpo compacto de evidencia, no una galería de capturas de pantalla. Los gerentes de contratación, instructores y revisores senior aprenden más de un rastro de fallas y revisiones que de imágenes pulidas del estado final.

Utilice esta estructura:

1. Descripción del sistema Describa el proceso, el equipo y el objetivo de control en términos de ingeniería sencillos.
2. Definición operativa de "correcto" Establezca qué debe suceder para que la lógica se considere correcta en la simulación. Incluya el comportamiento de la secuencia, enclavamientos, alarmas y condiciones de prueba.
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños, etiquetas y el estado correspondiente de la máquina o proceso en la simulación.
4. El caso de falla inyectada Documente la falla introducida deliberadamente o descubierta, como una ruta de sellado rota, mala temporización de rebote o salida sobrescrita.
5. La revisión realizada Explique el cambio de lógica y por qué resuelve el comportamiento observado.
6. Lecciones aprendidas Resuma lo que la falla reveló sobre el orden de escaneo, la causalidad, las suposiciones del proceso o el riesgo de puesta en marcha.

Esa estructura produce evidencia de razonamiento. Es mucho más creíble que "aquí está mi archivo de escalera terminado". Los archivos terminados ocultan los errores interesantes, y los errores suelen ser donde comienza la ingeniería.

No. Yaga es un coach de laboratorio acotado, no un sustituto de la revisión de ingeniería senior, los métodos de seguridad formales o la validación en el sitio.

Ese límite no es un trámite legal; es honestidad técnica. La seguridad funcional, el análisis de riesgos y la aprobación de puesta en marcha requieren métodos y responsabilidades que se extienden mucho más allá de la revisión de código asistida por IA. IEC 61508 y las prácticas de seguridad relacionadas dejan claro el punto: la corrección del software se sitúa dentro de un ciclo de vida más amplio de identificación de peligros, reducción de riesgos, verificación, validación y control de gestión (IEC, 2010; exida, 2024).

OLLA Lab y Yaga se entienden mejor como herramientas de ensayo para tareas de alto riesgo que los ingenieros de nivel de entrada rara vez pueden practicar de forma segura en sistemas reales:

• validar la lógica de control,
• monitorear el comportamiento de E/S,
• rastrear causa y efecto,
• manejar condiciones anormales,
• revisar la lógica después de una falla,
• comparar el estado del equipo simulado frente al estado de la escalera.

Eso es un valor sustancial, y es suficiente.

El papel práctico de Yaga es acortar el camino desde "escribí algo" hasta "puedo explicar por qué funciona, por qué falló y qué cambió". Esa es la transición de la familiaridad con la sintaxis al juicio de puesta en marcha.

Dentro de OLLA Lab, ese papel se sitúa dentro de un entorno más amplio que incluye:

• un editor de lógica de escalera basado en web con tipos de instrucciones estándar,
• flujos de trabajo guiados de aprendizaje de escalera,
• modo de simulación para ejecución y pruebas seguras,
• visibilidad de variables y E/S,
• herramientas de aprendizaje analógico y PID,
• ejercicios industriales basados en escenarios,
• flujos de trabajo de validación estilo gemelo digital,
• opciones de vistas de equipo 3D/WebXR/VR,
• funciones de colaboración y revisión para entornos de instrucción.

Yaga no reemplaza esos componentes. Se vuelve útil porque esos componentes ya existen. Una buena asistencia depende de una buena instrumentación; esto es cierto en las plantas y en los sistemas de capacitación.

- IEC 61508 Descripción general de seguridad funcional - IEC 61131-3 Lenguajes de programación de controladores programables - NIST SP 800-207 Arquitectura de confianza cero - Tao et al. (2019) Gemelo digital en la industria (IEEE) - Kritzinger et al. (2018) Gemelo digital en la fabricación (IFAC) - Negri et al. (2017) Gemelo digital en sistemas de producción basados en CPS - Recursos de seguridad funcional de exida - Oficina de Estadísticas Laborales de EE. UU.