Cómo programar la coexistencia segura entre humanos y robots en la Industria 5.0

Para programar una coexistencia segura entre humanos y robots en la Industria 5.0, los ingenieros deben validar las zonas de seguridad dinámicas, los enclavamientos deterministas y la lógica de monitoreo de velocidad y separación. OLLA Lab proporciona un entorno de gemelo digital delimitado donde se pueden probar la lógica de escalera (ladder logic), la causalidad de E/S y las respuestas a fallos antes de que comience la puesta en marcha física.

La Industria 5.0 no es un eslogan sobre hacer que las fábricas se sientan más humanas. Es una corrección a la suposición más estrecha de que la autonomía total es siempre la filosofía de control óptima. El planteamiento de la Comisión Europea es explícito: la industria del futuro debe ser centrada en el ser humano, resiliente y sostenible, no simplemente automatizada a la máxima intensidad (Comisión Europea, 2021).

La razón práctica es sencilla. Los sistemas "a oscuras" (lights-out) manejan bien la repetibilidad, pero manejan mal la varianza cuando esta no se ha modelado de antemano. Una línea puede estar perfectamente optimizada hasta que llega la realidad, lo cual suele ocurrir sin previo aviso.

En pruebas de estrés recientes con WebXR en OLLA Lab, los ingenieros que simularon brechas en zonas dinámicas descubrieron que los peldaños (rungs) de seguridad generados por IA fallaban en el comportamiento requerido de parada de emergencia en 7 de 32 tareas cuando no eran corregidos por una revisión humana, lo que representa una tasa de error del 21,9%. Metodología: n=32 tareas de enclavamiento en celdas colaborativas simuladas, comparador de referencia = conjunto de peldaños deterministas revisados por humanos, ventana de tiempo = enero-marzo de 2026. Esto respalda solo un punto limitado: la generación de borradores no es prueba de una lógica de seguridad desplegable. No respalda una afirmación general sobre todo el trabajo de PLC asistido por IA.

La fábrica a oscuras está haciendo la transición porque la optimización sin el juicio humano adaptativo es frágil. La Industria 4.0 enfatizó la conectividad, la automatización y las operaciones ricas en datos. La Industria 5.0 mantiene esos logros, pero restaura al operador humano, al técnico y al ingeniero como componentes activos en la resiliencia del sistema, en lugar de considerarlos mano de obra residual en los márgenes.

El modelo de Industria 5.0 de la Comisión Europea es la declaración formal más clara de este cambio. No rechaza la automatización. Rechaza la idea de que la automatización por sí sola sea el objetivo industrial más elevado (Comisión Europea, 2021).

Esto es importante en la ingeniería de control porque los estados anormales son donde la filosofía se convierte en lógica de escalera. Las interrupciones de suministro, la deriva de los sensores, los productos mal formados, las anulaciones de mantenimiento y la intervención manual parcial no desaparecen porque una línea esté altamente automatizada. Se convierten en las condiciones que exponen si la estrategia de control fue diseñada para la realidad o para un folleto.

### Filosofías de control: Industria 4.0 vs. Industria 5.0

| Dimensión | Énfasis de la Industria 4.0 | Énfasis de la Industria 5.0 | |---|---|---| | Objetivo principal | Eficiencia, conectividad, rendimiento | Resiliencia, operación centrada en el humano, desempeño sostenible | | Rol del humano | Supervisor de activos automatizados | Gestor de excepciones activo, colaborador, tomador de decisiones | | Rol del PLC/sistema de control | Columna vertebral de automatización determinista | Columna vertebral determinista más coexistencia segura humano-máquina | | Enfoque de seguridad | Separación protegida, zonas de automatización fijas | Colaboración dinámica, espacios compartidos con riesgo reducido cuando se justifica | | Postura ante fallos | Minimizar la interrupción | Recuperarse de forma segura de la interrupción y la varianza |

La idea errónea que vale la pena corregir es que la Industria 5.0 significa "menos automatización". Por lo general, significa una mejor asignación de la cognición. Los robots repiten. Los humanos interpretan. Los buenos sistemas utilizan ambos a propósito.

Los robots seguros no existen de forma aislada; las aplicaciones seguras sí. Esa distinción no es un ajuste semántico. Es el núcleo de cómo se evalúan, validan y ponen en marcha los sistemas colaborativos.

Para las aplicaciones de robots colaborativos, el debate sobre las normas suele centrarse en:

• ISO 10218 para los requisitos de seguridad de los robots industriales
• ISO/TS 15066 para la guía de operación de robots colaborativos
• IEC 61508 para la seguridad funcional de sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad

