Cómo diagnosticar el síndrome de doble bobina en la lógica de PLC y por qué la IA omite los ciclos de escaneo

El síndrome de doble bobina ocurre cuando un programa de PLC escribe en la misma dirección de salida en varios peldaños, lo que provoca que el último peldaño evaluado sobrescriba la lógica anterior durante el ciclo de escaneo. Debido a que los asistentes de IA genéricos a menudo ignoran el orden de ejecución del PLC y las actualizaciones de salida diferidas, se requiere una validación basada en simulación para detectar y corregir estos fallos de sobrescritura determinista.

Un error común es pensar que el comportamiento de doble bobina es una condición de carrera. En la mayoría de los PLC, no lo es. Es una sobrescritura determinista causada por escribir en el mismo bit direccionado en varios lugares y olvidar que el controlador resuelve el estado en el orden del escaneo, no por la intención del programador.

En una prueba reciente de Ampergon Vallis Lab, el 14% de 500 scripts de lógica de escalera generados por IA para una tarea estándar de clasificación de transportadores contenían direccionamiento de bobina de salida duplicado que producía sobrescrituras destructivas [Metodología: n=500 scripts generados para un escenario de clasificación de transportadores, comparados con un patrón de referencia de bobina única revisado por humanos, recopilados durante pruebas internas en el primer trimestre de 2026]. Esto respalda una afirmación limitada: la IA genérica emite frecuentemente patrones de salida no válidos para el ciclo de escaneo en tareas de escalera acotadas. No respalda una afirmación sobre todas las herramientas de IA, todos los dialectos de PLC o todas las cargas de trabajo de automatización.

El ciclo de escaneo del PLC es un modelo de ejecución determinista en el que las actualizaciones de E/S físicas están separadas de la evaluación de la lógica. Esa separación es el problema central.

Bajo el modelo de programación IEC 61131-3, la lógica de escalera se evalúa en una secuencia repetible. El tiempo exacto varía según el controlador y la configuración de la tarea, pero el patrón central es lo suficientemente estable como para ser relevante a nivel operativo:

- Lectura de entradas: el controlador copia los estados de las entradas físicas en la memoria. - Ejecución de la lógica: los peldaños se resuelven en orden, típicamente de arriba a abajo y de izquierda a derecha. - Escritura de salidas: la imagen de memoria final se envía a los terminales de salida físicos.

La distinción importante es simple: el estado interno puede cambiar durante la ejecución de la lógica, pero las salidas físicas generalmente se actualizan después de que la ejecución se completa. Si dos peldaños escriben en el mismo bit de salida, el último peldaño gana para ese escaneo.

La secuencia de ejecución de 3 fases no es una preferencia de estilo

El ciclo de escaneo no es simplemente un modelo de enseñanza. Es la base para el comportamiento de control determinista, la resolución de problemas y el juicio de puesta en marcha.

Eso importa porque los LLM genéricos están entrenados en gran medida en patrones de software asíncronos o basados en eventos. En esos entornos, una instrucción a menudo implica un efecto inmediato, las devoluciones de llamada (callbacks) pueden dispararse de forma independiente y los errores de concurrencia surgen de interacciones temporales entre hilos, tareas o procesos. La lógica de escalera de PLC generalmente no funciona de esa manera en el caso ordinario de una sola tarea.

Por qué la IA genérica utiliza por defecto el modelo mental incorrecto

Los asistentes de IA genéricos tienden a tratar las instrucciones de escalera como si fueran controladores de eventos. Infieren: si esta condición se vuelve verdadera, energice esa salida ahora. Esa es una suposición propia de TI aplicada a una máquina de OT.

En un PLC, la bobina de salida se entiende mejor generalmente como una escritura en una ubicación de memoria que posteriormente participará en la actualización de la imagen de salida. Una vez que se pasa por alto esa distinción, las bobinas duplicadas pueden parecer inofensivas para el modelo. No son inofensivas. Son contradicciones diferidas.

No. En la ejecución estándar de escalera de PLC, el síndrome de doble bobina suele ser una sobrescritura determinista, no una condición de carrera.

Una condición de carrera en TI se refiere a un fallo dependiente del tiempo entre operaciones concurrentes, donde el resultado depende de qué hilo o proceso llegue primero al estado compartido. Esa definición es útil en ingeniería de software, pero a menudo se aplica mal en controles.

Un fallo de doble bobina en un PLC típico es diferente:

• El controlador ejecuta en un orden definido.
• El mismo bit direccionado se escribe más de una vez.
• La última escritura en el orden de ejecución determina el estado final para ese escaneo.
• El resultado es repetible a menos que las tareas, saltos o servicios asíncronos compliquen la estructura del programa.

