Gateway ZigBee

(1)

Faculdade de Engenharia da Universidade do Porto

Mestrado Integrado em Engenharia

Orientador:

i

Faculdade de Engenharia da Universidade do Porto

Gateway ZigBee - Modbus/TCP

Pedro Miguel Carvalho Pereira

Dissertação realizado no âmbito do

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Major Automação

Orientador: Paulo José Lopes Machado Portugal

Junho de 2009

Faculdade de Engenharia da Universidade do Porto

Modbus/TCP

Electrotécnica e de Computadores

(2)

(3)

(4)

iii

Resumo

Actualmente as redes de sensores sem fios apresentam uma expansão significativa devido a terem sido superadas algumas das dificuldades iniciais no momento do seu aparecimento. Dificuldades como a fiabilidade na transmissão das mensagens, aumento da longevidade da bateria e custo elevado foram resolvidas abrindo portas para mercados com maiores exigências como a indústria ou aplicações médicas.

Este trabalho apresenta uma solução tecnológica para integrar as redes sem fios com as redes de campo já existentes, tendo como propósito criar uma estrutura capaz de fazer a ligação entre o protocolo ZigBee e o Modbus. Esta estrutura é capaz de pertencer adequadamente aos dois protocolos expandindo uma rede Modbus e tornando possível o acesso aos dispositivos sem fios através da rede cablada.

A implementação de uma gateway entre as duas redes possibilita a conectividade pretendida mantendo a estrutura sem necessidade de alterações em nenhuma das redes. Este ponto é essencial pois só assim é possível uma interactividade completa respeitando a integridade de ambos os protocolos, indispensável para obter uma utilização fiável em aplicações industriais, onde por vezes existem mais do que um tipo de dispositivos a funcionar cooperativamente.

Para além da descrição dos aspectos técnicos ligados à implementação é feita uma exposição sobre a arquitectura que a gateway deve ter para permitir o bom funcionamento da rede. Toda a estrutura desta dissertação e consequente implementação teve como objectivo a gateway pertencer a uma rede com um único cliente de Modbus, podendo existir ou não mais servidores de Modbus. Esta gateway tem de ser capaz de, para além de gerir a rede ZigBee, de responder aos pedidos do clientes Modbus.

(5)

(6)

v

Abstract

Nowadays, the wireless sensor networks are growing significantly mainly because the initial difficulties were all ready overcome, like the transmission´s reliance of the messages, the low capacity of the battery and the high cost of the wireless technology itself. These facts allowed the entrance of the wireless technology in hard markets, like industry and medical markets.

This work presents a technologic solution to integrate a wireless sensor network with previous implanted field networks and the aim of this work is to create a framework that is able to establish a connection between the ZigBee and the Modbus protocols. This framework is also able to belong correctly to the two networks and therefore to expand the Modbus network, making possible the access to the ZigBee nodes through the wired network.

The gateway´s implementation provides the desired connection keeping the framework of the two protocols.

This point is one of the most important because only that way, it is possible to ensure the integrity of the protocol and the full connection with all networks which is indispensable in an industrial environment.

Beside the technical issues of the implementation, a general overview of the architecture of the gateway is presented in order to guarantee the correct operation of the entire network. The framework and the consequent implementation had the single propose that gateway would belong in a network with only a Modbus client.

(7)

(8)

vii

Agradecimentos

Ao meu orientador, professor Paulo Portugal, pela paciência teve comigo, pelas suas palavras motivadoras e pelos seus esforços feitos no decorrer desta dissertação.

Aos meus pais por todos os momentos em que me ajudaram. Aos meus amigos por todas as noites passadas em conjunto.

À Cristina pelos incontáveis dias adiados sempre com um toque paciência e pronta para me ajudar.

(9)

(10)

ix

Índice

Resumo ... iii

Abstract ... v

Agradecimentos ... vii

Índice ... ix

Lista de figuras ... xi

Lista de tabelas ... xiii

Abreviaturas e Símbolos ... xv

Capítulo 1 ... 1

Introdução ... 1 1.1 - _{Enquadramento ... 1} 1.2 - _{Objectivos ... 2} 1.3 - _{Metodologia ... 2} 1.4 - _{Estrutura da dissertação ... 3}

Capítulo 2 ... 5

Tecnologias e Conceitos Associados ... 5

2.1 - _{Redes de sensores sem fios ... 5}

2.2 - _{A importância de uma gateway ... 6}

2.3 - _{Modbus ... 6}

2.3.1. Estrutura das mensagens ... 7

2.3.2. Excepções ... 10

2.4 - _{ZigBee ... 11}

2.4.1. Dispositivos presentes numa rede ZigBee ... 11

2.4.2. Topologia da rede ... 12

2.4.3. Formato das frames ... 13

2.4.4. Arquitectura do ZigBee ... 14

2.4.5. Primitivas ... 16

2.4.6. “Binding”... 17

2.4.7. Exemplos de aplicações ZigBee ... 18

Capítulo 3 ... 19

(11)

3.1 - _{Descrição ... 19} 3.2 - _{A arquitectura da gateway ... 21} 3.3 - _{Mapeamento de funções ... 30} 3.4 - _{Hardware ... 31}

Capítulo 4 ... 33

Implementação ... 33 4.1 - _{Hardware utilizado ... 33} 4.2 - _{Picdem Z ... 34} 4.3 - _{Xport ... 35} 4.4 - _{Software utilizado ... 37} 4.4.1. A “stack” da Microchip ... 38 4.4.2. Zena ... 38 4.5 - _{Trabalho desenvolvido ... 40}

4.5.1. Máquina de estados de ZigBee ... 42

4.5.2. Máquina de estados de Modbus ... 44

4.5.3. Interacção entre os dois protocolos ... 45

4.5.4. Configurações ... 46

4.5.5. Integração com o programa da Microchip ... 51

4.5.6. Dificuldades encontradas ... 53

Capítulo 5 ... 55

Conclusões e Trabalho Futuro ... 55

5.1 - _{Conclusões ... 55}

5.2 - _{Trabalho futuro ... 56}

(12)

xi

Lista de figuras

Figura 1 - Estrutura típica de uma mensagem de Modbus TCP ... 7

Figura 2 - Gama de "function codes" do protocolo ... 8

Figura 3 - Envio de mensagem sem erro de recepção adaptado de [5]. ... 8

Figura 4 - Envio de mensagem com erro de recepção adaptado de [5]. ... 9

Figura 5 - Esquema de uma transição do lado do servidor adaptado de [5]. ... 10

Figura 6 - Rede ZigBee em estrela ... 13

Figura 7 - Rede ZigBee em "cluster" ... 13

Figura 8 - Rede ZigBee emalhada ... 13

Figura 9 - Frame de dados do protocolo ZigBee ... 14

Figura 10 - Esquema da “stack” de ZigBee ... 15

Figura 11 - interacção entre camadas [9]. ... 16

Figura 12 - Exemplo de "binding" adaptado de [10]. ... 17

Figura 13 - Exemplo de aplicações ZigBee no campo da domótica adaptado de [12]. ... 18

Figura 14 - Estrutura da rede. ... 20

Figura 15 - Estrutura da gateway (vista global). ... 22

Figura 16 - Pormenor da gateway. ... 23

Figura 17 - Junção de um nó á rede. ... 25

Figura 18 - Esquema de uma recepção de mensagem de leitura desde o cliente até à gateway. ... 26

Figura 19 - Esquema de recepção de uma mensagem de escrita e subsquente envio para o nó respectivo ... 27

(13)

Figura 21 -Estrutura básica da gateway adaptado de [17] ... 31

Figura 22 - Nó de desenvolvimento do Picdem Z... 34

Figura 23 – Xport ... 35

Figura 24 - Arquitectura interna do Xport. ... 36

Figura 25 - Página de configurações da porta série do XPort ... 37

Figura 26 - Painel de configurações do software Zena. ... 39

