Modbus RTU vs Modbus TCP: cómo decidir sin caer en mitos

El ingeniero de automatización que cierra la especificación de un tablero nuevo suele llegar a este punto con dos voces en la cabeza. De un lado, el veterano de campo dice que "Ethernet en tablero industrial no funciona, se cae, agarra ruido, la latencia es imprevisible". Del otro, el integrador moderno dice que "RS-485 es de los años 80, ya nadie lo usa, todo SCADA nuevo es TCP". Los dos exageran. Modbus RTU y Modbus TCP conviven en millones de plantas en 2026, cada uno resolviendo problemas distintos, y la elección equivocada cuesta cable, switches y horas de puesta en marcha. Este post compara ambos protocolos en lo que importa para decidir: capa física, trama, latencia, seguridad, costo, escenarios de aplicación y cómo convivir con los dos vía gateway. Al final, el papel honesto del AEM-60DC8 en esta decisión.

Historia rápida — de dónde vino cada uno

Modbus RTU nació en 1979 en Modicon, parte de la entonces recién creada familia de PLCs Modicon 084 y 184. El escenario era una planta con PLCs caros e instrumentos de campo simples; el protocolo tenía que correr sobre serie barata (al inicio RS-232, luego RS-485 cuando Modicon publicó la especificación física) y debía ser lo bastante simple para que un microcontrolador de 8 bits de la época lo procesara por interrupción. El resultado fue un protocolo maestro-esclavo, binario, con CRC-16 y tabla de funciones compacta. Modicon liberó la especificación como abierta en 2004; hoy la mantiene la Modbus Organization.

Modbus TCP apareció veinte años después, en 1999, especificado por Schneider Electric (que había comprado Modicon en 1996) como adaptación del mismo protocolo de aplicación corriendo sobre TCP/IP, puerto 502. La motivación fue clara: las plantas se conectaban a redes Ethernet corporativas y los SCADA migraban a PCs en red. En lugar de crear un protocolo nuevo, Schneider preservó la semántica RTU (mismas funciones, mismos códigos, misma estructura de registros) y solo cambió el transporte. Por eso la curva de aprendizaje entre RTU y TCP es corta para quien ya conoce uno de los dos.

Vale recordar que existe una tercera variante, Modbus ASCII, que es el mismo protocolo de aplicación en texto sobre serie. Hoy es raro en campo, usado casi solo en diagnóstico o en sistemas legados con módems analógicos lentos. Esta comparación se enfoca en RTU y TCP, los dos relevantes en proyectos nuevos.

Capa física — RS-485 vs Ethernet

Aquí es donde más aparecen los mitos. RS-485 es diferencial, dos hilos (más tierra de referencia), hasta 32 cargas unitarias por segmento (1200 m a baja velocidad), buena inmunidad a ruido modo común y costo de transceiver del orden de centavos. Ethernet industrial es par trenzado categoría 5e o 6, también diferencial, 100 m por tirada entre nodo y switch, exige switches gestionables para cualquier red seria y tiene costo por puerto en unidades de dólar.

Aspecto	RS-485 (RTU)	Ethernet (TCP)
Topología	Bus (daisy-chain)	Estrella vía switch
Distancia	Hasta 1200 m por segmento a 9600 bps	100 m por tirada, repetida por switch
Nodos por segmento	32 cargas unitarias (hasta 256 con repetidor)	Limitado solo por el switch
Cable típico	Par trenzado blindado 24 AWG	Cat 5e / Cat 6
Inmunidad EMC	Alta (diferencial, baja impedancia)	Alta con cable blindado y aterramiento correcto
Costo por nodo	Transceiver de US$ 0,50, conector US$ 1	Puerto de switch industrial US$ 30 a US$ 80
Complejidad de configuración	Dirección, baud, paridad	IP, máscara, gateway, VLAN, switch

En la práctica, RS-485 sigue ganando en tablero chico y en enlace punto a punto en ambientes con EMC adversa (subestaciones de media tensión, salas de máquinas con variadores). Ethernet gana en planta grande con muchos dispositivos distribuidos y cuando la infraestructura de red ya existe para otros fines (video, IT, gestión).

Trama y overhead — cuántos bytes por lectura

Acá RTU es más liviano, y eso importa en enlace lento. Una trama Modbus RTU típica leyendo 10 holding registers es:

