IA en Automatización Industrial

Guía del artículo

Cómo programar zonas de seguridad dinámicas para AMR en un PLC con lógica LiDAR

Aprenda cómo los campos de advertencia y protección LiDAR pueden mapearse en la lógica de un PLC para la reducción de velocidad y el comportamiento de parada de los AMR, y cómo utilizar OLLA Lab para ensayar e inspeccionar la ruta de respuesta antes de las pruebas en vivo.

Respuesta directa

Una valla de seguridad virtual para un AMR es una estrategia de velocidad y parada controlada por PLC que mapea las intrusiones en los campos LiDAR a límites de movimiento deterministas. En la práctica, el controlador ajusta el robot desde la velocidad máxima hasta un punto de consigna de velocidad de advertencia o hasta cero, basándose en los campos de protección activos y en la lógica de entrada a prueba de fallos alineada con la norma ISO 3691-4.

Lo que responde este artículo

Resumen del artículo

Una valla de seguridad virtual para un AMR es una estrategia de velocidad y parada controlada por PLC que mapea las intrusiones en los campos LiDAR a límites de movimiento deterministas. En la práctica, el controlador ajusta el robot desde la velocidad máxima hasta un punto de consigna de velocidad de advertencia o hasta cero, basándose en los campos de protección activos y en la lógica de entrada a prueba de fallos alineada con la norma ISO 3691-4.

Una valla de seguridad virtual no es un círculo pintado en el software. Es una respuesta de control determinista ante una intrusión espacial y, si la ruta de respuesta es débil, la valla es imaginaria de la manera incorrecta.

Para los AMR, la distinción útil no es "sensor instalado frente a sensor ausente", sino deceleración en campo de advertencia frente a parada en campo de protección, ejecutada a través de una ruta de escaneo que realmente se puede verificar. La norma ISO 3691-4 establece el objetivo de seguridad; el PLC y la arquitectura de seguridad deciden si la máquina se comporta correctamente cuando alguien entra en su trayectoria.

Métrica de Ampergon Vallis: En la validación interna de un escenario LiDAR de AMR en OLLA Lab, el enrutamiento de la reducción de velocidad en la zona de advertencia a través de una ruta Ethernet estándar no segura añadió suficiente retardo de comando como para producir una superación de zona en 3 de cada 12 pruebas de aproximación a alta velocidad, mientras que el mapeo directo de la señal de advertencia virtual a las entradas del controlador local eliminó dichas superaciones en el mismo conjunto de escenarios. Metodología: 12 pruebas de aproximación simuladas a 2,0 m/s contra una disposición fija de campos de advertencia/protección, comparador de referencia = limitación de velocidad enrutada por red, ventana de tiempo = sesión de validación de marzo de 2026. Esto respalda un punto concreto: el diseño de la ruta de señal afecta materialmente al comportamiento de parada simulado. No establece una cifra de latencia universal para todas las arquitecturas de AMR.

El papel de OLLA Lab aquí es limitado y práctico. Es un entorno de lógica de escalera (ladder) y gemelo digital basado en web para ensayar tareas de validación de alto riesgo —pruebas de lógica, trazado de E/S, inyección de fallos y revisiones al estilo de puesta en marcha— antes de que alguien las intente en un vehículo real. La sintaxis es barata. La capacidad de despliegue seguro no lo es.

¿Qué es una zona de seguridad dinámica en la navegación de un AMR?

Una zona de seguridad dinámica es una envolvente de protección definida por LiDAR que cambia el estado de movimiento permitido del AMR en función de la intrusión detectada y, en algunas arquitecturas, de la cinemática del vehículo, como la velocidad o el ángulo de dirección.

En términos operativos, la "valla de seguridad virtual" no es una sola zona, sino un conjunto de campos. Una disposición típica incluye:

  • un campo libre, donde se permite el desplazamiento comandado,
  • un campo de advertencia, donde se reduce la velocidad, y
  • un campo de protección, donde el movimiento se detiene mediante una acción clasificada de seguridad.

Esa distinción es importante porque no toda intrusión debe producir la misma respuesta de la máquina. Una limitación de velocidad suele ser la respuesta correcta antes de que sea necesaria una parada de emergencia.

¿En qué se diferencian los campos de advertencia y de protección?

El campo de advertencia es una condición de deceleración controlada. El campo de protección es una condición de parada.

