Protocolo Modbus

Francisco Manuel Gomes da Torre e Frias­Bulhosa
Estudante do Mestrado em Engenharia Eletrotécnica e de Computadores ramo de Telecomunicações, no Instituto
Superior de Engenharia do Porto
1130359@isep.ipp.pt

Resumo tipo   de  dispositivos   de   campo  que   controla  ficam

interligados, em termos elétricos em paralelo, como
O   protocolo  Modbus  é  um   protocolo  utilizado  em ilustra a figura  1, por  dois ou três cabos e  trocam
redes de campo. Foi desenvolvido em 1979 para envio mensagens  usualmente   pequenas  entre   eles,
e   receção   de   mensagens  entre  Programmable   Logic seguindo   um   conjunto   de   regras   definidas   pelo
Controllers (PLC), com o intuito de ser simples e fácil protocolo, para  transmissão de valores ou execução
de   implementar.   Neste   documento   são   explicadas   as de ações.  A maior parte destas redes  são  utilizadas
funcionalidades   do   protocolo,   como   se   usa   e   as em   ambiente   industrial,   onde   existem  unidades
vantagens e desvantagens que apresenta em relação a inteligentes, normalmente PLCs ou equivalentes, que
outros protocolos utilizados no mesmo âmbito. executam   tarefas   específicas  nas   várias  zonas  da
nave fabril. Também é usual existir um equipamento
que supervisiona as mensagens trocadas na rede ou
1. Introdução comanda os PLC por uma outra rede de campo.
O protocolo  Modbus  já existe há bastante tempo.
É um  protocolo  que  define  o  tipo  de  mensagens  a
enviar  entre  dois  equipamentos, que pode ser para
leitura   de  sensores   remotos,   acionamento   de
atuadores, etc... E, por isso, é normalmente utilizado
em redes de instrumentação ou de campo, como por
Figura 1. Ligação típica de
exemplo linhas de produção industriais.
equipamentos numa rede de campo
Neste   artigo   é   feita   uma   revisão   ao   protocolo,
[2].
tendo como objetivos dar a conhecer a sua evolução
no tempo, realizar uma comparação com protocolos
parecidos,   dar   também   a   conhecer   como   se 1.2. Organização do relatório
implementa, sendo apresentado um exemplo de uma
rede, tendo como principal objetivo concluir se ainda No   capítulo   1   deste   relatório   é   feita   uma
se   justifica   o   uso   deste   protocolo   ou   se   este   foi introdução e é apresentada e razão de existência do
tornado   obsoleto   por   outros   protocolos   mais protocolo.
robustos. No   capítulo   2,   é   apresentada   a   evolução   do
protocolo   ao   longo   do   tempo   e   são   também
indicadas quais as entidades que possuíam direitos
1.1. Redes de campo
de   autoria  e   responsáveis   por   certificação   dos
equipamentos.
As   redes   de   campo   são   redes   para   troca   de
No capítulo 3 é feita a descrição do protocolo em
informação   entre   equipamentos  afastados
si.   São   apresentadas  as   várias   camadas   do  modelo
fisicamente,  mas que  precisam  de  realizar trocas de
Open   Systems   Interconnection  (OSI)  que   estão
dados [1]. Inicialmente nos processos automatizados
definidas por este.
existia uma unidade central do tipo PLC, que estava
No capítulo 4 é apresentado o estado de uso deste
ligado   aos   vários   sensores   e   atuadores  que
protocolo,   nomeadamente   os   setores   em   que   é
controlava  por  ligações   individuais  com  cabos   de
implementado   e   a   quantidade  relativa  de  uso   em
cobre  através das suas  entradas  e  saídas.  Passou  a
comparação com outros protocolos.
haver   a   necessidade  em   processos   mais   complexos
No  capítulo  5   é   efetuada   uma   comparação  com
de   reduzir   o   número   de   cabos   utilizados  e   de
alguns   dos   protocolos   mais   comuns   com   o   mesmo
entradas e saídas do PLC. Então a implementação de
tipo de implementação.
rede de campo resolve o problema, o PLC e  todo o
 No capítulo 6 é apresentado um caso concreto de