Campo	Bytes
Dirección de esclavo	1
Código de función (0x03)	1
Dirección inicial	2
Cantidad de registros	2
CRC-16	2
Total de la petición	8 bytes
Respuesta: addr+func+bytecount+datos (20)+CRC	25 bytes
Round-trip total	33 bytes

A 9600 bps con 8N1 son unos 34 ms solo de transmisión, más el tiempo de procesamiento del esclavo (típicamente 2 a 10 ms) y el silencio inter-trama obligatorio de 3,5 caracteres (3,6 ms a 9600).

La misma petición en Modbus TCP lleva un encabezado extra llamado MBAP (Modbus Application Protocol) de 7 bytes: transaction ID (2), protocol ID (2), length (2), unit ID (1). No hay CRC porque TCP ya garantiza integridad en la capa de transporte.

Campo	Bytes
Encabezado MBAP	7
Función + dirección + cantidad	5
Total de la petición	12 bytes
Respuesta: MBAP (7) + func (1) + bytecount (1) + datos (20)	29 bytes
Round-trip en la capa Modbus	41 bytes

Encima viene el overhead TCP/IP: cabecera IP (20), cabecera TCP (20), Ethernet (18), agregando ~58 bytes por paquete. A 100 Mbps son microsegundos, pero en polling masivo (1000 nodos, 10 Hz) empieza a importar para el switch.

Eficiencia de polling: en RTU a 19200 bps, un sondeo cíclico de 8 esclavos leyendo 32 registros cada uno termina en unos 250 ms (4 Hz). En TCP sobre LAN 100 Mbps, los mismos 8 nodos se leen en paralelo (múltiples conexiones simultáneas) en menos de 50 ms. RTU es más denso en bytes; TCP es más paralelo en transacciones.

Latencia y determinismo

RTU es determinístico por construcción: el maestro habla, el esclavo responde, nadie más habla. El tiempo de polling es predecible dentro de una tolerancia pequeña (jitter de ~1 ms). Para lazos de control de ciclo corto (50 a 200 ms) en tablero aislado, RTU entrega latencia consistente.

TCP es probabilístico. La latencia típica en LAN industrial dedicada está en 1–5 ms, pero en red compartida con tráfico de video, backup o ruteo mal configurado puede saltar a decenas o cientos de milisegundos sin aviso. Donde gana TCP es en red grande con múltiples maestros leyendo el mismo dispositivo (imposible en RTU sin token-passing, que en la práctica nadie implementó en Modbus), o cuando los dispositivos están físicamente distribuidos por edificios y Ethernet ya es el camino natural.

Regla práctica: para control (PID, enclavamiento, protección), RTU en tablero aislado tiende a entregar latencia más previsible. Para supervisión e historización (SCADA, MES, BI), TCP entrega más flexibilidad. La mayoría de los proyectos usa los dos.

Seguridad — los dos nacieron desnudos

Acá no hay ganador por defecto: ni Modbus RTU ni Modbus TCP traen autenticación, cifrado o control de integridad en la capa de aplicación. Cualquiera con acceso físico al bus (RTU) o a la red (TCP) puede leer todos los registros y escribir en los que estén expuestos.

Existe un suplemento llamado Modbus/TCP Security (publicado en 2018), que envuelve el tráfico en TLS 1.2 o superior en el puerto 802, con X.509 mutuo. Es raro en campo — estimaciones conservadoras indican menos del 1% de las instalaciones Modbus/TCP corriendo TLS en 2026. La razón es práctica: la mayoría de los dispositivos de campo aún no tiene firmware con TLS, y los SCADA legados no hablan Modbus/TCP Security.

La defensa real hoy es por capas:

• RTU: aislamiento físico. Tablero cerrado, cableado dentro del gabinete, RS-485 no expuesto fuera de la zona controlada. Si el atacante ya está dentro del gabinete, el problema es mayor que Modbus.
• TCP: segmentación de red. VLAN dedicada para OT, firewall entre OT e IT, conduits según el modelo ISA/IEC 62443, lista blanca de IPs por dispositivo, monitoreo de tráfico anómalo. Idealmente Modbus/TCP Security cuando el dispositivo lo soporte.

El AEM-60DC8 solo habla Modbus RTU. La defensa, entonces, viene por topología: el equipo queda en el gabinete junto al bus DC que monitorea, y el gateway que expone los datos a la red corporativa es el que implementa autenticación y aislamiento.

