Desenvolvimento de um Driver de Comunicação para Coleta de ... · da UFRN como parte dos...

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO

Desenvolvimento de um Driver de Comunicaçãopara Coleta de Dados em Redes ISA100.11a

Willy Moser de Figueiredo Tomé

Orientador: Prof. Dr. Ivanovitch Medeiros Dantas da Silva

Natal, RN, Junho de 2015

Willy Moser de Figueiredo Tomé

Desenvolvimento de um Driver de Comunicaçãopara Coleta de Dados em Redes ISA100.11a

Trabalho de Conclusão de Curso apresen-tado ao Curso de Engenharia de Computaçãoda UFRN como parte dos requisitos para ob-tenção do título de Engenheiro de Computa-ção.

Orientador: Prof. Dr. Ivanovitch Medei-ros Dantas da Silva

Natal, RN, Junho de 2015

Agradecimentos

A graduação é o inicio de vários começos, é o inicio do amadurecimento pessoal, é iniciode novos desafios, é o amadurecimento do conhecimento e o usufruir de vários momentos.Concluir uma graduação é ver realizado um sonho compartilhado por várias pessoas, queacreditam na sua capacidade. A conclusão não seria possível sem a contribuição de muitaspessoas especiais ao longo desta caminhada.

Gostaria de agradecer aos meus pais Edilva e Carlos, por terem transparecido que comesforço, honestidade e estudo é possível abrir muitas portas na vida. Sou grato profunda-mente pelos incentivos nos momentos difíceis e pela enorme paciência.

Agradeço a minha esposa, Karina, por ter me ajudado a encontrar foco na vida. Agradeçotambém a compreensão pelos momentos perdidos devido a graduação.

Ao Professor Aquiles Burlamaqui, agradeço por ter acreditado no meu potencial no co-meço da minha graduação, pelas oportunidades a mim concedidas e também pelos conse-lhos e comentários de extrema importância.

Agradeço a todos amigos de graduação, em especial Felipe Gama, José Kleiton, JúlioCésar, Layon Luciano, Mário Sérgio, Tiago Fernandes e Fabio Fonseca pelas noites desono perdidas para terminar projetos, estudar para provas, discutir novas tecnologias e atéjogar conversa fora. Vocês foram fundamentais na minha formação.

Ao meu orientador e amigo, Professor Ivanovitch Medeiros, gostaria de externar minhagratidão pela orientação e ajuda. Discussões, comentários e conselhos foram de grandeimportância para o meu desenvolvimento profissional e do presente trabalho.

A toda equipe do Projeto Wireless, agradeço pela oportunidade de aprendizado bem comopor trabalhar com profissionais dedicados e talentosos.

À Petrobras e FUNPEC, pelo apoio financeiro.

Resumo

Atualmente as redes cabeadas implantadas em ambientes industriais trazem algunsproblemas como por exemplo, alto custo de manutenção, interrupção da produção du-rante instalações, entre outros. Com base nestes e outros problemas, uma das vertentes daindústria é o estudo dos protocolos de redes de sensores sem fio (Wireless), em especial,os principais protocolos no mercado: WirelessHart e ISA100.11a. O Potencial de apli-cações para este tipo de rede não estão fixadas apenas a áreas industriais, variando desdeambientes militares, domésticos, hospitalares etc. Visando essa inevitável migração paraas rede sem fio, o presente trabalho tem como objetivo principal o desenvolvimento deum driver capaz de se comunicar com dispositivos que utilizam protocolo ISA100.11a,afim de coletar dados da rede em tempo real. Além disso, o driver tem a função de abs-trair a complexidade de comunicação com tais dispositivos e fornecer portabilidade paraanálise e monitoramento de redes, não precisando dos softwares disponibilizados pelosfabricantes.

Palavras-chave: Automação Industrial, Redes Industriais Sem Fio, ISA100.11a.

Abstract

Currently wired networks implanted in industrial environments bring some problemsfor example, high maintenance costs, interruption of production during installations, amongothers. Based on these and other problems, one of the aspects of the industry is study ofthe protocols of wireless sensor networks, in particular the main protocols in the market:WirelessHART and ISA100.11a. The potential applications for this type of network arenot fixed only industrial areas, varying from military environments, household, hospital,etc. Aiming this inevitable migration to wireless network, this work has as main objec-tive the development of a capable driver to communicate with devices using ISA100.11aprotocol in order to collect data in real time. Moreover, the driver has the function ofabstracting the complexity of communication with such devices and provide portabilityfor analysis and monitoring networks not requiring the software provided by the manu-facturers.

Keywords: Industrial Automation, Wireless Industrial Networks, ISA10011a.

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas iv

Lista de Publicações v

1 Introdução 11.1 Redes Sem Fio Industriais . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Padrão ISA100.11a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Camada de Rede e Transporte . . . . . . . . . . . . . . . . . . . 81.2.4 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Contribuições do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Metodologia 112.1 Equipamentos Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Estratégias e Solução Encontrada . . . . . . . . . . . . . . . . . . . . . . 14

3 Estado da Arte 173.1 Sistemas de Gerenciamento de redes . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Field Wireless Monitor . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Driver de Comunicação 204.1 BR-Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

i

4.2 JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 GSAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Comunicação com Dispositivos ISA100.11a . . . . . . . . . . . . . . . . 244.5 Implementação e Comandos Implementados . . . . . . . . . . . . . . . . 26

5 Resultados 305.1 Software de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 BR-WirelessExpert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Aplicação de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Conclusão e Trabalhos Futuros 35

Referências bibliográficas 37

Lista de Figuras

1.1 Tecnologias sem fio utilizadas em ambientes industriais . . . . . . . . . . 21.2 Arquitetura do protocolo ISA100.11a . . . . . . . . . . . . . . . . . . . 31.3 Rede ISA100.11a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Tipos de roteamento na camada de enlace . . . . . . . . . . . . . . . . . 61.5 Saltos em frequência do padrão ISA100.11a . . . . . . . . . . . . . . . . 7

2.1 Dispositivos Yokogawa . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Dispositivos NIVIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 data-analizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Pacotes Transmitidos X Tempo . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Field Wireless Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Arquitetura BR-Collector . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Formato geral do pacote GSAP . . . . . . . . . . . . . . . . . . . . . . . 224.3 Nova arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Passos para a comunicação com o dispositivos ISA100.11a . . . . . . . . 254.5 Passos para a comunicação com os’ dispositivos ISA100.11a . . . . . . . 264.6 Algoritmo padrão de implementação dos comandos . . . . . . . . . . . . 27

5.1 Software de teste da especificação GSAP . . . . . . . . . . . . . . . . . 305.2 Teste serviço device list report . . . . . . . . . . . . . . . . . . . . . . . 315.3 Interface web BR-WirelessExpert . . . . . . . . . . . . . . . . . . . . . 325.4 Organização da rede isa . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5 Cenário com os instrumentos . . . . . . . . . . . . . . . . . . . . . . . . 335.6 Controlador com tempo de 4 segundos . . . . . . . . . . . . . . . . . . . 33

iii

Lista de Tabelas

1.1 Subcamadas da que formam a camada de enlace do padrão ISA100.11a . 6

4.1 Tipos de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Status possíveis para o serviço de session e device list report . . . . . . . 27

5.1 Kp, Ki e Kd para o teste de 4s . . . . . . . . . . . . . . . . . . . . . . . 34

iv

Lista de Publicações

GAMA, F. O. S. ; MARTINS, J. K. E. C. ; MIRANDA, T. F. ; TOMÉ, W. M. F. ; FER-NANDES, M. A. C. . Controle de Fluxo de Ar em Ventiladores Utilizando SistemasEmbarcados em Microcontroladores. In: XXI Congreso Internacional de Ingeniería Elec-trónica, Eléctrica y Computación - INTERCON, 2014, Arequipa. XXI Congreso Interna-cional de Ingeniería Electrónica, Eléctrica y Computación - INTERCON 2014, 2014. v.1.