uma rede que implemente o protocolo Modbus.
No   capítulo   7   estão   resumidas   as   principais
conclusões   a   tirar   com   base   nos   conteúdos   deste
artigo.
2. História
Os   engenheiros   da  empresa  Modicon,   nome
proveniente de MOdular DIgital CONtroller, foram os
primeiros   a   desenvolver  um  PLC  em   1968  [3],  e
foram   também   os   primeiros   a   desenvolver  um
protocolo   específico   para   que   os   PLCs   pudessem
comunicar entre si, quando em 1979, desenvolveram
o protocolo Modbus para ser implementado nos seus
PLCs,  permitindo   uma   troca   de   dados   entre
equipamentos   de   forma  estruturada,   organizada,
eficiente e simples.
A  Modicon  foi  sendo  comprada   por   outras
empresas e em 1994 acabou no grupo que viria a ser
o  Grupe   Schneider  [4].  A  12   de   Abril   de  2004,   os
direitos   de   autoria   do   protocolo  Modbus  foram
transferidos   para   uma   organização  sem   fins
lucrativos   chamada  de  Modbus­IDA  (atualmente
Modbus  Organization),   que   efetua   certificação  de
equipamentos  que   seguem   as   recomendações,
publicadas  nos   documentos   criados   por   esta,  para
assegurar   a   interoperabilidade   dos   mesmos.  Nesta
altura   o   protocolo   passou   a   ser   aberto  e   muitos
fabricantes começaram a implementar este protocolo
nos seus equipamentos.
A  grande adesão  ao  protocolo  e  a sua  cada vez
maior presença levaram a que o Modbus se tornasse
num de facto standard para redes industriais.
Inicialmente   os   PLCs   da  Modicon  comunicavam
todos  utilizando   uma   interface  Recommended
Standard 232 (RS232), e por isso existia um capítulo
no protocolo  com  definições  para a implementação,
mais especificamente  a  nível  da  camada  de  dados,
quando   fosse   pretendido   utilizar   interface   RS232,
apesar   de   esta   camada   não   estar   definida   pelo
protocolo.  Posteriormente foi definido, pela  Modbus
Organization,  um  documento à parte do protocolo,
intitulado de  MODBUS over Serial Line Specification
and Implementation Guide V1.02 [5] onde é definido
o   protocolo  Modbus   Serial  Line  protocol,   um
protocolo   de   camada   de   dados   para   troca   de
informação   entre   um  master  e   um   ou   mais  slaves,
quando   é  utilizando   como   camada   lógica
Recommended Standard 485 (RS485) ou RS232. Este
documento foi criado pois se verificou  que a maior
parte   dos   dispositivos  Modbus,  comunicavam  via
RS485   ou   RS232,  mas   não   implementavam   a
camada   de dados  de  forma   igual,   tornando  alguns
incompatíveis.
Se   os  designers  que   pretendam   implementar   o
protocolo  Modbus  numa   comunicação   série,  que
utilize RS485 ou RS232, seguirem as orientações do
referido   documento,  é   assegurada   a
interoperabilidade   entre   dispositivos   de   diferentes
fabricantes, sendo de  salientar  que este documento
não faz parte do protocolo Modbus.
De   forma   parecida   foi   também   criada   um
documento  equivalente  por   parte   da  Schneider
Automation,   para   implementação  com  Ethernet,
denominado  MODBUS   Messaging   on   TCP/IP
Implementation   Guide   V1.0b  [6],  onde   são   dadas
orientações   a   nível   de  software,   aos  designers  que
pretendam   desenvolver   ou   programar   dispositivos
para comunicarem recorrendo a Ethernet.
3. Descrição do protocolo
O protocolo  Modbus  define o tipo de mensagem
que   é   utilizado,  para   pedidos   de   dados   ou
requerimento   de   ações   de   outro   equipamento,
independentemente   do   tipo   de   rede   em   que   se
encontra.  Por  esse  motivo  define  apenas  a  camada
de   aplicação   do   modelo   OSI  [7].  No  entanto  os
engenheiros da  Modicon  também definiram como é
que   os   seus   PLCs  implementavam  a   camada   de
dados,   quando  era  utilizado  na   camada   física  o
RS232, que era a interface que os seus PLCs tinham.
Definiram   dois  modos   de   transmissão  a   nível   de
camada de dados [8], aos quais chamaram de modo
American Standard Code for Information Interchange
(ASCII) e modo Remote Terminal Unit (RTU).
Mais tarde por parte da Modbus Organization, foi
criado   o   documento  MODBUS   over   Serial   Line
Specification   and   Implementation   Guide   V1.02  [5],
onde explicam como se utilizam estes dois modos de
transmissão  a   nível   de  camada   de   dados   e  como
interligar   equipamentos   na   mesma   rede.  Neste
capítulo são apresentados para além das mensagens
definidas   no   protocolo,  os   modos   recomendados
para   comunicações série,  quando  utilizando RS485
ou RS232 denominados de ASCII e RTU e também o
utilizado em redes TCP/IP.
O modo  de transmissão  ASCII,  tal como o  modo
RTU, está definido para ser utilizado na transmissão
de mensagens Modbus entre dispositivos que estejam
ligados via ligação série RS485 ou RS232. Neste tipo
de   redes   existe   apenas   um   cliente,   denominado
master, e podem existir vários servidores, que são os
slaves.  Cada  slave  tem um endereço que é utilizado
para   endereçar   as   mensagens.   Como   só  existe   um
master que interpreta as respostas, estas apresentam
no campo do endereço o mesmo endereço  do  slave
que responde, que serve também para confirmar que
a resposta é do servidor pretendido.
Para   informação   mais   detalhada   sobre   qualquer
questão relacionada com o protocolo  Modbus  ou as
implementações   recomendadas   pela  Modbus
Organization,  podem­se  consultar  os   documentos
referenciados   ao   longo   do   texto,   que   estão
disponibilizados no site da Modbus Organization.
3.1. Trama de mensagem Modbus
Sendo  Modbus  um   protocolo   da   camada   de
aplicação,   apenas   define   o   tipo   de   mensagem
(trama) que é enviado entre o cliente e o servidor e
vice­versa.
É   um   protocolo   de   pedido/resposta,  a
comunicação  começa pelo envio de um pedido por
parte do cliente, para um servidor e este envia uma
mensagem   de   resposta   conforme   o   tipo   de   pedido
realizado.
A trama ou Protocol Data Unit (PDU) do protocolo
Modbus contêm dois campos [7]:
• Function  code  ­   este   primeiro   campo
identifica o tipo de ação que é pretendido o
servidor realizar e é sempre um byte;
• Data  ­  este   campo   varia   em   conteúdo   e
tamanho,   pois   contém   os   argumentos
necessários para o servidor  executar a ação
correspondente   ao  Function  code  enviado,
estando   o   seu   tamanho   limitado   a   um
máximo de 252  bytes  e podendo em alguns
casos este campo ser nulo.
Existem   três   tipos   de   mensagem:   de   pedido,   de
resposta e de exceção. As mensagens de pedido, que
são enviadas do cliente para o servidor, transmitem o
Function   code  e   os   argumentos   necessários,   a
resposta,   enviada   do   servidor   para   o   cliente,
transmite o mesmo  Function code  e em vários casos
os   argumentos   são   os   mesmos.  As   mensagens   de
exceção   são   enviadas   pelo   servidor   para   o   cliente,
quando a ação correspondente ao Function code não
pode ser realizada. Nesta mensagem o Function code
é   igual   ao   do   pedido,   mas   com   o  bit  mais
significativo a 1 e no campo Data é enviado um byte,
denominado  Exception  code, que identifica porque  é
que a ação pedida não foi realizada.
Os   principais   tipos   de   funções,  definidos   no
protocolo  Modbus,   e   os   mais   utilizados   são  os   de
pedido de leitura e de escrita de dados num servidor.
O tipo de dados pode ser de quatro tipos, tipos estes
baseados no tipo de dados que um PLC utiliza [7]:
• Coils  ­  saídas digitais  ou  variáveis internas,
que apenas contém um bit de informação;
• Discrete   Inputs  ­  entradas   digitais   também
apenas de um bit;
• Holding   Register  ­  saídas   analógicas   ou
variáveis   internas,   com  16  bits  de
informação;
• Input Register ­ entrada analógica de 16 bits.
Existem seis funções para este tipo de ação.
Para   ler  Coils  e  Discrete   Inputs  são   utilizadas   as
funções  1 e 2 correspondentemente, sendo para as
duas   enviados   dois   valores   de   16  bits  no   campo
Data, o primeiro o endereço  e o segundo o número
de variáveis a ler. Por exemplo para se ler a décima
variável  utiliza­se o endereço  0x0009  e  requer­se  a
leitura de apenas uma variável (0x0001).
Para escrita de Coils existe a função 5 para apenas
uma   e   a   15  (0x0F)  para   a   escrita   de   várias
sequencialmente endereçadas.
Para leitura de  Holding Registers  e  Input Registers
utilizam­se as funções 3 e 4 correspondentemente  e
para   escrita   de  Holding   Registers  a   função   6  para
escrita de apenas uma variável e a função 16 (0x10)
para   serem   escritas   várias  endereçadas
sequencialmente.
A   maior   parte   das  restantes  funções  definidas
servem para propósitos de diagnósticos.
Como se pode ver pela figura 2, as funções estão
classificadas   como   publicas   ou   definidas   pelo
utilizador. As funções públicas são funções que estão
definidas no protocolo e é assim garantido que o seu
funcionamento   é  o   mesmo   independentemente  do
dispositivo. As funções definidas pelo utilizador são
funções que não estão definidas no protocolo e cada
utilizador   pode   implementar  livremente  nos   seus
dispositivos  conforme  precisar.  O   utilizador   pode
também requerer que uma função desenvolvida por
si, fique reservada como pública, sendo­lhe atribuído
um   número  ainda  livre.  Das   funções   públicas,   que
são no total 108, apenas 30 estão definidas, 19 pelo
protocolo   e  mais   11  por   pedido   de   utilizadores,
significando  que  para   além   das  19   que  podem   ser
implementadas   livremente   por   utilizadores  ainda
podem vir a ser definidas mais 78.
 0x08 (erro de paridade na  relacionado com as funções 20 
memória) e 21 indica que o servidor 
detetou erros no ficheiro que 
estava a ser lido
0x0A (falha de  quando a comunicação é feita 
encaminhamento) através de um gateway e este 
não conseguiu criar um canal 
de comunicação entre os dois
0x0B (dispositivo não  quando a comunicação é feita 
respondeu) através de um gateway e este 
não obteve resposta do outro 
dispositivo

