Camadas de protocolo Modbus

Prévia do material em texto

O que é o protocolo Modbus?
O Modbus é um protocolo de requisição-resposta que utiliza um relacionamento mestre-escravo. Em um relacionamento mestre-escravo, a comunicação sempre ocorre em pares — um dispositivo deve iniciar a requisição e então aguardar por uma resposta — e o dispositivo iniciador (o mestre) é responsável por iniciar cada interação. Tipicamente, o mestre é uma interface homem-máquina (IHM) ou sistema SCADA (Supervisory Control and Data Acquisition) e o escravo é um sensor, controlador lógico programável (CLP) ou controlador programável para automação (CPA). O conteúdo dessas requisições e respostas e as camadas de rede pelas quais essas mensagens são enviadas são definidos pelas diferentes camadas do protocolo.
Figura 1. Relacionamento de rede tipo mestre-escravo
Camadas do protocolo Modbus
Em sua implementação inicial, o Modbus era um protocolo simples, criado no topo da comunicação serial; dessa forma, não podia ser dividido em camadas. Ao longo do tempo, outras unidades de dados de aplicação 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 separação entre o protocolo básico, que define a unidade de dados de protocolo (PDU) e a camada de rede, que define a unidade de dados de aplicação (ADU).
Voltar ao topo
Unidade de dados de protocolo
A PDU e seu código formam a base da especificação do protocolo de aplicação do Modbus. Essa especificação define o formato da PDU, os diversos conceitos de dados usados pelo protocolo, o uso de códigos de função para acessar esses dados e a implementação dos diversos códigos de função e as restrições específicas de cada um deles.
A PDU do Modbus é formada por um código de função seguido por um conjunto de dados associado. As dimensões e o conteúdo desses dados são definidos pelo código de função, mas toda a PDU (código de função e dados) não pode ultrapassar 253 bytes. Cada código de função tem um comportamento específico, que os escravos têm flexibilidade para implementar com base no comportamento desejado da aplicação. A especificação de PDU define os conceitos básicos para o acesso e manipulação dos dados; entretanto, um escravo pode tratar os dados de uma maneira não definida explicitamente na especificação.
Acesso aos dados no Modbus e o modelo de dados do Modbus
Os dados que podem ser acessados pelo Modbus são armazenados, de forma geral, em um dos quatro bancos de dados, ou faixas de endereço: coils, entradas discretas, registradores holding e registradores de entrada. Como ocorre com muitas partes da especificação, esses nomes podem variar, dependendo da indústria ou aplicação. Por exemplo, os registradores holding podem ser denominados registradores de saída, e os coils podem ser referidos como saídas digitais ou discretas. Esses bancos de dados definem o tipo e os direitos de acesso dos dados contidos. Os dispositivos escravo têm acesso direto a esses dados, que são hospedados localmente nos dispositivos. Os dados que podem ser acessados pelo Modbus são de forma geral um subconjunto da memória principal do dispositivo. Por outro lado, os mestres Modbus precisam solicitar acesso a esses dados, utilizando diversos códigos de função. O comportamento de cada bloco é descrito no quadro 1.
	Bloco de memória
	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 não sinalizada
	Leitura/escrita
	Leitura/escrita
	Registradores de entrada
	Palavra não sinalizada
	Somente leitura
	Leitura/escrita
 
Quadro 1. Blocos do modelo de dados do Modbus
Esses blocos dão a você a capacidade de restringir ou permitir acesso a diferentes elementos de dados e também fornecer mecanismos simplificados na camada de aplicação para o acesso a diferentes tipos de dados.
Os blocos são totalmente conceituais. Eles podem existir como endereços de memória distintos em um dado sistema, mas também podem se sobrepor entre si. Por exemplo, o coil 1 pode existir na mesma posição de memória que o primeiro bit da palavra representada pelo registrador holding 1. O esquema de endereçamento é totalmente definido pelo dispositivo escravo, e a interpretação de cada bloco de memória é uma parte importante do modelo de dados do dispositivo.
Endereçamento do modelo de dados
A especificação define que cada bloco contém um espaço de endereçamento de até 65.536 (216) elementos. Com a definição da PDU, o Modbus define o endereço 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 máximo de 65.536. Assim, o coil 1 está no endereço 0 do bloco de coils, enquanto que o registrador holding 54 está no endereço 53 da seção de memória reservada pelo escravo para os registradores holding.
Não é obrigatório implementar as faixas completas permitidas pela especificação no dispositivo. Por exemplo, pode ser escolhido para um dado dispositivo não 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 aceitável; nesse caso, tentativas de acesso inválidas seriam tratadas por exceções.
Faixas de endereçamento de dados
Embora a especificação defina que diferentes tipos de dados devem existir em blocos diferentes e atribua uma faixa de endereços local para cada tipo, isso não implica que haverá necessariamente um esquema de endereçamento intuitivo ou facilmente compreensível para a documentação da memória que pode ser acessada pelo Modbus para um determinado dispositivo. Para simplificar a discussão sobre as posições dos blocos de memória, foi introduzido um esquema de numeração que inclui prefixos ao endereço dos dados em questão.
Por exemplo, em vez de se referir a um item como registrador holding 14 no endereço 13, o manual do dispositivo pode se referir a um item de dados no endereço 4.014, 40.014 ou 400.014. Em todos esses casos, o primeiro número especificado é 4, que representa os registradores holding; os demais números especificam um endereço. A diferença entre 4XXX, 4XXXX e 4XXXXX depende do espaço de endereços utilizado pelo dispositivo. Se todos os 65.536 registradores estiverem em uso, utilizaremos a notação 4XXXXX, pois ela permite o uso da faixa de 400.001 a 465.536. Se apenas alguns registradores forem usados, uma prática comum é usar a faixa de 4.001 a 4.999.
Nesse esquema de endereçamento, cada tipo de dados recebe um prefixo, como mostrado no quadro 2.
 
	Bloco de dados
	Prefixo
	Coils
	0
	Entradas discretas
	1
	Registradores de entrada
	3
	Registradores holding
	4