| Estado del campo LiDAR | Condición de disparo típica | Respuesta del PLC / Seguridad | Comando de velocidad del AMR | Propósito típico | |---|---|---|---|---| | Zona libre | No se detecta intrusión | Movimiento normal permitido | Referencia al 100%, ej. 2,0 m/s | Desplazamiento normal | | Zona de advertencia | Objeto o persona detectada en campo exterior | Limitar velocidad, a menudo con alarma o baliza | Punto de consigna reducido, ej. 15% | Deceleración controlada y reducción de riesgo | | Zona de protección | Objeto o persona detectada en campo interior | Parada de protección, a menudo vinculada a STO o ruta de parada segura equivalente | 0% | Evitar contacto o aproximación peligrosa |

¿Cómo se relaciona la norma ISO 3691-4 con esta lógica?

La norma ISO 3691-4:2020 aborda los requisitos de seguridad y la verificación de las carretillas industriales sin conductor y sus sistemas. Para este artículo, el punto de ingeniería relevante es sencillo: el AMR debe detectar peligros y realizar la transición a un estado de reducción de riesgos adecuado dentro de una arquitectura validada.

Eso no significa "ponerle un escáner y esperar que el accionamiento se comporte". Significa que la lógica de campo, la categoría de parada, el comportamiento de deceleración y el método de verificación deben ser coherentes como sistema.

¿Qué significa aquí "listo para la simulación" (Simulation-Ready)?

"Listo para la simulación" significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de zona frente al comportamiento real de la máquina antes de que llegue a un AMR en vivo.

Operativamente, esto incluye la capacidad de:

  • observar los cambios de estado del campo LiDAR,
  • rastrear esos cambios en las entradas del PLC o del controlador de seguridad,
  • verificar la referencia de velocidad o el comando de parada resultante,
  • inyectar condiciones anormales como entradas obsoletas o comandos retrasados,
  • comparar el estado de la lógica de escalera con el movimiento simulado del vehículo, y
  • revisar la lógica tras una prueba fallida.

Ese es el umbral útil: no solo dibujar un peldaño, sino validar una ruta de respuesta.

¿Cómo se mapean los datos del campo LiDAR a las entradas del PLC?

Se mapean los datos del campo LiDAR a la lógica del PLC convirtiendo las salidas del escáner en estados de entrada deterministas que representan el estado del campo, y luego utilizando esos estados para controlar la limitación de velocidad o el comportamiento de parada.

En muchos sistemas reales, los escáneres de seguridad exponen el estado del campo a través de salidas clasificadas de seguridad, como pares OSSD, bus de campo seguro o una interfaz de controlador de seguridad. La ruta de hardware exacta varía, pero el principio de control no: la capa de PLC o de seguridad debe recibir un estado inequívoco que pueda evaluarse sin conjeturas interpretativas.

¿Qué debería recibir realmente el PLC?

El controlador debe recibir señales de estado de campo discretas y acotadas, tales como:

  • `LIDAR_CLEAR_OK`
  • `LIDAR_WARNING_ACTIVE`
  • `LIDAR_PROTECTIVE_ACTIVE`
  • `SCANNER_FAULT`
  • `FIELDSET_SELECT_VALID`

Esto es preferible a las abstracciones vagas. Si el nombre de la etiqueta no puede decirle qué estado de la máquina representa, la puesta en marcha terminará haciéndolo por usted.

¿Por qué son importantes las convenciones de entrada a prueba de fallos?

El diseño de entradas a prueba de fallos es importante porque un cable roto, una señal perdida o un fallo del escáner deben inclinar el sistema hacia un estado seguro en lugar de continuar el movimiento.

Para los circuitos de seguridad, esto suele significar diseñar en torno a un comportamiento de lógica de seguridad normalmente cerrada (NC) a nivel funcional, incluso si la interfaz exacta del dispositivo utiliza salidas electrónicas de doble canal en lugar de una cadena NC de contacto seco literal. El principio de ingeniería es el punto: la pérdida de una señal saludable no debe interpretarse como permiso para funcionar.

Un mapeo práctico podría ser así:

  • Canales de escáner saludables presentes = el movimiento puede ser evaluado
  • Campo de advertencia infringido = comando de velocidad reducida
  • Campo de protección infringido = comando de parada
  • Desacuerdo de canales o fallo del escáner = comando de parada
  • Selección de conjunto de campos no válida = parada o inhibición del movimiento, según la evaluación de riesgos

¿Qué pasa con el cambio dinámico de campos?

