Cómo solucionar problemas de un enclavamiento de seguridad PLC retentivo: Detecte el error n.º 2

Un enclavamiento de seguridad de PLC que permanece activo (true) después de un ciclo de potencia suele ser un error de diseño de memoria retentiva. Cuando se utiliza lógica Set/Latch donde se requiere un permisivo no retentivo, la máquina puede volver a entrar en modo RUN con el movimiento aún autorizado, lo que puede entrar en conflicto con la intención de reinicio de las normas NFPA 79 e IEC 60204-1.

Una idea errónea común es que cualquier peldaño (rung) que "funcionaba antes de la pérdida de potencia" es una buena lógica de control. No lo es. En la lógica de permisivos adyacentes a la seguridad, sobrevivir a un reinicio puede ser el defecto.

Considere el modo de fallo: la potencia cae, la CPU se reinicia y un motor o secuencia se reanuda sin una acción nueva por parte del operador. Eso es un riesgo de reinicio.

Métrica de Ampergon Vallis: Durante una prueba simulada de 50 ciclos de pérdida de potencia en el escenario de control de motores de OLLA Lab, los bits de enclavamiento retentivo permanecieron en TRUE durante el estado de reinicio de la CPU en las 50 pruebas, mientras que las salidas equivalentes de enclavamiento no retentivo cayeron a FALSE al reiniciar en menos de 12 ms. Metodología: n=50 pruebas de transición controlada RUN→PROG→RUN en una tarea interna de control de motores; comparador de referencia = peldaño de enclavamiento OTE no retentivo; ventana de tiempo = sesión única de QA el 24/03/2026. Esto respalda la afirmación limitada de que el simulador puede reproducir la distinción de comportamiento entre la lógica retentiva y la no retentiva durante las pruebas de reinicio. No respalda ninguna afirmación más amplia sobre la tasa de fallos en campo.

En este artículo, la tarea es forense: identificar por qué el bit sobrevive, por qué eso importa bajo las expectativas de seguridad de la máquina y cómo reemplazar el patrón con un diseño no retentivo que pueda defender durante la puesta en marcha.

El comportamiento de enclavamiento sobrevive a un reinicio porque las instrucciones retentivas y las instrucciones de salida no retentivas no se tratan de la misma manera durante la inicialización de la CPU.

En la ejecución práctica de un PLC, la distinción es simple: OTE escribe el estado para el escaneo actual; OTL almacena el estado hasta que algo lo elimina explícitamente. La sintaxis puede parecer similar en pantalla. El comportamiento de reinicio es donde termina la discusión.

La rutina de limpieza de pre-escaneo

Cuando un PLC pasa de PROGRAM a RUN, o se recupera de una pérdida de potencia, la CPU normalmente realiza una rutina de inicialización o pre-escaneo. La implementación exacta varía según la plataforma, pero la distinción de ingeniería es consistente:

1. La CPU evalúa las condiciones de inicio antes de que se reanude la ejecución cíclica normal.
2. Las instrucciones de salida estándar no retentivas, como OTE, se borran a FALSE durante el comportamiento de pre-escaneo.
3. Las instrucciones retentivas, como OTL, no se borran simplemente porque el controlador se reinició.
4. Su memoria asociada permanece en el último estado almacenado hasta que se ejecuta una condición de reinicio explícita, como OTU o equivalente.

Es por eso que un permisivo retentivo puede permanecer activo después de un reinicio, incluso cuando ningún operador ha emitido un nuevo comando de inicio.

Lo que esto significa en términos de lógica de escalera (ladder)

Un enclavamiento retentivo responde a una pregunta diferente a la de un circuito de auto-enclavamiento (seal-in).

- Lógica de auto-enclavamiento: "¿Debería esta salida permanecer activa mientras la ruta permisiva actual siga siendo válida?" - Lógica de enclavamiento retentivo: "¿Debería este bit permanecer activo a través de la pérdida de escaneo, cambios de modo o interrupción de potencia hasta que otra instrucción lo borre?"

Esas no son opciones de diseño intercambiables. Una es continuidad de estado. La otra es continuidad de permisivo activo. Confundirlas es cómo se escriben los riesgos de reinicio, peldaño a peldaño.