Quadro 2. Prefixos das faixas de dados
Coils utilizam o prefixo 0. Isso significa que a referência 4001 pode se referir ao registrador holding 1 ou ao coil 4001. Por esse motivo, é recomendado que todas as implementações novas utilizem o endereçamento de 6 dígitos com zeros na frente. Essa informação deverá ser anotada na documentação. Dessa forma, o registrador holding 1 é referenciado como 400.001 e o coil 4001 é referenciado como 004.001.
Valores iniciais dos endereços de dados
A diferença entre endereços de memória e números de referência inclui uma complicação adicional, representada pela indexação selecionada por uma determinada aplicação. Como mencionado anteriormente, o registrador holding 1 está localizado no endereço 0. Tipicamente, os números de referência são indexados em 1; nesse caso, o valor inicial de uma faixa será 1. Dessa forma, a tradução literal de 400.001 é registrador holding 00001, que está no endereço 0. Algumas implementações escolhem iniciar suas faixas em zero; dessa forma, 400.000 indica registrador holding no endereço zero. O quadro 3 demonstra esse conceito.
	Endereço
	Número do registrador
	Número (indexação em 1, padrão)
	Número (indexação em 0, alternativa)
	0
	1
	400001
	400000
	1
	2
	400002
	400001
	2
	3
	400003
	400002
Quadro 3.Esquemas de indexação dos registradores
 