El cambio dinámico de campos significa que el conjunto de campos LiDAR activo cambia con el estado de la máquina, comúnmente basado en:

  • velocidad actual,
  • ángulo de dirección,
  • dirección de desplazamiento,
  • condición de carga,
  • modo de pasillo o modo de área abierta,
  • estado de acoplamiento o aproximación de precisión.

Aquí es donde el "dinámico" en zona de seguridad dinámica se vuelve real. La envolvente de protección para una maniobra de acoplamiento lenta no debería coincidir necesariamente con la envolvente para el desplazamiento en suelo abierto a máxima velocidad.

¿Cómo se escribe la lógica de escalera para la limitación de velocidad del AMR?

Se escribe la lógica de limitación de velocidad del AMR evaluando el estado de la zona LiDAR activa, asignando una referencia de velocidad acotada para cada condición válida y forzando una ruta de velocidad cero o de parada para cualquier estado de protección o fallo.

La lógica de escalera debe ser lo suficientemente legible como para que otro ingeniero pueda auditarla rápidamente. La lógica adyacente a la seguridad no es el lugar para la astucia ornamental.

### Paso 1: Leer y normalizar las entradas LiDAR

Comience llevando el estado del escáner o del controlador de seguridad a etiquetas nombradas.

Ejemplo de etiquetas de entrada:

  • `LIDAR_Healthy`
  • `Zone_Warning`
  • `Zone_Protective`
  • `AMR_Enable`
  • `Drive_Permissive`
  • `Scanner_Fault`

En esta etapa, normalice los estados contradictorios. Si `Zone_Warning` y `Zone_Protective` están ambos activos, la lógica debe resolverse al estado más restrictivo.

### Paso 2: Crear una decisión de estado de zona única

Utilice bits internos o un registro de estado entero para establecer una condición de movimiento autorizada.

Ejemplo de prioridad de estado:

  1. Fallo o escáner no saludable
  2. Zona de protección activa
  3. Zona de advertencia activa
  4. Zona libre

La prioridad importa porque la lógica de movimiento debe degradarse de forma segura ante la ambigüedad.

### Paso 3: Mover el punto de consigna de velocidad correcto

Utilice valores enteros o reales acotados para controlar la referencia de velocidad del AMR.

Concepto ilustrativo de escalera:

Lenguaje: Diagrama de contactos (Ladder)

// Lógica de parada de protección |---[/]-------------------------------[MOV]---|     LIDAR_Healthy                       0                                             AMR_Speed_Ref

|---[ ]--------------------------------[MOV]---|     Zone_Protective                    0                                             AMR_Speed_Ref

// Lógica de limitación de velocidad en zona de advertencia |---[ ]---[/]--------------------------[MOV]---|     Zone_Warning  Zone_Protective       15                                             AMR_Speed_Ref

// Velocidad normal en zona libre |---[/]---[/]---[ ]--------------------[MOV]---|     Zone_Warning Zone_Protective AMR_Enable                                             100                                             AMR_Speed_Ref

Esto es intencionalmente simple. En una arquitectura de producción, a menudo se separaría la lógica de referencia de velocidad estándar de la ruta de parada clasificada de seguridad y se verificaría la interacción cuidadosamente.

### Paso 4: Separar la limitación de velocidad de la ruta de parada de protección

Un comando de velocidad reducida no es lo mismo que una parada de seguridad.

Esa distinción es fácil de difuminar en un simulador y peligrosa de difuminar en una máquina real. Una referencia de velocidad de cero emitida a través de una lógica de control estándar no es automáticamente equivalente a una función de parada clasificada de seguridad. Dependiendo de la arquitectura, la acción de protección puede necesitar activar la desconexión segura de par (Safe Torque Off), la parada segura 1 (Safe Stop 1) u otra función de seguridad validada bajo los principios de diseño alineados con IEC 62061 / IEC 61508.

### Paso 5: Añadir diagnósticos y enclavamientos donde esté justificado

Los diagnósticos mejoran la puesta en marcha y el aislamiento de fallos.

Las adiciones útiles incluyen:

  • alarma de escáner no saludable,
  • alarma de estado no válido,
  • registro de eventos de superación de campo,
  • registro de causa de parada,
  • requisito de reinicio manual tras una parada de protección, cuando la evaluación de riesgos lo requiera.

Una máquina que se detiene sin decirle por qué solo es cooperativa a medias.

¿Qué comportamiento de parada debería elegir: reducción de velocidad, Categoría 0 o Categoría 1?

