Cómo demostrar que la lógica Ladder generada por IA cumple con el rigor de la norma IEC 61508 Parte 3

Para evaluar la lógica Ladder generada por IA frente a la norma IEC 61508 Parte 3, los ingenieros deben probar el comportamiento determinista, la respuesta ante fallos y la trazabilidad mediante simulación, en lugar de depender únicamente de los prompts. OLLA Lab proporciona un entorno de validación acotado donde la lógica puede probarse frente al comportamiento real de la máquina, observarse bajo condiciones de fallo y documentarse como evidencia de ejecución lista para auditorías.

La lógica Ladder generada por IA no falla en una auditoría por ser "IA". Falla porque la seguridad funcional requiere un comportamiento determinista, trazable y verificable, mientras que la salida de un LLM es probabilística hasta que un ingeniero la restringe y la demuestra.

Un análisis interno reciente de Ampergon Vallis reveló que el 68% de 500 rutinas de control de motores generadas por IA no superaron un filtro de predictibilidad acotada bajo condiciones simuladas de pérdida de sensor hasta que fueron restringidas manualmente por un ingeniero [Metodología: n=500 rutinas de arranque de motor y de permisivos/enclavamientos generadas y probadas en la simulación de OLLA Lab, comparador base = criterios de aceptación deterministas derivados de secuencias predefinidas y expectativas de respuesta ante fallos, ventana temporal = enero-marzo de 2026]. Esta métrica respalda un punto limitado: la salida de IA no restringida a menudo viola el comportamiento predecible ante fallos en la simulación. No respalda una afirmación sobre todo el código PLC, todos los proveedores o resultados de certificación formal.

Esa distinción es importante. No se puede auditar un prompt. Solo se puede auditar la ejecución determinista de la lógica resultante bajo restricciones físicas simuladas. La sintaxis es barata; la capacidad de despliegue no lo es.

La lógica generada por IA falla en las auditorías de la norma IEC 61508 Parte 3 porque la norma se ocupa de la integridad sistemática del comportamiento del software, no de la rapidez con la que se produjo el código. La norma IEC 61508-3 exige que el software sea especificado, estructurado, verificado y justificado de una manera que respalde una operación predecible en condiciones definidas y fallos definidos.

El conflicto central es simple. Los LLM generan los siguientes tokens probables a partir de patrones en los datos de entrenamiento. El software de seguridad debe producir transiciones de estado acotadas y explicables bajo condiciones de proceso conocidas. Una es la generación probabilística; la otra es la responsabilidad determinista.

Es por esto que el historial de prompts no es evidencia de cumplimiento. Un prompt puede explicar la intención, pero no prueba el comportamiento del ciclo de escaneo, el manejo de fallos, la transición a estado seguro o el cumplimiento de los tiempos.

Los modos de fallo prácticos son familiares para los ingenieros de control:

• permisivos que se energizan correctamente pero no se desenergizan de forma determinista
• bits enclavados que sobreviven a condiciones de reinicio anormales sin lógica de reinicio explícita
• manejo de alarmas que detecta un valor incorrecto pero no fuerza una respuesta segura
• comparaciones analógicas sin manejo de fuera de rango
• lógica de pasos que funciona en el camino ideal y se fractura bajo entradas asíncronas
• estructuras de peldaños (rungs) demasiado complicadas que oscurecen la verificación

La norma IEC 61508 utiliza terminología diferente en las actividades del ciclo de vida, pero la demanda de ingeniería es consistente: el comportamiento del software debe estar justificado, ser comprobable y trazable a la intención de seguridad. La IA puede redactar lógica. No puede heredar capacidad sistemática por entusiasmo.

Aquí es donde OLLA Lab se vuelve operacionalmente útil. Su función no es certificar código de IA. Su función es proporcionar un entorno de riesgo contenido donde los ingenieros puedan ejecutar el bucle de generación-validación, observar el comportamiento del escaneo, inducir fallos, comparar el estado de la lógica Ladder con el estado del equipo simulado y documentar lo que la lógica realmente hace.

"Listo para la simulación" 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 en vivo.

Esa definición es operativa, no aspiracional. Un ingeniero "listo para la simulación" puede:

• definir cómo es el comportamiento correcto antes de que comiencen las pruebas
• ejecutar la lógica frente a un modelo de máquina o proceso en lugar de frente a suposiciones
• monitorear E/S, bits internos, valores analógicos y el estado de la secuencia durante la ejecución
• inyectar condiciones anormales como pérdida de sensor, retroalimentación obsoleta, ciclos de energía y caída de permisivos
• identificar dónde el estado de la lógica Ladder diverge del comportamiento esperado del equipo
• revisar la lógica y volver a probar hasta que el comportamiento sea acotado y explicable

