Modbus RTU vs Modbus TCP: como decidir sem cair em mito

O engenheiro de automação que está fechando a especificação de um painel novo costuma chegar nesse ponto com duas vozes na cabeça. De um lado, o veterano de campo diz que "Ethernet em painel industrial não funciona, fica caindo, fica com ruído, fica com latência imprevisível". Do outro, o integrador moderno diz que "RS-485 é dos anos 80, ninguém mais usa, todo SCADA novo é TCP". Os dois exageram. Modbus RTU e Modbus TCP convivem em milhões de plantas em 2026, cada um resolvendo problemas diferentes, e a escolha errada custa cabo, switch e horas de comissionamento. Este post compara os dois protocolos no que importa para decidir: camada física, frame, latência, segurança, custo, cenários de aplicação e como conviver com os dois via gateway. No fim, o papel honesto do AEM-60DC8 nessa decisão.

História rápida — de onde cada um veio

Modbus RTU nasceu em 1979 na Modicon, parte da então recém-criada família de PLCs Modicon 084 e 184. O cenário era um chão de fábrica com PLCs caros e instrumentos de campo simples; o protocolo precisava rodar sobre serial barata (inicialmente RS-232, depois RS-485 quando a Modicon publicou a especificação física) e tinha que ser simples o suficiente para um microcontrolador de 8 bits da época processar em interrupção. O resultado foi um protocolo mestre-escravo, binário, com CRC-16 e tabela de funções compacta. Modicon liberou a especificação como aberta em 2004, hoje mantida pela Modbus Organization.

Modbus TCP apareceu vinte anos depois, em 1999, especificado por Schneider Electric (que tinha comprado a Modicon em 1996) como adaptação do mesmo protocolo de aplicação rodando sobre TCP/IP, porta 502. A motivação foi clara: as plantas estavam se conectando a redes Ethernet corporativas e os SCADA estavam migrando para PCs em rede. Em vez de criar um protocolo novo, Schneider preservou a semântica RTU (mesmas funções, mesmos códigos, mesma estrutura de registradores) e trocou só o transporte. Por isso a curva de aprendizado entre RTU e TCP é pequena para quem já conhece um dos dois.

Vale lembrar que existe um terceiro, Modbus ASCII, que é o mesmo protocolo de aplicação em texto sobre serial. Hoje é raro em campo, usado quase só em diagnóstico ou em sistemas legados com modems analógicos lentos. Esta comparação foca RTU e TCP, que são os dois relevantes em projeto novo.

Camada física — RS-485 vs Ethernet

Aqui é onde os mitos mais aparecem. RS-485 é diferencial, dois fios (mais terra de referência), até 32 cargas unitárias por segmento (1200 m a baixa velocidade), imunidade boa a ruído modo-comum e custo de transceiver na casa de centavos. Ethernet industrial é par trançado categoria 5e ou 6, par diferencial também, 100 m por lance entre nó e switch, exige switches gerenciáveis para qualquer rede séria e tem custo por porta na casa de unidades de dólar.

Aspecto	RS-485 (RTU)	Ethernet (TCP)
Topologia	Barramento (daisy-chain)	Estrela via switch
Distância	Até 1200 m por segmento a 9600 bps	100 m por lance, repetida por switch
Nós por segmento	32 cargas unitárias (até 256 com repetidor)	Limitado só pelo switch
Cabo típico	Par trançado blindado 24 AWG	Cat 5e / Cat 6
Imunidade EMC	Alta (diferencial, baixa impedância)	Alta com cabo blindado e aterramento correto
Custo por nó	Transceiver de US$ 0,50, conector de US$ 1	Porta de switch industrial US$ 30 a US$ 80
Complexidade de configuração	Endereço, baud, paridade	IP, máscara, gateway, VLAN, switch

Na prática, RS-485 ainda ganha em painel pequeno e em interligação ponto-a-ponto em ambientes com EMC ruim (subestações de média tensão, salas de máquinas com inversores). Ethernet ganha em planta grande com muitos dispositivos espalhados e quando a infraestrutura de rede já existe para outros fins (vídeo, IT, gestão).

Frame e overhead — quantos bytes por leitura

Aqui o RTU é mais enxuto, e isso importa em link lento. Um quadro Modbus RTU típico de leitura de 10 holding registers é:

Campo	Bytes
Endereço escravo	1
Função (0x03)	1
Endereço inicial	2
Quantidade de registers	2
CRC-16	2
Total pedido	8 bytes
Resposta: addr+func+bytecount+dados (20)+CRC	25 bytes
Round-trip total	33 bytes

A 9600 bps com 8N1 isso são cerca de 34 ms só de transmissão, mais o tempo de processamento do escravo (tipicamente 2 a 10 ms) e o silêncio inter-frame obrigatório de 3,5 caracteres (3,6 ms a 9600).

O mesmo pedido em Modbus TCP carrega um cabeçalho extra chamado MBAP (Modbus Application Protocol) de 7 bytes: transaction ID (2), protocol ID (2), length (2), unit ID (1). Não há CRC porque o TCP já garante integridade na camada de transporte.

Campo	Bytes
MBAP header	7
Função + endereço + quantidade	5
Total pedido	12 bytes
Resposta: MBAP (7) + func (1) + bytecount (1) + dados (20)	29 bytes
Round-trip total na camada Modbus	41 bytes

Mas acima disso vem o overhead TCP/IP: cabeçalho IP (20), cabeçalho TCP (20), Ethernet (18), o que adiciona ~58 bytes por pacote. Em 100 Mbps isso ainda é microssegundos, mas em poll massivo (1000 nós, 10 Hz) começa a importar para o switch.

Eficiência de polling: em RTU a 19200 bps, um polling cíclico de 8 escravos lendo 32 registers em cada gira em ~250 ms (4 Hz). Em TCP em LAN 100 Mbps, os mesmos 8 nós podem ser lidos em paralelo (múltiplas conexões simultâneas) em <50 ms. Ou seja, RTU é mais "denso" em bytes e TCP é mais paralelo em transações.

Latência e determinismo

RTU é determinístico por construção: mestre fala, escravo responde, ninguém mais fala. O tempo de polling é previsível dentro de uma tolerância pequena (variação de jitter ~1 ms). Para malha de controle de ciclo curto (50 a 200 ms) em painel isolado, RTU entrega latência consistente.

TCP é probabilístico. A latência típica em LAN industrial dedicada fica em 1–5 ms, mas em rede compartilhada com tráfego de vídeo, backup ou roteamento mal configurado, pode subir para dezenas ou centenas de milissegundos sem aviso. Quando TCP ganha é em rede grande com múltiplos masters lendo o mesmo dispositivo (impossível em RTU sem token-passing, que ninguém implementou em Modbus na prática), ou quando os dispositivos estão fisicamente distribuídos por edifícios e a Ethernet já é o caminho natural.

Regra prática: para controle (PID, intertravamento, proteção), RTU em painel isolado tende a entregar latência mais previsível. Para supervisão e historização (SCADA, MES, BI), TCP entrega mais flexibilidade. A maioria dos projetos usa os dois.

Segurança — os dois nasceram nus

Aqui não há vencedor por padrão: nem Modbus RTU nem Modbus TCP têm autenticação, criptografia ou controle de integridade na camada de aplicação. Qualquer um com acesso físico ao barramento (RTU) ou à rede (TCP) pode ler todos os registers e escrever em qualquer um que esteja exposto.

Existe um suplemento chamado Modbus/TCP Security (publicado em 2018), que envelopa o tráfego em TLS 1.2 ou superior na porta 802, com X.509 mútuo. É raro em campo — estimativas conservadoras apontam menos de 1% das instalações Modbus/TCP rodando TLS em 2026. A razão é prática: a maioria dos dispositivos de campo não tem ainda firmware com TLS, e os SCADA legados não falam Modbus/TCP Security.

A defesa real, hoje, é por camadas:

• RTU: isolamento físico. Painel fechado, cabeamento dentro do gabinete, RS-485 não exposto fora da zona controlada. Se o atacante já está dentro do gabinete, o problema é maior que Modbus.
• TCP: segmentação de rede. VLAN dedicada para OT, firewall entre OT e IT, conduits no modelo ISA/IEC 62443, lista branca de IPs por dispositivo, monitoramento de tráfego anômalo. Idealmente, Modbus/TCP Security quando o dispositivo suportar.