GAMA, F. O. S. ; MARTINS, J. K. E. C. ; TOMÉ, W. M. F. ; MIRANDA, T. F. ; FER-NANDES, M. A. C. . Comparação de Desempenho entre Sistemas Especialistas Apli-cados ao Desvio de Obstáculos em Robôs Móveis. In: III CBSF - Terceiro CongressoBrasileiro de Sistemas Fuzzy, 2014, João Pessoa. III CBSF - Terceiro Congresso Brasi-leiro de Sistemas Fuzzy, 2014. v. 1.

GAMA, F. O. S. ; MARTINS, J. K. E. C. ; MIRANDA, T. F. ; TOMÉ, W. M. F. ; FER-NANDES, M. A. C. . Control of Airflow in Ventilation Systems Using Embedded Sys-tems in Microcontrollers.. DYNA (Medellín), 2015.

Capítulo 1

Introdução

As redes industriais, também chamadas de redes de chão-de-fábrica, foram especifi-camente desenvolvidas para automação industrial, sendo portanto, bastante diferentes dasredes de computadores tradicionais em relação a dados, padrões de tráfegos, confiabili-dade das aplicações, exigências temporais, entre outros fatores [Sauter 2005]. Atualmenteas redes sem fio vem se mostrando uma solução para os problemas ocasionados pela re-des com cabos. Sendo assim diversas pesquisas estão sendo feitas afim de viabilizar essamudança.

O objetivo deste capítulo inicialmente é revisar de maneira breve adoção das tecnolo-gias sem fio. Além disso, descrever de maneira mais detalhada o protocolo ISA100.11aextremamente importante para a realização do presente trabalho. Ao final deste capí-tulo serão descritos também a motivação, as contribuições do trabalho e a organização dorespectivo documento.

1.1 Redes Sem Fio Industriais

A tecnologia de rede sem fio industrial foi uma evolução das primeiras tecnologiasque usavam cabo como meio de transmissão de dados no âmbito industrial. A inten-ção de eliminar o cabeamento não é algo novo, por exemplo, Lessard & Gerla [1988]desenvolveram um dos primeiros trabalhos nessa área na tentativa de comunicar dispo-sitivos industriais por infravermelho. Apesar das muitas vantagens proporcionadas pelasredes sem fio industriais, como principal vantagem a redução do cabeamento, por muitotempo essa tecnologia foi vista com desconfiança pelas companhias. Esse cenário foi cri-ado principalmente pela baixa confiabilidade do canal de comunicação, haja visto que osequipamentos são instalados em áreas sujeitas à influência de agentes externos (ruídos,interferências, clima adverso, obstáculos naturais), que podem provocar erros em taxassuperiores aos das tecnologias cabeadas [Bai & Atiquzzaman 2003].

CAPÍTULO 1. INTRODUÇÃO 2

Além disso, como o meio de transmissão é o ar, os dados transmitidos ficam de certaforma "disponíveis"a dispositivos que estão ao alcance do rádio. Devido a isso torna-sede extrema importância um elevado nível de segurança com o intuito de evitar o acessoindevido a essas informações. No extremo, pessoas não autorizadas podem aproveitar daausência de segurança para injetar pacotes nocivos à rede afim de realizar algum ataqueou roubar informações [Chang & Chen 2012]. Existe também um desafio importante aser observado que é o acesso ao meio de comunicação já que o ambiente sem fio é abertoe muitas outras tecnologias estão presentes, podendo até compartilhar a mesma faixa defrequência. Assim é de extrema importância que essas redes possam operar normalmentemesmo em meio a outras tecnologias presentes.

Apesar de todos esses desafios, com a evolução das tecnologias de comunicação, no-vos mecanismos foram desenvolvidos para garantir a confiabilidade das redes sem fio(modulação e codificação, escalonamento determinístico, saltos de frequências e topolo-gias redundantes), tornando sua utilização acessível aos ambientes industriais [Gungor &Hancke 2009, Han et al. 2011]. As principais soluções atualmente para redes industriaissem fio são divididas em dois grupos e podem ser descritas na Figura 1.1.

Figura 1.1: Tecnologias sem fio utilizadas em ambientes industriais

O grupo WLAN (Redes Locais Sem Fio) engloba as tecnologias que são baseadasno padrão IEEE 802.11 e o grupo WPAN (Redes Pessoais Sem Fio) engloba as tecno-logias baseadas no padrão IEEE 802.15 e outras comissões de padronização com porexemplo, IEC (Comissão Eletrotécnica Internacional) e ISA (Sociedade Internacional de


Automação). Como o objetivo do trabalho não é a descrição de todos esses padrões,recomenda-se a análise global dos mesmos com a leitura das seguintes referências [Zandet al. 2012, Petersenand & Carlsen 2011]. Os padrões que se destacam em meio a tan-tos, no ambiente industrial, são os padrões WirelessHart e ISA100.11a. O primeiro é umpadrão desenvolvido pela HART Comunication Foundation (HCF) adaptado ao padrãocabeado já existente HART. Como esse padrão não é o foco do trabalho, recomenda-sea leitura da seguinte referência [IEC 2010]. No caso do ISA100.11a, esse protocolo serábem detalhado na próxima seção.

1.2 Padrão ISA100.11a

Aprovado em 2009 pela Sociedade Internacional de Automação (ISA), esse padrãode comunicação sem fio conhecido como ISA100.11a foi desenvolvido voltado para apli-cações industriais de controle e monitoramento. Diferente do padrão WirelessHart elefoi desenvolvido baseado nas exigências de usuários finais, no caso do WirelessHart, foiadaptado a um padrão específico já existente (HART). Como em muitos padrões já exis-tentes, a arquitetura base do padrão ISA100.11a é uma versão simplificada do modelo OSI(Open Systems Interconnection), contendo apenas 5 camadas bem definidas. Uma visãogeral da arquitetura existente no padrão é descrito na Figura 1.2. Nas próximas seçõesessas camadas serão mais bem detalhadas.

Figura 1.2: Arquitetura do protocolo ISA100.11a

Este padrão pode coexistir junto a outras tecnologias em um mesmo ambiente, comopor exemplo, IEEE 802.11x, IEEE 802.15x, IEEE 802.16x, telefonia celular, ou seja,


ele apresenta suporte a coexistência. Além disso, apresenta também um mecanismo detunelamento capaz de fazer com que vários outros padrões industriais de comunicação(HART, WirelessHART, Foundation Fieldbus, Profibus, Modbus, entre outros) possamser utilizados em uma rede ISA100.11a. O padrão tem como objetivo prover uma comu-nicação sem fio confiável e segura para aplicações com até 100 ms de latência, típicas demonitoramento e controle.

Uma rede ISA100.11a é formada por dispositivos com funções bem definidas. Osdispositivos em geral podem assumir as seguintes funções: gerente de sistema, gerentede segurança, gateway, roteador backbone, roteador, dispositivos I/O, dispositivo portá-til, função de provisionamento e referência temporal. O gateway, o gerente de sistemas,gerente de seguração e a backbone podem ser encontrados num único dispositivo ou sim-plesmente em dispositivos separados. Uma típica rede ISA100.11a é descrita na Figura1.3.

Figura 1.3: Rede ISA100.11a

O dispositivo I/O é responsável por atuar ou monitorar as variáveis do ambiente. Comintuito de economizar energia nestes dispositivos, de acordo com a norma eles não temcapacidade de roteamento. Um dispositivo I/O também pode ser portátil, nesse caso, suaoperação é limitada a testes, manutenção e configurações de outros dispositivos. Valesalientar que os dispositivos de campo podem ser configurados como roteadores, I/O ouprovisionadores. O roteador e roteador backbone (ou simplesmente backbone) são res-ponsáveis pelo roteamento. O roteador encaminha dados em direção ao gateway e estendeo alcance da rede. Além disso, tem a função também de comissionar novos dispositivos.O backbone é responsável pelo roteamento de alto nível da rede, tunelamento, e também


