ANÁLISE DA INTEROPERABILIDADE DO PROTOCOLO MODBUS EM DISPOSITIVOS DE FABRICANTES DIFERENTES

Andrade, T. R., Morais, J. S., Morais, A. S., Vincenzi, F. R. S.,

Faculdade de Engenharia Elétrica (FEELT) Universidade Federal de Uberlândia (UFU)

Av. João Naves de Ávila, 2160 - Bloco 3N - Campus Santa Mônica CEP: 38400-902 Uberlândia, MG, Brasil

e-mail: tulioresende@yahoo.com.br Resumo - A interoperabilidade entre dispositivos dar-se-á pela correta implementação do protocolo nos mesmos, porém quando esta comunicação não é concretizada devemos analisar onde está a incoerência. Neste artigo estudaremos o protocolo MODBUS apresentando técnicas, aplicativos e conceitos, com o intuito de identificar e possivelmente sanar o problema de comunicação com este protocolo. Analisaremos então dois dispositivos: um que está em acordo e outro em desacordo com a norma do protocolo. Utilizaremos um software de escuta de linha para fazer a análise do que é transmitido e numa primeira etapa do experimento, será feita a comunicação do equipamento com outro aplicativo. Já na segunda etapa a comunicação será feita utilizando equipamentos físicos. Palavras-chave - Redes Locais Industriais, Protocolos de Comunicação, Simuladores. ANALYSIS OF INTEROPERABILITY PROTOCOL MODBUS DEVICES IN DIFFE

RENTMANUFACTURERS

Abstract - Interoperability between devices will give the correct implementation of the protocol the same, but when this communication is not achieved we should examine where this inconsistency. In this article we study the MODBUS protocol presenting techniques, applications and concepts in order to identify and possibly remedy the communication problem with this protocol. Then analyze two devices: one that is in agreement and disagreement with others in the standard protocol. We use a software listener line to make the analysis of what is transmitted and a first stage of the experiment, it will communicate with another application of the equipment. In the second phase the communication will be done using physical equipment. Keywords - Industrial Local Area Networks, Communication Protocols, Simulators. ____________________________

I. INTRODUÇÃO

Atualmente existe uma grande variedade de dispositivos que utilizam de redes locais como forma de troca de dados. Para garantir a interoperabilidade entre os equipamentos, os protocolos são normalizados e regidos por organizações independentes. Porém devido à complexidade dos mesmos, certos artifícios são utilizados de um fabricante para outro para atender a norma do protocolo, o que leva às vezes à incompatibilidade entre os fabricantes. Isso se torna um problema que pode às vezes ser resolvido sem a necessidade da troca do equipamento.

Para resolver tal problema é necessário que se faça um estudo sobre o protocolo utilizado, neste artigo é feito para o protocolo MODBUS, para conhecer o padrão de dados que deveriam transitar na rede e comparar com os que realmente transitam por ela. Caso esteja realmente diferente, levar-se-á adiante essa pesquisa no intuito de encontrar o erro, sua causa e daí analisar a possibilidade de resolvê-la. Se não for o caso, ou seja, se a comunicação está realmente seguindo o padrão do protocolo, deve procurar o problema na estrutura física da rede.

II. O PROTOCOLO MODBUS

O MODBUS é um protocolo mestre-escravo que foi desenvolvido pela Modicon Industrial Automation Systems, a atual Schneider. Apesar de ser um dos protocolos mais antigos, é de grande utilização na área de automação industrial, devido a sua simplicidade e facilidade de operação.

Sua implementação pode ser feita de dois modos, em ASCII (American Standard Code for Information Interchange) ou RTU (Remote Terminal Unit), onde que em ambos os modos o conjunto de dados, ou framing, é composta pelos campos de início de framing, endereço de escravo, função MODBUS, dados para o escravo, checksum e fim de framing.

No modo ASCII, cada palavra é composta por dois caracteres no formato ASCII, e serão compostas por 10 bits, sendo 1 start bit, 7 data bits, e 2 stop bits. A composição do framing nesse modo é a seguinte, seu início é indicado pelo caractere dois pontos ‘:’, o endereço do dispositivo é transmitido do caractere mais significativo para o menos significativo, a função

MODBUS é identificada por dois caracteres, em seguida são enviados os dados necessários, depois o checksum que é feito pelo método LRC que também é enviado do caractere mais significativo para o menos significativo e encerrando com o fim de framing indicado pelos caracteres CR + LF.