3.2. Modo ASCII

O  modo  ASCII,  tal   como   o   nome   indica,  utiliza

caracteres   ASCII  para   transmissão   de   dados.  Por
cada byte da mensagem que se pretenda enviar, são
enviados   dois   caracteres   com   a   sua   representação
hexadecimal,  por   exemplo,  se   for   pretendido
transmitir o valor decimal 59, 0x3B em hexadecimal,
são enviados os caracteres "3" (0x33) e "B" (0x42).
Cada caracter é enviado de acordo com a figura 3.
É   enviado   um  bit  de  start,   depois   são   enviados  os
Figura 2. Esquema com funções sete bits que representam o caracter ASCII do menos
definidas no protocolo Modbus [7]. significativo para o mais significativo, é enviado um
Apesar   de   as   funções   estarem   definidas   no bit  de paridade, que serve para deteção de erros na
protocolo,   não   é   necessário   estarem  todas transmissão de um caracter e por fim é enviado um
implementadas em cada dispositivo. bit de stop.
Existe um conjunto de  Exception  codes,  referidos
anteriormente   neste   capítulo,  que   identificam  na
resposta de erro no campo Data, qual o tipo de erro
que ocorreu. Na tabela 1 são apresentados os vários
Exception codes definidos no protocolo. Figura 3. Transmissão de um caracter em
Tabela 1. Lista de Exception codes e o modo ASCII [5].
que significam [7]. Cada   caracter  enviado   corresponde   a  10  bits
enviados.
Exception code Tipo de erro Em termos de PDU, é acrescentado um cabeçalho
0x01 (função ilegal) a função no pedido não está  e um campo para verificação de erro no fim, como se
configurada no servidor ilustra  na   figura  4.  O  cabeçalho consiste  num  byte
0x02 (endereço ilegal) um endereço pedido não  que   contém   o   endereço   do  slave,  ao   qual  a
corresponde a uma variável  mensagem se destina ou que está a responder. Neste
válida modo   a   verificação   de   erro   é   feita   com  um  byte
0x03 (dado ilegal) um dos valores no pedido não  acrescentado   no   fim   da   trama,   que   implementa
está correto Longitudinal  Redundancy  Checking  (LRC).  Tanto   o
0x04 (falha do servidor) erro relacionado com o  endereço   como   o  byte  de   LRC   são   enviados   como
funcionamento do servidor ou  dois   caracteres   ASCII.  A   condição   de   início   de
subcomponentes mensagem é o caracter ":", que tem de ser sempre
0x05 (receção) o pedido foi recebido mas vai  enviado, neste caso, antes do endereço  do  slave  e a
demorar bastante tempo a ser  condição   de   fim   de   trama   é   a   sequência   dos
processado
caracteres Carriage Return e Line Feed. No entanto se
0x06 (servidor ocupado) o servidor está a processar um  durante  o  tempo  de  um  segundo  não  for  recebido
pedido que demora e não pode 
receber mais pedidos por 
nenhum caracter ou for recebido o caracter de início
enquanto ":", a trama é dada por incompleta e é descartada.

