Puente grúa con Computación en el Borde: práctica de OPC UA
Puente grúa inteligente y computación en el borde: práctica de ingeniería en adquisición de datos OPC UA y conversión de protocolos. El sistema de puerta de enlace inteligente y computación en el borde del puente grúa es el nexo clave entre la capa de dispositivo y la capa de información: realiza conversión de protocolos, adquisición de datos, computación en el borde y reanudación de transmisión tras desconexión entre el PLC y el variador de frecuencia, por un lado, y el MES, SCADA y la plataforma en la nube, por el otro.
El sistema de puerta de enlace inteligente y computación en el borde del puente grúa constituye el nexo fundamental entre la capa de dispositivo y la capa de información: gestiona la conversión de protocolos, la adquisición de datos, la computación en el borde y la reanudación de transmisión tras desconexión entre el PLC y el variador de frecuencia, por un lado, y el MES, SCADA y la plataforma en la nube, por el otro. Kelude Industrias Pesadas, basándose en la puerta de enlace industrial IoT2050 de Siemens y en su plataforma propia de datos en el borde, ha desarrollado una arquitectura estandarizada para la adquisición de datos y conversión de protocolos en puentes grúa. Esta arquitectura soporta la interconversión en tiempo real de cinco protocolos: PROFINET, OPC UA, Modbus TCP, MQTT y REST API. Una única puerta de enlace puede adquirir simultáneamente datos operativos de 8 puentes grúa, con una latencia de procesamiento en el borde inferior a 50 ms y cero pérdida de datos en la reanudación de transmisión tras desconexión. Este artículo expone de forma sistemática esta práctica de ingeniería, desde la selección de hardware, la configuración de la pila de protocolos y el modelado de datos hasta el despliegue y la operación de mantenimiento.
Selección de hardware para puerta de enlace industrial y arquitectura de sistema
El componente de hardware central del sistema de adquisición de datos del puente grúa es la puerta de enlace industrial, que se instala en el armario de control del puente grúa o en una estación de control de campo adyacente. Se conecta hacia arriba con la red a nivel de taller y, hacia abajo, directamente con el PLC del puente grúa a través de una interfaz PROFINET. En su solución estandarizada, Kelude Industrias Pesadas selecciona la puerta de enlace industrial IoT2050 de Siemens como plataforma de hardware principal. Este dispositivo incorpora un procesador ARM Cortex-A72 de cuatro núcleos (1,5 GHz) y 4 GB de RAM DDR4, integra dos puertos Ethernet RJ45 Gigabit, dos interfaces USB 3.0 y una ranura para tarjeta SD de grado industrial. Ejecuta Siemens Industrial Edge y Edge Apps basadas en contenedores Linux. El IoT2050 admite un rango de temperatura de funcionamiento de -20 °C a 60 °C, ofrece un Grado de Protección IP20 y es apto para montaje en carril DIN dentro del armario de control.
| Parámetro | SiemensIOT2050 | Solución de sustitución nacional |
|---|---|---|
| procesador | ARM Cortex-A72 1.5GHzQuad-core | RK3568 2.0GHzQuad-core |
| Memoria RAM | 4GB DDR4 | 4GB LPDDR4 |
| Almacenamiento | 32GB eMMC + SDRanura para tarjeta | 64GB eMMC + M.2 SSD |
| Ethernet | 2×GigabitRJ45 | 2×GigabitRJ45 |
| Soporte de protocolos | PROFINET/OPC UA/Modbus/MQTT | PROFINET/OPC UA/Modbus/MQTT |
| Entorno operativo | Industrial Edge / Yocto Linux | Debian / Ubuntu |
| Temperatura de trabajo | -20°C~60°C | -20°C~70°C |
| Método de montaje | DINCarril DIN/Montaje en pared | DINCarril DIN/Montaje en pared |
La arquitectura del sistema se despliega en tres capas: extremo, borde y nube. La capa de dispositivos en el extremo incluye el PLC S7-1500, el variador de frecuencia G120, los módulos de interfaz de encoder y el conjunto de sensores dentro del armario de control de cada puente grúa. El PLC publica datos operativos al gateway mediante PROFINET IO en ciclos de 10 ms, mientras que el variador de frecuencia G120 publica la velocidad de rotación del motor, la corriente, la temperatura y los códigos de fallo a través del perfil de driver PROFINET. La capa de borde incorpora un gateway IOT2050 que ejecuta cuatro Edge Apps principales: un servidor OPC UA (que agrega los datos UA de todos los nodos PLC), un motor de conversión de protocolos (PROFINET, OPC UA, Modbus, MQTT), una unidad de procesamiento de datos en el borde (cola de caché, reanudación de transferencia tras interrupción y compresión de datos) y un módulo de seguridad de datos (cifrado TLS y lista de control de acceso). La capa de nube incluye el sistema de ejecución de fabricación MES, la plataforma de monitoreo SCADA y el panel de operación y mantenimiento con Gemelo Digital, que se comunican con el gateway de borde mediante clientes OPC UA o un broker MQTT.
Configuración del servidor OPC UA y modelado de nodos de datos
OPC UA es el protocolo de comunicación central que conecta el PLC del puente grúa con los sistemas de nivel superior. Kelude ha diseñado un modelo de información estandarizado para el puente grúa en el servidor OPC UA del gateway de borde, agrupando y nombrando los nodos de datos del sistema de control del puente grúa según la especificación OPC UA for Machinery (IEC 62541-100). Esto garantiza una estructura de datos coherente entre distintos puentes grúa, de modo que los sistemas MES y SCADA no necesitan adaptarse individualmente a cada equipo.
El modelo de información se organiza en cuatro niveles jerárquicos. El primer nivel es el de sitio (Site), que corresponde al taller o nave industrial: la ruta de nodo "/Site/Workshop_01" contiene el conjunto de todos los puentes grúa de ese taller. El segundo nivel es el de área (Area), que corresponde al grupo de puentes grúa en un mismo vano o puesto de trabajo: la ruta "/Area/Bay_A" incluye los 3 puentes grúa de ese vano. El tercer nivel es el de dispositivo (Device), que corresponde a un puente grúa individual: la ruta "/Device/Crane_01" contiene todos los grupos de datos de ese equipo. El cuarto nivel es el de bloque funcional (Function), que corresponde a las distintas unidades funcionales del sistema de control del puente grúa: el grupo de control de movimiento Motion (modo de operación, posición objetivo, posición real, velocidad, estado de aceleración), el grupo de variadores Drive (corriente del motor de cada mecanismo, velocidad de rotación, temperatura, estado de funcionamiento, códigos de alarma), el grupo de frenos Brake (estado abierto/cerrado de los dos sistemas de frenado, corriente electromagnética, contador de desgaste, indicador de falta de sincronización), el grupo de estado de seguridad Safety (estados STO/SLS/SBC/SDI, contador de paradas de emergencia, registro de eventos de seguridad) y el grupo de diagnóstico Diagnosis (tiempo de funcionamiento del sistema, cola de códigos de fallo, fecha y hora del PLC).
Los nodos de datos se nombran en formato camelCase, e incluyen la definición del tipo de datos y una descripción. Motion.ActualPosition (Int32, unidad mm), Motion.Speed (Real, unidad m/s), Drive.Current_A (Real, unidad A), Brake.Status_A (Boolean, True = freno abierto / freno cerrado), Brake.UnsyncCount (UInt16), Safety.STO_Active (Boolean), Safety.EventCount (UInt32). Durante la implementación en campo, se realiza el mapeo de direcciones y la validación de tipos de datos de los 26 nodos OPC UA estándar de cada puente grúa. Una vez completado el mapeo, se utiliza la herramienta UA Expert para verificar la legibilidad y la corrección de los tipos de datos de todos los nodos.
| Grupo funcional | Número de nodos | Nodo típico | Tipo de datos | AdquisiciónFrecuencia |
|---|---|---|---|---|
| Control de movimientoMotion | 6 | Position/Speed/Mode | Int32, Real, UInt16 | 50ms |
| Variador de FrecuenciaDrive | 8 | Current/Temp/Status | Real, UInt16, String | 100ms |
| FrenoBrake | 5 | Status/Current/Wear | Boolean, Real, UInt32 | 200ms |
| Estado de seguridadSafety | 4 | STO/SLS/EventLog | Boolean, UInt32 | 20ms |
| DiagnósticoDiagnosis | 3 | Uptime/FaultQueue | UInt32, String[] | 1s |
Capa de conversión de protocolos: de PROFINET a OPC UA, Modbus y MQTT
La conversión de protocolos es la función principal de la pasarela perimetral. El PLC del puente grúa publica datos en la pasarela mediante PROFINET IO en tiempo real (ciclo de 10 ms). El motor de conversión de protocolos de la pasarela analiza los datos PROFINET IO a un formato de datos interno unificado y, a continuación, los reempaqueta según los requisitos de destino de cada protocolo. La pasarela ejecuta simultáneamente tres salidas de protocolo: un servidor OPC UA, un servidor Modbus TCP y un cliente MQTT, que dan servicio respectivamente a los sistemas MES, SCADA y a la Plataforma en la Nube.
Configuración de la salida OPC UA. El servidor OPC UA de la pasarela se basa en la pila de código abierto open62541 y admite el protocolo binario OPC UA (puerto predeterminado 4840) y el protocolo HTTPS (puerto 443). La política de seguridad del servidor se configura con cifrado y firma Basic256Sha256 (SecurityMode=SignAndEncrypt). La autenticación de clientes emplea un modo de lista blanca de certificados X.509: solo se permite que los clientes OPC UA cuyo certificado esté en la lista de confianza de la pasarela se conecten y lean datos. El servidor publica los 26 nodos estándar del puente grúa mencionados anteriormente. El cliente UA (por ejemplo, el Cliente OPC UA del sistema MES) descubre toda la estructura de nodos mediante la operación Browse y, a continuación, lee los datos en tiempo real de forma masiva mediante suscripciones, con un intervalo de muestreo mínimo de 50 ms.
Configuración de la salida Modbus TCP. La pasarela asigna los datos estándar del puente grúa a la tabla de registros Modbus. Las direcciones de registro se asignan consecutivamente a partir de 40001: 40001~40006 corresponden a los 6 registros del grupo funcional Motion, 40007~40014 a los 8 registros del grupo funcional Drive, 40015~40019 a los 5 registros del grupo funcional Brake y 40020~40023 a los 4 registros del grupo funcional Safety. Cada registro ocupa 2 bytes; los datos de 32 bits (como Real, Int32) ocupan dos registros consecutivos. El sistema SCADA actúa como Maestro Modbus TCP (puerto predeterminado 502) y sondea periódicamente las direcciones de registro, pudiendo obtener de forma masiva los datos de un rango de direcciones consecutivo en una sola instrucción de lectura, reduciendo así la sobrecarga de red.
Configuración de la salida MQTT. La unidad de procesamiento de datos perimetral de la pasarela se conecta al Broker MQTT de la Plataforma en la Nube (por ejemplo, EMQX o VerneMQV, puerto predeterminado 8883) como cliente MQTT, utilizando comunicación cifrada TLS. Los temas MQTT se diseñan según la jerarquía de equipos del puente grúa, empleando una estructura de tres niveles: topic/workshop_id/crane_id/function/parameter, por ejemplo, "krunde/workshop01/crane_01/motion/position". La publicación de datos utiliza QoS=1 para garantizar la entrega al menos una vez. La carga útil de datos se encapsula en formato JSON, incluyendo tres campos: marca de tiempo, valor del dato y marca de calidad. La frecuencia típica de publicación MQTT es de 1s/vez, con un volumen de datos de aproximadamente 200 bytes/vez/puente grúa. El tráfico de red para 8 puentes grúa en funcionamiento simultáneo es de aproximadamente 1.6 KB/s.
Procesamiento de datos perimetral y reanudación de la transmisión
La recopilación fiable de los datos de funcionamiento del puente grúa depende de la caché de datos local y del mecanismo de reanudación de la transmisión de la pasarela perimetral. El entorno de red industrial — especialmente las interrupciones del WiFi debidas al movimiento del puente grúa a lo largo del carril o las interferencias armónicas de los variadores de frecuencia en el taller — puede provocar interrupciones breves en la conexión de red entre la pasarela y la Plataforma en la Nube. Para ello, la plataforma de datos perimetral de Kelude ha diseñado un mecanismo de caché de búfer circular y de reanudación de la transmisión en el punto de interrupción.
La capa de caché de datos utiliza una arquitectura de caché de dos niveles: memoria + tarjeta SD. El primer nivel es un búfer circular en memoria (Ring Buffer) con capacidad para 10000 registros de datos (a 200 bytes por registro, ocupa aproximadamente 2 MB de memoria). La latencia de escritura en la caché de memoria es inferior a 1 ms y se implementa mediante un modelo productor-consumidor: los subprocesos de salida OPC UA/Modbus/MQTT actúan como consumidores que leen los datos de la caché y los reenvían, marcándolos como procesados tras el éxito del reenvío. El segundo nivel es una caché de archivos en tarjeta SD. Cuando la interrupción de la red provoca un backlog de datos que supera el umbral de memoria (80% por defecto), la unidad de procesamiento de datos perimetral escribe automáticamente los datos acumulados en archivos de caché en la tarjeta SD. La capacidad de la caché SD depende del tamaño de la tarjeta (se recomienda una tarjeta SD industrial de 32 GB). Para un máximo de 7 días de caché, se necesitan aproximadamente 1.2 GB de espacio; una tarjeta SD de 32 GB puede almacenar más de 180 días de datos de funcionamiento del puente grúa.
La estrategia de reanudación de la transmisión tras una interrupción se divide en tres casos. Interrupción breve (≤30 segundos): la caché de memoria es suficiente para contener los datos acumulados; tras la recuperación de la red, la conexión TCP del subproceso de salida del protocolo se reconecta automáticamente y envía rápidamente los datos de la caché en orden de marca de tiempo. Interrupción media (30 segundos a 2 horas): tras el desbordamiento de la memoria, los datos se transfieren automáticamente a la caché de archivos en la tarjeta SD; al recuperarse la red, el módulo de sincronización de archivos de reanudación escanea los archivos de caché no enviados en la tarjeta SD y los sube a una velocidad de 500 registros por segundo (lo que requiere un ancho de banda de subida de aproximadamente 212 KB/s, satisfecho por una red de taller de 10 Mbps). Interrupción larga (≥2 horas): cuando la caché SD está llena (el número de archivos de caché alcanza el umbral de alarma), la plataforma perimetral ejecuta automáticamente una política de eliminación de caché — elimina los registros más antiguos según el FIFO de marca de tiempo — y simultáneamente activa una alarma local que se envía al Panel de operación del puente grúa para notificar al personal de mantenimiento. Tras la recuperación de la red, la pasarela informa al sistema MES del rango de marcas de tiempo de los registros faltantes, y el MES decide si es necesario recopilarlos de los registros históricos del PLC.
Seguridad de datos y control de acceso
La seguridad de los datos de la plataforma de datos perimetral del puente grúa se adhiere a la norma de seguridad de redes industriales ISA/IEC 62443. Las medidas de seguridad se dividen en tres capas: seguridad de la transmisión, control de acceso y registro de auditoría.
La capa de seguridad de la transmisión activa el cifrado TLS 1.3 en todos los enlaces de comunicación externos. El servidor OPC UA está configurado con comunicación cifrada y firmada Basic256Sha256, y se prohíben las conexiones sin cifrado (SecurityPolicy=None está prohibido). El cliente MQTT utiliza TLS para conectarse al Broker MQTT; la verificación del certificado del servidor habilita la verificación de la cadena CA — la pasarela tiene precargado el certificado CA de fábrica y se prohíben las conexiones con certificados autofirmados. Dado que Modbus TCP no admite cifrado por sí mismo, se utiliza un túnel VPN (WireGuard) para establecer un canal cifrado entre la pasarela perimetral y el servidor SCADA, transmitiendo los paquetes Modbus dentro del túnel. El túnel VPN utiliza autenticación mediante clave precompartida (PSK), que se rota cada 90 días.
La capa de control de acceso implementa un modelo de control de acceso basado en roles (RBAC). Se definen tres roles de usuario: Administrador del sistema (Admin), Operario (Operator) e Ingeniero de mantenimiento (Engineer). Cada rol tiene permisos específicos sobre los nodos de datos y las funciones de configuración de la pasarela. La autenticación de usuarios se realiza mediante nombre de usuario y contraseña, con bloqueo automático de la cuenta tras 5 intentos fallidos. Todas las operaciones de acceso a datos y configuración se registran en el registro de auditoría local, incluyendo la marca de tiempo, el usuario, la dirección IP de origen y la operación realizada. El registro de auditoría se almacena en un formato de solo anexión y se exporta periódicamente al sistema MES para su archivado y monitorización de seguridad.
Los certificados OPC UA de los tres roles se cargan y vinculan a través de la interfaz de gestión web del gateway. Cuando un cliente UA se conecta, el gateway verifica el campo Common Name del certificado del cliente para determinar el rol y aplicar los permisos correspondientes. El control de acceso MQTT se implementa mediante reglas ACL. Cada cliente MQTT se autentica con nombre de usuario y contraseña, y las reglas ACL restringen el rango de temas MQTT que el cliente puede publicar o suscribir.
La capa de registro de auditoría registra todos los eventos de acceso a datos. Cada conexión y desconexión de un cliente OPC UA, cada suscripción/cancelación de suscripción de un cliente MQTT, y cada solicitud de lectura Modbus TCP que supere las 20 veces/segundo (lo que activa la limitación de velocidad de conexión) se registra en el archivo de registro de auditoría del gateway. El formato del registro incluye marca de tiempo, dirección IP de origen, tipo de protocolo, tipo de operación y resultado de la operación. El registro de auditoría se rota automáticamente, con un período de retención de 90 días. Los archivos de registro se almacenan cifrados y solo el rol Admin puede descargarlos y verlos a través de la interfaz de gestión web del gateway.
Despliegue, puesta en marcha y gestión de operaciones
El despliegue y la puesta en marcha del gateway perimetral para puentes grúa siguen un proceso estandarizado. El primer paso es la instalación del hardware: el IOT2050 se monta en el carril DIN del Armario de Control (ocupando 4 anchos de módulo estándar). El gateway se conecta mediante un cable de red blindado CAT6A al switch de red PROFINET del Taller, y mediante otro cable de red al switch de la red de oficina del Taller (para la carga MQTT y la gestión remota). La Alimentación Eléctrica del gateway utiliza 24 V CC desde la Fuente de Alimentación Conmutada del Armario de Control, con un Filtro EMC (corriente nominal 0,5 A) instalado en la entrada de alimentación.
El segundo paso es el despliegue del entorno de software perimetral: las imágenes de las Edge Apps se envían de forma remota al IOT2050 a través de la plataforma Siemens Industrial Edge Management (IEM). El orden de despliegue de las Apps es: entorno de ejecución base (Docker y configuración de red), App del servidor OPC UA, App del motor de conversión de protocolo, App de procesamiento de datos perimetrales y App del módulo de seguridad de datos. Después de cada despliegue, se ejecuta un script de autocomprobación para verificar el estado del contenedor y el estado del puerto de escucha. En la solución nacional, los archivos de configuración de Docker Compose y las imágenes se envían por SSH, y se ejecuta docker-compose up -d para un despliegue con un solo comando.
El tercer paso es la verificación de la comunicación OPC UA: se utiliza UA Expert para conectarse al servidor OPC UA del gateway (puerto predeterminado 4840), se importa el certificado de cliente emitido por la CA, se verifica que la función Browse pueda recorrer los 26 nodos estándar y se ejecuta una operación de lectura en cada nodo para confirmar que el tipo de datos y el rango de valores son correctos. Se utiliza la función Subscription de UaExpert para suscribirse al nodo Motion.Position (intervalo de muestreo 50 ms), se observa si la actualización de datos en tiempo real es estable y se verifica que la tasa de pérdida de paquetes de suscripción sea ≤ 0,1%.
El cuarto paso es la verificación de la carga de datos: en el cliente de prueba MQTT, se suscribe al tema "krunde/workshop01/+/motion/position" y se observa si el formato JSON de los datos publicados por el gateway es correcto. Se utiliza Modbus Slave para simular el Sistema SCADA y leer las direcciones de registro 40001~40023, verificando que los valores de datos coinciden con los mostrados en el lado del PLC. Prueba de desconexión de red: se desconecta el cable de red de la red operativa del gateway durante 30 segundos, se verifica que el archivo de caché de la tarjeta SD se crea automáticamente, y tras la recuperación de la red, el módulo de reanudación de transferencia en punto de interrupción carga automáticamente los datos en caché, confirmando en el lado del MES que no hay pérdida de datos y que las marcas de tiempo son continuas.
El quinto paso es la configuración de la gestión de operaciones: en la interfaz de gestión web del gateway (HTTPS://192.168.x.x:8443) se configuran las reglas de alarma: tiempo de espera de conexión del cliente OPC UA (30 segundos por defecto) que activa una alerta por correo electrónico; pérdida de latido del Broker MQTT (sin PINGRESP durante 60 segundos por defecto) que activa una alerta; uso de la caché de la tarjeta SD superior al 80% que activa una alerta; uso de CPU del gateway superior al 80% durante 5 minutos que activa una alerta. Todas las alertas se envían por SMTP al correo del ingeniero de operaciones. Además, la luz indicadora LED del Panel de operación local (verde para normal, rojo para alarma, amarillo para mantenimiento) proporciona una indicación de estado en el sitio.
