Cómo validar la lógica de PLC mediante Software-in-the-Loop (SITL) y gemelos digitales de OLLA Lab

Las pruebas Software-in-the-Loop (SITL) en automatización industrial consisten en la ejecución de la lógica de control del PLC frente a un modelo de software del comportamiento del equipo, en lugar de utilizar hardware físico. En OLLA Lab, la lógica de escalera (ladder) puede probarse frente a gemelos digitales 3D para verificar la temporización de secuencias, enclavamientos, comportamiento en estados anormales y recuperación de fallos antes de la puesta en marcha real.

Una lógica de escalera sintácticamente correcta no es lo mismo que una lógica de control lista para su despliegue. Un compilador puede confirmar la validez de las instrucciones, la consistencia de las etiquetas y el orden básico de ejecución; pero no puede decirle si un transportador se indexa dentro de un cilindro extendido, si una secuencia de reinicio vuelve a energizar un movimiento peligroso o si un sensor llega demasiado tarde para proteger el mecanismo. La sintaxis es barata. Los errores de puesta en marcha no lo son.

Una definición útil de "listo para la simulación" es operativa, no aspiracional: un ingeniero está listo para la simulación cuando puede probar, observar, diagnosticar y fortalecer la lógica de control frente al comportamiento realista del proceso antes de que este llegue a un proceso real.

En un análisis interno de Ampergon Vallis de 1,200 escenarios de puesta en marcha simulados ejecutados en OLLA Lab, los usuarios que validaron la lógica frente a un gemelo digital 3D identificaron el 84% de las condiciones de carrera (race conditions) mecánicas modeladas antes de la primera ejecución física. Metodología: tamaño de muestra = 1,200 ejecuciones de escenarios en laboratorios preestablecidos y personalizados; definición de tarea = detección de condiciones de carrera modeladas, tales como conflictos de actuación superpuesta e indexación; comparador de referencia = revisión de lógica y estado de compilación válida sin ejecución de gemelo digital; ventana de tiempo = enero de 2025 a febrero de 2026. Esto respalda la afirmación de que la simulación puede exponer clases de fallos que las comprobaciones de sintaxis ordinarias pasan por alto. No prueba la fiabilidad en campo, la competencia del operador ni la certificación de seguridad.

SITL, HIL y la puesta en marcha física responden a diferentes preguntas de validación. Tratarlos como intercambiables es una forma segura de pasar por alto riesgos.

Bajo el marco de puesta en marcha virtual descrito en la norma VDI 3693, Software-in-the-Loop (SITL) significa que tanto la lógica del controlador como el comportamiento de la planta están representados en software, sin necesidad de que el PLC físico, el cableado de campo o el hardware de la máquina estén presentes. El objetivo es validar el comportamiento del control frente a la respuesta simulada del proceso en un entorno de riesgo contenido.

Hardware-in-the-Loop (HIL) se acerca un paso más a la realidad. La planta permanece simulada, pero se introduce el hardware del controlador real. Esto prueba la temporización del hardware, el manejo de E/S y algunos comportamientos específicos de la plataforma que SITL no puede reproducir completamente.

La puesta en marcha física es el conjunto completo: lógica de control, PLC físico, cableado, instrumentación, actuadores, dinámica de la máquina y las sorpresas que aparecen cuando todo eso se encuentra durante la puesta en marcha.

### Comparación: SITL vs HIL vs puesta en marcha física

| Modo de validación | Qué es real | Qué es simulado | Propósito principal | Nivel de riesgo | |---|---|---|---|---| | SITL | Entorno de ejecución de lógica de control | Comportamiento de planta/equipo | Validar lógica de secuencia, enclavamientos, supuestos de temporización, transiciones de estado, gestión de fallos | Bajo | | HIL | Hardware de PLC/controlador físico | Comportamiento de planta/equipo | Validar ejecución específica del controlador, comportamiento de E/S, temporización de hardware, supuestos de integración | Medio | | Puesta en marcha física | PLC, cableado, sensores, actuadores, máquina/proceso | Poco o nada | Validar el sistema desplegado bajo condiciones operativas reales | Alto |

En qué es bueno SITL

• Verificar el orden de la secuencia y la lógica de permisos.
• Probar el comportamiento ante alarmas y disparos (trips).
• Ejercitar la lógica de reinicio y recuperación.
• Exponer condiciones de carrera entre comandos y retroalimentaciones.
• Ensayar estados anormales sin arriesgar el equipo.