El contraste correcto es sobrescritura frente a concurrencia

Utilice esta distinción al revisar la lógica de escalera generada por IA:

- Condición de carrera de TI: anomalía temporal entre operaciones concurrentes. - Fallo de sobrescritura de OT: resolución de estado determinista donde gana el último peldaño.

Esa distinción importa porque la solución es diferente. Los fallos de sobrescritura determinista se resuelven consolidando la autoridad de salida, no aplicando conceptos de seguridad de hilos.

El síndrome de doble bobina aparece como una discrepancia entre las condiciones lógicas visibles y el comportamiento real de la máquina. Parte del programa puede parecer correcta mientras la planta hace otra cosa.

Los síntomas comunes incluyen:

- El peldaño "muerto": un peldaño es verdadero, está resaltado y aparentemente comandando un motor o válvula, pero el dispositivo no se activa porque un peldaño posterior escribe la misma salida como falsa. - Divergencia de estado entre la lógica y el equipo: se acepta un comando HMI, un permisivo interno parece satisfecho, pero la salida física permanece apagada después de que el escaneo se resuelve. - Chasquido o tartamudeo intermitente: en estructuras más complejas que involucran saltos, secuenciadores o bits intermedios mal gestionados, las sobrescrituras repetidas pueden contribuir a un comportamiento inestable del dispositivo o al desgaste de los relés. - Confusión en la puesta en marcha: un técnico prueba el cableado de campo, la tarjeta de E/S y la ruta del contactor, pero la carga aún se niega a responder de manera consistente. El fallo está en la propiedad del estado, no en el cobre.

Por qué esto importa más durante la puesta en marcha que durante la codificación

La puesta en marcha expone los conflictos de estado rápidamente porque el proceso responde. Una bobina duplicada en una revisión de código es un mal patrón. Una bobina duplicada en un permisivo de bomba en vivo puede convertirse en un falso "no arranca", un disparo molesto o un turno perdido mientras se culpa primero al panel.

Es por esto que la sintaxis y la capacidad de despliegue no son lo mismo.

Los errores de doble bobina generados por IA suelen provenir de la finalización de patrones locales en lugar del diseño de estado de todo el programa. El modelo ve dos condiciones legítimas que deberían energizar el mismo actuador y emite dos bobinas de salida separadas en lugar de una ruta de comando consolidada.

Las causas típicas incluyen:

- Generación de código condición por condición: el modelo escribe un peldaño por requisito sin reconciliar la propiedad de salida compartida. - Poca conciencia del ciclo de escaneo: el modelo no razona de manera confiable sobre las actualizaciones de salida diferidas. - Transferencia de modismos de TI a la lógica de OT: trata las salidas como acciones inmediatas en lugar de asignaciones de estado respaldadas por memoria. - Poca distinción entre bits de comando y salidas físicas: la IA a menudo escribirá directamente en una salida de hardware donde un ingeniero humano construiría primero un bit de comando interno, luego aplicaría enclavamientos y el mapeo de salida final en un solo lugar.

El problema más profundo es arquitectónico, no gramatical

Un diagrama de escalera puede parecer sintácticamente válido y seguir siendo operativamente incorrecto. La IA suele ser competente en el vocabulario de instrucciones y más débil en la estructura de autoridad.

Una pregunta de revisión útil es: ¿quién posee este bit de salida? Si la respuesta son varios peldaños, dependiendo de lo que solicitó el prompt, el programa ya se está desviando hacia problemas.

La corrección correcta es garantizar que cada salida física tenga un único punto deliberado de resolución de estado, o un patrón de enclavamiento/desenclavamiento (latch/unlatch) gestionado explícitamente donde ese comportamiento esté justificado y sea revisable.

### Patrón 1: Consolidar condiciones en un solo peldaño de salida

Esta es la corrección más simple y generalmente la mejor.

Error de IA: bobina de salida duplicada

Peldaño 1: [ Sensor_A ] --------------------( Motor_Run ) Peldaño 2: [ Sensor_B ] --------------------( Motor_Run ) // Sobrescribe el Peldaño 1

Corrección humana: rama paralela a una bobina de salida

Peldaño 1: [ Sensor_A ] --+-----------------( Motor_Run ) | [ Sensor_B ] --+

Esto preserva un punto de autoridad para `Motor_Run`. Múltiples condiciones de inicio válidas se combinan antes de que ocurra la escritura.

### Patrón 2: Usar un bit de comando interno, luego mapear a la salida una vez

Este patrón suele ser más limpio en proyectos reales porque separa la lógica de proceso del accionamiento del hardware.