pode ser usado para aumentar a vazão de tráfego de dados de acordo com o aumento dassub-redes. O tráfego entre backbones utiliza uma versão compactada do IPV6, o 6LoW-PAN (IPV6 sobre redes pessoais de baixa potência), o qual é otimizada para as redes desensores sem fio [Neves & Rodrigues 2010].

A operação de uma rede ISA100.11a são centralizadas em três dispositivos: gateway,gerente de segurança e gerente de sistema. O gateway é responsável por interligar as redessem fio com aplicações presentes na rede industrial. O gerente de segurança é responsávelpor manter as comunicações seguras e manutenção e distribuição das chaves de segurança.O gerente de sistema é o centro da rede, responsável pela garantia de comunicação entreos dispositivos.

1.2.1 Camada Física

Essa camada é baseada no padrão IEEE 802.15.4, com a responsabilidade de converterinformações de dados digitais em energia de rádio frequência, capturando ou enviandopor antenas de rádio. Em relação ao rádio, é esperado alcances de aproximadamente 100metros de acordo com o padrão base, no entanto, testes realizados em ambientes abertose com visada direta obtiveram um alcance de até 600 metros (ganho extra da antena)[Yamamoto et al. 2010]. Porém isso pode não ser muito bom, dado que com o aumentodo alcance, o consumo de energia aumenta. Esse protocolo utiliza apenas a faixa defrequência de 2.4 GHz para transmissão dos dados. O ISA100.11a permite a utilizaçãode 16 canais (11-26) para transmissão dos pacotes, sendo o que o canal 26 é bloqueadodependendo do país. Essa camada fornece dois tipos de serviço:

• Serviço de dados: responsável por permitir a transmissão e recepção de dados atra-vés de um canal de rádio físico.

• Gerenciamento de Serviços: responsável por controlar as funções de operação, taiscomo: seleção de canais, seleção de potência de transmissão etc.

Adicionalmente, este padrão permite o controle da potência de transmissão do rádio,porém nenhum algoritmo é especificado pelo padrão para realizar esta função.

1.2.2 Camada de Enlace

A característica básica de todas as camadas de enlace baseadas no modelo OSI é con-trolar o acesso dos dispositivos ao meio de transmissão. Porém, existe uma peculiaridadenesta camada que é o roteamento a nível da camada de enlace. A camada de enlace fun-damentalmente é dividida em 3 subcamadas: MAC, extensão da MAC e uma subcamada


de alto nível. As devidas responsabilidades de cada camada podem ser encontradas naTabela 1.1 abaixo.

Subcamadas Funções/CaracterísticasMAC Subconjunto de funções do padrão IEEE802.15.4.

Extensão da MAC Inclui algumas características que o padrão da IEEE802.15.4 não suporta relacionadas com o CSMA-CA,TDMA e Saltos de Frequência.

Alto Nível Responsável pelo roteamento a nível de camada de enlace.

Tabela 1.1: Subcamadas da que formam a camada de enlace do padrão ISA100.11a

A comunicação entre os dispositivos ocorre utilizando slots de tempo, superframes,links e grafos. Essa norma suporta também topologia estrela, mesh e híbrida. Para lidarcom roteamento em malha a norma suporta dois algoritmos de roteamento: grafo (Graph

Router) e origem (Source Router). De acordo com a Figura 1.4, podemos ter uma ideiado comportamento desses algoritmos de roteamento.

Figura 1.4: Tipos de roteamento na camada de enlace

O source router possui apenas um caminho do nó de origem ao nó destino, caso o link

seja perdido, não encontramos outro caminho que possa ser usado para enviar o pacote,logo o pacote é perdido. No caso do graph Router, uma única instância da rede pode tervários grafos sobrepostos, bem como inúmeros caminhos para um nó de origem. Assim,caso aconteça de algum link quebrar, o pacote pode ser transmitido por outro caminho,isso garante redundância e aumenta a confiabilidade da rede, diferente do source router.Podemos observar isso analisando a Figura 1.4, existem caminhos diferentes do nó A aoF, por exemplo A-C-E-F e A-B-D-F. Apesar do source router parecer algo inicialmenteruim no contexto geral, dependendo da aplicação, pode ser a solução mais indicada doque o graph router.

A ISA100.11a define controle de acesso ao meio com base em TDMA (Time Division

Multiple Access) acoplado a saltos de frequência. Nesse padrão são definidos 3 tipos


diferentes de saltos em frequência: slotted, lento e Híbrido. A Figura 1.5 descreve essessaltos de frequência.

Figura 1.5: Saltos em frequência do padrão ISA100.11a

No primeiro, slotted, cada comunicação ocorre em um intervalo de tempo diferente,com isso foram definidos 5 padrões diferentes de salto. A ordem dos canais tem comoobjetivo otimizar a coexistência com redes IEEE 802.11 e WirelessHart. Já no segundocaso, é alocado um intervalo de tempo de 100 a 400 ms para a transmissão e o próximocanal só é escolhido depois deste intervalo de tempo. O problema desse tipo de salto é queaumenta o consumo de energia dos dispositivos. Além disso, por questões de coexistênciarecomenda-se usar os canais 15, 20 e 25. No Híbrido, como o próprio nome já diz, éuma mesclagem do slotted com o lento. O híbrido são usados para otimizar o envio dealarmes e retransmissões. Os slots de comunicação independente do perfil do salto, temduração de 10 ms ou 12 ms. Esse slot de 12 ms foi adicionado ao padrão para suportarsequência múltiplas de mensagens de reconhecimento (dualcast), permitir comunicaçãode dispositivos ligeiramente atrasados da referência temporal e priorização de mensagensdo tipo CCA (Clear Channel Assessment).


1.2.3 Camada de Rede e Transporte

A camada de rede é responsável por prover o roteamento a nível dos backbones. Nacamada de enlace, o roteamento limita-se apenas as sub-redes e ao chegar nos backbones

a responsabilidade do roteamento se volta a camada de rede. Com relação ao endereça-mento feito nas camadas de rede e enlace, na camada de enlace o endereçamento de cadadispositivo é feito utilizando 16 bits, diferentemente da camada de rede que usa 128 bits(6LoWPAN). Umas das funções desta camada é justamente traduzir esses endereços de16 bits para endereços com 128 bits. Outra função é a fragmentação de dados de mensa-gens com tamanhos superiores a carga útil da camada de enlace, ou seja, esses dados sãofragmentados e suas partes enviadas uma a uma.

A respeito da camada de transporte, sua função está relacionada a comunicações fim-a-fim (end-to-end), operando apenas nos nós finais da comunicação. Fornece também,serviços sem conexão (não orientado a conexão), geralmente com segurança baseada emcriptografia. Tais serviços são extensões do UDP sobre o 6LoWPAN [Petersenand &Carlsen 2011].

1.2.4 Camada de Aplicação

A camada de aplicação é estruturada no padrão orientado a objetos, ou seja, tudo podeser descrito como um objeto. Sendo assim os dispositivos da rede são modelados comoobjetos, possuindo seus respectivos atributos. Devido a forma com que essa camada foiprojetada, o padrão da suporte ao tunelamento, onde aplicações que utilizam padrões jáconhecidos e usados na indústria como HART, Foundation Fieldbus, Profbus, possamacessar os dispositivos da rede ISA100.11a. Essa camada criar uma espécie de contratocom os dispositivos, com intuito de fornecer latência limitada, escalonamento etc. Atroca de informações usa o modelo produtor/consumidor ou cliente/servidor. Além disso,os dispositivos podem ser configurados para enviar alertas caso um determinado eventoocorra.

1.3 Motivação