Figura 27 - Modo de visualização das mensagens ZigBee. ... 39

Figura 28 - Estrutura de leitura de um registo do tipo holding adaptado de [5]. ... 41

Figura 29 - Estrutura de funcionamento da gateway. ... 42

Figura 30 - Estrutura da máquina estados ZigBee. ... 43

Figura 31 - Estrutura de um servidor de Modbus adaptado de [5]. ... 44

Figura 32 - Menu de configurações com opção genérica. ... 47

Figura 33 - Estrutura da opção para acrescentar um nó. ... 48

Figura 34 - Estrutura da opção para alterar as configurações de cada nó. ... 49

Figura 35 - Estrutura da opção para eliminar um nó da gateway. ... 50

Figura 36 - Estrutura da opção para listar os nós. ... 50

Figura 37 - Inclusão do programa principal no código do coordenador ZigBee ... 51

Figura 38 - inserir um nó na tabela de endereçamento... 51

Figura 39 - Recepção de uma mensagem via Modbus. ... 52

Figura 40 - Actualização da tabela de endereçamentos. ... 52

Figura 41 - Actualização automática das entradas dos nós. ... 52

(14)

xiii

Lista de tabelas

Tabela 1 - Exemplo das funções mais comuns do protocolo Modbus ... 7

Tabela 2 - Tabela de endereçamento conceitual. ... 24

Tabela 3 - Recepção de uma trama com um "function code" não implementado. ... 25

Tabela 4 - Envio de uma trama de resposta a um "function code" não implementado. ... 26

Tabela 5 - Trama de leitura de um registo enviada pela cliente Modbus. ... 26

Tabela 6 - Envio da resposta à trama de leitura de um registo enviada pela cliente Modbus. ... 27

Tabela 7 - Envio, pelo cliente Modbus, de um pedido de escrita num registo. ... 27

Tabela 8 - Envio da trama ZigBee para escrever na saída correspondente. ... 28

Tabela 9 - Confirmação que a mensagem foi enviada com sucesso. ... 28

Tabela 10 - Envio, para o cliente Modbus, da confirmação da escrita no registo pedido... 28

Tabela 11 – Envio de uma trama para o cliente Modbus, caso não exista confirmação de envio. ... 28

Tabela 12 - Envio de trama ZigBee de forma a ler todas as entradas e saídas presentes no nó ZigBee. ... 29

Tabela 13 - Envio da resposta por parte do nó ZigBee. ... 29

Tabela 14 - Tabela de endereçamentos. ... 46

(15)

(16)

xv

Abreviaturas e Símbolos

Lista de abreviaturas

APL Application layer APO Application object

APS Application support sub-layer

APSDE Application support sub-layer data entity

FFD Full function device

IP Internet Protocol

MAC Medium access control

NWK Network layer

OSI Open Systems Interconnection PHY Physical layer

SAP Service access point

RFD Reduced function device RSSF Redes de sensores sem fios ZED ZigBee end device

ZDO ZigBee device object

(17)

(18)

1

Capítulo 1

Introdução

Este capítulo faz uma pequena introdução à temática na qual se insere o trabalho. São ainda referidos os objectivos bem como a metodologia utilizada na abordagem do mesmo. No final, são enumerados os assuntos abordados em cada capítulo.

1.1 -

_{Enquadramento}

O desenvolvimento actual das redes sem fios permite a produção de nós de sensores cada vez mais pequenos, fiáveis e autónomos facilitando a sua integração em campos onde a sua utilização não era permitida anteriormente.

Estes pequenos dispositivos têm vindo a abranger áreas como a vigilância e a domótica onde se têm revelado extremamente capazes devido à flexibilidade e capacidade de se organizarem de forma a reencaminhar mensagens para os vários destinos apesar do seu curto alcance.

O “boom” desta tecnologia originou o aparecimento de redes como o ZigBee, que alia a flexibilidade ao baixo consumo dos seus dispositivos tornando-a assim uma tecnologia interessante quando se tratam de redes com muitos nós e uma taxa de transferência baixa.

Existem já um sem número de aplicações deste género apesar da sua curta existência. Com o crescimento desta tecnologia e com o aumento da sua segurança e fiabilidade, as redes de sensores sem fios começaram a surgir em áreas que até então não eram sequer consideradas. A indústria, nas suas variadas vertentes, é uma dessas áreas, existindo hoje em dia já bastantes aplicações. No entanto existe a dificuldade de integrar dois sistemas tão distintos como as redes de campo que surgiram antes da década de 80 e as redes sem fios mais actuais. É neste campo que se insere o projecto tentando facilitar a integração das

(19)

2 Introdução redes sem fios de curto alcance em ambientes de natureza industrial de forma a diminuir os custos de implementação destas bem como acrescentar outras vantagens de operabilidade com novas redes de sensores.

1.2 -

_Objectivos

A necessidade de uma interface que concilie uma rede sem fios e uma rede de campo é uma mais-valia considerável principalmente no domínio das redes sem fios facilitando a sua integração em áreas industriais. Se nesta integração for utilizada uma rede de campo com grande aceitação no mercado quer a gateway, o trabalho aqui apresentado, quer a rede sem fios em questão saem beneficiadas.

Este trabalho propõe-se desenvolver uma gateway que permita interligar uma rede ZigBee a uma rede que suporte o protocolo Modbus/TCP respeitando os dois protocolos e criando um meio no qual os dois possam trocar informação. A gateway tem também de condicionar o acesso dos nós ZigBee à rede, impedindo assim ligações de nós que não tenham significado no contexto da rede Modbus/TCP. Este trabalho tem também por objectivo permitir o acesso de um dispositivo Modbus/TCP às entradas e saídas desses mesmos nós presentes na rede ZigBee.

1.3 -

_Metodologia

A metodologia deste trabalho consistiu em:

• Conhecer os protocolos necessários para a realização deste trabalho bem como o tipo de perfis que cada um implementa de forma a ser possível estruturar uma gateway onde os dois protocolos podem interagir entre si.

• Efectuar um levantamento das escolhas possíveis para o hardware necessário para a implementação e desenvolvimento da gateway.

• Implementar a gateway garantindo um fluxo organizado de informação do cliente Modbus para os nós ZigBee criando uma rede com uma topologia do tipo cliente/servidor através de TCP/IP.

• Disponibilizar a informação dos nós ZigBee na gateway para que esta possa ser acedida pelo cliente Modbus/TCP.

(20)

Estrutura da dissertação 3 • Criar uma estrutura flexível de modo a que seja possível adicionar ou remover um nó

ZigBee garantindo, no caso de um nó não estar presente na rede que o cliente Modbus é informado dessa situação.

1.4 -

_{Estrutura da dissertação}

Esta dissertação encontra-se dividida em 5 capítulos.

O primeiro capítulo apresenta o problema e os objectivos deste trabalho bem como a metodologia utilizada para o resolver e por fim é efectuada uma visão sobre a estrutura de todo o documento.

O segundo capítulo é dedicado aos conceitos teóricos associados a este trabalho começando com uma introdução sobre redes sem fios, também denominadas por redes de sensores sem fios. De seguida existe uma interpretação sobre a gateway, o seu papel na rede e a sua importância no contexto do problema. Para finalizar apresentam-se os protocolos usados durante a implementação do trabalho e alguns dos seus pormenores mais importantes. O terceiro capítulo é todo ele dedicado à arquitectura da gateway definida neste trabalho descrevendo como a gateway se deve organizar para obter uma interacção correcta entre os dois protocolos mapeando os diferentes dispositivos de cada um deles, disponibilizando um intercâmbio de serviços para a unidade responsável por gerir a rede Modbus.

O quarto capítulo começa com uma apresentação dos aspectos mais relevantes do hardware e do software utilizado, terminando com a exposição do trabalho implementado e as principais dificuldades encontradas durante o seu desenvolvimento. A apresentação do trabalho é maioritariamente composta por diagramas representativos da estrutura do código desenvolvido facilitando a sua compreensão.

