Cómo preparar la lógica de PLC para auditorías de capacidad sistemática según IEC 61508 Edición 3

Para preparar la lógica de PLC para las auditorías de capacidad sistemática de la norma IEC 61508 Edición 3, los ingenieros necesitan evidencia de comportamiento que demuestre que el software responde de manera determinista y segura bajo condiciones de fallo definidas. Un entorno de simulación como OLLA Lab puede utilizarse como un entorno de verificación acotado para probar propiedades de seguridad, documentar el manejo de fallos y robustecer la lógica antes de la auditoría formal y la validación física.

La seguridad del software bajo IEC 61508 no es principalmente una cuestión de si el código parece ordenado. Es una cuestión de si se puede demostrar que la lógica se comporta de manera correcta, repetible y segura cuando el proceso deja de ser "amable".

Esa distinción importa más en la Edición 3, donde se espera que la carga de la prueba en torno al comportamiento sistemático del software se endurezca en lugar de relajarse. El análisis de fallos de hardware todavía gira en torno a medidas de fallo probabilísticas como PFD y PFH. El software no falla porque haya envejecido mal en un armario; falla sistemáticamente debido a errores de diseño, lagunas en las especificaciones, interacciones no deseadas y casos límite no probados.

Un estudio comparativo interno reciente de Ampergon Vallis respalda este punto. Durante un análisis interno de 500 casos de prueba de funciones instrumentadas de seguridad (SIF) simuladas en OLLA Lab, el 68% de los borradores iniciales de lógica fallaron en una verificación de robustez cuando se sometieron a deriva analógica, comportamiento de entrada de estado obsoleto o forzado fuera de rango [Metodología: n=500 tareas de validación de SIF simuladas en escenarios de bombas, cintas transportadoras, HVAC y patines de proceso; comparador base = borrador de primera pasada antes de la revisión; ventana temporal = enero-febrero de 2026]. Esto respalda la afirmación de que la lógica de primera pasada a menudo omite el manejo de estados anormales. No respalda ninguna afirmación sobre tasas de defectos en toda la industria o resultados de cumplimiento formal.

El cambio práctico es un mayor énfasis en demostrar la Capacidad Sistemática a través de evidencia reproducible, no simplemente afirmando la adhesión a un ciclo de vida.

IEC 61508 siempre ha tratado el software de manera diferente al hardware porque los fallos de software son sistemáticos en lugar de aleatorios. En la práctica, esto significa que las discusiones de la Edición 3 se centran en si el proceso de desarrollo y verificación puede demostrar que los requisitos de seguridad del software se tradujeron en un comportamiento controlado y comprobable. "Revisamos el código cuidadosamente" no es una declaración inútil, pero ya no es suficiente.

Un segundo cambio es la creciente expectativa de que la garantía del software se integre con preocupaciones adyacentes como la ciberseguridad, el control de configuración y la disciplina de la cadena de herramientas. Eso no colapsa la norma IEC 61508 en la IEC 62443, pero la separación ya no es tan cómoda como algunos equipos preferirían.

### Expectativas de software: Edición 2 vs. Edición 3

| Tema | Énfasis en la Edición 2 | Dirección de la Edición 3 | |---|---|---| | Garantía de software | Adhesión al ciclo de vida, disciplina de revisión, pruebas estructurales | Evidencia de comportamiento más sólida, verificación reproducible, pruebas verificables por máquina donde sea factible | | Manejo de fallos | A menudo documentado en forma narrativa | Presión creciente para pruebas explícitas de estados anormales y resultados trazables | | Soporte de herramientas | Útil pero no central | Más importante donde las herramientas mejoran la repetibilidad, trazabilidad y cobertura de pruebas | | Relación con la ciberseguridad | A menudo manejado por separado | Interacción más explícita con el desarrollo seguro y preocupaciones de integridad del sistema | | Evidencia de Capacidad Sistemática | Demostración centrada en procesos | Proceso más prueba observable de que la lógica se comporta de forma segura bajo casos límite definidos |