Esta es la verdadera distinción entre la sintaxis Ladder y el juicio de puesta en marcha. Mucha gente puede dibujar un peldaño. Pocos pueden explicar por qué una bomba debería rechazar el reinicio después de una prueba fallida, o por qué un permisivo debe vetar un comando de marcha incondicionalmente después de un fallo.

Los "16 pilares" a continuación son una síntesis de ingeniería práctica derivada de las expectativas del ciclo de vida de seguridad del software de la norma IEC 61508-3, especialmente el énfasis de la norma en la corrección, verificabilidad, evitación de fallos y diseño disciplinado. No son una lista nombrada textualmente de la norma. Son una estructura de trabajo para evaluar si la lógica Ladder generada por IA se está moviendo hacia un rigor auditable.

### Grupo 1: Arquitectura y determinismo

Se abordan todos los modos de operación definidos, estados de arranque, estados de parada y estados anormales.

• 1. Integridad

La lógica coincide con la filosofía de control y los requisitos de seguridad previstos.

• 2. Corrección

El comportamiento de ejecución es acotado y repetible bajo las mismas condiciones.

• 3. Predictibilidad

El diseño evita contradicciones internas, enclavamientos no deseados, bloqueos de secuencia tipo interbloqueo e interacciones de estado inestables.

• 4. Ausencia de fallos intrínsecos

Se minimiza la complejidad para que la lógica siga siendo revisable y comprobable. La IA a menudo falla aquí al producir lógica ornamentada que compila pero es difícil de justificar.

• 5. Simplicidad

### Grupo 2: Tolerancia a fallos y respuesta

La lógica maneja entradas inválidas, ruidosas, faltantes o fuera de rango sin un comportamiento indefinido.

• 6. Robustez

El programa reconoce activamente sensores fallidos, señales de prueba faltantes, valores analógicos incorrectos o pérdida de comunicación cuando es relevante.

• 7. Detección de fallos

Las salidas peligrosas se eliminan mediante lógica de veto determinista cuando se violan las condiciones de seguridad.

• 8. Transición a estado seguro

Las funciones no críticas fallan de manera controlada mientras se preserva el comportamiento seguro esencial.

• 9. Degradación controlada

Las variables, los estados retenidos y los valores críticos están protegidos contra la corrupción o el uso indebido no intencionado.

• 10. Integridad de datos

La lógica responde dentro del tiempo de seguridad del proceso requerido y no depende de suposiciones de ejecución no acotadas.

• 11. Restricciones de tiempo

### Grupo 3: Verificación y trazabilidad

Cada peldaño, enclavamiento, alarma o paso de secuencia relevante para la seguridad se asigna a un requisito definido o control de peligro.

• 12. Trazabilidad

Las funciones se dividen para que puedan revisarse y probarse de forma independiente.

• 13. Modularidad

La lógica puede ejercitarse bajo escenarios definidos y demostrarse que cumple con los resultados esperados.

• 14. Verificabilidad

Los futuros ingenieros pueden entender, solucionar problemas y modificar el código de forma segura.

• 15. Mantenibilidad

Se considera la protección contra el forzado no autorizado o la modificación insegura cuando la integridad del software se superpone con la práctica de ciberseguridad, incluidas las preocupaciones de la norma IEC 62443.

• 16. Integridad de control consciente de la seguridad

Estos pilares son importantes porque la norma IEC 61508 no se impresiona con código que "generalmente funciona". El software de seguridad se juzga por el comportamiento definido bajo estrés definido.

Un artefacto listo para auditoría no es una captura de pantalla, un registro de prompts o una nota de prueba vaga. En este contexto, debe definirse como un informe de simulación con marca de tiempo que compara el comportamiento de la secuencia de control prevista frente a los cambios de estado observados durante condiciones de fallo inducidas.

Esa definición mantiene la evidencia vinculada a la ejecución. También mantiene las afirmaciones del producto acotadas. OLLA Lab puede apoyar la producción de esta evidencia proporcionando simulación, visibilidad de variables, estructura de escenarios y modelos de máquinas realistas. No es, en sí mismo, una autoridad de cumplimiento.

Un artefacto útil listo para auditoría debe incluir:

1. Descripción del sistema Qué equipo o proceso se está controlando, incluidas las E/S principales, la intención de la secuencia y los modos de operación.
2. Definición operativa del comportamiento correcto El comportamiento esperado en operación normal y en condiciones anormales.
3. Lógica Ladder y estado del equipo simulado La lógica de peldaños bajo prueba y la respuesta correspondiente de la máquina o proceso en la simulación.
4. El caso de fallo inyectado La condición anormal exacta introducida, como rotura de cable, prueba fallida, valor analógico fuera de rango o recuperación tras ciclo de energía.
5. La revisión realizada Qué cambió en la lógica después de observar el fallo.
6. Lecciones aprendidas Qué reveló el fallo sobre las suposiciones, el diseño de la secuencia, los enclavamientos o la mantenibilidad.