La norma ISO/TS 15066 no otorga a un robot un estatus "seguro" místico. Define conceptos de operación colaborativa, expectativas de reducción de riesgos y consideraciones a nivel de aplicación como fuerza, contacto, velocidad, separación y estados monitoreados. La norma IEC 61508, por su parte, proporciona el marco de seguridad funcional más amplio para el comportamiento de control relacionado con la seguridad y la disciplina del ciclo de vida.

Los cuatro modos de operación colaborativa reconocidos

1. Parada monitoreada con seguridad (SRMS) El robot se detiene cuando una persona entra en el espacio colaborativo, y el movimiento se reanuda solo bajo condiciones controladas.
2. Guía manual (HG) El humano guía físicamente el movimiento del robot a través de dispositivos de habilitación y una lógica de operación restringida.
3. Monitoreo de velocidad y separación (SSM) La velocidad o el estado de movimiento del robot cambian dinámicamente según la distancia medida respecto a una persona.
4. Limitación de potencia y fuerza (PFL) El robot y las herramientas están diseñados para que las fuerzas de contacto permanezcan dentro de los límites aceptables para la aplicación definida.

La carga de ingeniería es mayor en SSM porque depende de la detección dinámica, la respuesta determinista y la lógica de zona validada. "Dinámico" no significa vago. Significa que la lógica cambia de estado según la separación medida bajo restricciones de tiempo y seguridad definidas.

Qué significan estas normas en términos de PLC

Para un ingeniero de control, las normas se convierten en comportamientos observables:

• el estado del escáner o sensor de seguridad debe estar representado por entradas a prueba de fallos (fail-safe)
• los permisivos deben colapsar a un estado seguro ante la pérdida de señal o un estado no válido
• los comandos de reducción de velocidad y parada deben ser deterministas
• el comportamiento de reinicio debe ser deliberado, limitado y no automático cuando la evaluación de riesgos lo requiera
• las condiciones anormales deben probarse, no descartarse por suposición

Ahí es donde muchos equipos descubren la diferencia entre sintaxis y capacidad de despliegue.

La simulación en RV es útil para SSM porque las pruebas físicas de brechas en las zonas son costosas, lentas y, a veces, innecesariamente arriesgadas. Si la primera vez que un ingeniero observa la lógica del escáner bajo intrusión humana es durante la puesta en marcha en vivo, el proceso ya está demasiado avanzado en la curva de riesgo.

En términos prácticos, la validación de SSM requiere que los ingenieros verifiquen:

• las transiciones de estado de zona bajo una posición cambiante del operador
• los comandos de reducción de velocidad cuando se violan las zonas de advertencia exteriores
• los comandos de parada cuando se violan las zonas de protección interiores
• las condiciones de reinicio y reanudación después de despejar la zona
• el comportamiento a prueba de fallos durante la caída del sensor, estado obsoleto o transiciones no válidas

OLLA Lab es útil aquí como un entorno de ensayo delimitado. Los ingenieros pueden construir lógica de escalera en el navegador, ejecutar la simulación, inspeccionar variables y el estado de E/S, y observar cómo responde una celda de trabajo 3D o WebXR cuando un operador virtual entra en las zonas definidas. El punto no es la novedad visual. El punto es la causalidad.

Qué significa "listo para la simulación" a nivel operativo

"Listo para la simulación" debe definirse por el comportamiento, no por la confianza. Un ingeniero está listo para la simulación cuando puede:

• probar el comportamiento de control previsto antes del despliegue
• observar la causalidad de E/S durante estados normales y anormales
• diagnosticar por qué un permisivo falló o permaneció enclavado
• inyectar un fallo realista y verificar el estado seguro resultante
• revisar la lógica después del caso de fallo y volver a probar la secuencia
• comparar el estado de la escalera con el estado del equipo simulado sin rodeos

Esa es una definición de puesta en marcha, no un adjetivo de currículum.

Por qué WebXR y los gemelos digitales son importantes aquí

Un gemelo digital es operativamente útil cuando el estado del equipo virtual es lo suficientemente cercano como para probar las suposiciones de control, la lógica de secuencia y la respuesta a fallos antes del trabajo en sitio. No es un sustituto de la puesta en marcha final, y no debe describirse como tal. Pero es extremadamente útil para detectar errores de categoría desde el principio: orden de permisivos incorrecto, ruta de reinicio incorrecta, estado predeterminado incorrecto, expectativa de tiempo incorrecta.

Chocar una celda colaborativa virtual es más barato que chocar una física. Esta no es una idea profunda, pero sigue estando subutilizada.

