Modbus RTU guia completo para engenheiros de campo

Quatro décadas depois de sua publicação, o Modbus RTU continua presente em painéis novos, retrofits de subestação e linhas de manufatura recém-comissionadas. A pergunta razoável em 2026 é por que um protocolo serial, sem segurança nativa e com modelo de dados de 16 bits ainda compete com OPC UA, MQTT Sparkplug e variantes industriais sobre TCP. A resposta é prática: existe uma base instalada de centenas de milhões de dispositivos que falam Modbus RTU, a especificação é aberta e estável desde 1996, qualquer microcontrolador de oito bits implementa a pilha em poucos kilobytes e o custo de transceiver RS-485 ficou abaixo de um dólar. Este guia consolida o que um engenheiro de campo precisa para integrar, depurar e documentar um link Modbus RTU com qualidade industrial. O foco é o frame binário, os tipos de dados, o mapeamento real de um dispositivo, a comparação com TCP, o tratamento de exceções e as armadilhas de camada física que aparecem em obras reais.

O que é Modbus RTU

O Modbus foi publicado pela Modicon em 1979 como linguagem de comunicação entre o CLP 084 e periféricos remotos. A variante RTU (Remote Terminal Unit) é a codificação binária do protocolo sobre uma linha serial assíncrona, em contraste com o Modbus ASCII (caracteres hexadecimais legíveis, com overhead aproximadamente dobrado) e o Modbus TCP (encapsulado em sockets IP, sem CRC). A especificação atual é mantida pela Modbus Organization e referenciada em normas como a IEC 61158 (família de fieldbus industriais), que cataloga o Modbus como Type 15.

A camada física típica é EIA/TIA-485 (frequentemente chamada de RS-485), diferencial, half-duplex, multidrop, com até 32 cargas unitárias por segmento sem repetidor. Também é possível operar Modbus RTU sobre RS-232 ponto a ponto, embora seja incomum em instalações novas. O modelo é cliente/servidor estrito: existe um único cliente (anteriormente chamado de "master") que inicia transações, e até 247 servidores ("slaves") endereçáveis no mesmo barramento. Servidores nunca falam espontaneamente; eles apenas respondem ao endereço unicast direcionado a eles ou processam silenciosamente requisições broadcast em endereço 0.

A taxa de transmissão usual cobre 4800, 9600, 19200, 38400, 57600 e 115200 bps. A especificação obriga o suporte a 9600 e 19200 bps; as demais são opcionais. O formato de caractere padrão é 11 bits: 1 start, 8 dados, 1 paridade par, 1 stop. Quando a paridade é desativada, dois stop bits são obrigatórios para preservar o tempo total do caractere.

Frame Modbus RTU

O frame RTU é delimitado por silêncio na linha, não por caracteres especiais. A especificação define que o intervalo entre dois frames consecutivos seja de no mínimo 3,5 tempos de caractere (t3,5) e que o intervalo entre dois caracteres dentro do mesmo frame não ultrapasse 1,5 tempo de caractere (t1,5). Para taxas acima de 19200 bps, esses tempos são fixados em 1750 µs e 750 µs, respectivamente, por recomendação da especificação.

A estrutura do frame é:

Campo	Tamanho (bytes)	Conteúdo
Endereço	1	0 (broadcast) ou 1–247 (unicast); 248–255 reservado
Function code	1	Código da operação solicitada
Data	0–252	Parâmetros da função (endereços, quantidades, valores)
CRC-16	2	Polinômio 0xA001, low byte primeiro

O tamanho máximo do PDU (Protocol Data Unit) é 253 bytes, o que leva o frame ADU (Application Data Unit) RTU a no máximo 256 bytes considerando endereço e CRC. O CRC é calculado sobre endereço, function code e data; o registrador inicia em 0xFFFF e usa o polinômio reverso 0xA001. Implementações via tabela de 256 entradas resolvem o cálculo em microssegundos mesmo em MCUs modestos.

Os quatro function codes mais usados em campo são:

• 0x03 Read Holding Registers: lê 1 a 125 holding registers consecutivos. É a operação dominante em supervisórios.
• 0x04 Read Input Registers: lê 1 a 125 input registers (somente leitura) consecutivos. Usado para grandezas medidas em tempo real.
• 0x06 Write Single Register: escreve um valor de 16 bits em um único holding register. Útil para comandos e setpoints individuais.
• 0x10 Write Multiple Registers: escreve 1 a 123 holding registers em uma única transação. Indispensável para configurar blocos parametrizáveis.

