En el diseño de cualquier arquitectura de Internet de las Cosas Industrial (IIoT), la elección del protocolo de comunicación determina directamente el consumo energético, el costo de transferencia de datos, la latencia y la seguridad del sistema. En entornos de manufactura, a menudo coexisten tecnologías de hace tres décadas con microcontroladores modernos que transmiten a la nube.
La importancia del protocolo en IoT
A diferencia del software web convencional donde el ancho de banda y la energía son abundantes, los dispositivos IoT operan frecuentemente con restricciones severas:
- Dispositivos alimentados por batería: donde cada transmisión de radio consume valiosos microamperios.
- Conectividad celular restringida: enlaces 4G LTE-M o satelitales con costo por megabyte transmitido.
- Redes con pérdidas de paquetes: entornos industriales ruidosos electromagnéticamente o plantas remotas.
Modbus RTU/TCP: El estándar heredado
Creado en 1979 por Modicon (hoy Schneider Electric), Modbus sigue siendo el protocolo industrial más extendido en PLCs (Controladores Lógicos Programables), variadores de frecuencia y medidores de energía. Opera bajo una arquitectura estricta de Maestro-Esclavo (o Cliente-Servidor en Modbus TCP):
- Modbus RTU: Corre sobre interfaces seriales como RS-485 a dos hilos. Es bidireccional de medio dúplex (half-duplex) y transmite tramas binarias compactas con verificación de redundancia cíclica (CRC16).
- Modbus TCP: Encapsula la trama Modbus dentro de paquetes TCP/IP en el puerto estándar 502, eliminando el cálculo de CRC porque la capa TCP ya garantiza la integridad del paquete.
Limitación de seguridad: El protocolo Modbus nativo no incluye autenticación ni cifrado. Cualquier dispositivo en la red puede leer o sobrescribir registros de control a menos que se implemente Modbus Security (TLS en puerto 802) o se aísle en una VLAN dedicada.
MQTT: El estándar de facto en IoT moderno
MQTT (Message Queuing Telemetry Transport) fue creado originalmente por IBM para monitorear oleoductos vía satélite y se ha convertido en el estándar indiscutible para el IoT moderno debido a su modelo de Publicación / Suscripción (Pub/Sub):
- Broker central: Los clientes nunca se comunican directamente entre sí; todos se conectan a un servidor central (como Eclipse Mosquitto, EMQX o AWS IoT Core).
- Encabezado ultraligero: La cabecera mínima de un paquete MQTT es de apenas 2 bytes, comparado con los cientos de bytes que requiere una petición HTTP.
- Niveles de Calidad de Servicio (QoS):
QoS 0 (At most once):El mensaje se envía una vez sin confirmación. Ideal para telemetría continua de alta frecuencia.QoS 1 (At least once):Garantiza la entrega mediante acuse de recibo (PUBACK). El mensaje puede duplicarse si se pierde el acuse.QoS 2 (Exactly once):Handshake de 4 pasos que garantiza que cada mensaje se procesa exactamente una vez. Vital para transacciones críticas o alertas de parada de emergencia.
- Cifrado y autenticación: Soporta autenticación por usuario/contraseña, certificados X.509 de cliente y cifrado TLS (MQTTS en el puerto 8883).
CoAP: Comunicación ligera sobre UDP
CoAP (Constrained Application Protocol), definido en la RFC 7252 por el IETF, fue diseñado específicamente para traducir el paradigma REST (GET, POST, PUT, DELETE) a dispositivos de recursos extremadamente limitados (8 bits de microcontrolador y redes 6LoWPAN):
- Opera sobre UDP en lugar de TCP, eliminando el coste de establecimiento de conexión (handshake de 3 vías).
- Implementa su propio mecanismo ligero de retransmisión y detección de duplicados mediante mensajes confirmables (CON) o no confirmables (NON).
- Se asegura utilizando DTLS (Datagram Transport Layer Security) en lugar de TLS estándar.
HTTP / REST: Cuándo usarlo y cuándo evitarlo
HTTP/1.1 y HTTP/2 son la columna vertebral de la web, pero en dispositivos embebidos presentan desventajas claras:
- Sobrecarga masiva: Una simple petición HTTP GET con cabeceras típicas (User-Agent, Accept, Host, Authorization) supera con facilidad los 500 a 1,000 bytes solo en metadatos para enviar un valor de temperatura de 4 bytes.
- Modelo pull (Polling): Si un dispositivo debe esperar una orden del servidor, debe consultar continuamente (polling), consumiendo batería y ancho de banda innecesariamente.
- Cuándo sí usarlo: Carga de archivos pesados (actualizaciones de firmware OTA), envío de imágenes o integración directa con APIs web de terceros desde gateways conectados a corriente eléctrica permanente.
Tabla comparativa técnica
| Protocolo | Transporte | Sobrecarga Mínima | Modelo | Seguridad Nativa | Caso de Uso Ideal |
|---|---|---|---|---|---|
| Modbus RTU/TCP | Serial / TCP | 4 - 8 bytes | Maestro / Esclavo | No (Requiere VLAN o Modbus Sec) | Maquinaria pesada, PLCs, subestaciones eléctricas |
| MQTT | TCP / WebSockets | 2 bytes | Pub / Sub | TLS / MQTTS (X.509) | Telemetría masiva a nube, dashboards en tiempo real |
| CoAP | UDP | 4 bytes | Request / Response | DTLS | Sensores a batería, redes LPWAN / Zigbee / Thread |
| HTTP / REST | TCP | 300 - 800+ bytes | Request / Response | HTTPS / TLS | Gateways con energía ilimitada, subida de logs y OTA |
Arquitectura híbrida recomendada para la industria
En proyectos reales de digitalización de plantas industriales, la mejor práctica de ingeniería no consiste en reemplazar los equipos antiguos, sino en implementar un Edge Gateway que conecte ambos mundos:
- El gateway (como una Raspberry Pi CM4 industrial o un IPC Advantech) se comunica localmente por Modbus RTU/RS-485 con los variadores y PLCs existentes a alta velocidad.
- El gateway procesa y filtra los datos en el borde (Edge Computing) para calcular medias y detectar anomalías.
- Los datos procesados se empaquetan en formato JSON y se envían de forma segura por MQTT sobre TLS al broker en la nube de la empresa.