TABELA I Framing em ASCII

Início de framing 3AH Endereço do dispositivo Char + Char -

Função Modbus 2 chars Dados para o dispositivo N chars

Checksum LRC + LRC - Fim de framing 0DH 0AH

No modo RTU, cada palavra é composta por um

caractere no padrão hexadecimal, e serão compostas por 11 bits, sendo 1 start bit, 8 data bits, e 2 stop bits. Na composição do framing temos que o início e o fim do framing são indicados por um período ocioso que deve ser no mínimo 3,5 vezes do tamanho da palavra de dados, um caractere indica o endereço do dispositivo, e outro indica a função MODBUS, seguido pelos dados necessários, e pelo checksum feito pelo método CRC que nesse caso é transmitido do caractere menos significativo para o mais significativo.

TABELA II Framing em RTU

Início de framing TInício Endereço do dispositivo 1 Char 1 Char

Função Modbus 1 chars Dados para o dispositivo N chars

Checksum CRC - CRC - Fim de framing TFim TFim

Assim então, são enviados os pedidos dos mestres

aos escravos, chamados de querys, que podem ser endereçados a apenas um escravo, ou a todos os escravos utilizando o endereço de broadcast. Após o envio o escravo retorna com uma mensagem semelhante, chamada response, que poderá incluir dados ou erros encontrados, se isso não acontecer em um determinado tempo, o mestre detecta erro na transmissão e reenvia o pedido. Não existe response no caso de comunicação em broadcast.

O endereçamento dos escravos é feito com a faixa de endereços 0 a 247, onde que o endereço número 0 é destinado ao broadcast. Nas querys o mestre insere o endereço do escravo, e nas responses o escravo insere novamente seu próprio endereço para que seja reconhecido pelo mestre.

Para a função MODBUS, tem-se uma faixa de valores de 1 a 255. Quando uma mensagem é recebida pelo escravo, este campo indica qual ação deve ser tomada, por exemplo, fazer leitura ou escrita de sensores ou registradores, etc. Na response em que a ação foi concluída com sucesso, é devolvido o mesmo valor neste campo, se houve algum erro, ou exception, o escravo devolve o código da função com o seu bit mais

significativo em nível 1. Abaixo é mostrado na TABELA III os principais códigos das funções.

TABELA III Funções Modbus

Código Função Modbus 02 Read Discrete Inputs 03 Read Holding Registers 04 Read Input Registers 06 Write Single Register 10 Write Multiple Registers 2B Read Device Identification O Campo de dados é formado por conjuntos de 2

dígitos hexadecimais, variando de 00H a FFH. As informações contidas neste campo estão relacionadas ao tipo de função definido no campo função MODBUS, como por exemplo, a quantidade de sensores ou dados a serem escritos ou lidos, os dados a serem programados em determinados registradores, e a quantidade de bytes que está sendo enviado na mensagem. Na response enviada pelo escravo, ela poderá apenas retornar as informações pedidas pelo mestre, ou no caso de erro conterá um código de exception, identificando o motivo que causou o erro e orientando o mestre na execução do próximo comando. Abaixo é mostrada a TABELA IV com os códigos de identificação de erro nesse campo.

TABELA IV Códigos de identificação de erro

Código Identificação 01 Função inválida 02 Sensor ou registrador inválido 03 Valor de dado inválido 04 Falha no dispositivo 05 Estado de espera 06 Dispositivo ocupado 07 Não reconhecimento 08 Erro de paridade na memória

III. SOFTWARES

Para o estudo da interoperabilidade de dispositivos operando em MODBUS, existem dois aplicativos desenvolvidos pela Win-TECH Software Design que serão descritos a seguir.

A. Modscan O Modscan é um aplicativo que simula um

dispositivo mestre operando em MODBUS, utilizando a interface serial RS-232. Sua interface permite que o usuário visualize toda a comunicação enviada pelos escravos, também sendo possível alteração nesses dados. Isso faz com que esse aplicativo seja uma ferramenta muito importante para verificar a compatibilidade de dispositivos escravos com o protocolo MODBUS e quais erros que são pertinentes para designar o local do problema.

Fig. 1. Interface do Modscan Sua interface permite a escolha da visualização em