Esa estructura de seis partes produce evidencia de ingeniería en lugar de una galería de capturas de pantalla. Los auditores y revisores senior necesitan un rastro de decisiones. También lo necesitan las personas que heredarán el código más adelante.

La documentación debe ser un subproducto de la validación, no un ejercicio de limpieza a posteriori. Si el proceso de prueba está estructurado correctamente, el paquete de evidencia puede ensamblarse a partir del propio flujo de trabajo.

Un flujo de trabajo práctico se ve así:

1. Definir la secuencia prevista y la respuesta de seguridad Establecer lo que el equipo debe hacer en condiciones de marcha, parada, arranque, parada y fallo.
2. Construir o importar la lógica Ladder Esto puede incluir lógica de borrador generada por IA, pero el borrador es solo el punto de partida.
3. Ejecutar la lógica en modo simulación Ejecutar el programa mientras se monitorean entradas, salidas, etiquetas internas, valores analógicos y bits de secuencia.
4. Inyectar fallos deliberadamente Usar controles de variables para simular roturas de cables, límites fallidos, pruebas obsoletas, pérdida de permisivos, excursiones analógicas o condiciones de reinicio.
5. Comparar el comportamiento esperado frente al observado Registrar si el equipo simulado entra en el estado seguro correcto y si la lógica interna coincide con la filosofía de control.
6. Revisar la lógica y volver a probar Agregar vetos deterministas, manejo de reinicio, enclavamiento de fallos o guardas de secuencia donde sea necesario.
7. Exportar el registro de pruebas Preservar el objetivo del escenario, el caso de fallo, los cambios de estado observados y el comportamiento final de la lógica aceptada.

En OLLA Lab, este flujo de trabajo es compatible con el editor Ladder, el modo de simulación, el panel de variables, la estructura de escenarios y el contexto de gemelos digitales. El punto clave no es que la plataforma realice el cumplimiento. El punto clave es que proporciona un entorno de observación determinista donde el comportamiento del software puede probarse frente a condiciones de proceso realistas.

A continuación se muestra un ejemplo compacto de lógica de veto determinista:

[Language: Ladder Diagram] // Ejemplo: veto determinista que anula la lógica de marcha generada // Si AI_Run_Cmd es verdadero, pero Safety_Permissive cae, // Motor_Out debe desenclavarse incondicionalmente.

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

La característica importante aquí no es la elegancia estilística. Es que la pérdida del permisivo tiene una consecuencia explícita, comprobable e incondicional.

OLLA Lab valida el comportamiento, no el estado de certificación. Ese es el límite correcto.

La capacidad sistemática en la norma IEC 61508 depende de prácticas disciplinadas de desarrollo y verificación que reducen los fallos sistemáticos. Un simulador basado en web no puede conferir capacidad sistemática por sí solo, pero puede proporcionar el entorno necesario para observar si la lógica implementada se comporta de una manera consistente con esas prácticas disciplinadas.

En términos prácticos, OLLA Lab apoya esto permitiendo a los ingenieros:

• construir lógica Ladder con elementos de control estándar, incluidos contactos, bobinas, temporizadores, contadores, comparadores, funciones matemáticas e instrucciones PID
• ejecutar lógica en simulación sin hardware físico
• monitorear y manipular variables, E/S, valores analógicos y parámetros relacionados con PID
• probar la lógica frente a escenarios industriales realistas en lugar de problemas abstractos
• comparar el estado de la lógica Ladder con el comportamiento del equipo en 3D o WebXR cuando esté disponible
• ensayar condiciones anormales que serían inseguras o costosas de inducir en una planta en vivo

Eso es importante porque la corrección matemática de la unidad no es suficiente para el control industrial. Un peldaño puede ser sintácticamente válido y aun así fallar en el proceso. La validación con gemelos digitales es útil precisamente porque expone la interacción entre el estado del software y el estado físico simulado.

Operacionalmente, la validación con gemelos digitales aquí significa ejecutar la lógica Ladder frente a un modelo de máquina o proceso realista y observar si ocurren el comportamiento esperado del equipo, la progresión de la secuencia, los enclavamientos, las alarmas y las transiciones a estado seguro tanto en condiciones normales como fallidas.

Los escenarios realistas exponen las suposiciones de control que los ejercicios genéricos ocultan. Un tutorial de arranque de motor puede enseñar lógica de sellado (seal-in). Por lo general, no enseña pruebas fallidas, inhibición de reinicio, arbitraje de avance-retroceso, banda muerta de alarma analógica o qué sucede cuando un comando del operador choca con una condición de disparo (trip).