Existem ainda 0x01/0x02 para coils e discrete inputs, 0x05 para coil único, 0x0F para múltiplos coils, 0x17 (read/write multiple), 0x16 (mask write) e 0x2B (read device identification). A função 0x08 (diagnostics) é útil para sondar a saúde do enlace, mas o suporte varia por fabricante.

Tipos de dados Modbus

O modelo de dados original do Modbus reflete a memória do CLP 984 da Modicon, com quatro tabelas distintas. A confusão clássica entre "endereço lógico" (1-based, com prefixos 0/1/3/4) e "endereço de protocolo" (0-based, transmitido no frame) é fonte permanente de erro em integrações.

Tabela	Acesso	Tamanho	Endereço lógico	Endereço de protocolo	Function codes
Coils	Leitura/escrita	1 bit	00001–09999	0x0000–0x270E	0x01, 0x05, 0x0F
Discrete inputs	Somente leitura	1 bit	10001–19999	0x0000–0x270E	0x02
Input registers	Somente leitura	16 bits	30001–39999	0x0000–0x270E	0x04
Holding registers	Leitura/escrita	16 bits	40001–49999	0x0000–0x270E	0x03, 0x06, 0x10, 0x16

Valores de 32 bits (float, int32, contadores de energia) são armazenados em dois holding registers contíguos. A ordem dos bytes e dos registros varia entre fabricantes: ABCD (big-endian puro), CDAB (word swap), BADC (byte swap) e DCBA (full reverse). Documentar essa ordem é tão importante quanto documentar o endereço; integrações que falham apenas com valores grandes quase sempre têm o swap errado.

Como mapear um dispositivo real

A documentação do mapa de registros é o ativo de integração mais importante de qualquer equipamento Modbus. Como exemplo prático, considere o AEM-60DC8, monitor industrial de tensão DC de 8 canais, que expõe na versão de firmware v1.03 um total de 147 holding registers organizados em 17 blocos funcionais.

O recorte abaixo é um exemplo simplificado com fins didáticos; o mapa autoritativo é o anexo B do manual técnico do produto:

Bloco	Faixa (hex)	Registros	Tipo	Observação
Tensão CH1–CH8 (instantânea)	0x0000–0x0007	8	int16	Valor em mV, signed
Tensão CH1–CH8 (média 1 s)	0x0008–0x000F	8	int16	Janela móvel de 1 segundo
Status de alarme global	0x0100	1	bitfield	Bit i indica canal i em violação
Limites superiores CH1–CH8	0x0110–0x0117	8	int16	Escrita habilitada
Limites inferiores CH1–CH8	0x0118–0x011F	8	int16	Escrita habilitada
Contadores de evento	0x0200–0x020F	16	uint16	2 contadores por canal
Identificação e firmware	0x0F00–0x0F0F	16	ASCII/u16	Inclui versão v1.03

Boas práticas ao publicar um mapa: indicar unidade física, escala (multiplicador e offset), faixa válida, valor de "dado inválido" (tipicamente 0x8000 para int16) e se o registro é volátil ou persistente. Para o leitor do mapa, o que importa é o contrato — não a estrutura interna do firmware.

Modbus RTU vs Modbus TCP

A escolha entre RTU e TCP raramente é estética; depende de topologia, latência aceita e infraestrutura existente.

Critério	Modbus RTU	Modbus TCP
Camada física	RS-485 ou RS-232	Ethernet 10/100/1000 Mbps
Topologia	Multidrop (até 32 nós sem repetidor)	Estrela via switch
Endereçamento	1 byte (1–247)	IP + Unit Identifier
Integridade	CRC-16	Checksum TCP (sem CRC Modbus)
Enquadramento	Por silêncio (t3,5)	Cabeçalho MBAP (7 bytes)
Latência típica	5–50 ms por transação	<5 ms em LAN dedicada
Custo de hardware	Muito baixo	Moderado (PHY, switch industrial)
Distância sem repetidor	Até 1200 m a 9600 bps	100 m por segmento (cobre)
Determinismo	Alto (apenas o cliente fala)	Sujeito a colisões lógicas e congestionamento
Imunidade EMI	Excelente (par diferencial)	Boa, depende de cabeagem
Concorrência	Um cliente, um diálogo por vez	Múltiplos clientes simultâneos

