Esta checklist de conectividad IIoT recoge las preguntas que deciden si un proyecto de conexión de planta entra en servicio en una semana o se estanca durante meses. Sirve igual para una planta de manufactura en Monterrey, una operación minera en Chile o una fábrica en Valencia. Repásala antes de que llegue el primer gateway y sabrás exactamente qué reglas de firewall solicitar, qué protocolos tienes que convertir, cómo nombrar tus datos y a qué broker conectarte.
La checklist se agrupa en seis áreas. Cada punto es algo que puedes verificar, no un principio vago, y varios incluyen un comando que puedes ejecutar hoy mismo.
1. Alcance y responsables
La mayoría de los proyectos estancados fracasan por las personas, no por los paquetes. Resuelve estos puntos antes de hablar de hardware.
- Nombra un responsable en el lado OT y otro en el lado TI, cada uno con autoridad para aprobar cambios en su ámbito.
- Escribe el primer caso de uso en una frase, por ejemplo "mostrar el estado en vivo y el recuento de piezas de las seis máquinas CNC de la célula 4".
- Enumera las máquinas incluidas, sus controladores y su ubicación física.
- Acordad qué queda fuera del alcance de la fase uno. Escribir en los PLC es lo que más a menudo se pospone.
- Define cómo medirás el éxito: latencia de los datos, completitud y si las personas que pidieron los datos realmente los usan.
Si esas respuestas no están claras, nuestro plan de prueba de concepto IIoT te da una estructura de 30 días para concretarlas.
2. Checklist de acceso a la red
Tus datos necesitan un camino desde la máquina hasta el broker. Trázalo salto a salto.
- Identifica la zona de red de cada máquina y cada gateway: red de célula aislada, red OT de planta, DMZ o red corporativa.
- Confirma si el gateway se conectará directamente a internet, a través de un broker en la DMZ o a través de un proxy. Nuestra guía para ubicar MQTT en una DMZ industrial compara estas opciones.
- Solicita TCP 8883 saliente (MQTT sobre TLS) hacia el hostname del broker. Evita el 1883 en texto plano a través de cualquier límite de zona.
- Si navegadores o paneles web necesitan datos en vivo, solicita también TCP 8084 (MQTT sobre WebSocket seguro).
- Confirma la resolución DNS desde la red del gateway.
- Pregunta si hay un proxy con inspección TLS en el camino. Si lo hay, solicita una excepción para el hostname del broker.
- Comprueba el timeout de inactividad del firewall y fija el keepalive de MQTT por debajo.
- Confirma que el gateway puede llegar a un servidor NTP. Un reloj incorrecto rompe la validación TLS y las marcas de tiempo.
Verifica el camino desde el propio gateway, no desde tu portátil:
# Gateway Linux: DNS, TCP y TLS de una sola vez
getent hosts broker.connectmq.com
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null \
| grep -E "subject=|issuer=|Verify return code"
# Prueba MQTT de extremo a extremo con un client ID y un topic únicos
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i gw-test-$RANDOM -t connectmq/demo/gw-test-$RANDOM/ping -m hello -d
En un gateway basado en Windows o en un PC con HMI, el equivalente rápido es:
powershell -Command "Test-NetConnection broker.connectmq.com -Port 8883"
Un Verify return code: 0 (ok) de OpenSSL y un CONNACK (0) de mosquitto_pub -d significan que la parte de red está lista.
3. Checklist de protocolos y fuentes de datos
Tus máquinas hablan el protocolo con el que se fabricaron. Haz inventario.
| Fuente | Interfaz típica | Conversión necesaria | Qué hay que gestionar |
|---|---|---|---|
| PLC moderno | OPC UA, S7, Ethernet/IP | Gateway a MQTT | Acceso de solo lectura a los tags |
| PLC o variador antiguo | Modbus TCP o RTU | Gateway a MQTT | Mapa de registros del fabricante |
| Controlador CNC | MTConnect, OPC UA, API del fabricante | Adaptador a MQTT | Adaptador o licencia del fabricante |
| Máquina con lógica de relés | Ninguna | Sensores añadidos | Electricista para pinzas y contactos |
| Sensores nuevos | MQTT nativo, LoRaWAN, Wi-Fi | A menudo ninguna | Credenciales por dispositivo |
- Anota el protocolo, la dirección IP y el puerto o los parámetros serie de cada fuente.
- Confirma que es posible el acceso de solo lectura y obtén la aprobación por escrito del responsable de control.
- Exporta la lista de tags o registros y marca los que realmente necesitas. Veinte tags buenos valen más que dos mil sin usar.
- Anota los límites de sondeo. Algunos controladores antiguos tienen problemas si se consultan más de una vez por segundo.
- Decide si el gateway usará MQTT plano con JSON o Sparkplug B. Ambos funcionan; mezclarlos sin un plan, no.
4. Checklist de modelado de datos
Los datos que llegan con nombres crípticos son datos que nadie usa.
- Elige una jerarquía de topics, idealmente alineada con ISA-95: empresa, planta, área, línea, célula y después la máquina.
- Pon por escrito las reglas de nomenclatura: minúsculas, sin espacios, guiones o guiones bajos, unidades coherentes.
- Define el formato del payload, por ejemplo
{"value": 72.4, "unit": "C", "ts": "2026-10-16T08:00:00Z"}. - Decide qué topics son retenidos (estado actual) y cuáles son eventos (alarmas, piezas terminadas).
- Acordad las reglas de report by exception: qué cambio de valor merece un mensaje nuevo.
- Reserva un subárbol aparte para la salud de gateways y dispositivos: estado de conexión, última comunicación, versión de firmware.
La guía de topics MQTT con ISA-95 tiene ejemplos prácticos que puedes adaptar.
5. Checklist de seguridad
- Cada cliente se autentica con su propio nombre de usuario y contraseña. Nada de credenciales compartidas entre gateways.
- TLS en cada conexión que atraviese un límite de zona.
- En la fase uno, los gateways solo publican hacia arriba. Cualquier vía de comandos se diseña y revisa de forma explícita.
- Las credenciales se guardan en el gateway en un fichero protegido, no escritas en scripts que acaban en el control de versiones.
- Un mensaje last will marca cada gateway como desconectado cuando se desconecta de forma inesperada.
- Tienes un proceso para revocar una credencial cuando se sustituye o se roba un gateway.
- Nunca se publica nada sensible en un servidor MQTT público gratuito: sirve para pruebas y prototipos, no para datos de producción.
Considéralos mínimos: un gateway que no cumpla alguno de ellos no debe conectarse, ni siquiera para un piloto.
6. Checklist de selección del broker
El broker es el núcleo del que depende todo lo demás. Evalúalo frente a las necesidades de tu planta, no solo frente a una lista de funciones.
- Admite MQTT 3.1.1 y 5.0, para que se conecten tanto los gateways antiguos como los clientes modernos.
- Ofrece TLS en el 8883 y WebSocket seguro para los paneles en el navegador.
- Soporta tu número de conexiones y tamaños de mensaje, con margen para crecer.
- Admite como mínimo QoS 1, y QoS 2 si algún consumidor necesita entrega exactamente una vez.
- Admite retained messages y sesiones persistentes para que el estado sobreviva a las reconexiones.
- Entiende payloads industriales como Sparkplug B o, como mínimo, te permite inspeccionarlos.
- Te da visibilidad: quién está conectado, qué topics están activos y alertas por umbral.
- Tiene una respuesta clara sobre quién lo parchea y lo monitoriza. Un broker autoalojado es un servidor más del que tiene que ocuparse el equipo OT.
Para una comparación más profunda, consulta cómo elegir un broker MQTT para IoT y nuestra guía sobre el modelo de broker MQTT en la nube. Para ver cómo encajan todas estas piezas en una planta, lee la guía de IoT industrial con MQTT.
Cómo encaja ConnectMQ en la checklist
ConnectMQ es un broker MQTT gestionado diseñado pensando en la conexión de plantas. Admite MQTT 3.1.1 y 5.0 en TCP 1883, TLS 8883, WebSocket 8083 y WebSocket seguro 8084, usa un certificado de Let's Encrypt en el que ya confían los almacenes de CA estándar y vincula los client IDs a las credenciales emitidas. Detecta topics ISA-95 y de Unified Namespace, decodifica payloads Sparkplug B y puede volver a publicar los datos Sparkplug en topics ISA-95 legibles. El portal incluye un cliente MQTT en el navegador, un explorador de topics en vivo y reglas de alerta por umbral, lo que facilita verificar los puntos de las secciones 4 y 6 durante la puesta en marcha.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Tendrás credenciales en minutos, así que podrás ejecutar las pruebas de red de la sección 2 contra tu propio endpoint de ConnectMQ y completar hoy mismo la primera mitad de esta checklist.
Preguntas frecuentes
¿Qué puertos necesita un gateway IIoT para llegar a un broker MQTT?
Normalmente solo TCP 8883 saliente para MQTT sobre TLS. Añade TCP 8084 si hay paneles en el navegador que se conectan por WebSocket seguro. No hace falta ningún puerto entrante hacia la planta.
¿Quién debe ser responsable de un proyecto de conectividad IIoT?
Tanto OT como TI. Nombra un responsable en cada lado con autoridad para aprobar cambios, porque la mayoría de los retrasos se deben a aprobaciones poco claras y no a problemas técnicos.
¿Debo usar Sparkplug B o JSON para los datos de planta?
Ambos funcionan. Sparkplug B añade un modelo estricto de sesión y estado que entienden las herramientas SCADA, mientras que JSON con un árbol de topics ISA-95 es más fácil de leer e integrar. Elige uno por fuente de datos y documenta la decisión.
¿Cómo pruebo la conectividad antes de instalar ningún software de gateway?
Ejecuta las pruebas de DNS, OpenSSL y mosquitto_pub desde una máquina situada en la misma zona de red que el futuro gateway. Si las tres funcionan contra el puerto 8883, el camino de red está listo.