Peldaño 1: [ Sensor_A ] --+-----------------( Motor_Run_Cmd ) | [ Sensor_B ] --+

Peldaño 2: [ Motor_Run_Cmd ] [ All_Permissives_OK ] ----( Motor_Run_Output )

Esta estructura mejora la capacidad de revisión y el rastreo de fallos:

• la intención del comando es visible,
• los enclavamientos están centralizados,
• el mapeo de salida física es singular,
• la simulación se vuelve más fácil de interpretar.

### Patrón 3: Usar latch/unlatch solo cuando el modelo de estado lo requiera

Un par `OTL/OTU` o una estructura de set/reset equivalente puede ser correcta cuando el proceso requiere un estado de comando retenido, memoria de secuencia o comportamiento de reconocimiento del operador. No es un parche genérico para una estructura de peldaño deficiente.

Use latch/unlatch cuando pueda responder a todo lo siguiente:

• ¿Qué evento establece el estado?
• ¿Qué evento lo borra?
• ¿Qué condición anormal debe forzar el reinicio?
• ¿Cómo se validará el estado retenido durante el arranque y reinicio?

Si esas respuestas son vagas, el latch probablemente no esté justificado.

El diagnóstico más rápido es rastrear la autoridad de salida a través de un escaneo completo y verificar si el estado final del bit coincide con las indicaciones del peldaño anterior.

Utilice esta secuencia:

1. Encuentre cada escritura en el bit de salida direccionado. Busque en el programa todas las instancias de la misma dirección de bobina o etiqueta mapeada.
2. Identifique el orden de los peldaños. Determine qué escritura se ejecuta al final en la tarea o rutina relevante.
3. Compruebe si la salida es física o interna. Las escrituras duplicadas en bits internos también son peligrosas, pero las escrituras duplicadas en salidas físicas suelen ser más urgentes.
4. Pruebe las combinaciones verdadero/falso. Fuerce o simule cada condición de entrada y observe si la lógica verdadera anterior es negada posteriormente.
5. Verifique el comportamiento de la imagen de salida final. No se detenga en el resaltado del peldaño. Confirme el estado de la etiqueta resuelta después de la ejecución de la lógica.
6. Refactorice a un único punto de autoridad. Consolide ramas, use bits de comando o rediseñe la propiedad de la secuencia.

Qué documentar como evidencia de ingeniería

Si está revisando lógica generada, construya un cuerpo de evidencia compacto en lugar de una galería de capturas de pantalla. Una estructura práctica es:

1. Descripción del sistema
2. Definición operativa del comportamiento correcto
3. Lógica de escalera y estado del equipo simulado
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas

Este formato muestra razonamiento, no solo uso de herramientas.

OLLA Lab es útil aquí como un entorno de diagnóstico porque permite a los ingenieros observar el estado de la escalera, el comportamiento de E/S y la respuesta del equipo simulado antes de que intervenga cualquier hardware real.

En el Modo de Simulación, puede ejecutar la lógica, alternar entradas y ver cómo cambian las salidas y variables en tiempo real. En el Panel de Variables, puede inspeccionar estados de etiquetas, valores de E/S, comportamiento analógico y condiciones de escenario mientras la lógica se ejecuta. Esa visibilidad es lo que expone los fallos de doble bobina: un peldaño puede parecer válido, pero el estado final del bit muestra la sobrescritura posterior.

Qué significa "listo para simulación" en este contexto

"Listo para simulación" significa que el ingeniero puede probar, observar, diagnosticar y fortalecer la lógica de control contra el comportamiento real del proceso antes de que llegue a un proceso en vivo.

Operativamente, eso incluye la capacidad de:

• rastrear causa y efecto a través del escaneo,
• comparar el estado de la escalera con el estado del equipo simulado,
• probar condiciones anormales y fallos de permisivos,
• revisar la lógica después de un fallo,
• verificar que la autoridad de salida final sea singular e intencional.

Esa definición es más estrecha que conocer la sintaxis de escalera y más útil que confiar solo en la intuición.

Un flujo de trabajo práctico de OLLA Lab para el diagnóstico de doble bobina

Use OLLA Lab de esta manera:

1. Cargue o construya la lógica de escalera en el editor.
2. Entre en el Modo de Simulación.
3. Alterne las entradas relevantes una por una y en combinación.
4. Observe la etiqueta de salida direccionada en el Panel de Variables.
5. Compare la veracidad del peldaño con el estado final de la etiqueta.
6. Observe el comportamiento de la máquina simulada frente a la salida resuelta.
7. Refactorice la lógica a una ruta de autoridad de salida única.
8. Vuelva a probar el mismo caso de fallo y documente la corrección.