O AEM-60DC8 só fala Modbus RTU. A defesa, portanto, é via topologia: o equipamento fica no gabinete junto ao barramento que ele monitora, e o gateway que expõe os dados para a rede corporativa é quem implementa autenticação e isolamento.

Custo total — não é só o preço do dispositivo

A conta honesta inclui cabo, conector, switch, treinamento e tempo de comissionamento. Exemplo simplificado de um painel com 6 dispositivos:

Item	Modbus RTU	Modbus TCP
Cabo (par trançado vs Cat 5e)	80 m × R$ 4 = R$ 320	6 lances × 15 m × R$ 6 = R$ 540
Conectores	12 × R$ 5 = R$ 60	12 × R$ 10 = R$ 120
Switch / conversor	1 conversor USB-RS485 R$ 200	Switch industrial 8 portas R$ 1.800
Treinamento (horas-engenheiro)	4 h (endereço, baud)	12 h (IP, VLAN, switch)
Tempo de comissionamento típico	2 a 4 h	4 a 8 h
Total estimado de hardware	~R$ 580	~R$ 2.460

Esse exemplo é simplificado e não inclui mão de obra de lançamento de cabo, que é parecida nos dois casos. O salto fica claro: em painel pequeno e isolado, RTU é dramaticamente mais barato. Em planta grande já cabeada com Ethernet para outros fins, o custo marginal do TCP é menor porque a infraestrutura existe.

Quando usar cada um — matriz de decisão

A decisão raramente é binária. A matriz abaixo é o que usamos em projeto:

Cenário	RTU	TCP	Por quê
Painel solar isolado, 4 a 8 dispositivos no mesmo gabinete	Recomendado	Excessivo	Custo, simplicidade, EMC
Estação telecom em torre, gabinete único	Recomendado	Excessivo	Mesmo motivo, mais ambiente hostil
Subestação 138 kV, vários gabinetes a 50 m	Híbrido	Recomendado para SCADA	EMC favorece RTU local + gateway para fora
Fábrica conectada (Indústria 4.0) com MES/historian	Em ilhas locais	Recomendado no backbone	TCP é o caminho natural até o SCADA
Edifício comercial com automação predial	Possível	Recomendado	Reuso da rede Ethernet existente
Sala de máquinas com inversores VFD	Recomendado	Cuidado com ruído	EMC severa, par diferencial blindado
Datacenter monitorando barramento DC	Recomendado em rack	TCP para agregar racks	RTU dentro do rack, TCP entre racks

A regra prática: dentro do gabinete e em painel isolado, RTU. Entre painéis e até o SCADA, TCP. A junção é o gateway, descrito na próxima seção.

Coexistência — gateway como ponto de junção

Na maioria dos projetos reais, RTU e TCP coexistem. O ponto de junção é um gateway Modbus RTU↔TCP, que se comporta como mestre RTU em um lado e escravo TCP no outro (ou vice-versa, dependendo da topologia). Marcas comuns no mercado: Moxa MGate, HMS Anybus, Advantech EKI, Comtrol DeviceMaster.

Exemplo simplificado de arquitetura híbrida usando AEM-60DC8:

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

O gateway tipicamente mapeia cada escravo RTU para um unit ID TCP. O SCADA enxerga três "dispositivos TCP" no mesmo IP, com unit IDs 1, 2 e 3, e o gateway resolve internamente o polling RS-485. Cuidados ao especificar gateway:

• Buffer de polling: o gateway deve manter um cache atualizado em background e responder o TCP a partir do cache, em vez de bloquear a requisição TCP esperando o RTU responder. Sem cache, o tempo de resposta do SCADA fica atrelado ao polling RTU mais lento.
• Timeout independente: timeout RTU configurado conforme o pior escravo; timeout TCP configurado conforme o SCADA. Os dois desacoplados.
• Mapeamento de exceções: erro RTU (escravo offline, CRC, timeout) deve virar exceção Modbus TCP correta, não silêncio.
• Limite de conexões TCP simultâneas: gateways baratos suportam 2 ou 4 conexões; em projeto sério, especifique 16 ou mais.

O AEM-60DC8 nessa decisão — só RTU, e por quê

Para ser direto: o AEM-60DC8 só fala Modbus RTU sobre RS-485. Não tem porta Ethernet. Essa decisão de projeto vem de três frentes.