Un enclavamiento almacena el estado a través de una interrupción. Un circuito de auto-enclavamiento restablece el estado solo mientras las condiciones del peldaño sigan siendo válidas.

Esta es la distinción diagnóstica central.

| Patrón de diseño | Comportamiento de memoria | Comportamiento de reinicio | Uso típico | Idoneidad para permisivos de seguridad | |---|---|---|---|---| | Set-Reset OTL/OTU | Retentivo | El estado puede persistir tras el reinicio hasta que se reinicie explícitamente | alarma de primer evento, memoria de paso de lote, contadores de mantenimiento | Mala elección para permisivos de movimiento o habilitaciones sensibles al reinicio | | Circuito de auto-enclavamiento OTE | No retentivo | La salida cae al reiniciar y debe restablecerse mediante condiciones válidas del peldaño | retención de arranque/parada de motor, permisivos de marcha comandados por operador | Preferido cuando el reinicio debe requerir una re-iniciación deliberada |

Una regla mnemotécnica útil es esta: el enclavamiento es memoria; el auto-enclavamiento es continuidad. A la planta generalmente le importa cuál de los dos quiso implementar.

La NFPA 79 y la IEC 60204-1 exigen que la restauración de la potencia no reinicie automáticamente la maquinaria cuando dicho reinicio cree un peligro.

Este es el problema normativo detrás del problema de codificación. El defecto en la lógica de escalera importa porque el comportamiento de reinicio de la máquina importa.

El principio de las normas

El requisito relevante, expresado en términos de ingeniería práctica, es:

• La pérdida y restauración de la potencia no debe por sí misma causar que se reanude un movimiento peligroso.
• El reinicio debe requerir una acción deliberada cuando la reanudación automática ponga en peligro al personal.
• La parada de emergencia, la interrupción de una guarda o la restauración de la potencia no deben ser puenteadas por un estado retenido obsoleto.

La NFPA 79 y la IEC 60204-1 están alineadas en este punto. La redacción difiere según la edición y el contexto de la aplicación, pero la intención del diseño es estable: no permitir reinicios inesperados peligrosos.

Por qué un bit de "listo" retenido se convierte en un problema normativo

Un bit retenido como `System_Ready`, `Run_Enable` o un permisivo de puerta de seguridad puede omitir la ruta de reinicio manual esperada después de un reinicio.

Eso significa que la lógica puede satisfacer la sintaxis interna mientras viola la filosofía de reinicio de la máquina. A las normas no les importa que el peldaño fuera elegante. Les importa si la máquina se movió cuando debería haber esperado.

Este artículo no es una opinión formal de cumplimiento, y el cumplimiento siempre depende de la evaluación de riesgos completa de la máquina, la arquitectura de seguridad y la jurisdicción aplicable. Pero como regla de diseño de control, usar memoria retentiva para permisivos de movimiento es difícil de defender.

Usted detecta este error observando una transición de estado, no admirando el peldaño de forma aislada.

La revisión de código estático ayuda, pero los defectos de reinicio a menudo se esconden a plena vista. Un peldaño puede parecer ordenado y aun así comportarse mal en el momento en que la CPU parpadea.

Definición operativa de "listo para simulación": un ingeniero está listo para la simulación cuando puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso antes de que esa lógica llegue a un proceso real. En este caso, eso significa reproducir la condición de reinicio, observar la persistencia de las etiquetas (tags) y verificar que la lógica revisada falle de forma segura durante el cambio de estado de la CPU.

Reproducción del fallo paso a paso

Utilice OLLA Lab como un entorno de validación acotado para una prueba de puesta en marcha de alto riesgo que sería insegura o disruptiva operativamente en equipos reales.

1. Abra el escenario de control de motores en OLLA Lab.
2. En el Panel de Variables, monitoree la etiqueta `System_Ready` y cualquier etiqueta de salida o permisivo relacionada.
3. En el Editor de Lógica de Escalera, active la condición de inicio para que el enclavamiento retentivo se energice.
4. Confirme que `System_Ready = TRUE`.
5. Use el Modo de Simulación para cambiar la CPU virtual de RUN a PROG, representando una pérdida de potencia o una transición de modo del controlador.
6. Regrese la CPU de PROG a RUN.
7. Observe si `System_Ready` permanece en TRUE antes de que ocurra cualquier acción nueva del operador.