Recentemente, apesar do conservadorismo da indústria, as redes sem fio industriaisvem se tornando uma solução viável para o cabeamento estruturado tradicionalmenteadotado em projetos de comunicação com aplicações industriais. Esse paradigma temcomo objetivo diminuir os custos com manutenção, instalação, peso (por exemplo pla-


taformas de petróleo) e escalabilidade. Atualmente os principais protocolos do mercadoque trabalham com este novo paradigma são os protocolos ISA100.11a e o WirelessHart.

Os fabricantes que utilizam esses protocolos fornecem algumas ferramentas que des-crevem a rede de maneira geral, exibindo por exemplo, tempo de vida útil da bateria dosdispositivos, topologia, endereço IPV4 e IPV6, variável de processo, perda de pacotes,entre outros. Estes dados inicialmente podem servir para fazer uma análise superficialdo comportamento da rede, no entanto análises mais minuciosas só seriam possíveis como acesso a esses dados independente das ferramentas fornecidas por fabricantes. Essa"liberdade"de acesso aos dados, abre várias possibilidades para análise e avaliação dedesempenho destas redes, além da possibilidade de construir a própria ferramenta de ava-liação.

1.4 Contribuições do Trabalho

A principal contribuição do referido trabalho é um driver capaz de se comunicar comos dispositivos de rede sem fio que utilizam o protocolo ISA100.11a. A ferramenta re-solve problemas importantes com relação a coleta de dados destes dispositivos. Fornecetambém, portabilidade a outros desenvolvedores que utilizam os equipamentos com o pro-tocolo, de criar sua própria ferramenta. Além disso, o driver abstrai a complexidade decomunicação existente no processo de troca de informações entre o driver e os dispositi-vos da rede, ajudando na implementação de novas aplicações. Agora, com a possibilidadede coletar dados da rede, várias métricas podem ser desenvolvidas para avaliações maisdetalhada sobre a rede.

1.5 Organização do Trabalho

No primeiro capítulo foi abordado o contexto geral das redes sem fio, com foco noprincipal protocolo de estudo para a realização deste trabalho, o padrão ISA100.11a. Fo-ram descritos a arquitetura do protocolo, os padrões atuais da indústria, motivação e con-tribuições do trabalho. No transcorrer do trabalho serão encontrados mais 5 capítulos,descritos brevemente abaixo:

• No capítulo 2 é descrito todo passo-a-passo realizado para o desenvolvimento doreferido trabalho, bem como os instrumentos e estratégias utilizadas. Esse capí-tulo tem como objetivo também mostrar os problemas e empecilhos encontrados,


bem como testes realizados com intuito de mostrar que o trabalho proposto seriapossível.

• O capítulo 3 descreve algumas soluções existentes no mercado, que utilizam al-gum tipo de solução para a coleta de dados das redes ISA100.11a. Essas soluçõesserviram como referencial para o desenvolvimento do referido trabalho.

• O capítulo 4 apresenta o produto bruto do presente trabalho. Neste capítulo procura-se exemplificar minuciosamente todos os passos, tecnologias utilizadas para a cria-ção do driver, estratégia de implementação, bem como os comandos implementa-dos até o momento, para coleta de dados dos dispositivos que utilizam o protocoloISA100.11a.

• O Capítulo 5 engloba todos cenários utilizados para validar a ferramenta. Estecapítulo caracteriza-se por apresentar a aplicabilidade do driver em diferentes apli-cações validando-o.

• No capítulo 6 finaliza-se o trabalho recapitulando um pouco de tudo que já foifalado no documento e os trabalhos que serão desenvolvidos posteriormente com autilização dessa ferramenta.

Capítulo 2

Metodologia

Este capítulo tem como objetivo descrever todos os passos abordados desde o iníciodo desenvolvimento do driver. São descritos os principais desafios encontrados, bemcomo as estratégias utilizadas para contorna-los. Descreve-se também os equipamentosutilizados para teste de coleta dos dados e softwares que já realizavam essa coleta demaneira off-line, desenvolvidos no projeto previamente ao driver.

2.1 Equipamentos Utilizados

Durante o desenvolvimento do referido trabalho foram utilizados equipamentos dedois fabricantes: Yokogawa e Nivis. Ambos trabalham com o protocolo ISA100.11a emseus dispositivos. Ao contrário da Yokogawa que trabalha apenas com esse protocolo semfio, a Nivis inclui também o WirelessHart, outro padrão muito importante na comunicaçãosem fio industrial. O ISA100.11a e WirelessHart são os principais padrões no mercadoatualmente e implementam diferentes soluções para tornar esse novo paradigma viável nomeio industrial.

A Yokogawa iniciou suas atividades no Brasil em 1973, com objetivo disponibilizartecnologia em automação industrial incluindo instrumentação de teste, medição, registrode grandezas elétricas e controle de processos industriais [YOKOGAWA 1915]. Os equi-pamentos utilizados no projeto referentes a este fabricante podem ser visto na Figura 2.1.Da esquerda para direita respectivamente, um sensor de pressão, sensor de temperatura eo gateway.

Neste caso o gerenciador de sistemas e segurança, backbone e o próprio gateway

estão juntos em um equipamento apenas, porém atualmente já são disponibilizados demaneira separada. Esse dispositivos são muito resistentes a variações climáticas, feitossobre medida para ambientes industriais externos, onde há uma constante mudança nascondições do clima.

CAPÍTULO 2. METODOLOGIA 12

Figura 2.1: Dispositivos Yokogawa

A Nivis é especialista em redes abertas, sensoriamento e controle sem fio padrão se-guras. Foi utilizado o kit de desenvolvimento Nivis ISA100.11a Integration Kit [NIVIS2010] desta empresa. Esses dispositivos podem publicar muitas outras variáveis do queapenas temperatura e pressão em somente um dispositivo, podem ser vistos na Figura 2.2.

Figura 2.2: Dispositivos NIVIS


2.2 Desafios

Os dispositivos que utilizam o protocolo ISA100.11a, em especial o gateway, gravambackups de tudo que ocorreu na rede nos últimos 15 minutos e organizam em um docu-mento simples com extensão txt. Esse backup contém todos os eventos ocorridos na redenesse intervalo de tempo, como por exemplo, queda do dispositivo da rede, entrada dodispositivo na rede, variações da potência e nível do sinal de cada dispositivo, pacotestransmitidos com sucesso ou não, topologias formadas durante a entrada e a queda dosdispositivos na rede, entre outros. Sendo assim, alguns softwares desenvolvidos no pro-jeto tinham a responsabilidade de extrair esse backup, organizar melhor as informações,e exibir tudo o que tinha acontecido na rede durante os 15 minutos. Essa estratégia é co-nhecida no projeto como análise off-line. O módulo responsável por extrair e organizar osdados é conhecido como PW-Extractor. Já o software responsável por fazer uma análisefuncional da rede é conhecido com Analyzer. Existe um outro módulo responsável porfazer análise gráfica da rede o qual também consome os dados vindos do PW-Extractor.Esses dois últimos podem ser vistos na Figura 2.3 e Figura 2.4, onde o data-analyzer éum módulo do analyzer.

Figura 2.3: Analyzer


Figura 2.4: data-analizer

O problema é que, caso fosse preciso analisar a rede em tempo-real, ou seja, acessaras informações em qualquer instante de tempo, para tomar algum tipo de decisão, comanálise off-line isso não seria possível. Os dados presentes no backup são antigos e apenasatualizados a cada 15 minutos.

Essa análise pretendida em tempo real, foi nomeada no projeto como análise online.Apesar dos dados do backup, ainda não existia uma espécie de comunicação real com osdispositivos, o que tornava a proposta do referido trabalho difícil de ser realizada. Na pró-xima subseção seram abordadas as estratégias realizadas que levaram ao desenvolvimentodo driver proposto.

2.3 Estratégias e Solução Encontrada