OLLA Lab no corrige el programa automáticamente. Proporciona un lugar controlado para detectar la divergencia de estado antes de que intervenga un actuador, bomba, transportador o válvula real.

Dónde encaja Yaga, y dónde no

GeniAI, el guía de laboratorio de IA de OLLA Lab, puede apoyar la incorporación, la orientación correctiva y la asistencia en lógica de escalera dentro de la plataforma. En este contexto, su valor es limitado: puede ayudar a señalar al alumno problemas de lógica revisables y pasos de validación específicos de la plataforma.

No debe tratarse como un sustituto del juicio de ingeniería, la revisión funcional o la aprobación específica del sitio. La IA genérica puede generar el fallo; la IA guiada en un entorno de validación restringido puede ayudar a sacarlo a la superficie. Esas no son la misma cosa.

La validación de gemelos digitales importa porque los fallos del ciclo de escaneo no son meramente errores simbólicos; crean discrepancias entre el estado de control previsto y el comportamiento observado de la máquina.

Cuando la lógica de escalera se prueba contra modelos de máquina o escenarios de proceso realistas, el ingeniero puede comparar:

• estado comandado,
• respuesta real del equipo simulado,
• comportamiento de alarmas y permisivos,
• manejo de fallos bajo entradas anormales.

Ese es el puente práctico desde la corrección del código hasta el juicio de puesta en marcha. Un peldaño puede ser legal y aun así ser incorrecto para el proceso. La validación de gemelos digitales ayuda a exponer esa diferencia antes de que lo haga el campo.

Esto se alinea con una base de literatura de ingeniería más amplia que sugiere que la simulación y la validación asistida por gemelos digitales pueden mejorar el descubrimiento de fallos, la comprensión del operador y la verificación previa a la puesta en marcha cuando se utilizan con límites de modelo claros y casos de prueba realistas. La literatura no justifica afirmaciones amplias, pero respalda la proposición más estrecha de que la simulación realista es útil cuando el modo de fallo depende del comportamiento dinámico del sistema en lugar de solo de la sintaxis estática.

Los ingenieros deben revisar la lógica de escalera generada por IA en cuanto a propiedad del estado, efectos del orden de escaneo, estructura de permisivos y comportamiento ante fallos antes de considerarla desplegable.

Una lista de verificación de revisión práctica:

• ¿Tiene cada salida física un punto claro de autoridad?
• ¿Están los bits de comando separados de las salidas de hardware cuando corresponde?
• ¿Están los enclavamientos y disparos centralizados y revisables?
• ¿Se comporta la lógica correctamente a lo largo de un escaneo completo, no solo un peldaño?
• ¿Se pueden simular y observar las condiciones anormales de forma segura?
• ¿Se define el comportamiento correcto en términos de proceso, no solo en términos de código?

Ese último punto a menudo se descuida. "El peldaño se vuelve verdadero" no es una definición operativa de éxito. "La bomba arranca solo cuando se satisfacen los permisivos, se detiene ante un disparo, alarma ante una prueba fallida y permanece estable durante el reinicio" es más cercano.

El síndrome de doble bobina es un fallo de sobrescritura de estado de PLC determinista, no suele ser una condición de carrera. La IA genérica tiende a producirlo porque completa patrones lógicos locales sin modelar de manera confiable la resolución de estado del ciclo de escaneo y las actualizaciones de salida diferidas.

La solución es sencilla en principio y disciplinada en la práctica: consolidar la autoridad de salida, validar el estado final de la etiqueta y probar la lógica contra el comportamiento realista de la máquina antes de la puesta en marcha. OLLA Lab encaja en ese flujo de trabajo como un simulador de lógica de escalera y gemelo digital basado en web donde los ingenieros pueden observar, diagnosticar y revisar estos fallos de forma segura. Ese es un papel creíble para un entorno de simulación y una forma práctica de distinguir el código que parece plausible de la lógica que puede sobrevivir al contacto con un proceso.

Este artículo fue redactado por el equipo de ingeniería de OLLA Lab, especializado en la validación de sistemas de control industrial y la integración de IA en entornos de automatización.

El contenido técnico sobre el ciclo de escaneo del PLC y el síndrome de doble bobina ha sido verificado contra los estándares IEC 61131-3 y las prácticas de puesta en marcha de sistemas de control industrial. Los datos sobre el rendimiento de la IA se basan en pruebas internas realizadas en Ampergon Vallis Lab durante el primer trimestre de 2026.

- 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 de gemelos digitales (NIST)