Cómo probar escenarios "qué pasaría si" en PLCs mediante RV para el análisis de fallos

El análisis de fallos de alta interacción consiste en la inyección deliberada de fallos de control realistas, como la pérdida de retroalimentación de sensores, consignas negativas y fallos de verificación, en la lógica del PLC para verificar las respuestas defensivas. WebXR y los gemelos digitales en RV hacen que estas pruebas sean observables y repetibles sin exponer a los equipos reales, a los operadores o a los activos de producción a riesgos innecesarios.

Probar solo la secuencia prevista no es validación. Es un ensayo para un mundo en el que nada sale mal, que no es el mundo en el que operan las plantas.

Tanto la norma IEC 61508 como la IEC 61511 impulsan a los equipos de ingeniería hacia la validación del ciclo de vida bajo condiciones anormales y de fallo, no solo bajo un comportamiento nominal. La dificultad es práctica: muchos de los estados de fallo que vale la pena probar son precisamente aquellos que un sitio responsable no le permitirá inducir en equipos reales. Pocos gerentes de operaciones se muestran entusiastas ante la idea de forzar brevemente una señal analógica errónea en un equipo en funcionamiento.

Durante la evaluación comparativa interna de los escenarios de skid de proceso 3D de OLLA Lab, los ingenieros que practicaron la inyección de fallos por pérdida de retroalimentación identificaron y corrigieron el comportamiento desbocado de un PID un 62% más rápido que el grupo de comparación que solo utilizó diagramas 2D [Metodología: n=26 estudiantes e ingenieros junior; tarea definida como diagnosticar y corregir un desbocamiento de control de nivel simulado causado por pérdida de señal; el comparador base fue formación solo con editor de escalera sin interacción 3D/WebXR; medido a lo largo de una ventana de laboratorio de 14 días]. Esto respalda una afirmación limitada: la consecuencia visual del fallo puede mejorar la velocidad de diagnóstico en este contexto de formación. No demuestra un rendimiento universal en campo en todas las plantas, equipos o tipos de proceso.

El análisis de fallos de alta interacción es la práctica de inyectar fallos realistas en la lógica de control y observar si el sistema responde de manera segura, determinista y diagnóstica. El objetivo no es simplemente ver si el peldaño (rung) compila. El objetivo es ver si la estrategia de control sobrevive al contacto con entradas erróneas, retroalimentación faltante, movimiento retardado y errores del operador.

En términos operativos, esta es la brecha entre la programación de "camino feliz" (happy-path) y la validación de grado de puesta en marcha. La lógica de "camino feliz" asume que los sensores se comportan correctamente, que los operadores introducen valores sensatos, que los actuadores se mueven cuando se les ordena y que las secuencias progresan según lo programado. Las plantas son menos educadas.

Una forma útil de plantearlo es a través del pensamiento estilo FMEDA. Los modos de fallo no son papeleo abstracto; son indicadores para preguntas comprobables:

• ¿Qué sucede si una señal de 4–20 mA cae por debajo de su rango válido?
• ¿Qué sucede si se energiza una orden de válvula pero nunca llega la verificación (proof)?
• ¿Qué sucede si una entrada de HMI excede los límites seguros?
• ¿Qué sucede si la retroalimentación de un paso de secuencia llega fuera de orden?
• ¿Qué alarma aparece primero y es esa alarma útil para el diagnóstico?

Ahí es donde el análisis de alta interacción se vuelve valioso. Obliga a la lógica a tener en cuenta permisivos, disparos (trips), perros guardianes (watchdogs), límites (clamps), alarmas de primer evento (first-out), manejo de tiempos de espera y desacuerdo de estados. La sintaxis importa. La capacidad de despliegue importa más.

Las limitaciones de las pruebas de hardware

Las pruebas físicas tienen límites estrictos. En un sistema real o pre-real, algunas condiciones anormales son demasiado arriesgadas, demasiado destructivas o demasiado disruptivas operativamente para inducirlas deliberadamente.