Tendo em vista os desafios descritos acima para o desenvolvimento do driver, o pri-meiro passo, foi tentar verificar a estrutura dos pacotes trocados entre a ferramenta webdisponibilizada pela NIVIS e o gateway. Para isso utilizou-se o software Wireshark queé uma especie de sniffer de rede capaz de capturar e visualizar o tráfego de dados (pa-cotes) entre hosts, como mostrado na Figura 2.5. O host monitorado neste caso, era ogateway, e a medida que os comandos eram executados no sistema web disponibilizadopelo fabricante, as requisições, bem como as resposta, eram capturadas e posteriormenteanalisadas.


Figura 2.5: Wireshark

Foi observado que os dados eram requisitados usando uma estrutura organizada ba-seada no JSON (JavaScript Object Notation). JSON é um formato de texto que é com-pletamente independente da linguagem utilizada, mas usa convenções familiares aos pro-gramadores da família-C. O JSON é usada como uma linguagem de intercâmbio de da-dos universal [JSON 1999]. As informações dos dispositivos eram acessadas usandorequisições HTTP, porém eram poucas as informações disponíveis na estrutura do pacote.Apesar de conseguir reproduzir algumas dessas requisições, isso não era o ideal, mais játínhamos um caminho a seguir.

O segundo passo foi semelhante ao primeiro, porém o foco do rastreamento foi ossoftwares disponibilizados pelos fabricantes e não mais a ferramenta web. Ao verificaros pacotes trocados foi observado um padrão, porém não sabíamos o que cada byte dospacotes significavam. Uma olhada mais minuciosa na norma ISA100.11a, encontramosuma espécies de API chamada GSAP que é responsável por justamente, permitir a comu-nicação dos dispositivos com aplicações clientes externas.

Em contato com a NIVIS, ela disponibilizou um documento que descrevia como im-plementar os comandos GSAP para aquisição de dados. Desta forma o Driver se tornouviável dependendo apenas da implementação dos comandos. Porém, antes de começar,procuramos validar os dados adquiridos usando essa especificação. Era importante saberse os dados coletados eram novos ou antigos, vindo do backup por exemplo. A estratégiautilizada foi bastante simples, implementar um comando presente na especificação e rea-lizar requisições ao Gateway afim de comprovar que os dados realmente alteravam com


o decorrer do tempo. Foi medido a quantidade de pacotes transmitidos com sucesso. AFigura 2.6 abaixo descreve o resultado encontrado.

Figura 2.6: Pacotes Transmitidos X Tempo

Foram monitoradas a quantidade de pacotes transmitidos por intervalo de tempo.Pode-se observar que com o decorrer do tempo os dados foram mudando em intervalosdiferentes de tempo, sendo assim foi comprovado que a especificação retornava valoresnovos, viabilizando assim o uso da GSAP. API GSAP será descrita de uma forma deta-lhada no capítulo 4.

Capítulo 3

Estado da Arte

Em uma rede industrial, o gerenciamento das informações capturadas das redes temgrande importância, e quando se fala de redes sem fio, essa importância aumenta devidoas desconfianças com relação a esse novo paradigma, como a segurança, eficácia, atrasode comunicação, duração da baterias, entre outros. O uso e o tempo de vida de sensoressem fio em redes inteligentes é um dos temas mais inspiradores para vários pesquisadores[Eris et al. 2013]. A análise desse conjunto de dados é muito importante nas tomadas dedecisões. Os softwares que ajudam os usuários determinarem que tipo de soluções deveser tomada dado algum problema, por debaixo dos panos, abstrai toda a complexidade decomunicação entre o softwares (aplicação cliente) e os dispositivos que formam a rede.Neste capítulo serão apresentados alguns sistemas responsáveis pelo gerenciamento dasinformações das redes industriais, com intuito de apresentar uma base para o desenvolvi-mento do driver proposto, bem como as soluções presentes no mercado.

3.1 Sistemas de Gerenciamento de redes

O gerenciamento das informações permitem o desenvolvimento de métricas capazesde servir como avaliação de desempenho de inúmeras coisas de modo geral, nesse con-texto, de redes ISA100.11a. Apesar dos benefícios diretos, uma rede industrial de sen-sores sem fio apresenta vários desafios como confiabilidade, consumo de energia, inter-ferência do ambiente e também o conservadorismo no âmbito industrial. Desta forma,a demanda para o desenvolvimento de ferramentas de gerenciamento de informações darede torna-se iminente. Os sistemas que gerenciam essas informações procuram abstrairtoda a complexidade de comunicação e dispor ao usuário de maneira agradável as infor-mações obtidas da rede. Essa abstração é um dos importantes objetivos de um sistemade gerenciamento e normalmente solucionados com implementação de drivers de comu-nicação. Nesta seção, são apresentadas algumas soluções encontradas no mercado para

CAPÍTULO 3. ESTADO DA ARTE 18

gerenciar essas informações em redes industriais que utilizam o protocolo ISA100.11a.

3.1.1 Field Wireless Monitor

O Field Wireless Monitor é um ferramenta desktop de gerenciamento de dados deredes ISA100.11a fornecida pelos fabricantes, e tem a função de acessar os dados dosdispositivos bem como alterar certas configurações na rede. A Figura 3.1 apresenta essaferramenta.

Figura 3.1: Field Wireless Monitor

Observa-se nesta imagem os diversos tipos de dados coletados sobre os dispositivoscomo, o identificador do dispositivo, nível de sinal, regras associadas a cada dispositivo(I/O, Router ou ambos), nível de bateria e algumas informações adicionais sobre a topo-logia formada, sendo exibida graficamente. Essas informações são acessadas em temporeal. Em qualquer instante de tempo é possível requisitar algo sobre a rede. Foi base-ado nesse software que foi encontrado informações sobre a especificação GSAP, ao sermonitorado pela ferramenta Wireshark, como explicado na seção anterior.

3.1.2 Sistema Web

Essa ferramenta tem as mesmas funções do Field Wireless Monitor, porém ela sedestaca pela portabilidade. É possível analisar as informações da rede ISA100.11a emqualquer lugar, precisando apenas de conexão com a internet. A partir desta ferramentavários dados podem ser visualizados, tais como, pacotes transmitidos e perdidos por cadadispositivo, nível de sinal, nível de bateria, os processos de entrada na rede, visualização

CAPÍTULO 3. ESTADO DA ARTE 19

gráfica da topologia formada, qualidade dos links, entre muitos outros. Esse sistema éapresentado na Figura 3.2.

Figura 3.2: Sistema Web

Capítulo 4

Driver de Comunicação

A parte mais técnica do trabalho está descrito nesse capítulo. O capítulo tem comoobjetivo descrever as tecnologias utilizadas para o desenvolvimento do driver. Serãoabordados aqui de maneira geral a linguagem utilizada, a ferramenta BR-Collector, aespecificação GSAP, como acontece a comunicação entre os dispositivos do protocoloISA100.11a e a implementação do driver, bem como os comandos implementados até omomento para coleta de dados dessas redes.

4.1 BR-Collector

O BR-Colector é uma ferramenta de captura de dados em ambientes industriais, de-senvolvido através de uma parceria entre UFRN e Petrobras. Atualmente o BR-Collectorsuporta captura de dados de processo histórico e em tempo real, captura de dados dealarmes e eventos históricos [Machado 2014].

O BR-Collector é formado pela união de vários drivers e slots. Os drivers são res-ponsáveis por implementar os detalhes de cada protocolo de comunicação e servem comointerfaces do BR-Collector. Já os slots tem como função tornar padrão a forma como oBR-Collector entende cada tipo de dado.

Neste contexto, o driver desenvolvido foi adaptado ao BR-Collector afim de permitira comunicação dessa ferramenta com os dispositivos de redes ISA100.11a. Vale salientarque ferramentas semelhante a essa, vem sendo desenvolvida em paralelo no projeto pararedes WirelessHart. Atualmente na arquitetura do BR-Collector estão presentes 4 drivers

e 4 slots conforme demonstra a Figura 4.1. À medida que for necessário, novos drivers

