Está en la página 1de 6

O protocolo Modbus em detalhes

Publish Date: Ago 01, 2014

Overview
O Modbus um protocolo industrial desenvolvido em 1979 para possibilitar a comunicao entre dispositivos de automao. Originalmente implementado como um protocolo de nvel de
aplicao destinado a transferir dados por uma camada serial, o Modbus foi ampliado para incluir implementaes em comunicaes seriais, TCP/IP e UDP (user datagram protocol). Este
documento oferece uma viso detalhada da implementao do protocolo.

Table of Contents
1. O que o protocolo Modbus?
2. Unidade de dados de protocolo
3. Unidade de dados de aplicao
4. Novos cdigos de funo
5. Camadas de rede
6. Modificaes da ADU

1. O que o protocolo Modbus?


O Modbus um protocolo de requisio-resposta que utiliza um relacionamento mestre-escravo. Em um relacionamento mestre-escravo, a comunicao sempre ocorre em pares um
dispositivo deve iniciar a requisio e ento aguardar por uma resposta e o dispositivo iniciador (o mestre) responsvel por iniciar cada interao. Tipicamente, o mestre uma interface
homem-mquina (IHM) ou sistema SCADA (Supervisory Control and Data Acquisition) e o escravo um sensor, controlador lgico programvel (CLP) ou controlador programvel para
automao (CPA). O contedo dessas requisies e respostas e as camadas de rede pelas quais essas mensagens so enviadas so definidos pelas diferentes camadas do protocolo.

Figura 1. Relacionamento de rede tipo mestre-escravo

Camadas do protocolo Modbus


Em sua implementao inicial, o Modbus era um protocolo simples, criado no topo da comunicao serial; dessa forma, no podia ser dividido em camadas. Ao longo do tempo, outras unidades
de dados de aplicao foram sendo introduzidas para alterar o formato dos pacotes utilizados sobre o serial ou permitir o uso de TCP/IP e redes UDP (User Datagram Protocol). Isso levou a uma
separao entre o protocolo bsico, que define a unidade de dados de protocolo (PDU) e a camada de rede, que define a unidade de dados de aplicao (ADU).

2. Unidade de dados de protocolo


A PDU e seu cdigo formam a base da especificao do protocolo de aplicao do Modbus . Essa especificao define o formato da PDU, os diversos conceitos de dados usados pelo protocolo,
o uso de cdigos de funo para acessar esses dados e a implementao dos diversos cdigos de funo e as restries especficas de cada um deles.
A PDU do Modbus formada por um cdigo de funo seguido por um conjunto de dados associado. As dimenses e o contedo desses dados so definidos pelo cdigo de funo, mas toda a
PDU (cdigo de funo e dados) no pode ultrapassar 253 bytes. Cada cdigo de funo tem um comportamento especfico, que os escravos tm flexibilidade para implementar com base no
comportamento desejado da aplicao. A especificao de PDU define os conceitos bsicos para o acesso e manipulao dos dados; entretanto, um escravo pode tratar os dados de uma
maneira no definida explicitamente na especificao.

Acesso aos dados no Modbus e o modelo de dados do Modbus


Os dados que podem ser acessados pelo Modbus so armazenados, de forma geral, em um dos quatro bancos de dados, ou faixas de endereo: coils, entradas discretas, registradores holding e
registradores de entrada. Como ocorre com muitas partes da especificao, esses nomes podem variar, dependendo da indstria ou aplicao. Por exemplo, os registradores holding podem ser
denominados registradores de sada, e os coils podem ser referidos como sadas digitais ou discretas. Esses bancos de dados definem o tipo e os direitos de acesso dos dados contidos. Os
dispositivos escravo tm acesso direto a esses dados, que so hospedados localmente nos dispositivos. Os dados que podem ser acessados pelo Modbus so de forma geral um subconjunto da
memria principal do dispositivo. Por outro lado, os mestres Modbus precisam solicitar acesso a esses dados, utilizando diversos cdigos de funo. O comportamento de cada bloco descrito
no quadro 1.

Bloco de memria

Tipo de dados

Acesso ao mestre

Acesso ao escravo

Coils

Booleano