La corrección importante es esta: la Edición 3 no significa que el software ahora obtenga una fórmula mágica como el hardware. Significa que se espera que las afirmaciones sobre el software estén respaldadas por una evidencia más sólida.

La Capacidad Sistemática es la capacidad demostrada del proceso de desarrollo y la lógica resultante para evitar, detectar y controlar fallos sistemáticos al nivel requerido por la función de seguridad objetivo.

Para los ingenieros de PLC, esa definición se vuelve concreta cuando se traduce en comportamientos observables:

• La lógica de seguridad se ejecuta de manera predecible y acotada.
• Las transiciones de estado son explícitas y recuperables.
• Los fallos llevan al sistema a un estado seguro definido.
• La lógica no relacionada con la seguridad no corrompe ni retrasa el comportamiento de seguridad.
• La evidencia de las pruebas es reproducible y trazable a los requisitos.

Aquí es donde el contraste entre sintaxis y capacidad de despliegue resulta útil. Un peldaño (rung) puede ser sintácticamente válido y aun así ser inseguro para su puesta en marcha.

La Capacidad Sistemática tampoco es una insignia de producto. No se confiere mediante el uso de un simulador, un generador de código o un asistente de IA. Se establece a través de una especificación, implementación, verificación, documentación y validación final disciplinadas en el flujo de trabajo de garantía real.

La agrupación exacta puede variar según las metodologías, pero un conjunto práctico de propiedades de seguridad de software utilizadas en el trabajo avanzado de seguridad funcional incluye los siguientes comportamientos que los ingenieros deben ser capaces de probar y explicar.

Las 16 propiedades de seguridad en términos operativos

• Integridad (Completeness) — Se define cada modo de operación, transición, ruta de disparo y ruta de recuperación requeridos.
• Corrección (Correctness) — La lógica implementada coincide con el requisito de seguridad y la filosofía de control establecidos.
• Consistencia (Consistency) — Las etiquetas (tags), estados, transiciones e interbloqueos se comportan de manera uniforme en todo el programa.
• Determinismo (Determinism) — Las mismas entradas bajo las mismas condiciones producen las mismas salidas dentro de los límites de ejecución requeridos.
• Robustez (Robustness) — La lógica maneja entradas erróneas, ruidosas, obsoletas, faltantes o fuera de rango sin un comportamiento inseguro.
• Ausencia de interferencia (Freedom from interference) — Las tareas no relacionadas con la seguridad, las acciones de HMI, los diagnósticos o la lógica auxiliar no alteran el comportamiento de seguridad de manera inadecuada.
• Trazabilidad (Traceability) — Los requisitos, peldaños, etiquetas, pruebas y resultados pueden vincularse sin conjeturas.
• Verificabilidad (Verifiability) — La estructura del código permite pruebas independientes y un juicio claro de aprobado/fallido.
• Mantenibilidad (Maintainability) — Se pueden realizar ediciones futuras sin crear regresiones de seguridad ocultas.
• Simplicidad (Simplicity) — El diseño evita una complejidad innecesaria que oscurezca la intención o aumente el riesgo de fallo.
• Defensividad (Defensiveness) — La lógica anticipa estados inválidos y los maneja explícitamente.
• Recuperabilidad (Recoverability) — Después de un fallo, el sistema regresa solo a través de condiciones de reinicio controladas y definidas.
• Acotamiento (Boundedness) — Los temporizadores, contadores, escalado analógico y transiciones de estado permanecen dentro de límites conocidos.
• Observabilidad (Observability) — Los estados internos y los puntos de decisión pueden inspeccionarse durante la verificación.
• Comportamiento a prueba de fallos (Fail-safe behavior) — La pérdida de señal, el desacuerdo o un estado de proceso inválido conducen a una respuesta segura donde sea necesario.
• Capacidad de prueba (Testability) — Los ingenieros pueden inyectar condiciones y confirmar los resultados esperados sin ambigüedad.

