O mundo da automação – O protocolo Modbus

Estamos começando uma nova coluna com informações que são importantes para este atual mundo da automação, que já está “casado” com a rede de dados já há algum tempo, em especial, o protocolo IP.

Muito se houve falar na indústria 4.0, que a automação vai dominar o mundo, gerando desemprego e, sim, é bem verdade que isto deverá ocorrer num breve futuro.

Mas para que você tenha um lugar cativo neste atual mundo da automação, é importante começar a entender como a automação está acontecendo, tecnologias, protocolos, etc, que estaremos abordando de agora em diante nesta coluna. Entre outras tecnologias e protocolos, vamos abordar além do Modbus, o protocolos BACNET, CAN, LON, KNX, protocolos sem fio, protocolos para IoT… Vamos abordar sobre o LORA, SIGFOX, NBIoT, entre diversos outros, além do que está acontecendo no mundo na área de automação e cidades inteligentes e como a Internet liga tudo ao redor.

Penso que o ponto de partida para começarmos falar de automação, começa pelo entendimento do protocolo Modbus, que embora tenha sido criado na década de 70 (1979),  se mantem atual em função da sua simplicidade e robustez. Além do Modbus RTU, já existe o Modbus encapsulado no protocolo IP.

Vamos tentar tratar destes assuntos, da forma mais didática possível e, deixaremos sempre um link (www.mobus.org) para que se possa aprofundar em cada uma das tecnológicas que serão abordadas aqui. Mas, vamos ao que interessa e começarmos a falar de automação do inicio, ou seja, o protocolo Modbus. Para cada protocolo ou tecnologia, desenvolveremos de 2 a 3 artigos e assim por diante, para ficar uma leitura simples, didática e não muito grande.

O Modbus se situa na camada 7 da arquitetura OSI, de 7 camadas (aplicação). Passou a ser um padrão de fato, no ano de 1979 e, até hoje, a maioria dos equipamentos do mundo predial e fabril (geradores, controladores de motores, medidores de energia, etc) utilizam o protocolo Modbus, sendo que hoje temos milhões de dispositivos enviando e recendo informações por meio deste protocolo.

O Modbus pode ser encapsulado no protocolo TCP (da pilha TCP/IP) na porta 502. MODBUS é um protocolo de solicitação / resposta tipo Mestre e escravo, que oferece serviços especificados por códigos de função. Os códigos de função MODBUS são elementos das PDUs ( do protocolo) que enviam  solicitação / resposta MODBUS. A figura 1 apresenta a pilha de protocolo MOBUS que atualmente é implementado usando:

• TCP / IP sobre Ethernet.
• Transmissão serial assíncrona em uma variedade de mídias (fio: EIA / TIA -232-E, EIA-422,EIA / TIA-485-A; fibra, rádio, etc.)
• MODBUS PLUS

Figura 1 – A pilha de protocolo Modbus

A figura 2 apresenta a versatilidade da transferência de informações Modbus sobre diversas tecnologias que dá a ideia da versatilidade do protocolo, ou seja, dentro do mundo IP, serial RS 232 e 485.

Todos os tipos de dispositivos (PLC, IHM, Painel de Controle, Driver, Controle de Movimento, Dispositivo de I / O) podem usar Protocolo MODBUS para iniciar uma operação remota. A mesma comunicação pode ser feita também na linha serial como em redes Ethernet TCP / IP. Os gateways permitem uma comunicação entre vários tipos de barramentos ou redes usando o protocolo MODBUS.

Figura 2 – Exemplo de uma arquitetura de rede Modbus

O PROTOCOLO

O protocolo MODBUS, conforme figura 3, define uma unidade de dados de protocolo simples (PDU) independente das camadas de comunicação subjacentes. O mapeamento do protocolo MODBUS em barramentos específicos ou rede pode introduzir alguns campos adicionais na unidade de dados da aplicação (ADU).

Figura 3 – Formato do quadro Modbus

A unidade de dados da aplicação MODBUS é construída pelo cliente que inicia uma transação MODBUS. A função indica ao servidor que tipo de ação deve ser executado e o aplicativo MODBUS protocol estabelece o formato de um pedido iniciado por um cliente.

