Un gateway IoT industrial es un dispositivo, o un software instalado en un pequeño ordenador industrial, que se sitúa entre las máquinas de la planta y los sistemas que necesitan sus datos. Lee valores de PLC, variadores y medidores en los protocolos que estos hablan, los traduce a un formato que entienden los sistemas de TI y la nube, y los envía de forma segura, normalmente sin que haya que modificar las propias máquinas.

Si necesita los datos de los PLC y de las máquinas en un panel, un historian o un sistema de mantenimiento, la mayoría de las decisiones prácticas giran en torno al gateway. ¿Qué protocolos tiene que leer? ¿Cuánto procesamiento debe hacerse junto a la máquina? ¿Y en qué punto de la red de planta debe situarse para no convertirse en el eslabón débil? Este artículo aborda esas preguntas en ese orden.

Lo esencial

  • Un gateway lee protocolos industriales como Modbus, OPC UA o EtherNet/IP por un lado y publica los datos, a menudo por MQTT, por el otro.
  • También guarda los datos en búfer cuando se cae la conexión y mantiene la red de control cerrada al exterior.
  • El procesamiento edge en el gateway reduce los datos en bruto de alta frecuencia a los valores que importan antes de que salgan de la planta.
  • El hardware de gateway para una fábrica está pensado para armarios eléctricos: carril DIN, 24 V CC, amplio rango de temperatura, puertos serie y varios puertos Ethernet.

¿Cómo funciona un gateway IoT industrial?

Si se sigue un valor a través de un gateway, sus funciones quedan claras. Supongamos que se quiere obtener la corriente del motor de una extrusora, que su PLC ya mide.

El lado southbound del gateway se conecta a la máquina. Tiene drivers para protocolos industriales: Modbus RTU por una línea serie RS-485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET o protocolos propios de fabricante como Siemens S7. Se configura para leer el registro del PLC o el nodo OPC UA que contiene la corriente del motor, y con qué frecuencia, por ejemplo una vez por segundo.

A continuación, el gateway da significado al número en bruto. Un registro Modbus puede contener 1523, que el programador del PLC concibió como 152,3 amperios. El gateway aplica el escalado, añade un nombre, una unidad y una marca de tiempo, y puede descartar o combinar valores según las reglas que se definan.

En esta fase, el sondeo (polling) requiere cierto cuidado. La capacidad de comunicación de un PLC se reparte entre todo lo que se comunica con él, incluidos el HMI y el SCADA. Leer doscientos registros dispersos una vez por segundo, petición a petición, puede ralentizar esas otras conexiones. Una buena configuración de gateway agrupa los registros contiguos en una sola petición, lee los valores que cambian despacio, como las temperaturas, cada pocos segundos en lugar de en cada ciclo, y solo publica un valor cuando varía más de una cantidad fijada, lo que se conoce como banda muerta.

Después viene el lado northbound, por donde salen los datos. La mayoría de los gateways modernos publican por MQTT, un protocolo ligero de publicación/suscripción en el que los dispositivos envían mensajes a un broker bajo topics con nombre y cualquier sistema autorizado puede suscribirse. Algunos también ofrecen HTTPS, OPC UA para otros sistemas de planta o Sparkplug B, una especificación que estandariza los topics y los payloads de MQTT para uso industrial.

Otras dos funciones se cumplen discretamente en segundo plano. El almacenamiento en búfer (store-and-forward) guarda los mensajes cuando se cae la conexión de red y los envía, con sus marcas de tiempo originales, cuando vuelve. Y la seguridad: el gateway inicia conexiones salientes cifradas, así que nada de fuera de la planta necesita una vía de entrada.

Los gateways adoptan muchas formas, desde flujos de Node-RED en un PC industrial hasta Modbus2MQTT, el hardware de Moxa y Advantech o software edge comercial como Ignition Edge. Cualquiera de ellos se conecta a Kilo apuntando su salida MQTT a un broker: MQTT en la nube, que Kilo aprovisiona por usted y que solo acepta conexiones cifradas con TLS, o su propio broker mediante MQTT externo. Después se decide cómo encuentra cada mensaje su dispositivo en Kilo: por topic o por un ID de dispositivo dentro del payload JSON. Si sus máquinas exponen un servidor OPC UA, un puente que se suscribe a sus nodos y publica JSON por MQTT es la vía habitual para conectar equipos OPC UA de este modo.