Los ejemplos son rutinarios:

• Forzar una señal falsa de nivel bajo en un tren de bombas puede provocar funcionamiento en seco o cavitación.
• Simular una válvula de dosificación química atascada en posición abierta puede crear un trastorno real en el proceso.
• Introducir una consigna de velocidad o presión negativa puede violar las restricciones del equipo o los procedimientos operativos.
• Romper una ruta de retroalimentación de verificación durante una secuencia activa puede crear un estado de máquina incierto.

Esto no es precaución por precaución. Es una restricción impuesta por la seguridad, la protección de activos, la exposición ambiental y la continuidad de la producción. Las normas IEC 61508 e IEC 61511 no requieren imprudencia; requieren una validación disciplinada.

¿Cómo se relaciona esto con FAT, SAT y la puesta en marcha virtual?

La puesta en marcha virtual extiende la validación a estados de fallo que son difíciles o inaceptables de inducir físicamente. No reemplaza a FAT o SAT. Cambia lo que se puede probar antes de que esas etapas se vuelvan costosas.

Una distinción práctica:

• FAT verifica que el sistema construido generalmente se ajusta a la intención del diseño en un entorno controlado.
• SAT verifica que el sistema instalado se comporta correctamente en su contexto real de sitio.
• La puesta en marcha virtual verifica la lógica, la secuenciación y el manejo de estados anormales frente al comportamiento simulado del equipo antes de la exposición en el sitio.

Aquí es donde OLLA Lab se vuelve operativamente útil. Su editor de lógica de escalera basado en navegador, modo de simulación, panel de variables y entorno de gemelo digital 3D/WebXR permiten a los ingenieros inyectar fallos, observar la respuesta del equipo y revisar la lógica antes de que un proceso real tenga que absorber la lección.

Se prueban tratando la entrada del operador como una fuente de fallo, no como una verdad absoluta. Las entradas de HMI son una de las formas más comunes de crear problemas extraordinarios.

Una consigna negativa, una orden de velocidad implausiblemente alta o un valor fuera de los límites de diseño del proceso deberían activar un comportamiento de control explícito. La expectativa mínima es el rechazo o la corrección acotada. Los mejores sistemas también proporcionan una alarma clara y preservan la trazabilidad de lo que se intentó.

En la lógica de escalera, el patrón defensivo suele construirse a partir de un pequeño conjunto de instrucciones familiares:

- LIM (Limit Test): verifica si un valor introducido está dentro de una banda operativa aceptable. - MOV (Move): sobrescribe un valor inválido con un valor de respaldo, mínimo o máximo seguro. - GRT / LES (Greater Than / Less Than): detecta condiciones fuera de rango. - Bobina de alarma / bit de estado: expone el estado de entrada inválida al HMI o a la lógica de secuencia. - Bit de interbloqueo: impide la ejecución hasta que el valor sea corregido o reconocido.

Una estrategia de control compacta podría verse así:

• Si el operador introduce una orden de velocidad inferior a 0 RPM, rechazarla.
• Si el operador introduce una orden de velocidad superior al máximo permitido del motor, limitarla (clamp).
• Activar una alarma de "Entrada Inválida".
• Impedir el permisivo de arranque hasta que la orden sea válida.

En OLLA Lab, esto puede ejercitarse directamente a través del panel de variables forzando un valor de comando erróneo en el conjunto de etiquetas (tags) simuladas y observando tanto la respuesta del estado de la escalera como el comportamiento del gemelo digital. Eso importa porque el manejo de entradas inválidas no está completo cuando el peldaño se ve ordenado. Está completo cuando el estado de la máquina también permanece seguro.

Implementación de lógica de límite (clamp) en OLLA Lab

Una secuencia de validación práctica para probar entradas fuera de rango es:

1. Crear una etiqueta de comando como `Motor_Speed_SP`.
2. Definir la banda válida, por ejemplo, de `0` a `1800`.
3. Usar `LIM` para probar si la consigna es aceptable.
4. Usar `MOV` para forzar un valor de respaldo si la consigna está fuera de los límites.
5. Activar un bit de alarma cuando la entrada sea inválida.
6. Confirmar en la simulación que el comportamiento de salida sigue el valor corregido, no el erróneo.
7. Observar el estado del equipo en 3D o WebXR para verificar que la máquina no ejecute la orden insegura.

Esa secuencia enseña más que sintaxis. Enseña programación defensiva bajo incertidumbre del operador, lo cual es una aproximación más cercana al trabajo real de puesta en marcha.

WebXR es útil aquí porque convierte el fallo de control invisible en una consecuencia observable del equipo. En este artículo, esa es la definición operativa, no una novedad.

Una señal de sensor perdida es a menudo fácil de describir y sorprendentemente difícil de razonar bajo presión. Considere una bomba en funcionamiento controlada por un lazo de nivel o presión. Si la retroalimentación analógica cae a 0 mA debido a un cable roto, un transmisor fallido, un terminal defectuoso o un fallo de escalado, el PLC tiene que decidir si ese valor es plausible, si el lazo debe continuar y si la condición debe disparar un paro, una alarma o un fallo.

En una pantalla 2D, el fallo puede parecer un número que cambia. En un gemelo digital, el mismo fallo puede mostrar:

• un nivel de tanque que sigue subiendo,
• una bomba funcionando en seco,
• una válvula que permanece abierta contra lo esperado,
• una salida PID saturándose,
• o una secuencia de proceso estancada.

Ese acoplamiento visual importa porque vincula el fallo de la etiqueta con la consecuencia del proceso. Los ingenieros no ponen en marcha etiquetas de forma aislada. Ponen en marcha sistemas.

¿Por qué no probar esto simplemente en hardware?

Porque el hardware es costoso, finito y generalmente está conectado a algo que el propietario preferiría no dañar.

Un gemelo digital WebXR o de RV se entiende mejor aquí como un entorno de inyección de fallos de riesgo cero:

• Riesgo cero para el personal ante estados anormales inducidos.
• Riesgo cero para la continuidad de la producción durante la formación o el ensayo.
• Riesgo cero para el equipo ante pruebas repetidas de estados erróneos.
• Repetición de bajo costo del mismo caso de fallo hasta que la lógica se endurezca.

Eso no significa que la simulación sea mejor que la realidad en todos los aspectos. Significa que es más adecuada para el ensayo repetido de estados anormales.

Programación de la alarma de primer evento (first-out)

La pérdida de retroalimentación no debería producir una inundación de alarmas vagas. Debería producir una indicación de primer evento útil para el diagnóstico que le diga al operador o ingeniero qué falló primero y qué hizo el sistema de control después.

Un patrón práctico de primer evento incluye:

• temporizador de fallo o eliminación de rebotes (debounce),
• estado de disparo o respaldo,
• bit de alarma de primer evento enclavado,
• y mensaje dirigido al operador vinculado al fallo original.

En el modo de simulación de OLLA Lab, los usuarios pueden alternar o forzar un fallo de entrada a mitad del ciclo y luego verificar si la lógica de escalera:

• detecta la pérdida de señal,
• inhibe la continuación insegura,
• enclava la alarma correcta,
• y transiciona el modelo de equipo a un estado seguro.

Si el gemelo digital muestra desbordamiento, cavitación o continuación incontrolada, la lógica aún no es defensiva. La máquina está siendo honesta respecto al código.

Se programa probando el desacuerdo entre el estado ordenado y el estado verificado. La fricción mecánica, el atasco o la falta de movimiento es un problema clásico de puesta en marcha porque el PLC puede creer que la orden tuvo éxito mientras la máquina permanece físicamente atascada.

Aquí es donde la lógica de verificación (proof logic) demuestra su valor. Si una salida está energizada y la retroalimentación esperada no llega dentro de una ventana de tiempo definida, el sistema debería emitir una alarma, inhibir la progresión de la secuencia y pasar a un estado seguro o conocido.