Figura 4. PDU com condições de início e
de fim para o modo de transmissão
ASCII [5].
Como para cada byte são enviados dois caracteres
ASCII, a quantidade de informação enviada é grande
em comparação com a informação útil após receção
e   o   tempo   de   transmissão   pode   também   ser
considerável  grande, no entanto como os dados são
legíveis, é possível uma pessoa analisar as tramas de
forma   mais   fácil  e   o   tempo   entre   caracteres   de   1
segundo permite também que sejam enviadas tramas
a partir de um teclado ou interface homem­máquina
equivalente.
3.3. Modo RTU
No  modo de transmissão RTU é transmitido cada
byte da mensagem sem qualquer tipo de codificação.
Em comparação com o exemplo dado para o modo
ASCII, se se pretender transmitir o valor decimal 59,
0x3B  em   hexadecimal,   são   enviados   os  oito  bits,
correspondentes a esse  byte.  A maneira como cada
byte é enviado é idêntica à do modo ASCII, mas em
vez de se enviarem sete bits enviam­se oito, como se
mostra na figura 5.
Figura 5. Transmissão de um byte em modo
RTU [5].
A PDU no modo RTU é também muito similar à
do modo ASCII.  Uma das diferenças é a  verificação
de erro ser feita com dois bytes, que são o resultado
da implementação do algoritmo Cyclical Redundancy
Checking (CRC) aos bytes da PDU. No modo ASCII a
delimitação   da   PDU   é   feita   enviando   caracteres
específicos   que   nunca   aparecem   a   meio   de   trama,
mas como em modo RTU pode ser enviado qualquer
byte  na   trama,   a   delimitação   não   é   feita   com   um
valor ou sequência específicos, mas sim com tempo
de silêncio.  Como  se  ilustra  na figura  6,  uma trama
só começa a ser recebida se durante pelo menos 3,5
vezes o tempo que leva a transmitir um byte, 11 bits
em modo RTU,  não existir nenhuma transmissão de
qualquer tipo na rede e só é dada por concluída, se a
mesma condição ocorrer  no fim da  trama.  Um  byte
só é aceite como parte da trama atual, se não ocorrer
um tempo de silêncio maior que 1,5 vezes o tempo
de transmissão de um byte, desde a última receção.
Figura 6. PDU com condições de início e
de fim para o modo de transmissão
RTU [5].
Este modo tem a principal vantagem de transmitir
quase   nenhuns   dados,  que   não   sejam  com
informação útil e subsequentemente ser mais rápido.
Este  modo  é  por  essas  razões  o  mais  utilizado  em
redes   com   comunicação   série,   apesar   de   requerer
maior precisão temporal, tanto em transmissão como
em recessão e ser mais difícil uma pessoa interpretar
a informação.
3.4. Modbus sobre TCP/IP
Também   é   possível   integrar   comunicação   entre
clientes   e   servidores  Modbus  sobre   redes  Ethernet.
Foi definido que a transmissão deverá ser realizada
utilizando TCP/IP  para assegurar  a integral receção
das mensagens, estando reservado o porto 502 para
os servidores Modbus receberem pedidos.
Ao   implementar  Modbus  com  Ethernet,  pode­se
tomar   partido  da  possibilidade  de  existir   mais   que
um cliente na mesma rede e inclusive cada cliente
enviar   vários   pedidos   seguidos,   pois  é   assegurado
com o uso de TCP que todas as mensagens chegam
ao   destino  e   não   são   interpretadas   pelos   outros
dispositivos.
Tal   como   nos   modos   de   transmissão
anteriormente   referidos,   a   PDU   terá   campos
adicionais.  É   acrescentado   um   cabeçalho,
denominado  Modbus  Application  Protocol  header  (
MBAP header), o qual contém quatro campos [6]:
• Transaction Identifier ­ este campo de 16 bits
contém   um   valor,   atribuído   pelo   cliente  e
repetido na resposta pelo servidor, que serve
para o cliente conseguir associar a resposta
ao pedido correspondente;
• Protocol   Identifier  ­  este   campo   de   16   bits
representa o tipo de protocolo utilizado, que
neste caso será sempre 0x0000;
• Length ­ 16 bits que servem para o cliente e o
servidor saberem quantos bytes a mensagem
contém.   Isto   é   necessário   pois   uma
mensagem   pode   ser   separada   em   vários
pacotes   TCP,   assim   o   dispositivo  consegue
determinar quando já recebeu todos os bytes
da mensagem  e pode processar. É de notar
 que   o   último   campo   do   MBAP   também   é
