Un gateway edge IIoT es el dispositivo que convierte una fábrica llena de PLC, contadores y variadores en un flujo de mensajes MQTT estructurados que el resto de la empresa puede aprovechar. Este artículo explica las cuatro tareas que realiza todo gateway (traducción de protocolos, búfer, seguridad y edge computing), muestra una arquitectura de referencia y te da una checklist práctica para elegir uno.
Por qué las plantas industriales necesitan gateways edge
Los equipos industriales se diseñaron para hablar con otros equipos de la misma red, no con la nube. Una planta típica, ya esté en Monterrey, Bogotá o Bilbao, mezcla Modbus RTU sobre RS485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET y protocolos propios de cada fabricante, a menudo en redes deliberadamente aisladas de la oficina y de internet. Esos protocolos son en su mayoría de petición-respuesta: un cliente tiene que consultar a cada dispositivo por cada valor.
Los sistemas en la nube, los paneles y la analítica esperan otra cosa: datos seguros, salientes y orientados a eventos, con nombres y unidades coherentes. El gateway es el traductor y el puesto de control entre ambos mundos. Sin él, cada aplicación que quisiera datos de máquina necesitaría sus propios drivers, su propia ruta de red hacia la red OT y su propia carga de sondeo sobre controladores delicados.
Las cuatro funciones principales de un gateway edge IIoT
1. Traducción de protocolos y modelado de datos
El gateway consulta o se suscribe a los dispositivos en sus protocolos nativos y vuelve a publicar los datos por MQTT. Un buen gateway hace algo más que copiar registros: aplica escalado, unidades y nombres, de modo que 40001 = 2351 se convierte en {"temperature_c": 23.51} en un topic con significado como acme/plant1/packaging/line2/filler/temperature.
Ese paso de nomenclatura es donde un gateway contribuye a un Unified Namespace. Si cada gateway publica en una jerarquía compartida de estilo ISA-95 (empresa, planta, área, línea, celda), los consumidores pueden encontrar los datos sin saber qué gateway o protocolo los generó. Las rutas de traducción concretas se tratan en las guías de Modbus TCP a MQTT y de gateway OPC UA a MQTT.
2. Búfer y store-and-forward
Las redes de planta y los enlaces WAN fallan. Un gateway que simplemente descarta datos mientras el broker no está accesible deja huecos en el histórico que a menudo es imposible rellenar. Los gateways industriales encolan los mensajes localmente, en disco y no solo en memoria, y los reenvían en orden cuando vuelve la conexión. Los detalles de diseño (tamaño del búfer, marcas de tiempo, ritmo de reenvío) están en store and forward para MQTT.
3. Frontera de seguridad
El gateway suele ser el único dispositivo que toca tanto la red OT como una red externa. Eso lo convierte en el lugar adecuado para aplicar varias reglas:
- Solo conexiones salientes. El gateway abre una conexión TLS hacia el broker; nada en internet inicia conexiones hacia la planta.
- Aislamiento de credenciales. Solo el gateway guarda las credenciales del broker. Los PLC nunca.
- Solo lectura por defecto. Escribir consignas desde la nube debería habilitarse explícitamente por tag, si es que se habilita.
- Segmentación de red. Dos interfaces de red, una por zona, sin enrutamiento entre ellas, o la ubicación en una DMZ industrial.
4. Edge computing
Parte de la lógica debe estar junto a la máquina: filtrar ruido, calcular promedios, detectar cruces de umbral o ejecutar alarmas que deben funcionar aunque la nube no esté disponible. El cálculo en el edge más valioso suele ser también el más simple: report by exception, que publica un valor solo cuando cambia de forma significativa y puede reducir drásticamente el tráfico frente al sondeo a intervalos fijos.
Arquitectura de referencia
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
El gateway publica en topics que siguen la jerarquía de la planta. Un payload típico tiene este aspecto:
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Incluir en cada mensaje una marca de tiempo de origen, un indicador de calidad y el ID del gateway facilita muchísimo los reenvíos desde el búfer y la resolución de problemas.
Cómo elegir un gateway edge IIoT: checklist de selección
| Criterio | Preguntas que hacer |
|---|---|
| Drivers de protocolo | ¿Admite todos los protocolos que hay hoy en tu planta, incluido el serie heredado? ¿Los drivers se licencian por protocolo o por tag? |
| Calidad del cliente MQTT | ¿MQTT 3.1.1 y 5? ¿TLS con CA personalizada? ¿QoS, retained messages, Last Will y keep alive configurables? |
| Opciones de payload | ¿JSON plano, Sparkplug B o ambos? ¿Puedes controlar por completo la estructura de topics? |
| Store-and-forward | ¿Respaldado en disco? ¿Cuánto? ¿Reenvío ordenado? ¿Reenvío con limitación de ritmo? |
| Lógica en el edge | ¿Bandas muertas, escalado, scripting o contenedores para código propio? |
| Hardware | ¿Carril DIN, amplio rango de temperatura, sin ventilador, entrada de alimentación industrial, puertos serie? |
| Gestión | ¿Configuración remota y actualizaciones de firmware sin abrir puertos entrantes en el firewall? |
| Seguridad | ¿Arranque seguro, actualizaciones firmadas, acceso local basado en roles, interfaces de red separadas? |
| Ciclo de vida | ¿Cuánto tiempo le dará soporte el fabricante y puedes exportar la configuración si lo sustituyes? |
Tipos habituales de gateway
- Gateways industriales dedicados. Equipos de carril DIN diseñados para este fin, con una herramienta de configuración del fabricante. Rápidos de desplegar, limitados a los protocolos y la lógica que ofrece el fabricante.
- PC industriales con software de gateway. Más flexibles: ejecutan una plataforma de conectividad comercial, Node-RED o tus propios contenedores. Requieren un mantenimiento más propio de TI.
- PLC y controladores con MQTT integrado. Muchos controladores modernos pueden publicar MQTT directamente. Esto elimina una caja, pero traslada responsabilidades de red al controlador, algo con lo que no todas las plantas se sienten cómodas.
- Gateways basados en microcontrolador. Para pequeños retrofits, un microcontrolador puede conectar unos pocos dispositivos Modbus con MQTT, como en el tutorial de ESP32 Modbus RS485 a MQTT. Adecuados para pilotos y monitorización no crítica.
¿Sparkplug B o JSON plano?
Cada vez más gateways ofrecen Sparkplug B, que añade un espacio de nombres de topics estándar, certificados de nacimiento y muerte para conocer el estado y payloads Protobuf compactos. El JSON plano es más fácil de leer y de consumir desde cualquier herramienta. Muchas plantas usan ambos: Sparkplug B desde los gateways y una vista JSON ISA-95 legible para los consumidores. ConnectMQ puede decodificar payloads Sparkplug B y volver a publicarlos en topics ISA-95, por ejemplo convirtiendo spBv1.0/factory1/DDATA/line1/cnc1 en connectmq/factory1/production/line1/cnc1/telemetry, de modo que ambos estilos conviven en un mismo broker. La visión general está en la guía de IoT industrial con MQTT.
Probar un gateway antes del despliegue
Antes de conectar un gateway a datos de producción, apúntalo a un broker de pruebas y verifica los topics, los payloads y el comportamiento de reconexión:
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Configura el gateway para que publique valores simulados o no sensibles bajo connectmq/demo/gw-test-81/... en el servidor MQTT público gratuito de ConnectMQ, desconecta su cable de red durante unos minutos y confirma que los mensajes del búfer llegan en orden al reconectar. Recuerda que cualquiera puede leer el servidor público: es solo para pruebas y prototipos, así que nunca envíes allí datos reales de planta.
Dónde encaja el broker
El gateway es solo la mitad del sistema. El broker en el que publica debe gestionar TLS, autenticación, muchos suscriptores simultáneos y el estado retenido de cada tag. Operar esa infraestructura por tu cuenta implica parches, renovación de certificados y monitorización. Un broker MQTT gestionado elimina esa carga, y las opciones van desde brokers serverless compartidos para pilotos hasta clústeres dedicados o brokers desplegados en tu propia cuenta cloud para requisitos más estrictos. Si antes quieres entender las ventajas e inconvenientes del alojamiento, consulta la guía para elegir un broker MQTT en la nube, y para decidir cuánta lógica debe quedarse en el edge y cuánta en la nube, lee edge computing vs cloud computing en IIoT.
Conecta tus gateways a ConnectMQ
ConnectMQ da a cada gateway un endpoint TLS en el puerto 8883, credenciales emitidas y vinculadas a su client ID, un explorador de topics en vivo y una vista de dispositivos organizada por niveles ISA-95. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y apunta tu primer gateway hacia él.
Preguntas frecuentes
¿Qué diferencia hay entre un gateway edge IIoT y un router?
Un router reenvía paquetes de red sin entenderlos. Un gateway edge entiende los protocolos industriales, lee los valores, los convierte en mensajes con significado y los publica por MQTT.
¿Necesito un gateway si mi PLC admite MQTT?
No siempre. Un gateway sigue siendo útil cuando tienes muchos dispositivos heredados, necesitas un búfer respaldado en disco o quieres mantener las credenciales del broker y el acceso a internet fuera de tus controladores.
¿Debe el gateway usar Sparkplug B?
Usa Sparkplug B si tus aplicaciones consumidoras lo admiten y quieres una gestión del estado estandarizada. Usa JSON plano si muchas herramientas sencillas necesitan leer los datos directamente; algunas plantas publican ambos.
¿Cuántos datos debe almacenar en búfer un gateway?
Dimensiona el búfer para la caída más larga que quieras soportar a tu ritmo de datos normal, con margen. Report by exception reduce tanto el tráfico normal como las necesidades de búfer.