Cómo diseñar una red IoT industrial

Una red IoT industrial tiene que hacer dos cosas que tiran en direcciones opuestas: sacar los datos de la planta con facilidad y mantener protegido el sistema de control. Una arquitectura IoT industrial por capas lo resuelve decidiendo dónde se ubica cada dispositivo y en qué sentido puede circular el tráfico.

La distribución a la que acaban llegando la mayoría de las plantas es esta, de la máquina hacia fuera:

  • Redes de máquina y de célula. PLC, variadores, E/S remotas y HMI se comunican por su propio bus de campo o por Ethernet industrial. Aquí es donde se produce el control en tiempo real, y nada de esta capa debería depender de la nube.
  • Red de control de planta. Los servidores SCADA, las estaciones de ingeniería y los sistemas de línea conectan las células. Unos cortafuegos la separan de la red de oficina.
  • DMZ industrial. Una zona intermedia entre la red de control y la red corporativa. El gateway suele situarse aquí, o a caballo de la frontera con un puerto de red a cada lado, para poder leer de los controladores y publicar hacia fuera sin enrutar tráfico entre ambas.
  • Red corporativa y nube. El ERP, los sistemas de mantenimiento, los paneles y las plataformas en la nube reciben los datos.

Las reglas de tráfico se derivan de esta distribución. El gateway inicia las conexiones hacia los controladores en el interior y hacia el broker en el exterior; nada del exterior inicia una conexión hacia dentro. Si un sistema en la nube necesita enviar una orden de vuelta a un equipo, esa orden debe llegar igualmente a través de la propia conexión saliente del gateway, y es el controlador local de la máquina el que decide si la acepta.

Los sensores inalámbricos añaden un camino paralelo. Los sensores con batería que vigilan la vibración o la temperatura en máquinas antiguas suelen informar a un gateway LoRaWAN o a una estación base mioty, que reenvía sus mensajes a un servidor de red. Ese camino no toca en ningún momento la red de control, y esa es una de las razones por las que se recurre a él a menudo para modernizar equipos antiguos.

Una comprobación práctica del diseño consiste en dibujar todas las flechas en una sola hoja: cada dispositivo, en qué red está y en qué sentido se abre cada conexión. Si alguna flecha va de internet hacia la red de control, hay que revisar el diseño.

Edge computing vs nube en el IoT industrial

El edge computing en el IoT industrial consiste en procesar los datos en el gateway o cerca de él, antes de que salgan de la planta. La nube, o un centro de datos central, se encarga de lo que necesita datos de muchas máquinas o emplazamientos. La mayoría de los proyectos usan ambos, así que la pregunta útil es qué tarea corresponde a cada lado.

Los datos de vibración son el mejor argumento a favor del procesamiento en el edge. Un sensor de vibración muestreado 10 000 veces por segundo genera 864 millones de muestras al día. A dos bytes por muestra, son unos 1,7 GB al día para un solo eje de medida en una sola máquina. Enviar eso a la nube en una planta con cien rodamientos monitorizados no es ni barato ni útil. Un dispositivo edge que calcula una vez por minuto la velocidad de vibración RMS y unos cuantos valores espectrales envía en cambio 1440 conjuntos de valores al día, y guarda localmente la forma de onda en bruto para el analista que la necesite.

El mismo razonamiento se aplica a los valores de proceso corrientes. Un nivel de depósito que se lee cada segundo pero solo se publica cuando varía más de un 0,5 % puede enviar unos cientos de mensajes al día en lugar de 86 400, sin perder nada que fuera a motivar una actuación. Elegir esas bandas muertas señal a señal es uno de los ajustes edge más útiles, y uno de los que más a menudo se quedan con el valor por defecto.

Tarea Mejor en el edge Mejor en la nube
Reducir señales de alta frecuencia a indicadores Sí
Almacenar en búfer durante los cortes de red Sí
Reacciones locales rápidas (milisegundos) Sí, aunque el control sigue en el PLC
Comparar máquinas entre líneas y emplazamientos Sí
Histórico a largo plazo e informes Sí
Alertas que deben llegar a personas estén donde estén Sí
Actualizar la lógica de muchos emplazamientos a la vez Sí