Un patrón estándar es el temporizador de verificación de movimiento.

El temporizador de verificación de movimiento

El siguiente ejemplo de escalera expresa una regla simple pero importante:

• ordenar la válvula,
• permitir una ventana de movimiento razonable,
• y si la verificación nunca llega, declarar un fallo.

Una implementación representativa es:

• Energizar `Valve_Command`
• Iniciar `TON Valve_Feedback_Timer` con un preajuste de `5000 ms`
• Si `Valve_Feedback_Timer.DN` es verdadero y `Valve_Open_Limit_Switch` sigue siendo falso, enclavar `Valve_Stuck_Alarm`

En OLLA Lab, el ingeniero puede simular la orden, retener o deshabilitar la retroalimentación esperada y observar tanto la transición del estado de la escalera como la respuesta del equipo 3D. Eso es materialmente diferente a leer el peldaño y asumir que es suficiente.

¿Qué debería hacer la lógica defensiva después del fallo de verificación?

La alarma del temporizador por sí sola no es suficiente. Una respuesta de grado de puesta en marcha generalmente incluye alguna combinación de:

• detener el avance de la secuencia,
• desenergizar salidas dependientes,
• enclavar un estado de fallo,
• presentar un mensaje de alarma claro,
• y requerir la intervención del operador o mantenimiento antes del reinicio.

La respuesta exacta depende del riesgo del proceso, el diseño mecánico y la filosofía de control. Un amortiguador (damper) pegado en HVAC no es una válvula de cierre fallida en un skid químico. Patrón similar, consecuencias diferentes.

"Listo para la simulación" no debe usarse como un cumplido vago. Operativamente, significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso real.

Esa definición tiene componentes observables. Un ingeniero listo para la simulación puede:

• mapear etiquetas de escalera al comportamiento del equipo simulado,
• inyectar condiciones anormales deliberadamente,
• explicar qué significa "correcto" antes de probar,
• identificar el desacuerdo entre la orden y la verificación,
• revisar la lógica después de un fallo,
• y verificar que la lógica revisada cambie los resultados tanto del estado de la etiqueta como del estado del equipo.

Esta es la distinción entre conocer la sintaxis de escalera y ser capaz de validar un comportamiento de control desplegable. Lo primero es necesario. Lo segundo es lo que importa en el trabajo de puesta en marcha.

En OLLA Lab, esa preparación operativa se apoya a través de:

• un editor de lógica de escalera basado en web con tipos de instrucciones estándar,
• modo de simulación para ejecutar y detener la lógica de forma segura,
• un panel de variables para visibilidad de E/S, valores analógicos y condiciones forzadas,
• modelos de equipo 3D/WebXR/RV para la observación de estados,
• ejercicios basados en escenarios con peligros, interbloqueos y notas de puesta en marcha,
• y soporte guiado de GeniAI, el guía de laboratorio de IA, para la incorporación y asistencia correctiva.

La afirmación del producto debe permanecer acotada: OLLA Lab es un entorno de ensayo y validación para tareas de puesta en marcha de alto riesgo. No es un sustituto de los procedimientos del sitio, la evaluación formal de competencias, la verificación SIL o la autorización específica de la planta.

Deben documentar un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla. Una captura de pantalla puede mostrar que un simulador existía. No puede mostrar que el ingeniero entendió lo que se estaba validando.

Utilice esta estructura:

Especifique qué significa el comportamiento correcto en términos observables: permisivos satisfechos, transiciones de salida, condiciones de alarma, umbrales de disparo, tiempos de secuencia y comportamiento en estado seguro.

Indique exactamente qué se forzó: pérdida de retroalimentación analógica, consigna negativa, interruptor de verificación fallido, movimiento retardado o desajuste de secuencia.

Documente el cambio de lógica: temporizador de vigilancia (watchdog), límite (clamp), enclavamiento de primer evento, permisivo, comparador, tiempo de espera o condición de reinicio.