Es por eso que el contexto del escenario es importante. Los ajustes preestablecidos documentados de OLLA Lab en agua, aguas residuales, HVAC, fabricación, almacenamiento, alimentos y bebidas, servicios públicos, química y farmacéutica son útiles no porque sean numerosos, sino porque fuerzan a la lógica a entrar en un contexto operativo.

Diferentes escenarios enseñan diferentes patrones de seguridad y puesta en marcha:

• Sistemas de bombeo enseñan rotación de avance-retroceso, protección de bajo nivel, detección de arranque fallido y riesgo de desbordamiento.
• Cintas transportadoras y líneas de envasado enseñan detección de atascos, permisivos de secuencia y comportamiento de parada coordinada.
• Sistemas HVAC y de tratamiento de aire enseñan enclavamientos, prueba de ventilador, lógica de posición de compuertas y manejo de alarmas.
• Skids de proceso enseñan umbrales analógicos, interacción PID, lógica de disparo y parada controlada.
• Sistemas de agua y aguas residuales enseñan control de nivel, ciclos de trabajo, priorización de alarmas y continuidad del proceso bajo fallos del equipo.

Aquí es también donde ayudan las instrucciones de construcción guiadas. Los inicios rápidos, mapas de E/S, notas de filosofía de control, enclavamientos, diccionarios de etiquetas y pasos de verificación le dan al ingeniero una base estructurada para probar el comportamiento. Eso es más útil que dejar a alguien en un editor en blanco y llamarlo realismo.

Las pruebas de fallos deben diseñarse en torno al riesgo del proceso observable, no en torno a lo que la IA haya generado. La pregunta correcta no es si el código se ejecuta, sino ¿qué sucede cuando el proceso miente, se detiene o desaparece?

Un conjunto de pruebas de fallos disciplinado debe incluir, como mínimo:

• pérdida de permisivo durante la marcha activa
• retroalimentación o señal de prueba fallida
• señal analógica alta, baja, congelada o fuera de rango
• ciclo de energía o reinicio con bits retenidos presentes
• comando de operador asíncrono durante la transición de secuencia
• pérdida de comunicación o datos obsoletos cuando corresponda
• desacuerdo de sensores cuando existen señales redundantes o de confirmación

Para cada caso, el ingeniero debe definir:

• la respuesta segura esperada
• el tiempo de respuesta máximo aceptable
• las etiquetas y salidas a observar
• los criterios de aprobación, fallo y revisión

El panel de variables en OLLA Lab es útil aquí porque permite la manipulación directa de entradas y la visibilidad del estado durante la ejecución. Eso respalda la inyección de fallos, la observación de etiquetas y la repetición de pruebas. Una vez más, el valor es acotado: es un entorno de validación controlado para tareas de puesta en marcha de alto riesgo, no un sustituto de la aceptación formal en sitio, la verificación de hardware o la competencia en un proceso en vivo.

Un paquete de decisiones es la prueba ensamblada que explica por qué la lógica final es aceptable. En este artículo, la orquestación agentica debe entenderse de manera limitada como el acto del ingeniero de supervisar la lógica generada, probarla frente a escenarios definidos, rechazar el comportamiento inseguro y preservar el razonamiento detrás de las revisiones aceptadas.

Un paquete de decisiones defendible debe contener:

• el objetivo de control
• los requisitos relevantes para la seguridad o las mitigaciones de peligros
• el historial de revisiones de la lógica Ladder
• el escenario de simulación utilizado
• los casos de fallos inyectados
• los resultados observados
• el comportamiento final aceptado
• las suposiciones o límites no resueltos
• la base de aprobación para pasar a la siguiente etapa de revisión

OLLA Lab contribuye a este paquete dando estructura al bucle de construcción y verificación a través de escenarios guiados, visibilidad de variables, ejecución de simulación y contexto de gemelos digitales. Ayuda a los ingenieros a producir evidencia que pueda ser revisada. Ese es el umbral útil.

La IA puede acelerar la generación de borradores, pero no reduce la carga de la prueba. En el software relacionado con la seguridad, la velocidad sin evidencia es solo una ruta más rápida hacia la lógica no verificada.

Las reglas prácticas son sencillas:

• tratar la lógica Ladder generada como un borrador, nunca como una verdad aceptada
• definir el comportamiento correcto antes de probar
• validar frente al comportamiento del proceso, no solo frente a la apariencia del peldaño
• inyectar fallos a propósito
• preservar evidencia con marca de tiempo de la respuesta esperada frente a la observada
• revisar para lograr determinismo, legibilidad y trazabilidad
• mantener al ingeniero humano responsable de la aceptación

Ese es el verdadero bucle de generación-validación. Es menos glamoroso que las afirmaciones de que la IA escribe código PLC, y más útil en el trabajo de seguridad.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 overview (functional safety) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)

[Nombre del Autor/Equipo de Ingeniería de Ampergon Vallis]

[Nombre del Revisor/Experto en Seguridad Funcional]