Leitura/escrita

Leitura/escrita

Entradas discretas

Booleano

Somente leitura

Leitura/escrita

Registradores holding

Palavra no sinalizada

Leitura/escrita

Leitura/escrita

Registradores de entrada

Palavra no sinalizada

Somente leitura

Leitura/escrita

Quadro 1. Blocos do modelo de dados do Modbus


Esses blocos do a voc a capacidade de restringir ou permitir acesso a diferentes elementos de dados e tambm fornecer mecanismos simplificados na camada de aplicao para o acesso a
diferentes tipos de dados.
Os blocos so totalmente conceituais. Eles podem existir como endereos de memria distintos em um dado sistema, mas tambm podem se sobrepor entre si. Por exemplo, o coil 1 pode existir
na mesma posio de memria que o primeiro bit da palavra representada pelo registrador holding 1. O esquema de endereamento totalmente definido pelo dispositivo escravo, e a
interpretao de cada bloco de memria uma parte importante do modelo de dados do dispositivo.
Endereamento do modelo de dados
A especificao define que cada bloco contm um espao de endereamento de at 65.536 (2 16) elementos. Com a definio da PDU, o Modbus define o endereo de cada elemento de dados
na faixa de 0 a 65.535. Entretanto, cada elemento de dados numerado de 1 a n, onde n tem o valor mximo de 65.536. Assim, o coil 1 est no endereo 0 do bloco de coils, enquanto que o
registrador holding 54 est no endereo 53 da seo de memria reservada pelo escravo para os registradores holding.
No obrigatrio implementar as faixas completas permitidas pela especificao no dispositivo. Por exemplo, pode ser escolhido para um dado dispositivo no implementar coils, entradas
discretas ou registradores de entrada e, em vez disso, utilizar registradores holding de 150 a 175 e 200 a 225. Isso perfeitamente aceitvel; nesse caso, tentativas de acesso invlidas seriam
tratadas por excees.

1/6

www.ni.com

Faixas de endereamento de dados


Embora a especificao defina que diferentes tipos de dados devem existir em blocos diferentes e atribua uma faixa de endereos local para cada tipo, isso no implica que haver
necessariamente um esquema de endereamento intuitivo ou facilmente compreensvel para a documentao da memria que pode ser acessada pelo Modbus para um determinado dispositivo.
Para simplificar a discusso sobre as posies dos blocos de memria, foi introduzido um esquema de numerao que inclui prefixos ao endereo dos dados em questo.
Por exemplo, em vez de se referir a um item como registrador holding 14 no endereo 13, o manual do dispositivo pode se referir a um item de dados no endereo 4.014, 40.014 ou 400.014. Em
todos esses casos, o primeiro nmero especificado 4, que representa os registradores holding; os demais nmeros especificam um endereo. A diferena entre 4XXX, 4XXXX e 4XXXXX
depende do espao de endereos utilizado pelo dispositivo. Se todos os 65.536 registradores estiverem em uso, utilizaremos a notao 4XXXXX, pois ela permite o uso da faixa de 400.001 a
465.536. Se apenas alguns registradores forem usados, uma prtica comum usar a faixa de 4.001 a 4.999.
Nesse esquema de endereamento, cada tipo de dados recebe um prefixo, como mostrado no quadro 2.

Bloco de dados

Prefixo

Coils

Entradas discretas

Registradores de entrada

Registradores holding

4
Quadro 2. Prefixos das faixas de dados

Coils utilizam o prefixo 0. Isso significa que a referncia 4001 pode se referir ao registrador holding 1 ou ao coil 4001. Por esse motivo, recomendado que todas as implementaes novas
utilizem o endereamento de 6 dgitos com zeros na frente. Essa informao dever ser anotada na documentao. Dessa forma, o registrador holding 1 referenciado como 400.001 e o coil
4001 referenciado como 004.001.
Valores iniciais dos endereos de dados
A diferena entre endereos de memria e nmeros de referncia inclui uma complicao adicional, representada pela indexao selecionada por uma determinada aplicao. Como mencionado
anteriormente, o registrador holding 1 est localizado no endereo 0. Tipicamente, os nmeros de referncia so indexados em 1; nesse caso, o valor inicial de uma faixa ser 1. Dessa forma, a
traduo literal de 400.001 registrador holding 00001, que est no endereo 0. Algumas implementaes escolhem iniciar suas faixas em zero; dessa forma, 400.000 indica registrador holding
no endereo zero. O quadro 3 demonstra esse conceito.
Endereo