De la tabla se desprenden dos reglas prácticas. Todo lo que tenga que funcionar cuando se cae internet corresponde al edge o al PLC. Todo lo que necesite una visión de conjunto de varias máquinas, emplazamientos o meses corresponde al nivel central. Las funciones de seguridad no corresponden a ninguno de los dos; se quedan en controladores de seguridad dedicados.

¿Qué hardware IoT industrial se necesita?

El hardware IoT industrial de un proyecto de planta suele reducirse a tres tipos de dispositivo: gateways para los equipos cableados, sensores para lo que todavía no se mide y gateways de radio para los sensores inalámbricos.

Para un gateway que lea PLC, conviene buscar características pensadas para un armario de control y no para una oficina:

  • montaje en carril DIN y entrada de alimentación de 24 V CC, para que quepa junto al PLC y comparta su alimentación;
  • un rango de temperatura de funcionamiento acorde con el armario, que en una planta calurosa puede superar los 50 °C;
  • puertos serie RS-485 para los equipos Modbus RTU más antiguos, y al menos dos puertos Ethernet para mantener separadas la red de control y la de salida;
  • almacenamiento suficiente para guardar en búfer varios días de datos durante un corte;
  • arranque seguro y actualizaciones de firmware firmadas, para que nadie pueda reprogramar el gateway sin que se note;
  • un fabricante que publique actualizaciones de seguridad durante toda la vida útil del dispositivo.

El gateway no tiene por qué ser un equipo dedicado. El software de gateway también puede ejecutarse en un PC industrial que ya esté en el armario o en una máquina virtual de un servidor de planta, algo adecuado para las plantas que estandarizan una única plataforma de hardware para muchos usos. La contrapartida está en quién se responsabiliza: un gateway dedicado tiene una sola función y un único ciclo de actualizaciones, mientras que el hardware compartido exige que OT y TI se pongan de acuerdo en quién lo parchea y cuándo.

Muchas máquinas tienen además señales que nadie mide todavía: la temperatura de un rodamiento, el nivel de un depósito, el estado de marcha de un motor. Para ellas, los sensores inalámbricos con batería evitan tender cable nuevo, y un solo gateway de radio montado en alto en la nave suele bastar para cubrir todo un edificio.

Los equipos antiguos que solo hablan Modbus también pueden conectarse mediante pequeños convertidores que leen sus registros y transmiten los valores. Kilo Electronics tiene dispositivos Modbus para este tipo de conexión.

Preguntas frecuentes sobre gateways IoT industriales

¿Qué diferencia hay entre un gateway IIoT y un router?

Un router reenvía paquetes de red entre redes sin entender su contenido. Un gateway IIoT entiende los protocolos industriales: lee valores concretos de las máquinas, los convierte y los etiqueta, y los publica en un formato nuevo. Algunos dispositivos combinan ambas funciones en un solo equipo.

¿Puede un PLC hacer de gateway IoT industrial?

En parte. Muchos PLC recientes incluyen un servidor OPC UA o un cliente MQTT, así que pueden compartir datos directamente. Aun así, sigue siendo habitual un gateway independiente cuando una planta tiene controladores de varios fabricantes o generaciones, porque ofrece un único punto de conexión coherente y deja que el procesador del PLC se centre en el control.

¿Los gateways IoT industriales son compatibles con Sparkplug B?

Muchos sí. Sparkplug B, mantenido por la Eclipse Foundation, define una estructura de topics, un formato de payload binario compacto y mensajes de «birth» y «death» que avisan a los suscriptores cuando un dispositivo se conecta o se desconecta. Ese conocimiento del estado es su principal ventaja frente a MQTT a secas con JSON personalizado.

Elija una máquina cuyo PLC ya exponga datos por Modbus TCP u OPC UA e instale junto a ella un gateway que publique cuatro tags por MQTT: corriente del motor, velocidad, una temperatura y un código de fallo. Represéntelos en Kilo con el plan gratuito y luego desconecte durante una hora el cable de salida del gateway para comprobar si su búfer envía las lecturas que faltan cuando vuelve la conexión.