ANLISE 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 Eltrica (FEELT) Universidade Federal de Uberlndia (UFU) Av. Joo Naves de vila, 2160 - Bloco 3N - Campus Santa Mnica CEP: 38400-902 Uberlndia, MG, Brasil e-mail: tulioresende@yahoo.com.br Resumo - A interoperabilidade entre dispositivos dar-se- pela correta implementao do protocolo nos mesmos, porm quando esta comunicao no concretizada devemos analisar onde est a incoerncia. Neste artigo estudaremos o protocolo MODBUS apresentando tcnicas, aplicativos e conceitos, com o intuito de identificar e possivelmente sanar o problema de comunicao com este protocolo. Analisaremos ento 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 anlise do que transmitido e numa primeira etapa do experimento, ser feita a comunicao do equipamento com outro aplicativo. J na segunda etapa a comunicao ser feita utilizando equipamentos fsicos. Palavras-chave - Redes Locais Industriais, Protocolos de Comunicao, Simuladores.

I.

INTRODUO

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.

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 so normalizados e regidos por organizaes independentes. Porm devido complexidade dos mesmos, certos artifcios so 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 necessrio que se faa um estudo sobre o protocolo utilizado, neste artigo feito para o protocolo MODBUS, para conhecer o padro 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 no for o caso, ou seja, se a comunicao est realmente seguindo o padro do protocolo, deve procurar o problema na estrutura fsica 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 utilizao na rea de automao industrial, devido a sua simplicidade e facilidade de operao. Sua implementao 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 incio de framing, endereo de escravo, funo MODBUS, dados para o escravo, checksum e fim de framing. No modo ASCII, cada palavra composta por dois caracteres no formato ASCII, e sero compostas por 10 bits, sendo 1 start bit, 7 data bits, e 2 stop bits. A composio do framing nesse modo a seguinte, seu incio indicado pelo caractere dois pontos :, o endereo do dispositivo transmitido do caractere mais significativo para o menos significativo, a funo

MODBUS identificada por dois caracteres, em seguida so enviados os dados necessrios, depois o checksum que feito pelo mtodo LRC que tambm 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
Incio de framing Endereo do dispositivo Funo Modbus Dados para o dispositivo Checksum Fim de framing 3AH Char + 2 chars N chars LRC + 0DH LRC 0AH Char -

significativo em nvel 1. Abaixo mostrado na TABELA III os principais cdigos das funes. TABELA III Funes Modbus
Cdigo 02 03 04 06 10 2B Funo Modbus Read Discrete Inputs Read Holding Registers Read Input Registers Write Single Register Write Multiple Registers Read Device Identification

No modo RTU, cada palavra composta por um caractere no padro hexadecimal, e sero compostas por 11 bits, sendo 1 start bit, 8 data bits, e 2 stop bits. Na composio do framing temos que o incio e o fim do framing so indicados por um perodo ocioso que deve ser no mnimo 3,5 vezes do tamanho da palavra de dados, um caractere indica o endereo do dispositivo, e outro indica a funo MODBUS, seguido pelos dados necessrios, e pelo checksum feito pelo mtodo CRC que nesse caso transmitido do caractere menos significativo para o mais significativo. TABELA II Framing em RTU
Incio de framing Endereo do dispositivo Funo Modbus Dados para o dispositivo Checksum Fim de framing TIncio 1 Char 1 chars N chars CRC TFim CRC TFim 1 Char

O Campo de dados formado por conjuntos de 2 dgitos hexadecimais, variando de 00H a FFH. As informaes contidas neste campo esto relacionadas ao tipo de funo definido no campo funo 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 informaes pedidas pelo mestre, ou no caso de erro conter um cdigo de exception, identificando o motivo que causou o erro e orientando o mestre na execuo do prximo comando. Abaixo mostrada a TABELA IV com os cdigos de identificao de erro nesse campo. TABELA IV Cdigos de identificao de erro
Cdigo 01 02 03 04 05 06 07 08 Identificao Funo invlida Sensor ou registrador invlido Valor de dado invlido Falha no dispositivo Estado de espera Dispositivo ocupado No reconhecimento Erro de paridade na memria