Nmero do registrador

Nmero (indexao em 1, padro)

Nmero (indexao em 0, alternativa)

400001

400000

400002

400001

400003

400002

Quadro 3. Esquemas de indexao dos registradores

Faixas indexadas em 1 so muito usadas e altamente recomendadas. De qualquer forma, o valor inicial de cada faixa sempre dever ser indicado na documentao.

Tipos de dados para grandes valores


O padro Modbus oferece um modelo de dados relativamente simples, que no inclui outros tipos de dados alm do valor do bit e palavra no sinalizada. Esses valores podem ser suficientes
para alguns sistemas, nos quais os valores de bit correspondem a solenides e rels e os valores das palavras correspondem a valores ADC sem escala, mas no para sistemas avanados.
Como resultado, muitas implementaes do Modbus incluem tipos de dados que vo alm das fronteiras do registrador. O mdulo LabVIEW Datalogging and Supervisory Control (DSC) e o
KEPServerEX definem alguns tipos de referncia. Por exemplo, as strings armazenadas em um registrador holding seguem o formato padro (400.001), mas so seguidas por um decimal, o
comprimento e o byte que ordena a string (400.001.2H, uma string de 2 caracteres no registrador holding 1, onde o byte em nvel alto corresponde ao primeiro caractere da string). Isso
necessrio porque cada requisio tem tamanho finito; dessa forma, o mestre Modbus precisa saber exatamente onde a string comea e termina, em vez de procurar por um comprimento fixo ou
delimitador, como o NULL.

Acesso a bit
Alm de permitir acesso a dados que vo alm das fronteira do registrador, alguns mestres Modbus permitem o uso de referncias a bits individuais dentro de um registrador. Com isso, os
dispositivos podem combinar dados de todos os tipos em uma mesma faixa de memria sem ter de separar dados binrios no coil e faixas de entrada discretas. Normalmente, esse recurso
indicado pelo uso de um ponto decimal e o ndice de bit ou nmero, dependendo da implementao. Ou seja, o primeiro bit do primeiro registrador pode ser 400.001.00 ou 400.001.01.
recomendado que toda documentao especifique o esquema de indexao utilizado.

Configurao endian dos dados


Os dados de mltiplos registros, como valores de ponto flutuante de preciso nica, podem ser facilmente transferidos ao Modbus, com a separao dos dados em dois registradores. Como isso
no definido pelo padro, a ordem de bit (endian) utilizada nessa separao tambm no est definida. Cada palavra no sinalizada deve ser enviada na ordem de bit usada pela rede (big
endian) para satisfazer o padro, mas muitos dispositivos invertem a ordem de bytes no caso de dados formados por vrios bytes. A figura 2 mostra um exemplo incomum, mas vlido, dessa
implantao.

Figura 2. Inverso da ordem de bytes em dados formados por vrias palavras


de responsabilidade do mestre entender como o escravo est armazenando informaes na memria e decodific-las adequadamente. recomendvel que a documentao informe a ordem
da palavra usada pelo sistema. A ordem endian pode tambm ser entendida como uma opo de configurao do sistema, com funes de codificao e decodificao, se for necessrio ter
flexibilidade na implementao.

Strings
Strings podem ser armazenadas facilmente em registradores Modbus. Por simplicidade, algumas implementaes requerem que os comprimentos de string sejam mltiplos de 2 e que qualquer
espao adicional seja preenchido por valores nulos. A ordem dos bytes tambm uma varivel nas interaes das strings. O formato das strings pode ou no incluir um NULL como valor final.
Como exemplo dessa variabilidade, alguns dispositivos podem armazenar dados como mostrado na figura 3.

2/6

www.ni.com

Figura 3. Inverso da ordem dos bytes em strings do Modbus