A regra prática é: barramento físico longo, ruidoso e com muitos dispositivos baratos pede RTU; integração com SCADA moderno, múltiplos supervisórios concorrentes e taxas amostrais agressivas pede TCP. Gateways RTU↔TCP são lugar-comum e resolvem cenários híbridos sem reescrever firmware.

Erros e exceções

Quando o servidor reconhece a requisição mas não consegue atendê-la, ele responde com o function code original somado a 0x80 e um byte de código de exceção. Os mais comuns no campo:

Código	Nome	Causa típica
0x01	Illegal Function	Function code não implementado pelo servidor
0x02	Illegal Data Address	Endereço fora do mapa ou bloco proibido
0x03	Illegal Data Value	Quantidade fora de 1–125 ou valor fora da faixa permitida
0x04	Slave Device Failure	Erro interno (memória, hardware, autocheck)

Erros 0x05 (Acknowledge), 0x06 (Slave Busy), 0x08 (Memory Parity Error) e 0x0B (Gateway Target Failed to Respond) aparecem em cenários específicos — programação longa, dispositivos com fila e gateways respectivamente. Quando não há nenhuma resposta dentro do timeout (tipicamente 100–500 ms), o cliente deve registrar timeout, não exception; a diferença é diagnóstica.

A rotina recomendada de debug em campo é: (1) confirmar baud rate, paridade e stop bits idênticos nos dois lados; (2) confirmar endereço do servidor; (3) capturar o tráfego bruto com analisador serial ou sniffer Modbus; (4) validar o CRC da requisição manualmente; (5) testar o mesmo registro com um cliente conhecido (QModMaster, mbpoll); (6) só então suspeitar do firmware do servidor.

Boas práticas de instalação RS-485

A maioria das falhas atribuídas ao "Modbus instável" é, na verdade, problema de camada física. A norma EIA-485 dimensiona o transceiver, mas o projeto do barramento é responsabilidade do integrador.

• Topologia: linha de transmissão única (daisy-chain), sem estrelas e sem stubs maiores que 30 cm. Estrelas curtas funcionam em laboratório e falham em obra com ruído.
• Terminação: resistor de 120 Ω em cada extremidade física do barramento, casado com a impedância característica do par. Terminar apenas uma ponta gera reflexão.
• Polarização (bias): resistores de pull-up no A e pull-down no B (tipicamente 680 Ω a 1 kΩ) para manter estado idle definido. Sem polarização, o primeiro bit após silêncio pode ser interpretado errado.
• Cabo: par trançado blindado de impedância 120 Ω (ex.: Belden 9841 ou equivalente). A blindagem aterrada em um único ponto, normalmente no painel do cliente Modbus.
• Referência de terra: condutor adicional (signal common) interligando todos os GNDs dos transceivers via resistor de 100 Ω/0,5 W em cada nó, limitando corrente de modo comum.
• Comprimento × taxa: a relação clássica é até 1200 m a 9600 bps; em 115200 bps fique abaixo de 100 m para preservar margem de jitter.
• Isolação galvânica: obrigatória em ambientes com VFDs, soldagem ou aterramentos questionáveis. Transceivers isolados resolvem mais problemas que repetidores ativos.
• Separação de cabeamento: distância mínima de 30 cm de cabos de potência; cruzamentos sempre em ângulo de 90°.

Um barramento bem dimensionado a 19200 bps com 16 dispositivos é mais confiável e mais fácil de manter do que o mesmo barramento empurrado a 115200 bps sem necessidade real. Performance não é objetivo isolado em Modbus RTU.

Como testar sua integração

Antes de subir o supervisório, vale exercitar o mapa de registros contra um servidor controlado. A LRI disponibiliza um simulador em Python que emula o comportamento de um AEM-60DC8 — incluindo os 147 holding registers, os blocos de alarme e a curva de leitura dos 8 canais — sobre porta serial virtual ou TCP encapsulado. Conceitualmente, o simulador permite:

• Validar o cliente sem o equipamento físico em mãos.
• Forçar condições de borda (canal em sobretensão, alarme global, falha de canal) que seriam difíceis de provocar em bancada.
• Executar testes de regressão automatizados em CI a cada mudança no supervisório.
• Comparar duas implementações do cliente (ex.: legado vs. novo) lendo o mesmo conjunto de registros.

A combinação de um simulador determinístico com o equipamento real reduz drasticamente o tempo de comissionamento. Para conhecer o mapa de registros completo, as faixas elétricas e os modos Secure by Design do produto, consulte a página do AEM-60DC8 e a documentação técnica disponível em aem.lri.com.br.

Conclusão

O Modbus RTU sobrevive porque resolve um problema bem definido: transportar inteiros de 16 bits entre um cliente e dezenas de servidores em um par de fios, de forma previsível, barata e auditável. Saber ler um frame, mapear holding registers com clareza, dimensionar a camada física e diagnosticar exceções é o ferramental mínimo do engenheiro que integra equipamentos industriais em 2026. Protocolos modernos vão coexistir com o RTU por muito tempo, e o profissional capaz de transitar entre serial e TCP, entre CRC e TLS, é o que entrega projetos no prazo. O AEM-60DC8 foi projetado para esse profissional, com mapa de registros estável, simulador disponível e postura Secure by Design.

Perguntas frequentes

Modbus RTU ainda é usado em 2026? Sim. A base instalada é da ordem de centenas de milhões de dispositivos, e a maioria dos retrofits industriais ainda exige compatibilidade com RTU. Equipamentos novos costumam expor RTU e TCP simultaneamente.

Qual a diferença entre holding registers e input registers? Holding registers são leitura/escrita (function codes 0x03, 0x06, 0x10), tipicamente usados para parâmetros, setpoints e configurações. Input registers são somente leitura (function code 0x04), reservados a grandezas medidas.

Como descobrir o endereço Modbus RTU de um dispositivo desconhecido? A varredura sistemática nos endereços 1–247 com leitura de um registro provável (por exemplo, 0x0000) é a abordagem padrão. Ferramentas como mbpoll e QModMaster automatizam a varredura. Em barramentos críticos, faça a varredura offline para evitar ruído nas trocas normais.

Modbus RTU é seguro? A especificação não prevê autenticação nem criptografia. A boa prática é isolar fisicamente o barramento e usar gateways com filtragem para qualquer ponte com redes não confiáveis. Equipamentos com postura Secure by Design complementam o Modbus com controles em camadas adjacentes (assinatura de firmware, registros de auditoria, separação de planos).

Posso ter dois clientes (masters) no mesmo barramento RTU? Não na especificação clássica. O modelo é estritamente um cliente por barramento. Cenários com múltiplos supervisórios exigem gateway com arbitragem, troca para Modbus TCP ou segmentação física do barramento.

---

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Modbus RTU ainda é usado em 2026?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sim. A base instalada é da ordem de centenas de milhões de dispositivos, e a maioria dos retrofits industriais ainda exige compatibilidade com RTU. Equipamentos novos costumam expor RTU e TCP simultaneamente."
      }
    },
    {
      "@type": "Question",
      "name": "Qual a diferença entre holding registers e input registers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Holding registers são leitura/escrita (function codes 0x03, 0x06, 0x10), tipicamente usados para parâmetros, setpoints e configurações. Input registers são somente leitura (function code 0x04), reservados a grandezas medidas."
      }
    },
    {
      "@type": "Question",
      "name": "Como descobrir o endereço Modbus RTU de um dispositivo desconhecido?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A varredura sistemática nos endereços 1 a 247 com leitura de um registro provável é a abordagem padrão. Ferramentas como mbpoll e QModMaster automatizam a varredura."
      }
    },
    {
      "@type": "Question",
      "name": "Modbus RTU é seguro?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A especificação não prevê autenticação nem criptografia. A boa prática é isolar fisicamente o barramento e usar gateways com filtragem para qualquer ponte com redes não confiáveis. Equipamentos com postura Secure by Design complementam o Modbus com controles em camadas adjacentes como assinatura de firmware e registros de auditoria."
      }
    },
    {
      "@type": "Question",
      "name": "Posso ter dois clientes (masters) no mesmo barramento RTU?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Não na especificação clássica. O modelo é estritamente um cliente por barramento. Cenários com múltiplos supervisórios exigem gateway com arbitragem, troca para Modbus TCP ou segmentação física do bar