PROTOCOLO MODBUS RTU

realizar o monitoramento por meio de um computador ou smartphone.

O ScadaBr ´e um recurso computacional da fam´ılia dos sistemas SCADA (Supervisory Control and Data Acquisition), nacional e de c ´odigo aberto, que permite desenvolver esta tarefa. Atrav ´es deste framework, o comporta- mento dos frangos pode ser acompanhado pela transmiss ˜ao da imagem de c ˆameras instaladas no interior dos galp ˜oes, pela coleta dos par ˆametros de tem- peratura e umidade via sensores, etc. Al ´em disso, o ScadaBR conta com uma estrutura de alarmes que alertam de maneira eficaz para eventuais defeitos em equipamentos ou mau funcionamento do sistema. Tamb ´em h ´a a possibilidade de atuac¸ ˜ao via interface remota. Em conjunc¸ ˜ao, esses aspectos tornam mais eventual a presenc¸a do avicultor no galp ˜ao.

No escopo deste trabalho, o ScadaBR ser ´a utilizado para monitorar a comunicac¸ ˜ao entre um microcontrolador e os dispositivos de atuac¸ ˜ao dispos- tos no avi ´ario. Com base nessa comunicac¸ ˜ao, ´e implementada uma interface que identifica de maneira intuitiva os valores medidos nos pontos de aquisic¸ ˜ao de dados e a ac¸ ˜ao em tempo real dos equipamentos de atuac¸ ˜ao. Al ´em disso, a interface prov ˆe um esquema de interfer ˆencia manual sobre o processo au- tom ´atico. Essa comunicac¸ ˜ao ´e realizada atrav ´es do protocolo Modbus RTU.

2.8 PROTOCOLO MODBUS RTU

O protocolo Modbus foi desenvolvido pela Modicon Industrial Auto- mation Systems, a atual Schneider Eletric, como um meio de comunicac¸ ˜ao en- tre dispositivos, sendo eles um mestre e um ou mais escravos. Embora seja uti- lizado normalmente sobre conex ˜oes seriais padr ˜ao RS-232, ele tamb ´em pode ser usado como um protocolo da camada de aplicac¸ ˜ao de redes industriais, tais como TCP/IP sobre Ethernet e MAP (FILHO, 2002).

Este protocolo define uma estrutura de mensagem que os disposi- tivos reconhecem e utilizam, independentemente do tipo de rede sobre a qual se comunicam. Ele descreve a maneira como um controlador realiza pedidos

2.8 Protocolo Modbus RTU 32

e responde outros dispositivos, segundo alguma func¸ ˜ao pr ´e-definida, al ´em de como os erros de envio e recepc¸ ˜ao de mensagens s ˜ao detectados e notifica- dos, estabelecendo um formato comum para o layout e conte ´udo dos campos das mensagens (MODICON, 1996).

Segundo a documentac¸ ˜ao fornecida pela Modicon, os controladores que utilizam este protocolo de comunicac¸ ˜ao, em redes Modbus padr ˜ao, podem ser configurados para se comunicar utilizando um dos dois modos de trans- miss ˜ao existentes: ASCII e RTU. Os usu ´arios podem implementar um dos dois modos, juntamente com os par ˆametros da porta de comunicac¸ ˜ao serial, como identificac¸ ˜ao da porta serial, taxa de transmiss ˜ao, modo de paridade, etc. O modo de transmiss ˜ao e os par ˆametros de configurac¸ ˜ao serial devem ser os mesmos para todos os dispositivos presentes na rede Modbus. O Modbus padr ˜ao, no qual existem os modos ASCII e RTU, define o conte ´udo dos cam- pos de mensagens, que s ˜ao arranjos de bits transmitidos de maneira serial, e como as informac¸ ˜oes s ˜ao organizadas nos campos do pacote de dados, al ´em de como ser ˜ao decodificadas pelo dispositivo que as receberem.

A comunicac¸ ˜ao entre dispositivos utilizando o protocolo Modbus ´e baseada no modelo mestre-escravo, onde um ´unico dispositivo da rede, o mes- tre, pode iniciar transac¸ ˜oes, ou troca de mensagens, e os demais, chamados escravos, respondem, suprindo os dados requisitados pelo mestre, ou execu- tando uma ac¸ ˜ao por ele comandada (FILHO, 2002). Quando o mestre envia uma mensagem enderec¸ada a um escravo, apenas o dispositivo enderec¸ado retorna uma resposta, como mostra a Figura 7.

O mestre inicia a comunicac¸ ˜ao enviando um byte com o enderec¸o do escravo para o qual se destina a mensagem. Ao enviar a resposta, o es- cravo tamb ´em inicia o telegrama com o seu pr ´oprio enderec¸o. O campo “c ´odigo da func¸ ˜ao” tamb ´em cont ´em um ´unico byte, onde o mestre especifica o tipo de servic¸o ou func¸ ˜ao solicitada ao escravo (leitura, escrita, etc.). De acordo com o protocolo, cada func¸ ˜ao ´e utilizada para acessar um tipo espec´ıfico de dado. As