notação binária, decimal ou hexadecimal, tanto quanto na escolha do modo de transmissão RTU ou ASCII.

Como se pode ver na Fig. 2, o Modscan tem quatro tipo de variáveis, duas dessas são discretas (Input Status e Input Register), e as outras duas são analógicas e são mostradas em notação binária (Coil Status e Holding Register). Cada uma dessas variáveis tem um intervalo dedicado na memória, estando esses começando com uma numeração diferente no endereço.

Fig. 2. Tipos de Variáveis A conexão dos simuladores pode ser feita em

MODBUS/TCP ou utilizando uma das nove portas como mostrado na Fig. 3. Essas portas podem ser configuradas de acordo com a rede e com o tipo de comunicação que será estabelecida (RTU ou ASCII).

Fig. 3. Interface para configuração de porta de comunicação Como visto na Fig. 4, sua interface permite

visualização em várias notações como binário, hexadecimal, etc.

Fig. 4. Notações para visualização dos resultados

B. Modsim Similarmente ao Modscan, o Modsim é um

aplicativo que opera em MODBUS, porém este é utilizado para a simulação de múltiplos dispositivos escravo enviando informações ao seu mestre. Tem como sua finalidade executar testes em novos dispositivos mestres adicionados na rede para conferencia da sua interoperabilidade. Sendo assim, são enviados dados pelo Modsim ao dispositivo mestre seguindo o patrão do protocolo MODBUS, então caso seja gerado algum erro no dispositivo mestre, esse deve ter sua configuração verificada.

Fig. 5. Interface do Modsim. A conexão dos simuladores pode ser feita em

Modbus/TCP ou utilizando uma das nove portas como mostrado na Fig. 6.

Fig. 6. Conexão do Modsim. Essas portas podem ser configuradas de acordo com

a rede e com o tipo de comunicação que será estabelecida (RTU ou ASCII).

Fig. 7. Interface para configuração de porta de comunicação. Sua interface permite visualização em várias

notações como binário, hexadecimal, etc.

Fig. 8. Notações para visualização dos resultados.

C. Serial Monitoring Studio Este é um software que permite capturar, visualizar,

analisar, gravar e reproduzir todos os dados da porta serial trocados entre os aplicativos do Windows e do dispositivo serial.

O programa se anexa ao driver da porta e monitora toda atividade que o software executar através de portas seriais. Esse programa está equipado com um analisador de protocolo MODBUS e é útil para desenvolvimento ou implementação de protocolos seriais, engenharia reversa e software de teste.

Neste trabalho, esse programa será utilizado para visualizar os dados trocados entre o programa do PLC com o próprio PLC, e também com os softwares de simulação. O software poderá ler os dados no padrão do protocolo MODBUS e fazer sua interpretação.

IV. MATERIAIS E MÉTODOS

A primeira fase do experimento utiliza o software Modscan, editando e também fazendo a leitura dos dados que são enviados na porta serial do computador, juntamente com o software Serial Monitoring Studio usado para interpretar o código em Modbus, e assim poder fazer a análise de seu funcionamento.

No endereço 2568, inserimos um valor pra variável, por se tratar de uma entrada analógica, são necessários dois endereços para armazenar esse valor.

Fig. 9. Modscan em execução com variável analógica

No software de escuta de linha, é demonstrada a

leitura do endereço de memória 2568 decorrente à atribuição desse valor para essa variável. Query: Mode: RTU Address: 1 (Slave) Function: 3 (Read Holding Registers) Starting Address: 2567 Number of Registers: 2 Parsed As:

Address: 42567-42568 (2) CRC:30226 (OK) Response: Mode: RTU Address: 1 (Slave) Function: 3 (Read Holding Registers) Parsed As: Register0: 0 Register1: 17244 CRC:52026 (OK)

Claramente pode-se ver na query o pedido de leitura da variável na posição de memória que inicia em 2567 e com duas posições de memória já que se trata de uma variável analógica, e em seguida na response a valor da variável é retornado ao mestre.

Para fazer uma completa análise e demonstrar que o Modscan comunica em MODBUS, abaixo está demonstrado o código gerado com o significado de cada variável.

Query: 01 03 0A 07 00 02 76 12

O ‘01’ é o endereço do dispositivo, o ‘03’ é o código