La lógica de zona de seguridad dinámica debe ser determinista, a prueba de fallos y fácil de auditar. La estructura suele separar la reducción de velocidad de la zona exterior, el comportamiento de parada de la zona interior y las condiciones de reinicio manual, en lugar de mezclarlos en un solo peldaño ingenioso. La astucia envejece mal en la puesta en marcha.

Por qué la lógica normalmente cerrada es común para estados a prueba de fallos

La representación normalmente cerrada se utiliza a menudo para estados relacionados con la seguridad porque la pérdida de señal debe tender hacia un resultado seguro. Si un escáner falla, se pierde la integridad del cable o una entrada de seguridad cae, el permisivo debe abrirse en lugar de permanecer falsamente saludable.

En términos simples:

• entrada saludable presente → el permisivo puede permanecer verdadero si se cumplen todas las demás condiciones
• entrada perdida o fallida → el permisivo colapsa
• permisivo colapsado → el robot transita a un estado de riesgo reducido o parada según el diseño de seguridad

La implementación exacta depende de la arquitectura de seguridad, el controlador y la evaluación de riesgos. Pero el principio rector es estable: un estado incierto no debe disfrazarse de estado seguro.

La causalidad mínima que un ingeniero debería poder explicar

Un ingeniero que valide esta lógica debería poder responder:

• ¿Qué causa la reducción de velocidad en lugar de la parada total?
• ¿Qué estado exacto causa la parada de emergencia?
• ¿Qué sucede ante un fallo del escáner frente a una brecha de zona válida?
• ¿Puede el movimiento reanudarse automáticamente o se requiere confirmación?
• ¿Qué condiciones deben ser verdaderas antes de que se acepte el reinicio?
• ¿Cuál es el estado seguro si la señal de zona se vuelve contradictoria u obsoleta?

Si esas respuestas no son explícitas, la lógica no está lista. Puede que todavía sea ejecutable. Eso no es lo mismo.

La validación con el humano en el bucle (human-in-the-loop) es importante porque los operadores no siempre se comportan de acuerdo con el camino ideal. Entran demasiado pronto, reinician demasiado rápido, omiten las expectativas de secuencia y, ocasionalmente, crean la condición exacta que la revisión de diseño olvidó imaginar.

Aquí es donde OLLA Lab se vuelve operativamente útil. En un escenario de empaquetado colaborativo o manejo de materiales, un ingeniero puede:

• construir la lógica de escalera para los permisivos de zona y los comandos de estado del robot
• ejecutar la simulación y observar las salidas en tiempo real
• usar el Panel de Variables para forzar cambios de estado del escáner, fallos y confirmaciones
• comparar el estado de la escalera con la respuesta del equipo en 3D o RV
• revisar la lógica después de una condición anormal inyectada

El valor del producto aquí es limitado y creíble. Proporciona práctica repetida en tareas de alto riesgo que son difíciles de ensayar en equipos reales, especialmente para ingenieros junior. No certifica la competencia, no reemplaza la supervisión en el sitio ni elimina la necesidad de una validación de seguridad formal.

Un flujo de trabajo práctico de inyección de fallos dentro de una celda colaborativa simulada

Una secuencia de validación útil se ve así:

1. Comience con un estado de escáner saludable y un permisivo de robot a máxima velocidad.
2. Infrinja la zona exterior y verifique la transición solo a velocidad reducida.
3. Infrinja la zona interior y verifique el comando de parada y la caída del permisivo.
4. Despeje la zona pero deje el reinicio sin confirmar; confirme que no haya reinicio automático si el diseño lo prohíbe.
5. Inyecte un fallo de escáner mientras la zona está despejada; verifique que el sistema permanezca en un estado inhibido seguro.
6. Intente el reinicio bajo condiciones no válidas; confirme que el reinicio es rechazado.
7. Corrija la estructura del peldaño si queda algún reinicio no deseado o un permisivo obsoleto.

Esa secuencia es más educativa que diez capturas de pantalla de un peldaño terminado. La evidencia de ingeniería debe mostrar pensamiento bajo fallo, no solo sintaxis bajo condiciones ideales.

Un registro de simulación útil es un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla. La documentación debe mostrar qué se probó, por qué se consideró correcto, qué falló y cómo cambió la lógica.

Utilice esta estructura:

Establezca los comportamientos esperados en términos observables. Ejemplo: "La brecha en la zona exterior fuerza una velocidad reducida dentro de la transición de estado simulada; la brecha en la zona interior hace caer el permisivo de seguridad y ordena la parada; el reinicio requiere confirmación manual después de despejar la zona".

Describa la condición anormal introducida: caída del escáner, entrada de zona atascada, reinicio prematuro, estado contradictorio, confirmación retrasada o reingreso del operador.