Cdigos de funo
Ao contrrio do modelo de dados, que pode variar significativamente de um dispositivo a outro, os cdigos de funo e seus dados so definidos explicitamente pela norma. Cada funo segue
um padro. Em primeiro lugar, o escravo valida entradas como, por exemplo, cdigo de funo, endereo dos dados e faixa de dados. Em seguida, ele executa a ao requisitada e envia a
resposta apropriada ao cdigo. Se qualquer etapa desse processo falhar, uma exceo ser enviada de volta ao requisitante. O transporte de dados dessas solicitaes a PDU.

A PDU do Modbus
A PDU formada por um cdigo de funo de 1 byte seguido por at 252 bytes de dados de funo.

Figura 4. A PDU do Modbus


O cdigo de funo o primeiro item a ser validado. Se o cdigo de funo no for reconhecido pelo dispositivo que recebe a requisio, ele responder com uma exceo. Se o cdigo de
funo for aceito, o dispositivo escravo comear a decompor os dados conforme a definio da funo.

Como o tamanho do pacote limitado a 254 bytes, os dispositivos so limitados com relao quantidade de dados que pode ser transferida. Os cdigos de funo mais comuns podem
transferir entre 240 e 250 bytes de dados do modelo de dados do escravo, dependendo do cdigo.

Execuo da funo pelo escravo


Conforme definido pelo modelo de dados, diferentes funes so definidas para acessar diferentes blocos conceituais de dados. Uma implementao muito usada faz os cdigos acessarem
posies estticas de memria, mas outros comportamentos podem ser usados. Por exemplo, cdigo de funo 1 (ler coils) e 3 (ler registradores holding) podem acessar a mesma posio fsica
na memria. Por outro lado, o cdigo de funo 3 (ler registradores holding) e 16 (escrever em registradores holding) podem acessar posies de memria completamente diferentes. Dessa
forma, a execuo de cada cdigo de funo melhor considerada como parte da definio do modelo de dados do escravo.
Independentemente do comportamento executado, todos os dispositivos escravo devem seguir um diagrama de estados simples para cada requisio. A figura 5 mostra um exemplo baseado no
cdigo 1, ler coils.

Figura 5. Diagrama de estado de leitura de coils conforme a especificao do protocolo Modbus


Cada escravo precisar validar o cdigo de funo, quantidade de entradas, endereo inicial, faixa total e a execuo da funo pelo escravo que far a leitura.
Embora sejam mostradas faixas de endereos estticos no diagrama de estados acima, as necessidades dos sistemas do mundo real podem causar alguma variao com relao aos nmeros
definidos. Em alguns casos, os dispositivos escravo no conseguem transferir a quantidade mxima de bytes definida pelo protocolo. Isso significa no permitir que um mestre requisite 0x07D0
entradas se eles s podem responder com 0x0400. De maneira similar, um modelo de dados de escravo pode definir a faixa de valores de coil aceitveis como os endereos de 0 a 500. Se um
mestre fizer uma requisio de 125 endereos a partir do endereo 0, isso estar OK, mas se fizer a mesma requisio a partir do endereo 400, o coil final estaria no endereo 525, que est
fora da faixa para esse dispositivo, o que resultaria na exceo 02, conforme definido pelo diagrama de estados.

Cdigos de funo padro


A definio de cada cdigo de funo padro fornecida na especificao. Mesmo para os cdigos de funo mais comumente usados, inevitvel haver algum descasamento entre as funes
habilitadas no mestre e aquelas que podem ser tratadas pelo escravo. Para lidar com isso, as verses mais recentes da especificao TCP do Modbus definiu trs classes de conformidade. O
documento oficial Modbus Conformance Test Specification no faz referncia a essas classes; em vez disso, define conformidade para cada funo. Entretanto, elas ainda podem facilitar a
compreenso. recomendado que qualquer documentao siga a especificao do teste e defina sua conformidade pelos cdigos que pode utilizar, e no pelas classificaes usadas
anteriormente.
Cdigos da classe 0
Os cdigos da classe 0 so considerados em geral o mnimo para um dispositivo Modbus utilizvel, pois do a um mestre a capacidade de ler ou escrever no modelo de dados.

3/6

www.ni.com

