Industria 5.0 y supervisión humana (Human-in-the-Loop) para la validación de lógica PLC mediante IA

En la Industria 5.0, la supervisión humana (Human-in-the-Loop, HITL) es el acto de ingeniería consistente en verificar que la lógica de control generada por IA se comporte de forma segura frente a las restricciones del equipo físico antes de su implementación. OLLA Lab respalda dicha validación permitiendo a los ingenieros probar la lógica de escalera (ladder) en simulación, inspeccionar el comportamiento de E/S, inyectar fallos y comparar la intención del código con el comportamiento de la máquina en 3D o RV.

La asistencia de la IA en la automatización no está bloqueada por la falta de generación de sintaxis. Está bloqueada por el hecho de que el control industrial es físico, determinista y sensible a los fallos. Un peldaño (rung) de lógica de escalera puede parecer plausible y, aun así, llevar a una máquina a un estado peligroso.

Esta distinción es importante porque la Industria 5.0 no trata sobre eliminar a las personas de la producción. El enfoque de la Comisión Europea sitúa al trabajador humano de nuevo en el centro, con la resiliencia, la colaboración y la complementariedad humano-máquina como principios fundamentales, más que como lenguaje decorativo.

Una reciente prueba de estrés interna de Ampergon Vallis refuerza este punto: en 500 secuencias de control de motores generadas por IA, la salida bruta del LLM produjo sistemáticamente una lógica que requería corrección humana antes de una validación segura en simulación, con fallos frecuentes en torno al antirrebote (debounce), los permisivos y las suposiciones de seguridad ante fallos. Metodología: 500 generaciones de respuesta a prompts para tareas de arranque/parada de motores y enclavamientos, comparadas con la lógica de referencia creada por instructores, evaluadas durante un periodo de prueba interno de 30 días. Esta métrica respalda una afirmación limitada: la salida de IA sin revisar no está lista para la validación de control. No respalda la afirmación más amplia de que la IA sea inútil en la automatización. Es útil. Simplemente no es un argumento de seguridad.

La Industria 4.0 enfatizó la conectividad, la automatización y la integración ciberfísica. La Industria 5.0 añade un centro de gravedad diferente: el operador humano, el ingeniero y el responsable de la toma de decisiones siguen siendo esenciales para una producción resiliente.

No se trata de un ajuste de marca. Es una distinción de sistemas. La Industria 4.0 a menudo se resumía a través de la conectividad máquina a máquina, las células autónomas y el ideal de la "fábrica oscura". La Industria 5.0, particularmente en el contexto de la política europea, se desplaza hacia el enfoque humano, la sostenibilidad y la resiliencia (Comisión Europea, 2021).

Para los ingenieros de control, la implicación práctica es directa. El ingeniero ya no se define simplemente como la persona que escribe la lógica. El ingeniero se convierte en quien valida si la lógica generada es físicamente coherente, operativamente segura y recuperable en condiciones anormales. La sintaxis es barata. El juicio determinista no lo es.

Aquí es donde el término Human-in-the-Loop requiere disciplina. En este artículo, HITL no significa "una persona echó un vistazo a la salida". Significa que un ingeniero humano ha:

• revisado la secuencia de control lógicamente,
• comprobado frente al comportamiento del equipo,
• verificado la respuesta de seguridad ante fallos en condiciones anormales,
• y confirmado que el estado de la máquina y el estado de la lógica de escalera permanecen alineados.

Cualquier cosa menos que esto es teatro de flujo de trabajo.

Los LLM generan texto probable. Los PLC ejecutan lógica determinista frente a E/S reales y restricciones de ciclo de escaneo. Ese desajuste es el problema central.

Un modelo de lenguaje predice el siguiente token a partir de patrones en los datos de entrenamiento. No ejecuta un escaneo de máquina, no posee un dispositivo de campo ni razona inherentemente a partir de la inercia del actuador, las convenciones de cableado o el tiempo muerto del proceso. La programación de control IEC 61131-3 vive en un mundo de ejecución ordenada, estado explícito y causalidad observable. El trabajo de seguridad funcional bajo normas como la IEC 61508 es aún más estricto.

El resultado es predecible. La lógica de escalera generada por IA a menudo parece estructuralmente competente mientras permanece operativamente incompleta. Puede producir peldaños. No puede garantizar un comportamiento seguro de la máquina. Esos son logros diferentes.

Los 3 peligros físicos que el código de IA ignora habitualmente

#### 1. Momento mecánico

La lógica de IA a menudo asume que borrar un bit de salida significa que la máquina se ha detenido. Los sistemas físicos son menos obedientes.

Las cintas transportadoras avanzan por inercia. Los equipos rotativos tienen inercia. Los ejes neumáticos se sobrepasan. Un cabezal de recogida robótico no se detiene instantáneamente solo porque el peldaño se volvió falso. Si los permisivos posteriores asumen una parada instantánea, las colisiones y los atascos son fáciles de escribir y costosos de explicar.

