Cómo programar paradas de emergencia e interbloqueos de seguridad: Guía de programación defensiva de PLC

Programar correctamente las paradas de emergencia (E-Stops) y los interbloqueos de seguridad requiere un enfoque de diseño de PLC defensivo: las funciones de seguridad por hardware deben eliminar la energía peligrosa, mientras que la lógica estándar del PLC debe responder de forma determinista, desactivar los estados de ejecución y evitar reinicios inesperados. OLLA Lab proporciona un entorno de simulación acotado para validar estos comportamientos ante condiciones anormales antes de la puesta en marcha real.

Un error común es pensar que "programar la parada de emergencia" significa que el PLC está ejecutando la función de seguridad. No es así. Según las prácticas reconocidas de seguridad en máquinas, la función de parada de emergencia debe ser implementada mediante hardware de seguridad o sistemas de control con clasificación de seguridad adecuadamente diseñados, mientras que la lógica estándar del PLC normalmente monitoriza ese estado de seguridad y reacciona eliminando las órdenes de marcha por software, activando alarmas y bloqueando las rutas de reinicio.

La brecha práctica no está en la sintaxis, sino en el comportamiento ante fallos. Un programa de nivel junior a menudo demuestra que una máquina puede arrancar; un programa defendible demuestra qué sucede cuando un cable se rompe, una prueba no llega o un operador restablece la parada de emergencia.

Métrica de Ampergon Vallis: En una revisión interna de 5,000 proyectos de lógica de contactos (ladder) enviados por usuarios en escenarios de cintas transportadoras en OLLA Lab, el 68% de las presentaciones iniciales no lograron mantener el estado de marcha del motor desactivado tras un reinicio simulado de la parada de emergencia hasta que se emitió una orden de reinicio deliberada. Metodología: n=5,000 presentaciones de estudiantes en tareas de parada/arranque de cintas transportadoras; comparador base = comportamiento esperado de no reinicio automático tras la restauración del estado de seguridad; ventana temporal = 1 de enero de 2025 al 28 de febrero de 2026. Esto respalda un punto específico sobre errores de formación comunes en la lógica de reinicio. No mide las tasas de incidentes en campo, el rendimiento de seguridad de la planta ni la competencia de la fuerza laboral en general.

La programación defensiva en la automatización industrial significa diseñar la lógica de contactos bajo la premisa de que los dispositivos fallarán, los operadores actuarán fuera de secuencia y la retroalimentación del proceso a veces faltará, llegará tarde o será falsa. Esa es la base de diseño normal, no pesimismo. Las plantas son muy eficaces encontrando la única rama que usted no probó.

En el trabajo con PLC, la programación defensiva es la distinción entre hacer posible el movimiento y hacer que la operación sea controlable bajo condiciones anormales. Lo primero es fácil de demostrar. Lo segundo es lo que sobrevive a la puesta en marcha.

Un programa de control defendible suele incluir:

• permisivos explícitos para el arranque,
• interbloqueos activos para detener o inhibir la continuación,
• comprobaciones de prueba de operación,
• gestión de tiempos de espera (timeouts),
• generación de alarmas,
• disciplina de reinicio tras disparos o eventos de parada de emergencia,
• lógica de reinicio de estado que sea deliberada en lugar de implícita.

Aquí es también donde "Simulation-Ready" (Listo para simulación) necesita una definición precisa. En el uso de Ampergon Vallis, un ingeniero "Simulation-Ready" no es alguien que solo conoce la sintaxis ladder. Significa un ingeniero capaz de probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento real del proceso antes de que llegue a un proceso en vivo.

Por qué el diseño de entradas a prueba de fallos suele comenzar con lógica normalmente cerrada

El diseño discreto a prueba de fallos a menudo utiliza dispositivos de campo normalmente cerrados (NC) para circuitos críticos de parada y permisivos, de modo que un cable roto, una pérdida de energía o un circuito abierto tiendan a una condición de parada en lugar de una de marcha. El principio es simple: el fallo debe parecerse al estado seguro.