Las cinco propiedades que los equipos de PLC suelen subestimar

- Determinismo: El comportamiento del escaneo debe permanecer predecible bajo todas las combinaciones de entrada relevantes. - Robustez: La deriva analógica, los contactos que vibran (chattering) y los valores de comunicación obsoletos no deben producir una retención de estado insegura. - Integridad: Cada transición de máquina de estados necesita una condición de entrada y una condición de salida segura. - Ausencia de interferencia: La lógica de visualización, la mensajería y las funciones de conveniencia no deben perturbar la ejecución de seguridad. - Verificabilidad: Si la arquitectura no se puede probar limpiamente, el problema de auditoría comienza antes que el problema en el sitio.

Estos son comportamientos de ingeniería. Si un equipo no puede demostrarlos bajo condiciones de prueba controladas, la discusión de la auditoría se vuelve más interpretativa de lo que debería ser.

"Listo para simulación" (Simulation-Ready) debe definirse de manera operativa, no decorativa.

Un ingeniero listo para la simulación es capaz de probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento real del proceso antes de que esa lógica llegue a un proceso en vivo. Eso incluye más que escribir sintaxis de escalera (ladder). Incluye:

• mapear E/S al comportamiento previsto del equipo,
• definir qué significa "correcto" antes de realizar las pruebas,
• forzar condiciones normales y anormales,
• rastrear causa y efecto a través de etiquetas y estados,
• identificar modos de fallo,
• revisar la lógica después de un fallo,
• y comparar el estado del equipo simulado con el estado de la escalera.

Esta es la diferencia entre dibujar peldaños y ensayar el juicio de puesta en marcha.

La simulación virtual valida el determinismo haciendo que el comportamiento de ejecución sea observable bajo condiciones repetibles.

En un entorno de simulación acotado, los ingenieros pueden ejecutar la lógica, mantener las condiciones constantes, alternar entradas en secuencias controladas y observar si las salidas y los estados internos cambian exactamente como se pretende. El punto clave es la repetibilidad.

Con OLLA Lab, ese flujo de trabajo de verificación puede incluir:

• ejecutar lógica de escalera en modo de simulación sin hardware físico,
• alternar entradas discretas y forzar valores analógicos,
• monitorear el estado de las etiquetas a través del panel de variables,
• comparar el comportamiento del peldaño con los objetivos del escenario y la respuesta del equipo,
• y repetir la misma prueba después de cada revisión.

Para las comprobaciones de determinismo, los ingenieros deben probar al menos estos casos:

• secuencias de entrada idénticas repetidas varias veces,
• cambios de entrada asíncronos cerca de los límites de transición,
• transiciones dependientes de temporizadores,
• comportamiento de reinicio y reinicio,
• pérdida y restauración de permisivos,
• cruces de umbral analógico con ruido o deriva.

Una idea errónea común es que la simulación solo prueba la funcionalidad básica. Utilizada correctamente, también puede mostrar si la lógica tiene límites de comportamiento estables.

OLLA Lab debe posicionarse como un entorno de verificación con riesgos contenidos, no como un motor de certificación.

Su valor operativo es directo: los ingenieros pueden construir lógica de escalera en un editor basado en web, ejecutarla en simulación, inspeccionar variables y el comportamiento de E/S, y validar la lógica contra modelos de máquinas basados en escenarios y gemelos digitales antes de la puesta en marcha física. Eso lo hace útil para el endurecimiento previo a la auditoría, el ensayo de fallos y la captura de evidencia.

Dentro de ese rol acotado, OLLA Lab admite varias tareas de verificación relevantes:

- Editor de lógica de escalera: construir y revisar la lógica de control utilizando tipos de instrucciones estándar, incluidos temporizadores, contadores, comparadores, matemáticas, lógica y PID. - Modo de simulación: ejecutar la lógica de forma segura, detener y volver a ejecutar pruebas, y forzar condiciones de entrada sin exposición al hardware. - Panel de variables y visibilidad de E/S: inspeccionar etiquetas, salidas, valores analógicos y comportamiento de bucle mientras se rastrea la causa y el efecto. - Escenarios 3D/WebXR/VR: comparar el comportamiento de la escalera con la respuesta de la máquina o del proceso en contextos operativos realistas. - Validación de gemelos digitales: probar si la secuencia prevista realmente se comporta correctamente frente a un modelo de equipo virtual. - Práctica de puesta en marcha basada en escenarios: ensayar interbloqueos, alarmas, retroalimentaciones de prueba, disparos, permisivos y lógica de reinicio. - Guía de laboratorio GeniAI: proporcionar soporte guiado y asistencia con la escalera durante el aprendizaje y la preparación de pruebas.

Ese último punto necesita un límite. La asistencia de IA puede acelerar la redacción y la explicación. No reemplaza la revisión determinista, la verificación independiente o el juicio de seguridad.

La validación de gemelos digitales significa probar la lógica de control contra una representación virtual del comportamiento del equipo o proceso para confirmar que las decisiones de la lógica producen la respuesta del sistema prevista.

En el trabajo relacionado con la seguridad, eso significa hacer preguntas como:

• ¿Una condición de disparo fuerza el estado seguro esperado?
• ¿El tiempo de espera de la retroalimentación de prueba se comporta correctamente?
• ¿El reinicio manual permanece bloqueado hasta que todos los permisivos estén saludables?
• ¿El manejo de fallos analógicos evita un reinicio falso o una continuación insegura oculta?
• ¿La secuencia se recupera limpiamente después de una parada anormal?

Aquí es donde OLLA Lab se vuelve operativamente útil. La estructura de escenarios de la plataforma, la visibilidad de E/S y el marco de gemelos digitales permiten a los ingenieros probar el comportamiento en lugar de simplemente inspeccionar la sintaxis.

Dicho esto, la validación de gemelos digitales no es un sustituto de la aceptación final en el sitio, la validación del dispositivo o las actividades certificadas del ciclo de vida de seguridad. Es una capa de evidencia previa a la puesta en marcha.

Los ingenieros deben probar los casos de fallo que exponen suposiciones ocultas en la lógica, especialmente donde la retención de estado, los permisivos y la interpretación analógica pueden fallar silenciosamente.

Un conjunto de fallos útil previo a la auditoría incluye:

- Sensor fuera de rango: valores bajos, altos, equivalentes a NaN o inverosímiles. - Deriva analógica: movimiento gradual a través de los umbrales de alarma y disparo. - Entrada discreta con vibración (chattering): ruido de transición repetido en interruptores de límite o retroalimentaciones. - Entrada de estado obsoleto: valor congelado mientras las condiciones del proceso deberían estar cambiando. - Pérdida de permisivo: retroalimentación del arrancador del motor perdida, prueba de válvula ausente, presión no establecida. - Condición de ciclo de energía o reinicio: validación de bits retenidos y estado de inicio. - Uso indebido del reinicio manual: reinicio disponible antes de que se elimine el peligro. - Interrupción de secuencia: parada o disparo durante la transición de paso intermedio. - Sustituto de caída de comunicación: estado congelado o inválido de un subsistema dependiente. - Desacuerdo de interbloqueo: comando emitido mientras la retroalimentación contradice el estado esperado del equipo.

Estas pruebas importan porque muchos fallos peligrosos no son dramáticos. Son discrepancias silenciosas entre lo que cree la escalera y lo que el equipo está haciendo realmente.

Un paquete listo para auditoría debe documentar el razonamiento de ingeniería y la prueba de comportamiento, no solo capturas de pantalla.

Utilice esta estructura compacta para cada escenario o función relevante para la seguridad:

Capture la perspectiva de ingeniería: suposición oculta, permisivo faltante, ruta de reinicio ambigua, problema de temporización o riesgo de interferencia.

