Rede Modbus RTU

Redes de comunicação constituem um tema de crescente importância em sistemas de automação industrial. Atualmente, diversos
dispositivos utilizados em automação industrial são providos de interfaces de comunicação para algum tipo de rede. Alguns dispositivos,
como controladores programáveis, fornecem múltiplas opções de rede de comunicação, cada uma delas talhada para determinada classe
de aplicação

São muitos os motivos que determinaram a disseminação das redes de comunicação, entre os quais pode-se citar:

-O barateamento dos microprocessadores e interfaces de comunicação serial. Isto determinou a proliferação de dispositivos inteligentes
de baixo custo que se comunicam com outros dispositivos inteligentes. O alcance desta comunicação pode variar desde poucos metros
(dentro de uma sala), até os limites de empresas, cidades, estados e países.

-A dificuldade, falta de espaço e alto custo, quando não impossibilidade, de passar centenas ou milhares de fios de instrumentação ao
longo de distâncias que podem variar de poucos metros a milhares de quilômetros. Uma rede de comunicação tem a capacidade de
transmitir através de um único fio uma quantidade muito grande de informações. Isto pode substituir milhares de fios de
instrumentação, propiciando grande economia de espaço e fiação.

-A distribuição e especialização do processamento. Ao invés de concentrar a inteligência num único controlador ou computador central
ligado por fios em instrumentos “burros”, as redes possibilitam subdividir grandes tarefas em diversas sub-tarefas especializadas
executadas por diversos componentes de uma rede de comunicação (controladores, instrumentos inteligentes, etc).

-Disponibilidade com custos cada vez mais acessíveis de diversos meios de comunicação públicos ou privados, tais como cabos elétricos,
fibras óticas, rádio, micro-ondas, satélites, infra-estrutura telefônica, e outros.

Com este artigo, inauguramos uma série sobre diversas redes de comunicação existentes no mercado de automação industrial, algumas
similares entre si, outras com características e aplicações diferentes.

Iniciaremos com uma rede bastante simples e extremamente popular, que é a rede MODBUS RTU. Devido à sua simplicidade, é uma boa
oportunidade para introduzir conceitos básicos que futuramente serão úteis para outros tipos de redes de comunicação.

Modbus RTU – Um padrão “de fato”

A rede MOBUS RTU foi criada em 1978 pela empresa Modicon, fabricante de controladores programáveis. Ao invés de definir a rede
como proprietária (uso exclusivo) da empresa, o protocolo foi aberto e disponibilizado para uso geral. Devido à simplicidade de sua
implementação, e ao pioneirismo de ser um protocolo aberto, alcançou enorme popularidade entre fabricantes de diversos tipos de
dispositivos de automação, tais como:

-controladores programáveis
-computadores de supervisão
-terminais de operação
-instrumentos de medição e atuação (medidores de vazão, válvulas inteligentes, medidores de energia)
-RTUs (remote terminal units), ou unidades de entrada e saída remotas
-relés de proteção elétrica
-controladores PID multi-loop

Existe outra versão similar a rede MODBUS RTU, chamada de MODBUS ASCII, que no entanto não possui tanta aceitação, porque
necessita de mais “bits” para transmitir a mesma informação que MODBUS RTU. Neste artigo, nos restringiremos a MODBUS RTU,
embora os conceitos e estruturas de ambas sejam muito semelhantes.

Arquitetura Típica de um Equipamento com Interface MODBUS RTU