Assim ento, so enviados os pedidos dos mestres aos escravos, chamados de querys, que podem ser endereados a apenas um escravo, ou a todos os escravos utilizando o endereo de broadcast. Aps o envio o escravo retorna com uma mensagem semelhante, chamada response, que poder incluir dados ou erros encontrados, se isso no acontecer em um determinado tempo, o mestre detecta erro na transmisso e reenvia o pedido. No existe response no caso de comunicao em broadcast. O endereamento dos escravos feito com a faixa de endereos 0 a 247, onde que o endereo nmero 0 destinado ao broadcast. Nas querys o mestre insere o endereo do escravo, e nas responses o escravo insere novamente seu prprio endereo para que seja reconhecido pelo mestre. Para a funo MODBUS, tem-se uma faixa de valores de 1 a 255. Quando uma mensagem recebida pelo escravo, este campo indica qual ao deve ser tomada, por exemplo, fazer leitura ou escrita de sensores ou registradores, etc. Na response em que a ao foi concluda com sucesso, devolvido o mesmo valor neste campo, se houve algum erro, ou exception, o escravo devolve o cdigo da funo com o seu bit mais

III.

SOFTWARES

Para o estudo da interoperabilidade de dispositivos operando em MODBUS, existem dois aplicativos desenvolvidos pela Win-TECH Software Design que sero 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 usurio visualize toda a comunicao enviada pelos escravos, tambm sendo possvel alterao 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 so 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, porm este utilizado para a simulao de mltiplos dispositivos escravo enviando informaes ao seu mestre. Tem como sua finalidade executar testes em novos dispositivos mestres adicionados na rede para conferencia da sua interoperabilidade. Sendo assim, so enviados dados pelo Modsim ao dispositivo mestre seguindo o patro do protocolo MODBUS, ento caso seja gerado algum erro no dispositivo mestre, esse deve ter sua configurao verificada.

Sua interface permite a escolha da visualizao em notao binria, decimal ou hexadecimal, tanto quanto na escolha do modo de transmisso RTU ou ASCII. Como se pode ver na Fig. 2, o Modscan tem quatro tipo de variveis, duas dessas so discretas (Input Status e Input Register), e as outras duas so analgicas e so mostradas em notao binria (Coil Status e Holding Register). Cada uma dessas variveis tem um intervalo dedicado na memria, estando esses comeando com uma numerao diferente no endereo.
Fig. 5. Interface do Modsim.

A conexo dos simuladores pode ser feita em Modbus/TCP ou utilizando uma das nove portas como mostrado na Fig. 6.
Fig. 2. Tipos de Variveis

A conexo 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 comunicao que ser estabelecida (RTU ou ASCII).
Fig. 6. Conexo do Modsim.

Essas portas podem ser configuradas de acordo com a rede e com o tipo de comunicao que ser estabelecida (RTU ou ASCII).

Fig. 3. Interface para configurao de porta de comunicao

Como visto na Fig. 4, sua interface permite visualizao em vrias notaes como binrio, hexadecimal, etc.

Fig. 7. Interface para configurao de porta de comunicao.

Fig. 4. Notaes para visualizao dos resultados

Sua interface permite visualizao em vrias notaes como binrio, hexadecimal, etc.

Fig. 8. Notaes para visualizao 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 atravs de portas seriais. Esse programa est equipado com um analisador de protocolo MODBUS e til para desenvolvimento ou implementao 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 prprio PLC, e tambm com os softwares de simulao. O software poder ler os dados no padro do protocolo MODBUS e fazer sua interpretao. IV. MATERIAIS E MTODOS

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 varivel na posio de memria que inicia em 2567 e com duas posies de memria j que se trata de uma varivel analgica, e em seguida na response a valor da varivel retornado ao mestre. Para fazer uma completa anlise e demonstrar que o Modscan comunica em MODBUS, abaixo est demonstrado o cdigo gerado com o significado de cada varivel. Query: 01 03 0A 07 00 02 76 12 O 01 o endereo do dispositivo, o 03 o cdigo da funo que nesse caso a leitura de variveis analgicas, 0A 07 e 00 02 so as posies da memria que deve ser lida, e por final 76 12 que o campo de checksum feita por CRC. No ser demonstrado como feito esse clculo do CRC, pois no o interesse desse estudo. Response: 01 03 04 00 00 43 5C CB 3A Na response os dois primeiros campos so 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 so usados para discriminar a mesma varivel. E por ltimo o campo de checksum CB 3A. Atravs dessa anlise, pode se ter certeza de como o funcionamento do protocolo MODBUS que gerou sucesso na comunicao, e assim pode ser aplicado na anlise de equipamentos reais. Na segunda fase deste experimento foram utilizados dispositivos fsicos reais, primeiramente um CLP da Smar e posteriormente um CLP da Siemens, e foram colhidos seus dados de comunicao. Abaixo na Fig. 10, tem-se a interface do programa do CLP da Smar rodando um programa em Ladder.