2.8 Protocolo Modbus RTU 33 Endereço do Disposi! vo Endereço do Disposi! vo Código da Função Código da Função v v Checagem de Erro Checagem de Erro B tes de Dados Endereço do Disposi! vo Endereço do Disposi! vo Código da Função Código da Função v v Checagem de Erro Checagem de Erro B tes de Dados Mensagem do Mestr esposta do Escr vo R a e y y

Figura 7: Ciclo de mensagens gen ´ericas do Modbus trocadas entre mestre e escravo.

func¸ ˜oes s ˜ao pr ´e-definidas para este protocolo. O campo “bytes de dados” pos- sui tamanho vari ´avel e o formato e conte ´udo deste campo dependem da func¸ ˜ao utilizada e dos valores transmitidos (WEG, 2013). Por ´ultimo, h ´a um mecanismo de checagem de erro, finalizando a construc¸ ˜ao do pacote.

Neste trabalho, o protocolo de comunicac¸ ˜ao utilizado para troca de informac¸ ˜oes entre o microcontrolador MSP430G2553 e o sistema ScadaBR, foi o Modbus RTU. A Figura 8 mostra o formato das mensagens trocadas entre os dispositivos sob este protocolo.

2.8 Protocolo Modbus RTU 34

Entre as mensagens ´e necess ´ario um espac¸o de tempo de 3 a 5 chars, ou seja, o tempo necess ´ario para transmitir de 3 a 5 bytes. O c ´alculo deve ser realizado baseado na taxa de transmiss ˜ao escolhida.

O campo “enderec¸o” pode assumir valores entre 0 e 247 (em hexa- decimal, 0x00 a 0xf7), sendo que os dispositivos s ˜ao enderec¸ados com valores entre 1 e 247. O enderec¸o zero ´e reservado para ser utilizado como enderec¸o broadcast, ou seja, as mensagens destinadas ao enderec¸o zero s ˜ao reconhe- cidas por todos os elementos da rede. O campo “func¸ ˜ao” recebe o c ´odigo da func¸ ˜ao que ser ´a utilizada para realizar a comunicac¸ ˜ao. O valor pode variar de 1 a 255 (0x01 a 0xff, em hexadecimal), por ´em, ser ˜ao reconhecidos apenas va- lores que variam entre 1 e 127 (0x01 e 0x7f, em hexadecimal). Isso deve-se ao fato de que o bit mais significativo indica um c ´odigo de diagn ´ostico de falha ou sucesso na comunicac¸ ˜ao. O campo “dados” pode variar conforme a func¸ ˜ao e o tipo da mensagem, requisic¸ ˜ao ou resposta. No caso de escrita em algum registrador, este campo pode representar o valor que se deseja escrever. J ´a o campo “CRC” (Cyclical Redundancy Check ) cont ´em o resultado de um meca- nismo de checagem de erros (FILHO, 2002).

O campo CRC verifica o conte ´udo de toda a mensagem. Ele ´e apli- cado independentemente de qualquer m ´etodo de verificac¸ ˜ao de paridade uti- lizado para cada um dos caracteres da mensagem. O CRC ocupa dois bytes do pacote, contendo um valor bin ´ario de 16 bits. Seu valor ´e calculado pelo dispositivo de transmiss ˜ao, que acrescenta o CRC `a mensagem. O dispositivo receptor refaz a operac¸ ˜ao durante a recepc¸ ˜ao da mensagem, e compara o va- lor calculado para o valor real que recebeu no campo CRC. Se os dois valores n ˜ao forem iguais, ocorrer ´a um erro (MODICON, 1996).

A listagem a seguir apresenta um exemplo em linguagem C para o c ´alculo do CRC (CONTROL, 2013). A func¸ ˜ao recebe como entrada a vari ´avel que armazena o pacote de dados do Modbus RTU e seu comprimento. O retorno da func¸ ˜ao ´e o valor do CRC para o pacote de dados dado como par ˆametro.

2.8 Protocolo Modbus RTU 35

Neste exemplo, o valor de retorno ´e composto por dois bytes invertidos entre si, ou seja, para que a comparac¸ ˜ao de CRC esteja correta, ´e necess ´ario trocar suas posic¸ ˜oes.

1

2 // Exemplo de c´odigo em C para c´alculo do CRC 3 UInt16 M o d R T U _ C R C( byte [] buf , int len )

4 {

5 UInt16 crc = 0 xFFFF ; 6

7 for (int pos = 0; pos < len ; pos ++) {

8 crc ^= ( UInt16 ) buf [ pos ]; // XOR byte into least sig . byte of crc

9

10 for (int i = 8; i != 0; i - -) { // Loop over each bit 11 if (( crc & 0 x0001 ) != 0) { // If the LSB is set

12 crc > >= 1; // Shift right and XOR

0 xA001

13 crc ^= 0 xA001 ;

14 }

15 else // Else LSB is not set

16 crc > >= 1; // Just shift right

17 }

18 }

19 // Note , this number has low and high bytes swapped , so use it a c c o r d i n g l y ( or swap bytes )

20 return crc ;

21 }

Durante a gerac¸ ˜ao do CRC por meio do c ´odigo apresentado, cada caractere de 8 bits passa pela operac¸ ˜ao XOR (l ´ogica “ou exclusivo”) com o conte ´udo atual do registro. Em cada uma das vezes, o resultado ´e deslocado na direcc¸ ˜ao do bit menos significativo (LSB), com um zero preenchido na posic¸ ˜ao

2.8 Protocolo Modbus RTU 36

de bit mais significativo (MSB). O LSB ´e extra´ıdo e examinado. Se seu valor l ´ogico for 1, o registro passa pela operac¸ ˜ao XOR com um valor fixo predefinido (0xA001). Se o LSB tiver valor l ´ogico 0, ocorre apenas o deslocamento `a direita novamente. Este processo ´e repetido at ´e que oito mudanc¸as sejam realizadas. O protocolo Modbus RTU pode ser utilizado para comunicar o sis- tema ScadaBR com dispositivos como microcontroladores e CLP’s.