El comportamiento de parada correcto depende de la evaluación de riesgos de la máquina, la carga útil, la dinámica y el diseño de la función de seguridad validada.

Un error común es pensar que la parada más rápida es siempre la más segura. No lo es. Una parada de Categoría 0 elimina la energía inmediatamente; en algunos AMR, especialmente aquellos que transportan cargas inestables o líquidos, eso puede crear peligros secundarios a través de la inercia, el chapoteo o la pérdida de frenado controlado.

¿Cuándo es apropiada la reducción de velocidad en la zona de advertencia?

La reducción en la zona de advertencia es apropiada cuando el objetivo es reducir la energía cinética antes de que sea necesaria una parada de protección.

Los usos típicos incluyen:

  • desplazamiento en suelo abierto donde la presencia de peatones es plausible,
  • distancias de parada largas a mayor velocidad,
  • entornos con intrusión intermitente en los campos de detección exteriores,
  • aplicaciones donde la deceleración controlada mejora la estabilidad.

¿Cuándo es necesaria una parada de protección?

Una parada de protección es necesaria cuando la intrusión llega al campo interior o cuando el escáner o la ruta de seguridad ya no pueden garantizar un movimiento seguro.

Esto puede resultar en:

  • Desconexión segura de par (Safe Torque Off),
  • una parada controlada seguida de la eliminación del par,
  • inhibición de movimiento más secuencia de reinicio,
  • u otra respuesta de seguridad validada definida por la función de seguridad de la máquina.

La norma no recompensa la improvisación. Recompensa la prueba.

¿Cómo se valida la lógica LiDAR del PLC frente a un gemelo digital?

Se valida la lógica LiDAR del PLC frente a un gemelo digital comparando el estado del controlador, la velocidad comandada y el movimiento simulado del AMR tanto en condiciones normales como de fallo.

Aquí es donde OLLA Lab se vuelve operativamente útil. Su editor de lógica de escalera basado en navegador, modo de simulación, panel de variables y escenarios 3D/WebXR permiten a los ingenieros probar la causa y el efecto sin exponer a personas o hardware al primer borrador de la lógica.

¿Qué debería probar primero?

Comience con los casos deterministas mínimos:

  • zona libre activa, sin estado de advertencia o protección,
  • intrusión en zona de advertencia a velocidad nominal,
  • intrusión en zona de protección a velocidad nominal,
  • fallo del escáner,
  • pérdida de señal saludable,
  • entrada de estado de zona contradictoria,
  • comportamiento de reinicio y reanudación tras una parada.

Utilice el panel de variables para observar:

  • bits de zona activa,
  • `AMR_Speed_Ref`,
  • estado de habilitación del accionamiento,
  • etiqueta de causa de parada,
  • bits de alarma,
  • cualquier lógica de temporizador o antirrebote.

¿Cómo es una prueba de gemelo digital válida?

Una prueba válida no es "el robot se ralentizó una vez". Es una comparación repetible entre el comportamiento esperado y el observado.

En OLLA Lab, eso significa que puede:

  • alternar o inducir estados de zona,
  • observar la transición de la escalera,
  • inspeccionar el registro de referencia de velocidad,
  • ver la respuesta del AMR en el escenario 3D,
  • repetir la prueba bajo las mismas condiciones,
  • y revisar la lógica cuando la respuesta de la máquina no coincide con la filosofía de control prevista.

Esa es la diferencia entre animación y validación.

¿Por qué las pruebas en vivo en un AMR físico son un mal lugar para aprender esto?

Las pruebas en vivo son costosas, peligrosas y, por lo general, intolerantes a los errores exploratorios.

Un ingeniero junior no debería necesitar descubrir, en un vehículo cargado en movimiento, que una limitación de zona de advertencia se enrutó a través de una ruta lenta o no determinista. OLLA Lab proporciona un entorno de ensayo acotado para exactamente esa clase de error: de alta consecuencia, lo suficientemente común como para importar y difícil de practicar de forma segura en equipos reales.

¿Qué evidencia de ingeniería debería documentar después de las pruebas?

Debe documentar un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla.

Utilice esta estructura:

Resuma la idea de control, no solo el resultado. Por ejemplo: "la reducción en zona de advertencia sobre control de red estándar fue funcionalmente correcta pero demasiado lenta para este caso de velocidad de aproximación".

  1. Descripción del sistema Defina el modo del AMR, la disposición del escáner, la lógica de campo, la interfaz de accionamiento y las suposiciones relevantes.
  2. Definición operativa de "correcto" Establezca exactamente qué debe suceder en los estados libre, de advertencia, de protección y de fallo.
  3. Lógica de escalera y estado del equipo simulado Capture los peldaños relevantes, las etiquetas y el comportamiento correspondiente del AMR en el simulador.
  4. El caso de fallo inyectado Registre la condición anormal introducida, como fallo del escáner, bit de advertencia obsoleto o limitación de velocidad retrasada.
  5. La revisión realizada Muestre qué cambió en la lógica, la secuenciación o la ruta de señal.
  6. Lecciones aprendidas

Esta forma de evidencia es más útil que una imagen de panel pulida sin historial de fallos. La memoria de puesta en marcha se construye a partir de revisiones, no de cosmética.

¿Qué normas y fuentes técnicas son importantes para este tema?

Las normas y marcos técnicos principales son la seguridad funcional y la seguridad de robots móviles, no el optimismo robótico genérico.

Las referencias más relevantes incluyen:

- ISO 3691-4:2020 para carretillas industriales sin conductor y sus sistemas,

  • IEC 62061 para la seguridad funcional de maquinaria,
  • IEC 61508 como marco fundamental de seguridad funcional,
  • manuales de escáneres de seguridad del fabricante para la configuración de campos y el comportamiento de respuesta,
  • y evaluaciones de riesgos específicas de la aplicación que definen las funciones de seguridad requeridas y el comportamiento de parada.

La literatura académica e industrial sobre gemelos digitales y validación basada en simulación también es relevante, pero debe utilizarse con cuidado. La simulación puede mejorar la calidad del ensayo, la visibilidad de los fallos y la preparación de la puesta en marcha; no sustituye la validación formal de seguridad en el sistema real.

¿Dónde encaja OLLA Lab en este flujo de trabajo?

OLLA Lab encaja como un entorno de validación y ensayo con riesgos contenidos para la lógica de escalera, el comportamiento de E/S, la observación de gemelos digitales y la resolución de problemas al estilo de puesta en marcha.

Acotado correctamente, esa es una afirmación sólida y útil. OLLA Lab permite a los ingenieros:

  • construir lógica de escalera en un editor basado en web,
  • ejecutar simulación sin hardware físico,
  • monitorear etiquetas y E/S en el panel de variables,
  • trabajar a través de escenarios tipo AMR en entornos 3D/WebXR,
  • y probar cómo la lógica de control se mapea al comportamiento de la máquina antes de la exposición en el sitio.

No certifica una función de seguridad, no sustituye una evaluación de riesgos formal ni hace que un AMR en vivo sea seguro por asociación. Un simulador es una sala de ensayo, no un sello de cumplimiento.

Conclusión

Programar una valla de seguridad virtual es un problema de control con consecuencias de seguridad. La tarea principal es mapear los estados de los campos LiDAR a respuestas deterministas de la máquina, y luego verificar que el AMR realmente se ralentiza o se detiene según lo previsto en condiciones normales y de fallo.

La distinción duradera es simple: presencia del sensor frente a ruta de respuesta validada. Muchos problemas de integración viven en ese vacío.

Un ingeniero útil en este dominio no solo domina la sintaxis de escalera. Un ingeniero útil puede definir el comportamiento correcto, probarlo frente a equipos simulados, inyectar fallos, revisar la lógica y explicar por qué la ruta de control final es más segura que el primer borrador.

Sigue explorando

Lecturas relacionadas y próximos pasos

References

Transparencia editorial

Esta entrada del blog fue escrita por un ser humano, con toda la estructura central, el contenido y las ideas originales creadas por el autor. Sin embargo, esta publicación incluye texto refinado con la asistencia de ChatGPT y Gemini. La IA se utilizó exclusivamente para corregir gramática y sintaxis, y para traducir el texto original en inglés al español, francés, estonio, chino, ruso, portugués, alemán e italiano. El contenido final fue revisado, editado y validado críticamente por el autor, quien mantiene la responsabilidad total de su precisión.

Sobre el autor:PhD. Jose NERI, Lead Engineer at Ampergon Vallis

Verificación: Validez técnica confirmada el 2026-03-23 por el equipo de QA del laboratorio de Ampergon Vallis.

Listo para la implementación

Usa flujos de trabajo respaldados por simulación para convertir estos conocimientos en resultados medibles para la planta.

© 2026 Ampergon Vallis. All rights reserved.
|