Modbus TCP: qué es, cómo funciona en Ethernet y cómo leer registros en automatización.

Modbus TCP es uno de los métodos de intercambio de datos más utilizados en la automatización industrial, la ingeniería energética y los sistemas BMS, especialmente allí donde Ethernet es la base natural de la comunicación. Si alguna vez has integrado un contador de energía, un variador de frecuencia (VFD), un PLC, un panel HMI o un sistema SCADA y en la documentación aparecía “Modbus TCP”, en la práctica se trata de un modelo sencillo y predecible para leer y escribir datos de proceso (registros) sobre TCP/IP, normalmente en el puerto 502.

En este artículo explico qué es Modbus TCP, cómo es la trama (incluida la cabecera MBAP), cómo entender el direccionamiento de registros, en qué se diferencia Modbus TCP de Modbus RTU y qué conviene tener en cuenta en las integraciones, desde red y rendimiento hasta seguridad. El texto es intencionadamente técnico y práctico: está pensado para ayudarte a tomar buenas decisiones en instalaciones reales.

Modbus TCP: definición e idea principal

Modbus TCP es una variante del protocolo Modbus diseñada para redes Ethernet, basada en TCP/IP. Desde la perspectiva del usuario, es un “lenguaje” que utilizan los dispositivos industriales para intercambiar datos sencillos: estados binarios, valores numéricos, consignas, alarmas, contadores de energía, temperaturas, caudales, estados de funcionamiento. Toda la filosofía es deliberadamente minimalista: una parte solicita un rango concreto de datos y la otra responde.

Ese minimalismo es precisamente la razón de su popularidad. Modbus TCP no intenta ser una red “inteligente” en tiempo real como algunos protocolos fieldbus/Ethernet industrial. En su lugar, ofrece lectura y escritura predecible de registros, fácil de implementar en controladores, pasarelas Modbus y software SCADA. Por eso lo encontrarás tanto en fábricas como en edificios: en automatización HVAC, cuadros eléctricos, contadores, variadores, grupos electrógenos, sistemas UPS, estaciones de bombeo o estaciones de recarga.

Cliente-servidor, puerto 502 y el papel de la conexión TCP

En Modbus TCP se habla con más frecuencia de un modelo cliente-servidor (también puede aparecer la terminología master/slave, pero en TCP resulta más práctico pensar en “quién inicia la petición” y “quién responde”). Un escenario típico:

• Cliente Modbus TCP (por ejemplo, SCADA, PLC, panel HMI, pasarela Modbus) consulta datos de forma cíclica.
• Servidor Modbus TCP (por ejemplo, contador de energía, variador, controlador, módulo de E/S) expone registros y responde.
• Transporte: TCP, normalmente en el puerto 502 del lado del servidor.

TCP aporta dos elementos clave: comunicación orientada a conexión y control de la correcta entrega. En la práctica, esto significa que el cliente establece una conexión con el servidor, envía solicitudes y recibe respuestas, mientras la pila TCP gestiona retransmisiones y orden. Una buena práctica en integraciones Modbus TCP es mantener la conexión abierta y consultar de forma cíclica sin desconectar constantemente, porque el “connect/disconnect” frecuente puede cargar dispositivos débiles, como contadores, y provocar inestabilidad.

Trama Modbus TCP: MBAP + PDU (sin CRC)

La diferencia más importante “a nivel de bytes” entre Modbus TCP y Modbus RTU es que TCP no utiliza CRC en la capa de aplicación. En su lugar, Modbus TCP usa la cabecera MBAP (Modbus Application Protocol header), y la corrección de la transmisión la garantiza TCP mediante sus mecanismos de checksum y transporte.

La estructura de la unidad de datos en Modbus TCP (ADU) es la siguiente: MBAP (7 bytes) + PDU (Function Code + Data).

El campo Unit Identifier puede resultar confuso: en un Modbus TCP “puro” (cuando te conectas directamente a un dispositivo TCP) a menudo se ignora o se establece en 0xFF/0x00. Sin embargo, cuando te conectas a una pasarela Modbus de TCP a Modbus RTU, el Unit Identifier suele corresponder a la dirección slave en RS-485. Es un detalle que puede “matar” una integración si el cliente envía un Unit ID distinto del que espera la pasarela.

La PDU en Modbus TCP sigue exactamente la misma lógica que conoces de Modbus RTU: Function Code (por ejemplo, 03 - Read Holding Registers, 06 - Write Single Register, 16 - Write Multiple Registers) más datos (dirección inicial, número de registros, valores).

Ejemplo: lectura de Holding Registers (Function 03)