O quinto capítulo está reservado para as conclusões do trabalho fazendo-se uma retrospectiva deste e apontando sugestões para o trabalho futuro que possa melhorar a gateway.

(21)

(22)

5

Capítulo 2

Tecnologias e Conceitos Associados

Neste capítulo são apresentados os conceitos relevantes no desenvolvimento deste trabalho.

Nesse sentido é feita uma breve referência às redes de sensores sem fios de forma a enquadrar o projecto e posteriormente, ao conceito de gateway, e qual o seu papel numa rede de comunicações. No final são apresentados os protocolos de Modbus e ZigBee.

2.1 -

_{Redes de sensores sem fios}

As redes de sensores sem fios (ou rssf) têm vindo a assumir uma importância crescente no nosso mundo, envolvendo cada vez mais áreas de aplicação.

O seu baixo custo, flexibilidade e baixo consumo de cada elemento da rede tornam-na ideal para as necessidades do mundo actual. Assim, em contra partida com as redes tradicionais, por fios, as redes de sensores sem fios não necessitam de um planeamento tão exigente para a sua disposição física apresentando ainda a vantagem da substituição, em caso de avaria, de um elemento da rede estar simplificada devido à ausência de fios.

Estas redes têm vindo a suscitar interesse em ramos como a indústria automóvel, a têxtil, a ferroviária [1] existindo inclusivamente aplicações médicas utilizando este tipo de redes.

A nível das aplicações não industriais a domótica destaca-se, existindo um vasto número de aplicações com este tipo de redes [2].

O crescente número de aplicações deve-se ao facto de nos dias de hoje existir uma maior necessidade de interactividade com meio exterior.

Numa habitação em que tenham sido implementadas funções de domótica, esta aplicação pode interagir com os seus habitantes facilitando-lhes as tarefas do quotidiano. No entanto

(23)

6 Tecnologias e Conceitos Associados esta também pode interagir de formas mais complexas com o intuito de salvar vidas em situações que o utilizador esteja em perigo. A utilização de redes sem fios nesse campo apresenta vantagens como a flexibilidade da rede, o baixo custo e facilidade de implementação da mesma [3].

Estas vantagens são mais evidentes quando a habitação não foi projectada inicialmente para a domótica, pois devido à ausência de fios toda a remodelação necessária é reduzida ao mínimo.

2.2 -

_{A importância de uma gateway}

As redes sem fios deparam-se com o desafio da interoperabilidade com as redes campo actualmente existentes.

Uma rede sem fios apresenta vantagens inerentes à sua natureza, apesar de muitas serem intrínsecas ao protocolo implementado. Contudo, existem vantagens comuns às redes sem fios tais como a facilidade e baixo custo de implementação, a fácil reconfiguração entre outras.

De igual forma existem desvantagens como a sensibilidade a ruído electromagnético, velocidade de transmissão reduzida quando comparada com as redes com fios e a segurança, sendo esta última uma questão fundamental em redes industriais [4].

Contudo, as redes sem fios são uma opção viável para um futuro cada vez mais próximo em que substituirão grande parte das redes de campo actuais.

Este trabalho insere-se nesta área interligando uma rede bastante conhecida e de domínio industrial como o Modbus (na sua vertente TCP/IP) com uma rede mais recente e sem fios como a rede ZigBee, tendo como objectivo a criação de um dispositivo de interconectividade entre estas duas redes convertendo a informação de um protocolo para o outro.

2.3 -

_Modbus

O Modbus foi pela primeira implementado para aplicações de redes de autómatos programáveis em 1979 sendo, na altura, um protocolo proprietário da Modicon. Actualmente o protocolo é mantido pela Modicon-IDA e é um protocolo aberto e vastamente utilizado no domínio das redes de autómatos.

Em 1999 esta mesma entidade acrescentou à norma o Modbus/TCP adicionando assim uma funcionalidade ao protocolo original e adaptando-o às necessidades actuais.

(24)

Modbus 7

2.3.1. Estrutura das mensagens

O Modbus define uma arquitectura cliente/servidor em que o cliente é responsável pela organização da rede, pelo fluxo das mensagens e também pelo envio de mensagens aos servidores. Um servidor numa rede Modbus é, usualmente, um módulo de entradas e saídas.

A estrutura básica de uma mensagem de Modbus apresenta três campos distintos: o endereço de destino, o “function code” pretendido, uma gama de informação adicional que está intrinsecamente ligado com o “function code” da mensagem.

Figura 1 - Estrutura típica de uma mensagem de Modbus TCP

O “function code” é mais do que um código de dois bytes que identifica uma função que o destinatário deverá reconhecer.

Tabela 1 - Exemplo das funções mais comuns do protocolo Modbus Descrição Function code (em hexadecimal)

Ler entrada discreta 0x02

Ler saída 0x01

Escrever saída simples 0x05

Escrever saídas múltiplas 0x0F

Ler registo de entrada 0x04

Ler registo “holding” 0x03

Escrever registo simples 0x06

Escrever registos múltiplos 0x10

Ler/escrever registos múltiplos 0x17

Os function codes podem ser de três tipos:

• Funções publicas - São funções bem definidas pela norma, em que é necessário que estas cumpram a estrutura presente na norma.

• Funções definidas pelo utilizador - São funções que, como o próprio nome indica, são implementadas pelo próprio utilizador, sem que se garanta a compatibilidade entre outras podendo mesmo existir funções diferentes com o mesmo código.

(25)

8 Tecnologias e Conceitos Associados

• “Function codes” reservados - Funções actualmente utilizadas por algumas empresas e que detêm o direito exclusivo do seu uso. Como tal, não podem ser utilizadas pelo público em geral.

Figura 2 - Gama de "function codes" do protocolo

É importante referir que para além destas 127 funções, representadas na figura, existem ainda outras 127 que correspondem a diferentes incoerências presentes na mensagem recebida. Estas são denominadas por excepções onde o “function code” dessas mensagens é igual ao “function code” original, sem erro, mas com o “bit” mais significativo a 1.

Isto significa que uma função como a “0x01” enviada pelo cliente, em caso de erro na recepção no lado do servidor teria como resposta “0x81”.

Estas excepções podem ter de diferentes origens. Assim, enquanto umas resultam do facto da mensagem original tentar aceder a registos não existentes, outras devido ao facto da função pretendida não ser suportada pelo cliente em questão.

(26)

Modbus 9

Figura 4 - Envio de mensagem com erro de recepção adaptado de [5].

Na Figura 3 e na Figura 4 pode-se observar o esquema de troca de mensagens entre um cliente e um servidor Modbus, bem como a diferença entre os dois esquemas, que se deve a um erro recepção da mensagem proveniente do cliente. Uma mensagem de Modbus, em traços gerais, é composta por dois campos. O primeiro, o “function code” é responsável por chamar uma função específica do lado do servidor, existindo mais de vinte funções pré-definidas pela norma. Por exemplo, o código “0x01” especifica a função para ler o estado de uma saída do servidor e o código “0x05” serve para escrever nessa mesma variável.

O segundo campo é reservado a dados adicionais relativos à respectiva função. Este campo pode ser utilizado para enviar dados específicos a cada função ou para reportar erros de leitura na mensagem recebida por parte do servidor. Na Figura 5 é apresentado o esquema de uma transacção com as verificações necessárias, que o servidor tem que percorrer, de modo a ser garantida a integridade da mensagem recebida e posteriormente o envio de uma resposta válida.

(27)

Figura 5 - Esquema de uma transição do lado do servidor adaptado de [5].

2.3.2. Excepções

A norma de Modbus define dez códigos de excepção estando na Figura 5 representados seis deles. A seguir apresenta-se uma breve descrição de cada um deles:

• Excepção “1” - Retornado numa mensagem quando o servidor não suporta a mensagem enviada pelo cliente.

• Excepção “2” - Corresponde à tentativa de acesso a um registo que inexiste.

• Excepção “3” - Existe quando o valor presente no campo dos dados não é permitido para o servidor em questão.

• Excepção “4” - Ocorreu um erro no servidor enquanto este tentava responder ao pedido em questão.

• Excepção “5” - Significa que o servidor esta numa operação que envolve algum processamento e consequentemente algum tempo, logo esta mensagem é enviada de forma a impedir um erro de “time out” no cliente.

• Excepção “6” - Significa que o servidor esta numa operação demorada e como tal o cliente deve retransmitir a mensagem mais tarde.

• Excepção “8” - Excepção usada nas funções de leitura e escrita de um ficheiro, significando que o servidor tentou ler um ficheiro mas detectou um erro de paridade.

(28)

ZigBee 11 • Excepção “0A” - Esta excepção é apenas usada em redes em que existam gateways e significa que a gateway não consegue reencaminhar a mensagem para o destino pretendido, significando, normalmente, que esta está mal configurada ou em sobrecarga.

• Excepção “0B” - Tal como a anterior excepção, estas também são usadas em redes onde existam gateways sendo que neste caso a gateway não obtém resposta do destino pretendido, significando, habitualmente que o dispositivo não está presente na rede.

2.4 -

_ZigBee

O ZigBee é uma tecnologia relativamente recente na área das redes de sensores sem fios, apresentada em Junho de 2005. Esta tem vindo a despertar um interesse crescente em diversas áreas, desde as industriais até à domótica. O ZigBee apresenta grandes potencialidades para a sua utilização em redes que tenham como requisitos o baixo custo, o baixo consumo ou baixa taxa de transmissão. Assim sendo a rede ZigBee apresenta as seguintes características [6]:

• Baixo consumo energético - tornando possível a utilização de pequenas unidades remotas, tornando-as autónomas durante longos períodos de tempo sem que seja preciso manutenção.

• Baixo custo por nó - devido à baixa exigência do protocolo é possível implementa-lo em unidades com reduzida memória e processamento.

• Roteamento - o protocolo ZigBee permite que as mensagens, quando não exista uma rota directa para o destino, sejam reencaminhadas para o mesmo por outras unidades da rede.

• Encriptação das mensagens - utilizando um algoritmo poderoso como o AES de 128-bit.

2.4.1. Dispositivos presentes numa rede ZigBee

Os elementos da rede de ZigBee podem ser divididos em dois grupos, os “full function devices” ou FFD e os “reduced function devices” ou RFD. Os FFD, como o próprio nome indica são dispositivos que implementam toda a pilha protocolar sendo assim elementos mais complexos da rede. No entanto, são os dispositivos mais versáteis podendo funcionar como coordenador, “router” ou mesmo RFD. O segundo grupo de elementos são os RFD, que ao implementarem apenas parte da norma apresentam menores exigências por parte do hardware e como tal baixam significativamente os custos do conjunto da rede, visto que estes dispositivos são os mais numerosos.

(29)

12 Tecnologias e Conceitos Associados Coordenador - é o dispositivo que cria e gere a rede mantendo a tabela de roteamento das mensagens. Em cada rede existe apenas um dispositivo desta natureza podendo comunicar, directa ou indirectamente com todos os restantes tipos de dispositivos. Como já foi referido este dispositivo é um FFD.

“Router” - é o dispositivo que se apresenta, normalmente, entre o coordenador e os RFD's tendo como objectivo o encaminhamento de mensagens entre os mesmos. Para tal, cada “router” pode comunicar com o coordenador, outros “routers” e com os RFD's a ele associados. Isso é conseguido implementando toda a stack ZigBee nestes dispositivos, sendo estes dispositivos FFD's tal como o coordenador.

RFD - é o dispositivo mais básico da rede tendo como função o de fornecer o estado das variáveis a monitorizar, podendo apenas comunicar com o FFD ao qual está directamente ligado.

2.4.2. Topologia da rede

Uma das grandes vantagens da rede ZigBee é a versatilidade e como tal existem três topologias possíveis para estruturá-la.

O formato de ligação em estrela é apresentado na Figura 6. Neste tipo de configuração toda a rede dispõe de uma conexão directa com o nó coordenador dispensando-se assim os elementos de reencaminhamento na rede. Esta configuração é bastante utilizada em redes com poucos elementos devido à sua simplicidade e ao facto de os algoritmos necessários para a criarem serem de igual forma simples o que leva a uma menor sobrecarga no elemento coordenador.

A topologia emalhada, Figura 8, é uma das topologias mais vantajosas visto permitir ultrapassar a questão do curto alcance da rede e mesmo de obstáculos que estejam a enfraquecer o sinal.

A perda de conectividade com um “router” origina duas situações distintas. Em primeiro lugar é necessário reconfigurar as rotas de acesso a toda a rede, de seguida, e se existirem dispositivos RFD que tenham perdido ligação com a restante rede, é necessário recuperar essa conectividade. No entanto essa acção só é possível se existirem “routers” nas imediações do “router” perdido que possam aceitar esses RFD's na sua rede interna.

A topologia por “clusters” representada na Figura 7 difere da anterior visto nesta os “routers” apresentarem uma função organizativa da rede conferindo-lhe níveis de hierarquização.

Em qualquer das topologias o nó coordenador é responsável pela criação e manutenção da rede. No entanto na topologia emalhada e na topologia por “clusters” os “routers” podem adicionar novos elementos à rede.

(30)

ZigBee 13

2.4.3. Formato das frames

As frames, ou mensagens, enviadas no protocolo ZigBee podem dividir-se em quatro grupos [7]:

• Frames de dados – usada para transmitir informação;

• Frames de “acknowledge” - usada para confirmar a recepção de uma mensagem se o utilizador assim o pretender;

• Frames de “beacon” – utilizadas pelo coordenador para ajudar no sincronismo da rede diminuindo drasticamente o consumo de energia por parte dos nós;

• Frame de “MAC command” – mecanismo de controlo remoto e configuração dos nós.

(31)

Figura 6 - Frame de dados do protocolo ZigBee

Tipicamente uma frame de ZigBee tem o aspecto da Figura 6 com dois campos principais. O “APS header”, cabeçalho da mensagem, contém informação sobre o endereçamento e sobre o controlo da frame. O “APS payload” é um campo destinado à informação e pode não existir em alguns tipos de frames como por exemplo numa frame do tipo “acknowledge”.

2.4.4. Arquitectura do ZigBee

A ZigBee Alliance é a instituição que define todo o protocolo, sendo responsável pela camada de rede (NWK) e de aplicações (APS). Estas duas camadas estão implementadas em cima da camada física (PHY) e a camada de acesso ao meio (MAC) definida pela norma IEEE802.15.4 como se observa na Figura 7.

Sendo a norma IEEE 802.15.4 responsável pela definição a camada PHY e a camada MAC para redes de sensores de curto alcance com baixa taxa de transmissão conhecidas por LR-WPAN [8].

A camada física suporta três gamas de frequência distintas tornando-a assim mais flexível e dando oportunidade ao implementador de utilizar a banda com a menor interferência possível. A banda mais comum para as aplicações utiliza a banda destinada a aplicações industriais, científicas e médicas conhecida por ISM e disponibilizando 16 canais diferentes para a sua utilização. É de sublinhar que esta banda utiliza a mesma frequência que a rede Wi-Fi, podendo originar em ambientes com redes muito sobrecarregadas alguns problemas de conectividade.

As restantes gamas de frequência são a 868MHz e 915MHz estas são gamas regionais utilizadas, a primeira, em toda a Europa e a segunda nos Estados Unidos.

(32)

ZigBee 15

Figura 7 - Esquema da “stack” de ZigBee