1. Descripción del sistema Defina el equipo, el propósito del proceso, el modo de operación y el rol de seguridad.
2. Definición operativa de "correcto" Indique el comportamiento esperado exacto, incluidos permisivos, disparos, condiciones de reinicio, temporización y estado seguro.
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños relevantes, el mapeo de etiquetas y el estado del equipo o proceso utilizado en la simulación.
4. El caso de fallo inyectado Documente la condición anormal introducida, cómo se forzó y por qué importa.
5. La revisión realizada Registre el cambio de lógica, el ajuste de parámetros o la corrección de manejo de estado realizada después de la prueba.
6. Lecciones aprendidas

Esta estructura es deliberadamente sencilla. Los auditores y revisores suelen preferir evidencia que puedan seguir sin arqueología interpretativa.

Los ingenieros pueden usar OLLA Lab para generar artefactos pre-auditoría reproducibles vinculando cada prueba a un escenario, un conjunto de condiciones forzadas, comportamiento de etiquetas observable y una revisión documentada.

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

1. Seleccione un escenario con objetivos operativos explícitos Por ejemplo, una cadena de parada de emergencia (E-Stop), control de bomba principal/reserva, secuencia de cinta transportadora o conjunto de permisivos de AHU.
2. Defina el comportamiento seguro esperado antes de probar Indique qué debe suceder en caso de disparo, reinicio y entrada anormal.
3. Ejecute la escalera en modo de simulación Utilice el editor y los controles de simulación para ejecutar la lógica en condiciones normales primero.
4. Fuerce el fallo a través del panel de variables Inyecte valores analógicos fuera de rango, elimine la retroalimentación de prueba, alterne interbloqueos o simule estados obsoletos.
5. Observe y registre la respuesta Confirme si las salidas, estados, alarmas y rutas de reinicio se comportan según lo definido.
6. Revise la lógica y vuelva a ejecutar el caso exacto Esta es la parte importante. La evidencia sin historial de revisión es a menudo solo un diario.
7. Capture los parámetros del escenario y el resumen de resultados Conserve las condiciones de prueba para que otro revisor pueda reproducir el resultado.

En ese flujo de trabajo, el valor de OLLA Lab no es que pruebe el cumplimiento por sí solo. Su valor es que ayuda a los ingenieros a crear un cuerpo repetible de evidencia de comportamiento antes de la presentación formal de la auditoría y antes de que el equipo en vivo se convierta en el banco de pruebas.

Una implementación de E-Stop defensiva debe hacer cumplir el comportamiento de pérdida a prueba de fallos, el reinicio manual explícito y la protección contra condiciones de reinicio atado o prematuro.

[Idioma: Diagrama de escalera - IEC 61131-3]

|----[/] E_STOP_OK ----+-------------------------------( ) SAFE_TRIP_ACTIVE | | |----[/] SAFETY_RELAY_FB-+

|----[ ] E_STOP_OK ----[ ] SAFETY_RELAY_FB ----[ ] RESET_PB ----[/] SAFE_TRIP_ACTIVE ----[TON ANTI_TIEDOWN 500ms] |------------------------------------------------------------------------------------------------------------( ) RESET_PERMISSIVE

|----[ ] RESET_PERMISSIVE ----[ ] ALL_PERMISSIVES_OK ----[ ] NO_ACTIVE_FAULTS ----[/] START_INHIBIT ----( ) SAFETY_ENABLE

|----[/] SAFETY_ENABLE ------------------------------------------------------------------------------------( ) MOTOR_RUN_CMD

Por qué importa este patrón

- Integridad: el reinicio requiere condiciones saludables definidas, no solo la restauración de la parada de emergencia. - Robustez: la pérdida de retroalimentación del relé de seguridad o de la salud de la parada de emergencia fuerza el comportamiento de disparo. - Recuperabilidad: el reinicio es manual y condicionado. - Comportamiento a prueba de fallos: la ausencia de entradas de seguridad saludables elimina la habilitación. - Ausencia de interferencia: la ruta de seguridad es explícita y separable de la lógica de conveniencia.