Lo que SITL no reemplaza

• Pruebas de aceptación en sitio (SAT).
• Comprobaciones de lazos y verificación de cableado.
• Validación de seguridad funcional.
• Determinación de SIL o demostración de cumplimiento.
• Formación de operadores en el activo instalado exacto, a menos que el alcance del modelo lo permita.

Ese límite es importante. Un gemelo digital es útil porque reduce la incertidumbre, no porque la elimine.

La lógica de escalera falla en campo porque los sistemas físicos no son diagramas booleanos. Tienen retardo, inercia, fricción, deriva y modos de fallo que un compilador no modela.

Un peldaño (rung) de compilación válida aún puede ordenar una secuencia imposible. También puede ordenar una secuencia posible en el momento equivocado, lo cual suele ser peor porque falla de forma intermitente.

Las tres realidades físicas que los compiladores ignoran

1. Inercia mecánica Un comando de parada no produce una parada instantánea. Los motores se desplazan por inercia, los transportadores se exceden y las cargas suspendidas siguen moviéndose. La lógica puede ser correcta a nivel de escaneo y aun así ser incorrecta a nivel de máquina.
2. Latencia del sensor Los sensores reales tienen tiempo de respuesta, tolerancia de montaje, rebote y filtrado. Una fotocélula o un interruptor de límite que cambia de estado unos milisegundos más tarde de lo esperado puede invalidar una secuencia por lo demás elegante.
3. Fricción (stiction) del actuador y retardo del proceso Los cilindros neumáticos necesitan acumulación de presión. Las válvulas pueden atascarse antes de moverse. Las bombas no crean un flujo estable en el instante en que se activa un bit del motor. Al diagrama de escalera no le importa; al proceso sí.

La falacia de "parece correcto"

"Parece correcto" suele significar "pasa una revisión visual bajo supuestos ideales". Eso no es lo mismo que probar que la secuencia sobrevive a condiciones realistas de temporización y fallos.

Considere un transportador de clasificación con un cilindro empujador:

• La lógica ordena la parada del transportador.
• La lógica ordena la extensión del cilindro.
• La lógica espera la confirmación de extendido.
• La lógica reinicia el transportador después de la desviación del producto.

Sobre el papel, esto es ordenado. En una máquina simulada, el transportador puede seguir moviéndose por inercia cuando el cilindro entra en el carril. Si la secuencia depende de una parada instantánea, el mecanismo colisiona aunque cada peldaño sea legal y cada nombre de etiqueta sea correcto. El compilador no pondrá objeciones. La física, por lo general, sí lo hará.

En este artículo, un gemelo digital no es un sinónimo de marketing para gráficos 3D. Es un modelo de software que intercambia estados con la lógica de control en un bucle de validación determinista.

Operativamente, un gemelo digital de validación de PLC es:

> Un modelo de software cinemático y de eventos discretos que consume las salidas del PLC, aplica restricciones físicas simuladas como retardo de movimiento, gravedad, fricción y temporización dependiente del estado, y devuelve entradas deterministas de sensores y procesos a la lógica de control.

Esa definición es intencionalmente estrecha. Excluye la visualización decorativa que no participa en el intercambio de estados de control.

Un gemelo digital útil para el trabajo de control debe hacer cuatro cosas

Ejemplo: comandos de marcha de motor, comandos de apertura de válvula, bits de extensión de cilindro, puntos de consigna analógicos.

• Consumir las salidas del controlador

Ejemplo: aceleración, desaceleración, tiempo de permanencia, tiempo de recorrido, retardo de presión, cambio de nivel o retardo de proceso.

• Aplicar el comportamiento modelado del equipo

Ejemplo: interruptores de proximidad, fotocélulas, interruptores de límite, variables de proceso (PV) analógicas, estados de alarma, retroalimentaciones de prueba.

• Devolver entradas simuladas a la lógica

El mismo caso de prueba debe ser lo suficientemente reproducible para diagnosticar cambios en la lógica y comparar revisiones.

• Preservar condiciones de prueba deterministas

Esta es la diferencia entre un video y un entorno de validación. Uno es ilustrativo. El otro puede vetar una lógica de control deficiente.