O campo de código de função de uma unidade de dados MODBUS é codificado em um byte. Códigos válidos estão no intervalo de 1 … 255 decimal (o intervalo 128 – 255 é reservado e usado para respostas). Quando uma mensagem é enviada de um Cliente para um dispositivo Servidor, o campo do código de função informa ao servidor que tipo de ação deve ser executada. O código de função “0” não é válido.

Códigos de subfunção são adicionados a alguns códigos de função para definir várias ações. O campo de dados de mensagens enviadas de um cliente para dispositivos do servidor contém informações adicionais que o servidor usa para executar a ação definida pelo código de função. Isso pode incluir itens como endereços discretos e de registro, a quantidade de itens a serem manipulados e a contagem de bytes de dados reais no campo.

O campo de dados pode ser inexistente (de comprimento zero) em certos tipos de pedidos, neste caso o servidor não requer nenhuma informação adicional. O código de função sozinho especifica a ação que deve ser feita.

O tamanho da PDU MODBUS é limitado pela restrição de tamanho herdada da primeira implementação MODBUS na rede Serial Line (máx. RS485 – ADU = 256 bytes).

Assim sendo:

PDU MODBUS para comunicação em linha serial = 256 – Endereço do servidor (1 byte) – CRC (2bytes) = 253 bytes.

Consequentemente:

ADU RS232 / RS485 = 253 bytes + Endereço do servidor (1 byte) + CRC (2 bytes) = 256 bytes.

TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.

O protocolo MODBUS define três PDUs. São eles:

• PDU de solicitação MODBUS, mb_req_pdu
• PDU de resposta MODBUS, mb_rsp_pdu
• PDU de Resposta de Exceção MODBUS, mb_excep_rsp_pdu

O MODBUS baseia seu modelo de dados em uma série de tabelas que possuem características diferenciadas.

O Modbus manipula 4 tipos de banco de dados que são:

Tabela 1 – Tabela primária

Todos os dados manipulados via MODBUS (bits, registradores) devem estar localizados no dispositivo, ou seja, na memória da aplicação. Mas endereço físico na memória não deve ser confundido com dados de referência.

Vamos encerrar esta primeira parte explicando melhor esta tabela primária:

Exemplo 1: Dispositivo com 4 blocos separados ( 4 bancos de dados)

O exemplo da figura 4 mostra a organização dos dados em um dispositivo exemplo com entradas e saídas digitais e analógicas.

Cada bloco é separado porque os de blocos diferentes não tem correlação, ou seja, as entradas e saídas analógicas e digitais são independentes. Desta forma, o bloco é assim acessível com diferentes funções MODBUS.

Figura 4 – Modelo de dados separado por blocos

Exemplo 2: Dispositivo com apenas 1 bloco

No exemplo da figura 5, o dispositivo tem apenas 1 bloco de dados. Os mesmos dados podem ser alcançados através de várias funções MODBUS, seja através de um acesso de 16 bits ou através de um bit de acesso.

Estes 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 de retenção 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.

Figura 5 – Modelo de dados com 1 bloco

Explicando melhor estes registradores

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 (que estamos chamando de retenção) e registradores de entrada. Esses nomes de registradores podem variar, dependendo do fabricante. Por exempo, o que estamos chamando de registradores holding (retenção) podem ser denominados de uma melhor forma, como registradores de saída, e os coils, para facilitar o entendimento, podem ser referidos como saídas digitais (1 bit). Os dispositivos escravos armazenam localmente estes dados nos dispositivos e podem ser acessados pelo protocolo de forma geral por meio de 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.

Nesse esquema de endereçamento, cada tipo de dados recebe um prefixo, como mostrado na tabela 2.

Tabela 2 –  Esquema do prefixo de endereçamento

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.

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 (retenção) 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.

Na próxima edição, vamos avançar mais no protocolo Modbus com exemplos de rede e sistemas de automação.

Bibliografia

www.modbus.org

https://www.ni.com/pt-br/innovations