podem ser incorporados a arquitetura sem qualquer mudança nas camadas superiores.Com relação a comunicação, para a aplicação cliente se comunicar ao BR-Collector

deve ser implementada em java, pois a ferramenta utiliza a tecnologia Java Remote Method

Invocation (RMI) como forma de comunicação com os clientes. Com a conexão estabele-

CAPÍTULO 4. DRIVER DE COMUNICAÇÃO 21

Figura 4.1: Arquitetura BR-Collector

cida o cliente recebe uma referência para a interface Request onde estão todos os métodosde acesso as funcionalidades do BR-Collector. A partir daí o acesso a todos os dados sedará através de chamadas de métodos da classe Request abstraindo a comunicação entrea máquina servidora e o cliente, para o usuário.

4.2 JAVA

A linguagem de programação usada no desenvolvimento do referido trabalho foi oJAVA, devido a necessidade de seguir um padrão referente ao BR-Colector. Atualmenteo BR-Collector utiliza a tecnologia Java Remote Method Invocation como forma de co-municação com as máquinas clientes. Desta maneira, para se ter acesso a todas as fun-cionalidades disponibilizadas pelo BR-Collector é necessário que a aplicação cliente sejaimplementada também em Java como dito no subseção anterior. Outra observação impor-tante para o uso dessa linguagem, é que a camada de aplicação do protocolo trata tudocomo objeto, e o JAVA é especialista nisso, pois ela é uma linguagem que segue o para-digma de programação orientada a objetos (POO). Pode parecer estranho quando falamosde driver, quando a implementação é feita em uma linguagem de tão alto nível como ojava, porém no contexto do BR-Colector é assim que a ferramenta se comporta.

4.3 GSAP

Para a realização do trabalho foi preciso um estudo detalhado do documento dispo-nível pela NIVIS sobre o padrão GSAP de comunicação. A GSAP (Gateway Service


Access Point) é uma especificação responsável por permitir a comunicação entre o Ga-

teway e uma aplicação cliente. A partir dessa comunicação é possível ter acesso aos dadosdas redes ISA100.11a. A comunicação é baseada no protocolo TCP (Transmission Con-

trol Protocol), uma característica importante pois assim absorve as vantagens inerentesdo protocolo.

A GSAP utiliza comunicação baseada em pacotes, desta forma, mesmo que o Gateway

aceite as conexões pela porta TCP, só será possível se comunicar com os dispositivosseguindo a estrutura descrita no documento. O Gateway envia um pacote de confirmaçãopara cada requisição válida feita pelo cliente. A porta TCP padrão para comunicação coma rede ISA100.11a é a 4902. A estrutura padrão dos pacotes é descrita na Figura 4.2abaixo.

Figura 4.2: Formato geral do pacote GSAP

Todos os pacotes tem tamanho de cabeçalho fixo e tamanho variável no campo dedados. O cabeçalho e campo de dados são protegidos, cada um, por um checksum CRC-32C. Caso o campo de dados seja vazio, o checksum não é usado, porém para o cabeçalhodeve ser sempre calculado. Isso é usado para prevenir que erros de transmissão alcancea rede ISA100.11a. Se algum erro de CRC for detectado a conexão TCP é fechada,forçando a ressincronização entre os dois hosts (Gateway e Aplicação Cliente). Isso tornao padrão confiável.

O campo de dados do pacote padrão tem relação direta com o tipo de serviço, depen-dendo do tipo de serviço esse campo muda de tamanho e deve incluir argumentos únicosde cada serviço. A Tabela 4.1 apresenta todos os serviços disponíveis na especificaçãoGSAP, bem como os sub-tipos de serviços de cada um, se existir. Para cada serviço estáassociado um valor em byte correspondente único, esse deve ser informado no camposervice type do cabeçalho padrão.


Serviço Sub-tipo do serviço

Session -

Lease -

Device List Report -

Topology Report -

Schedule Report -

Device Health Report -

Neighbor Health Report -

Network Health Report -

Time -

Client/Server -

Publish/Subscribe Publish / Subscribe / Publish Timer / SubscribeTimer / Watchdog Timer

Bulk Transfer Open / Transfer / Close

Alert Subscribe / Notify

Gateway Configuration Read / Writer

Device Configuration Read / Writer

Contract List Report -

Network Resource Report -

Tabela 4.1: Tipos de Serviço


No Driver é implementado alguns desses serviços os quais chamamos de comandosno contexto da ferramenta. Através disso é possível obter dados da rede ISA100.11a,apenas seguindo a estrutura dos pacotes estabelecido por cada serviço. Para cada serviçoexiste um pacote de requisição e outro de confirmação. Isso acontece também para os sub-tipos de cada serviço. Em alguns existe também um pacote de indicação, porém esses nãosão explorados atualmente no Driver.

4.4 Comunicação com Dispositivos ISA100.11a

Este driver permite o monitoramento e gerenciamento de redes ISA100.11a, isso foipossível com a implementação de alguns comandos necessários para a comunicação, de-finidos pelo protocolo GSAP. O driver foi projetado para fazer parte do BR-Colector,ou seja, os comando implementados fazem parte de chamadas padrões desta ferramenta.Assim, a nova arquitetura de comunicação proposta é demonstrada na Figura 4.3 com odriver ISA fazendo parte da arquitetura do BR-Collector.

Figura 4.3: Nova arquitetura proposta

Internamente ao driver, a comunicação com os dispositivos acontece da seguinte ma-neira: A aplicação cliente faz uma chamada ao Driver para se conectar com a rede, in-forma o ip do gateway e abre uma conexão na porta 4902. Porém, como informado antes,apenas com a conexão aberta não conseguimos extrair nada da rede, é preciso abrir umasessão (serviço GSAP) e a partir daí executar os comandos presentes no Driver. O Ga-teway não responderá a nenhum comando caso a sessão não esteja criada. É possível quevários clientes se conectem ao gateway, porém não temos a informação sobre o limite deconexões, consideramos que "muitas"conexões podem ser feitas.

Essa sessão pode durar tempo indeterminado, de acordo com a Documentação GSAP,é possível configurar esse tempo. O driver já cria essa sessão com tempo ilimitado au-


tomaticamente utilizando o comando Create Session. Ao conectar-se com Gateway aaplicação cliente já poderá executar os comandos implementados livremente pois o co-mando citado já foi executado na chamada principal do driver. Porém nada impede queseja configurado com tempo limitado.

A Figura 4.4 descreve os passos realizados para comunicação. Utilizamos o tempoilimitado pois existe outro comando que faz o papel de fechar a conexão chamado closed

Session. Uma observação importante a se fazer é que caso a conexão TCP por algummotivo tenha fechado, a sessão criada é deletada pelo gateway, sendo necessário umanova ressincronização com o gateway. Esse comando será melhor descrito na próximaseção 4.5.

Figura 4.4: Passos para a comunicação com o dispositivos ISA100.11a

Uma visão mais geral da comunicação é demonstrada na Figura 4.5. As aplicaçõessolicitam ao BR-Collector dados das redes ISA e esse por sua vez requisita ao driver

que executa os comandos necessários, retornando os dados solicitados. Esse canal ficaaberto até que o cliente feche a conexão ou simplesmente encerre a sessão com o driver

ISA, afinal com o BR-Collector o usuário pode ter acesso a outros tipos de rede, comopresentes na sua arquitetura atual.


Figura 4.5: Passos para a comunicação com os’ dispositivos ISA100.11a

4.5 Implementação e Comandos Implementados

Cada serviço descrito na Tabela 4.1 é considerado no contexto deste driver como umcomando. Essa abordagem se torna semelhante ao padrão WirelessHart de comunicação[IEC 2010]. A implementação dos comandos segue um padrão comum de algoritmo,bem simples e intuitivo. O modelo deste algoritmo é descrito pelo diagrama de blocos naFigura 4.6.

