Modbus vs OPC UA vs SNMP vs MQTT: qué protocolo industrial usar en cada proyecto

Si está integrando equipos físicos a software —HVAC en una sala técnica, PLCs en planta, routers de un ISP, sensores en campo— la primera decisión técnica es qué protocolo usar para hablar con el equipo. Equivocarse aquí no se nota al principio, pero seis meses después se traduce en métricas faltantes, integraciones frágiles y costos de soporte que no estaban en el presupuesto.

Esta guía no es un manual exhaustivo. Es la decisión rápida que tomamos en COL0 cuando llega un proyecto nuevo, con los criterios prácticos para que usted la tome igual.

TL;DR — qué protocolo según el caso

Necesidad	Protocolo
Hablar con un PLC, variador, medidor o equipo industrial	Modbus (RTU sobre RS-485 o TCP sobre Ethernet)
Integrar una planta moderna con modelado de datos rico	OPC UA
Monitorear infraestructura de red (routers, switches, servidores)	SNMP
Llevar telemetría de muchos dispositivos a la nube	MQTT
HVAC, BMS, iluminación de edificio	BACnet (mención aparte)

Si combina varias en un mismo proyecto, lo está haciendo bien. Lo raro es que un proyecto industrial real use solo uno.

Modbus: el lenguaje universal de la planta

Es el más viejo (1979) y el más extendido. Casi cualquier equipo industrial habla Modbus en alguna variante:

• Modbus RTU sobre RS-485 — para equipos de planta cableados en serie. Lo encuentra en variadores, medidores eléctricos, sensores de proceso, básculas industriales.
• Modbus TCP sobre Ethernet — la versión moderna, plug-and-play en redes IP.

Cuándo elegir Modbus:

• El equipo lo soporta (revise el manual; con muchísima probabilidad sí).
• Necesita leer registros concretos: temperatura, voltaje, peso, estado.
• Tiene presupuesto limitado y no necesita modelado de datos sofisticado.

Limitaciones reales:

• Solo lee/escribe registros numéricos. No hay tipos complejos, no hay descubrimiento, no hay metadatos.
• Sin seguridad. Modbus TCP va en claro — protéjalo con VLAN o VPN, nunca expuesto a internet.
• Cliente-servidor: usted debe consultar (polling). Para alertas en tiempo real necesita combinarlo con MQTT.

En proyectos colombianos lo vemos en el 70% de los casos: la pregunta no es “¿uso Modbus?” sino “¿solo Modbus alcanza o necesito complementarlo?”.

Si su proyecto vive en este territorio, este es el servicio que cubre la integración con dispositivos físicos que tenemos en COL0.

OPC UA: cuando el sistema lo amerita

OPC UA es el estándar moderno (IEC 62541) para comunicación industrial. No reemplaza a Modbus en el equipo viejo; reemplaza a Modbus en la capa de planta cuando el sistema crece.

Cuándo elegir OPC UA:

• Planta nueva o modernización mayor — los PLCs nuevos (Siemens S7-1500, Allen-Bradley CompactLogix, Beckhoff) hablan OPC UA nativo.
• Necesita modelar datos con tipos complejos (no solo “registro 40001 = 23.5”, sino “Motor M1.Velocidad = 23.5 RPM con timestamp y calidad”).
• Requiere seguridad real: autenticación, autorización, cifrado TLS.
• Integración con SCADA, MES o sistemas que ya entienden OPC UA.

Limitaciones reales:

• Más pesado que Modbus. Un microcontrolador no implementa OPC UA, necesita un gateway o un PLC.
• Curva de aprendizaje mayor para el equipo de software.
• Licencias de algunas implementaciones comerciales cuestan.

Patrón común en plantas industriales: equipos viejos por Modbus → gateway que los normaliza → expone vía OPC UA al SCADA y MES. Mezclar protocolos no es pecado, es la realidad.

SNMP: hecho para redes

SNMP (Simple Network Management Protocol) es lo que usa un router para reportar su estado, una impresora para informar nivel de tinta o un servidor para mostrar carga de CPU.

Cuándo elegir SNMP:

• Monitorear infraestructura de red: routers MikroTik, switches Cisco, firewalls.
• Monitorear servidores físicos, UPS, PDUs.
• Necesita métricas de operación (no de proceso industrial).
• Quiere recibir alertas push del equipo (SNMP traps) cuando algo falla.