Faixas indexadas em 1 são muito usadas e altamente recomendadas. De qualquer forma, o valor inicial de cada faixa sempre deverá ser indicado na documentação.
Tipos de dados para grandes valores
O padrão Modbus oferece um modelo de dados relativamente simples, que não inclui outros tipos de dados além do valor do bit e palavra não sinalizada. Esses valores podem ser suficientes para alguns sistemas, nos quais os valores de bit correspondem a solenóides e relés e os valores das palavras correspondem a valores ADC sem escala, mas não para sistemas avançados. Como resultado, muitas implementações do Modbus incluem tipos de dados que vão além das fronteiras do registrador. O módulo LabVIEW Datalogging and Supervisory Control (DSC) e o KEPServerEX definem alguns tipos de referência. Por exemplo, as strings armazenadas em um registrador holding seguem o formato padrão (400.001), mas são 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 nível alto corresponde ao primeiro caractere da string). Isso é necessário porque cada requisição tem tamanho finito; dessa forma, o mestre Modbus precisa saber exatamente onde a string começa e termina, em vez de procurar por um comprimento fixo ou delimitador, como o NULL.
Acesso a bit
Além de permitir acesso a dados que vão além das fronteira do registrador, alguns mestres Modbus permitem o uso de referências a bits individuais dentro de um registrador. Com isso, os dispositivos podem combinar dados de todos os tipos em uma mesma faixa de memória sem ter de separar dados binários no coil e faixas de entrada discretas. Normalmente, esse recurso é indicado pelo uso de um ponto decimal e o índice de bit ou número, dependendo da implementação. Ou seja, o primeiro bit do primeiro registrador pode ser 400.001.00 ou 400.001.01. É recomendado que toda documentação especifique o esquema de indexação utilizado.
Configuração endian dos dados
Os dados de múltiplos registros, como valores de ponto flutuante de precisão única, podem ser facilmente transferidos ao Modbus, com a separação dos dados em dois registradores. Como isso não é definido pelo padrão, a ordem de bit (endian) utilizada nessa separação também não está definida. Cada palavra não sinalizada deve ser enviada na ordem de bit usada pela rede (big endian) para satisfazer o padrão, mas muitos dispositivos invertem a ordem de bytes no caso de dados formados por vários bytes. A figura 2 mostra um exemplo incomum, mas válido, dessa implantação.
Figura 2. Inversão da ordem de bytes em dados formados por várias palavras
É de responsabilidade do mestre entender como o escravo está armazenando informações na memória e decodificá-las adequadamente. É recomendável que a documentação informe a ordem da palavra usada pelo sistema. A ordem endian pode também ser entendida como uma opção de configuração do sistema, com funções de codificação e decodificação, se for necessário ter flexibilidade na implementação.
Strings
Strings podem ser armazenadas facilmente em registradores Modbus. Por simplicidade, algumas implementações requerem que os comprimentos de string sejam múltiplos de 2 e que qualquer espaço adicional seja preenchido por valores nulos. A ordem dos bytes também é uma variável nas interações das strings. O formato das strings pode ou não incluir um NULL como valor final. Como exemplo dessa variabilidade, alguns dispositivos podem armazenar dados como mostrado na figura 3.
Figura 3. Inversão da ordem dos bytes em strings do Modbus
Códigos de função
Ao contrário do modelo de dados, que pode variar significativamente de um dispositivo a outro, os códigos de função e seus dados são definidos explicitamente pela norma. Cada função segue um padrão. Em primeiro lugar, o escravo valida entradas como, por exemplo, código de função, endereço dos dados e faixa de dados. Em seguida, ele executa a ação requisitada e envia a resposta apropriada ao código. Se qualquer etapa desse processo falhar, uma exceção será enviada de volta ao requisitante. O transporte de dados dessas solicitações é a PDU.
A PDU do Modbus
A PDU é formada por um código de função de 1 byte seguido por até 252 bytes de dados de função.
Figura 4. A PDU do Modbus
O código de função é o primeiro item a ser validado. Se o código de função não for reconhecido pelo dispositivo que recebe a requisição, ele responderá com uma exceção. Se o código de função for aceito, o dispositivo escravo começará a decompor os dados conforme a definição da função.
Como o tamanho do pacote é limitado a 254 bytes, os dispositivos são limitados com relação à quantidade de dados que pode ser transferida. Os códigos de função mais comuns podem transferir entre 240 e 250 bytes de dados do modelo de dados do escravo, dependendo do código.
Execução da função pelo escravo
Conforme definido pelo modelo de dados, diferentes funções são definidas para acessar diferentes blocos conceituais de dados. Uma implementação muito usada faz os códigos acessarem posições estáticas de memória, mas outros comportamentos podem ser usados. Por exemplo, código de função 1 (ler coils) e 3 (ler registradores holding) podem acessar a mesma posição física na memória. Por outro lado, o código de função 3 (ler registradores holding) e 16 (escrever em registradores holding) podem acessar posições de memória completamente diferentes. Dessa forma, a execução de cada código de função é melhor considerada como parte da definição do modelo de dados do escravo.
Independentemente do comportamento executado, todos os dispositivos escravo devem seguir um diagrama de estados simples para cada requisição. A figura 5 mostra um exemplo baseado no código 1, ler coils.
Figura 5. Diagrama de estado de leitura de coils conforme a especificação do protocolo Modbus
Cada escravo precisará validar o código de função, quantidade de entradas, endereço inicial, faixa total e a execução da função pelo escravo que fará a leitura.
Embora sejam mostradas faixas de endereços estáticos no diagrama de estados acima, as necessidades dos sistemas do mundo real podem causar alguma variação com relação aos números definidos. Em alguns casos, os dispositivos escravo não conseguem transferir a quantidade máxima de bytes definida pelo protocolo. Isso significa não 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 aceitáveis como os endereços de 0 a 500. Se um mestre fizer uma requisição de 125 endereços a partir do endereço 0, isso estará OK, mas se fizer a mesma requisição a partir do endereço 400, o coil final estaria no endereço 525, que está fora da faixa para esse dispositivo, o que resultaria na exceção 02, conforme definido pelo diagrama de estados.
Códigos de função padrão
A definição de cada código de função padrão é fornecida na especificação. Mesmo para os códigos de função mais comumente usados, é inevitável haver algum descasamento entre as funções habilitadas no mestre e aquelas que podem ser tratadas pelo escravo. Para lidar com isso, as versões mais recentes da especificação TCP do Modbus definiu três classes de conformidade. O documento oficial Modbus Conformance Test Specification não faz referência a essas classes; em vez disso, define conformidade para cada função. Entretanto, elas ainda podem facilitar a compreensão. É recomendado que qualquer documentação siga a especificação do teste e defina sua conformidade pelos códigos que pode utilizar, e não pelas classificações usadas anteriormente.
Códigos da classe 0
Os códigos da classe 0 são considerados em geral o mínimo para um dispositivo Modbus utilizável, pois dão a um mestre a capacidade de ler ou escrever no modelo de dados.
	Código
	Descrição
	3
	Read Multiple Registers
	16
	Write Multiple Registers
Quadro 4. Códigos em conformidade com a classe 0
Códigos da classe 1
Os códigos de função da classe 1 compreendemoutros códigos necessários para acessar todos os tipos do modelo de dados. Na definição original, essa lista incluía o código de função 7 (ler exceção). Entretanto, esse código é definido pela especificação atual como código somente serial.
	Código
	Descrição
	1
	Read Coils
	2
	Read Discrete Inputs
	4
	Read Input Registers
	5
	Write Single Coil
	6
	Write Single Register
	7
	Read Exception Status (somente serial)