Ao receber a chamada de um comando, o algoritmo monta o pacote de acordo como tipo de serviço envia pra o gateway e fica esperando a resposta. Caso nenhum pacotede confirmação seja retornado, uma exceção é lançada com erro de timeout. Ao recebera confirmação ainda é necessário verificar o campo de status presente no pacote, geral-mente no início do campo de dados, que define se a solicitação foi com sucesso ou não,identificando o motivo.

Dependendo do tipo de serviço a quantidade de status possíveis pode mudar e o signi-ficado também. Muitos deles estão descritos na norma ISA100.11a e não na documenta-ção GSAP. Como exemplo, no serviço de session o status presente no pacote de confirma-ção pode assumir 5 tipos diferentes de informação segundo a Norma ISA100.11a, dife-rente do serviço de device list report que são 2, isso é apresentado na Tabela 4.2[ISA100


2009].

Session Device ListReport

0-Sucess, new session created, renewed or delete 0-Sucess

1-Sucess, new session created or or renewed with reduced period 1-Failure

2-Failure, session does not exist to renewed or deleted -

3-Failure, session cannot be created -

4-Failure, other -

Tabela 4.2: Status possíveis para o serviço de session e device list report

O pacote recebido contêm os dados solicitados estruturado de maneira organizadaproposta pela GSAP, porém ainda continuam como um array de bytes, inicialmente semnenhum significado ao usuário que não conhece a documentação. Assim, o algoritmoorganiza esses dados de forma que toda informação presente no pacote seja traduzida eencapsulada em um objeto, esse, sendo retornado para o usuário.

Figura 4.6: Algoritmo padrão de implementação dos comandos


Esse algoritmo pode sofrer algumas modificação dependendo do tipo de serviço, emalguns casos ele precisa requisitar outros serviços internamente para retornar a respostadesejada como por exemplo quando precisamos da variável de processo de algum instru-mento ou número de dias restante da bateria. Essas mudanças são percebidas a medidaque informamos a função de cada comando.

Comandos Implementados

Os comandos implementados são descritos a seguir. Cada comando é exemplificadode maneira geral abstraindo a parte comunicação e montagem de pacotes, demonstrandoa função geral do comando.

• Create Session: Esse é o primeiro comando a ser executado pelo driver. Utiliza oserviço de session da documentação GSAP que é usado pelo gateway para gerenciartodos os recursos de comunicação ISA100.11a associados a um cliente de gateway

específico.• Close Session: É reponsável por fechar a sessão. Utiliza o mesmo serviço de ses-

sion alterando algumas configurações para que sessão seja deletada. Se a comuni-cação TCP for fechada ele não é executado, porém todas as sessões são deletadasautomaticamente.

• get Device List Report: Utiliza o serviço de device list report. Esse comando re-torna a lista de dispositivos presentes na rede ISA100.11a. Além disso, exibe umrelatório completo de cada dispositivo, informando os seguintes dados: revisão, tag

do dispositivo, número serial, endereço IPV4 e IPV6, nível de bateria (em porcenta-gem), tipo de dispositivo (gateway, backbone, dispositivo roteador, dispositivo I/Oetc), fabricante, modelo e número de série.

• get Topology Report: O objetivo deste comando é informar como os dispositivosestão conectados na rede, fornece um relatório da topologia que relaciona os dispo-sitivos dentro da malha sem fios. Utiliza-se do serviço topology report para acessarinformações. As informações capturadas neste comando são: lista de dispositivos ecom quem ele esta conectado, quais dos dispositivos tem o clocksource de referên-cia, secundário ou não etc.

• get Schedule Report: fornece um relatório de slots de tempo ou de alocações decanal em uma base por dispositivo. Utiliza o serviço de Schedule Report. Comesse comando é possível acessar diversas informações, sobre canal de comunicação,links entre os dipositivos, superframe etc.


• get Device Health Report: Pretende-se com esse comando obter um relatório sobrea saúde dos dispositivos na rede. Ele utiliza o serviço de Device Health que forneceum relatório sobre a "saúde"da comunicação para cada dispositivo. Dados comopacotes (DPDUs) transmitidos, pacotes perdidos, falhas de transmissão podem ob-tidos através desse comando.

• get Neighbor Health Report: Semelhante ao get Device Heal Report esse comandotem como objetivo informa a saúde do vizinho de cada dispositivo. Esse comandoinforma alguns novos dados como força do sinal, qualidade do sinal, status do linkde comunicação entre outros.

• get Network Health Report: Tem o mesmo objetivo do comando acima, porémapresenta novas variáveis com relação a saúde da rede. Por exemplo joinCount,que representa o total da contagem de Joins desde que o gerenciador de sistema foiiniciado, incluindo os dispositivos que não estão atualmente na rede. Além disso,oferece também os tipos da redes, latência entre outros.

• get Process Variable: Ele é responsável por capturar a variável de processo medida.Esse comando utiliza-se do serviço de lease. Esse serviço é dos mais importantesda especificação pois é responsável por estabelecer uma conexão entre o gateway eum recurso específico de um dispositivo de campo, ou seja, a partir desse comandoé possível ter acesso direto aos dispositivos e obter inúmeros atributos, como porexemplo, quantidade de dias que faltam para a bateria descarregar, variável de pro-cesso, entre outros. Os atributos acessíveis estão descrito nos manuais de cadadispositivo. Além disso, é possível escrever nos dispositivos, porém isso se faz emconjunto com outro serviço, o subscriber. No caso deste comando, por default aoabrir o lease a variável de processo já começa a ser publicada então não é precisousar o subscriber. Uma observação importante é que caso não precise esta conec-tado diretamente a um dispositivo é necessário que o lease seja deletado, se não orecursos alocados por ele antes não serão deletados simplesmente fechando a ses-são ou fechando a comunicação. Isso pode ocasionar problemas de memória nogateway. O driver já se responsabiliza por isso. Neste comando, após capturar aPV, o lease é deletado.

Capítulo 5

Resultados

Este capítulo tem como objetivo descrever os resultados obtidos com o desenvolvi-mento do driver de comunicação. Será descrito algumas ferramentas desenvolvidas eaplicações que tornaram-se possíveis baseadas no presente trabalho.

5.1 Software de Teste

Durante o desenvolvimento do driver, antes da implementação dos comandos, foi ne-cessário testar cada tipo de serviço da especificação GSAP, testar os pacotes de requisiçãoe as respostas obtidas de cada requisição válida. Para isso foi desenvolvido um softwarepara realizar esses testes de forma rápida e prática, de modo agilizar o desenvolvimentodo trabalho proposto.

Figura 5.1: Software de teste da especificação GSAP

CAPÍTULO 5. RESULTADOS 31

A Figura 5.1 descreve a interface implementada durante o projeto. A ferramenta ape-sar de ser bastante simples teve uma parcela importante de contribuição no trabalho.

Um exemplo da utilização deste software é descrito na Figura 5.2, onde o serviçotestado é o device list report da especificação GSAP. Ele lista todos os dispositivos darede, bem como, outras informações já mencionadas neste trabalho. Porém, o que osoftware exibe é apenas o pacote de confirmação e o da requisição, ou seja, dois arrays

de bytes. Esses arrays de bytes eram posteriormente analisados afim de proporcionarrobustez ao driver de comunicação, testando diversas possibilidade de configuração dospacotes de requisição e resposta GSAP.

Figura 5.2: Teste serviço device list report

5.2 BR-WirelessExpert

O BR-WirelessExpert é uma ferramenta Web de monitoramento de ativos de redesindustriais, em especial as redes ISA100.11a e WirelessHart. O seu principal objetivo éfornecer informações sobre redes industriais sem fio tanto para operadores quanto paraprojetistas, permitindo o desenvolvimento de aplicações industriais tolerantes a falhas emanutenção do sistema de forma mais eficiente e rápida. Ele foi desenvolvido durante oprojeto e utiliza o driver para se comunicar e obter informações da rede ISA100.11a. Ainterface é descrita na Figura 5.3, bem como alguns dados obtidos da rede num instantede tempo qualquer.