OLLA Lab se vuelve operativamente útil cuando el programa de escalera y el equipo simulado comparten un estado observable. La plataforma no es solo un editor de escalera con una escena al lado; el valor reside en vincular las variables de lógica al comportamiento de la máquina y luego observar cómo se cierra el bucle.

En OLLA Lab, los usuarios crean lógica de escalera en un editor basado en web, la ejecutan en modo simulación e inspeccionan o manipulan variables a través del panel de variables. La plataforma admite flujos de trabajo de aprendizaje orientados a booleanos, analógicos, temporizadores, comparadores, matemáticas y PID, junto con escenarios de simulación 3D/WebXR. Dentro de ese flujo de trabajo, las etiquetas pueden asociarse con estados de equipos simulados para que los bits de comando impulsen el modelo y los eventos del modelo devuelvan retroalimentación a la lógica.

Flujo de trabajo práctico de vinculación de etiquetas en OLLA Lab

Una configuración de validación típica se ve así:

• Definir las etiquetas de comando en la lógica de escalera
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Definir las etiquetas de retroalimentación y sensores
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Vincular etiquetas de comando a comportamientos del gemelo digital
• `Conveyor_Run_CMD` impulsa el estado de movimiento del transportador
• `Cylinder_Extend_CMD` impulsa la secuencia de extensión del actuador

• Vincular las respuestas del equipo simulado de vuelta a las etiquetas
• El movimiento del transportador actualiza `Conveyor_At_Speed`
• El interruptor de límite virtual actualiza `Cylinder_Extended_LS`
• El raycast virtual o la detección de objetos actualiza `Photoeye_PE1`

• Ejecutar la secuencia e inspeccionar las transiciones de estado
• Alternar entradas
• Pausar, ejecutar o detener la simulación
• Observar cambios de etiquetas, temporizadores, valores analógicos y estados de fallo

Lo que esto aporta al ingeniero

• Una cadena visible de causa y efecto entre la lógica de los peldaños y la respuesta de la máquina.
• Un lugar para probar si los enclavamientos son realmente suficientes.
• Una forma de inspeccionar desajustes de temporización entre el comando y la prueba.
• Un entorno seguro para inyectar fallos que serían costosos o peligrosos en equipos reales.

Aquí es donde OLLA Lab encaja de manera creíble: como un entorno de ensayo de riesgo contenido para la validación y la práctica de resolución de problemas. No reemplaza la puesta en marcha en campo, pero permite a los ingenieros ensayar partes de la puesta en marcha que son demasiado destructivas, costosas o disruptivas para aprenderlas en una línea real.

Las pruebas SITL más valiosas no son las secuencias nominales. Son las pruebas de estados anormales. Casi cualquier estrategia de control parece competente cuando cada sensor se comporta correctamente y cada actuador llega a tiempo.

Casos de prueba SITL obligatorios

Active una parada de emergencia mientras el movimiento está activo y el mecanismo está transportando o empujando material. Verifique:

• que el movimiento peligroso se desenergice según lo previsto,
• que la memoria de estado se comporte de forma predecible,
• que el reinicio requiera una acción deliberada del operador,
• que no exista una ruta de reanudación automática oculta.

Fuerce un dispositivo de límite normalmente cerrado o normalmente abierto al estado de fallo durante el movimiento. Verifique:

• que la detección de fallos ocurra dentro de la ventana esperada,
• que el movimiento se inhiba o se detenga de forma segura,
• que el texto de la alarma y los bits de fallo sean inequívocos,
• que las condiciones de reinicio sean deliberadas y limitadas.

Simule la pérdida de potencia de control o la interrupción de la ejecución. Verifique:

• que las salidas vuelvan a valores predeterminados seguros,
• que la lógica de arranque no reinicie automáticamente el movimiento peligroso,
• que los estados retenidos no creen supuestos de secuencia imposibles,
• que se requiera el reconocimiento del operador cuando sea apropiado.

Ordene un movimiento y retenga la retroalimentación esperada. Verifique:

• que la lógica de tiempo de espera se dispare,
• que el fallo se enclave correctamente,
• que el movimiento aguas abajo se bloquee,
• que la ruta de recuperación sea explícita.

Introduzca una superposición de temporización entre estados adyacentes de la máquina. Verifique:

• que las acciones mutuamente excluyentes sigan siendo excluyentes,
• que un estado no pueda adelantarse a otro sin la prueba requerida,
• que los supuestos de orden de escaneo no estén enmascarando un defecto de secuenciación.