1. Descripción del sistema Defina la unidad de proceso, máquina o skid que se está controlando. Indique las E/S clave, el propósito de la secuencia y el contexto operativo.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Presente la sección de escalera relevante y el comportamiento del equipo correspondiente en la simulación. Muestre la relación entre el estado de la etiqueta y el estado físico.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Explique qué pasó por alto la lógica original, qué captura ahora la lógica revisada y qué supuestos residuales permanecen.

Este formato es más sólido porque demuestra el razonamiento de ingeniería bajo condiciones de fallo. Los empleadores y revisores necesitan evidencia de que el candidato puede pensar con claridad cuando el proceso deja de comportarse correctamente.

La base normativa es sencilla: la seguridad funcional y la validación del ciclo de vida requieren atención a las condiciones anormales, la respuesta ante fallos y el comportamiento diagnóstico, no solo a la operación prevista.

Los anclajes relevantes incluyen:

• IEC 61508 para conceptos de ciclo de vida de seguridad funcional en sistemas eléctricos, electrónicos y programables.
• IEC 61511 para sistemas instrumentados de seguridad en las industrias de procesos.
• Práctica FMEDA utilizada en el análisis de fiabilidad y diagnóstico para razonar sobre modos de fallo y cobertura de detección.
• Literatura sobre gemelos digitales, puesta en marcha virtual y formación basada en simulación para mejorar la eficiencia de la validación y la preparación de operadores o ingenieros.

La inferencia limitada es que la simulación y los gemelos digitales son especialmente útiles donde la inducción física de fallos es insegura, poco práctica o demasiado costosa de repetir. Ese es un caso de uso de ingeniería sólido. No requiere afirmaciones exageradas sobre la inmersión.

OLLA Lab encaja en el punto donde los ingenieros necesitan construir, probar, observar y revisar la lógica de escalera frente al comportamiento realista del equipo antes de que la puesta en marcha real absorba el costo de un error prevenible.

En términos prácticos, la plataforma admite:

• construir lógica de escalera en un editor basado en navegador,
• simular la ejecución de la lógica sin hardware físico,
• monitorear E/S, variables, valores analógicos y comportamiento relacionado con PID,
• validar la lógica frente a gemelos digitales 3D o WebXR,
• y trabajar a través de escenarios industriales realistas en agua, HVAC, fabricación, servicios públicos y sistemas de procesos.

Eso lo hace adecuado para ensayar tareas que son costosas de aprender por primera vez en el piso de una planta real:

• manejo de pérdida de retroalimentación,
• rechazo de órdenes fuera de rango,
• fallos de verificación de movimiento,
• validación de interbloqueos,
• secuenciación de alarmas,
• y revisión defensiva después de un fallo.

Esa es la propuesta de valor creíble. No es magia. No es experiencia instantánea. La repetición bajo condiciones de fallo controladas suele ser menos glamorosa que el texto de marketing, pero está más cerca de cómo se construye la competencia.

El análisis de fallos de alta interacción es la prueba disciplinada de cómo se comporta la lógica del PLC cuando el proceso deja de cooperar. Eso incluye entradas erróneas, retroalimentación faltante, actuadores que no se mueven y fallos de secuencia que no aparecen en los casos de demostración ordenados.

Los gemelos digitales WebXR y de RV son útiles en este contexto porque proporcionan un entorno de inyección de fallos de riesgo cero donde los ingenieros pueden observar la consecuencia física de una lógica errónea, revisarla y probar de nuevo. La distinción clave es simple: dibujar lógica frente a validar comportamiento.

Un ingeniero listo para la simulación no es la persona que puede explicar qué hace un temporizador. Es la persona que puede mostrar qué sucede cuando el temporizador es lo único que se interpone entre una orden y un fallo.

- WebXR Device API (Borrador de recomendación de candidato W3C) - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Descripción general de seguridad funcional IEC 61508 - Página de inicio de la revista IFAC-PapersOnLine - Página de inicio de la revista MDPI Sensors