Quadro 5. Códigos em conformidade com a classe 1
Códigos da classe 2
Os códigos de função da classe 2 são funções mais especializadas, implementadas com menor frequência. Por exemplo, Read/Write Multiple Registers pode ajudar a reduzir a quantidade total de ciclos de requisição-resposta, mas o comportamento ainda pode ser implementado com códigos de classe 0.
	 Código
	Descrição
	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. Códigos em conformidade com a classe 2
 
Interface encapsulada do Modbus
O código de interface encapsulada do Modbus (MEI), função 43, é usado para encapsular outros dados dentro de um pacote Modbus. Até o momento, há dois números de MEI disponíveis, 13 (CANopen) e 14 (Device Identification).
A função 43/14 (Device Identification) é útil por permitir a transferência de até 256 objetos exclusivos. Alguns desses objetos são pré-definidos e reservados, como nome do fornecedor e código do produto, mas aplicações podem definir outros objetos a serem transferidos como conjuntos de dados genéricos.
Esse código não é implementado comumente.
Exceções
Os escravos usam exceções para indicar diversas condições problemáticas, de requisições mal formadas a entradas incorretas. Entretanto, as exceções podem também ser geradas como resposta no nível da aplicação a uma requisição inválida. Os escravos não respondem a requisições emitidas com uma exceção. Nesses casos, o escravo ignora uma requisição incompleta ou corrompida e começa a esperar pela chegada de uma nova mensagem.
Exceções são relatadas em um formato de pacote definido. Em primeiro lugar, um código de função é enviado de volta ao mestre solicitante igual ao código de função original com exceção de seu conjunto de bits mais significativo. Isso equivale a incluir 0x80 ao valor do código de função original. Em vez dos dados normais associados à resposta a uma determinada função, as respostas à exceção incluem um único código de exceção.
No padrão, os quatro códigos de exceção mais comuns são 01, 02, 03 e 04. Esses códigos são mostrados no quadro 7, com os significados padrão para cada função.
	Código de exceção
	Significado
	01
	O código de função recebido não é suportado. Para confirmar o código de função original, subtraia 0x80 do valor retornado.
	02
	A requisição tentou acessar um endereço inválido. No padrão, isso pode acontecer somente se o endereço inicial e a quantidade de valores requisitada ultrapassar 216. Entretanto, alguns dispositivos podem limitar ainda mais esse espaço de endereços em seus modelos de dados.
	03
	A requisição tem dados incorretos. Em alguns casos, isso significa que houve algum descasamento entre parâmetros, por exemplo, entre o número 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 número de registradores.
	04
	Ocorreu um erro não recuperável durante uma tentativa de processar a requisição. Esse é um código de exceção geral, que indica que a requisição era válida, mas o escravo não conseguiu executá-la.
Quadro 7. Códigos comuns de exceção do Modbus
 