En términos de software, esto a menudo significa que el PLC ve un bit de estado de cadena de seguridad saludable solo cuando el circuito monitorizado está intacto. Si el circuito se abre inesperadamente, el bit cae. Una máquina en buen estado no debería depender de una continuidad deseada.

Esto no convierte a un PLC estándar en uno con clasificación de seguridad. Hace que la respuesta del PLC estándar a la cadena de seguridad sea más determinista y fácil de validar.

La estructura correcta consiste en separar la función de seguridad de la respuesta estándar del PLC. La función de parada de emergencia en sí misma debe eliminar la energía peligrosa mediante relés de seguridad cableados, contactores o un PLC de seguridad o controlador de seguridad diseñado para tal fin. El PLC estándar monitoriza entonces un estado auxiliar de esa ruta de seguridad y lo utiliza para eliminar las órdenes de marcha por software, borrar enclavamientos, inhibir el reinicio y gestionar los mensajes al operador.

Esa distinción es importante porque la norma IEC 61508 aborda la disciplina del ciclo de vida de la seguridad funcional, y la ISO 13850 define la función de parada de emergencia como una medida de protección complementaria y no como una conveniencia de software. Si la lógica estándar pretende ser la capa de seguridad, el diseño ya ha tomado un rumbo equivocado.

Una secuencia práctica para la respuesta del PLC estándar

Una implementación típica en un PLC que no es de seguridad realiza lo siguiente:

1. Monitoriza un bit de "cadena de seguridad saludable" derivado de un contacto auxiliar de un relé de seguridad o estado equivalente.
2. Coloca ese bit en serie con la autorización de marcha para que la ruta de software colapse inmediatamente cuando se pierde la seguridad.
3. Elimina la lógica de auto-enclavamiento (seal-in) ante la pérdida de seguridad.
4. Requiere una orden de reinicio deliberada tras el restablecimiento, en lugar de permitir el reinicio automático cuando la parada de emergencia se restablece físicamente.
5. Anuncia la causa para que el operador y el técnico puedan distinguir entre parada de emergencia, fallo de permisivo, disparo de interbloqueo y tiempo de espera de prueba.

Ejemplo de patrón ladder para lógica de marcha consciente de la parada de emergencia

A continuación, se muestra un patrón simplificado para la lógica estándar de PLC que refleja el estado de seguridad. Es ilustrativo, no un diseño certificado de seguridad.

Patrón ladder:

• `StartPB` en serie con `StopPB` y `EStop_OK` energiza `RunCmd`.
• `RunCmd` con `StopPB`, `EStop_OK` y `Permissive_OK` mantiene una ruta de auto-enclavamiento como `Mtr_SealIn`.
• `Mtr_SealIn` activa `Motor_Run`.

Interpretación:

• `EStop_OK` es verdadero solo cuando la cadena de seguridad monitorizada está saludable.
• Si `EStop_OK` cae, la ruta de marcha y la ruta de auto-enclavamiento colapsan.
• Cuando `EStop_OK` vuelve tras el reinicio, el motor no arranca automáticamente a menos que se emita `StartPB` de nuevo.

Ese último punto no es cosmético. Evitar el reinicio inesperado es uno de los requisitos de comportamiento fundamentales en torno a la respuesta de parada de emergencia.

¿Qué debería suceder tras el reinicio de la parada de emergencia?

Tras restablecer la parada de emergencia, el PLC estándar debe permanecer en estado de parada hasta que se cumplan todas las condiciones de reinicio requeridas y se realice una acción de arranque deliberada. En muchos sistemas, esto incluye:

• cadena de seguridad restaurada,
• comando de parada saludable,
• ninguna condición de disparo activa,
• estado de secuencia restablecido o reconocido,
• reinicio emitido por el operador.

Si su lógica se reinicia porque el enclavamiento sobrevivió o porque la condición de arranque nunca se borró, el código no está "casi bien". Está mal de una manera peligrosa.

Un permisivo es una condición que debe ser verdadera antes de que se permita iniciar una secuencia. Un interbloqueo es una condición que detiene, inhibe o interrumpe la operación cuando ocurre una condición de funcionamiento insegura o inválida. Los niveles junior a menudo confunden los términos porque ambos aparecen como contactos en la lógica ladder. Al proceso no le importa el vocabulario, pero la revisión de diseño sí.