Si el bit permanece activo después del reinicio, ha reproducido el patrón de fallo.

Por qué esta prueba pertenece primero a la simulación

Aquí es donde OLLA Lab se vuelve operativamente útil.

El valor de la plataforma aquí no es que "enseñe PLCs" en abstracto. Proporciona un lugar para ensayar una prueba de estado de reinicio que a menudo es costosa, incómoda o peligrosa en maquinaria puesta en marcha. Puede monitorear el estado de la escalera, el estado de E/S y el comportamiento del equipo simulado juntos, que es exactamente lo que requieren los diagnósticos de reinicio.

Esa es la diferencia entre la práctica de sintaxis y la práctica de validación. La distinción no es cosmética.

El reemplazo correcto para un permisivo de marcha sensible al reinicio suele ser un circuito de auto-enclavamiento no retentivo construido alrededor de una OTE.

El patrón clásico de control de tres hilos sobrevive porque resuelve un problema real de forma limpia. Los patrones antiguos persisten cuando la física sigue votando a favor de ellos.

Patrón de escalera incorrecto vs. correcto

INCORRECTO: Enclavamiento retentivo (sobrevive al ciclo de potencia)

|---[ Start_PB ]-------------------------------------( L )---| System_Ready

CORRECTO: Auto-enclavamiento no retentivo (cae ante la pérdida de potencia)

|---[ Start_PB ]-------[/ Stop_PB ]------------------( )---| | System_Ready |---[ System_Ready ]---------------------------------|

Por qué el peldaño de auto-enclavamiento es más seguro para este caso de uso

El diseño de auto-enclavamiento no retentivo funciona porque:

• la salida se mantiene solo mientras la lógica del peldaño sigue siendo válida,
• la OTE se borra ante el comportamiento de reinicio,
• el operador debe volver a emitir un comando de inicio después de la restauración de la potencia,
• la ruta de control refleja las condiciones actuales de la máquina en lugar de la memoria histórica.

Eso se alinea con la filosofía de reinicio esperada para muchos comandos de marcha de máquinas y permisivos de movimiento.

Qué verificar después de la revisión

Después de reemplazar el enclavamiento con un peldaño de auto-enclavamiento, repita la prueba de reinicio y verifique:

• `System_Ready` cae a FALSE durante la transición de reinicio,
• ninguna salida reanuda el movimiento sin un comando nuevo,
• las condiciones de parada e interbloqueo siguen rompiendo la ruta de retención correctamente,
• las condiciones anormales no recrean el permisivo inesperadamente.

Una corrección no está completa porque el peldaño parezca más respetable. Está completa cuando el comportamiento de reinicio es correcto.

Debe documentar un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla.

Un registro de resolución de problemas creíble muestra el razonamiento, el método de prueba, la reproducción del fallo y el resultado de la revisión. Eso es lo que los revisores, instructores y empleadores pueden inspeccionar realmente.

Use esta estructura:

Establezca el comportamiento de reinicio esperado en términos observables. Ejemplo: "Tras la restauración de la potencia, la salida del motor deberá permanecer desenergizada hasta que el operador presione Start".

Describa la prueba exacta: transición RUN→PROG→RUN, bit retenido observado, consecuencia en la salida.

Registre el principio de diseño: la memoria retentiva es válida para el estado almacenado, no para la autorización de movimiento sensible al reinicio.

1. Descripción del sistema Defina la celda de la máquina, el objetivo de control y el permisivo o salida afectada.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Capture el peldaño original, las etiquetas relevantes y la condición de la máquina simulada antes y después del reinicio.
4. El caso de fallo inyectado
5. La revisión realizada Muestre la lógica de reemplazo y explique por qué cambia el comportamiento de reinicio.
6. Lecciones aprendidas

Esa estructura es útil en la formación porque refleja la revisión lógica de la puesta en marcha real. También es útil en el campo porque la memoria no es fiable bajo presión de cronograma, mientras que la evidencia escrita es simplemente poco común.

