análise da interoperabilidade do protocolo modbus em dispositivos

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: [email protected]
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 PR
OTOCOL 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
Endereço do dispositivo
Função Modbus
Dados para o dispositivo
Checksum
Fim de framing
3AH
Char +
Char 2 chars
N chars
LRC +
0DH
LRC 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
Endereço do dispositivo
Função Modbus
Dados para o dispositivo
Checksum
Fim de framing
TInício
1 Char
1 Char
1 chars
N chars
CRC TFim
CRC 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
02
03
04
06
10
2B
Função Modbus
Read Discrete Inputs
Read Holding Registers
Read Input Registers
Write Single Register
Write Multiple Registers
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
01
02
03
04
05
06
07
08
Identificação
Função inválida
Sensor ou registrador inválido
Valor de dado inválido
Falha no dispositivo
Estado de espera
Dispositivo ocupado
Não reconhecimento
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.
B.
Fig. 1. Interface do Modscan
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.
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. 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. 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. 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. 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. 7. Interface para configuração de porta de comunicação.
Fig. 4. Notações para visualização dos resultados
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
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.
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:
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.
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.
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)
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.wintech.com/html/modscan32.htm
[5] Site HDD Software. Acedido em 10 de maio de
2011 em: http://www.hhdsoftware.com/serialmonitor