Permisivo vs. interbloqueo

| Tipo de lógica | Función | Temporización típica | Ejemplo en OLLA Lab | |---|---|---|---| | Permisivo | Condición previa al arranque que debe satisfacerse antes de la iniciación | Antes de la orden de marcha o inicio de secuencia | Nivel de tanque por encima del mínimo antes de arrancar la bomba | | Interbloqueo | Condición de funcionamiento activo que fuerza la parada, inhibición o disparo si se viola | Durante la operación | Presión de descarga alta-alta dispara la bomba en marcha | | Permisivo con relevancia de auto-enclavamiento | Debe ser verdadero para arrancar y a veces permanecer verdadero para continuar, según la filosofía | Arranque y posiblemente marcha | Puerta de seguridad cerrada antes de iniciar el ciclo | | Disparo / interbloqueo de parada | Fuerza una parada inmediata o secuenciada | Durante un estado anormal | Sobretemperatura o pérdida de retroalimentación de sobrecarga del motor |

Una distinción de diseño útil

Los permisivos responden a: "¿Puedo arrancar?" Los interbloqueos responden a: "¿Puedo continuar?"

Ese contraste es compacto porque es operativamente útil. También expone rápidamente la lógica deficiente.

### Ejemplo: control de bomba

Para una secuencia de bomba simple:

- Permisivo: Nivel de pozo húmedo por encima del umbral bajo-bajo. - Permisivo: Sobrecarga del motor no disparada. - Interbloqueo: Presurostato de descarga alta se abre durante la marcha. - Interbloqueo: La retroalimentación de prueba de marcha no se activa en 3 segundos. - Regla de reinicio: Tras el disparo, requerir reinicio del operador y reemisión del arranque.

Aquí es donde la filosofía de control importa más que el número de peldaños (rungs). Un programa corto puede seguir estando muy mal.

El enfoque más limpio es separar la lógica en capas distintas: autorización de arranque, mantenimiento de marcha, detección de disparos y disciplina de reinicio. Mezclarlos en un peldaño denso ahorra espacio vertical pero pierde claridad. Las pantallas son baratas; la ambigüedad es cara.

Una estructura práctica se ve así:

1. Capa de autorización de arranque

Utilice un bit dedicado como `Start_Permissive_OK` construido a partir de todas las precondiciones requeridas:

• estado saludable de parada de emergencia monitorizado desde el hardware de seguridad,
• servicios disponibles,
• ningún disparo activo,
• condición de proceso requerida presente,
• selección de modo válida.

2. Capa de mantenimiento de marcha

Utilice un bit separado como `Run_Allowed` que permanezca verdadero solo mientras las condiciones de marcha activas sigan siendo aceptables:

• ningún disparo de interbloqueo,
• ningún comando de parada,
• ningún tiempo de espera de prueba,
• ninguna interrupción de secuencia.

3. Capa de detección de disparos

Cree bits de disparo explícitos en lugar de ocultar las causas de disparo dentro de un solo peldaño de marcha:

• `Trip_HighPressure`
• `Trip_ProofFail`
• `Trip_Overtemp`
• `Trip_EStopObserved`

Esto mejora el diagnóstico, los mensajes en la HMI y la revisión post-fallo.

4. Disciplina de reinicio

Requiera un reinicio manual cuando sea apropiado, luego requiera un nuevo comando de arranque. El reinicio debe borrar el estado de disparo; no debe emitir movimiento silenciosamente.

Esa distinción vale la pena mantenerla clara: reinicio no es arranque.

El manejo de fallos no puede validarse en el "camino feliz". Debe inyectar el fallo, observar la transición de estado y revisar la lógica si la respuesta es incorrecta. Ese es todo el ejercicio.

Aquí es donde OLLA Lab se vuelve operativamente útil. Su editor ladder basado en navegador, el Modo Simulación, la visibilidad de variables y los modelos de equipos basados en escenarios permiten a los ingenieros probar condiciones anormales sin tocar equipos energizados.

Qué hace OLLA Lab en este flujo de trabajo