Na Figura 5.4 abaixo, de posse de informações sobre a topologia requisitados ao driver


Figura 5.3: Interface web BR-WirelessExpert

de comunicação, a imagem descreve a organização da rede formada no instante de temporequisitado. São exibidos todos os dispositivos com seus respectivos identificadores, bemcomo os links que existem entre os dispositivos da rede ISA100.11a.

Figura 5.4: Organização da rede isa

5.3 Aplicação de Controle

Aplicações de controle são muito comuns no ambiente industrial e inúmeras variáveispodem ser controladas tais como pressão, temperatura, etc. A aplicação sugerida temcomo objetivo controlar o nível de um determinado tanque. Ela comunica-se com a redeISA100.11a usando o Driver. Uma visão geral da proposta é apresentada na Figura 5.5.O Driver permite a leitura da pressão medida pelo dispositivo industrial, bem com a


escrita do valor calculado pelo controle em outro dispositivo, fechando assim a malha decontrole.

Figura 5.5: Cenário com os instrumentos

Com isso foi observado o comportamento da planta (o tanque) utilizando o controladorcom tempo de 4s e os resultados apresentados estão descritos na Figura 5.6.

Figura 5.6: Controlador com tempo de 4 segundos

Para isso foi utilizado um controlador PID com constantes kp, ki e kd com os seguintesvalores descritos na Tabela 5.1 abaixo:


Kp Ki Kd

0.0100 0.0010 0.0000

Tabela 5.1: Kp, Ki e Kd para o teste de 4s

Como a constante Kd é 0, o controlador usado se transforma em um PI, com apenas aação integrativa atuando. Vários outros equipamentos foram utilizados e testes realizados,porém como não é foco do capítulo não foram exemplificados. No entanto, fazendo umaanálise breve de acordo com a Figura 5.6, pode-se observar que o controle estabilizou onível do tanque no set point desejado, em tempo relativamente aceitável.

5.4 Considerações Finais

A inserção das tecnologias de comunicação sem fio tem proporcionado a criação denovas aplicações em ambientes industriais. Esse capítulo de certa forma apresentou oquanto de possibilidades foram abertas para o estudo de redes sem fio industriais e tam-bém o quanto o driver teve papel importante para viabilizar estes resultados.

Capítulo 6

Conclusão e Trabalhos Futuros

Atualmente a comunicação sem fio vem se tornando uma tendência no âmbito indus-trial. As novas tecnologias de comunicação sem fio criam um cenário motivador paracriação de novas aplicações. Apesar dos vários benefícios frente ao padrão com cabos,os desafios encontrados como confiabilidade, coexistência com outras redes, conservado-rismo da indústria, se apresentam como entraves para implantação desse novo paradigma.

No entanto, alguns protocolos estão surgindo com soluções para esses problemas. Aespecificação ISA100.11a surge como uma boa solução, isso devido, ao protocolo ter sidocriado com base nas necessidades dos usuários finais. Esse protocolo implementa técnicasque procuram acabar com as desconfianças desse novo paradigma.

Com o objetivo de difundir as tecnologias sem fio em ambiente industrial foi desen-volvido neste trabalho um driver de comunicação com redes que utilizam o protocoloISA100.11a. Os resultados demonstraram que o driver possibilitou a criação de novasferramentas e aplicações, alcançando assim o objetivo proposto. Além disso, o referidotrabalho possibilita a análise da rede em tempo-real, proporcionando maior flexibilidadede análise dos dados coletados.

Trabalhos Futuros

Como trabalhos futuros pretende-se aprimorar o driver ISA100.11a com a implemen-tação de novos comandos e tratamento de erros. Desenvolver novas ferramentas paraanálise das redes, bem como a criação de KPIs (Key Performance Indicator) para avalia-ção do nível de desempenho das redes.

As próximas atividades estão listadas a seguir:

• Revisão dos métodos de comunicação síncrona do driver ISA100.11a vim BR-Collector.

• Implementação dos métodos para comunicação assíncrona através do driver ISA100.11avia BR-Collector.

CAPÍTULO 6. CONCLUSÃO E TRABALHOS FUTUROS 36

• Comparação de desempenho entre os controladores para redes WirelessHART eISA100.11a.

• Análise dos dados coletados afim de criar métricas, bem como KPIs de avaliaçãodas redes ISA100.11a e analogamente para redes WirelessHart.

Referências Bibliográficas

Bai, H. & M. Atiquzzaman (2003), ‘Error modeling schemes for fading channels in wire-less communications: A survey’, Communications Surveys Tutorials, IEEE 2(5), 2–9.

Chang, K.-D. & J.-L. Chen (2012), ‘A survey of trust management in wsns, internet ofthings and future internet’, KSII Transactions on Internet and Information Systems

6(1), 5–23.

Eris, C., M. Saimler & C. Gungor (2013), ‘Lifetime analysis of wireless sensor nodes indifferent smart grid environments’, Sensors 13(1), 1–11.

Gungor, V. C. & G.P. Hancke (2009), ‘Industrial wireless sensor networks: Challenges,design principles, and technical approaches’, Industrial Electronics, IEEE Transac-

tions on 56(10), 4258–4265.

Han, Song, Xiuming Zhu, Mok A.K., Chen Deji & Nixon M. (2011), Reliable and real-time communication in industrial wireless mesh networks, Real-Time and Embed-ded Technology and Applications Symposium (RTAS), 2011 17th IEEE, pp. 3–12.

IEC (2010), ‘Iec 62591: Industrial communication networks wireless communicationnetwork and communication profiles wirelesshart’.

ISA100 (2009), ‘Isa100 (2009), isa100.11a - wireless systems for industrial automation:Process controland related applications, isa standards.’.

JSON (1999), ‘Ecma-404 the json data interchange standard.’.URL: json.org

Lessard, A. & M. Gerla (1988), ‘Wireless communications in the automated factory en-vironment’, Network, IEEE 2(3), 64–69.

Machado, Rivaldo (2014), Desenvolvimento de um middleware para comunicação viaweb services e sua aplicação em sistemas de aquisição de dados industriais., Disser-tação de Mestrado.

37

json.org

REFERÊNCIAS BIBLIOGRÁFICAS 38

Neves, P.A.C.S. & J.J.P.C. Rodrigues (2010), ‘Internet protocol over wireless sensornetworks, from myth to reality’, Journal of Communications 5(3), 189–196.

NIVIS (2010), ‘Isa100.11a integration kit r2, nivis, inc.’.

Petersenand, Stig & Simon Carlsen (2011), A survey of wireless sensor networks forindustrial applications, CRC Press, capítulo 12, pp. 1–10.

Sauter, T. (2005), Fieldbus systems - history and evolution, em R.Zurawski, ed., ‘TheIndustrial Communication Technology Handbook’, CRC Press, capítulo 7.

Yamamoto, Shuji, Naoki Maeda, Makoto Takeuchi & Masaaki Yonezawa (2010), ‘Worldsfirst wireless field instruments based on isa100.11a, relatório técnico 2, ia foundationtechnology center.’, 53.

YOKOGAWA (1915), ‘Yokogawa electric corporation’.URL: http://www.yokogawa.com.br/

Zand, Pouria, Chatterjea Supriyo, Das Kallol & Havinga Paul (2012), ‘Wireless industrialmonitoring and control networks: The journey so far and the road ahead’, Journal

of Sensor and Actuator Networks 1(2), 123–152.URL: http://www.mdpi.com/2224-2708/1/2/123

http://www.yokogawa.com.br/

http://www.mdpi.com/2224-2708/1/2/123

Desenvolvimento de um Driver de Comunicação para Coleta de ... · da UFRN como parte dos...

Documents

Transcript of Desenvolvimento de um Driver de Comunicação para Coleta de ... · da UFRN como parte dos...