contabilizado como byte da mensagem;
• Unit   Identifier  ­  este  byte  serve   para
endereçar   um  slave  que   se   encontra   numa
rede,  RS485  ou   equivalente,  acessível
através   de  um  gateway.  Nesta   situação   o
endereço IP de destino é o do gateway e este
ao  receber   a   mensagem,  transforma­a   na
PDU apropriada destinada para o  slave  com
este   número  e   o   oposto   acontece   na
resposta. Se o servidor de destino estiver na
rede  Ethernet,   é   endereçado   normalmente
através do IP e este campo deve ser 0xFF ou
0x00.
Por permitir um maior número de dispositivos na
mesma   rede,  permitir   a   transmissão   de   um   novo
pedido antes de se obter a resposta para o anterior,
esta implementação é mais capaz e rápida apesar de
ser   transmitida   muita   informação   não   útil  nas
tramas.  Esta   implementação   permite   também   que
exista   comunicação   entre   dispositivos   em   locais
afastados através da Internet.
4. Implantação
O  protocolo  Modbus  é   utilizado   em  muitos
equipamentos  para  realização   de  troca   de   dados,
sendo em redes de comunicação série, a versão RTU
a mais utilizada a seguir ao protocolo Profibus e em
redes   baseadas   em   Ethernet   a   versão   TCP/IP   é   a
quarta   mais   implementada  [1].  Mesmo   assim
existem   muitos   mais   que  não   implementam  o
protocolo  exatamente   como   este   está   especificado,
mas   sim   uma   variante,   nomeadamente   quanto   ao
tipo de dados transmitidos. O protocolo Modbus está
definido para utilizar os tipos de dados mais comuns
nos PLCs, bits (Coils ou Discrete Inputs) e registos de
16  bits  (Holding  Registers  ou  Input   Registers)
usualmente   chamados   de  words.  Não   muito
raramente são desenvolvidos servidores Modbus, que
retornam dados estruturados no lugar de registos de
16 bits em resposta a pedidos com o Function code 3
ou 4.
O   protocolo  Modbus  é  implementado
principalmente  para  comunicação  entre
equipamentos de controlo e/ou sensorização, mas é
apontado   como   sendo   possivelmente   o   mais
implementado em termos globais  em  aplicações  de
monitorização  Supervisory  control   and   data
acquisition (SCADA) [9].
Por  ser   um   protocolo   que   não   define   a   camada
lógica,  dispositivos  Modbus  que   utilizem   interfaces
diferentes  não  podem ser ligados, a não ser que se
utilizem  equipamentos   com  gateways  ou
conversores, o  que  pode  ser considerado frustrante.
No   entanto   por   não   ter   restrições   a   este   nível,   é
possível   se   desenvolverem   equipamentos   que
utilizem   as  interfaces   mais   adequadas  ao   meio   em
que vão ser utilizados.
Mesmo   assim   verifica­se   que   a   quase   totalidade
dos   dispositivos  Modbus  seguem   as   orientações
documentadas   e  publicadas   pela  Modbus
Organization, tornando fácil instalar na mesma rede
dispositivos de  vários  fabricantes e assegurar a sua
compatibilidade. Mesmo quando os mesmos utilizam
interfaces   diferentes,   é   fácil   de   encontrar
conversores apropriados, que tornam a comunicação
transparente.
Se for necessário que a comunicação seja efetuada
de forma  wireless  ou por fibra ótica, em  ambientes
que o requeiram, podem ser seguidas as definições
do documento MODBUS over Serial Line Specification
and   Implementation   Guide   V1.02  [5]  e   tratar   a
ligação  wireless  como   se   fosse   RS485,   pois   é   na
mesma um meio partilhado entre os dispositivos e a
fibra ótica como RS232, pois  é utilizada  uma  para
emitir (TX) e outra para receber (RX). O mais usual
é   os   dispositivos   comunicarem   com   conversores
externos.
5. Comparação
Existem vários protocolos para redes de  campo e
muitos  apresentam   certas   vantagens   em   algum
aspeto  quando   comparados   com   outros,   o   que   os
torna mais apropriados para certos tipos de rede de
campo.  Neste  capítulo  será  efetuada  a  comparação
entre as caraterísticas do protocolo Modbus e outros
protocolos   de   rede   de   campo,  que   são
implementados   no   mesmo  âmbito  de   redes  de
campo,   ou   seja   para   comunicação   entre   PLCs   ou
equipamentos   equivalentes  e  por   isso  foram
escolhidos   os   protocolos  Building  Automation
Controls Network (BACnet) e ProfIbus.
5.1. BACnet
BACnet  [10]  é um  protocolo  desenvolvido com o
principal   objetivo   de   interligar  sistemas   de
automação   em   edifícios,  de   forma   a   estes
comunicarem entre si, em especial para poderem ser
controlados por uma central de comando. O tipo de
dados trocado é denominado no protocolo de objeto,
e é normalmente do tipo binário, de apenas um bit,
ou analógico com mais bits, mas também podem ser
trocados   dados   estruturados  ou   processos
computacionais  estando definidos no total 23 tipos
de   objetos   no   protocolo.  Para   cada   objeto  estão
definidas   propriedades   como   valor,   tipo   de   dados,
máximo, etc... E são estas propriedades que são lidas
ou   escritas.  Para   isso   estão   definidos   os   tipos   de
mensagens que se usam chamados de serviços.
Este protocolo utiliza Ethernet ou RS485 tal como
o  Modbus  e os dispositivos podem ser endereçados
como  slaves  com um endereço atribuído  ou através
de  endereço  IP  no caso de a comunicação ser feita
pela Internet [11].
Em   comparação   com   o  Modbus,   os  dados   estão
definidos  de maneira diferente e existem mais tipos
de   dados   definidos   pelo   BACnet,  tendo   cada   um
vários parâmetros.  O fato de o número de serviços
definidos   ser   menor   que   o   número   de   funções   do
Modbus, fica compensado pela existência dos vários
tipos   de   objetos.  Mas   quando   o   BACnet   é
implementado em RS485,  existe passagem de  token
e   à   vez   cada   dispositivo   funciona   como  master  da
rede, algo não definido como possível em Modbus.
5.2. Profibus
Existem   duas  versões   do   protocolo  Profibus.  A
versão  Profibus   DP  comunica   por  RS485  ou   fibra
ótica com baudrates até 12 Mbps e cabos e conetores
próprios  [12].   Esta   versão   também   implementa
passagem de  token, permitindo que  seja um  master
diferente a controlar a rede. Ao contrário da BACnet,
os  slaves  nunca   funcionam   como  master,   tal   como
um  master  nunca funciona como  slave.  A passagem
do token é feita apenas entre masters [13].
A versão  Profibus PA  comunica  pela denominada
Manchester   Bus   Power,   uma   ligação   própria   que
transmite não só as mensagens mas também energia
para  alimentar  os  equipamentos   pelos   cabos.  Esta
versão   foi   criada   para   ser   implementada   em
ambientes  com   risco   de   explosão.  Enquanto   que   a
versão  Profibus DP  pode transmitir até 12 Mbps  a  o
Profibus PA  transmite sempre a 31,25 kbps.  Ambas
as versões apresentam cabos com cores próprias, o
que   é   muito   prático,  para   se   poder   determinar
rapidamente que tipo de protocolo passa nos cabos
especialmente   em   zonas   com   grande   densidade   de
diferentes cabos.
Comparando   com  Modbus,  o  Profibus  apresenta
vantagens  em  termos  de interface pois  permite  ter
velocidades   de  comunicação   mais   rápidas  e  têm
conectores e cabos próprios nomeadamente as cores
e  o fato de a versão  Profibus PA  poder ser utilizada
em   ambientes   com   risco   de   explosão  [14].   No
entanto o tipo de dados em Profibus é mais complexo
tal como a PDU, o que dá vantagem ao Modbus  por
ser mais fácil de perceber e implementar [15].
6. Caso prático
É apresentado o exemplo da rede que implementa
Modbus  sobre RS485  implementando o modo RTU,
ilustrada na figura 7.
Figura 7. Rede RS485 na qual é
implementado Modbus RTU, com um
master e dois slaves [16].
Nesta  rede o  master  é  um  computador industrial
Impact­E   30.  Neste   está   instalado   um  software
SCADA,   configurado   para   a   rede   e   para   os
dispositivos que estão ligados à mesma. Este tipo de
software tem interface gráfica e permite ao utilizador
configurar as mensagens que o master irá transmitir
quer para receber dados como para enviar, de forma
fácil   e  interativa,   pelo   que  o   utilizador   muitas  das
vezes  nem   precisa   de   saber   o   funcionamento   do
protocolo Modbus. Pode­se visualizar na imagem que
é   utilizado   um   conversor   de   RS232   para   RS485   à
saída do computador, apesar de este ter uma saída
RS485.  O  uso   deste   tipo   de   conversores   é   comum
principalmente nos slaves, por exemplo quando estes
são  servidores TCP/IP ou a interface do dispositivo
for diferente.
Os dois  slaves  desta rede  são módulos RU­87P8,
naturalmente  com   endereços   diferentes,  que   são
configurados   por   dois   botões   rotacionais  presentes
na   frente   de   cada   módulo.  Os   dois   têm   interfaces
para   receção   de   sinais   do   tipo   4­20   mA  e   nestas
interfaces estão ligados contadores de impulsos, que
apesar de não estar explicito, devem funcionar como
entradas analógicas ou seja Input Registers.
 Assim é possível saber quanto é  medido  em cada