OLLA Lab debe posicionarse cuidadosamente aquí. No reemplaza la puesta en marcha en sitio, la validación de seguridad ni la evaluación formal de seguridad funcional. Proporciona un entorno de ensayo con riesgos contenidos para tareas que son demasiado peligrosas, disruptivas o costosas para practicar casualmente en activos reales.

En términos prácticos, la plataforma permite a los usuarios:

• construir lógica ladder en un editor basado en web,
• ejecutar y detener la simulación de forma segura,
• alternar entradas y observar salidas en tiempo real,
• inspeccionar variables, etiquetas (tags), valores analógicos y estados de control,
• comparar el comportamiento ladder frente a la respuesta simulada del equipo,
• trabajar dentro de escenarios industriales realistas con peligros documentados y notas de puesta en marcha.

Ese es el caso de uso correcto: ensayo, validación e iteración consciente de fallos.

Cómo probar una respuesta de parada de emergencia en OLLA Lab

Una secuencia de validación útil en OLLA Lab es directa:

5. Confirme que:

• la bobina de marcha cae,
• el auto-enclavamiento cae,
• el estado de salida se desenergiza,
• cualquier indicación de disparo o alarma se activa como se espera.

1. Construya un peldaño de arranque/parada de motor con una rama de auto-enclavamiento.
2. Añada un bit monitorizado `EStop_OK` en serie con la ruta de marcha.
3. Inicie la máquina simulada.
4. En el Modo Simulación, utilice el Panel de Variables para forzar el bit de parada de emergencia saludable de verdadero a falso.
5. Restaure `EStop_OK` a verdadero.
6. Confirme que la máquina permanece parada hasta que se emita un nuevo comando de arranque.

Esa secuencia enseña más que sintaxis. Enseña disciplina de reinicio y conciencia de estado.

Por qué importa la inyección de fallos basada en escenarios

La simulación basada en escenarios importa porque los interbloqueos son contextuales. Una cinta transportadora, una estación de elevación, una unidad de tratamiento de aire y un mezclador no fallan de la misma manera, y no deben programarse como si lo hicieran.

La estructura de escenarios de OLLA Lab es útil aquí porque vincula la lógica a:

• mapeos de E/S,
• filosofía de control,
• peligros,
• requisitos de secuenciación,
• enlaces analógicos o PID donde sea relevante,
• pasos de verificación.

Eso convierte un ejercicio de ladder en un ensayo de puesta en marcha. La diferencia no es sutil.

El comportamiento correcto debe definirse operativamente antes de comenzar las pruebas. "Se ve bien" no es un criterio de prueba.

Para una respuesta estándar de PLC ante un evento de parada de emergencia monitorizado, una definición funcional de correcto suele incluir:

• la orden de marcha por software cae dentro de la siguiente respuesta de escaneo ante la pérdida del estado de seguridad monitorizado,
• el estado de marcha enclavado no sobrevive al evento de parada de emergencia,
• las salidas comandadas por la lógica estándar se desenergizan apropiadamente,
• el estado de alarma o evento identifica la causa de la parada,
• el restablecimiento del estado físico de la parada de emergencia por sí solo no reinicia el movimiento,
• el reinicio requiere una acción deliberada del operador y cualquier secuencia de reinicio requerida.

Para un diseño de permisivo o interbloqueo, el comportamiento correcto también puede incluir:

• la secuencia no puede arrancar con permisivos fallidos,
• el disparo activo interrumpe el estado de marcha de forma predecible,
• el tiempo de espera de la retroalimentación de prueba se detecta dentro de la ventana configurada,
• la máquina de estados de secuencia vuelve a un estado seguro definido tras el disparo,
• ningún enclavamiento oculto o bit retenido causa un reinicio involuntario.

Es por esto que la simulación debe estar basada en evidencia. Si los criterios de aceptación son vagos, el resultado de la prueba también lo será.

Si desea demostrar un juicio de control real, mantenga un cuerpo compacto de evidencia de ingeniería en lugar de una carpeta de capturas de pantalla. Las capturas de pantalla son fáciles de recopilar y fáciles de malinterpretar.