Os cdigos da classe 0 so considerados em geral o mnimo para um dispositivo Modbus utilizvel, pois do a um mestre a capacidade de ler ou escrever no modelo de dados.
Cdigo

Descrio

Read Multiple Registers

16

Write Multiple Registers


Quadro 4. Cdigos em conformidade com a classe 0

Cdigos da classe 1
Os cdigos de funo da classe 1 compreendem outros cdigos necessrios para acessar todos os tipos do modelo de dados. Na definio original, essa lista inclua o cdigo de funo 7 (ler
exceo). Entretanto, esse cdigo definido pela especificao atual como cdigo somente serial.
Cdigo

Descrio

Read Coils

Read Discrete Inputs

Read Input Registers

Write Single Coil

Write Single Register

Read Exception Status (somente serial)


Quadro 5. Cdigos em conformidade com a classe 1

Cdigos da classe 2
Os cdigos de funo da classe 2 so funes mais especializadas, implementadas com menor frequncia. Por exemplo, Read/Write Multiple Registers pode ajudar a reduzir a quantidade total
de ciclos de requisio-resposta, mas o comportamento ainda pode ser implementado com cdigos de classe 0.
Cdigo

Descrio

15

Write Multiple Coils

20

Read File Record

21

Write File Record

22

Mask Write Register

23

Read/Write Multiple Registers

24

Read FIFO
Quadro 6. Cdigos em conformidade com a classe 2

Interface encapsulada do Modbus


O cdigo de interface encapsulada do Modbus (MEI), funo 43, usado para encapsular outros dados dentro de um pacote Modbus. At o momento, h dois nmeros de MEI disponveis, 13
(CANopen) e 14 (Device Identification).
A funo 43/14 (Device Identification) til por permitir a transferncia de at 256 objetos exclusivos. Alguns desses objetos so pr-definidos e reservados, como nome do fornecedor e cdigo
do produto, mas aplicaes podem definir outros objetos a serem transferidos como conjuntos de dados genricos.
Esse cdigo no implementado comumente.

Excees
Os escravos usam excees para indicar diversas condies problemticas, de requisies mal formadas a entradas incorretas. Entretanto, as excees podem tambm ser geradas como
resposta no nvel da aplicao a uma requisio invlida. Os escravos no respondem a requisies emitidas com uma exceo. Nesses casos, o escravo ignora uma requisio incompleta ou
corrompida e comea a esperar pela chegada de uma nova mensagem.
Excees so relatadas em um formato de pacote definido. Em primeiro lugar, um cdigo de funo enviado de volta ao mestre solicitante igual ao cdigo de funo original com exceo de
seu conjunto de bits mais significativo. Isso equivale a incluir 0x80 ao valor do cdigo de funo original. Em vez dos dados normais associados resposta a uma determinada funo, as
respostas exceo incluem um nico cdigo de exceo.
No padro, os quatro cdigos de exceo mais comuns so 01, 02, 03 e 04. Esses cdigos so mostrados no quadro 7, com os significados padro para cada funo.
Cdigo de exceo

Significado

01

O cdigo de funo recebido no suportado. Para confirmar o cdigo de funo original, subtraia 0x80 do valor retornado.

02

A requisio tentou acessar um endereo invlido. No padro, isso pode acontecer somente se o endereo inicial e a quantidade de valores requisitada ultrapassar
216. Entretanto, alguns dispositivos podem limitar ainda mais esse espao de endereos em seus modelos de dados.

03

A requisio tem dados incorretos. Em alguns casos, isso significa que houve algum descasamento entre parmetros, por exemplo, entre o nmero de registradores
enviados e o campo "byte count". Mais comumente, o mestre solicitou mais dados do que permitido pelo escravo ou pelo protocolo. Por exemplo, um mestre pode
ler apenas 125 registradores holding por vez, e dispositivos com recursos limitados podem reduzir ainda mais esse nmero de registradores.

04

Ocorreu um erro no recupervel durante uma tentativa de processar a requisio. Esse um cdigo de exceo geral, que indica que a requisio era vlida, mas
o escravo no conseguiu execut-la.
Quadro 7. Cdigos comuns de exceo do Modbus