O diagrama de estado para cada código de função deve cobrir pelo menos o código de exceção 01 e normalmente incluir os códigos 04, 02 e 03; quaisquer outros códigos de exceção definidos são opcionais.
Voltar ao topo
Unidade de dados de aplicação
Além das funções definidas no núcleo da PDU do protocolo Modbus, você pode usar diversos protocolos de rede. Os protocolos mais usados são TCP/IP e serial, mas você também pode usar outros, como o UDP. Para transmitir os dados necessários 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 comunicação confiável. O Unit ID ou Address é usado em todos os formatos de ADU para fornecer informações de roteamento à camada de aplicação. Cada ADU é fornecida com uma PDU completa, incluindo o código de função e os dados associados a uma determinada requisição. Para aumentar a confiabilidade, todas as mensagens contêm informações de verificação de erro. Além disso, todas as ADUs possuem um mecanismo que determina o início e o fim do quadro da requisição, mas os implementa de formas diferentes.
Formatos padrão
Os três formatos padrão para as ADUs são TCP, RTU (unidade de terminal remoto) e ASCII. As ADUs dos tipos RTU e ASCII são 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 são formadas pelo cabeçalho do Modbus Application Protocol (MBAP) concatenado com a PDU do Modbus. O MBAP é um cabeçalho de uso geral, que depende de uma camada de rede confiável. O formato dessa ADU, incluindo o header, é mostrado na figura 6.
Figura 6. A ADU do tipo TCP/IP
Os campos de dados do cabeçalho indicam seu uso. Em primeiro lugar, ele contém um identificador de transações. Esse é um recurso valioso em uma rede que pode ter várias requisições em processamento simultaneamente. Com isso, por exemplo, um mestre pode enviar requisições 1, 2 e 3. Em algum ponto posteriormente, um escravo pode responder na ordem 2, 1, 3. Nesse caso, o mestre pode combinar as requisições 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 posição desse elemento também indica a dependência desse formato do cabeçalho em uma camada de rede confiável. Como os pacotes TCP possuem verificação de erro incorporada e garantem a coerência e entrega dos dados, o comprimento do pacote pode estar localizado em qualquer parte do cabeçalho. Em uma rede inerentemente menos confiável, como uma rede serial, um pacote pode ser perdido. Nesse caso, mesmo que um feixe de dados lido pela aplicação incluísse informações válidas de transação e protocolo, a informação corrompida de comprimento tornaria o cabeçalho inválido. O TCP oferece um razoável grau de proteção contra essa situação.
O campo Unit ID normalmente não é utilizado para dispositivos TCP/IP. Entretanto, o Modbus é um protocolo tão utilizado que muitos gateways diferentes foram desenvolvidos, o que converte o protocolo Modbus em outro protocolo. Em sua destinação original, o gateway Modbus de TCP/IP para serial poderia ser usado para permitir a conexão entre novas redes TCP/IP e redes seriais mais antigas. Em um ambiente como esse, a Unit ID é usada para determinar o endereço do dispositivo escravo para o qual a PDU é realmente destinada.
Para finalizar, a ADU contém uma PDU. O comprimento dessa PDU é ainda limitado a 253 bytes no protocolo padrão.
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 contém apenas duas partes de informação além da PDU base. Em primeiro lugar, um endereço é usado para definir a qual escravo a PDU é destinada. Na maior parte das redes, o endereço 0 é o endereço de "difusão". Isso significa que se um mestre enviar um comando ao endereço 0, todos os escravos deverão processar a requisição, mas nenhum deles deverá responder. Além desseendereço, um CRC é usado para garantir a integridade dos dados.
Entretanto, nas implementações mais modernas a realidade está muito longe de ser simples. O pacote é delimitado por um par de intervalos de silêncio — ou seja, períodos nos quais não há comunicação no barramento. Para a taxa de bauds de 9.600, esse intervalo é de aproximadamente 4 ms. O padrão define um intervalo de silêncio mínimo, 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 término desse tempo de guarda antes de processar o pacote. Um problema maior, entretanto, foi o surgimento de outras tecnologias utilizadas em transferências seriais e taxas de baud muito maiores do que as existentes quando o padrão foi lançado. Ao utilizar um cabo de conversão USB-serial, por exemplo, você não tem controle sobre o empacotamento e transferência dos dados. Testes mostram que usar um cabo USB-serial com o driver NI-VISA introduz grandes lacunas de tamanho variável no feixe de dados, e essas lacunas — períodos de silêncio — confundem o código que segue a especificação, fazendo-o acreditar que a mensagem foi concluída. Como a mensagem não está completa, isso normalmente leva a um CRC inválido e à interpretação pelo dispositivo de que a ADU foi corrompida.
Além dos problemas com a transmissão, as modernas tecnologias de drivers abstraem significativamente a comunicação serial e tipicamente requerem um mecanismo de polling do código de aplicação. Por exemplo, nem o .NET Framework 4.5 SerialPort Class nem o NI-VISA fornecem um mecanismo para detectar silêncio em uma linha serial além do polling em bytes na porta. Isso resulta em uma escolha de baixo desempenho (se o polling for realizado lentamente demais) ou alta utilização da CPU (se o polling for executado rapidamente demais).
Um método muito usado para tratar desses problemas é separar a camada de abstração entre a PDU do Modbus e a camada de rede. Com isso, o código serial interroga o pacote da PDU do Modbus para determinar o código de função. 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 informação, é possível usar um tempo de timeout muito maior, permitindo lacunas na transmissão, e o polling da aplicação pode ocorrer muito mais lentamente. Esse mecanismo é recomendado para novos desenvolvimentos. Caso o seu código não 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 também evita muitos dos problemas do pacote de RTU. Entretanto, ela tem suas próprias desvantagens.
Figura 8. ADU do ASCII
Para resolver o problema da determinação do tamanho do pacote, a ADU do ASCII tem início 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). Além disso, APIs seriais como NI-VISA e o .NET Framework SerialPort Class podem facilmente ler dados em um buffer até que um caractere específico — como CR/LR — seja recebido. Essas características tornam mais fácil processar a transmissão de dados na linha serial de maneira eficiente nos modernos códigos das aplicações.
A desvantagem da ADU de ASCII é que todos os dados são transferidos como caracteres hexadecimais codificados em ASCII. Isso significa que em vez de enviar um único byte para o código de função 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 também significa ser necessário transferir o dobro dos dados pela rede serial, além disso, as aplicações de envio e recepção devem ser capazes de interpretar os valores ASCII.
Exemplo de mestre redundante
Esse exemplo básico pode ser suficiente para algumas aplicações, mas pode não ser suficiente para aplicações mais complexas, nas quais a meta é conversar com um sensor ou gateway. Para ajudar a preencher essa lacuna, um exemplo de aplicação mostra como usar dois mestres para a comunicação com um determinado escravo. Se um dos mestres falhar e perder conexão com o escravo ou com a interface homem-máquina (IHM), o outro mestre assumirá o comando.
Figura 9. Projeto do exemplo com mestre redundante
Extensão do Modbus
O Modbus é um padrão relativamente simples e aberto, que pode ser modificado conforme as necessidades de uma determinada aplicação. Esse é o protocolo mais usado na comunicação entre uma IHM e CLP ou CPA, pois essa é uma situação na qual uma única organização controla as duas pontas do protocolo. Os desenvolvedores de sensores, por exemplo, têm maior probabilidade de aderir ao padrão escrito, porque eles tipicamente somente controlam a implementação de seus escravos, e a interoperabilidade é desejável.
De forma geral, não é recomendável modificar o protocolo. Esta seção é simplesmente fornecida como um reconhecimento dos mecanismos que outros já usaram para ajustar o comportamento do protocolo.
Voltar ao topo
Novos códigos de função
Alguns códigos de função estão definidos, mas o padrão Modbus permite que você desenvolva outros códigos de função. Especificamente os códigos de função de 1 a 64, 73 a 99 e de 111 a 127 são códigos públicos, reservados e com exclusividade garantida. Os códigos restantes, de 65 a 72 e 100 a 110 são para uso definido pelo usuário. Com esses códigos definidos pelo usuário, 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 aplicação deve ser validada para garantir que as outras camadas trabalharão como esperado quando a PDU ultrapassar o limite padrão. Os códigos de função acima de 127 são reservados para respostas a exceções.
Voltar ao topo
Camadas de rede
O Modbus pode ser executado em muitas camadas de rede além de serial e TCP. Uma implementação potencial é o UDP, por ser adequado ao estilo de comunicação do Modbus. O Modbus é basicamente um protocolo baseado em mensagem; assim, a capacidade da UDP de enviar um pacote bem definido de informação sem qualquer informação adicional no nível da aplicação, como um caractere inicial ou comprimento, torna a implementação 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 aplicação. Entretanto, usar o UDP dessa maneira elimina o campo de identificador de transação da ADU do TCP, o que impede a possibilidade de haver diversas transações simultâneas. Assim, o mestre deve ser síncrono ou o pacote do UDP deve ter um identificador que ajude o mestre a organizar requisições e respostas. Uma sugestão de implementação seria usar a ADU do TCP/IP em uma camada de rede do UDP.
Voltar ao topo
Modificações da ADU
Para finalizar, uma aplicação pode escolher modificar uma ADU ou usar partes não 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 são sempre zero. Uma extensão simples do protocolo poderia enviar três pacotes simultaneamente alterando o campo de protocolo para um número diferente de zero e usando os dois bytes não utilizados (Unit ID e maior byte do campo de comprimento) para o envio dos comprimentos das duas PDUs adicionais (veja a figura 9).
Figura 10. Exemplo de modificação da ADU do TCP
que é o protocolo Modbus?
O protocolo Modbus pode ser definido como uma forma de estabelecer uma comunicação mestre-escravo entre dispositivos inteligentes.
Seu desenvolvimento foi feito pela Modicomem 1979 e desde então, foi amplamente aplicado. A sua aplicação vai além das industriais, sendo utilizado em algumas soluções prediais, além de internet das coisas.
É importante ressaltar que o protocolo Modbus é independente. Com isso, é possível ter numa rede, dispositivos de diferentes fornecedores comunicando-se entre si.
Neste artigo, veremos diversas variações do protocolo encontradas no mercado como, Modbus TCP/IP, Modbus RTU e ASCII. Focaremos no funcionamento e na diferença entre cada uma das possibilidades.
Onde utilizar o protocolo Modbus?
Vamos imaginar um cenário para lhe ajudar a entender melhor! 
Você precisa fazer a comunicação entre um dispositivo de campo, carinhosamente conhecido como escravo. Este dispositivo será responsável por enviar informações para um controlador, ou mestre, responsável pela análise e ação de comando.
Neste cenário, o protocolo Modbus seria uma das opções possíveis para conectar o mestre com escravo e os dois se entenderem. Seria essa a melhora opção? Pode ser que sim, ou pode ser que não.
Para afirmarmos isso, precisamos de um cenário muito bem construído e dessa forma, analisar a viabilidade de cada protocolo de comunicação.
O protocolo Modbus tem uma atuação muito maior do que apenas a de um protocolo industrial. Por conta da sua configuração simplicada e o seu uso simples, a sua viabilidade torna o Modbus uma solução flexível e viável para diferentes cenários.
Quando temos uma comunicação, ponto-a-ponto. Podemos utilizar o Modbus RS232. Agora, caso tenha diversos escravos na rede de comunicação, o Modbus RS 485 ou Modbus TCP/IP são mais adequados.
Como funciona o protocolo Modbus?
Primeiramente, vamos falar do protocolo Modbus no geral e depois entrar em suas variações, explicação seu funcionamento e as diferenças entre eles. Sua utilização é feita para comunicar devices com controladores para coleta de dados e comandos, certo?
Um exemplo muito bom seria a aplicação em medidores fiscais. Um dos protocolos aceitos em aplicações fiscais é o protocolo modbus e eu tive a oportunidade de fazer start-up de alguns medidores ultrassônicos de vazão em flares.
Estes medidores, em sua grande parte utilizam o protocolo modbus para enviar os dados de processo.
Você também pode usar o Modbus com um computador para configurar ou coletar dados de um dispositivo de campo. Você pode ter comunicação serial com o Modbus RTU e ASCII ou usando um cabo Ethernet para utilizar o Modbus TCP/IP.
Ok, agora é hora de entrar nos detalhes do protocolo.
Seu endereço de Email: 
Preencha com seu email
Modbus RS232
O protocolo Modbus usando RS-232, tem uma distância máxima entre o mestre e o escravo de 15 metros. Além disso, essa aplicação permite apenas um mestre e um escravo, conhecido como uma conexão ponto-a-ponto.
Modbus RS422 e Modbus RS485
Agora, os protocolos Modbus RS422 ou Modbus RS485, oferecem maior flexibilidade. Neste cenário, você tem um único mestre na rede, mas é possível ter diversos escravos.
A rede tem uma estrutura de cabos como Tx + / Tx- para realizar a transmição do sinal e o Rx + / Rx – mais um terra para receber a informação transmitida anteriormente.
Será muito mais comum você encontrar o protocolo Modbus RS485 do que o protocolo Modbus RS422, já que o RS485 permite até 32 escravos na rede sem utilizar repetidor. No entanto, você pode aplicar até 247 escravos caso coloque repetidores na rede, mantendo o comprimento máximo de 1200 metros.
Configuração do Modbus RS485
Quando é feita a adição de um novo dispositivo a uma rede, é necessário ter todos os dispositivos da rede na mesma taxa de transmissão ou bit, pois, o protocolo Modbus é um protocolo assíncrono.
Normalmente, você pode obter uma velocidade de transmissão (Baud rate or bit rate) entre 9600 e 19200, mas pode configurar para ter velocidades mais rápidas de 300 ate 100.000.
Como é feita a troca de mensagem no protocolo Modbus?
Primeiramente, o protocolo faz o envio de uma condição inicial do mestre para os escravos. Esta mensagem enviada possui 28 bits ou 3,5 caracteres. Então, o mestre envia o endereço que os escravos recebem como um código funcional de 8 bits.
Protocolo modbus_Modbus.org
Imagem em cortesia da organização Morbus.org
Esta lista mostra os códigos funcionais mais comuns:
Essas informações serão encontradas em inglês, por isso vou manter as informações em inglês também para que você possa se familiarizar com o que vê ou verá no dia a dia, ok?
1 – Read coil status
2 – Read input status
3 – Read holding registers
4 – Read input registers
5 – Write single-coil status
6 – Write single register
15- Write multiple-coil status
16 – Write multiple registers
Após o envio dos códigos de função, o mestre enviará os dados para os escravos. Essa mensagem também é em código de 8 bits. É importante ressaltar que, a quantidade enviada dependerá do tipo de escravo, mas você pode obter os detalhes no manual.
Em seguida, o mestre envia uma verificação de erro em 16 bits e, finalmente, uma condição de parada em 28 bits. Por outro lado, nós temos os escravos respondendo às perguntas do mestre com ecos, ou se mantendo em silêncio quando nada é requerido.
Modbus e os tipos de dados e endereçamento
É hora de falar um pouco sobre os de códigos de função e como eles se aplicam ao protocolo Modbus.
Protocolo Modbus
Com uma Coils, você pode ler e escrever uma mensagem de 1 bit em um endereço de 00001 a 09999. Utilizando discrete input você tem a função apenas de leitura, e essa mensagem também tem o tamanho de 1 bit e o seu endereço vai de 10001 a 19999.
Agora, com um Input register, você também terá o acesso apenas de leitura, mas sua mensagem será de 16 bits e o endereço vai de 30001 a 39999. Utilizando o Holding register, você possui o acesso de leitura e escrita com uma mensagem de 16 bits e um endereço indo de 40001 ate 49999.
Talvez vocês estejam se perguntando: “Como faço para ter uma mesagem de 32 bits?”
Boa pergunta!
Para ter um mesangem de 32 bits, você precisa de dois endereços de 16 bits para enviar junto. O mestre ou o escravo lerá as duas mensagens de 16 bits como uma unidade de 32 bits.
Seu endereço de Email: 
Preencha com seu email
Como funciona o Modbus RTU (Remote Terminal Unit)?
Caso o master da rede seja configurado com RTU, cada unidade conterá dois caracteres hexadecimais de 4 bits. A opção RTU oferece melhor rendimento de dados do que o ASCII devido à sua excelente densidade de caracteres.
Como funciona Modbus TCP/IP?
Em 1999, o Modbus TCP / IP surgiu para lidar com a nova realidade dos protocolos Ethernet em aplicações industriais. O TCP / IP usa a internet para transportar os dados dos dispositivos, e as instruções do protocolo Modbus vêm através do TCP/IP.
Este protocolo foi desenvolvido para a internet e oferece interoperabilidade entre os fornecedores. Como sabemos, cada vez mais os protocolos Ethernet estão crescendo no meio industrial e o Modbus TCP/IP ainda é um excelente solução.
Por exemplo, diversas aplicações de WirelessHART, como a comunicação da gateway da rede com o sistema de controle utilizando Modbus TCP/IP. Recentemente, outras adições foram feitas, como a opção do EtherNet/IP.
Como funciona o Modbus ASCII (American Standard Code for information Interchange)?
Você pode configurar os mestres para se comunicar com ASCII ou RTU. Em ASCII, cada unidade de 8 bits transmite como dois caracteres ASCII. O ASCII pode ter até um segundo entre os caracteres sem criar um erro na comunicação.
O que é CRC no protocolo Modbus?
Quando falamos das mensagens (frame) trocadas na rede Modbus RTU, todas essas incluirão o CRC (Cyclic Redundancy Check) ou em português, uma verificação de redundância cíclica. O CRC são 2 bytes no final da mensagem do Modbus RTU.
O mestre e o escravos utilizam estes dois bytes para fazer a verificação da integridade todas as mensagens que são recebidas por ambos. Mas como isso é calculado? Bom, o CRC é calculado levando em conta o restante da mensagem.
O que acontece é que quando um dispositivo recebe uma nova mensagem,ele calculará o seu próprio CRC e então comparará com o valor do CRC da mensagem recebida.
O que é são códigos de função na rede Modbus?
Quando uma mensagem é enviada entre um mestre e o escravo, o código de função (function code) é o responsável em dizer para o escravo que tipo de ação ele deve fazer.
Se você estiver utilizando o Modbus ASCII, o function code será 2 caracteres na messagem enviada já em se estiver utilizando o Modbus RTU, o function code é representado por 8 bits.
O que é o mapa Modbus?
Um mapa Modbus define simplesmente os dados que você encontrará num escravo — que tipo (vazão,pressão, etc.), qual local (tabela e endereço) e qual formato (byte, ordem das palavras e assim por diante).
Você pode encontrar dispositivos no mercado com mapas predefinidos, mas para a maioria deles, é possível criar os seus próprios dispositivos para se comunicar com o mestre.
Quais as diferenças entre o protocolo Modbus RTU e Modbus TCP/IP?
Levantei algumas características de cada um dos protocolos e listarei abaixo:
O protocolo Modbs RTU:
Utiliza a comunicação serial
O disposivitos da rede podem ser daisy-chain na rede
Pode utilizar repetidor na rede
Comprimento máximo 1200 metros
32 escravos na rede sem utilizar repetidor e 247 com repetidor.
O protocolo Modbus TCP/IP
Rede Ethernet
Pode utilizar estrutura Ethernet existente
Mais rápido e fácil de fazer diagnósticos
Redução de custo com estrutura
Conversor da rede Modbus para outras redes
Uma solução bem comum e simples de aplicar são os conversores. No entanto, isso não quer dizer que conversores são a melhor maravilha do mundo. Conversores podem ser complicados de configurar e um ponto a mais de problema na rede.
No caso do Modbus, você encontrará diversos conversores para outras redes.
A grande maioria funciona de forma bem tranquila e transparente. Você pode encontrar conversores de Modbus TCP/IP para EtherNet/IP ou, por exemplo para Profibus.
Ferramentas essenciais para utilizar numa rede Modbus
Como fazemos para testar a comunicação Modbus de um determinado equipamento, antes de coloca-lo na rede? Bom, essa é uma solução bem simples e comum de ser utilizada por técnicos e engenheiros de fabricantes.
Uma delas é o ModScan32, onde você pode ler as informações dos seus equipamentos para ter a certeza que tudo foi configurado de forma adequada, antes de implementar ele na rede.
Caso queira simular um escravo ou mais de um, outra solução bem antiga, mas ainda funcional, é o ModSim32. Você pode testar um ponto na rede para ter certeza que o cabo está ok, e o mestre está recebendo as informações.
Além desses softwares, você pode precisar de uma interface serial para Modbus RTU or ASCII, para isso interfaces como… diversas que tem no mercado irão ajudar no dia a dia.
Conclusão
O Modbus é um protocolo comum, pois você pode usar de várias maneiras e situações para implementar aplicações importantes. Para o tipo comunicação por Modbus, a NI oferece três opções relativas, que oferecem uma extensamente variedade de funcionalidades para atender as utilidades de sua aplicação. o primeiro tipo, uma API de baixo nível oferece controle fino sobre o protocolo, com alto desempenho, com sacrifício da capacidade de uso. Tudo precisa ser feito manualmente quando utilizamos a API de baixo nível. O segundo tipo para aplicações mais simples de monitoramento, os servidores de E/S de Modbus oferecem uma API mais simples e de mais fácil uso para o acesso ou fornecimento de dados do Modbus. Em troca da facilidade de uso, os servidores de E/S proporcionam um melhor controle do protocolo, que pode ser necessário para algumas aplicações. e por fim, para sistemas complexos de grande porte, pode ser aproveitavael considerar o uso de um servidor OPC completo para operar como agregador de dados. Então somente será necessário utilizar uma ferramenta como o por exemplo driver LabVIEW OPC UA ou servidores de E/S OPC para fornecer acesso a esses dados e então à sua aplicação.