Utilice esta estructura:

Especifique el fallo introducido: pérdida de parada de emergencia, fallo de prueba, disparo por presión, permisivo roto, estado de sensor atascado, tiempo de espera o condición dependiente de comunicación si está modelada.

1. Descripción del sistema Defina la máquina o celda de proceso, su objetivo operativo, E/S principales y estados relevantes para la seguridad.
2. Definición operativa de "correcto" Establezca el comportamiento exacto esperado para el arranque, parada, evento de parada de emergencia, disparo, reinicio y re-arranque.
3. Lógica ladder y estado del equipo simulado Capture los peldaños relevantes, estados de las etiquetas y condición de la máquina simulada en el momento de la prueba.
4. El caso de fallo inyectado
5. La revisión realizada Registre qué cambió en la lógica después de observar el fallo.
6. Lecciones aprendidas Resuma el error de diseño y el principio corregido, como "la rama de auto-enclavamiento debe colapsar ante la pérdida del estado de seguridad" o "el bit de reinicio no debe funcionar como comando de arranque".

Ese paquete es mucho más creíble que una galería pulida. La evidencia de ingeniería debe explicar el comportamiento, no simplemente decorarlo.

El límite clave es que la lógica ladder estándar de PLC no es un sustituto para una implementación de parada de emergencia con clasificación de seguridad. Ese es el primer principio.

El segundo principio es que el software sigue siendo importante porque gobierna la respuesta determinista de la máquina después de que la función de seguridad actúa. En la práctica, eso incluye:

• eliminar permisos de marcha por software,
• borrar el estado de secuencia donde sea necesario,
• prevenir reinicios inesperados,
• anunciar la causa,
• apoyar una recuperación ordenada.

Las referencias relevantes incluyen:

• ISO 13850 para la función de parada de emergencia y la prevención de reinicio inesperado en el contexto de la máquina.
• IEC 61508 para el marco más amplio de seguridad funcional y pensamiento de ciclo de vida.
• ISO 13849-1 e IEC 62061 también pueden ser relevantes en el diseño de seguridad de máquinas dependiendo de la arquitectura y la integridad de rendimiento requerida.
• La orientación de organizaciones como exida suele ser útil para la interpretación práctica del ciclo de vida de seguridad y la disciplina de validación.

Es necesaria una advertencia final: la validación por simulación es valiosa, pero no establece por sí misma la idoneidad SIL, el logro de PL, el cumplimiento legal o la preparación del sitio. Mejora la calidad de la lógica y la preparación para la puesta en marcha. Esos son beneficios importantes. No son lo mismo que la certificación.

La transición ocurre cuando deja de preguntar solo si el peldaño es sintácticamente correcto y comienza a preguntar si la respuesta del proceso es defendible ante un fallo. Ese es el verdadero umbral.

Una mentalidad de grado de puesta en marcha suele incluir estos hábitos:

• probar estados anormales tan deliberadamente como los estados normales,
• forzar retroalimentaciones faltantes y transiciones retrasadas,
• verificar que los enclavamientos colapsen cuando deben,
• separar el reinicio del arranque,
• documentar las causas de disparo explícitamente,
• comparar el estado del controlador con el estado del equipo simulado,
• revisar la lógica basada en el comportamiento de fallo observado, no en la intuición.

Este es el valor acotado de OLLA Lab. Ofrece a los ingenieros un lugar para ensayar las tareas exactas que las plantas reales son reacias a ofrecer como ejercicios para principiantes: inyectar fallos, rastrear causa y efecto, validar el comportamiento de reinicio y corregir la lógica antes de que el hardware esté involucrado.

Eso no es glamoroso. Es simplemente cómo se construye un trabajo de control competente.

Este artículo ha sido desarrollado por el equipo de ingeniería de OLLA Lab y Ampergon Vallis para promover mejores prácticas en la programación de sistemas de control industrial.

El contenido técnico ha sido revisado para asegurar la alineación con los principios de seguridad funcional (IEC 61508) y las normas de seguridad de maquinaria (ISO 13850), enfatizando la distinción entre la lógica de seguridad cableada y la lógica de control estándar.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)