En la práctica, la implementación exacta depende de la plataforma, la arquitectura de seguridad y la ruta de hardware certificada. El punto aquí es estructural: la recuperación segura debe ganarse, no asumirse.

Las simulaciones 3D y VR ayudan cuando mejoran la observabilidad de las consecuencias del proceso, no cuando simplemente añaden teatro visual.

En OLLA Lab, los escenarios 3D/WebXR/VR pueden ayudar a los ingenieros a comparar el estado de la escalera con la respuesta visible del equipo. Eso es útil al probar:

• progresión de secuencia,
• temporización del actuador,
• dependencias de retroalimentación de prueba,
• condiciones de alarma,
• movimiento interbloqueado,
• y consecuencias del reinicio del operador.

El beneficio de ingeniería es que los errores de lógica se vuelven más fáciles de detectar cuando el equipo virtual hace algo obviamente incorrecto por una razón trazable.

Dicho esto, la evidencia permanece en el lado del software y acotada a la simulación. Fortalece la verificación previa a la puesta en marcha. No reemplaza la validación física, el comportamiento del dispositivo certificado o el caso de seguridad formal.

Los equipos deben usar la asistencia de IA para la aceleración en la capa de borrador y explicación, y luego aplicar una revisión humana determinista en la capa de decisión.

En OLLA Lab, GeniAI puede ayudar con la incorporación, la explicación de peldaños, sugerencias correctivas y soporte de redacción de escalera. Eso es útil, especialmente para el aprendizaje estructurado y la iteración en etapas tempranas. Reduce la fricción, pero la reducción de la fricción no es lo mismo que la garantía de seguridad.

Para la lógica relacionada con la seguridad, los equipos deben requerir:

• mapeo explícito de requisitos,
• revisión independiente de la lógica generada,
• simulación con inyección de fallos,
• revisión documentada después de casos fallidos,
• y aprobación final por un ingeniero calificado dentro del ciclo de vida de seguridad del proyecto.

El contraste memorable es simple: generación de borradores frente a veto determinista. El segundo es el trabajo.

Los ingenieros deben comenzar convirtiendo las afirmaciones de seguridad abstractas en casos de prueba repetibles.

Una secuencia práctica es:

• identificar las funciones relevantes para la seguridad en el alcance del PLC,
• definir el comportamiento correcto para estados normales, de disparo, de reinicio y anormales,
• mapear cada función a un pequeño conjunto de propiedades de seguridad,
• ejecutar simulación con inyección de fallos antes de las pruebas de hardware,
• documentar las revisiones en un paquete de evidencia compacto,
• y reservar la puesta en marcha en vivo para la validación, no para el primer descubrimiento.

Si su flujo de trabajo actual todavía trata las pruebas de estado anormal como algo que sucede una vez que el panel está energizado, el proceso llega tarde.

_Texto alternativo de la imagen: Captura de pantalla del Panel de Variables de OLLA Lab que demuestra una prueba de Capacidad Sistemática. Se fuerza una entrada analógica fuera de rango y la lógica transita a un estado seguro, ilustrando la propiedad de robustez en un flujo de trabajo de auditoría IEC 61508 simulado._

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - Descripción general de IEC 61508 (seguridad funcional) - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Gemelo digital en la fabricación: una revisión y clasificación bibliográfica categórica (IFAC, DOI) - Gemelo digital en la industria: estado del arte (IEEE, DOI)

El equipo de ingeniería de Ampergon Vallis Lab se especializa en la validación de sistemas de control críticos y la aplicación de estándares de seguridad funcional en entornos industriales complejos.

Este artículo ha sido revisado por especialistas en seguridad funcional para asegurar la alineación con los principios de la norma IEC 61508 Edición 3 y las mejores prácticas de verificación de software de PLC.