O diagrama de estado para cada cdigo de funo deve cobrir pelo menos o cdigo de exceo 01 e normalmente incluir os cdigos 04, 02 e 03; quaisquer outros cdigos de exceo definidos
so opcionais.

4/6

www.ni.com

3. Unidade de dados de aplicao


Alm das funes definidas no ncleo da PDU do protocolo Modbus, voc pode usar diversos protocolos de rede. Os protocolos mais usados so TCP/IP e serial, mas voc tambm pode usar
outros, como o UDP. Para transmitir os dados necessrios para o Modbus em todas essas camadas, o Modbus inclui um conjunto de variantes de ADU feitas especificamente para cada
protocolo de rede.
Recursos comuns
O Modbus requer determinados recursos para fornecer comunicao confivel. O Unit ID ou Address usado em todos os formatos de ADU para fornecer informaes de roteamento camada
de aplicao. Cada ADU fornecida com uma PDU completa, incluindo o cdigo de funo e os dados associados a uma determinada requisio. Para aumentar a confiabilidade, todas as
mensagens contm informaes de verificao de erro. Alm disso, todas as ADUs possuem um mecanismo que determina o incio e o fim do quadro da requisio, mas os implementa de
formas diferentes.
Formatos padro
Os trs formatos padro para as ADUs so TCP, RTU (unidade de terminal remoto) e ASCII. As ADUs dos tipos RTU e ASCII so tradicionalmente utilizadas por uma linha serial, enquanto que o
TCP usado em redes TCP/IP ou UDP/IP modernas.
TCP/IP
As ADUs do tipo TCP so formadas pelo cabealho do Modbus Application Protocol (MBAP) concatenado com a PDU do Modbus. O MBAP um cabealho de uso geral, que depende de uma
camada de rede confivel. O formato dessa ADU, incluindo o header, mostrado na figura 6.

Figura 6. A ADU do tipo TCP/IP


Os campos de dados do cabealho indicam seu uso. Em primeiro lugar, ele contm um identificador de transaes. Esse um recurso valioso em uma rede que pode ter vrias requisies em
processamento simultaneamente. Com isso, por exemplo, um mestre pode enviar requisies 1, 2 e 3. Em algum ponto posteriormente, um escravo pode responder na ordem 2, 1, 3. Nesse
caso, o mestre pode combinar as requisies com suas respostas e interpretar os dados corretamente. Esse um recurso til para redes Ethernet.
O identificador do protocolo normalmente zero, mas voc pode us-lo para expandir o comportamento do protocolo. O campo Length usado pelo protocolo para delinear o comprimento do
restante do pacote. A posio desse elemento tambm indica a dependncia desse formato do cabealho em uma camada de rede confivel. Como os pacotes TCP possuem verificao de erro
incorporada e garantem a coerncia e entrega dos dados, o comprimento do pacote pode estar localizado em qualquer parte do cabealho. Em uma rede inerentemente menos confivel, como
uma rede serial, um pacote pode ser perdido. Nesse caso, mesmo que um feixe de dados lido pela aplicao inclusse informaes vlidas de transao e protocolo, a informao corrompida de
comprimento tornaria o cabealho invlido. O TCP oferece um razovel grau de proteo contra essa situao.
O campo Unit ID normalmente no utilizado para dispositivos TCP/IP. Entretanto, o Modbus um protocolo to utilizado que muitos gateways diferentes foram desenvolvidos, o que converte o
protocolo Modbus em outro protocolo. Em sua destinao original, o gateway Modbus de TCP/IP para serial poderia ser usado para permitir a conexo entre novas redes TCP/IP e redes seriais
mais antigas. Em um ambiente como esse, a Unit ID usada para determinar o endereo do dispositivo escravo para o qual a PDU realmente destinada.
Para finalizar, a ADU contm uma PDU. O comprimento dessa PDU ainda limitado a 253 bytes no protocolo padro.
RTU
A ADU da RTU parece ser muito mais simples, como mostrado na figura 7.

Figura 7. ADU da RTU