A figura 1 mostra a arquitetura de um equipamento com interface de comunicação MODBUS RTU. Trata-se de um exemplo de
equipamento de E/S Remoto (entradas e saídas remotas), também conhecido como RTU (Remote Terminal Unit). Observa-se que basta
um microprocessador (CPU, uma UART (Universal Asynchronous Receiver Transmitter), um conversor de meio físico, e um conector,
além de alguns cristais. O sistema de E/S (entradas e saídas) foi simplificado no desenho, pois não é o interesse primordial deste artigo.

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 F.1 – Hardware Típico de um Interface MODBUS RTU para E/S Remoto

O conector é o limite físico do interface de comunicação do equipamento. Nele se conectam os cabos de comunicação, que podem ser
ligados a outros equipamentos com interface MODBUS RTU de forma direta ou indireta, como veremos adiante. No conector,
encontram-se os pinos de transmissão e recepção de dados, além de outros pinos auxiliares (terra de sinal, e sinais de controle
eventualmente necessários).

O sinal de transmissão para o conector provém de um componente denominado transmissor ou “driver” (TX), e o sinal de recepção do
conector chega a um componente determinador receptor ou “receiver” (RX). Estes componentes têm a função de transformar a
codificação elétrica do sinal dentro do equipamento (TTL, CMOS, etc) numa codificação adequada para a rede de comunicação externa ao
equipamento (RS-232, RS-485, fibra ótica, etc).

A UART é uma unidade de conversão paralela/serial assíncrona. Ela transforma os dados vindos de forma paralela da CPU (via “data bus”
ou barramento de dados) em um sinal único serial que será transmitido via TX. De forma similar, a UART transforma os dados vindos de
forma serial da rede de comunicação via RX para dados na forma paralela que podem ser lidos pela CPU.

A CPU e a UART se comunicam através do “data bus” de forma paralela (um barramento de 8 ou 16 bits, tipicamente), com auxílio das
linhas de controle RD (read) e WR (write). A linha de interrupção (INTR) é utilizada pela UART para avisar a CPU sobre a recepção de
um ou mais bytes via RX, ou para avisar a CPU que os bytes que a mesma solicitou transmitir já foram transmitidos. INTR também pode
avisar sobre condições de erro na recepção de dados, entre outras funções. Registradores especializados dentro da UART permitem a
leitura e escrita de dados, códigos de erros, sinais de controle, configuração da velocidade de transmissão (baudrate), etc.

Observa-se que há um cristal para a UART, que utiliza o sinal de “clock” gerado como base de tempo para determinar o tempo de duração
de cada bit na comunicação serial. Quanto menor a duração do bit, maior a taxa de comunicação (ou baudrate), medida em bits por
segundo (bps). Redes velozes possuem altos baudrates. A rede MODBUS normalmente opera com baudrates entre 110 bps e 115.200 bps
(mais tipicamente entre 9600 e 38400 bps).

Comunicação Serial Assíncrona

Dentro de um equipamento (computador, controlador programável, etc) os diversos componentes (microprocessadores, memória,
periféricos, UART) se comunicam tipicamente de maneira paralela, através do “data bus” e linhas de controle para leitura (RD) e escrita
(WR). Trata-se de uma comunicação paralela pois utiliza diversas linhas de dados (barramentos de 8, 16, 32 e até 64 bits são comuns). A
comunicação paralela é rápida e eficiente, mas exige diversas linhas de dados e linhas de controle (RD, WR). Ela tipicamente só é viável
em espaços pequenos e confinados, como o interior de um equipamento, sendo impraticável dos pontos de vista técnico e econômico em
distâncias maiores, como as envolvidas numa rede de comunicação.

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 Quando se trata de comunicação à distância, tipicamente é necessário utilizar comunicação serial, através de um único fio ou par de fios
(o fio de sinal, e uma referência, por exemplo). Neste caso, é imperativo economizar fiação e número de canais de comunicação.

Para transformar entre os padrões serial e paralelo, utilizam-se as UARTs, mencionadas anteriormente. A figura 2 mostra uma
seqüência de 2 bytes de dados em formato serial, como seria possível visualizar num osciloscópio.

F.2 – Seqüência de 2 bytes de dados numa linha serial assíncrona em nível RS-232C

Em primeiro lugar, como neste exemplo o nível elétrico é RS-232C, há 2 níveis de tensão. Tipicamente, o nível baixo é da ordem de –10 V
e o nível alto é de +10 V. Quando nenhum dado está sendo transmitido na linha (linha inativa), ela permanece no nível baixo (-10 V).

Observa-se que cada um dos bytes contém 11 bits (8 bits ou um byte de dados propriamente ditos, e outros 3 bits auxiliares). Na figura
anterior, estes bits foram numerados de 1 a 11. As linhas pontilhadas verticais separam os bits consecutivos dentro de cada byte, e a linha
cheia mostra o sinal elétrico. A duração de cada bit depende do baudrate (taxa de bits por segundo ou bps). Por exemplo, com 9600 bps, o
tempo de 1 bit vale 1/9600 segundos, ou seja, aproximadamente 0,1 ms.

O primeiro bit de cada byte (índice 1) é o “start bit” (SA). Ele sempre está em nível alto (+10 V), e indica que a linha saiu da condição
inativa. Ou seja, o “start bit” indica que um novo byte está começando.

Os próximos 8 bits (índices de 2 até 9) correspondem ao byte de dados propriamente dito. Um bit tem o valor 0 caso esteja em +10 V, e o
valor 1 caso esteja em –10V. Na figura, o primeiro byte vale “11011100” e o segundo byte vale “01011010” (o primeiro bit de cada byte de
dados – índice 2 - é o bit menos significativo do byte).

O bit 10 é um bit de paridade opcional. Ele pode não existir, pode ser fixo em 0, fixo em 1, par ou ímpar. O bit de paridade, quando
existente, auxilia a detectar se um byte recebido está íntegro ou foi distorcido. Na figura 2, estamos utilizando paridade ímpar. Isto
significa que o número total de bits em nível “1” (-10 V), considerando os bits entre os índices 2 e 10, deve ser ímpar. Portanto, o valor do
bit 10 (paridade) é calculado contando o número de bits anteriores (2 a 9) em nível

1. Se este número for par, o bit de paridade deve valer 1, para que se tenha um número ímpar de 1s. Do contrário, o bit de paridade deve
valer 0. Se um receptor observar que esta regra não é obedecida num byte recebido, ele sabe que alguma distorção (exemplo: ruído)
ocorreu durante a transmissão na rede de comunicação. Então o receptor acusa um “erro de paridade”. Este é um método de segurança
bastante utilizado mas não suficiente. Outros métodos de segurança complementares devem ser utilizados para que um receptor não
aceite dados distorcidos na linha de comunicação.

Finalmente, o bit 11 é o “stop bit”, que sempre está em –10 V, a mesma condição de linha inativa. Pode-se ter 1 ou 2 stop bits, e em nosso

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 exemplo há um único. Seu objetivo é garantir um tempo mínimo de inatividade na linha, para que o próximo start bit possa ser detectado,
como indicador do início de um novo byte. Esta estratégia é utilizada porque os sistemas que se comunicam não são sincronizados, e seus
“clocks” de baudrate podem ser levemente diferentes. Por este motivo este tipo de comunicação se chama de assíncrona. A cada novo
byte, ocorre uma “ressincronização”.

Na figura anterior ainda se mostra um tempo de inatividade adicional entre o final do stop bit do primeiro byte e o início do start bit do
segundo byte. Este tempo pode eventualmente existir entre bytes intermediários de uma mensagem, mas tipicamente não existe em
CPUs/UARTs modernas.

ETDs e ECDs, e Topologias de Comunicação Típicas para Modbus RTU

Dois equipamentos que trocam dados (equipamento produtor dos dados e equipamento consumidor dos dados) podem fazê-lo de forma
direta (exemplo: ligados diretamente por um cabo de comunicação) ou indireta (exemplo: ligados através de modems).

Os equipamentos que produzem e consomem dados são chamados de ETDs (equipamentos terminais de dados). Os equipamentos
auxiliares, que intermediam a comunicação entre os ETDs mas não produzem nem consomem estes dados, são denominados ECDs
(equipamentos de comunicação de dados).

Exemplos de ETDs:

-computadores
-controladores programáveis
-transmissores inteligentes
-E/S remoto

Exemplos de ECDs:

modems de linha telefônica (privada ou discada)

conversores RS-232/RS-485/fibra ótica
modems-rádio

A figura 3 mostra um exemplo de rede de comunicação mista, formada por diversos tipos de ETDs e ECDs, e utilizando diversas
tecnologias de comunicação. Os ECDs, na figura, recebem os nomes comerciais típicos (modems, rádios, conversores, etc).

F.3 - Exemplo de rede com diversas tecnologias de transmissão de dados

Observam-se diversos meios físicos de transmissão na figura, tais como RS-485, linhas telefônicas, RS-232, fibra ótica e rádio. Nesta
rede, tudo que determinado ETD transmite é recebido por todos os demais ETDs.

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 Embora possa parecer estranha tal mistura de meios físicos diferentes numa única rede, posso testemunhar por experiência que já vi
diversos casos semelhantes em aplicações práticas. Por exemplo, em aplicações de saneamento, existem diversas estações espalhadas
numa região urbana (estações de tratamento de água, estações de bombeamento, reservatórios de água, etc), e os meios disponíveis para
conectar todas estas estações podem variar muito de acordo com a localização de cada estação (disponibilidade de serviços telefônicos,
viabilidade de passar cabos) e a distância entre estações. Por exemplo, rádios são muito utilizados em locais remotos desprovidos de
serviços telefônicos.

O Protocolo Modbus RTU

Um protocolo é um conjunto de regras que define como os ETDs trocam dados. No caso do protocolo MODBUS RTU, as regras são
definidas nas seções seguintes.

Filosofia de Acesso ao Meio Físico e Endereçamento dos ETDs

Considere a figura 3 como se fosse uma rede MODBUS. Conforme informamos, tudo que determinado ETD transmite é recebido pelos
demais ETDs. Mas assim como numa conversa humana, deve haver uma disciplina de acesso ao meio físico (um fala de cada vez, e os
outros devem apenas escutar). Apenas um ETD deve transmitir dados em determinado instante. Se dois ou mais ETDs transmitirem
dados ao mesmo tempo, ocorre uma “colisão” ou “mistura de dados”, e o resultado é que os dados na rede são distorcidos.

A disciplina de acesso ao meio utilizada na rede MODBUS é bastante utilizada em protocolos simples, e denomina-se de mestre-escravo.
Por exemplo, na figura 3, elejamos o ETD1 como mestre, e todos os demais ETDs (2 até 6) como escravos.

Cada ETD escravo de ter um endereço de nó associado na rede. No caso de uma rede MODBUS, este endereço pode variar de 1 a 247,
sendo possível portanto haver 1 mestre e 247 escravos numa rede MODBUS. Em nosso exemplo da figura 3, o ETD2 poderia ter endereço
2, o ETD3 poderia ter endereço 3, etc. Dois ETDs diferentes nunca podem ter o mesmo endereço. O ETD1 (mestre) não possui nenhum
endereço.

A disciplina mestre-escravo consiste em que todas as comunicações são iniciadas pelo mestre, que transmite uma mensagem denominada
“requisição”. Nesta requisição, o mestre solicita um serviço para um dos escravos. Para indicar qual é o escravo que deve executar este
serviço, a mensagem de requisição embute o endereço do escravo. Todos os escravos recebem a mensagem de requisição, mas somente
aquele cujo endereço coincide com aquele embutido na requisição deve executar o serviço. A execução do serviço consiste em ações
internas no escravo (tais como ler ou escrever operandos), seguida da transmissão de uma mensagem deste escravo para o mestre,
denominada “resposta”. A resposta confirma a execução do serviço, e eventualmente contém dados solicitados pelo mestre.

Em resumo, a disciplina consiste em:

o mestre envia uma requisição para o escravo de endereço X, que é ouvida por todos os escravos na rede somente o escravo X executa o
serviço solicitado nesta requisição, e envia uma resposta para o mestre

Mensagens em Broadcast

Anteriormente, dissemos que o endereço de um escravo pode variar de 1 a 247. No entanto, o mestre pode transmitir uma requisição para
o endereço 0, que significa “broadcast”. Isto determina que:

-todos os escravos da rede devem executar o serviço solicitado

-nenhum escravo deve emitir uma resposta para o mestre confirmando o serviço (do contrário, todos tenderiam a -transmitir ao mesmo
tempo, causando colisão entre respostas)

Portanto, o mestre não recebe confirmação do serviço dos escravos (resposta). Este tipo de endereçamento é útil, por exemplo, se o
mestre deseja escrever um mesmo conjunto de dados, simultaneamente, em todos os escravos da rede.

No entanto, não faz sentido utilizar broadcast para ler dados dos escravos, pois estes dados viriam na resposta, que não existe neste caso.

Tipos de Dados

O protocolo MODBUS define os seguintes tipos de dados:

dados de 1 bit:

-coils: podem ser lidos do escravo ou escritos no escravo

-inputs: somente podem ser lidos do escravo
-dados de 16 bit (ou registers):
-holding registers: podem ser lidos do escravo ou escritos no escravo
-input registers: somente podem ser lidos do escravo

Endereçamento Lógico dos Dados

Cada um dos tipos definidos anteriormente pode ter até 9999 operandos ou variáveis. Cada operando deve ter um endereço lógico para
diferenciá-lo dos demais operandos. Existe uma faixa de endereços destinada aos operandos de cada tipo de dados, conforme define-se a
seguir:

-coils: 00001 a 09999

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 -inputs: 10001 a 19999
-input registers: 30001 a 39999
-holding registers: 40001 a 49999

Endereçamento dos Dados dentro das Mensagens

O endereço dos dados dentro das mensagens difere levemente do seu endereçamento lógico. Dentro das mensagens, o endereço dos
operandos varia sempre de 0 a 9998, independente do tipo de dado.

Por exemplo, para um input register, o endereço lógico 30001 corresponde ao endereço 0 dentro das mensagens, o endereço lógico
30002 corresponde ao endereço 1 dentro das mensagens, e assim por diante. Da mesma maneira, para um holding register, o endereço
lógico 40001 corresponde ao endereço 0 dentro das mensagens, o endereço lógico 40002 corresponde ao endereço 1 dentro das
mensagens, e assim por diante.

Em princípio, pode-se imaginar que isto causaria confusão. Como saber se o endereço 0 é um input register ou um holding register? A
resposta está na próxima seção (tipos de serviços). Os tipos de serviços, que também estão embutidos na mensagem, especificam
implicitamente o tipo de operando.

Principais Serviços Requisitados pelo Mestre

Quando o mestre transmite uma requisição para determinado escravo, ele embute na mensagem o código do serviço solicitado. Os
seguintes códigos são os mais comuns em dispositivos com interface MODBUS:

1 - read coil status: leitura de múltiplos operandos do tipo "coil"

2: read input status: leitura de múltiplos operandos do tipo "input"
3 - read holding registers: leitura de múltiplos operandos do tipo "holding register"
4 - read input registers: leitura de múltiplos operandos do tipo "input register"
5 - force single coil: escrita de um único operando do tipo "coil"
6 - preset single register: escrita de um único operando do tipo "holding register"
15 - force multiple coils: escrita de múltiplos operandos do tipo "coil"
16 - preset multiple registers: escrita de múltiplos operandos do tipo "holding register"

Observa-se que alguns destes serviços requisitam a leitura ou escrita de múltiplos operandos consecutivos. Nestes casos, na requisição, o
mestre especifica o endereço do primeiro operando, e também o número de operandos envolvidos na comunicação.

Formato das Mensagens

Conforme visto anteriormente, há 2 tipos de mensagens:

-requisições transmitidas pelo mestre

-respostas transmitidas pelos escravos

Uma mensagem é uma seqüência de bytes consecutivos. Na figura 2 mostramos um exemplo de seqüência de 2 bytes. Uma mensagem
MODBUS pode ser uma seqüência que varia deste alguns poucos bytes (menos de 10) até algumas centenas (máximo de 256 bytes).

Cada um dos serviços definidos na seção anterior possui um formato de mensagem para a requisição e outro para a resposta.

A requisição normalmente deve transportar as seguintes informações:

-o endereço do escravo (1 a 247, ou 0 para broadcast)

-o serviço solicitado (ex: 16 = preset multiple registers). Isto automaticamente informa o tipo de operando -associado (no caso do
comando 16, holding registers).
-o endereço do primeiro operando
-a quantidade de operandos consecutivos, a partir do primeiro
-caso seja uma escrita, os dados a serem escritos pelo mestre no escravo. Pode-se ter no máximo 250 bytes de dados (125 registers, ou
2000 bits).
-CRC (cyclic redundancy check), utilizado para detecção de erros.

A resposta normalmente deve transportar as seguintes informações:

-o endereço do escravo (1 a 247)

-o serviço solicitado
-o endereço do primeiro operando
-a quantidade de operandos consecutivos, a partir do primeiro
-caso seja uma leitura, os dados a serem lidos pelo mestre a partir do escravo. Pode-se ter no máximo 250 bytes -de dados (125 registers,
ou 2000 bits).
-CRC (cyclic redundancy check), utilizado para detecção de erros.

Para ter uma descrição exata do formato das mensagens para cada tipo de serviço, utilize a referência bibliográfica citada no final deste
artigo.

Regras de Temporização

O protocolo MODBUS define algumas regras de temporização que devem ser respeitadas:

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 o tempo de linha inativa entre bytes de uma mesma mensagem (requisição ou resposta) não pode exceder a 1,5 tempos de byte. Por
exemplo, a 9600 bps, considerando bytes de 11 bits (start bit, 8 bits de dado, paridade e stop bit), o tempo de um byte é de
aproximadamente 1,14 ms. Ou seja, 1,5 tempo de byte seria 1,72 ms.

entre duas mensagens consecutivas (requisição e resposta, ou resposta e requisição), deve existir um tempo mínimo de inatividade na
linha, de 3,5 tempos de byte (aproximadamente 4 ms a 9600 bps)

Estas regras auxiliam a detecção do início e fim de mensagens.

Detecção de Erros

Quando um ETD recebe uma mensagem, existem diversas maneiras de avaliar se ela não foi distorcida enquanto transitava na rede.

se a paridade de algum dos bytes recebidos está incorreta (ver descrição anterior de paridade)
se houve erro de “framming” num dos bytes (o stop bit não vale –10 V)
se a mensagem recebida não obedece as regras sintáticas do protocolo (por exemplo, se o código do serviço não corresponde a nenhum
valor válido)
se o número de bytes recebidos da mensagem é menor ou maior do que o esperado
no caso do mestre, se ele não receber resposta nenhuma do escravo para sua requisição
se o CRC (cyclic redundancy check) calculado pelo receptor difere do CRC recebido na mensagem. Ver maiores detalhes a seguir.

Por exemplo, quando um transmissor quer enviar uma mensagem tem 100 bytes nos campos iniciais anteriores ao CRC (endereço do
escravo, código da função, endereço e quantidade de operandos, dados), um cálculo especial envolvendo todos estes 100 bytes é realizado.
O resultado deste cálculo são dois bytes de CRC, que são inseridos no final da mensagem. Portanto, a mensagem será transmitida com
102 bytes.

Quando o receptor recebe a mensagem de 102 bytes, ele executa o mesmo cálculo sobre os primeiros 100 bytes. O resultado deve coincidir
com os dois últimos bytes (CRC) recebido da mensagem. Se houver diferença, a mensagem é desconsiderada, pois foi distorcida na linha.
Este método é muito eficiente para detecção de erros.

Recuperação de Erros

Se um escravo recebe uma mensagem de requisição inválida (por exemplo, detectou um erro nela), ele a desconsidera (não executa o
serviço nem responde ao mestre).

Por outro lado, o mestre desconsidera respostas onde detectou erros. Se um mestre detecta erros na resposta de um escravo, ou
simplesmente não recebe nenhuma resposta do escravo depois de algum tempo (timeout), ele pode retransmitir a requisição. Este
processo se chama de retentativa. O número máximo de retentativas normalmente é configurável e limitado, pois é possível, por exemplo,
que a rede de comunicação tenha problemas físicos ou que o escravo esteja desligado ou danificado.

Timeout

Quando o mestre faz uma pergunta, o escravo pode demorar um pouco para responder. Existe um atraso típico, e também um atraso
máximo admissível para receber uma resposta do escravo. Este atraso máximo deve ser configurado no mestre como “timeout”. Se a
resposta não for recebida dentro do timeout, o mestre assume que ela não virá mais, e eventualmente fará uma retentativa de
comunicação.

Conclusões

Este artigo inaugural sobre redes de automação industrial abordou uma rede bastante simples e muito popular, que é a MODBUS RTU. É
extremamente aplicada, ainda nos dias atuais, para a transferência de dados em média quantidade e baixa velocidade. Esta simplicidade a
torna ideal para introduzir conceitos básicos, que serão úteis para a análise de redes mais complexas, que serão abordadas em artigos
subseqüentes.

Bibliografia

Modicon Modbus Protocol Reference Guide

PI–MBUS–300 Rev. J
(Esta bibliografia pode ser facilmente localizada na Internet, e o “download” é livre, já que o protocolo é aberto para quem o deseja
utilizar).

*Originalmente publicado na revista Mecatrônica Atual - Nº15 - Abr//04

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 Protocolo MODBUS
A segurança dos dados em uma rede industrial é fundamental para o funcionamento correto de um sistema. Veja porque o protocolo
MODBUS foi adotado nas automações industriais

Imagine a seguinte cena

Um CLP ou um computador controlando diversas etapas de um sistema automatizado, controlando sensores, motores, redutores,
atuadores e outras máquinas que compõem o sistema de produção, tudo funcionando como uma orquestra, onde se um elemento da rede
falhar todo o sistema pode ser comprometido. Em determinada etapa da produção um motor para por algum motivo ou funciona de
forma errônea, o passo seguinte da linha de produção começa a sofrer com a irregularidade ou pela falta de curso do processo, o gasto ou
prejuízo gerado até a parada de todo sistema pode ser enorme.

Agora imagine se o sistema parasse de funcionar logo após este mesmo motor parar de funcionar ou responder, ou ainda tomar uma rota
alternativa para não parar a produção.

Mas, como controlar todos os processos/ equipamentos de um sistema automatizado com confiança e com velocidade suficiente para se
tomar uma rápida atitude?

Agora vamos imaginar um segundo cenário

Um CLP ou um computador que gerencia todo um sistema automatizado, e que fica verificando se cada elemento está funcionando
corretamente. Para saber se cada um está de acordo, o CLP ou computador - que chamamos de Master (Mestre) - envia um sinal para
cada componente abrindo uma porta de comunicação, uma vez a porta aberta o Master pergunta para o equipamento - que chamamos de
Slave (escravo) - como está o seu funcionamento, o escravo por sua vez responde o seu status fechando a porta de comunicação.

Depois disso o Master executa o mesmo procedimento para todos os outros elementos do sistema, e assim mantém o gerenciamento de
tudo. Até aqui tudo bem, mas imagine se um dos elementos por alguma falha não abre um canal de comunicação e nem responde o seu
status? O Mestre ficaria esperando uma resposta até quando? Até alguém notar que o sistema que deveria ter parado, não parou?

É por isso que o protocolo MODBUS foi criado, o Mestre ao invés de abrir um canal de comunicação com um determinado dispositivo ou
elemento, joga na rede em que está conectado uma sequência de co- mandos (bits) onde contém além de outras informações, o número
do dispositivo que ele está chamando. O elemento que está na rede com aquele número tem um tempo aproximado para responder que
está ativo na rede, caso ele não responda ou demore a responder, ou se na sua resposta aparece um código de erro, o Mestre deverá
executar a instrução programada nele para corrigir aquele problema.

Para entendermos melhor como é a aplicação do protocolo MODBUS, a figura 1 ilustra uma linha de produção com diversos
dispositivos, cada um com o seu número (rótulo) na rede, sendo controlados pelo Mestre.

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 Como mencionado anteriormente, cada dispositivo deve ter um número, e visto que em cada frame de dados temos apenas 1 byte
reservado para indicar qual dispositivo deverá ser chamado, temos um limite de 247 dispositivos presos a rede, ou seja, podemos chamar
dispositivos que vão do 01 a 247, onde o 00 é reservado para broadcast.

O Frame do protocolo MODBUS

Como o tempo é primordial no tráfego de informações, o frame (pacote de bits enviados de um dispositivo a outro) deve ser enxuto o
bastante para não comprometer o sistema. Na figura 2 temos como os bits são distribuídos dentro de um frame do protocolo MODBUS,
tanto pelo Mestre como os dispositivos escravos.

O primeiro byte descreve o dispositivo, neste caso o dispositivo chamado é o 2A.

O segundo byte descreve o comando ou a função que será executada, neste exemplo 01 lê as saídas digitais (bobinas).

O terceiro byte (mais significativo) e o quarto byte (menos significativo) indicam os endereços de memória onde serão ou estão escritos os
dados no escravo, neste exemplo no endereço de memória 05 e 02.

O quinto byte (mais significativo) e o sexto byte (menos significativo) mostram a quantidade a ser lida ou escrita pelo escravo e seus
dados.

CRC (Cyclic Redundancy Check) são 2 words (palavras) ou 16 bits, utilizado para detectar erros na transmissão de dados.

Código de funções ou comandos

As funções são de leitura de informações de um escravo, a escrita de informações num dispositivo escravo, ou o broadcasting, que pode

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 ser a leitura ou escrita em todos os dispositivos escravos da rede.

Conforme o tipo de dados, ele pode ser Bobinas de 8 bits (coils) que podem ser lidos ou escritos do escravo, Entrada de 8 bits (inputs) que
somente podem ser lidos do escravo, Retentivos de 16 bits (holding) que podem ser lidos e escritos no escravo e, por fim, a Entrada de 16
bits (inputs) que somente podem ser lidos do escravo.

Na tabela 1 temos os principais comandos do protocolo MODBUS e suas representações em hexadecimais.

As funções inseridas no protocolo MODBUS de domínio público são únicas e bem definidas, validadas pela comunidade da organização
MODBUS, possuindo testes de certificação e documentação em MB IETF RFC, além de ter áreas reservadas para expansões. Além das
funções públicas, existem duas faixas de código onde o usuário poder definir novas funções, independentemente da área, sem ter que
notificar ou pedir autorização da comunidade MODBUS, porém é importante verificar se as novas implementações não irão conflitar com
as já existentes.

Caso o usuário deseje tornar a sua função uma “função pública” é necessário iniciar junto à comunidade MODBUS uma RFC para ver a
sua aceitação.

Endereçamento lógico dos registros/dados

Nesta parte do frame encontramos nos dois bytes o local e o tipo de dados e operando, que cada tipo pode conter até 9999 operandos,
pois cada um tem um registro que o descreve para diferenciá-lo. Para se ter uma idéia, o operando que especifica uma saída discreta
(Coils) está entre 00001a 09999, o de entrada discreta (Inputs) vai de 10001 a 19999, o de Entradas analógicas (Input Registers) de
30001 a 39999 e o de Saídas analógicas (Holding Registers) de 40001 a 49999.

Lembrando que o endereço dos dados difere do endereço do operando, que está na faixa de 1 a 9998, um exemplo que podemos citar é
lermos um dado 40001. Saberemos que é um Holding Register, mas as informações estão contidas no endereço 0, caso o dado recebido
fosse 40002 seria o endereço 1 do Holding Register, e assim até 49999.

CRC (Cyclic Redundancy Check)

Os dois últimos caracteres do frame servem para certificar que os dados passados naquele pacote de informações estão corretos através
de uma lógica de verificação. Caso os valores não sejam conforme o esperado, o pacote é dado como erro. Na hora da formação destes dois
caracteres o processo é invertido, tornando o byte mais importante como o de menor importância e o de menor como de maior
importância, antes de serem enviados ao escravo.

Formato de transmissão

São quatro os modos em que os dados são formatados antes da transmissão: o RTU (Remote Terminal Unit) é o mais utilizado pelo fato
de compor o frame em binário, onde cada byte contém dois caracteres de 4 bits cada. Ele difere do formato ACSII (American Standard
Code for Information Interchange), ocupando menos recurso de rede, pois um byte do formato ACSII é formado por 7 bits e pode ser
entendido somente por ler a sequência.

Os outros dois formatos são o MODBUS/TCP onde os dados são encapsulados em pacote e enviados pela rede Ethernet via TCP ,
utilizando-se do CSMA/CD (Carrier Sense Multiple Access with Collision Detection) que gerencia as possíveis colisões que possam

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)
 ocorrer, caso outros dispositivos estejam usando o mesmo canal, dando taxas de prioridade ao pacote enviado; e o MODBUS Plus, que é