OTL y OTU son válidas cuando el proceso requiere genuinamente un estado retenido a través de una interrupción.

El problema no es la instrucción. El problema es pretender que todo estado merece sobrevivir a un reinicio.

Aplicaciones apropiadas de memoria retentiva

| Aplicación | Por qué el comportamiento retentivo es apropiado | |---|---| | Captura de alarma de primer evento | La fuente de fallo inicial debe permanecer registrada incluso si la potencia se interrumpe antes de la revisión. | | Seguimiento de recetas o pasos de lote | El proceso puede necesitar reanudarse con conocimiento del último paso confirmado. | | Contadores de mantenimiento | Los conteos de ciclos e indicadores de desgaste deben sobrevivir al reinicio para la integridad del mantenimiento. | | Reconocimientos del operador con lógica de reinicio controlada | Ciertos reconocimientos pueden necesitar persistir hasta que se ejecute una ruta de reinicio formal. | | Marcadores de estado de producción no relacionados con la seguridad | Algunos estados de secuencia se retienen intencionalmente para preservar la continuidad del proceso tras una recuperación controlada. |

Cuándo la memoria retentiva debe activar un escrutinio adicional

Aplique una revisión adicional cuando el bit retenido esté vinculado a:

• habilitación de movimiento,
• permisivo de guarda,
• autorización de reinicio,
• ruta de recuperación de E-stop,
• interbloqueos adyacentes a la seguridad,
• cualquier salida cuya restauración inesperada pueda crear riesgo para el personal.

Eso no hace que el diseño no cumpla automáticamente, pero significa que la carga de la justificación acaba de volverse real.

La validación con gemelos digitales ayuda haciendo que el comportamiento de reinicio sea observable en la capa lógica y en la capa de comportamiento del equipo al mismo tiempo.

Ese es el valor operativo. No solo está preguntando si un bit se mantuvo alto. Está preguntando qué haría la máquina porque el bit se mantuvo alto.

En OLLA Lab, el editor de escalera, la visibilidad de variables y el estado del equipo simulado pueden usarse juntos para probar:

• si el bit retenido persiste,
• si la ruta de salida se restablece,
• si el modelo del equipo refleja una condición de arranque no comandada,
• si la lógica revisada elimina ese comportamiento.

Es por esto que la simulación es importante para la práctica de la puesta en marcha. Muchos fallos peligrosos son fallos de transición: arranque, recuperación, cambio de modo, pérdida de permisivo, desacuerdo de sensores, retroalimentación retardada. No siempre son obvios en la operación de estado estable. Las plantas reales no son partidarias de ser utilizadas como cajas de arena para depuración, por razones bastante válidas.

La literatura reciente sobre gemelos digitales, puesta en marcha virtual y formación industrial basada en simulación generalmente respalda el uso de entornos simulados de alta fidelidad para un descubrimiento temprano de fallos, preparación del operador y validación del sistema de control, al tiempo que deja claro que la simulación no reemplaza la validación de seguridad formal o las pruebas de aceptación en sitio. Ese límite importa.

Un enclavamiento de seguridad de PLC retentivo suele ser un error de diseño cuando permite que un permisivo de máquina sobreviva a la restauración de la potencia.

El principio correctivo es sencillo:

• use memoria retentiva para estados que deban sobrevivir a una interrupción,
• use lógica de auto-enclavamiento no retentiva para la autorización de marcha sensible al reinicio,
• pruebe el comportamiento a través de la transición de estado de la CPU en lugar de asumir que la intención del peldaño es obvia,
• documente el fallo, la revisión y el resultado de reinicio observado.

Así es como se ve el trabajo listo para la simulación en la práctica: no solo escribir lógica de escalera, sino probar cómo se comporta cuando el proceso hace algo inconveniente. Lo cual, en la industria, es la mayoría de los días.

- IEC 60204-1 equipo eléctrico de máquinas - IEC 61508 visión general de seguridad funcional - ISO 13849-1 partes de los sistemas de control relativas a la seguridad - Documentación de Studio 5000 Logix Designer - Revisión de puesta en marcha virtual y gemelos digitales (Journal of Manufacturing Systems)