37

3 RESULTADOS

Este cap´ıtulo ´e dividido em quatro macro sec¸ ˜oes, Modelagem, S´ıntese, Implementac¸ ˜ao e Monitoramento, cada uma descrevendo uma das etapas que constituem o sistema proposto no trabalho.

Para a implementac¸ ˜ao de um sistema de controle de temperatura e umidade baseado na TCS aplicado ao processo av´ıcola, ´e ideal que as vari ´aveis que se deseja controlar sejam monitoradas em v ´arios pontos do am- biente. Na arquitetura tradicional, discutida na Sec¸ ˜ao 2.2, apenas 2 sensores cobrem uma vasta ´area de 100 a 200 metros de extens ˜ao, dificultando uma ac¸ ˜ao de controle objetiva. Nesse sentido, ´e fato que, quanto mais sensores forem distribu´ıdos ao longo do avi ´ario, melhor ser ´a o monitoramento clim ´atico como um todo e mais objetiva tende a ser a ac¸ ˜ao do controlador. Assim, uma tarefa imediata desse trabalho ´e aumentar o n ´umero de sensores ao longo da extens ˜ao do galp ˜ao.

Ao posicionar uma quantidade maior de sensores, ´e poss´ıvel identi- ficar em cada ponto de medic¸ ˜ao os valores de temperatura e umidade. Por ´em, sob o ponto de vista do sistema de controle, n ˜ao basta apenas conhecer os pontos cr´ıticos do ambiente (em que as vari ´aveis monitoradas n ˜ao encontram- se em valores ideais), mas sim viabilizar ac¸ ˜oes baseadas nessas informac¸ ˜oes, manipulando vari ´aveis at ´e que o sistema alcance um estado t ´ermico desejado. Portanto, a tarefa de reposicionamento e expans ˜ao da quantidade de sensores pressup ˜oe a divis ˜ao do espac¸o f´ısico do galp ˜ao em setores de ventilac¸ ˜ao, onde cada setor recebe, n ˜ao s ´o um ponto de aquisic¸ ˜ao de dados, mas tamb ´em atuadores locais. Cada setor ´e visto isoladamente, tornando o sistema facilmente escal ´avel e mais robusto, uma vez que problemas em equi-

3 Resultados 38

pamentos de um setor n ˜ao afetar ˜ao os demais. A Figura 9 ilustra a forma assumida pela nova organizac¸ ˜ao dos componentes do sistema.

X X X X X X X

Exaustores (saída de ar)

Cortina (entrada de ar) Pontos de aquisição de

dados (sensores)

Nebulizadores

Fluxo de ar transversal

Figura 9: Modelo de arquitetura proposta para o novo sistema de controle do avi ´ario.

Note que o fluxo de circulac¸ ˜ao interna de ar passa a ser transversal, o que sugere um melhoramento na homogeneizac¸ ˜ao da temperatura e da umi- dade, uma vez que a dist ˆancia percorrida pelo ar entre a entrada e a sa´ıda ´e menor em relac¸ ˜ao ao modelo tradicional, o que diminui seu superaquecimento. Salienta-se ainda que, nessa nova arquitetura, a atuac¸ ˜ao local dos componentes do sistema pode interferir no comportamento dos componentes vizinhos. Entretanto, essa interfer ˆencia ´e absorvida pelo sistema de controle proposto, que ser ´a apresentado na sequ ˆencia.