Diferentemente da ADU mais complexa do TCP/IP, essa ADU contm apenas duas partes de informao alm da PDU base. Em primeiro lugar, um endereo usado para definir a qual escravo
a PDU destinada. Na maior parte das redes, o endereo 0 o endereo de "difuso". Isso significa que se um mestre enviar um comando ao endereo 0, todos os escravos devero processar
a requisio, mas nenhum deles dever responder. Alm desse endereo, um CRC usado para garantir a integridade dos dados.
Entretanto, nas implementaes mais modernas a realidade est muito longe de ser simples. O pacote delimitado por um par de intervalos de silncio ou seja, perodos nos quais no h
comunicao no barramento. Para a taxa de bauds de 9.600, esse intervalo de aproximadamente 4 ms. O padro define um intervalo de silncio mnimo, independente da taxa de bauds, um
pouco menor que 2 ms.

Em primeiro lugar, isso traz uma desvantagem ao desempenho, pois o dispositivo precisa esperar o trmino desse tempo de guarda antes de processar o pacote. Um problema maior, entretanto,
foi o surgimento de outras tecnologias utilizadas em transferncias seriais e taxas de baud muito maiores do que as existentes quando o padro foi lanado. Ao utilizar um cabo de converso
USB-serial, por exemplo, voc no tem controle sobre o empacotamento e transferncia dos dados. Testes mostram que usar um cabo USB-serial com o driver NI-VISA introduz grandes lacunas
de tamanho varivel no feixe de dados, e essas lacunas perodos de silncio confundem o cdigo que segue a especificao, fazendo-o acreditar que a mensagem foi concluda. Como a
mensagem no est completa, isso normalmente leva a um CRC invlido e interpretao pelo dispositivo de que a ADU foi corrompida.
Alm dos problemas com a transmisso, as modernas tecnologias de drivers abstraem significativamente a comunicao serial e tipicamente requerem um mecanismo de polling do cdigo de
aplicao. Por exemplo, nem o .NET Framework 4.5 SerialPort Class nem o NI-VISA fornecem um mecanismo para detectar silncio em uma linha serial alm do polling em bytes na porta. Isso
resulta em uma escolha de baixo desempenho (se o polling for realizado lentamente demais) ou alta utilizao da CPU (se o polling for executado rapidamente demais).
Um mtodo muito usado para tratar desses problemas separar a camada de abstrao entre a PDU do Modbus e a camada de rede. Com isso, o cdigo serial interroga o pacote da PDU do
Modbus para determinar o cdigo de funo. Em conjunto com outros dados no pacote, o comprimento do pacote restante pode ser descoberto e utilizado para determinar o final do pacote.
Tendo essa informao, possvel usar um tempo de timeout muito maior, permitindo lacunas na transmisso, e o polling da aplicao pode ocorrer muito mais lentamente. Esse mecanismo
recomendado para novos desenvolvimentos. Caso o seu cdigo no empregue esse mecanismo, voc poder ter uma quantidade de pacotes "corrompidos" maior que a esperada.
ASCII
A ADU do ASCII mais complexa que a RTU mostrada na figura 8, mas tambm evita muitos dos problemas do pacote de RTU. Entretanto, ela tem suas prprias desvantagens.

Figura 8. ADU do ASCII


Para resolver o problema da determinao do tamanho do pacote, a ADU do ASCII tem incio e fim nicos e bem definidos para cada pacote. Cada pacote iniciado por ":" e encerrado com os
caracteres CR (carriage return) e LF (line feed). Alm disso, APIs seriais como NI-VISA e o .NET Framework SerialPort Class podem facilmente ler dados em um buffer at que um caractere
especfico como CR/LR seja recebido. Essas caractersticas tornam mais fcil processar a transmisso de dados na linha serial de maneira eficiente nos modernos cdigos das aplicaes.
A desvantagem da ADU de ASCII que todos os dados so transferidos como caracteres hexadecimais codificados em ASCII. Isso significa que em vez de enviar um nico byte para o cdigo de
funo 3, 0x03, ela envia os caracteres ASCII 0 e 3, ou 0x30/0x33. Isso facilita a leitura do protocolo por um ser humano, mas isso tambm significa ser necessrio transferir o dobro dos
dados pela rede serial, alm disso, as aplicaes de envio e recepo devem ser capazes de interpretar os valores ASCII.

