A segurança dos dados em uma rede industrial é fundamental para o funcionamento correto de um sistema. Veja porque o protocolo MODBUS foi adotado nas automações industriais
Imagine a seguinte cena
Um CLP ou um computador controlando diversas etapas de um sistema automatizado, controlando sensores, motores, redutores, atuadores e outras máquinas que compõem o sistema de produção, tudo funcionando como uma orquestra, onde se um elemento da rede falhar todo o sistema pode ser comprometido. Em determinada etapa da produção um motor para por algum motivo ou funciona de forma errônea, o passo seguinte da linha de produção começa a sofrer com a irregularidade ou pela falta de curso do processo, o gasto ou prejuízo gerado até a parada de todo sistema pode ser enorme.
Agora imagine se o sistema parasse de funcionar logo após este mesmo motor parar de funcionar ou responder, ou ainda tomar uma rota alternativa para não parar a produção.
Mas, como controlar todos os processos/ equipamentos de um sistema automatizado com confiança e com velocidade suficiente para se tomar uma rápida atitude?
Agora vamos imaginar um segundo cenário
Um CLP ou um computador que gerencia todo um sistema automatizado, e que fica verificando se cada elemento está funcionando corretamente. Para saber se cada um está de acordo, o CLP ou computador - que chamamos de Master (Mestre) - envia um sinal para cada componente abrindo uma porta de comunicação, uma vez a porta aberta o Master pergunta para o equipamento - que chamamos de Slave (escravo) - como está o seu funcionamento, o escravo por sua vez responde o seu status fechando a porta de comunicação.
Depois disso o Master executa o mesmo procedimento para todos os outros elementos do sistema, e assim mantém o gerenciamento de tudo. Até aqui tudo bem, mas imagine se um dos elementos por alguma falha não abre um canal de comunicação e nem responde o seu status? O Mestre ficaria esperando uma resposta até quando? Até alguém notar que o sistema que deveria ter parado, não parou?
É por isso que o protocolo MODBUS foi criado, o Mestre ao invés de abrir um canal de comunicação com um determinado dispositivo ou elemento, joga na rede em que está conectado uma sequência de co- mandos (bits) onde contém além de outras informações, o número do dispositivo que ele está chamando. O elemento que está na rede com aquele número tem um tempo aproximado para responder que está ativo na rede, caso ele não responda ou demore a responder, ou se na sua resposta aparece um código de erro, o Mestre deverá executar a instrução programada nele para corrigir aquele problema.
Para entendermos melhor como é a aplicação do protocolo MODBUS, a figura 1 ilustra uma linha de produção com diversos dispositivos, cada um com o seu número (rótulo) na rede, sendo controlados pelo Mestre.
Como mencionado anteriormente, cada dispositivo deve ter um número, e visto que em cada frame de dados temos apenas 1 byte reservado para indicar qual dispositivo deverá ser chamado, temos um limite de 247 dispositivos presos a rede, ou seja, podemos chamar dispositivos que vão do 01 a 247, onde o 00 é reservado para broadcast.
O Frame do protocolo MODBUS
Como o tempo é primordial no tráfego de informações, o frame (pacote de bits enviados de um dispositivo a outro) deve ser enxuto o bastante para não comprometer o sistema. Na figura 2 temos como os bits são distribuídos dentro de um frame do protocolo MODBUS, tanto pelo Mestre como os dispositivos escravos.
O primeiro byte descreve o dispositivo, neste caso o dispositivo chamado é o 2A.
O segundo byte descreve o comando ou a função que será executada, neste exemplo 01 lê as saídas digitais (bobinas).
O terceiro byte (mais significativo) e o quarto byte (menos significativo) indicam os endereços de memória onde serão ou estão escritos os dados no escravo, neste exemplo no endereço de memória 05 e 02.
O quinto byte (mais significativo) e o sexto byte (menos significativo) mostram a quantidade a ser lida ou escrita pelo escravo e seus dados.
CRC (Cyclic Redundancy Check) são 2 words (palavras) ou 16 bits, utilizado para detectar erros na transmissão de dados.
Código de funções ou comandos
As funções são de leitura de informações de um escravo, a escrita de informações num dispositivo escravo, ou o broadcasting, que pode ser a leitura ou escrita em todos os dispositivos escravos da rede.
Conforme o tipo de dados, ele pode ser Bobinas de 8 bits (coils) que podem ser lidos ou escritos do escravo, Entrada de 8 bits (inputs) que somente podem ser lidos do escravo, Retentivos de 16 bits (holding) que podem ser lidos e escritos no escravo e, por fim, a Entrada de 16 bits (inputs) que somente podem ser lidos do escravo.
Na tabela 1 temos os principais comandos do protocolo MODBUS e suas representações em hexadecimais.
As funções inseridas no protocolo MODBUS de domínio público são únicas e bem definidas, validadas pela comunidade da organização MODBUS, possuindo testes de certificação e documentação em MB IETF RFC, além de ter áreas reservadas para expansões. Além das funções públicas, existem duas faixas de código onde o usuário poder definir novas funções, independentemente da área, sem ter que notificar ou pedir autorização da comunidade MODBUS, porém é importante verificar se as novas implementações não irão conflitar com as já existentes.
Caso o usuário deseje tornar a sua função uma “função pública” é necessário iniciar junto à comunidade MODBUSuma RFC para ver a sua aceitação.
Endereçamento lógico dos registros/dados
Nesta parte do frame encontramos nos dois bytes o local e o tipo de dados e operando, que cada tipo pode conter até 9999 operandos, pois cada um tem um registro que o descreve para diferenciá-lo. Para se ter uma idéia, o operando que especifica uma saída discreta (Coils) está entre 00001a 09999, o de entrada discreta (Inputs) vai de 10001 a 19999, o de Entradas analógicas (Input Registers) de 30001 a 39999 e o de Saídas analógicas (Holding Registers) de 40001 a 49999.
Lembrando que o endereço dos dados difere do endereço do operando, que está na faixa de 1 a 9998, um exemplo que podemos citar é lermos um dado 40001. Saberemos que é um Holding Register, mas as informações estão contidas no endereço 0, caso o dado recebido fosse 40002 seria o endereço 1 do Holding Register, e assim até 49999.
CRC (Cyclic Redundancy Check)
Os dois últimos caracteres do frame servem para certificar que os dados passados naquele pacote de informações estão corretos através de uma lógica de verificação. Caso os valores não sejam conforme o esperado, o pacote é dado como erro. Na hora da formação destes dois caracteres o processo é invertido, tornando o byte mais importante como o de menor importância e o de menor como de maior importância, antes de serem enviados ao escravo.
Formato de transmissão
São quatro os modos em que os dados são formatados antes da transmissão: o RTU (Remote Terminal Unit) é o mais utilizado pelo fato de compor o frame em binário, onde cada byte contém dois caracteres de 4 bits cada. Ele difere do formato ACSII (American Standard Code for Information Interchange), ocupando menos recurso de rede, pois um byte do formato ACSII é formado por 7 bits e pode ser entendido somente por ler a sequência.
Os outros dois formatos são o MODBUS/TCP onde os dados são encapsulados em pacote e enviados pela rede Ethernet via TCP , utilizando-se do CSMA/CD (Carrier Sense Multiple Access with Collision Detection) que gerencia as possíveis colisões que possam ocorrer, caso outros dispositivos estejam usando o mesmo canal, dando taxas de prioridade ao pacote enviado; e o MODBUS Plus, que é de prioridade da Schneider Electric, sendo que para utilizá-lo é necessário ter a licença de uso.
Na figura 3 temos o diagrama mostrando as diferença entre o pacote RTU e o pacote TCP que já utiliza o CRC32.
Temporização no MODBUS
De acordo com Pedro Urbano e Auzuir Ripardo, autores do livro “Redes Industriais” (ed. Ensino Profissional), o protocolo MODBUS define algumas regras de temporização a serem respeitadas. O tempo de linha inativa entre bytes de um mesmo pacote (requisição e resposta) não pode exceder 1,5 tempos de bytes. Por exemplo, numa taxa de 9600 bps, considerando dados de 11 bits (start bit, 8 bits de dados, paridade e stop bit) o tempo de byte é de aproximadamente 1,146 ms, ou seja 1,5 tempos de byte seria 1,72 ms.
Quando o mestre faz uma pergunta, o escravo pode demorar um pouco para responder. Existe um atraso típico e um atraso máximo aceitável para receber uma resposta do escravo. Este atraso máximo de resposta deve ser configurado no timeout do Mestre. Se a resposta não for recebida dentro deste timeout , o mestre assume que o pacote não vem mais e faz uma nova requisição.
Conclusão
Este artigo mostra como funciona o protocolo MODBUS. É importante para quem precisa realmente utilizar o protocolo, tanto para desenvolver como para reparar ou projetar sistema baseados nele, ler mais sobre as tabelas de operações públicas como as que já foram implementadas em outros locais, e também as soluções apresentadas por outros engenheiros de projetos. No quadro “Saiba Mais”, no início deste artigo, apresento algumas referências importantes para o melhor entendimento deste protocolo.