Documente el cambio exacto en la lógica. Ejemplo: se agregó dominancia de fallo antes del permisivo de reinicio, se separó la lógica de velocidad de la zona exterior de la lógica de parada de la zona interior, o se eliminó una ruta de reinicio automático no deseada.

1. Descripción del sistema Defina la celda, máquina o segmento de proceso. Identifique el activo controlado, las entradas de seguridad, los puntos de interacción del operador y los modos de operación previstos.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Presente los peldaños relevantes y el estado correspondiente del gemelo digital. Muestre nombres de etiquetas, permisivos, salidas y respuesta visual de la máquina.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Indique qué reveló la prueba sobre el diseño de la secuencia, las suposiciones a prueba de fallos, el comportamiento de reinicio o la interacción del operador.

Ese formato es útil para el aprendizaje, la revisión y las conversaciones de contratación porque muestra el juicio de ingeniería.

El modo de fallo más común no es simplemente "mala codificación". Es un mal diseño de estado. La lógica puede compilarse, simularse e incluso parecer ordenada mientras maneja incorrectamente los casos extremos.

Los modos de fallo típicos incluyen:

• errores de dominancia en la ruta de reinicio donde el reinicio omite un permisivo que aún no es válido
• enmascaramiento de fallos donde el fallo del escáner y el estado de despeje válido se tratan de manera demasiado similar
• jerarquía de zonas poco clara entre regiones de advertencia, velocidad reducida y parada
• suposiciones de reinicio automático que nunca fueron justificadas por la evaluación de riesgos de la aplicación
• retención de estado obsoleto donde las salidas permanecen enclavadas después de que la condición física cambió
• semántica de etiquetas deficiente que dificulta la revisión y oculta la causalidad
• mezcla de lógica de control estándar con intención de seguridad sin límites arquitectónicos claros

El patrón correctivo es igualmente consistente:

• defina primero el estado seguro
• defina todas las transiciones válidas en segundo lugar
• defina la dominancia de fallos en tercer lugar
• pruebe las condiciones anormales antes de declarar la secuencia completa

Ese orden ahorra tiempo y puede reducir el riesgo de puesta en marcha.

La asistencia de IA se utiliza mejor para la generación de borradores, la explicación y el apoyo a la revisión, no para el juicio de seguridad final. Puede acelerar el andamiaje de peldaños, las sugerencias de etiquetas y la guía instructiva. No puede cargar con la responsabilidad de la validación determinista por sí sola.

En OLLA Lab, GeniAI puede ayudar a reducir la fricción de incorporación explicando elementos de escalera, sugiriendo estructuras lógicas y ayudando a los estudiantes a avanzar a través de escenarios. Eso es útil, especialmente para ingenieros en etapas iniciales que aún no saben qué error están cometiendo. Pero la prueba de aceptación final sigue siendo dirigida por humanos y basada en evidencia.

Un marco seguro es:

• la IA puede proponer
• la simulación puede exponer
• los ingenieros deben decidir

Esa es la jerarquía adecuada para el trabajo de seguridad colaborativa.

La Industria 5.0 expande el rol del ingeniero de control de autor de secuencias a diseñador de coexistencia. El trabajo ya no es solo automatizar el movimiento. Es definir cuándo se permite el movimiento, cuándo debe degradarse, cuándo debe detenerse y cómo los humanos pueden volver a entrar de forma segura en el proceso sin crear riesgos de estado ocultos.

Ese cambio altera lo que cuenta como habilidad. Conocer la sintaxis de las instrucciones sigue siendo importante, pero la sintaxis es solo el requisito mínimo. La señal más fuerte es si un ingeniero puede validar el comportamiento bajo fallos, explicar la causalidad de los permisivos y revisar la lógica después de un evento anormal realista.

Es por eso que la simulación es importante. Brinda a los ingenieros un lugar para acumular experiencia en fallos sin pagar la matrícula en hardware dañado o horas de puesta en marcha inseguras.

- IEC 61131-3: Controladores programables — Parte 3: Lenguajes de programación - Familia de normas de seguridad funcional IEC 61508 - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Antecedentes de la política de Industria 5.0 de la UE - Descripción general del gemelo digital (NIST)

Este artículo fue preparado por el equipo de ingeniería de OLLA Lab para apoyar a los profesionales de la automatización en la transición hacia sistemas colaborativos seguros.

El contenido técnico ha sido verificado contra las normas ISO/TS 15066 e IEC 61508, y las metodologías de simulación han sido validadas mediante pruebas de estrés en el entorno de gemelos digitales de OLLA Lab.