Limitaciones reales:

• No sirve para leer un sensor de temperatura industrial (use Modbus).
• SNMP v1/v2c no tienen seguridad. Use v3 en redes empresariales.
• Cada vendor tiene MIBs propios — integrar requiere conocer los OIDs del equipo.

Si su proyecto es gestionar y monitorear infraestructura telecom, este es el servicio de integración telecom donde aplicamos SNMP y NETCONF directamente.

MQTT: el transporte para la nube

MQTT no es un protocolo para hablar con equipos industriales. Es un protocolo de mensajería ligero para llevar telemetría desde dispositivos distribuidos hasta una plataforma central, típicamente en la nube.

Cuándo elegir MQTT:

• Tiene cientos o miles de dispositivos remotos enviando datos a un broker central.
• Necesita conectividad sobre redes inestables — MQTT está diseñado para reconectarse.
• Quiere publicar/suscribir, no cliente/servidor.
• Está construyendo una plataforma IoT en AWS IoT Core, Azure IoT Hub o un broker propio (Mosquitto, EMQX).

Limitaciones reales:

• No habla con un PLC ni con un router directamente. Necesita un agente o gateway en el medio.
• El broker es punto único; planifique alta disponibilidad si es producción crítica.
• Tópicos mal diseñados son una pesadilla a 6 meses — invierta tiempo en el esquema desde el día 1.

El patrón estándar IoT: sensores hablan Modbus al gateway → gateway publica vía MQTT a la nube → la nube transforma y guarda. Si está pensando en esa arquitectura, este es exactamente el servicio de desarrollo IoT con dashboards en tiempo real que entregamos.

BACnet: mención obligatoria para edificios

Si su proyecto es HVAC, iluminación o controles de edificio, probablemente vea BACnet (Building Automation and Control Network). Es a edificios lo que Modbus es a planta.

Equipos típicos con BACnet: Honeywell, Siemens Desigo, Schneider EcoStruxure, Johnson Controls.

Consejo práctico: si su proyecto es solo edificio, vaya BACnet directo. Si mezcla planta + edificio, gateway que normalice a OPC UA o MQTT es lo que evita 6 meses de dolor.

Cómo decidimos en proyectos reales

En la primera hora del descubrimiento técnico hacemos cinco preguntas:

1. ¿Qué equipo concreto vamos a integrar? Marca, modelo, año. Sin esto, ninguna conversación sobre protocolo es real.
2. ¿Qué protocolos soporta ese equipo según el manual? Lo que el equipo soporta restringe la elección antes que cualquier preferencia.
3. ¿A dónde van los datos? Si es a un SCADA local, posiblemente OPC UA. Si es a la nube, MQTT. Si es a un dashboard interno, depende del volumen.
4. ¿Necesitamos modelado de datos o solo lecturas? Modbus alcanza para lecturas. OPC UA es para modelado.
5. ¿La red es de planta, telecom o mixta? SNMP no integra equipos de planta. Modbus no monitorea routers. No se cruzan.

Si su proyecto necesita resolver esta decisión bien estructurado, descargue la guía gratuita de viabilidad que entregamos a clientes —incluye el checklist completo de validación de equipos y protocolos— en el banner de abajo. O escríbanos directo desde contacto o por WhatsApp y conversamos en una llamada de 30 minutos sin compromiso.

Errores típicos que evitamos

1. Elegir el protocolo “moderno” sin que el equipo lo soporte. OPC UA no sirve si su variador de 2015 solo habla Modbus RTU.
2. Confundir protocolo industrial con transporte. Modbus y MQTT no compiten; complementan. Modbus lee el equipo, MQTT lleva el dato lejos.
3. Olvidar la seguridad. Modbus TCP y SNMP v2c expuestos a una red corporativa son boletos a un incidente. VLAN, VPN o firewall obligatorios.
4. Reinventar lo que ya existe. Si el equipo tiene una integración estándar documentada, úsela. No invente protocolos propios.
5. No probar con el equipo real. Las hojas de datos mienten. Pruebe lectura/escritura en un dispositivo físico antes de comprometer arquitectura.

---

¿Está en medio de una integración y no está seguro de qué protocolo es el correcto? En COL0 hemos integrado decenas de equipos en sectores industriales colombianos. Cuéntenos su caso y le decimos en una llamada qué camino tomar.