da função que nesse caso é a leitura de variáveis analógicas, ‘0A 07’ e ‘00 02’ são as posições da memória que deve ser lida, e por final ’76 12’ que é o campo de checksum feita por CRC. Não será demonstrado como é feito esse cálculo do CRC, pois não é o interesse desse estudo.

Response: 01 03 04 00 00 43 5C CB 3A

Na response os dois primeiros campos são iguais, em

seguida tem-se o ‘04’ que serve pra falar o tamanho da resposta, ‘00 00’ é o valor do primeiro campo e ‘43 5C’ é o valor contido no segundo campo, onde que os dois juntos são usados para discriminar a mesma variável. E por último o campo de checksum ‘CB 3A’.

Através dessa análise, pode se ter certeza de como é o funcionamento do protocolo MODBUS que gerou sucesso na comunicação, e assim pode ser aplicado na análise de equipamentos reais.

Na segunda fase deste experimento foram utilizados dispositivos físicos reais, primeiramente um CLP da Smar e posteriormente um CLP da Siemens, e foram colhidos seus dados de comunicação. Abaixo na Fig. 10, tem-se a interface do programa do CLP da Smar rodando um programa em Ladder.

Fig. 10. Programa CLP Smar

Em seguida na Fig. 11, é mostrada a interface do Serial Monitoring Studio com a leitura da porta serial utilizada pelo PLC.

Fig. 11. Interface do Serial Monitoring Studio Logo abaixo têm-se os dados obtidos através da

interpretação do protocolo MODBUS feita pelo programa de escuta de linha.

Aqui é mostrado o computador enviando um pedido de leitura das entradas digitais do mestre a partir do endereço 0 (Request ou Query), e são retornados os valores dessas variáveis no campo de dados (Response).

Query: Mode: RTU Address: 1 (Slave) Function: 2 (Read Discrete Inputs) Starting Address: 0 Quantity Of Coils: 10000 Parsed As: Address: 10000-19999 (10000) CRC:25142 (OK) Response: Mode: RTU Address: 1 (Slave) Function: 2 (Read Discrete Inputs) Parsed As: Coils 0-7: 1-1-1-1-1-1-1-1 Coils 8-15: 0-0-0-0-0-1-0-0 Coils 16-23: 1-1-1-1-1-1-0-0 Coils 24-31: 1-0-0-0-0-0-0-0 Coils 32-39: 0-0-0-0-0-0-0-0 Coils 40-47: 0-0-0-0-0-0-0-0 CRC:10405 (OK)

Nesse próximo exemplo o programa pede ao PLC mestre que envie a lista de endereço dos escravos, mas o Serial Monitoring Studio teve dificuldade para interpretar o campo de dados, o que podia ser esperado pois se trata de um experimento, e não haviam escravos conectados ao PLC. Mas a comunicação entre eles não teve falha, o que é importante para este estudo, isso é apenas um problema no nível físico.

Query: Mode: RTU Address: 1 (Slave) Function: 17 (Report Slave ID)

CRC:49196 (OK) Response: Mode: RTU Address: 1 (Slave) Function: 17 (Report Slave ID) This response can not be parsed because field sizes are device specific CRC:16137 (OK)

Agora o programa de escuta serial será utilizado apenas para a leitura dos dados em notação hexadecimal utilizada no modo RTU, e não será utilizada a interpretação do protocolo, isso sendo feito de modo manual.

Query: 01 02 00 00 27 10 62 36

Após um tempo de intervalo, inicia-se a transmissão dos dados da query, ‘01’ indica o endereço do CLP que opera como mestre, ‘02’ é o código correspondente a função de leitura de variáveis discretas, no campo de dados é escrito o intervalo de endereços para essa leitura, que começa em ‘00 00’ e vai até ‘27 10’, que em decimal corresponde a faixa de 0 a 10000. Por fim, tem-se o CRC calculado, que se inicia pelo valor menos significativo ‘62’ para o mais significativo ‘36’. Após a transmissão desses dados e o intervalo padrão é iniciada a transmissão de outros dados.

Response: 01 02 06 FF 00 00 01 00 00 A5 76

Na response tem-se o ‘01’ onde que o CLP mestre

indica seu próprio endereço para identificação, em seguida o ‘02’ indica a função MODBUS atribuída a essa response que é a leitura de variáveis discretas, em seguida é descrito o ‘06’ que mostra a quantidade de dados existente no campo de dados, este que retorna o valor das variáveis lidas ‘FF 00 00 01 00 00’, pode-se notar que não existem os 10000 valores que seria correspondente ao query feito, porém isso é uma limitação feita pela quantidade de portas digitais existentes no dispositivo.