Extenso do Modbus
O Modbus um padro relativamente simples e aberto, que pode ser modificado conforme as necessidades de uma determinada aplicao. Esse o protocolo mais usado na comunicao entre
uma IHM e CLP ou CPA, pois essa uma situao na qual uma nica organizao controla as duas pontas do protocolo. Os desenvolvedores de sensores, por exemplo, tm maior probabilidade
de aderir ao padro escrito, porque eles tipicamente somente controlam a implementao de seus escravos, e a interoperabilidade desejvel.
De forma geral, no recomendvel modificar o protocolo. Esta seo simplesmente fornecida como um reconhecimento dos mecanismos que outros j usaram para ajustar o comportamento

5/6

www.ni.com

De forma geral, no recomendvel modificar o protocolo. Esta seo simplesmente fornecida como um reconhecimento dos mecanismos que outros j usaram para ajustar o comportamento
do protocolo.

4. Novos cdigos de funo


Alguns cdigos de funo esto definidos, mas o padro Modbus permite que voc desenvolva outros cdigos de funo. Especificamente os cdigos de funo de 1 a 64, 73 a 99 e de 111 a
127 so cdigos pblicos, reservados e com exclusividade garantida. Os cdigos restantes, de 65 a 72 e 100 a 110 so para uso definido pelo usurio. Com esses cdigos definidos pelo usurio,
voc pode usar qualquer estrutura de dados. Os dados podem at mesmo ultrapassar o limite de 253 bytes para a PDU do Modbus, mas toda a aplicao deve ser validada para garantir que as
outras camadas trabalharo como esperado quando a PDU ultrapassar o limite padro. Os cdigos de funo acima de 127 so reservados para respostas a excees.

5. Camadas de rede
O Modbus pode ser executado em muitas camadas de rede alm de serial e TCP. Uma implementao potencial o UDP, por ser adequado ao estilo de comunicao do Modbus. O Modbus
basicamente um protocolo baseado em mensagem; assim, a capacidade da UDP de enviar um pacote bem definido de informao sem qualquer informao adicional no nvel da aplicao,
como um caractere inicial ou comprimento, torna a implementao do Modbus extremamente simples. Em vez de exigir uma ADU adicional ou reutilizar uma ADU existente, os pacotes de PDU
do Modbus podem ser enviados pelo uso de uma API de UDP e serem recebidos totalmente formados na outra extremidade. Embora o TCP seja vantajoso para alguns protocolos, devido ao seu
sistema interno de acknowledgement, o Modbus realiza esse acknowledgement na camada de aplicao. Entretanto, usar o UDP dessa maneira elimina o campo de identificador de transao da
ADU do TCP, o que impede a possibilidade de haver diversas transaes simultneas. Assim, o mestre deve ser sncrono ou o pacote do UDP deve ter um identificador que ajude o mestre a
organizar requisies e respostas. Uma sugesto de implementao seria usar a ADU do TCP/IP em uma camada de rede do UDP.

6. Modificaes da ADU
Para finalizar, uma aplicao pode escolher modificar uma ADU ou usar partes no utilizadas de uma ADU existente, como o TCP. Por exemplo, o TCP define um campo de 16 bits, um protocolo
de 16 bits e uma Unit ID de 8 bits. Dado que a maior PDU do Modbus tem 253 bytes, o maior byte do comprimento sempre zero. Para Modbus/TCP, o campo de protocolo e a Unit ID so
sempre zero. Uma extenso simples do protocolo poderia enviar trs pacotes simultaneamente alterando o campo de protocolo para um nmero diferente de zero e usando os dois bytes no
utilizados (Unit ID e maior byte do campo de comprimento) para o envio dos comprimentos das duas PDUs adicionais (veja a figura 9).

Figura 9. Exemplo de modificao da ADU do TCP

Recursos adicionais
Especificao do protocolo de aplicaes Modbus
Por que o OPC UA importante
Sobre o OPC
Tecnologia EtherNet/IPCIP em Ethernet
Suporte a Digi
Biblioteca Modbus para Java

6/6

www.ni.com

También podría gustarte