#### 2. Histéresis y ruido del sensor

La salida de la IA a menudo especifica insuficientemente el antirrebote (debounce), la banda muerta y la validación de señales.

Los sensores reales vibran. Los interruptores de nivel oscilan cerca del umbral. Las fotocélulas parpadean con la geometría del producto. Los valores analógicos derivan, se saturan y presentan picos. Una secuencia de control que reacciona a cada transición como si el instrumento fuera un demostrador de teoremas producirá disparos molestos en el mejor de los casos y secuencias inestables en el peor.

#### 3. Cableado de campo normalmente cerrado y convenciones de seguridad ante fallos

Los modelos de IA manejan regularmente mal la diferencia entre la verdad lógica y la interpretación segura del estado de campo.

Un circuito de parada normalmente cerrado, una cadena de permisivos saludable o un dispositivo de desconexión por disparo no se asignan claramente a suposiciones simplistas de "1 significa activo". Este es un modo de fallo común porque el modelo ve símbolos; la planta ve la filosofía de cableado.

El determinismo no es negociable porque el control industrial se juzga por un comportamiento repetible bajo condiciones definidas, no por si el código generado se parece a ejemplos anteriores.

Un escaneo de PLC se ejecuta en una secuencia conocida. Las entradas se leen, la lógica se resuelve, las salidas se actualizan y el comportamiento de temporización se evalúa en un ciclo repetible. Las funciones relacionadas con la seguridad requieren una disciplina aún más estricta en torno a los estados definidos, la cobertura de diagnóstico y la respuesta ante fallos. La norma IEC 61508 existe precisamente porque "probablemente correcto" no es una categoría de diseño aceptable para sistemas peligrosos.

Esto no significa que la IA no tenga lugar en el trabajo con PLC. Significa que la IA pertenece a la parte anterior a la validación, no a la posterior. La generación de borradores puede ser útil. El veto determinista debe permanecer bajo control humano.

Ese contraste merece mantenerse a la vista: generación de borradores frente a veto determinista. Uno es asistencia. El otro es responsabilidad.

Human-in-the-Loop significa que un ingeniero humano verifica que la lógica generada comande el sistema físico de forma segura, tenga en cuenta el comportamiento real del equipo y falle de forma segura en condiciones anormales antes de la implementación.

Esa definición es intencionalmente estrecha. Es observable. Puede ser auditada. Evita la niebla habitual en torno al término.

En términos operativos, la validación HITL incluye:

• comprobar que los permisivos, disparos y enclavamientos coinciden con la filosofía de control,
• verificar que el comportamiento de arranque, parada y reinicio de fallos sea determinista,
• confirmar que las suposiciones de los dispositivos de campo coinciden con el cableado real y los modos de fallo,
• probar estados anormales como pérdida de sensor, retroalimentaciones atascadas y movimiento retrasado,
• y revisar si la máquina alcanza un estado seguro cuando se espera.

Una revisión rápida del código no es suficiente. Un hilo de comentarios no es suficiente. Si el ingeniero no ha observado el comportamiento frente a un modelo de sistema simulado o físico, el bucle no está cerrado.

Un ingeniero listo para la simulación es aquel que puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que esa lógica llegue a un proceso en vivo.

Esto no es sinónimo de "conoce la sintaxis de escalera". Es un umbral más estricto.

Un ingeniero listo para la simulación puede:

• asignar etiquetas y E/S a un modelo de máquina o proceso,
• definir cómo se ve el comportamiento correcto antes de que comiencen las pruebas,
• observar la divergencia entre el estado de la escalera y el estado del equipo,
• inyectar fallos deliberadamente en lugar de esperar a que aparezcan por accidente,
• revisar la lógica después del fallo,
• y documentar por qué la revisión cierra el riesgo.

Esa es la diferencia entre la fluidez en el aula y la utilidad en la puesta en marcha.

Los ingenieros practican HITL de forma segura validando la lógica generada o redactada dentro de un entorno de simulación con riesgo controlado antes de cualquier implementación en vivo.

Aquí es donde OLLA Lab se vuelve operativamente útil. OLLA Lab es un entorno de formación en lógica de escalera y gemelos digitales basado en la web que permite a los usuarios construir lógica de escalera en el navegador, ejecutar simulaciones, inspeccionar E/S y variables, trabajar a través de escenarios industriales realistas y comparar el comportamiento de la lógica frente a modelos de equipos en 3D o RV. En términos acotados, es un entorno de ensayo para la validación y la práctica de resolución de problemas.