um dos contadores a partir do computador, que pode
estar instalado a uma grande distância dos  slaves  e
pode,  depois,  ser   guardado   no   computador  um
ficheiro com os valores medidos ao longo do tempo
ou  até mesmo estes dados  serem enviados para um
servidor remoto.
7. Conclusões
Ao   longo   de   toda   a   sua   existência   o   protocolo
Modbus  tem   sido   implementado   em   sistemas
automáticos, de controlo remoto e de monitorização.
Talvez  a   maior  vantagem  que o  leva  a   ser  mais
escolhido   para   implementação,  seja   a  sua
simplicidade.  Quando   é   necessário   se   implementar
um protocolo de rede de campo, num dispositivo,  o
fato do  Modbus  ser simples,  facilita  em  muito  pois
não requer um processo de aprendizagem longo.
Para além de todas as vantagens mencionadas ao
longo   deste   documento,   como   existem  Function
codes que podem ser implementados de forma livre,
o protocolo Modbus possibilita que  estes possam ser
utilizados   para  troca   de  dados   estruturados  com
servidores  ou   requerer   que   estes   executem   ações
específicas  tendo   em   conta   o   seu   contexto  de
utilização.
Este   protocolo  não   implementa   nenhum   tipo  de
codificação   para   segurança   da   informação
transmitida pela rede, o que é por vezes apontado
como uma falha [17], mas tendo em conta o tipo de
implementação   para   a   qual   o   protocolo   foi
desenvolvido, tal caraterística pode ser ignorada.
Por   ser   um   protocolo   que   de   forma   simples
permite a troca de dados essencialmente utilizados
em   redes   de   campo,   com   liberdade   de
desenvolvimento   de   funções,  com   custos   de
instalação menores em comparação com outros e por
já estar tão presente nas várias indústrias [18] [19],
este   protocolo  provavelmente  continuará   a   ser
implementado mesmo que não seja o melhor.
8. Referências
[1]  Introduction   to   Fieldbus   Systems.  [pdf]
Disponível   em:  http://people.cs.pitt.edu/  [Acedido:
5 de Junho de 2018].
[2]  Jeff  Kordik,  Fundamental Guide to Industrial
Networking. 2017. [pdf].
[3]  Schneider Electric,  Modicon is now  Schneider
Electric.  2018.   [site]   Disponível   em:
https://www.schneider­electric.co.uk/  [Acedido:  8
de Maio de 2018].
[4]  History of  the Modbus protocol.  [documento]
Disponível   em:  https://w3.usa.siemens.com
   /  