de prioridade da Schneider Electric, sendo que para utilizá-lo é necessário ter a licença de uso.

Na figura 3 temos o diagrama mostrando as diferença entre o pacote RTU e o pacote TCP que já utiliza o CRC32.

Temporização no MODBUS

De acordo com Pedro Urbano e Auzuir Ripardo, autores do livro “Redes Industriais” (ed. Ensino Profissional), o protocolo MODBUS
define algumas regras de temporização a serem respeitadas. O tempo de linha inativa entre bytes de um mesmo pacote (requisição e
resposta) não pode exceder 1,5 tempos de bytes. Por exemplo, numa taxa de 9600 bps, considerando dados de 11 bits (start bit, 8 bits de
dados, paridade e stop bit) o tempo de byte é de aproximadamente 1,146 ms, ou seja 1,5 tempos de byte seria 1,72 ms.

Quando o mestre faz uma pergunta, o escravo pode demorar um pouco para responder. Existe um atraso típico e um atraso máximo
aceitável para receber uma resposta do escravo. Este atraso máximo de resposta deve ser configurado no timeout do Mestre. Se a resposta
não for recebida dentro deste timeout , o mestre assume que o pacote não vem mais e faz uma nova requisição.

Conclusão

Este artigo mostra como funciona o protocolo MODBUS. É importante para quem precisa realmente utilizar o protocolo, tanto para
desenvolver como para reparar ou projetar sistema baseados nele, ler mais sobre as tabelas de operações públicas como as que já foram
implementadas em outros locais, e também as soluções apresentadas por outros engenheiros de projetos. No quadro “Saiba Mais”, no
início deste artigo, apresento algumas referências importantes para o melhor entendimento deste protocolo.

*Originalmente publicado na revista Mecatrônica Atual Nº42

You created this PDF from an application that is not licensed to print to novaPDF printer (http://www.novapdf.com)