Eso es importante porque la mayoría de los ingenieros junior no pueden aprender estas lecciones de forma segura en equipos energizados, cintas transportadoras activas, patines de bombas o células robóticas. El coste de aprender en hardware real suele ser equipos dañados, pérdida de tiempo o interrupciones operativas evitables.

El bucle de generación-validación en OLLA Lab

Un flujo de trabajo HITL práctico en OLLA Lab puede seguir cuatro pasos:

#### Paso 1: Generar una línea base

Utilice el editor de escalera y, cuando sea apropiado, GeniAI para redactar la lógica de escalera base para un escenario definido, como un paletizador, una cinta transportadora, una estación de bombeo o una secuencia de climatización.

El punto aquí no es la aceptación ciega. El punto es acelerar la creación del primer borrador para que pueda comenzar el trabajo real: la validación.

#### Paso 2: Vincular la lógica al equipo simulado

Asigne etiquetas, entradas, salidas y variables relevantes al modelo de escenario en el entorno de simulación de OLLA Lab, incluyendo vistas 3D o WebXR donde estén disponibles.

Este es el momento en que la lógica abstracta comienza a encontrarse con la consecuencia física. Muchos errores permanecen invisibles hasta que una salida se vincula al movimiento, al retardo o a la dependencia de la secuencia.

#### Paso 3: Inyectar fallos y observar el comportamiento ante fallos

Utilice el panel de variables para forzar condiciones anormales como:

• transiciones de sensor fallidas,
• retroalimentación de prueba retrasada,
• comportamiento de entrada discreta ruidosa,
• excursiones analógicas,
• o estados permisivos incorrectos.

Luego observe si la secuencia falla de forma segura, se detiene de forma segura o procede incorrectamente. Una buena validación no consiste en probar el camino feliz.

#### Paso 4: Aplicar la corrección humana

Revise la lógica de escalera en el editor para añadir salvaguardas deterministas como:

• temporizadores de antirrebote,
• correcciones de auto-retención (seal-in),
• lógica de parada de seguridad ante fallos,
• comprobaciones de prueba de movimiento,
• alarmas de tiempo de espera,
• y enclavamientos explícitos.

La contribución humana no es una edición cosmética. Es la inserción de juicio de ingeniería donde el borrador generado carecía de realismo físico.

Una secuencia de cinta transportadora o paletizador es un ejemplo útil porque expone errores de temporización, movimiento y enclavamiento rápidamente.

Suponga que una secuencia generada por IA arranca una cinta transportadora cuando se detecta producto aguas arriba y la detiene cuando la zona aguas abajo está ocupada. Sobre el papel, la lógica puede parecer coherente. En la simulación, surge el fallo: el sensor aguas abajo vibra, la cinta transportadora avanza por inercia después de la parada y la secuencia se vuelve a energizar antes de que la zona se haya despejado realmente. El resultado es un atasco o colisión en el modelo 3D.

Un validador humano detectaría esto comprobando tres cosas:

• si el sensor requiere antirrebote o confirmación de estado,
• si el comportamiento de parada de la cinta transportadora incluye tiempo de inercia física,
• y si la lógica de reinicio requiere una condición de despeje determinista en lugar de un solo bit transitorio.

Un patrón correctivo compacto a menudo incluye lógica de confirmación retardada. Por ejemplo:

[Idioma: Diagrama de escalera] // Lógica de antirrebote corregida por humanos |---[ Sensor_Físico ]-------[ TON: Temporizador_Retardo_Encendido, 50ms ]---| |---[ Temporizador_Retardo_Encendido.DN ]-----( Latch_Señal_Válida )----------|

Este fragmento de código no es una solución universal. Ilustra un punto más amplio: el ingeniero humano añade disciplina temporal y física que el borrador generado a menudo omite.

La simulación en RV y 3D construye un juicio útil porque permite a los ingenieros ver las consecuencias físicas de una mala lógica sin pagar por esas lecciones en equipos reales.

Esa frase, "cicatrices de batalla", debe manejarse con cuidado. No significa teatralidad o gamificación. Significa exposición repetida a patrones de fallo: condiciones de carrera, omisiones de enclavamiento, falsos permisivos, mal diseño de reinicio y comportamiento de reinicio inseguro. La consecuencia visual acelera la comprensión.

Cuando un ingeniero junior ve un atasco en una cinta transportadora virtual, una colisión en un paletizador o una secuencia de bomba que no logra transicionar porque la retroalimentación de prueba nunca llega, la lección se vuelve causal en lugar de abstracta. El estado de la escalera, el estado de la variable y el estado del equipo pueden compararse directamente. Ese es exactamente el tipo de modelo mental que requiere el trabajo de puesta en marcha.

La investigación sobre la formación técnica inmersiva y basada en simulación generalmente respalda esta dirección cuando el entorno está vinculado al realismo de la tarea, la retroalimentación y la práctica repetible en lugar de solo a la novedad. El calificador importante es obvio: la inmersión es útil cuando mejora la observación diagnóstica. Un casco por sí solo no es pedagogía.