Agora será mostrada a análise feita para o PLC da Siemens, que irá rodar um programa qualquer para que haja um fluxo de dados pela sua porta serial. Abaixo, está mostrada a Fig. 12 da interface do programa que irá programar o CLP.

Fig. 12. Interface CLP Siemens

Na visualização em MODBUS vista no programa de escuta é gerado o seguinte resultado:

Query: Mode: RTU Address: 104 (Slave) Function: 21 (Write General Reference/ Write File Record) Request0 File Number: 512 Record Number: 27698 CRC:60182 (WRONG) Query: Mode: RTU Address: 16 (Slave) Function: 2 (Read Discrete Inputs) CRC:24086 (WRONG) Response: Mode: RTU Address: 104 (Slave) Function: 23 (Read/Write Multiple Registers) CRC:2098 (WRONG)

Neste caso pode-se perceber que existe algum erro na transmissão, pois todos querys e responses apresentaram erros no campo de checksum. Para fazer uma análise mais profunda é necessário fazer a leitura dos dados em notação hexadecimal.

Query: 68 21 21 68 02 00 7C 32 01 00 00 00 00 00 14 00 00 28 00 00 00 00 00 00 FD 00 00 09 50 5F 50 52 4F 47 52 41 4D BA 16 Response: E5 Query: 10 02 00 5C 5E 16 Response: 68 10 10 68 00 02 08 32 Response: 03 00 00 00 00 00 01 00 Response: 00 00 00 28 68 16

Pode se ver que a comunicação fica confusa neste

caso. Na primeira query, o dispositivo tenta fazer uma comunicação com outro dispositivo no endereço 68, que não existe, e com a função MODBUS número 21, que não é suportada por este CLP. Se estivesse em conforme com o protocolo, deveria ser retornada uma response com o código ‘01’ que fala que a função não existe, ou com o código ‘02’ que fala que o endereço é inválido. Mas é retornado apenas ‘E5’ na response, que não tem nenhum significado lógico.

Na segunda query, é pedida a leitura das entradas discretas no dispositivo de endereço 10, mas no campo de dados onde deveria haver o intervalo de endereços para leitura, está 4200 até 2, de forma decrescente, o que é errado. Então esse framing também não está no padrão do protocolo. Em seguida são enviadas três responses de uma vez, o que mostra mais uma vez estar fora do padrão.

Pela leitura feita pela primeira vez no programa de escuta onde que foi utilizado o modo de interpretação do protocolo pode-se ver que os códigos são diferentes dessa segunda leitura, o que leva a pensar que os dados

não estão sendo enviados de forma cíclica e sim de uma forma aleatória sem qualquer significado lógico.

V. CONCLUSÕES

Este trabalho demonstra que mesmo que um CLP utiliza de um padrão de comunicação que é descrito em suas especificações, essa comunicação pode ser estabelecida de uma forma incorreta e isso compromete totalmente sua utilização, como foi no caso do CLP da Siemens utilizado neste experimento para se comunicar em MODBUS.

Com isso pode-se descartar a hipótese de haver um problema no próprio equipamento ou em sua camada física de comunicação, já que o problema foi detectado padrão de comunicação.

Desta forma, é difícil apontar qual o erro que está gerando essa incompatibilidade na comunicação, podendo existir várias origens, e por isso é necessário que se faça um estudo posterior mais profundo para descobrir o que é o problema, qual sua razão e sua solução.

VI. REFERÊNCIAS BIBLIOGRÁFICAS

[1] ALFA INSTRUMENTOS. Manual - Comandos de pesagem para Modbus RTU/ASCII, Revisão 2.0 – 21/09/2004.

[2] MODICON, Inc. Industrial Automation Systems. Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. J. June 1996.

[3] SIEMENS, Inc. SENTRON Expansion module PAC RS485 Manual. 02/2008.

[4] Site Win-TECH SOFTWARE DESIGN. Acedido em 21 de abril de 2011 em: http://www.win-tech.com/html/modscan32.htm

[5] Site HDD Software. Acedido em 10 de maio de 2011 em: http://www.hhdsoftware.com/serial-monitor