En la práctica, la operación más habitual que verás es la lectura de Holding Registers mediante la función 03. El cliente proporciona una dirección inicial y el número de registros, y el servidor devuelve los bytes de datos. Conviene recordar que Modbus trabaja con registros de 16 bits, pero los dispositivos reales a menudo almacenan valores de 32 bits (por ejemplo, float o int32) en pares de registros, y entonces aparece el tema del orden de palabras.

Modelo de datos: coils y registros; cómo leer direcciones

Modbus TCP utiliza el modelo de datos clásico de Modbus, que divide el espacio de direcciones en cuatro “tablas”. No se trata de memorias físicas, sino de áreas lógicas a las que se accede mediante funciones Modbus:

• Coils (0xxxx): bits de lectura/escritura, por ejemplo, control.
• Discrete Inputs (1xxxx): bits de solo lectura, por ejemplo, estados de entrada.
• Input Registers (3xxxx): registros de 16 bits de solo lectura, por ejemplo, mediciones.
• Holding Registers (4xxxx): registros de 16 bits de lectura/escritura, por ejemplo, consignas.

La trampa más habitual en integraciones Modbus TCP es el direccionamiento basado en 0 frente al basado en 1. La documentación de un dispositivo puede indicar “registro 40001”, mientras que el cliente espera la dirección inicial “0”. Otro fabricante puede indicar “Holding Register 1” y querer decir también “el primero”. Por eso siempre debes comprobar en tu herramienta o controlador si el campo de dirección cuenta desde 0 o desde 1.

16 bits, 32 bits, float y orden de palabras

Modbus por sí mismo ve el mundo como registros de 16 bits. Sin embargo, los contadores de energía, variadores o analizadores de calidad de red suelen almacenar valores como float32 o int32. Entonces un valor ocupa 2 registros y aparece la pregunta: ¿va primero la “palabra alta” o la “palabra baja”? A veces también aparece el intercambio de bytes dentro de una palabra (byte swap). No existe un estándar único: es una decisión del fabricante. Por eso, durante la integración:

• Empieza comparando con el valor mostrado en la pantalla del dispositivo, si dispone de ella.
• Busca en la documentación expresiones como “word order”, “endianness” o “float format”.
• Si el resultado es “cósmico”, el problema casi nunca es Modbus TCP, sino la interpretación de los datos.

Modbus TCP vs Modbus RTU: diferencias prácticas

En pocas palabras: Modbus RTU es Modbus sobre un enlace serie, normalmente RS-485, mientras que Modbus TCP es Modbus sobre Ethernet. Ambas variantes usan las mismas funciones y el mismo modelo de registros, pero se diferencian en su “entorno” y en el comportamiento de red.

• Direccionamiento de dispositivos: RTU lleva una dirección slave en la trama; TCP usa IP/puerto, y el Unit ID importa sobre todo en pasarelas.
• CRC: RTU lleva CRC en la trama; TCP se basa en los mecanismos de TCP/IP y Modbus TCP añade MBAP.
• Topología: RTU es un bus, un cable y muchos dispositivos; TCP es una red con switches, VLAN y routing.
• Escalabilidad: TCP suele escalar con más facilidad cuando hay muchos dispositivos distribuidos, pero exige una red bien gestionada.

Desde la perspectiva del integrador, el mejor compromiso suele ser una arquitectura híbrida: Modbus RTU donde predominan los dispositivos serie, por ejemplo, contadores RS-485, y pasarelas/controladores que exponen esos datos posteriormente como Modbus TCP hacia SCADA o BMS.

Aplicaciones en PLC, SCADA, BMS e ingeniería energética

Allí donde necesitas recopilar datos de los dispositivos de forma rápida y predecible, Modbus TCP es una elección natural. A continuación se muestran escenarios típicos que se repiten en muchos proyectos:

• Ingeniería energética y medición: contadores de energía, analizadores de red y monitorización del consumo en instalaciones.
• Variadores: VFD, arrancadores suaves y servovariadores; lectura de estado, alarmas, velocidad, corriente y potencia.
• BMS/HVAC: enfriadoras, UTA, bombas y cuadros eléctricos; integración en un sistema de supervisión.
• SCADA e IoT: recogida de datos de proceso para visualización, informes, alarmas y analítica.
• Modernización: “llevar” dispositivos legacy a Ethernet mediante pasarelas Modbus TCP.

En la práctica, el protocolo es tan sencillo que funciona muy bien con convertidores y pasarelas que traducen Modbus TCP a otros estándares, por ejemplo, Modbus RTU, BACnet IP o MQTT Broker. Por eso Modbus TCP se utiliza con tanta frecuencia como “lenguaje intermedio” en integraciones multiprotocolo.

Red, rendimiento y buenas prácticas de implementación

En Modbus TCP, el “problema” rara vez es el protocolo en sí. Con más frecuencia, el problema es que Modbus TCP funciona sobre Ethernet, y Ethernet puede ser implacable cuando la red es improvisada. Algunas prácticas que realmente mejoran la estabilidad:

1) Segmenta la red de automatización (VLAN / subred separada)

Si el tráfico Modbus TCP se mezcla con tráfico de oficina, como Wi-Fi, videoconferencias o copias de seguridad, aumenta el riesgo de retardos y timeouts. Una subred o VLAN separada para automatización, con routing controlado, es una de las mejoras de calidad más baratas.

2) Configura tiempos de polling y límites de registros razonables

Modbus TCP invita a consultar “todo lo posible” cada 100 ms. Sin embargo, muchos dispositivos tienen una CPU limitada y un número limitado de conexiones simultáneas. Buena práctica: agrupar registros en bloques mayores, si son contiguos, pero sin exagerar el tamaño de una sola petición y dejando margen para la respuesta. En lugar de 50 consultas pequeñas, normalmente es mejor usar 5–10 bloques sensatos alineados con la documentación.

3) Mantén conexiones TCP persistentes cuando tenga sentido

Algunos servidores Modbus TCP no gestionan bien una “tormenta” de conexiones cortas. Si tu cliente, ya sea SCADA o PLC, puede mantener la sesión abierta, normalmente merece la pena activarlo. Menos sobrecarga, menos estados transitorios problemáticos y diagnóstico más sencillo.

4) Recuerda los límites de concurrencia

Si 20 clientes consultan al mismo tiempo el mismo contador de energía mediante Modbus TCP, tarde o temprano verás retardos, conexiones caídas o respuestas con “illegal data value”. En estos sistemas funciona bien una arquitectura con un único recolector de datos, por ejemplo, una pasarela Modbus o un PLC, y el resto de sistemas leen los datos desde él, o a través de otro protocolo.

Seguridad de Modbus TCP: qué debe protegerse

El dato más importante es este: Modbus TCP no incorpora autenticación ni cifrado en el estándar. Fue diseñado en una época en la que las redes de automatización estaban aisladas. Hoy, cuando integramos instalaciones con IT, nube y servicio remoto, es necesario añadir seguridad “alrededor” del protocolo:

• No expongas el puerto 502 a Internet; es pedir problemas.
• Firewall + ACL: permite únicamente IP concretas de cliente hacia servidores concretos.
• Segmentación: VLAN o subred separada para automatización, con routing controlado.
• VPN para acceso remoto de servicio, en lugar de “abrir el puerto”.
• Roles y permisos: si el sistema lo permite, separa acceso de solo lectura del acceso de escritura.

En muchas instalaciones es suficiente con que Modbus TCP permanezca dentro de la red OT, con acceso remoto únicamente a través de un router VPN con allowlist. Si diseñas desde cero, trata la seguridad como un elemento funcional y no como una “opción al final”.

Diagnóstico y problemas habituales de integración

Cuando Modbus TCP “no funciona”, la mayoría de las veces el problema se encuentra en uno de unos pocos puntos. A continuación tienes una lista que ahorra mucho tiempo durante la puesta en marcha:

1) IP, máscara de subred, gateway y puerto 502

Empieza por lo básico: ¿el dispositivo responde al ping?, ¿está en la misma subred?, ¿está abierto el puerto 502?, ¿algún firewall, en el dispositivo o en la red, está bloqueando el tráfico? En la práctica, la “falta de respuesta” suele deberse a problemas de direccionamiento IP, conflictos de direcciones o filtros en un switch o router.

2) Unit Identifier en pasarelas TCP↔RTU

Si te conectas a una pasarela en lugar de hacerlo directamente a un dispositivo TCP, comprueba el Unit ID: a menudo debe coincidir con la dirección slave en RS-485. El síntoma del error es “la conexión está activa”, pero no hay respuesta, o aparecen excepciones, es decir, exception codes.

3) Direccionamiento de registros incorrecto (0-based vs 1-based)

El clásico. Si la documentación indica 40001 y la herramienta requiere la dirección 0, obtendrás una excepción “Illegal Data Address” o silencio. Prueba con un offset de 1 y asegúrate de cómo interpreta tu cliente el espacio de direcciones.

4) Tipo de dato y orden de palabras

Si la respuesta llega, pero los valores no tienen sentido, comprueba si realmente es int16 y no float32, si las palabras deben intercambiarse o si existe un factor de escalado, por ejemplo, ×0.1, descrito en la documentación. Modbus TCP aquí es “inocente”: simplemente transporta registros brutos.

Para un diagnóstico más profundo, resulta útil el análisis de tráfico, por ejemplo, con Wireshark, así como comparar solicitudes y respuestas: verás la función, es decir, el Function Code, la dirección inicial, el número de registros y cualquier exception code.

FAQ: preguntas más frecuentes sobre Modbus TCP