A camada de acesso ao meio define os dois tipos de dispositivos, FFD e RFD, já referidos anteriormente. As diferenças de funcionalidades entre estes dois elementos são bem visíveis nesta camada, isto porque enquanto um FFD apresenta todas as funções possíveis da mesma um RFD apenas apresenta as funções necessárias que o permitem ligar á rede e enviar mensagens sem que consiga coordenar mensagens.

Enquanto a camada de ligação à rede identifica apenas dois tipos de dispositivos, a camada de rede cria mais uma subdivisão entre os FFD, definindo assim o conceito de coordenador e o de “router” anteriormente apresentado.

A camada de rede também é responsável pela formação da rede, endereçamentos dos nós, gestão e descoberta de novas rotas.

A camada de aplicação é composta por três sub-camadas, a “Framework Application”, a “ZigBee Device Object” (ZDO) e a “Application Sub Layer” (APS). A “Framework Application” apresenta um conjunto de “Application Objects” (APO's) capazes de mapearem os nós vizinhos e assim facilitar a interacção entre eles. O ZDO é outro dos serviços fornecidos pela camada de aplicação que tem como objectivo a descoberta de novos elementos na rede e os serviços por eles implementados. A APS é a uma sub-camada, como o próprio nome indica, responsável pelo encaminhamento de informação dos APO's e do ZDO para a camada inferior e vice-versa [8].

(33)

2.4.5. Primitivas

De forma a permitir a interacção entre as duas camadas adjacentes presentes na Figura 7, quer o protocolo ZigBee quer o IEEE802.15.4 utilizam o conceito de primitivas possibilitando às camadas superiores acederem aos serviços disponibilizados pelas camadas inferiores. Desta forma a camada imediatamente inferior (N) pode fornecer um serviço que a camada imediatamente superior pode utilizar (N+1).

Figura 8 - interacção entre camadas [9].

A passagem de informação entre essas duas camadas passa-se através da invocação de funções ou troca mensagens sendo denominada por primitivas em que os pontos de conexão entre camadas estão representados na Figura 7 pelos “service access point” (SAP).

Apesar de cada SAP apresentar funcionalidades e respostas diferentes todos eles apresentam quatro formas genéricas de comunicação entre camadas, sendo estas: “request”, quando a camada superior (N+1) faz uma requisição de um serviço à uma camada inferior (N); “indication”, gerada pela camada inferior quando existe um evento necessário para a camada superior; “response”, resposta enviada pela camada superior a uma primitiva do tipo “indication” da camada N; “confirm”, enviado pela camada N para indicar que um “request” proveniente da camada N+1 terminou.

Este método facilita a troca de informação entre camadas mantendo a coerência e a funcionalidade entre as mesmas. Permitindo também a utilização dos serviços disponibilizados por cada camada para uma aplicação de utilizador de uma forma mais transparente.

(34)

ZigBee 17

2.4.6. “Binding”

O protocolo ZigBee implementa o conceito de “binding” para facilitar a troca de mensagens entre os elementos da rede.

Esta funcionalidade permite ligar um nó a outro ou mais nós da rede utilizando para tal uma tabela, a tabela de “binding”, na qual são guardadas informações como o endpoint ao qual os nós se estão a ligar, o endereço de destino do nó ou do grupo em questão e o identificador do nó de destino na rede. A vantagem em usar estes dois identificadores destaca-se quando o nó de destino muda de identificador e é possível actualizar o identificador do nó sem perder a sua entrada na tabela de “binding”.

O “binding” de dois ou mais nós facilita em muito a quantidade de mensagens a enviar quando existem vários nós que estão ligados ao mesmo endpoint, pois assim o código necessário para o envio das mensagens diminui significativamente deixando a APS responsável pelo envio das mesmas.

Figura 9 - Exemplo de "binding" adaptado de [10].

Como se pode ver na Figura 9 é possível associar um nó a outros através do “binding”. No caso do interruptor superior, a associação é estabelecida por um conjunto de nós representando os dispositivos de iluminação que por sua vez estão associados a um nó que contém um interruptor que envia comandos de forma a ligar ou desligar as luzes. Para tal ser possível é necessário que os nós responsáveis pelos dispositivos de iluminação estejam na tabela de “binding” do interruptor. Comparativamente com o conjunto de três interruptores, o “binding” dos dispositivos de iluminação apenas apresenta a desvantagem de não puderem ser utilizadas as três lâmpadas de forma independente.

(35)

2.4.7. Exemplos de aplicações ZigBee

Hoje em dia já existe um sem número de aplicações ZigBee as quais cobrem os mais vastos campos de aplicação. Desde aplicações médicas como é o caso presente em [11] em que prevendo-se a necessidade de uma monitorização permanente de uma população com uma esperança de vida cada vez maior, decidiu-se implementar um sensor integrado na roupa facilitando assim a sua utilização. Os pontos fortes para a aplicação da rede ZigBee neste projecto são o facto de ser uma rede sem fios com a capacidade de recolher informação de múltiplos sensores permitindo uma mobilidade elevada do utilizador do sensor. Factores como o reduzido tamanho da plataforma e elevada autonomia desta foram tidos em conta para este projecto com o intuito de criar uma plataforma de tamanho reduzido e capaz de ser utilizada numa base diária sem causar incómodo para o utilizador.

Figura 10 - Exemplo de aplicações ZigBee no campo da domótica adaptado de [12].

Uma das áreas de aplicação mais famosa da rede ZigBee é sua utilização em domótica de forma a ajudar à criação de edifícios inteligentes. Nesta área o ZigBee apresenta-se como um protocolo de comunicações que reúne a capacidade de integrar todo o tipo de aplicações tais como o controlo de iluminação, sistemas de aquecimento e ventilação, monitorização, segurança, áudio e vídeo [13]. Estes tipos de aplicações são as mais usadas em domótica e o onde o ZigBee apresenta como principal mais-valia a relação custo/eficiência do mesmo [7].

(36)

19

Capítulo 3

Arquitectura

Este capítulo apresenta o conceito da gateway implementada. Numa primeira parte é introduzida a arquitectura desenvolvida seguindo-se de uma descrição detalhada da estrutura que esta deve seguir.

É também descrita a interacção entre os dois protocolos e para finalizar apresenta-se o hardware necessário para desenvolver a gateway.

3.1 -

_Descrição

Parte do trabalho realizado envolveu o desenvolvimento da arquitectura que a gateway teria de seguir. Para este problema, não existe uma solução única e pelo facto de se tratar de dois tipos protocolos distintos apresentam-se dificuldades acrescidas. A primeira que se apresenta é o facto de a gateway ter de pertencer às duas redes de comunicação distintas, nas quais tem de, simultaneamente e de uma forma transparente comunicar com os diferentes dispositivos. Este ponto foi ultrapassado implementando na gateway dois papéis diferentes de funcionamento presentes nos dois protocolos, tornando-a assim um membro de cada uma das redes simultaneamente e desempenhando um papel diferente do ponto de vista de cada rede. Assim do ponto de vista da rede Modbus, a gateway comporta-se como um servidor de Modbus disponibilizando a informação a um cliente Modbus em forma de registos.

E do lado da rede ZigBee a gateway comporta-se como um nó coordenador ZigBee com as funcionalidades de criar a rede, gerir o acesso à mesma e de actualizar os dados presentes nos nós da rede.

A gateway foi desenvolvida com o propósito de integração numa rede com um cliente de Modbus apenas, a partir de uma ligação por ethernet. No outro ponto de acesso à gateway, ligam-se os nós sensores/actuadores por ZigBee. Assim cria-se um acesso aos dados presentes

(37)

20 Arquitectura nos nós por parte do cliente de Modbus. Na Figura 11 apresenta-se a estrutura da rede para a qual a gateway foi pensada e é com base neste ponto que toda a estrutura da mesma foi projectada.

Figura 11 - Estrutura da rede.

A estrutura da gateway escolhida teve em conta as considerações de integração das redes de sensores sem fios nas redes actuais, presentes no capítulo 2. A própria integração numa rede já existente influencia o facto de a gateway ser um servidor Modbus visto que assim a integração necessária é de todo simplificada e é apenas necessário actualizar o cliente Modbus que vai ler os registos nela presentes na gateway. A gateway também poderia apresentar-se como um cliente Modbus, no entanto este facto implicaria que a integração numa rede já existente seria limitada e não traria uma mais-valia tão significativa ao local onde esta seria aplicada. Pois seria uma rede à parte que apenas utilizava da rede Modbus para, possivelmente, os seus dados estarem disponíveis num SCADA ou noutro tipo de aplicação de monitorização da rede.

Tendo definido a função da gateway na rede Modbus é necessário fazer o mesmo para a rede ZigBee, tendo-se concluído que a opção mais viável seria implementar na gateway as funcionalidades de um nó coordenador da rede ZigBee. Esta definição do papel da gateway deve-se ao facto de ser necessário um nó coordenador que vai gerir o acesso aos restantes nós da rede bem como o fluxo de informação deles provenientes, tal não aconteceria se a gateway se apresentasse como um ZED ou mesmo um “router”.

(38)

A arquitectura da gateway 21

3.2 -

_{A arquitectura da gateway}

A arquitectura da gateway é a parte fundamental deste projecto definindo-se toda a organização deste e o modo como a gateway deve interagir em qualquer situação. Assim sendo e tendo o local da gateway definido na rede, em conformidade com a Figura 14, é necessário definir os procedimentos que esta deve ter ao inserir/remover um nó na rede, ao receber e ao enviar mensagens para o cliente Modbus bem como para os nós presentes na rede ZigBee.

Uma comunicação entre estas duas tecnologias poderia ser estabelecida de duas formas bastante distintas obtendo-se soluções muito diferentes no trabalho final. A primeira solução seria uma solução baseada em modems ZigBee os quais se ligariam a clientes e servidores Modbus usando a rede ZigBee apenas para o transporte de mensagens e organização da mesma, mantendo as capacidades de reorganização da rede bem conhecidas do protocolo ZigBee. Esta solução como uma solução final de um projecto a implementar em ambientes industriais seria a economicamente menos rentável visto, neste caso serem necessários dois tipos diferentes de aparelhos, o modem ZigBee e o servidor Modbus. No entanto apresenta a vantagem de poder reutilizar servidores Modbus já existentes.

Uma segunda solução, e a solução implementada neste projecto, é a utilização de uma gateway que vai comunicar com nós originalmente desenvolvidos para a sua utilização com o protocolo ZigBee. A diferença desta solução para a solução anterior consiste em adaptar os nós ZigBee, usando os serviços implementados pela “stack” ZigBee e não usar esta apenas para transmissão de mensagens. Ambas as soluções foram previamente descritas e estudadas como pode ser observado em [14], [15] e [16] reafirmando-se o contributo que o protocolo ZigBee acrescenta a este tipo de redes.

Na Figura 12 observam-se as três entidades envolvidas neste projecto, o cliente Modbus, a gateway e um nó ZigBee. Para além de se poder observar a diferença entre as camadas físicas pelas quais comunicam entre si, também é possível verificar que a gateway faz a interacção entre a mensagem recebida do cliente Modbus através de uma tabela de endereçamento. Esta tabela ao receber uma mensagem do cliente Modbus faz a correspondência do número do registo pretendido para o número do nó ZigBee em questão.

(39)

22 Arquitectura

Figura 12 - Estrutura da gateway (vista global).

Esta é a funcionalidade da gateway de um modo geral, no entanto para a sua definição estar completa é necessário mapear os serviços se a usar em cada um dos protocolos. Para tal e para ajudar neste ponto apresenta-se a Figura 13 que mostra as camadas que uma mensagem recebida pela gateway vinda do cliente Modbus tem de percorrer até poder ser enviada para um nó ZigBee. Esta mensagem vai sendo encaminhada pela camada física (PHY), de ligação de dados (MAC) e seguidamente pela camada rede, do lado Modbus, até chegar à camada de aplicação que é partilhada pelos dois protocolos.

A camada de aplicação esta dividida em três grandes aplicações que funcionam cooperativamente umas com as outras mantendo, no entanto, a sua independência ao máximo.

Depois da mensagem Modbus ser processada vai ser reencaminhada pelas camadas inferiores do protocolo ZigBee. Uma mensagem proveniente do protocolo ZigBee fará o caminho inverso desde as camadas inferiores do protocolo ZigBee até à camada de aplicação e de seguida pelas camadas inferiores do protocolo Modbus para desta forma ser enviada para o cliente Modbus.

O desenvolvimento da gateway e de um projecto desta natureza ocorre única e exclusivamente na camada de aplicação do modelo OSI sendo por isso esta a mais focada na descrição aqui presente, visto já ter sido feita uma descrição das capacidades de cada parte do protocolo no capítulo 2. Assim sendo, das camadas inferiores são utilizados os serviços que permitem fazer a conexão entre as diferentes redes e no caso da rede ZigBee a gateway tem de ser responsável também por uma gestão adequada da mesma.

Cliente

Modbus

Gatway

Ethernet ZigBee

Tabela de

endereçamentos

registo | número ZigBee

Nó

ZigBee

(40)

Figura 13 - Pormenor da gateway.

A estrutura idealizada para a gateway está presente na

Figura 12 e corresponde à camada de aplicação da estrutura da Figura 1. Neste capítulo apresentam-se os serviços a usar durante uma aplicação deste género e para demonstrar a interacção entre esses mesmos serviços são apresentados diagramas dos conjuntos mais relevantes.

Para organizar este fluxo de informação é necessário implementar uma tabela que faça a correspondência entre os registos Modbus e os nós ZigBee, tal como está representado na Figura 13. A essa tabela foi dada o nome de tabela de endereçamento e permite mapear cada entrada/saída disponível num nó ZigBee nos diferentes registos disponíveis. Com uma correspondência inequívoca de uma entrada de um nó a um registo do tipo “holding” e uma saída do mesmo nó a um registo simples é possível garantir que não existe a possibilidade de escrever numa entrada provocando um curto-circuito no nó.

A tabela de endereçamento deve ter como campos o número do registo e o tipo do mesmo de forma a garantir a correspondência do lado Modbus e do lado ZigBee é necessário que a tabela de endereços tenha campos como número do nó, a sua Mac e o valor lógico existente na entrada ou saída correspondente tal como se apresenta na Tabela 2.

(41)

24 Arquitectura Tabela 2 - Tabela de endereçamento conceitual.

Modbus ZigBee

Registo Tipo Numero ZigBee MAC Valor

1 “Holding” 0x0288 0x0004A30000000054 0

2 Simples 0x0288 0x0004A30000000054 1

3 Simples 0x0288 0x0004A30000000054 0

Na Tabela 2 ilustra-se um conjunto de entradas da tabela de endereçamento em que um mesmo nó apresenta três registos sendo o registo 1 correspondente a uma entrada do nó ZigBee e o registo 2 e 3 deles correspondentes a duas saídas diferentes do mesmo nó. No caso de existirem mais nós na rede vão existir mais registos presentes na tabela de endereçamentos, que serão colocados nas posições imediatamente seguintes à última presente na tabela de endereçamento. Neste caso e para mapear um novo nó com duas entradas/saídas estas iriam ocupar o registo 4 e 5 na tabela de endereçamento.

A gateway, ao iniciar as suas funções, deve ser responsável pela utilização cooperativa dos protocolos Modbus e ZigBee. Para tal, e após se proceder às inicializações, são necessários certos procedimentos, que devem seguir a ordem indicada:

• Criar as entradas predefinidas da tabela de endereçamento – neste ponto é atribuído um conjunto de registos a cada um dos nós para posteriormente poderem ser consultados através do cliente Modbus;

• Criar e configurar a rede ZigBee – é necessário que a gateway crie uma rede e permita que os nós se juntem à mesma. É necessário também que esta controle o acesso à rede dos mesmos através do seu endereço MAC procurando a sua entrada na tabela de endereçamentos;

• A partir deste instante a gateway está disponível para receber e enviar dados quer para a rede Modbus quer para a rede ZigBee. Para além disso a gateway vai fazer uma consulta cíclica de forma a manter o valor dos registos actualizados.

(42)

Junção de um nó

Figura 14 - Junção de um nó á rede.

Na Figura 14 pode-se ver o procedimento que a gateway tem ao ser acrescentado um novo nó á rede logo após à validação do nó na tabela de endereçamentos. Para validar um nó na rede, a gateway deve verificar a existência do seu endereço de MAC na tabela de endereçamentos. Caso não exista nenhum registo para o nó em questão este nó deve ser removido.

Troca de mensagens

Para receber e enviar dados através das duas redes a gateway deve, ao receber uma mensagem de Modbus, ler o seu “function code” e determinar se este é suportado pela gateway.

Tabela 3 - Recepção de uma trama com um "function code" não implementado. Pedido

“Function Code” (Byte 0) 04

Endereço (Byte 1-2) 00 00

(43)

26 Arquitectura Como o “function code” 0x04 correspondente à leitura de um registo de entrada não é suportado pela gateway esta deve retornar uma mensagem de excepção com o seguinte formato:

Tabela 4 - Envio de uma trama de resposta a um "function code" não implementado. Excepção

Excepção (Byte 1-2) 00 01

Caso a função seja suportada e de leitura de um registo “holding” a gateway deve consultar o registo em questão e enviar a resposta com o valor do registo adequado (Figura 15).

Figura 15 - Esquema de uma recepção de mensagem de leitura desde o cliente até à gateway.

O valor a consultar é proveniente directamente da tabela de endereçamentos sem que haja consulta directa do nó no momento em que existe o pedido do cliente Modbus.

Tabela 5 - Trama de leitura de um registo enviada pela cliente Modbus. Pedido

Registo de referência (Byte 1-2) 00 01

(44)

Tabela 6 - Envio da resposta à trama de leitura de um registo enviada pela cliente Modbus.

Resposta

Número de Bytes da resposta (Byte 1-2) 02

Valores dos registos (Byte 3-4) 00 01

É de referir que quando a leitura de registos é superior a um, o campo dos valores dos registos vai variar em comprimento apresentando dois bytes por cada registo lido.

Se for uma mensagem de escrita num registo (“function code” = 0x06) a gateway deve identificar o nó em questão e enviar para este uma frame ZigBee para que o mesmo active a saída correspondente. Neste tipo de mensagem é necessário o envio de uma mensagem igual à recebida por parte da gateway após o registo ter sido escrito. Dessa forma é enviada uma mensagem ZigBee onde se espera por uma mensagem de “acknowledge” do nó destinatário.

Figura 16 - Esquema de recepção de uma mensagem de escrita e subsquente envio para o nó respectivo

Tabela 7 - Envio, pelo cliente Modbus, de um pedido de escrita num registo. Pedido

(45)

28 Arquitectura A mensagem enviada via ZigBee tem o seguinte formato:

Tabela 8 - Envio da trama ZigBee para escrever na saída correspondente.

DstAddress 79 6F

ADSU 01 01

TxOptions 04

E a respectiva resposta, em caso de sucesso:

Tabela 9 - Confirmação que a mensagem foi enviada com sucesso.

DstAddress 79 6F

Status SUCCESS

Gera-se a partir daí uma actualização na tabela de endereçamentos e o envio da seguinte mensagem Modbus:

Tabela 10 - Envio, para o cliente Modbus, da confirmação da escrita no registo pedido. Resposta

Valores dos registos (Byte 3-4) 00 01

Se a mensagem não for recebida com sucesso, ou seja, o “status” for diferente de “SUCCESS” é necessário enviar uma resposta para o cliente Modbus de um modo diferente reportando uma excepção.

Tabela 11 – Envio de uma trama para o cliente Modbus, caso não exista confirmação de envio.

Resposta

Excepção (Byte 1) 01

É de referir que o primeiro byte do ADSU da mensagem enviada é relativo ao endereço da mensagem Modbus e o segundo byte é relativo ao valor a escrever nesse endereço. Se o pretendido fosse escrever 00 no endereço 01 o ADSU em questão teria o valor de 01 00.

A gateway possibilidade a da consulta periódica dos nós com o intuito de actualizar a tabela de endereçamentos para que o cliente Modbus possa sempre ler o valor correcto dos registos. Essa actualização processa-se nó a nó e de uma forma sequencial.

(46)

Figura 17 - Esquema de consulta periódica aos nós ZigBee.

Para tal actualização ocorrer, é necessário enviar uma mensagem que neste caso gera uma resposta por parte do nó em questão. Uma mensagem enviada com o seguinte formato é enviada para cada um dos nós:

Tabela 12 - Envio de trama ZigBee de forma a ler todas as entradas e saídas presentes no nó ZigBee.

DstAddress 79 6F

ADSU FF

Gerando uma resposta:

Tabela 13 - Envio da resposta por parte do nó ZigBee.

DstAddress 02 6F

ADSU 00 00 01 00

Neste caso pode-se observar que o nó em questão apresenta quatro variáveis a monitorizar via Modbus em que apenas a terceira se encontra activa. A gateway depois de receber esta resposta vai actualizar a tabela de endereçamentos e seguidamente enviar uma mensagem ZigBee para o próximo nó presente na tabela de endereçamentos com o ADSU a 0xFF até ter percorrido todos os nós da rede.

(47)

30 Arquitectura

3.3 -

_{Mapeamento de funções}

Para permitir a funcionalidade entre os dois protocolos é necessário definir que funcionalidades vão ser usadas em cada um dos protocolos já que estes apresentarem naturezas bastante distintas. Enquanto o protocolo Modbus está concentrado na leitura e escrita de registos tal não acontece no protocolo ZigBee. Como tal, é indispensável criar uma correspondência entre as funções a usar em cada um deles. Para tal e como o objectivo do trabalho é comunicar com nós ZigBee que estão a controlar um conjunto de entradas/saídas, foi escolhida a função de leitura de um registo do tipo “holding” e a função de escrita num registo. Estas funções foram escolhidas visto serem as que mais se adequam à transmissão e recepção de dados do lado dos nós ZigBee. Assim, é possível um mapeamento completo na gateway dos registos presentes em cada um dos nós garantindo-se que não é forçada nenhuma das entradas neles presentes.

Para a sua utilização em conformidade com o protocolo ZigBee é necessário que as funções de Modbus gerem uma mensagem via ZigBee que o nó conheça e aja em conformidade com a mesma. Para tal a gateway ao receber uma mensagem retira desta dois parâmetros fundamentais, a função de Modbus pretendida e o registo pretendido. Depois de obter o registo em questão, a gateway, a partir da tabela de endereçamentos, identifica o nó ZigBee e a sua respectiva variável a ser alterada. A partir deste ponto, na perspectiva da gateway a mensagem que anteriormente tinha uma vertente Modbus, apresenta todos os parâmetros necessários para a sua conversão para ZigBee.

A mensagem, ao ser construída vai utilizar inúmeros serviços da “Application Support Sub-Layer” (APS) nomeadamente aqueles que são utilizados para o encaminhamento das mensagens para os nós, sendo necessário efectuar pedidos à APSE-DATA dos seguintes parâmetros:

• DstAddrMode – modo como o endereço de destino vai ser apresentado;

• DstAddress – endereço de destino segundo o parâmetro especificado no DstAddrMode;

• DstEndpoint – utilizado apenas para endereçamentos maiores ou iguais a 16bit; • ProfileId – perfil da frame a enviar;

• ClusterId – identificação do “Application Object” destinatário;

• TxOptions – opções da transmissão;

• RadiusCounter – quantidade de retransmissões que a mensagem pode sofrer por parte dos outros elementos da rede.

De seguida a mensagem é dirigida para o seu destino através das APO's presentes na camada de aplicações da rede ZigBee e por fim transmitida para o seu destino.

De uma forma geral, a informação de uma mensagem Modbus é retirado o registo e a função a utilizar sendo estes parâmetros utilizados para construir uma mensagem nova com o

(48)

Hardware 31 formato correspondente ao protocolo ZigBee onde os parâmetros de destino do “APS Header” (ver Figura 6) são dados pela tabela de endereçamentos.

3.4 -

_Hardware

Para implementar o conceito definido nos pontos anteriores deste capítulo é necessário alguns requisitos mínimos, que tipicamente estão presentes na maior parte dos microcontroladores de baixo custo actuais. Para além da unidade de processamento é também necessário uma interface TCP/IP e uma interface ZigBee para ligar as diferentes redes à gateway. Estes três elementos são os componentes mínimos necessários para o desenvolvimento gateway e a sua interligação é efectuada, por norma, como demonstra a

Figura 18.

Figura 18 -Estrutura básica da gateway adaptado de [17]

Para desenvolver um projecto deste género é necessário ter em atenção alguns requisitos mínimos. O ponto central, a nível de hardware, para desenvolver a gateway é necessário um micro-controlador de 8-bits ou superior e uma memória superior a 64kB pois estes possuem, capacidade de implementar a gateway. É de referir que, apesar de nem o protocolo ZigBee nem o Modbus requererem muito do processamento do micro-controlador, exigem, por outro lado, uma maior capacidade de memória, onde a “stack” de ZigBee é o componente que mais a utiliza.

Para além das questões de capacidade de processamento, o micro-controlador deve ter conexão às interfaces externas, sendo mais aconselhável que se utilize, tal como neste trabalho, uma estrutura que já esteja embebida com uma das opções de interface. Apesar de esta não ser uma opção de todo condicionante é uma mais-valia facilitando a implementação do projecto.

(49)

32 Arquitectura Como foi referido, neste projecto, existia a possibilidade de se optar por um sistema que viesse integrado com uma interface TPC/IP ou por uma interface ZigBee. A opção seleccionada reverteu para a interface ZigBee visto esta ser a mais recente e que poderia apresentar mais dificuldade na implementação.

(50)

33

Capítulo 4

Implementação

Antes de se aprofundar o que foi implementado na gateway é necessário ter uma visão geral dos elementos que fazem parte da gateway bem como as ferramentas utilizadas para a criação da mesma. Assim, o presente capítulo descreve o trabalho implementado, iniciando-se a descrição, por uma análiiniciando-se do hardware e do software utilizado iniciando-seguindo-iniciando-se os iniciando-serviços utilizados de cada “stack”. Para finalizar, apresenta-se detalhadamente a gateway, desde o processo de inicialização até ao funcionamento como servidor da rede Modbus.

4.1 -

_{Hardware utilizado}

O facto de o hardware ter como base o kit de desenvolvimento da Microchip (PICDEM Z) originou uma subdivisão do hardware em duas partes distintas. Visto o PICDEM Z ser um kit de desenvolvimento de redes ZigBee este apresenta-se numa pequena placa com conexão com a antena ZigBee, porta série e uma pequena parte em que o utilizador pode personalizar a tabela de registos permitindo um melhor desenvolvimento da mesma. A segunda parte do hardware é o dispositivo da Lantronix, o XPort, que é responsável pela ligação via TCP da gateway. O XPort tem como objectivo receber uma trama da porta série da gateway e convertê-la para pacotes TPC/IP e vice-versa.

(51)

34 Implementação

4.2 -

_{Picdem Z}

O kit de desenvolvimento incorpora vários componentes que facilitam o desenvolvimento de uma aplicação utilizando o protocolo ZigBee. Assim, o PICDEM Z é composto por dois nós ZigBee completamente funcionais, para desenvolver a aplicação desejada, um “sniffer” para permitir visualizar o tráfego na rede proporcionando a correcção de alguns erros e ainda um conjunto de cd's com software de compilação, programação e documentos técnicos, que fornecem estes alguma informação sobre o hardware.

A unidade de processamento que acompanha o PICDEM Z é um micro-controlador PIC18F4620 da Microchip que apresenta as seguintes características principais:

• Velocidade de processamento até 40MHz; • 64kB de memória flash;

• Baixo consumo energético;

• Três modos distintos de funcionamento, modo normal (CPU e periféricos ligados), em suspensão (CPU desligado mas com os periféricos ligados) e em hibernação (CPU e periféricos desligados);

• 36 portas de entrada/saída e 4 temporizadores; • Ligação via porta série.

Figura 19 - Nó de desenvolvimento do Picdem Z.

A Figura 19 contém: 1- Unidade de processamento (PIC18F4620); 2- Antena ZigBee; 3- Área de desenvolvimento.

(52)

Xport

Estas características tornam aplicações como esta. O PICDEM Z ser substituído quando necessário

utilizador pode montar mais alguns dispositivos que

cada nó no kit de desenvolvimento são típicas de plataformas de desenvo possível diminuí-las facilmente com uma versão do m

mesmo retirando a área de desenvolvimento.

4.3 -

_Xport

Este dispositivo foi utilizado para a interface TCP/IP de converter as tramas vindas da

reencaminhando-os para a rede de ethernet de uma forma transparente para o utilizador sem exigir grandes configurações por parte deste.

muitas mais funcionalidades do que aquelas em utilização revelou-se de grande importância

eficaz da vertente TCP proporcionando mais Na Figura 21 apresenta

algumas das suas potencialidades

Estas características tornam-no num elemento bastante versátil e PICDEM Z incorpora ainda uma antena ZigBee (Figura

ando necessário. O kit de desenvolvimento inclui ainda uma área em que o utilizador pode montar mais alguns dispositivos que pretenda (Figura 19

-cada nó no kit de desenvolvimento são típicas de plataformas de desenvo

facilmente com uma versão do micro-controlador mais compacta do mesmo retirando a área de desenvolvimento.

foi utilizado para a interface TCP/IP dado ser um sistema embebido capaz de converter as tramas vindas da porta série da gateway em pacotes TCP/IP

os para a rede de ethernet de uma forma transparente para o utilizador configurações por parte deste. Apesar de este dispositivo

muitas mais funcionalidades do que aquelas em que é utilizado neste projecto,

grande importância, visto ter permitido uma implementação rápida e proporcionando mais tempo para outros aspectos deste trabalho. apresenta-se alguns pormenores da arquitectura interna do

potencialidades.

Figura 20 – Xport

35

emento bastante versátil e competente em Figura 19 - 2) podendo kit de desenvolvimento inclui ainda uma área em que o - 3). As dimensões do cada nó no kit de desenvolvimento são típicas de plataformas de desenvolvimento sendo controlador mais compacta do

um sistema embebido capaz da gateway em pacotes TCP/IP, os para a rede de ethernet de uma forma transparente para o utilizador e ste dispositivo ser capaz de que é utilizado neste projecto, a sua uma implementação rápida e tempo para outros aspectos deste trabalho.

(53)

36 Implementação

Figura 21 - Arquitectura interna do Xport.

O acesso às configurações do XPort pode ser efectuado de duas formas distintas. A forma mais apelativa ao utilizador é a configuração via “browser”, sendo possível navegar no menu de opções facilmente.

Este menu apresenta uma vasta gama de configurações disponíveis ao utilizador desde o protocolo da camada de transferência, número de bits, e outras presentes na Figura 22. Existem ainda opções que permitem associar eventos as três portas de entrada/saída presentes no XPort de forma aos utilizadores da rede ethernet receberem e-mails de avisos com seu estado.