Quando isso é vantagem:

• Painel industrial fechado, onde o monitor fica junto ao barramento DC monitorado e o cabo RS-485 nunca sai do gabinete. EMC, custo e simplicidade favorecem RTU.
• Cenário Secure by Design por isolamento físico: sem porta de rede, sem superfície de ataque IP, sem firmware de stack TCP/IP para auditar. O perímetro de segurança é o painel.
• Vida útil longa: RS-485 é tecnologia estável desde 1983, sem ciclo de obsolescência de "deprecate TLS 1.2 em 2030". O dispositivo instalado hoje fala o mesmo protocolo daqui a 20 anos.

Quando isso é limitação:

• Projeto que exige polling TCP direto do SCADA, sem hardware adicional. O AEM-60DC8 não cabe sem gateway.
• Planta já 100% Ethernet, com política de "nada de serial novo". Argumento de padronização vence técnica.
• Quando o cliente quer múltiplos masters lendo o mesmo dispositivo simultaneamente. RTU é mestre-escravo único; o gateway só ajuda parcialmente.

Como resolvemos no projeto: o caminho recomendado é o AEM-60DC8 falando RTU dentro do gabinete, conectado a um gateway industrial RTU↔TCP de mercado. O gateway expõe o dispositivo como Modbus/TCP no SCADA e implementa as 147 holding registers do firmware v1.03 transparentemente. Esse arranjo entrega o melhor dos dois mundos: EMC e simplicidade de RTU dentro do painel, flexibilidade de TCP para fora dele.

Em v1.03, o AEM-60DC8 suporta 4800, 9600, 19200, 38400, 57600 e 115200 bps em RS-485, com endereço Modbus de 1 a 247. A velocidade típica de projeto em painel industrial fica em 19200 ou 38400, que cobre folgadamente o polling útil até 8 dispositivos no mesmo barramento.

FAQ

1. Posso converter Modbus RTU em Modbus TCP só com software, sem gateway dedicado? Sim, existem bridges em software (modpoll, libmodbus, NodeRED com nó modbus-serial) rodando em um PC ou Raspberry Pi com adaptador USB-RS485. Funciona em laboratório e em projetos pequenos. Em produção 24/7 não recomendamos: PC desktop tem MTBF baixo, USB tem timing imprevisível e qualquer reinicialização do SO derruba o SCADA. Em projeto sério, gateway industrial dedicado.

2. Modbus TCP é mais rápido que Modbus RTU em todos os casos? Não. Em LAN dedicada com poucos dispositivos, TCP entrega latência menor por transação (1–5 ms vs 10–30 ms). Mas em painel pequeno com 4 dispositivos a 38400 bps, RTU já entrega 10 Hz de polling sem precisar de switch ou IP. A pergunta certa é "qual a latência exigida pela aplicação", não "qual protocolo é mais rápido".

3. Por que o AEM-60DC8 não tem Ethernet se a maioria das plantas é TCP? Por escolha de projeto: foco em painel industrial fechado onde a vantagem de custo, simplicidade, EMC e ausência de superfície de ataque IP supera a flexibilidade do TCP. Para integração com SCADA TCP, o caminho é gateway. Essa escolha não fecha o roadmap; é a posição em v1.03.

4. Modbus/TCP Security (TLS) vale a pena implementar hoje? Vale em cenários específicos: dispositivos novos, SCADA novo, política corporativa exigindo criptografia OT. Em campo, ainda é minoria — boa parte do parque instalado não suporta. Para a maioria dos projetos, a defesa real continua sendo VLAN, firewall, segmentação ISA/IEC 62443 e isolamento físico, não TLS na camada de aplicação Modbus.

5. Como dimensionar a rede RS-485 quando quero adicionar AEM-60DC8 a um barramento existente? Conte cargas unitárias (cada AEM-60DC8 é 1 UL em receive, 0 em idle), confira a polarização do barramento (resistor de 120 Ω nas duas pontas, polarização de bias do mestre), defina baud comum a todos os escravos e configure endereço único. Em 19200 bps com cabo até 500 m, até 16 dispositivos convivem sem problema; acima disso, ou troque para 9600 ou separe em dois segmentos com repetidor.