Inyecte perturbaciones de proceso o valores de sensor poco realistas. Verifique:

• que las alarmas se activen en los umbrales definidos,
• que la salida de control se comporte dentro de los límites esperados,
• que la transferencia sin saltos (bumpless) o los cambios de modo se manejen limpiamente,
• que los disparos y permisos sigan siendo coherentes ante una perturbación analógica.

1. Parada de emergencia (E-stop) asíncrona bajo carga
2. Fallo del sensor y verificación de seguridad (failsafe)
3. Recuperación tras ciclo de potencia
4. Tiempo de espera (timeout) mecánico y condiciones sin prueba
5. Condiciones de carrera de secuencia
6. Excursión analógica y perturbación PID

Un concepto erróneo práctico que vale la pena corregir

Probar solo el camino feliz (happy path) no es validación. Es demostración. El riesgo real de la puesta en marcha reside en las transiciones, los retardos y los fallos.

Un patrón de tiempo de espera es una de las estructuras defensivas más simples que gana valor real en SITL. Convierte un "el actuador debería haberse movido ya" en una condición de fallo observable.

A continuación, un ejemplo compacto para un tiempo de espera de extensión de cilindro. La sintaxis exacta varía según la plataforma, pero la intención de control es estándar.

Lenguaje: Diagrama de escalera (Ladder)

// Lógica de fallo de tiempo de espera de actuación de cilindro |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

Qué hace este peldaño

• `CMD_Extend` inicia la condición de temporización cuando se ordena la extensión.
• `Limit_Retract` no activado indica que el cilindro ya no está seguro en casa, dependiendo de la filosofía del dispositivo.
• `Limit_Extend` no activado significa que la prueba de extensión aún no ha llegado.
• `Fault_Delay` mide la ventana de recorrido permitida.
• Cuando el temporizador se completa sin prueba de extensión, se establece `Fault_Cyl_Ext_Timeout`.

Por qué SITL importa aquí

En una revisión de lógica estática, este peldaño parece sencillo. En un gemelo digital, puede probar si el tiempo de espera es:

• demasiado corto para un recorrido realista del actuador,
• demasiado largo para proteger el mecanismo,
• reiniciado incorrectamente por transiciones de secuencia,
• ciego ante movimientos parciales o condiciones de atasco.

Esa es la diferencia entre escribir un tiempo de espera y validarlo.

La evidencia de ingeniería debe mostrar razonamiento, no solo familiaridad con la interfaz. Una galería de capturas de pantalla demuestra que el software se abrió. No demuestra mucho más.

Si el objetivo es demostrar un trabajo de control serio, documente cada ejercicio simulado utilizando esta estructura:

Estructura de evidencia requerida

Ejemplo: "El transportador no debe reiniciarse hasta que el cilindro desviador esté completamente retraído y la presencia de producto esté despejada".

Ejemplo: "Comando de extensión de cilindro emitido mientras el tiempo de inercia del transportador permanecía en 1.8 s".

Ejemplo: "Se añadió permiso de velocidad cero del transportador y fallo de tiempo de espera de extensión".

1. Descripción del sistema Defina la máquina o celda de proceso, los actuadores principales, los sensores y el objetivo operativo.
2. Definición operativa de "correcto" Establezca qué debe ser cierto para que la secuencia se considere correcta.
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños relevantes, las definiciones de etiquetas y los estados o retroalimentaciones correspondientes del gemelo digital.
4. El caso de fallo inyectado Establezca exactamente qué se forzó o perturbó.
5. La revisión realizada Documente el cambio de lógica.
6. Lecciones aprendidas Explique qué supuesto falló y cómo la lógica revisada fortalece la secuencia.

Esta estructura es útil porque captura la intención del control, el modelo de fallo y el razonamiento correctivo. Ese es el material que los empleadores y revisores realmente pueden interrogar. Las capturas de pantalla por sí solas son mayormente decorativas.

OLLA Lab apoya un flujo de trabajo listo para la simulación combinando la creación de escalera, la simulación, la inspección de variables, el contexto del escenario y la interacción con el gemelo digital en un entorno basado en web. El beneficio no es la conveniencia por sí misma; es la reducción del cambio de contexto durante la validación.

Dentro de los hechos del producto delimitados, OLLA Lab ofrece:

• Un editor de lógica de escalera basado en web con contactos, bobinas, temporizadores, contadores, comparadores, funciones matemáticas, operaciones lógicas e instrucciones PID.
• Modo de simulación para ejecutar lógica, alternar entradas y observar salidas sin hardware físico.
• Un panel de variables para monitorear etiquetas, E/S, valores analógicos, variables relacionadas con PID y el estado del escenario.
• Simulaciones 3D/WebXR/VR que conectan la lógica de control con el comportamiento del equipo.
• Flujos de trabajo de validación de gemelos digitales para probar la lógica frente a modelos de máquinas realistas.
• Laboratorios basados en escenarios en manufactura, agua/aguas residuales, HVAC, química, farmacéutica, almacenamiento, alimentos y bebidas, y servicios públicos.
• Instrucciones de construcción guiadas con objetivos, mapeo de E/S, filosofía de control, enclavamientos y pasos de verificación.
• Orientación de IA a través de GeniAI, posicionada como coaching de laboratorio y soporte correctivo dentro del flujo de trabajo de aprendizaje.

La afirmación delimitada

OLLA Lab puede ayudar a los ingenieros a ensayar tareas de validación que son difíciles de organizar de forma segura en sistemas reales:

• rastrear causa y efecto de E/S,
• probar enclavamientos,
• observar el comportamiento ante fallos,
• revisar la lógica tras un fallo de estado anormal,
• comparar el estado de la escalera frente al estado del equipo simulado.

No debe presentarse como un sustituto de la experiencia en campo, el trabajo formal de seguridad funcional o la autoridad de puesta en marcha específica del sitio. Un simulador puede exponer supuestos erróneos tempranamente. No puede firmar la puesta en marcha de una planta.

SITL puede mejorar la calidad de la puesta en marcha al desplazar el descubrimiento de defectos a una etapa más temprana, pero por sí solo no establece el cumplimiento de la seguridad. Esa distinción es fundamental.

Lo que SITL puede apoyar

• Descubrimiento más temprano de defectos de secuenciación.
• Mejor cobertura de pruebas de estados anormales.
• Ensayo más seguro de la gestión de fallos.
• Preparación de puesta en marcha más disciplinada.
• Mejora de la comunicación entre los equipos de control, mecánicos y de procesos.

Lo que aún requiere tratamiento por separado

• Actividades del ciclo de vida de seguridad funcional bajo IEC 61508.
• Diseño y verificación de funciones instrumentadas de seguridad.
• Evaluación de riesgos específica del sitio.
• Análisis de tolerancia a fallos de hardware.
• Pruebas de prueba (proof testing) y validación del sistema instalado.

La literatura industrial sobre puesta en marcha virtual y simulación ciberfísica generalmente respalda el valor de la validación temprana del comportamiento, especialmente para sistemas mecatrónicos y con mucha secuenciación. El resultado recurrente no es que la simulación elimine el riesgo de puesta en marcha. Es que la simulación mueve una parte significativa del descubrimiento de defectos a una fase más barata y segura del proyecto. Esa es una afirmación más modesta, y también la más creíble.

Comience con una secuencia compacta que contenga movimiento, retroalimentación y una rama de estado anormal. Si el primer ejercicio es demasiado simple, enseña sintaxis pero no juicio.

Un buen caso inicial en OLLA Lab es un escenario de transportador y desviador o de bomba principal/reserva con:

• una ruta de comando,
• una retroalimentación de prueba,
• un tiempo de espera,
• una alarma,
• una condición de reinicio,
• un fallo inyectado.

Eso da suficiente estructura para probar la causalidad sin perderse en la arquitectura. El objetivo es aprender si la lógica sobrevive al contacto con un proceso modelado, no construir un sistema grande el primer día.

El equipo de ingeniería de Ampergon Vallis Lab desarrolla metodologías de validación para sistemas de control industrial, enfocándose en la integración de gemelos digitales y pruebas de lógica de PLC.

Este artículo ha sido revisado por especialistas en automatización industrial de Ampergon Vallis para asegurar la precisión técnica en los conceptos de SITL, HIL y la aplicación de gemelos digitales en entornos de OLLA Lab.

- IEC 61131-3: Controladores programables — Parte 3 - Resumen del estándar de seguridad funcional IEC 61508 - Perfil de fabricación inteligente del NIST - IEEE Access: Tecnologías habilitadoras de gemelos digitales (DOI)