Los ingenieros deben documentar un cuerpo compacto de evidencia de ingeniería, no una galería de interfaces atractivas.

Un artefacto de validación creíble debe incluir exactamente seis elementos:

1. Descripción del sistema Defina la máquina o proceso que se está controlando, el objetivo operativo y las E/S principales.
2. Definición operativa de "correcto" Establezca qué debe suceder, en qué orden, bajo qué condiciones y cómo se ve un fallo seguro.
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños, etiquetas y la condición de la máquina simulada correspondiente.
4. El caso de fallo inyectado Identifique la condición anormal introducida, como vibración del sensor, retroalimentación perdida, válvula atascada o rango analógico excedido.
5. La revisión realizada Documente el cambio exacto en la lógica, incluyendo temporizadores, enclavamientos, manejo de estados, alarmas o correcciones de permisivos.
6. Lecciones aprendidas Explique qué omitió el borrador original y por qué la revisión refleja mejor la realidad física y operativa.

Esta estructura es mucho más persuasiva que las capturas de pantalla con pies de foto como "laboratorio de paletizador completado". Completar no es evidencia. Diagnosticar sí lo es.

La IA debería servir como asistente para la redacción, la explicación y el apoyo a la iteración, mientras que el ingeniero sigue siendo responsable de la validación, el razonamiento de fallos y el juicio de implementación.

Eso se alinea con el modelo de la Industria 5.0 de forma más limpia que cualquiera de las posiciones extremas. El ingeniero no es reemplazado por un generador de texto, y el generador de texto no es irrelevante. El papel útil es la asistencia acotada dentro de un flujo de trabajo de validación controlado por humanos.

En OLLA Lab, eso significa que GeniAI puede ayudar a reducir la fricción de incorporación, explicar conceptos de escalera y apoyar la creación de borradores. El modo de simulación de la plataforma, el panel de variables, la estructura de escenarios y las vistas de gemelos digitales proporcionan entonces el entorno donde esos borradores se prueban, desafían y corrigen. Productivamente, esto no es "la IA escribe la planta". Es "la IA redacta; el ingeniero verifica".

OLLA Lab encaja como un entorno de ensayo acotado para tareas de puesta en marcha de alto riesgo que son demasiado costosas, demasiado inseguras o demasiado disruptivas operativamente para practicar primero en equipos en vivo.

Sus funciones relevantes en ese flujo de trabajo incluyen:

• construir lógica de escalera en un editor basado en navegador,
• simular la ejecución de la lógica sin hardware,
• monitorear etiquetas, E/S, valores analógicos y variables relacionadas con PID,
• seleccionar escenarios industriales realistas,
• comparar el comportamiento de la lógica frente a vistas de equipos en 3D o RV,
• y revisar la lógica después de observar fallos.

Ese posicionamiento es importante. OLLA Lab no es un proxy de certificación, no es una declaración SIL y no es un sustituto de la puesta en marcha específica del sitio bajo procedimientos formales. Es un entorno controlado para aprender y ensayar los comportamientos de validación que exigen los proyectos reales.

La Industria 5.0 no reduce la necesidad de ingenieros de control. Agudiza la necesidad de ingenieros que puedan validar la lógica asistida por IA frente a la realidad física, la ejecución determinista y el comportamiento de seguridad ante fallos.

La distinción central es simple: la IA puede generar texto de control plausible, pero no puede asumir la responsabilidad del comportamiento de la máquina. La supervisión humana (Human-in-the-Loop) cierra esa brecha comprobando si la lógica funciona no solo sintácticamente, sino operativamente.

Un ingeniero listo para la simulación no es, por tanto, solo alguien que puede escribir lógica de escalera. Es alguien que puede probar, observar, diagnosticar y endurecer esa lógica antes de que llegue a un proceso en vivo. El valor práctico de OLLA Lab se sitúa exactamente ahí: como un entorno de riesgo contenido donde los ingenieros pueden ensayar la validación, inyectar fallos, comparar el estado de la escalera con el estado del equipo y construir el tipo de juicio que las plantas rara vez tienen tiempo de enseñar con suavidad.

- U.S. Bureau of Labor Statistics (BLS) – Occupational Outlook Handbook - Deloitte Insights – 2025 Manufacturing Industry Outlook - The Manufacturing Institute & Deloitte – Talent and workforce research - European Commission – Industry 5.0 - IEC 61131-3 standard overview (IEC) - IEC 61508 functional safety standard overview (IEC) - ISO 10218 industrial robot safety standard overview (ISO) - International Federation of Robotics – World Robotics reports - IFAC-PapersOnLine journal homepage - Sensors journal – industrial digital twin and monitoring research