[Acedido: 1 de Junho de 2018].
[5] Modbus.org, MODBUS over Serial Line 
Specification and Implementation Guide V1.02. 20
de Dezembro de 2006. [pdf].
[6]  Modbus.org,  MODBUS   Messaging   on   TCP/IP
Implementation   Guide   V1.0b.  24   de   Outubro   de
2006. [pdf].
[7]  Modbus.org,  MODBUS   Application   Protocol
Specification V1.1b3. 26 de Abril de 2012. [pdf].
[8]  MODICON,  Modicon   Modbus   Protocol
Reference Guide. Junho 1996. [pdf].
[9]  Paul   Smart,  Why   Modbus   Matters:   An
Introduction.  9   de   Fevereiro   de   2015.   [site]
Disponível   em:  https://www.campbellsci.com
   /  
[Acedido: 4 de Junho de 2018].
[10]  Control   Solutions,  BACnet   Tutorial   from
Control   Solutions.  2016.   [site]   Disponível   em:
https://www.csimn.com/  [Acedido:  8  de   Junho   de
2018].
[11]  H.   Michael   Newman,  BACnet   ­   A   Tutorial
Overview.  15  de  Outubro  de  1998.  [apresentação]
Disponível em: http://www.bacnet.org/.
[12]  RF   Wireless   World,  Profibus   vs   Modbus­
difference   between   Profibus   and   Modbus.  2012.
[site]   Disponível   em:  http://www.rfwireless­
world.com/ [Acedido: 8 de Junho de 2018].
[13] PROFIBUS Nutzerorganisation e. V., PROFIBUS
&   PROFINET   International,  PROFIBUS   System
Description  Technology and Application.  Karlsruhe
Germany, Abril de 2016. [pdf].
[14]  James   Powell,  Profibus   and   Modbus:   a
comparison. Karlsruhe Germany, 2013. [pdf].
[15]  John   Rinaldi,  PROFIBUS   OBJECT   MODELS.
Edição.  29 de Dezembro de 2009. [site] Disponível
em: https://www.rtaautomation.com/.
[16]  Amplicon,  Process   Control   and   Automation
using Modbus Protocol. [pdf].

[17]  Nikko   Phongchit,  What  is  the  difference

between  BACnet,  Modbus  and  LonWorks?.  21   de
Julho   de   2016.   [site]   Disponível   em:
https://www.setra.com/.

[18]  Julie Gruenholz,  Why, In 2017, Are We Still

Using   Modbus?.  14   de   Setembro   de   2017.   [site]
Disponível em: https://www.hallam­ics.com/.

[19]  Using   MODBUS   for   Process   Control   and

Automation.  [pdf]  Disponível   em:
http://www.miinet.com/.