Costo total — no es solo el precio del dispositivo

La cuenta honesta incluye cable, conector, switch, capacitación y tiempo de puesta en marcha. Ejemplo simplificado de un tablero con 6 dispositivos:

Ítem	Modbus RTU	Modbus TCP
Cable (par trenzado vs Cat 5e)	80 m × US$ 0,80 = US$ 64	6 tiradas × 15 m × US$ 1,20 = US$ 108
Conectores	12 × US$ 1 = US$ 12	12 × US$ 2 = US$ 24
Switch / conversor	1 conversor USB-RS485 US$ 40	Switch industrial 8 puertos US$ 360
Capacitación (horas-ingeniero)	4 h (dirección, baud)	12 h (IP, VLAN, switch)
Tiempo de puesta en marcha típico	2 a 4 h	4 a 8 h
Total estimado de hardware	~US$ 116	~US$ 492

Este ejemplo es simplificado y no incluye mano de obra de tendido de cable, parecida en ambos casos. La diferencia queda clara: en tablero chico y aislado, RTU es mucho más barato. En planta grande ya cableada con Ethernet para otros fines, el costo marginal de TCP es menor porque la infraestructura ya existe.

Cuándo usar cada uno — matriz de decisión

La decisión rara vez es binaria. La matriz siguiente es la que aplicamos en proyectos reales:

Escenario	RTU	TCP	Por qué
Tablero solar aislado, 4 a 8 dispositivos en el mismo gabinete	Recomendado	Excesivo	Costo, simplicidad, EMC
Sitio de telecom en torre, gabinete único	Recomendado	Excesivo	Mismas razones, ambiente hostil
Subestación 138 kV, varios gabinetes a 50 m	Híbrido	Recomendado para SCADA	EMC favorece RTU local + gateway hacia afuera
Fábrica conectada (Industria 4.0) con MES/historian	En islas locales	Recomendado en el backbone	TCP es el camino natural hacia el SCADA
Edificio comercial con BMS	Posible	Recomendado	Reutiliza la Ethernet existente
Sala de máquinas con variadores VFD	Recomendado	Cuidado con ruido	EMC severa, par diferencial blindado
Data center monitoreando bus DC	Recomendado en rack	TCP para agregar racks	RTU dentro del rack, TCP entre racks

Regla práctica: dentro del gabinete y en tablero aislado, RTU. Entre tableros y hasta el SCADA, TCP. La junción es el gateway, descrita a continuación.

Coexistencia — gateway como punto de unión

En la mayoría de los proyectos reales, RTU y TCP coexisten. El punto de unión es un gateway Modbus RTU↔TCP, que se comporta como maestro RTU de un lado y esclavo TCP del otro (o viceversa, según topología). Marcas habituales: Moxa MGate, HMS Anybus, Advantech EKI, Comtrol DeviceMaster.

Ejemplo simplificado de arquitectura híbrida usando AEM-60DC8:

[ AEM-60DC8 #1 ]──┐
                  ├── RS-485 (Modbus RTU, 19200 8N1) ──> [ Gateway ] ── Ethernet ──> [ SCADA TCP ]
[ AEM-60DC8 #2 ]──┤
[ AEM-60DC8 #3 ]──┘

El gateway suele mapear cada esclavo RTU a un unit ID TCP. El SCADA ve tres "dispositivos TCP" en la misma IP, con unit IDs 1, 2 y 3, y el gateway resuelve internamente el polling RS-485. Cuidados al especificar gateway:

• Buffer de polling: el gateway debe mantener un caché actualizado en background y responder TCP desde el caché, en vez de bloquear la petición TCP esperando al RTU. Sin caché, el tiempo de respuesta del SCADA queda atado al polling RTU más lento.
• Timeout independiente: timeout RTU configurado según el peor esclavo; timeout TCP según el SCADA. Los dos desacoplados.
• Mapeo de excepciones: error RTU (esclavo offline, CRC, timeout) debe convertirse en excepción Modbus TCP correcta, no en silencio.
• Límite de conexiones TCP simultáneas: gateways baratos soportan 2 o 4 conexiones; en proyecto serio, especifique 16 o más.

El AEM-60DC8 en esta decisión — solo RTU, y por qué

Directo al grano: el AEM-60DC8 solo habla Modbus RTU sobre RS-485. No tiene puerto Ethernet. Esa elección de diseño viene de tres frentes.

Cuándo es ventaja:

• Tablero industrial cerrado, donde el monitor está junto al bus DC que vigila y el cable RS-485 nunca sale del gabinete. EMC, costo y simplicidad favorecen RTU.
• Escenario Secure by Design por aislamiento físico: sin puerto de red, sin superficie de ataque IP, sin firmware de stack TCP/IP para auditar. El perímetro de seguridad es el propio tablero.
• Vida útil larga: RS-485 es tecnología estable desde 1983, sin ciclo de obsolescencia tipo "deprecar TLS 1.2 en 2030". El dispositivo instalado hoy habla el mismo protocolo en 20 años.

Cuándo es limitación:

• Proyecto que exige polling TCP directo del SCADA, sin hardware adicional. El AEM-60DC8 no cabe sin gateway.
• Planta ya 100% Ethernet, con política de "nada de serie nueva". El argumento de estandarización vence al técnico.
• Cuando el cliente quiere múltiples maestros leyendo el mismo dispositivo en simultáneo. RTU es maestro único; el gateway solo ayuda parcialmente.

Cómo lo resolvemos en proyecto: el camino recomendado es el AEM-60DC8 hablando RTU dentro del gabinete, conectado a un gateway industrial RTU↔TCP de mercado. El gateway expone el dispositivo como Modbus/TCP al SCADA e implementa los 147 holding registers del firmware v1.03 de forma transparente. Este arreglo entrega lo mejor de ambos mundos: EMC y simplicidad de RTU dentro del tablero, flexibilidad de TCP hacia afuera.

En v1.03 el AEM-60DC8 soporta 4800, 9600, 19200, 38400, 57600 y 115200 bps en RS-485, con dirección Modbus de 1 a 247. La velocidad típica de proyecto en tablero industrial está en 19200 o 38400, que cubre con holgura el polling útil hasta 8 dispositivos en el mismo bus.

FAQ

1. ¿Puedo convertir Modbus RTU a Modbus TCP solo con software, sin gateway dedicado? Sí, hay bridges en software (modpoll, libmodbus, NodeRED con nodo modbus-serial) corriendo en un PC o Raspberry Pi con adaptador USB-RS485. Funciona en laboratorio y en proyectos chicos. En producción 24/7 no lo recomendamos: PC de escritorio tiene MTBF bajo, USB tiene timing imprevisible y cualquier reinicio del SO tira el SCADA. En proyecto serio, gateway industrial dedicado.

2. ¿Modbus TCP es más rápido que Modbus RTU en todos los casos? No. En LAN dedicada con pocos dispositivos, TCP entrega menor latencia por transacción (1–5 ms vs 10–30 ms). Pero en tablero chico con 4 dispositivos a 38400 bps, RTU ya entrega 10 Hz de polling sin switch ni plan de IPs. La pregunta correcta es "qué latencia exige la aplicación", no "qué protocolo es más rápido".

3. ¿Por qué el AEM-60DC8 no tiene Ethernet si la mayoría de las plantas es TCP? Por elección de diseño: foco en tablero industrial cerrado donde la ventaja de costo, simplicidad, EMC y ausencia de superficie de ataque IP supera la flexibilidad de TCP. Para integrar con SCADA TCP, el camino es gateway. Esta elección no cierra el roadmap; es la posición en v1.03.

4. ¿Vale la pena implementar Modbus/TCP Security (TLS) hoy? Vale en escenarios específicos: dispositivos nuevos, SCADA nuevo, política corporativa exigiendo cifrado OT. En campo todavía es minoría — gran parte del parque instalado no lo soporta. Para la mayoría de los proyectos, la defensa real sigue siendo VLAN, firewall, segmentación ISA/IEC 62443 y aislamiento físico, no TLS en la capa de aplicación Modbus.

5. ¿Cómo dimensiono la red RS-485 al sumar AEM-60DC8 a un bus existente? Cuente cargas unitarias (cada AEM-60DC8 es 1 UL en recepción, 0 en idle), verifique polarización del bus (resistor de 120 Ω en las dos puntas, polarización de bias en el maestro), elija un baud común a todos los esclavos y configure dirección única. A 19200 bps con cable hasta 500 m, hasta 16 dispositivos conviven sin problema; por encima de eso, baje a 9600 o separe en dos segmentos con repetidor.