A primeira fase do experimento utiliza o software Modscan, editando e tambm fazendo a leitura dos dados que so enviados na porta serial do computador, juntamente com o software Serial Monitoring Studio usado para interpretar o cdigo em Modbus, e assim poder fazer a anlise de seu funcionamento. No endereo 2568, inserimos um valor pra varivel, por se tratar de uma entrada analgica, so necessrios dois endereos para armazenar esse valor.

Fig. 9. Modscan em execuo com varivel analgica

No software de escuta de linha, demonstrada a leitura do endereo de memria 2568 decorrente atribuio desse valor para essa varivel. 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 notao hexadecimal utilizada no modo RTU, e no ser utilizada a interpretao do protocolo, isso sendo feito de modo manual.

Fig. 11. Interface do Serial Monitoring Studio

Query: 01 02 00 00 27 10 62 36 Aps um tempo de intervalo, inicia-se a transmisso dos dados da query, 01 indica o endereo do CLP que opera como mestre, 02 o cdigo correspondente a funo de leitura de variveis discretas, no campo de dados escrito o intervalo de endereos para essa leitura, que comea 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. Aps a transmisso desses dados e o intervalo padro iniciada a transmisso 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 prprio endereo para identificao, em seguida o 02 indica a funo MODBUS atribuda a essa response que a leitura de variveis discretas, em seguida descrito o 06 que mostra a quantidade de dados existente no campo de dados, este que retorna o valor das variveis lidas FF 00 00 01 00 00, pode-se notar que no existem os 10000 valores que seria correspondente ao query feito, porm isso uma limitao feita pela quantidade de portas digitais existentes no dispositivo. Agora ser mostrada a anlise 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.

Logo abaixo tm-se os dados obtidos atravs da interpretao 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 endereo 0 (Request ou Query), e so retornados os valores dessas variveis 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 prximo exemplo o programa pede ao PLC mestre que envie a lista de endereo 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 no haviam escravos conectados ao PLC. Mas a comunicao entre eles no teve falha, o que importante para este estudo, isso apenas um problema no nvel fsico. Query: Mode: RTU Address: 1 (Slave) Function: 17 (Report Slave ID)

Fig. 12. Interface CLP Siemens

Na visualizao 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 transmisso, pois todos querys e responses apresentaram erros no campo de checksum. Para fazer uma anlise mais profunda necessrio fazer a leitura dos dados em notao 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 comunicao fica confusa neste caso. Na primeira query, o dispositivo tenta fazer uma comunicao com outro dispositivo no endereo 68, que no existe, e com a funo MODBUS nmero 21, que no suportada por este CLP. Se estivesse em conforme com o protocolo, deveria ser retornada uma response com o cdigo 01 que fala que a funo no existe, ou com o cdigo 02 que fala que o endereo invlido. Mas retornado apenas E5 na response, que no tem nenhum significado lgico. Na segunda query, pedida a leitura das entradas discretas no dispositivo de endereo 10, mas no campo de dados onde deveria haver o intervalo de endereos para leitura, est 4200 at 2, de forma decrescente, o que errado. Ento esse framing tambm no est no padro do protocolo. Em seguida so enviadas trs responses de uma vez, o que mostra mais uma vez estar fora do padro. Pela leitura feita pela primeira vez no programa de escuta onde que foi utilizado o modo de interpretao do protocolo pode-se ver que os cdigos so diferentes dessa segunda leitura, o que leva a pensar que os dados

no esto sendo enviados de forma cclica e sim de uma forma aleatria sem qualquer significado lgico. V. CONCLUSES

Este trabalho demonstra que mesmo que um CLP utiliza de um padro de comunicao que descrito em suas especificaes, essa comunicao pode ser estabelecida de uma forma incorreta e isso compromete totalmente sua utilizao, como foi no caso do CLP da Siemens utilizado neste experimento para se comunicar em MODBUS. Com isso pode-se descartar a hiptese de haver um problema no prprio equipamento ou em sua camada fsica de comunicao, j que o problema foi detectado padro de comunicao. Desta forma, difcil apontar qual o erro que est gerando essa incompatibilidade na comunicao, podendo existir vrias origens, e por isso necessrio que se faa um estudo posterior mais profundo para descobrir o que o problema, qual sua razo e sua soluo. VI. REFERNCIAS BIBLIOGRFICAS

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

[2] MODICON, Inc. Industrial Automation Systems. Modicon Modbus Protocol Reference Guide PI MBUS300 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