Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Uberlândia
2011
TÚLIO RESENDE ANDRADE
______________________________________________
Assinatura do Orientador
Uberlândia
2011
Dedico este trabalho primeiramente a Deus,
e aos meus pais pelo esforço, dedicação e
compreensão, em todos os momentos desta
e de outras caminhadas.
AGRADECIMENTOS
Aos meus pais José Evaristo e Maria Beatriz, e meu irmão Fábio por todo o incetivo,
paciência e compreensão.
Ao Prof. Josué Silva de Morais pelo incentivo, motivação e orientação deste
trabalho.
E a todos meus amigos e colegas que demonstraram companheirismo nessa minha
caminhada.
RESUMO
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.
LISTA DE ILUSTRAÇÕES
1. 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 a complexidade dos mesmos certos artifícios
utilizados de um fabricante para outro, para atender a norma do protocola 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 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 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.
12
2. DESENVOLVIMENTO
O tempo necessário para envio de uma palavra de 11 bits é 572,9 µs, então o silent
terá o valor de 2,005 ms. Após o silent todos caracateres são enviados em
hexadecimal. Um caracter indica o endereço do escravo, 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 caracter menos significativo para o mais
significativo.
Se um intervalo maior que um silent for detectado antes que toda a mensagem
tenha sido recebida, o dispositivo descarta os dados já recebidos da mensagem
atual e assume que o próximo caracter será o campo de endereço de uma nova
mensagem. Assim como uma nova mensagem for recebida em um intervalo menor
14
que o intervalo silent, o escravo assume que esta mensagem é uma continuação da
última mensagem recebida.
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 escravos
utilizando do 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 reconhecida 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 na Tabela 3 são mostrados os códigos com
as correspondentes funções, essa tabela é a padrão do protocolo, e não quer dizer
que todos dispositivos utilizaram desses códigos, podendo que alguns códigos não
são suportados por determinados modelos, e também fabricantes podem criar
códigos próprios.
08 Diagnostics
09 Program 484
10 Poll 484
11 Fetch Comm. Event Ctr.
12 Fetch Comm. Event Log
13 Program Controller
14 Poll Controller
15 Force Multiple Coils
16 Preset Multiple Registers
17 Report Slave ID
18 Program 884/M84
19 Reset Comm. Link
20 Read General Reference
21 Write General Reference
22 Mask Write 4X Register
23 Read/Write 4X Registers
24 Read FIFO Queue
1º - Fazer a soma:
Valor a ser
Campo analisado Valores em HEXA
somado
Campo de Endereço 34H 35H 69 / 45H
Campo Função Modbus 30H 33H 3 / 03H
Endereço Registrador Inicial (+) 30H 30H 0 / 00H
Endereço Registrador Inicial (-) 30H 41H 10 / 0AH
Quantidade de Registradores (+) 30H 30H 0 / 00H
Quantidade de Registradores (-) 30H 31H 1 / 01H
Valor resultante da soma 83 / 53H
2º - Complemento de 1:
3º - Complemento de 2:
Esse método não é totalmente seguro, pois não faz uma checagem do que é
enviado na mensagem, e sim pelos valores dos campos. Ele faz a soma dos valores
numéricos, e não a soma dos bytes que são enviados.
No modo de transmissão RTU é utilizado o CRC (Cyclical Redundancy Check) para
o cálculo de checagem do framing. Para o cálculo de CRC carrega-se uma variável
de memória com 16 bits com o valor FFFFH, mas efetivamente somente 8 bits dessa
variável serão utilizados. Os bits de configuração: start, paridade e stop bits, não são
utilizados no cálculo do CRC, apenas os
bits do caractere propriamente dito. Cada caractere é submetido a uma lógica XOR
(ou exclusivo) com os 8 bits menos significativos da variável de memória de valor
FFFFH, e então o resultado é deslocado uma casa à direita em direção ao bit menos
significativo, sendo que a posição do bit mais significativo é preenchida com valor 0.
Após esta operação, o bit menos significativo é examinado, ocorrendo o seguinte
processamento:
- Se o valor deste bit for igual a 0, nada ocorre e a rotina de cálculo do CRC continua
normalmente;
- Se o valor do bit for igual a 1, o conteúdo de todo o registrador CRC (16 bits) é
submetido a uma lógica XOR com um valor constante A001H e o resultado é
retornado à variável de memória utilizada.
O processo é repetido 8 vezes para cada caractere da mensagem, até que chegue
em seu valor final que é enviado para o campo de checksum.
Como pode-se ver, esse processo de checagem é muito longo e requer mais tempo
para seu cálculo, porém é muito mais confiável em relação ao LRC, pois analisa os
dados bit a bit sendo transferidos na comunicação.
2.1.2. Softwares
2.1.2.1. Modscan
A conexão dos simuladores pode ser feita em MODBUS/TCP ou utilizando uma das
nove portas como mostrado na Figura 3. Essas portas podem ser configuradas de
acordo com a rede e com o tipo de comunicação que será estabelecida (RTU ou
ASCII).
2.1.2.2. Modsim
A conexão dos simuladores pode ser feita em Modbus/TCP ou utilizando uma das
nove portas como mostrado na figura 4.
Essas portas podem ser configuradas de acordo com a rede e com o tipo de
comunicação que será estabelecida (RTU ou ASCII).
O LC700 é um controlador híbrido universal, desenvolvido pela Smar, que pode ser
usado no “System302” também desenvolvido pela empresa. Foi projetado para
aplicações em automação de manufatura, tarefas de automação, controle de
processo regulatório contínuo e controle por batelada. É composto por raks com
slots, que servem para instalação de seus módulos, sua modularidade gera uma
grande flexibilidade, já que pode ser aplicado em pequenos processos e ser
expandido posteriormente.
Este tmbém é um CLP indicado para projetos de automação de pequeno porte, mas
também é modulado possibilitando expansão, e possui elevada performace. As
interfaces integradas padrão RS485 suportam taxas de transferência de dados até
187,5 Kbps e podem trabalhar no modo Freeport, que aceita protocolo definido pelo
usuário. Suporta as funções MODBUS 1, 2, 3, 4, 5, 15 e 16.
2.2. Metodologia
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)
Query: 01 03 0A 07 00 02 76 12
Response: 01 03 04 00 00 43 5C CB 3A
Primeiramente são colhidos os dados gerados pela interpretação feita pelo programa
de escuta da porta serial, demonstrando o que significa cada query e 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)
Na query é mostrado que este CLP também se comunica no modo RTU, e também
que o programa envia um pedido de leitura das entradas digitais do dispositivo num
intervalo que se inicia a partir do endereço 0 e tem o tamanho de 10000 posições de
memória.
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)
retornado uma leitura de apenas 48 entradas, isso se deve ao fato de que o CLP
contém apenas 48 entradas digitais, trata-se então de um limitação física. Mas neste
exemplo também pode-se ver que a comunicação foi feita com sucesso dentro dos
padrões MODBUS.
Segundo exemplo utilizando o CLP LC700 Smar:
Query:
Mode: RTU
Address: 1 (Slave)
Function: 17 (Report Slave ID)
CRC:49196 (OK)
Nesse exemplo tem-se uma query que mostra que o programa pede ao CLP que
envie a lista de endereço dos escravos.
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)
Na response pode-se notar que 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 CLP. 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.
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. Através desse código será feita uma explicação de cada variável.
Query: 01 02 00 00 27 10 62 36
33
Após um silent, inicia-se a transmissão dos dados da query, „01‟ indica o endereço
do CLP, „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‟, conferindo com o valor calculado através do programa de
cálculo do CRC „0x3662‟. 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 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‟ eu mostra a
quantidade de dados existente no campo de dados que retorna o valor das variáveis
lidas „FF 00 00 01 00 00‟, como no exemplo similar feito anteriormente pode-se notar
que não existem os 10000 valores que seria correspondente ao query feito, que é
devido a uma limitação física. O checksum também é preenchido corretamente de
acordo com o valor gerado pelo programa de cálculo „0x76A5‟. Isso demonstra que
este CLP da Smar que foi utilizado comunica-se corretamente de acordo com o
padrão MODBUS e pode ser aplicado normalmente em ambiente industrial.
Agora será mostrada a análise feita para o CLP S7-200 da Siemens, que irá rodar
um programa qualquer para que haja um fluxo de dados pela sua porta serial.
Anteriormente foram feitas tentativas de utilização desse CLP em laboratório onde
que não foi possível estabelecer uma comunicação desse dispositivo junto a
dispositivos de outras marcas, e através dessa análise de protocolo será feita uma
verificação se este pode ser o protocolo de comunicação. Abaixo, está mostrada a
Figura 15 da interface do programa que irá programar o CLP. O programa funciona
perfeitamente bem e se comunica com o CLP normalmente, mas quando se faz uma
análise dos dados que passam pela porta serial onde é ligado o CLP é encontrada
uma certa irregularidade como será mostrado em seguida.
34
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)
35
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, primeiramente
porque são enviados dois querys consecutivos para que só depois fosse enviada
uma response, e também todos querys e responses apresentaram erros no campo
de checksum. Outro problema está nos endereços dos dispositivos, pois o programa
se comunica apenas com o CLP mestre que tem o endereço 01H. Para fazer uma
análise mais detalhada é 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 (Escrita de registros na área de
memória estendida), que não é suportada por este CLP. Se estivesse em conforme
36
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
frame 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.
2.3. Resultados
3. CONCLUSÕES
4. REFERÊNCIAS