gateway entre uma rede de sensores e um sistema de … · as redes de sensores permitem melhorias...

Gateway entre uma Rede de Sensores e

um Sistema de Messaging

Miguel Franco Passos Inês Gaspar

(Licenciado)

Dissertação para a obtenção do Grau de Mestre em

Engenharia Electrotécnica e Computadores

Júri

Orientador: Renato Jorge Caleira Nunes

Co-Orientador: Mário Serafim Nunes

Presidente: Nuno Horta

Vogal: Carlos Almeida

Julho de 2010

i

Resumo

Esta dissertação está ligada às redes de sensores e actuadores e tem como objectivo criar um

sistema que permita a sua monitorização e comando através do uso de um sistema de mensagens

instantâneas (Instant Messaging).

Actualmente existem múltiplas tecnologias de sensores, desenvolvidas por diferentes fabricantes, que

são incompatíveis entre si ao nível aplicacional. Estas redes são tipicamente desenvolvidas sobre

plataformas de baixos recursos conduzindo a soluções desenhadas caso a caso para oferecerem os

níveis desejados de funcionalidade e desempenho. A falta de uniformidade das soluções existentes

constitui uma barreira para a evolução desta área e dificulta o desenvolvimento de ferramentas

genéricas capazes de aceder e controlar qualquer tipo de rede.

Nesta dissertação procura-se ultrapassar as limitações descritas adoptando-se o modelo DomoBus

para esconder as particularidades das redes de sensores e de actuadores, e desenvolvendo um

gateway que permite a sua integração com um sistema que permite a troca de mensagens de texto

em tempo real entre vários utilizadores (instant messaging).

A tecnologia DomoBus é baseada num modelo de abstracção de dispositivos que permite um

controlo genérico de uma rede de sensores e disponibiliza mecanismos de comunicação bastante

flexíveis que simplificam o desenvolvimento de aplicações adaptáveis às necessidades de cada

utilizador final. A utilização de um sistema de instant messaging permite dispôr de um meio de

interacção simples com uma rede de sensores e actuadores. Foi adoptada uma solução baseada na

norma XMPP o que permite a monitorização e controlo remoto destas redes usando diferentes

equipamentos e sistemas operativos e sem necessidade de instalação de aplicações específicas pois

pode ser usado um browser comum. Toda a lógica de interacção com a rede de sensores encontra-

se na gateway desenvolvida neste trabalho.

Palavras-Chave DomoBus, Monitorização e Controlo de Redes de Sensores, Instant Messaging, Redes de Sensores.

iii

Abstract

This work is focused on sensor networks and aims to create a system able to monitor and command

them through an Instant Messaging system.

Currently there are multiple sensor technologies, developed by different manufacturers, which are

incompatible at the application level. These networks are typically developed on low-resource

platforms, leading to solutions designed specifically to each case, to provide the desired levels of

functionality and performance. The lack of uniformity is a barrier to the development of this area and

hinders the development of generic tools able to access and control any type of network.

This dissertation seeks to overcome the limitations described, by adopting the DomoBus model that

hides the sensor networks’ peculiarities, and using a gateway that allows its integration with a system

that exchanges text messages in real-time among multiple users (instant messaging).

The Domobus technology is based on a device’s type abstraction that allows the control of a generic

sensor network and provides mechanisms flexible enough to enable an easy development of

applications adaptable to the needs of each end-user. Using an instant messaging system allows a

simple interaction with a sensors and actuators network. The adopted solution is based on the XMPP

standard, allowing remote monitoring and control of these networks using different kinds of hardware

and operating systems and avoiding the need to install specific applications, as it can be used through

a common browser. All the information processing is done by the gateway developed in this work.

Keywords DomoBus, Instant Messaging, Monitor and Command Sensor Networks, Sensor Networks.

v

Conteúdo

1. Introdução ........................................................................................................................................ 2

1.1 Enquadramento e Objectivos ..................................................................................................... 2

1.2 Estrutura da Dissertação ............................................................................................................ 4

2. Estado da Arte ................................................................................................................................. 6

2.1 Redes de Sensores .................................................................................................................... 6

2.1.1 Arquitectura de Comunicação ............................................................................................... 6

2.1.2 Pilha de Protocolos .............................................................................................................. 10

2.2 Sistemas Domóticos Normalizados .......................................................................................... 12

2.2.1 X10 ...................................................................................................................................... 12

2.2.2 EIB/KNX............................................................................................................................... 13

2.2.3 Batibus ................................................................................................................................. 13

2.2.4 European Home System Association (EHSA)..................................................................... 14

2.2.5 Konnex................................................................................................................................. 14

2.2.6 LonWorks............................................................................................................................. 14

2.2.7 CEBus .................................................................................................................................. 15

2.3 Sistema DomoBus .................................................................................................................... 16

2.3.1 Modelo de abstracção de dispositivos ................................................................................ 16

2.3.2 Nível de monitorização e controlo ....................................................................................... 19

2.3.3 Endereçamento de dispositivos .......................................................................................... 20

2.4 Mensagens Instantâneas ......................................................................................................... 23

2.4.1 Escolha do protocolo a usar ................................................................................................ 28

3. Descrição da Solução .................................................................................................................... 30

3.1 Arquitectura da Solução ........................................................................................................... 30

3.2 Funcionalidades Fundamentais ............................................................................................... 31

3.2.1 Ligação ao Sistema de IM ................................................................................................... 31

3.2.2 Envio e Recepção de Mensagens IM .................................................................................. 32

3.2.3 Ligação ao Sistema DomoBus ............................................................................................ 32

3.3 Interacção com o sistema DomoBus ........................................................................................ 34

vi

3.3.1 Utilizadores .......................................................................................................................... 34

3.4 Rede de Sensores para Domótica ........................................................................................... 36

3.4.1 Ficheiro House.xml .............................................................................................................. 37

3.4.2 Ficheiro DomoticSystem.xml ............................................................................................... 37

3.5 Notificações e Favoritos ........................................................................................................... 39

3.6 Estrutura dos Menus ................................................................................................................ 39

4. Avaliação da Solução .................................................................................................................... 44

4.1 Ligação do CommDir ................................................................................................................ 44

4.2 Ligação ao Sistema de IM ........................................................................................................ 45

4.3 Ligação do Simulador ............................................................................................................... 46

4.4 Funcionamento da Gateway IM ............................................................................................... 47

4.5 Verificação das acções realizadas pela gateway IM ................................................................ 51

4.6 Privilégios dos utilizadores ....................................................................................................... 51

4.7 Apreciação Geral ...................................................................................................................... 52

5. Conclusão ...................................................................................................................................... 54

vii

Lista de Figuras

Figura 1.1 – Exemplo de sensores que se podem encontrar numa rede de sensores. ......................... 2

Figura 2.1 – Nós Sensores dispostos num Campo de Sensores. [1] ..................................................... 7

Figura 2.2 - Componente de um nó sensor. [1]....................................................................................... 8

Figura 2.3 - Topologias básicas de uma Rede de Sensores. [8] ............................................................ 9

Figura 2.4- Pilha de protocolos de uma rede de sensores. [1] ............................................................. 10

Figura 2.5 – Exemplo de três dispositivos X10. .................................................................................... 13

Figura 2.6 – Dispositivo LonWorks equipado com um Neuron Chip. ................................................... 15

Figura 2.7 – Modelo de um dispositivo DomoBus ................................................................................. 17

Figura 2.8 - Arquitectura do sistema DomoBus .................................................................................... 20

Figura 2.9 – Endereçamento de um dispositivo na rede DomoBus. ..................................................... 21

Figura 2.10 – Endereços na rede DomoBus. ........................................................................................ 21

Figura 2.11 – Formato das mensagens entre aplicações e a rede DomoBus. ..................................... 21

Figura 2.12 – Estrutura do campo “data” de uma mensagem DomoBus. ............................................ 22

Figura 2.13 – Formato das mensagens pré-definidas. ......................................................................... 22

Figura 2.14 – Formato da mensagem do tipo Forward. ........................................................................ 23

Figura 3.1 – Gateway entre uma rede de sensores e um sistema de IM ............................................. 31

Figura 3.2 – Estrutura das aplicações. .................................................................................................. 33

Figura 3.3 – Menu de alteração de níveis de acesso. .......................................................................... 35

Figura 3.4 – Janela de alteração de níveis de acesso. ......................................................................... 36

Figura 3.5 – Funcionamento dos menus. .............................................................................................. 41

Figura 4.1 – Representação do registo de aplicação no ficheiro de configurações. ............................ 44

Figura 4.2 – CommDir apresentando as aplicações autorizadas. ........................................................ 44

Figura 4.3 – Menu Ligação (Esquerda); Janela de ligação ao CommDir (Direita). .............................. 45

Figura 4.4 – Ligação efectuada com sucesso. ...................................................................................... 45

Figura 4.5 – Menu Ligação (à esquerda); Ligação ao sistema de IM (à direita)................................... 46

Figura 4.6 – Ligação estabelecida ao sistema de IM. ........................................................................... 46

Figura 4.7 – Janela Principal do Simulador. .......................................................................................... 47

Figura 4.8 – Menu Serviços................................................................................................................... 49

Figura 4.9 – Opção Inválida. ................................................................................................................. 49

Figura 4.10 – Alteração do estado de um dispositivo. .......................................................................... 50

Figura 4.11 - Adicionar uma notificação ................................................................................................ 50

Figura 4.12 - Pedidos de GET e SET recebidos e processados. ......................................................... 51

Figura 4.13 – Utilizador sem acesso. .................................................................................................... 52

ix

Lista de Acrónimos

µAMPS - µ-Adaptative Multi-domain Power aware Sensors

BCI – Batibus Club International

CAD – Conversor Anológico-Digital

CEBus – Consumer Electronic Bus

CENELEC – Comité Européen de Normalisation Electrotechnique

DB – Data Base

EIA – Electronic Industries Association

EIB – European Installation Bus

EIBA – European Installation Bus Association

EHSA – European Home Systems Association

IETF – Internet Engineering Task Force

IM – Instant Messaging

MAC – Medium Access Control

OS – Operating System

PC – Personal Computer

RF – Radiofrequência

SASL – Simple Authentication a Security Layer

TLS – Transport Layer Security

VoIP – Voice over Internet Protocol

WINS – Wireless Integrated Network Sensors

WSN – Wireless Sensor Network

XEP – XMPP Extensible Protocols

XMPP – Extensible Messaging and Presence Protocol

xi

Lista de símbolos

kλ- Taxa de erro

µ - Densidade

A - Ampere

GHz – Giga Hertz

h - Hora

Hz – Hertz

MHz – Mega Hertz

( )kR t - Fiabilidade

t – Período de tempo

1

Capítulo 1

Introdução

2

1. Introdução

1.1 Enquadramento e Objectivos

As redes de sensores permitem melhorias significativas na gestão de edifícios e de outros espaços.

Estas melhorias podem ser notadas em diversas áreas, como a segurança, com sensores de

movimento, estando estes normalmente ligados a alarmes, detectores de fugas de gás, detectores de

incêndio e de inundações. Os consumos de energia podem também ser reduzidos, com detectores de

presença a fazer uma gestão da iluminação, termóstatos a gerirem aquecedores e aparelhos de ar-

condicionado, o que permite ainda um aumento do conforto possibilitando uma gestão remota do

ambiente onde os sensores se encontram. Na Figura 1.1 ilustram-se vários tipos de sensores que

podem ser encontrados numa rede de sensores num ambiente doméstico.

Figura 1.1 – Exemplo de sensores que se podem encon trar numa rede de sensores.

Estes dispositivos surgiram usando diferentes tecnologias de base. Esta variedade de tecnologias

não contemplou a compatibilidade entre umas e outras, fazendo com que possíveis avanços na

gestão centralizada tenha saído bastante prejudicada. Os sistemas que existem e permitem alguma

centralização da gestão de redes de sensores apresentam relações preço/qualidade de serviço

reduzidas e são de difícil instalação e utilização. Todos estes factores fizeram com que a procura

3

destas tecnologias seja muito inferior ao que seria de esperar, devido ao potencial apresentado pelas

mesmas.

Com o intuito de criar um sistema capaz de monitorizar uma rede de sensores completa, o Prof.

Renato Nunes desenvolveu o sistema DomoBus. Trata-se de uma solução genérica, aberta,

independente de qualquer tecnologia e que oferece uma infra-estrutura de comunicação gratuita que

permite simplificar o desenvolvimento de aplicações. Trata-se ainda de um sistema fácil de usar pois,

entre outros aspectos, foi desenvolvida uma biblioteca de comunicação - CommAPI - que simplifica o

desenvolvimento de aplicações que comuniquem entre si, permitindo soluções mistas envolvendo

várias tecnologias domóticas. Torna-se assim possível oferecer soluções mais flexíveis e fáceis de

adaptar ao utilizador final, em que o próprio tem a possibilidade de as configurar, deixando de existir a

necessidade de recorrer sistematicamente a técnicos qualificados. Este sistema baseia-se num

modelo de abstracção de dispositivos e utiliza mecanismos de comunicação bastante flexíveis que

permitem o desenvolvimento de aplicações adaptáveis às necessidades de cada utilizador final. Foi

então criada uma infra-estrutura de comunicação que permite uma interacção fácil entre múltiplas

aplicações e o acesso a diferentes tecnologias através de gateways adequadas. Este sistema tem por

objectivo atender à necessidade de oferecer suporte ao desenvolvimento de aplicações de alto nível

que ofereçam facilidades de monitorizar e definir o comportamento do sistema, interactuar com o

utilizador e permitir acesso remoto através da Internet.

O presente trabalho apresenta uma proposta de uma aplicação que funciona como gateway entre o

sistema DomoBus e um sistema de Instant Messaging (IM), através do protocolo XMPP. Os sistemas

de IM têm crescido muito ao longo dos anos em número de utilizadores tendo, como meio de

comunicação básico, a troca de mensagens de texto em tempo real. Com a integração destes dois

sistemas torna-se possível comunicar com uma rede de sensores que use o sistema DomoBus,

através de uma simples troca de mensagens de texto. Com a realização deste trabalho, a

monitorização de uma rede de sensores passa a poder ser feita em qualquer local e com qualquer

aparelho que tenha acesso à internet, fazendo uso de um browser. Deixa então de ser necessária a

instalação de uma aplicação própria para comunicar com estes sistemas, quebrando também a

barreira de compatibilidades das aplicações a serem usadas em diferentes Sistemas Operativos.

4

1.2 Estrutura da Dissertação

Esta dissertação encontra-se dividida em cinco capítulos. No capítulo dois é feito o enquadramento

do presente trabalho face a desenvolvimentos ocorridos em áreas afins. Uma vez feito este

enquadramento passa-se, no capítulo três, para uma descrição da solução proposta focando a

arquitectura e o modo de funcionamento da gateway desenvolvida. No capítulo quatro apresentam-se

os testes realizados para verificação do correcto funcionamento da solução. Por fim, no capítulo

cinco, são apresentadas as conclusões, sendo ainda sugeridos possíveis melhoramentos futuros da

solução proposta.

5

Capítulo 2

Estado da Arte

6

2. Estado da Arte

2.1 Redes de Sensores

Uma rede de sensores é composta por um alargado número de nós sensores que estão colocados no

espaço físico do fenómeno a ser observado ou muito perto dele. Algumas das áreas de aplicação das

redes de sensores são a saúde, militar, monitorização de ambientes, habitações, edifícios, pontes,

instalações industriais.

Um sensor pode ser descrito, de uma forma geral, como um dispositivo que converte uma grandeza

física num valor digital que é depois enviado através de mensagens.

Existe um vasto leque de tipos de sensores, nos quais se englobam movimento, temperatura, fumo,

gás, água, pressão, humidade, vibração, campo magnético, diversos tipos de radiação, entre outros.

Dentro dos diferentes tipos existem diferentes tecnologias associadas aos sensores, como os de

infra-vermelhos, microondas, fotoeléctricos, ionização, foto-ionização, magnéticos, condutividade

eléctrica e ultra-sons.

2.1.1 Arquitectura de Comunicação

Como é referenciado em [1], os nós sensores são geralmente espalhados num campo de sensores -

ver Figura 2.1. Cada um dos nós dispostos no campo tem capacidade de recolher e enviar dados

para o nó sink (que funciona como um contentor que recolhe os dados de todos os sensores). O sink

poderá, posteriormente, comunicar com o Task Manager Node, através de um canal de comunicação

como a internet ou satélite. A constituição de uma rede de sensores é influenciada por vários

factores, como tolerância a falhas, escalabilidade, custos de produção, ambiente de operação,

topologia da rede de sensores, limitações de hardware, meio de transmissão e consumo de energia.

Estes factores são importantes porque servem de orientação para a construção de um protocolo ou

algoritmo para uma rede de sensores.

Tolerâncias a Falhas – Alguns nós sensores podem ter uma falha de comunicação ou serem

bloqueados devido a uma falha de energia, algum dano físico ou uma interferência causada pelo

meio ambiente onde se encontram inseridos. Estas falhas não devem causar uma interrupção no

funcionamento geral de uma rede de sensores. A tolerância a falhas representa então a capacidade

de sustentar o funcionamento de uma rede de sensores, sem qualquer interrupção no funcionamento

da mesma, devido à falha de alguns dos nós sensores nela inserido.

A fiabilidade Rk(t), ou tolerância a falhas, de um nó sensor é aproximada em [2] através de uma

distribuição de Poisson, que permite calcular a probabilidade de não existirem falhas no intervalo de

tempo (0,t):

7

( ) tkR t e kλ−= (2.1)

Onde kλ representa a taxa de erro do nó sensor k e t representa o período de tempo.

Escalabilidade – O número de nós sensores dispostos numa rede para estudar um dado fenómeno

pode ser da ordem das centenas ou milhares, podendo mesmo chegar aos milhões, em casos

extremos, dependendo da aplicação. A densidade pode variar entre apenas alguns nós sensores até

algumas centenas de nós sensores numa dada região, que poderá ser menos que 10 m em diâmetro.

De acordo com [3], a densidade µ pode ser calculada:

( ) ( )2. /R N R Aµ π= (2.2)

onde N é o número de nós sensores dispostos na região A, e R é o alcance de transmissão via rádio.

Basicamente, ( )Rµ dá-nos o número de nós que se encontram no raio de transmissão de cada nó,

dentro da região A.

Figura 2.1 – Nós Sensores dispostos num Campo de Se nsores. [1]

Limitações de Hardware – Um nó sensor é composto por quatro componentes básicas: uma

unidade de detecção/ localização (dependendo da aplicação), uma unidade de processamento, uma

unidade de transmissão e uma unidade de energia. Podem ainda conter componentes dependentes

da aplicação a que se destinam como um sistema de localização ou um gerador de energia. As

unidades de detecção são usualmente compostas por duas subunidades: sensores e conversores

analógico-digital (CAD). Os sinais analógicos produzidos pelo sensor, com base no fenómeno

observado, são convertidos em sinais digitais pelo CAD e posteriormente enviados para a unidade de

processamento. A unidade de processamento, que geralmente está associada a uma pequena

unidade de armazenamento, gere os processos que permitem ao nó sensor comunicar com os

restantes nós para levarem a cabo as tarefas de detecção, monitorização e disseminação da

informação. A unidade de transmissão estabelece a ligação entre o nó e a rede. A unidade de energia

8

é uma das componentes mais importantes, pode ser suportada por unidades de energia renovável,

tais como células solares. Grande parte das técnicas de encaminhamento numa rede de sensores

requer um conhecimento bem aprofundado do local. É então muito comum um nó sensor possuir um

sistema de localização. Pode ser necessário, por vezes, possuir um mobilizador para mover os nós

sensores quando é requerido avançar com as tarefas que lhes são designadas.

Existem ainda, no entanto, alguns requisitos que poderão ser algo limitadores para os nós sensores.

Estes têm de consumir muito pouca energia, terem um custo de produção muito reduzido, serem

dispensáveis e autónomos, operarem sem qualquer tipo de acompanhamento e serem adaptáveis ao

ambiente onde são colocados.

“Consoante a aplicação alguns requisitos podem ser menos relevantes”

Figura 2.2 - Componente de um nó sensor. [1]

Topologia da Rede de Sensores – Uma rede de sensores sem fios, usualmente designadas por

WSN (Wireless Sensor Network), pode apresentar diferentes topologias. Encontram-se algumas

representadas na Figura 2.3, onde se incluem as topologias em estrela, anel, bus, árvore, totalmente

ligada e rede.

Num campo de sensores existem entre centenas e milhares de nós. São colocados a centenas de

metros uns dos outros [4], sendo que a densidade de nós poderá atingir os 20 nós/m3 [6], o que

requer cuidados no que respeita à manutenção da topologia da rede. A manutenção de uma topologia

de rede pode ser observada em três fases:

• Fase de pré-colocação e colocação: Os nós sensores poderão ser colocados em massa ou

um a um no campo de sensores. Poderão ser lançados de um avião, entregues numa caixa

de artilharia, ou míssil, ou ainda serem colocados por um ser humano ou mesmo um robot.

• Fase de pós-colocação: Após a colocação dos nós sensores, poderão existir alterações na

topologia da rede devido a alterações quer de, posição, alcance (devido a interferências,

ruído, obstáculos em movimento, etc.), energia disponível, não funcionamento, ou mesmo a

devido a detalhes de tarefas, nos nós sensores.

9

• Fase de recolocação de nós adicionais: Podem ser colocados nós adicionais a qualquer

momento para substituir nós que não estejam a funcionar ou devido a alteração das tarefas

pretendidas.

Figura 2.3 - Topologias básicas de uma Rede de Sens ores. [8]

Meio Ambiente – Os nós sensores são colocados ou muito perto, ou mesmo directamente no local

do fenómeno a ser observado. Encontram-se muitas vezes a funcionar em locais onde não existe

interacção humana, como por exemplo, no interior de máquinas de grandes dimensões, no fundo de

um oceano, numa zona química ou biologicamente contaminada, num campo de batalha em território

inimigo, como podem também encontrar-se num grande edifício ou numa residência.

Meio de Transmissão – Numa rede de sensores multi-ponto os nós de comunicação estão ligados

através de uma ligação sem fios que poderá ser através de rádio, infra-vermelhos, ou meio óptico.

Para tornar possível um controlo a nível global destas redes, o meio de transmissão escolhido tem de

estar disponível em qualquer local.

Uma grande percentagem do hardware disponível de nós sensores é baseada em circuitos de

radiofrequência (RF). Os nós sensores µ-Adaptative Multi-domain Power aware Sensors (µAMPS) [6]

usam um transmissor compatível Bluetooth a 2.4GHz com um sintetizador de frequência integrado. O

sensor de baixa potência descrito em [7] transmissor em RF de canal único que opera na banda dos

916MHz. A arquitectura Wireless Integrated Network Sensors (WINS) também utiliza ligações por

rádio para comunicar [5].

Outro meio para se realizar a comunicação entre nós sensores é por infra-vermelho, que é um meio

de comunicação que não requer qualquer tipo de licença e é robusto a interferências causadas por

aparelhos eléctricos. Os transmissores de infra-vermelhos são menos dispendiosos e mais fáceis de

construir. Existem ainda os dispositivos Smart Dust que são sistemas de detecção, computação e

comunicação autónomos e usam o meio óptico para transmissão. Tanto os dispositivos de infra-

vermelhos, como os ópticos necessitam de estar em linha de vista para poder existir comunicação

entre emissor e receptor.

10

Consumo de Energia – Um nó sensor sem fios, sendo um dispositivo microelectrónico, estará

equipado, necessariamente, de uma fonte de energia limitada (< 0.5Ah, 1.2V). Em algumas

aplicações poderá ser impossível fazer uso de energias renováveis, sendo o tempo de vida útil de um

nó sensor fortemente dependente do tempo de vida útil da sua bateria. Numa rede de sensores ad

hoc multiponto, cada nó tem um papel duplo, em que tanto pode originar, como distribuir dados. No

caso de falharem alguns nós a topologia da rede pode sofrer grandes alterações, o que poderá

implicar uma redistribuição dos pacotes e reorganização da rede, isto faz com que a conservação de

energia, bem como a gestão desta assumam uma importância ainda maior na rede. Pelas razões

assinaladas, actualmente os investigadores têm-se concentrado no desenvolvimento de protocolos e

algoritmos para redes de sensores que permitam uma melhor gestão de energia.

A tarefa principal de um nó sensor num campo de sensores é detectar eventos, processar

rapidamente dados sobre o evento e transmitir esses dados. Pode então dividir-se o consumo de

energia em três domínios: detecção, comunicação e processamento de dados.

2.1.2 Pilha de Protocolos

A pilha de protocolos usada pelos nós sink e pelos nós sensores presentes na Figura 2.1 é descrita

na Figura 2.4- Pilha de protocolos de uma rede de sensores. [1]. Esta pilha inclui informação do uso

de energia e encaminhamento de dados, engloba dados e protocolos do nível de rede, comunica por

rádio frequência usando “inteligentemente” a energia e promove um uso colectivo dos nós sensores.

A pilha de protocolos consiste nas camadas física, ligação de dados, rede, transporte e aplicação,

bem como nos planos de gestão de energia, gestão de mobilidade e gestão de tarefas. Estes últimos

são responsáveis pela supervisão do consumo de energia, movimento e distribuição de tarefas entre

os nós sensores. Estes planos são então responsáveis por guiar os nós sensores nas tarefas de

detecção e reduzir os gastos totais de energia.

Figura 2.4- Pilha de protocolos de uma rede de sens ores. [1]

11

Camada Física – Aborda a necessidade do uso de técnicas simples, mas robustas, de modulação,

transmissão e recepção.

Camada de Ligação de Dados – Uma vez que o ambiente é ruidoso e os nós sensores podem ser

móveis, o protocolo Medium Access Control (MAC) tem de ter em conta os consumos de energia,

bem como ser capaz de evitar colisões nas transmissões entre nós vizinhos.

Camada de Rede – Encarrega-se de distribuir os dados fornecidos na camada de transporte.

Camada de Transporte – Tem como função, essencialmente, manter o fluxo de dados se a

aplicação da rede de sensores assim necessitar.

Camada de Aplicação – Podem ser criados e usados diferentes tipos de aplicações, nesta camada,

dependendo no das tarefas de detecção pretendidas.

Plano de Gestão de Energia – Responsável por gerir como os nós sensores fazem uso da sua

energia.

Plano de Gestão de Mobilidade – Detecta e regista todos os movimentos dos nós sensores de

forma a poder manter um caminho de volta ao utilizador e os nós vizinhos poderem saber sempre

quem são os seus vizinhos. Ao saberem sempre quem são os vizinhos, os nós podem gerir o

consumo de energia e quando desempenhar as suas tarefas.

Plano de Gestão de Tarefas – Gere e distribui as tarefas de detecção a serem executadas numa

dada região. Nem todos os nós nessa região terão de realizar as suas tarefas de detecção ao mesmo

tempo. Isto faz com que alguns nós realizem as suas tarefas mais vezes que outros dependendo do

seu nível de energia.

Estes planos de gestão são necessários para que os nós sensores possam operar conjuntamente

fazendo um bom uso da energia disponível, distribuir os dados numa rede sensores móvel e ainda

partilharem recursos entre uns e outros.

A evolução das redes de sensores, em termos de controlo das mesmas, tem sido muito difícil. Mesmo

com toda a evolução nas WSN’s, não existia, até ao verão de 2002, um modo de acesso único a uma

rede completa, ou seja, cada tipo de sensor ou actuador, por ser de fabricantes diferentes, possuía o

seu método de acesso. No final dos anos 90 existiam algumas normas, ligadas ao domínio da

domótica, a nível internacional, como por exemplo Consumer Electronic Bus (CEBus) e LonWorks.

Algumas empresas tiveram inclusivamente a iniciativa de criarem associações, de acesso livre, e

divulgaram as especificações dos seus produtos aos seus membros, como foi o caso da European

Installation Bus (EIB). No entanto os resultados que se previam não se materializaram. A existência

de várias normas dividiu o mercado e continuam a surgir novas tecnologias. Na tentativa de criar um

sistema de acesso único às redes de sensores, Sam Madden, Wei Hong, Joe Hellerstein e Kyle

Stanek desenvolveram o TinyDB. O TinyDB é um sistema de processamento de consulta para extrair

informações de uma rede de sensores TinyOS. Ao contrário de outras soluções que também usam

12

TinyOS, o TinyDB não implica a escrita de código na linguagem C para os sensores, fornecendo uma

maneira simples para especificar os dados que se pretendem extrair, juntamente com outros

parâmetros, tal como é feito em SQL, bem como a taxa a que os dados devem ser actualizados, tal e

qual se faria com uma base de dados tradicional. Passou então a ser possível fazer múltiplas

consultas em simultâneo ao conjunto de nós que constituem uma rede. Estas consultas podem ser

feitas a diferentes taxas de amostragem, sendo possível a troca de informação entre nós de

diferentes tipos. No entanto, a versão disponível do TinyDB já não é compatível com as últimas

versões do TinyOS. Surgiu também uma outra abordagem que permite um acesso único e geral a

uma rede de sensores – o DomoBus. Um dos objectivos deste sistema é ter a capacidade de

endereçar um alargado número de dispositivos e possuir uma vasta rede de serviços a eles

associada. Inicialmente pensado para ser utilizado numa rede de Domótica, tal como o nome sugere,

pode ser aplicado a qualquer rede de sensores/actuadores. Os maiores benefícios a retirar de uma

rede de sensores automatizada são o conforto, a segurança e uma melhor gestão da energia.

Em seguida serão abordadas algumas das soluções normalizadas mencionadas acima e

posteriormente será detalhado o sistema DomoBus.

2.2 Sistemas Domóticos Normalizados

2.2.1 X10

X-10 é o protocolo mais antigo usado nas aplicações domóticas. Dado que o X-10 utiliza as linhas

eléctricas da habitação não é necessário instalar novos cabos para interligar os dispositivos. Visto

estar no mercado há algumas dezenas de anos, os produtos X-10 têm um preço muito competitivo

sendo líderes no mercado residencial Norte-Americano. O facto de ser a tecnologia mais acessível

para a realização de uma instalação domótica não complexa, faz com que seja também a mais

procurada [14][17]. Na Figura 2.5 podem ver-se três dispositivos que utilizam a tecnologia X10.

O protocolo X-10 usa uma modulação muito simples estando dependente do ciclo da onda sinusoidal

de 50hz (60hz nos EUA) para introduzir, um instante depois de esta cruzar o zero, um sinal muito

curto numa frequência fixa.

Os transmissores podem comandar até 256 receptores, os quais estão dotados de dois pequenos

comutadores giratórios, um com 16 letras e o outro com 16 números, que permitem identificar

univocamente um dos 256 valores possíveis, no entanto estes não são muito fiáveis pois não

permitem ter a garantia de que foram recebidos os comandos. Qualquer receptor pode receber

ordens de diferentes transmissores. Já os dispositivos bidireccionais, embora muito raros, têm a

capacidade de responder e confirmar a realização correcta de uma ordem (feedback), a qual pode ser

muito útil quando o sistema X-10 estiver ligado a um programa de visualização que mostre os estados

em que se encontra a instalação [18].

13

Figura 2.5 – Exemplo de três dispositivos X10.

2.2.2 EIB/KNX

O EIB é um sistema de automação desenvolvido por um conjunto de empresas líderes no Mercado

Europeu do material eléctrico com o objectivo declarado de criar um sistema que constitua uma

barreira às importações de produtos e sistemas semelhantes que estavam e estão a ser produzidos

noutros mercados, e criar um standard Europeu, promovendo assim a comunicação entre todos os

dispositivos de uma instalação [13][14].

O KNX passou a ser uma norma internacional, de forma a não se restringir apenas ao mercado

europeu e promovendo a compatibilidade com o Batibus e a EHS.

Possuindo uma arquitectura descentralizada, o EIB/KNX define uma relação elemento-a-elemento

entre os dispositivos, permitindo a distribuição de dados entre os sensores e actuadores instalados

sem a necessidade de um controlador central.

Este sistema tem possibilidade de comunicação em diferentes meios físicos, tais como, comunicação

através da rede eléctrica, par entrançado, radiofrequência, infra-vermelhos.

2.2.3 Batibus

Batibus foi certificado como standard europeu pelo Comité Européen de Normalisation

Electrotechnique (CENELEC). Utiliza um cabo blindado do tipo telefónico e admite as topologias em

bus, estrela, anel ou árvore ou qualquer combinação destas. A única indicação a respeitar é não

atribuir endereços físicos idênticos a dois dispositivos da mesma instalação. É um protocolo

totalmente aberto, podendo ser implementado por qualquer empresa. Neste protocolo todos os

dipositivos “ouvem” tudo o que circula no bus, todos eles processam a informação recebida, mas só

aqueles que tiverem sido programados irão filtrar a mensagem e enviá-la à aplicação existente no(s)

dispositivo(s) destino. O endereço é atribuído através de micro interruptores ou mini-teclados [13][14].

14

2.2.4 European Home System Association (EHSA)

O EHSA foi desenvolvido pela indústria europeia de microprocessadores, com o suporte da Comissão

Europeia, criando uma tecnologia que permite a implantação da domótica no mercado residencial. O

objectivo principal é cobrir as necessidades da automação da maioria das habitações europeias cujos

proprietários não têm capacidade de adquirir sistemas de maior capacidade, como são os casos do

EIB e Lonworks, e que obrigam a recorrer a mão-de-obra especializada para a sua instalação. Apesar

de ser um protocolo totalmento aberto, é uma tecnologia que de momento não tem expressão em

termos de aceitação do mercado [13][14].

2.2.5 Konnex

Konnex é uma iniciativa promovida por três associações europeias, European Installation Bus

Association (EIBA), BCI e EHSA, com o objectivo de criar um único standard Europeu para a

automação de edifícios e habitações [14]. Esta iniciativa teve como principais objectivos, criar um

único standard para a automação de edifícios e habitações que abranja todas as necessidades e

requisitos das instalações profissionais e residenciais a nível europeu, melhorar as prestações dos

diversos meios físicos de comunicação nomeadamente no que respeita a tecnologia radiofrequência,

integrar mais serviços, passando isto por envolver as empresas fornecedoras de serviços, como as

de telecomunicações e as de electricidade [13]. A criação do Konnex pretende ainda constituir uma

concorrência capaz de competir quer em qualidade, como em desempenho e preços, com outros

sistemas como o Lonworks ou o CEBus.

Este modelo pode ser implementado usando rede por cabo ou sem fios. Dentro das redes por cabo

existem cinco variantes: duas por pares de condutores, a primeira usa a norma EIB/KNX equivalente

e a segunda usa a norma Batibus equivalente; duas por correntes portadoras, uma usando a norma

EIB/KNX equivalente e a outra usando a norma EHS equivalente; e ainda uma por ligação Ethernet,

aproveitando a norma EIB.net. No que respeita a implementação sem fios, esta é efectuada por

radiofrequência, fazendo uso da norma EIB.RF.

2.2.6 LonWorks

A LonWorks surgiu em 1992, apresentada pela Echelon Corporation. É uma tecnologia usada

essencialmente em edifícios administrativos, hotéis e indústrias, devido ao seu elevado custo. Tal

como algumas das soluções já apresentadas é um sistema aberto e qualquer fabricante que queira

fazer uso desta tecnologia sem depender de sistemas proprietários é livre de o fazer, estando limitado

ao uso de circuitos integrados – Neuron Chip – desenvolvidos pela Echelon. O circuito Neuron inclui

15

vários microcontroladores e está representado na Figura 2.6. Tanto este circuito integrado como o

firmware que implementa o protocolo LonTalk foram desenvolvidos em 1990. Neste sistema os

dispositivos comunicam entre si enviando mensagens que contêm o destinatário, informação para o

encaminhamento, dados de controlo, assim como os dados da aplicação do utilizador e um código

para detecção de erros de transmissão. Os dados podem existir sob a forma de mensagens explícitas

ou variáveis de rede, sendo as primeiras a forma mais simples de enviar e receber dados entre duas

aplicações residentes em Neuron Chips de uma rede LonWorks, enquanto as segundas

proporcionam um modelo estruturado para troca automática de dados. As variáveis de rede, embora

menos flexíveis que as mensagens explicitas, evitam que o programador da aplicação distribuída

esteja dependente dos detalhes das comunicações [15][16].

Figura 2.6 – Dispositivo LonWorks equipado com um Neuron Chip.

2.2.7 CEBus

A tecnologia CEBus é uma norma desenvolvida nos Estados Unidos da América, tendo sido

normalizado pela Electronic Industries Association (EIA). Apresenta algumas semelhanças com

outras tecnologias, nomeadamente o EIB/KNX, podendo ser implementada sobre fios de par

entrançado, corrente eléctrica, cabo coaxial, fibra óptica, radiofrequência e infra-vermelhos. A sua

topologia é flexível, ou seja, um dispositivo pode ser instalado em qualquer localização em que seja

conveniente e ligado a qualquer meio físico, desde que contenha uma interface CEBus apropriada. O

mecanismo de interacção entre aplicações, ou Common Application Language (CAL), é mais

poderoso que os análogos de outras tecnologias, uma vez que as mensagens enviadas podem ser

programas que correm no nó destino [14].

16

2.3 Sistema DomoBus

O sistema DomoBus foi desenvolvido pelo Professor Renato Nunes com o intuito de ultrapassar

várias dificuldades ao tentar utilizar diferentes produtos para efeitos de testes e experimentação e

consiste numa abordagem à domótica que intervém a dois níveis:

• Gestão e supervisão domóticas usando uma abordagem flexível e que oferece suporte à

interoperação com outras tecnologias domóticas.

• Comando e monitorização domótica com interface directa com o meio físico através de

sensores e actuadores adequados.

Tem como objectivo principal permitir a interacção com uma rede de sensores de um modo genérico

e flexível, permitindo representar de forma abstracta qualquer dispositivo. Pretende-se que essa

representação seja tão simples quanto possível, mas suficientemente flexível para poder descrever

as capacidades essenciais de um dispositivo e ser independente da sua tecnologia [9]. Embora tenha

sido criado a pensar nos sistemas de domótica, pode ser adaptado a outras redes de sensores e

actuadores.

2.3.1 Modelo de abstracção de dispositivos

No modelo DomoBus cada dispositivo é definido por um conjunto de propriedades, cada uma com um

dado valor. Apresentam-se em seguida alguns exemplos. Um sensor de temperatura pode ser

representado apenas por uma propriedade - a temperatura - que contém o valor da temperatura

medida pelo sensor; uma lâmpada pode ser representada por duas propriedades - o seu estado

(ligada/desligada) e a sua intensidade (0 a 100, por exemplo); um televisor pode ter quatro

propriedades - o estado (ligado/desligado), o canal em que se encontra, o volume de som e o modo

de muting - considerando-se apenas as funções mais óbvias e úteis, embora se pudessem usar

propriedades adicionais para explicitar, por exemplo, o brilho, o contraste, os agudos e os graves. Na

Figura 2.7 estão representados os principais atributos deste modelo para os dispositivos.

17

Figura 2.7 – Modelo de um dispositivo DomoBus

Com este modelo, os dispositivos de uma rede de sensores podem ser agrupados em classes,

possibilitando diferentes maneiras de interagir com a rede, sendo estas: Propriedade, Serviço, ou

mesmo Zona (em que se encontra). Passa então a ser possível requisitar uma listagem de, por

exemplo, todos os dispositivos que pertençam à iluminação ou todos os dispositivos que se

encontram na zona “Cozinha”.

É possível interagir com a rede de sensores de diferentes modos. Começando pela classe Serviço,

esta permite agrupar tipos de dispositivos que partilham uma relação funcional, podendo esta ser a

iluminação, climatização, segurança, entretenimento, etc. Os dispositivos, para além de poderem

possuir mais do que uma propriedade, podem também estar associados a mais do que um serviço.

Um exemplo disso são os sensores de presença que podem estar associados quer ao serviço de

segurança (detecção de intrusos) quer ao serviço de iluminação (iluminação de uma determinada

área quando é detectada a presença de pessoas). De referir ainda que não existem limitações quanto

ao número de dispositivos associados a um dado serviço, sendo esta classe útil para quando um

utilizador pretender aceder a todos os dispositivos que apresentem uma determinada funcionalidade,

como por exemplo aceder a todos os dispositivos que estão associados à climatização, que irá incluir

aquecedores, sensores de temperatura e aparelhos de ar condicionado.

Como foi descrito acima, cada dispositivo pode apresentar uma ou mais propriedades, sendo possível

que uma propriedade esteja representada em mais do que um dispositivo, o que nos permite também

agrupar os dispositivos por TipoPropriedade, sendo esta particularidade muito útil pois permite

partilhar propriedades que são comuns a múltiplos dispositivos. Exemplos são, todos os dispositivos

que tenham a propriedade EstadoLigadoDesligado, ou os que possuam um canal ou uma

temperatura. Os principais atributos desta classe encontram-se representados na Figura 2.7. O

atributo Nome contém a designação do tipo de propriedade, podendo tomar valores tais como

temperatura, intensidade luminosa e canal. Para cada tipo de propriedade é possível definir um modo

de acesso que pode assumir valores tais como só-leitura, só-escrita, ou leitura-escrita. Esta

diferenciação nos modos de acesso deve-se ao facto de, por exemplo, num sensor de temperatura só

fazer sentido haver leitura, enquanto a intensidade luminosa de uma lâmpada pode ser lida e escrita,

mas também porque um utilizador poderá estar condicionado ao seu nível de acesso a essa

18

propriedade (este aspecto será abordado com maior pormenor mais à frente). Embora não tenha sido

ainda claramente expresso, neste momento deverá ser aparente que o modelo proposto assume que

todas as interacções com os dispositivos físicos são realizadas exclusivamente lendo ou escrevendo

valores em propriedades. Outro atributo de TipoPropriedade é TipoValor, que permite distinguir três

tipos de valores: Escalar, Enumerado e Vector.

O tipo Escalar identifica um valor que pode variar entre um valor mínimo (ValorMin) e um valor

máximo (ValorMax). Esse valor pode ter um certo tipo de unidades (Célsius, Watt, Lux, etc.), pode

corresponder a uma percentagem (0 a 100) ou simplesmente não possuir unidades, sendo essa

informação especificada no atributo Unidades. Um valor escalar pode ainda estar sujeito a um

processo de conversão (indicada por TipoConv), caso em que existirá uma associação a uma classe

Conversão a qual contém a expressão simbólica a usar. Esta possibilidade é útil em múltiplas

situações. Por exemplo, considere-se que a temperatura é medida com uma precisão de um décimo

de grau, mas é representada por um inteiro. Neste caso, uma gama de temperaturas entre -25,0ºC e

60,0ºC seria representada por um valor entre -250 e 600, pelo que e expressão de conversão seria

simplesmente 0,1*x.

Nalguns casos uma propriedade pode ter apenas um pequeno número de valores. Por exemplo, a

propriedade EstadoLigadoDesligado pode assumir apenas os valores 0 (desligado) e 1 (ligado).

Relativamente ao estado de funcionamento de um aparelho de ar condicionado, podem-se considerar

quatro possibilidades: desligado (0), ventilar (1), arrefecer (2), aquecer (3). Para estes casos, e outros

semelhantes, é muito mais amigável usar uma designação para representar o valor da propriedade

do que o respectivo valor numérico. Com esse objectivo, foi criado o tipo Enumerado. Quando uma

propriedade é deste tipo, ela estará associada a, pelo menos, dois objectos da classe Enumerado. O

atributo Designação dessa classe contém o nome associado a um dado valor.

Uma propriedade pode também ser do tipo Vector. Este tipo é usado em propriedades que contêm

uma lista de valores (representando um texto ou outro tipo de informação).

Verifica-se que estamos perante um modelo base muito flexível e eficaz. Após a definição dos tipos

de dispositivos existentes, torna-se simples adicionar os dispositivos concretos que se pretendem

instalar numa dada rede de sensores. A definição dos tipos de dispositivos pode ser reutilizada em

múltiplas situações, só necessitando ser modificada caso se torne necessário representar um novo

dispositivo.

Este modelo permite ainda representar o tempo, que é uma entidade fundamental na definição de

programações horárias. Consideramos que existe um dispositivo relógio, caracterizado por possuir as

seguintes propriedades: minutos, horas, dia da semana, dia, mês e ano. É claro que podem ser

usadas outras propriedades para representar, por exemplo, se é dia ou é noite, se o presente dia é

um feriado ou um dia normal. A capacidade de representar o relógio exactamente da mesma forma

que qualquer outro dispositivo é muito importante para permitir oferecer um modo genérico e

totalmente uniforme de programação do comportamento de um sistema.

19

2.3.2 Nível de monitorização e controlo

O nível de monitorização e controlo é essencialmente composto por módulos de controlo (Control

Modules – CM) interligados por uma rede, permitindo-lhes interagir e comunicar entre si [12]. Os

módulos de controlo podem estar ligados a um ou mais módulos de supervisão (Supervision Modules

– SM),

Os CM são placas com microprocessadores que se conectam directamente a interruptores, sensores

de temperatura, receptores de infravermelhos e outros dispositivos de “input”. Estes controlam

dispositivos eléctricos e electrónicos podendo, por exemplo, ajustar a intensidade de lâmpadas ou

ligar e desligar pequenos motores, electrodomésticos, aquecedores eléctricos ou sistemas de ar

condicionado, ou ainda executar acções mais específicas como gerar sinais de infravermelhos para

comandar televisões ou sistemas Hi-Fi. Os CM actuais são bastante flexíveis, uma vez que utilizam

micro controladores que incluem código, memória de dados e vários periféricos para efeitos de

temporizações e comunicação. Cada CM possui um transmissor/receptor (EIA-485) e interfaces para

leitura de interruptores e outros dispositivos físicos, podendo executar diferentes aplicações e

consequentemente executar várias funcionalidades. Assim sendo, uma solução domótica através

deste sistema pode tornar-se economicamente mais vantajosa, permitindo que um CM controle

diversos dispositivos, visto que nos outros sistemas domóticos existentes, um módulo de controlo

está associado, tipicamente, a um único dispositivo. Num sistema EIB/KNX típico, um interruptor de

parede, por exemplo, é composto por um módulo que incorpora um micro-controlador, com

periféricos, fonte de alimentação, hardware de comunicação e o próprio interruptor em si. Por outro

lado, o sistema DomoBus usa um CM, separado do interruptor físico, e que pode logo tratar, por

exemplo, oito interruptores eléctricos comuns. Esta aproximação permite pois o uso de interruptores

normais, com as características e aspecto que sejam mais do agrado dos utilizadores, tornando o

sistema global mais barato e vantajoso.

20

Figura 2.8 - Arquitectura do sistema DomoBus

A rede DomoBus do nível de monitorização e controlo pode ser decomposta em vários segmentos

que podem ser interligados entre si através de uma linha backbone e módulos de routing (módulos R

representados na Figura 2.8). Tal permite expandir o sistema e suportar maiores níveis de tráfego na

rede, pois comunicações que circulam dentro de um segmento não afectam as comunicações dos

outros segmentos.

Os SM são responsáveis pela gestão e supervisão do sistema e podem ser implementados usando

PCs comuns ou embebidos, ou Single Board Computers (SBC) correndo Linux. Estes recebem

informação dos CM e, de acordo com regras e comportamento pré-estabelecido, processam a

informação recebida, enviando posteriormente aos CM a resposta adequada. Um sistema pode ser

composto por vários SM dependendo do número de dispositivos que compõem a rede. Uma pequena

rede, pode conter apenas um SM, mas no caso de uma rede de larga escala, pode existir um SM por

cada segmento. Esta abordagem permite uma supervisão distribuída da rede trazendo benefícios no

que diz respeito a tempos de resposta e fiabilidade da rede, eliminando pontos únicos de falha. Os

SM de uma rede podem ainda trocar informação entre si para coordenar respostas a um determinado

evento. Eventualmente, esta troca de informação pode ser executada através de uma rede diferente

(Ethernet ou WLAN, por exemplo). Esta funcionalidade dos SM permite ainda interacção com outros

sistemas, permitindo atingir soluções integradas envolvendo diferentes tecnologias.

2.3.3 Endereçamento de dispositivos

Na rede DomoBus, no nível de monitorização e controlo, o endereçamento dos dispositivos físicos é

feito utilizando endereços de 16 bits tal como mostra a Figura 2.9. Os 12 bits mais significativos do

21

endereço identificam a Aplicação de Controlo e os últimos 4 bits identificam o dispositivo gerido por

essa aplicação. A identificação da aplicação de controlo pode ser interpretada como possuindo uma

estrutura hierárquica em que os 4 bits mais significativos identificam um segmento de rede

(permitindo um máximo de 16 segmentos), os 5 bits seguintes identificam um nó localizado nesse

segmento (com um máximo de 32 nós por segmento) e os 3 bits menos significativos identificam uma

tarefa dentro de um nó (podem existir até 8 tarefas). Cada tarefa controla até 16 dispositivos

(identificados por 4 bits).

No nível de supervisão o endereçamento é feito utilizando 32 bits em que os 16 bits mais

significativos servem para identificar aplicações de gestão, supervisão e gateways, e os 16 bits

menos significativos são os usados para endereçamento de dispositivos físicos, tal com foi referido

anteriormente. Na Figura 2.10 encontra-se ilustrado o endereçamento completo num sistema

DomoBus.

Figura 2.9 – Endereçamento de um dispositivo na red e DomoBus.

Figura 2.10 – Endereços na rede DomoBus.

As mensagens trocadas no sistema DomoBus, no nível de supervisão, têm o formato ilustrado na

Figura 2.11 em que o primeiro campo indica o tipo de mensagem, depois vêm os endereços de

origem e destino, um número de sequência, o tamanho dos dados e finalmente os dados. Estes

dados podem incluir informação em formato específico trocado entre as aplicações do nível de gestão

ou mensagens de controlo que explicitam uma propriedade de um dispositivo, a operação a realizar e

um valor.

Figura 2.11 – Formato das mensagens entre aplicaçõe s e a rede DomoBus.

O formato do campo de dados das mensagens usadas na interacção com dispositivos domóticos

(nível de monitorização e controlo) está ilustrado na Figura 2.12. Existe um campo de controlo (CTR)

22

que contém informação sobre a prioridade P), se é uma retransmissão (R), se é uma resposta a uma

mensagem anterior (ANS) e o tipo de mensagem (opCode), estando já definido os seguintes tipos:

GET, SET, REPORT e FORWARD.

Figura 2.12 – Estrutura do campo “data” de uma mens agem DomoBus.

Para o caso dos tipos de mensagens pré-definidas o formato do campo de payload é o indicado na

Figura 2.13 e inclui a identificação do dispositivo, a propriedade e o valor que se quer ler ou definir ou

reportar. Numa mensagem podem ser enviados múltiplos pares propriedade-valor.

Figura 2.13 – Formato das mensagens pré-definidas.

23

Para mensagens do tipo FORWARD o campo Device é substituído pelo campo DeviceAddress que

corresponde a um endereço completo de 16 bits, como se encontra apresentado na Figura 2.14. Este

endereço completo identifica o dispositivo a que se referem as propriedades e que será diferente de

quem está a enviar a mensagem. Com as mensagens FORWARD é possível ter um dispositivo A a

enviar mensagens para um dispositivo B mas que se refere a propriedades de um dispositivo C. Este

endereço C é o que irá no campo DeviceAddress.

Figura 2.14 – Formato da mensagem do tipo Forward.

A interligação com diferentes tecnologias domóticas é efectuada através de aplicações Gateway

específicas que correm nos Módulos de Supervisão. Uma Gateway traduz a lógica de funcionamento

do DomoBus nas operações específicas suportadas por uma dada tecnologia. As gateways tratam da

conversão dos endereços e dos comandos das diferentes tecnologias. Cada gateway possui uma

tabela de conversão de endereços para a tecnologia de destino e uma tabela com a informação de

como serão convertidas as mensagens recebidas numa tecnologia para o sistema DomoBus. É ainda

possível dispor de algum tipo de inteligência que faça com que certas funcionalidades presentes no

DomoBus tais como avisos periódicos do valor de um sensor sejam possíveis mesmo em tecnologias

que não o suportem.

2.4 Mensagens Instantâneas

As mensagens instantâneas ou Instant Messaging (IM) surgiu como uma aplicação de consumo,

tendo como pioneiro a AOL, no início dos anos 90. Em 1996 os serviços Buddy List, pertencente à

AOL, e o ICQ (I Seek You) tornaram o IM num fenómeno de popularidade. Hoje em dia é usado por

milhões de utilizadores e dispõe de um grande número de protocolos sendo os mais populares e mais

usados o Microsoft Messenger, Yahoo Messenger, Google Talk, ICQ, Internet Relay Chat (IRC) e

Skype.

O IM, tal como o nome indica, é um serviço de mensagens instantâneas que permite que dois ou

mais utilizadores troquem mensagens, em tempo real, o que não é possível com o e-mail. A ligação a

estes serviços pode ser ponto-a-ponto ou através de um servidor. A ligação mais usual é através de

um servidor, pois implica menores conhecimentos informáticos, sendo um processo bastante simples

para um utilizador comum. Detalham-se em seguida os aspectos mais relevantes dos dois tipos

possíveis de ligação.

24

Ligação ponto-a-ponto

A ligação ponto-a-ponto é feita directamente entre os dois utilizadores que pretendem comunicar. É

necessário que um utilizador saiba o endereço exacto de quem pretende contactar. Uma vez que o

endereço IP para grande número dos utilizadores não é estático, particularmente porque já é possível

aceder à internet em quase todo o lado. Variando o IP consoante o local em que um utilizador se liga,

isso torna este tipo de comunicação mais complicado. Os sistemas operativos da Microsoft tinham um

serviço de mensagens ponto-a-ponto: usando a linha de comandos podia-se enviar mensagens

através do serviço net send. Uma vez que não era necessária qualquer autorização para um utilizador

enviar mensagens a outro, muitas empresas começaram a usar este serviço para enviar publicidade

aos utilizadores e a Microsoft acabou por retirar este serviço a partir da actualização Service Pack 2

do seu sistema operativo Microsoft Windows XP. Este tipo de ligação não permite ao utilizador

seleccionar quem está autorizado a contactá-lo e é muito complexo o processo de saber para que

endereço enviar as mensagens, em caso de querer contactar algum utilizador específico. Como tal,

não é um serviço interessante no âmbito deste trabalho.

Ligação através de um servidor

O utilizador liga-se através de um protocolo a um dos servidores disponíveis. Exceptuando o IRC, o

processo de ligação a um determinado protocolo requer que o utilizador registe uma conta. Este

registo de conta implica que o utilizador forneça alguns dados, nomeadamente o seu endereço de e-

mail, que vai corresponder ao nome de utilizador usado para aceder ao serviço. Este registo implica

ainda que o utilizador, na maior parte dos casos, aceda a essa conta de e-mail e, através de uma

mensagem recebida com os dados de activação da conta registada, comprove que é realmente o

dono dessa conta de e-mail.

Finalizado este processo é então possível proceder à ligação. Para isso o utilizador tem de introduzir

o seu nome de utilizador e a palavra passe escolhida aquando do registo da sua conta numa

aplicação cliente ou através do browser, caso exista essa possibilidade por parte do protocolo. Depois

de efectuada a ligação é apresentada uma janela com a lista de contactos, entre outras opções que o

cliente possa ter, como escolher o nome que será apresentado aos utilizadores ligados a si.

A lista de contactos funciona através de um sistema de notificação de presença, ou seja, sempre que

um utilizador altera o seu estado, todos os utilizadores que o tenham na sua lista de contactos são

informados dessa alteração. Quando um utilizador não está ligado, o seu estado é apresentado como

desligado, enquanto, quando este se encontra ligado, existem alguns estados possíveis, tais como,

simplesmente ligado, disponível (pretendendo indicar que este se encontra disponível para

estabelecer uma conversação), ausente (indica que não se encontra presente), ou ocupado (que

indica que de momento não está disponível para comunicar).

Para se adicionar um contacto à lista de contactos, nestes protocolos de IM, é necessário que um

utilizador faça um pedido para adicionar o outro à sua lista e que ele aceite esse pedido. Só a partir

25

do momento que o pedido seja aceite e, como consequência, os dois utilizadores passem a ter o

contacto um do outro nas suas listas, é que as notificações de presença são enviadas entre estes.

Verifica-se assim que, nestes protocolos, existe uma certa privacidade para o utilizador, uma vez que,

apenas as pessoas por si autorizadas podem ter informação sobre o seu estado, bem como entrar

em contacto com o mesmo. A partir deste momento é então possível proceder-se à troca de

mensagens entre utilizadores em tempo real, caso estes se encontrem ligados. É possível nalguns

destes serviços enviar mensagens quando o utilizador de destino não se encontra ligado, porém não

se diferencia de uma mensagem de e-mail uma vez que não se sabe se este a recebe, nem quando a

recebe.

Clientes

Um cliente é uma aplicação usada para se efectuar ligação através do protocolo pretendido. Para

cada um dos protocolos existe uma aplicação própria disponibilizada pelos criadores desse mesmo

protocolo. Existem também clientes que permitem estabelecer ligações a diferentes protocolos,

podendo alguns estabelecer ligações tanto a mais do que uma conta de um mesmo protocolo, como

a contas de diferentes protocolos em simultâneo.

Protocolos

Existem vários protocolos implementados para o uso de IM. Para a escolha do protocolo a usar para

a realização deste trabalho consideraram-se algumas características como a sua complexidade, ser

proprietário ou público, se é simples de usar e ter uma ideia do número de utilizadores, que poderá

tornar a utilização desse protocolo numa opção viável ou não. Os protocolos com maior número de

utilizadores e que foram alvo de maior atenção foram o Internet Relay Chat (IRC), OSCAR protocol,

Yahoo Messenger (YMSG), Microsoft Notification Protocol (MSNP), Skype Protocol e o Extensible

Messaging and Presence Protocol (XMPP). Atendendo a que um dos principais objectivos é poder

haver comunicação com a rede de sensores a partir de qualquer computador ligado à internet sem ter

de se instalar qualquer aplicação, este poderá ser um factor de exclusão. No entanto, existe

possibilidade de estabelecer ligação a qualquer um destes protocolos através de um browser de

internet pelo que nenhum foi excluído por este motivo.

IRC

No caso do IRC, como foi dito anteriormente, o processo é diferente. O utilizador não tem

necessariamente de se registar para poder estabelecer ligação, escolhe uma alcunha que poderá ser

registada opcionalmente, em alguns servidores. Isto torna logo o serviço muito diferente dos

26

restantes. Enquanto nos outros casos o registo é feito através de um nome de utilizador, que

corresponde ao e-mail do utilizador, podendo este depois escolher o nome que será apresentado aos

restantes utilizadores, que não tem necessariamente de ser diferente de todos os outros. No caso do

IRC, o registo é feito através do nome que será visto pelos outros utilizadores. Isto faz com que o

nome com que um utilizador fica visível para todos os outros seja único, podendo estar protegido por

uma palavra passe. No que respeita a servidores, o IRC tem também um funcionamento bastante

diferente dos outros protocolos. Existe um grande número de servidores neste protocolo não tendo, a

maioria destes, qualquer tipo de ligação de uns para os outros. Sendo assim, dois utilizadores para

contactarem um com o outro, não precisam de estar apenas a usar o mesmo protocolo, mas também

têm de estar ligados ao mesmo servidor ou, pelo menos, a dois servidores que estejam ligados entre

si.

É importante referir ainda que o IRC foi criado usando uma filosofia de comunicação diferente dos

outros protocolos mencionados. O tráfego de mensagens é realizado, em grande parte, em salas de

conversação, ou seja, enquanto nos outros protocolos a conversação é feita principalmente entre dois

utilizadores, neste caso é feita entre grupos de utilizadores. Pode-se mesmo assim estabelecer

conversações privadas entre dois utilizadores no IRC. No entanto, a privacidade é muito reduzida em

relação aos outros protocolos, qualquer utilizador pode saber o estado de outro, bem como entrar em

contacto com quem entender.

Tendo sido um dos primeiros IM usados por uma grande comunidade de utilizadores, o IRC, que foi

criado em 1988, tem uma interface pouco user-friendly quando comparado com os clientes

disponibilizados pelos restantes protocolos. Os comandos, regra geral, têm de ser inseridos

manualmente, sendo necessário conhecer bem as funções disponibilizadas. O utilizador não possui

uma lista de contactos. Alguns clientes implementaram um serviço de notificação de presença, mas

essas notificações estão associadas às alcunhas dos utilizadores. Como já foi mencionado, para que

pertença a um utilizador em específico, a alcunha tem de ser registada no servidor e o utilizador que

pretenda a notificação tem de estar nesse mesmo servidor. Estando noutro servidor receberá

notificação em caso de presença dessa alcunha, podendo não se tratar do mesmo utilizador.

MSN

O MSN é um dos serviços mais usados em Portugal. Para se utilizar este serviço, o utilizador tem de

registar uma conta de e-mail no serviço Windows Live ID. Inicialmente essa conta tinha de ser

obrigatoriamente pertencente a um de dois serviços de e-mail, hotmail ou msn, mas actualmente é

possível registar contas de qualquer servidor de e-mail. Depois de registado o utilizador pode

começar a usar o serviço de IM. O MSN permite, para além da troca de mensagens instantâneas, a

troca de ficheiros, conversação áudio e vídeo, partilha de aplicações e assistência remota, caso se

esteja a usar o cliente criado pela Microsoft. No que toca a outros clientes, eles permitem usar muitas

das funcionalidades, mas não todas. No caso do utilizador querer usar o serviço através do browser,

fazendo ligação pelo Windows Live ID, apenas será possível a troca de mensagens instantâneas.

27

Skype

Este serviço, para além de ser um IM, foi criado com o principal objectivo de ser um cliente de Voice

over Internet Protocol (VoIP), ou seja, permite a troca de mensagens instantâneas, bem como

conversações áudio e vídeo e ainda troca de ficheiros, como a maior parte dos protocolos

mencionados. A principal diferença para os outros é permitir conversações com qualquer telefone

através do serviço de VoIP.

Google Talk

O Google Talk utiliza o protocolo XMPP. A Google introduziu este serviço inicialmente embutido no

serviço de e-mail, ou seja, um utilizador ao aceder ao seu e-mail passa a poder trocar mensagens

instantâneas com outros utilizadores que se encontrem também ligados. Posteriormente lançou uma

aplicação cliente para o sistema operativo da Microsoft. No entanto, o foco deste serviço de IM é ser

usado no browser, em conjunto com o serviço de e-mail, tendo mais ferramentas disponíveis do que a

aplicação cliente. Por exemplo, conversações em grupo apenas são possíveis quando se está ligado

através do browser. Estas mensagens podem ser enviadas quando um utilizador não se encontra

ligado, sendo posteriormente recebidas como uma mensagem de e-mail na sua caixa de correio. É

ainda possível realizar conversações áudio e vídeo tanto no cliente de e-mail, como na aplicação

externa ao browser, sendo que na primeira é necessário instalar um plugin para o browser.

XMPP

O protocolo usado no presente trabalho é o Extensible XMPP [19]. O XMPP consiste num conjunto de

tecnologias “abertas” para IM, notificação de presenças, chat entre vários utilizadores, chamadas de

voz e vídeo e encaminhamento geral de dados XML. Foi originalmente desenvolvido pela

comunidade Jabber de open-source para proporcionar um diálogo livre, seguro, livre de spam,

tornando-se uma alternativa descentralizada aos serviços de IM fechados que existiam até ao

momento. O XMPP oferece então algumas vantagens importantes relativamente a esses outros

serviços:

Aberto – O protocolo XMPP é aberto, de uso livre, público e facilmente compreensível. Além disso

existem várias implementações ao nível de clientes, servidores, componentes de servidores e

bibliotecas de código.

Normalizado – a Internet Engineering Task Force (IETF), formalizou o núcleo de protocolos

streaming XML, aprovado como uma tecnologia de mensagens instantâneas e de presença. As

28

especificações XMPP foram publicadas como RFC 3920 e RFC 3921, em 2004, e a XMPP Standards

Foundation continua a publicar muitos XMPP Extension Protocols (XEP).

Comprovado – as primeiras tecnologias Jabber / XMPP foram desenvolvidas por Jeremie Miller em

1998 sendo agora bastante estáveis. Hoje em dia existem centenas de programadores a trabalhar

nestas tecnologias, existindo centenas de milhares de servidores Jabber a funcionar na internet e

milhões de pessoas usam o XMPP para IM através de servidores públicos, como é o caso do Google

Talk e implementações de XMPP existentes em empresas de todo o mundo.

Descentralizado – a arquitectura da rede XMPP é semelhante à do e-mail, permitindo que qualquer

um possa correr o seu próprio servidor XMPP, tornando assim possível que indivíduos ou

organizações possam tomar controlo absoluto das suas comunicações.

Seguro – qualquer servidor XMPP pode ser isolado da rede pública (correndo, por exemplo, numa

intranet de uma empresa). O núcleo das especificações XMPP inclui mecanismos de segurança

robustos fazendo uso de Simple Authentication Security Layer (SASL) e Transport Layer Security

(TLS). De referir ainda que a equipa de desenvolvimento do XMPP se encontra a trabalhar na

capacidade de encriptação ponto-a-ponto de forma a elevar o nível de segurança.

Extensível – usando as capacidades do XML, qualquer um pode construir funcionalidades por cima

do núcleo de protocolos. Com o objectivo de manter a interoperabilidade, extensões comuns são

publicadas nas XEP. No entanto tal publicação não é necessária e as empresas podem manter as

suas próprias extensões se assim o desejarem.

Flexível – as aplicações XMPP, para além de IM, incluem serviços como gestão de redes,

organização de conteúdos, ferramentas de colaboração, partilha de ficheiros, jogos, monitorização

remota de sistemas e muito mais.

Diversificado – Existe um alargado número de empresas e projectos de open-source que usam o

XMPP para construir e implementar serviços e aplicações que comunicam em tempo-real.

2.4.1 Escolha do protocolo a usar

Todos os protocolos analisados podem ser utilizados a partir de qualquer local, bastando para isso

uma ligação à internet e um browser, não sendo necessário instalar qualquer tipo de aplicação nem

usar um sistema operativo específico para o efeito. No entanto, apenas um destes protocolos é não

proprietário, estando o seu código disponível e permitindo que quem queira possa criar uma

aplicação e/ou correr um servidor criado por si, se assim o entender. O protocolo XMPP dispõe de

todas as funcionalidades necessárias para a realização deste trabalho, permitindo ainda

desenvolvimentos futuros na monitorização e controlo de redes de sensores. No caso do IM da

Google, que faz uso do XMPP como foi referido anteriormente, o protocolo é usado de forma

integrada com o e-mail permitindo uma diferente abordagem ao serviço de notificações em que estas

estão sempre activas. Atendendo às características apresentadas, a nossa escolha recaiu sobre o

uso do protocolo XMPP no desenvolvimento do gateway.

29

Capítulo 3

Descrição da Solução

30

3. Descrição da Solução

O IM (instant messaging) é um sistema que tem vindo a crescer em larga escala nas últimas duas

décadas quer a nível de utilizadores, como a nível das aplicações e protocolos disponibilizados a

estes. Este sistema disponibiliza uma comunicação em tempo real entre utilizadores, através de

mensagens escritas, bastante fácil de usar.

O sistema DomoBus permite disponibilizar uma interacção com qualquer rede de sensores, de forma

bastante versátil, simples e poderosa, tirando partido do seu modelo de abstracção de dispositivos.

Até ao momento para se poder monitorizar ou actuar sobre uma rede de sensores que utilizasse o

sistema DomoBus era necessário instalar uma aplicação própria, no local onde o utilizador se

encontrasse.

Pretende-se com este trabalho fazer uso destas duas tecnologias para permitir a qualquer utilizador,

através do uso do protocolo XMPP de IM, monitorizar e actuar sobre uma rede DomoBus a partir de

qualquer local sem a necessidade de instalar qualquer tipo de aplicação. Para além de não ser

necessário instalar aplicações, o sistema de IM oferece ainda a vantagem de se poder estabelecer

uma ligação a partir de qualquer sistema operativo. A aplicação gateway entre o sistema DomoBus e

o sistema de IM foi desenvolvida na linguagem C#.

3.1 Arquitectura da Solução

A aplicação gateway permite interligar o sistema DomoBus ao sistema de IM, recorrendo para tal a

um serviço de directório denominado CommDir. Uma vez estabelecidas as ligações, a aplicação

gateway fica à escuta de mensagens provenientes de qualquer um dos sistemas.

A recepção de uma mensagem proveniente do sistema de IM vai gerar uma resposta automática que

indica como aceder ao menu das opções que estão disponíveis. O utilizador poderá então navegar

pelos menus de maneira a chegar ao dispositivo pretendido e actuar sobre o mesmo. Uma vez

escolhida a acção pretendida, a aplicação irá entrar em contacto com a rede DomoBus para efectuar

essa acção. Na Figura 3.1 encontra-se um esquema da arquitectura da solução desenvolvida.

31

Figura 3.1 – Gateway entre uma rede de sensores e u m sistema de IM

3.2 Funcionalidades Fundamentais

Nesta secção apresenta-se uma descrição das funcionalidades fundamentais necessárias para

interacção entre um utilizador e o sistema DomoBus. Em Anexo apresenta-se uma descrição das

funções C# mais relevantes desenvolvidas no presente trabalho.

3.2.1 Ligação ao Sistema de IM

Como já foi referido, o protocolo XMPP é um protocolo de código aberto. Para a realização deste

trabalho foi utilizada uma biblioteca, para a linguagem C#, disponibilizada pelos responsáveis pela

criação deste protocolo. Analisaram-se algumas aplicações exemplo disponibilizadas na página oficial

do protocolo para se compreender o funcionamento da ligação e os princípios de funcionamento

deste sistema de IM.

A primeira funcionalidade a ser implementada foi a ligação ao servidor. Optou-se por não incluir a

funcionalidade de adicionar ou aceitar novos utilizadores na aplicação, por não se tratar de uma

32

funcionalidade fundamental para o correcto funcionamento desta solução, tendo esta de ser feita

directamente no servidor ao qual pertencer a conta que vai ser utilizada na gateway. Para estabelecer

a ligação, o utilizador tem de possuir uma conta registada num dos serviços de IM que usam este

protocolo, estando a ligação preparada para detectar qual o serviço a que a conta pertence através

do endereço de e-mail usado como nome de utilizador, ou seja, tem resolução automática de

servidor. Uma vez estabelecida a ligação é efectuada a leitura de toda a lista de contactos do

utilizador, sendo essa informação apresentada na janela principal com indicação do estado de cada

um. A aplicação passa de seguida à escuta de mensagens que lhe sejam enviadas.

3.2.2 Envio e Recepção de Mensagens IM

Pretende-se que esta aplicação desempenhe as funcionalidades básicas de um sistema de IM para

comunicação entre utilizadores. A interacção com o sistema é feita então apenas através de

mensagens escritas em tempo real. O sistema está preparado para receber mensagens de qualquer

utilizador que se encontre na lista de contactos respondendo automaticamente com os menus

correspondentes. Foram encontradas algumas dificuldades na execução desta resposta automática.

Inicialmente, ao fim de algumas mensagens trocadas entre a aplicação e o utilizador, deixavam de

existir respostas enviadas pela aplicação, sendo retornada uma mensagem de erro por parte do

servidor. Após a execução de vários testes verificou-se que tal erro se devia a estas respostas serem

sempre devolvidas instantaneamente, havendo uma segurança no servidor para impedir que tal

aconteça. Foi criada uma função que gere o envio de respostas para o utilizador, fazendo um

compasso de espera aleatório, dentro de um intervalo limitado de segundos.

Foi também definida a possibilidade de activar ou desactivar o sistema de janelas de conversação.

Esta funcionalidade foi inicialmente criada para efeitos de teste da funcionalidade do sistema de IM.

No entanto, por permitir monitorizar as mensagens que os utilizadores de IM trocam com a Gateway,

optou-se por manter esta capacidade.

3.2.3 Ligação ao Sistema DomoBus

Conforme foi referido no início deste capítulo, a ligação ao sistema DomoBus é feita recorrendo a um

módulo de comunicações que utiliza um serviço de directório denominado CommDir. A Figura 3.2

ilustra a estrutura das aplicações. Pretende-se garantir que uma mensagem enviada por qualquer

utilizador de IM, sob a forma de mensagem escrita, chega à rede de sensores no formato DomoBus.

Da mesma forma qualquer mensagem enviada pela rede no formato DomoBus deve chegar aos

utilizadores IM sob a forma de uma mensagem escrita perceptível para estes. A correspondência

entre estes dois tipos de mensagem é feita na Gateway IM, recorrendo aos ficheiros XML que serão

descritos na sub-secção 3.4. Neste momento, e para simplificar o teste do sistema, o gateway não

liga directamente a uma rede de sensores (uma vez que o trabalho não se centra na vertente das

33

redes de sensores e sim na comunição com estas) e sim a um simulador que troca mensagens

segundo a lógica DomoBus, permitindo testar a exequibilidade e funcionalidades deste serviço.

GatewayIM

GatewayRede

Sensores

CommDIR

Figura 3.2 – Estrutura das aplicações.

O módulo de comunicação (integrado nas aplicações) e o CommDir foram criados para permitir uma

maior versatilidade nas comunicações entre a rede DomoBus e as aplicações que fazem uso desta.

Tanto a rede DomoBus, como cada uma das aplicações que pretendam trocar informações com esta,

necessitam de se registar no serviço de directório. Para fazer o registo é necessário conhecer o

endereço IP do CommDir e uma porta que esteja disponível para efectuar a ligação. No momento de

fazer esta ligação é indicado o endereço DomoBus da aplicação, o qual será divulgado por todas as

demais aplicações já registadas. As mensagens trocadas posteriormente não passam por este

serviço, servindo este apenas para registos e informar como contactar cada aplicação através da

rede.

A infra-estrutura de comunicação usada corresponde à última actualização efectuada, até à data, ao

sistema DomoBus, tendo trazido maior estabilidade e maior fiabilidade ao sistema. A ligação ao

CommDir é efectuada através do User Datagram Protocol (UDP). Para estabelecer esta ligação

integrou-se uma ferramenta já desenvolvida, para efeitos de teste, que permite troca de mensagens

com a rede DomoBus. Esta ferramenta encontra-se permanentemente à escuta de mensagens

provenientes da rede, tendo-se implementado código para que apenas sejam informados os

utilizadores de IM que explicitamente indiquem à gateway que pretendem receber determinada

informação.

A aplicação desenvolvida (gateway IM) liga-se ao serviço directório, introduzindo-se então os dados

necessários: os endereços IP respeitantes ao CommDir e ao endereço DomoBus que vai ser utilizado

pela aplicação de simulação, tal como os respectivos portos que cada uma vai utilizar para a

comunicação. Uma vez estabelecidas as ligações entre as aplicações DomoBus é possível iniciar-se

a comunicação entre o sistema de IM e a rede de sensores. O utilizador ao seleccionar determinado

dispositivo tem duas maneiras de interagir com ele, podendo pedir o estado actual de determinada

propriedade desse dispositivo ou alterar o estado da mesma. Consoante a acção pretendida é

chamada a função correspondente – GET para pedir o estado actual e SET para alterar o estado.

34

Após o pedido ter sido efectuado será recebida uma resposta que será enviada para o utilizador

através do serviço de IM.

3.3 Interacção com o sistema DomoBus

Nesta secção são descritas as funcionalidades específicas que permitem efectuar uma interacção

com o sistema DomoBus.

3.3.1 Utilizadores

Um utilizador, para ter acesso à rede de sensores, tem de estar necessariamente na lista de

contactos da conta que se encontra ligada à gateway IM, o que constitui assim um primeiro nível de

segurança.

Existe ainda um segundo nível de segurança que é implementado ao nível do controlo de acesso de

cada utilizador. No ficheiro XML que descreve a rede de sensores, no qual estão representados todos

os dispositivos que a constituem, existe um campo que define o nível de acesso a cada dispositivo,

em que, para um utilizador aceder a esse dispositivo, tem de possuir um nível de acesso igual ou

superior ao do dispositivo. Foi criado um ficheiro XML, que está relacionado directamente com a

conta usada para estabelecer a ligação IM, no qual são guardados todos os contactos que este

utilizador possui. Neste ficheiro é guardada a lista de contactos da conta que se encontra ligada

através da gateway, bem como o nível de acesso à rede de cada utilizador pertencente à lista de

contactos. Por omissão o nível é 0, podendo chegar a um valor máximo de 10. A alteração do nível

de acesso dos utilizadores tem de ser efectuada na gateway. Para efectuar essa alteração o utilizador

tem de aceder ao menu de acessos que se encontra na barra de ferramentas da aplicação, como se

encontra apresentado na Figura 3.3, acedendo-se então à janela de alteração de níveis de acesso,

que está representada na Figura 3.4. Este ficheiro é criado na primeira vez que se liga a uma conta

na aplicação, sendo guardado com nome igual ao nome de utilizador da conta, passando a ser

carregado, nas utilizações seguintes, no momento da ligação, podendo ser alterado caso existam

novos contactos.

Os dados de cada utilizador são sempre guardados em memória no momento em que se estabelece

a ligação, ficando guardados num objecto. Para além do nome de utilizador e do correspondente nível

de acesso, são também guardados o seu estado actual e o número de instâncias que estão a ser

usadas, para melhor controlo de quem se liga ou desliga do servidor. O número de instâncias é o

número de aplicações que determinada conta tem ligadas em simultâneo. Este controlo é efectuado

porque, ao desligar uma instância, é enviada a informação de que o utilizador se desligou e, uma vez

35

que podem continuar instâncias ligadas após esta se ter desligado, se não se guardar em memória o

número de instâncias com ligação estabelecida, o estado desse utilizador passaria a apresentar-se

como offline, quando na prática ainda se encontra online com uma, ou mais, instâncias.

Quando a aplicação estabelece ligação ao sistema de IM, após a autenticação, é recebida a lista de

utilizadores pertencentes a esta conta. Os dados de cada utilizador são recebidos um a um e,

guardados em memória. Também é consultado o ficheiro XML para verificar se esse utilizador já se

encontra guardado no mesmo, sendo devolvido o respectivo nível de acesso. Finalizado este

processo, o ficheiro XML é guardado e fechado não sendo mais necessário para esta sessão. Esta

lista de utilizadores é também apresentada na janela principal.

Figura 3.3 – Menu de alteração de níveis de acesso.

36

Figura 3.4 – Janela de alteração de níveis de acess o.

3.4 Rede de Sensores para Domótica

Para representar os dispositivos da rede de sensores são usados dois ficheiros XML - House.xml e

DomoticSystem.xml. Um deles contém as características genéricas dos elementos que compõem a

rede, tais como os tipos de dispositivos existentes, os tipos de propriedades associados a cada tipo

de dispositivo e os tipos de valores de cada propriedade. O outro ficheiro descreve os dispositivos

presentes na rede, bem como as diferentes categorias em que se encontram agrupados, tais como,

serviços, divisões e andares (estas duas últimas categorias permitem explicitar a localização dos

dispositivos).

Este modo de descrever a rede torna este serviço bastante versátil, uma vez que o carregamento

destes ficheiros XML é dinâmico permitindo que a configuração da rede possa ser alterada em

qualquer momento e facilmente se adapte a novas necessidades dos utilizadores. Esta descrição do

sistema é também, tal como a lista de utilizadores, carregada em memória no momento da ligação. A

informação presente nos ficheiros XML permite ainda um mapeamento fácil entre os endereços

DomoBus dos dispositivos e os nomes que o utilizador pretende que lhe sejam apresentados. Para

uma descrição completa da especificação XML usada pelo sistema DomoBus consultar 58[20], no

entanto, serão apresentados os aspectos mais relevantes para facilitar a compreensão.

37

3.4.1 Ficheiro House.xml

É neste ficheiro que se encontra a descrição das características genéricas da rede e dos seus

dispositivos, e onde são definidos os agrupamentos dos dispositivos em diferentes categorias. Todas

estas características da rede encontram-se descritas no primeiro nível de elementos do ficheiro xml.

Os elementos seguintes representam a lista de características que essa categoria apresenta, ou seja,

a lista de serviços, divisões, andares e dispositivos. As categorias Serviços, Divisões e Andares são

representadas pelos elementos ServiceList, DivisionList e FloorList respectivamente, sendo cada

elemento identificado por dois atributos: ID - número correspondente ao elemento em questão; e

Name - nome do elemento, para posteriormente ser apresentado nos menus ao utilizador. Indica-se

em seguida um exemplo da estrutura da informação da categoria Serviços:

<ServiceList>

<Service ID=”1” Name=”Aquecimento”/>

<Service ID=”2” Name=”Iluminação/>

</ServiceList>

Cada dispositivo que se encontra na lista de dispositivos é composto por um conjunto maior de dados

tais como, a que serviços, divisão ou andar pertence, qual o tipo de dispositivo, o seu nível de

acesso, o seu endereço na rede DomoBus. Apresenta-se em seguida a estrutura desta informação:

<DeviceList>

<Device ID="1" RefDeviceType="1" Name="Candeeiro-Mesa" Address="#0100" RefDivision="2"

AccessLevel="3,5" UserBlocked="-,27">

<DeviceServiceList>

<DeviceService RefService="1" />

<DeviceService RefService="4" />

</DeviceServiceList>

</Device>

</DeviceList>

3.4.2 Ficheiro DomoticSystem.xml

Neste ficheiro encontra-se a definição dos tipos de valores que as propriedades dos dispositivos

podem assumir, bem como os tipos de dispositivos presentes na rede. Existem três tipos de valores

possíveis para uma propriedade: Escalar, Enumerado ou Array. Dentro de cada um destes três tipos

de valores, existem características próprias para os valores assumidos.

Para os valores escalares existe o elemento ScalarValueTypeList que os identifica. Abaixo desse

elementos estão representados os diferentes tipos de valores escalares que uma propriedade pode

apresentar, sendo descritos por: ID - número que identifica o tipo de valor escalar, NumBits - número

38

de bits desse valor, MinValue - valor mínimo que este pode apresentar, MaxValue - valor máximo que

pode apresentar e Step - intervalos em que se pode alterar esse valor.

<ScalarValueType ID=”1” NumBits=”8” MinValue=”0” MaxValue=”100” Step = “1” />

O exemplo acima representa um valor scalar cujo valor é representado por 8 bit, podendo assumir

valores entre 0 e 100 que pode variar de 1 em 1 unidades.

Os valores Enumerados encontram-se identificados pelo elemento EnumValueTypeList, que inclui os

diferentes tipos de enumerados existentes. Cada tipo de enumerado é representado por um elemento

EnumValueType de acordo com o seguinte exemplo:

<EnumValueTypeList>

<EnumValueType ID="1">

<Enumerated Name="Off" Value="0" />

<Enumerated Name="On" Value="1" />

</EnumValueType>

</EnumValueTypeList>

Os valores representados por Array permitem representar todos os demais valores que não sejam

inteiros ou enumerados. Apresenta-se em seguida a estrutura deste tipo de valor que possui os

seguintes atributos: ID - número de identificação e MaxLen - comprimento máximo permitido para o

Array.

<ArrayValueTypeList>

<ArrayValueType ID="1" MaxLen="3" />

<ArrayValueType ID="2" MaxLen="1" />

</ArrayValueTypeList>

Finalmente, a lista de tipos de dispositivos é a mais complexa das já descritas. Um tipo de dispositivo

é caracterizado por um número que o identifica (ID), pelo nome do tipo de dispositivo (Name), por

uma descrição do mesmo (Description) e uma lista de propriedades (PropertyTypeList). Cada

propriedade é composta por um número que a identifica (ID), um nome (Name), modo de acesso à

mesma (AccessMode) que pode ser apenas de leitura, apenas de escrita ou de escrita e leitura, o tipo

de valor que a caracteriza - ValueType (enumerado, escalar ou array), e o subtipo de valor (tipo de

escalar, enumerado ou array). A sua estrutura é a seguinte:

<DeviceTypeList>

<DeviceType ID="1" Name="Lâmpada-Regulada" RefDeviceClass="1" Description="Cor Preta">

<PropertyTypeList>

<PropertyType ID="1" Name="On-Off" AccessMode="RW" ValueType="ENUM"

RefValueType="1" />

39

<PropertyType ID="2" Name="Intensidade" AccessMode="RW" ValueType="SCALAR"

RefValueType="1" />

</PropertyTypeList>

</DeviceType>

</ DeviceTypeList>

O programa desenvolvido carrega os dois ficheiros que foram descritos, ficando de posse de toda a

informação relevante do sistema e pode então gerar os menus de forma automática que vão ser

apresentados ao utilizador. As opções oferecidas ao utilizador permitem que ele aceda à rede de uma

forma simples e lógica e que possa escolher o tipo de acção que pretende realizar sobre um

determinado dispositivo, consultando ou alterando as suas propriedades. Os ficheiros incluem todos

os detalhes relevantes como, por exemplo, os endereços dos dispositivos, permitindo a geração das

mensagens adequadas para comunicar com a rede DomoBus na sua própria linguagem.

3.5 Notificações e Favoritos

Foram implementadas ainda duas funções na aplicação que tornam a interacção com a rede mais

simples e eficaz de acordo com as necessidades de cada utilizador. Um utilizador pode optar por ser

notificado sempre que determinada propriedade de um dado dispositivo se altere, de acordo com os

valores por si escolhidos. Para tal, o utilizador define o valor base para essa comparação e qual o tipo

de comparação a realizar (igual, diferente, menor, menor ou igual, maior ou maior ou igual). Por

exemplo, um utilizador pode optar por ser notificado cada vez que a temperatura de uma divisão

baixar dos 20ºC ou cada vez que a porta principal da sua fábrica seja aberta, não necessitando de

estar constantemente a consultar os valores dessas propriedades dos dispositivos correspondentes.

Foi ainda adicionada uma outra funcionalidade que é a possibilidade de um utilizador ter uma lista de

dispositivos favoritos, permitindo assim que, caso este se encontre ligado a uma rede que possui um

elevado número de sensores, este possa aceder de uma forma mais fácil e bastante mais rápida aos

dispositivos com os quais interage mais frequentemente. A opção de adicionar ou remover um

determinado dispositivo da lista de favoritos é apresentada quando esse dispositivo é escolhido.

3.6 Estrutura dos Menus

Pretende-se com este trabalho, não só tornar possível interagir com uma rede que utilize o sistema

DomoBus sem a necessidade de instalar qualquer aplicação própria para o efeito, como também

tornar o processo de interacção com esta o mais simples possível. Optou-se por isso por um sistema

de navegação intuitivo baseado em menus, como é descrito em seguida.

A estrutura dos menus foi criada partindo do princípio de que um dispositivo pode ser acedido de

diversas maneiras. Uma delas corresponde a um acesso directo ao dispositivo a partir de uma lista

40

completa dos dispositivos existentes na rede. Alternativamente, os dispositivos podem ser agrupados

por categorias, como por exemplo, serviços, andares, divisões ou zonas. Este processo de aceder à

rede através de menus, que se pretende que seja bastante intuitivo e flexível, é gerado

automaticamente a partir da leitura dos ficheiros XML, que possuem toda a informação sobre o

sistema. Isto quer dizer que os menus são gerados dinâmicamente, sendo adaptável ao mais

diversificado tipo de redes, podendo estas ser formadas por diferentes quantidades de dispositivos,

divisões, andares e serviços.

Um utilizador, quando pretende interagir com a rede, selecciona na sua lista de contactos de Instant

Messaging o utilizador que representa a rede, iniciando uma conversação com este. A aplicação

gateway, ao receber uma mensagem de um utilizador vai, em primeiro lugar, criar um menu para este

utilizador, mantendo ao longo do tempo o respectivo contexto de interacção. Para aceder ao menu

principal um utilizador apenas tem de enviar uma mensagem com o texto “h” ou “H” obtendo como

resposta o primeiro menu. Caso não saiba como aceder a este menu pode enviar uma mensagem

com um texto qualquer, recebendo como resposta uma mensagem a indicar como aceder ao menu

principal.

A partir do menu principal o utilizador pode aceder aos dispositivos existentes. As opções dos menus

são apresentadas em linhas separadas precedidas de um número que as identifica. Para escolher a

hipótese desejada o utilizador tem apenas de enviar uma mensagem de texto com o número

respectivo, sendo apresentado o menu seguinte. Todos os menus seguem este modelo. Caso um

utilizador deseje voltar ao menu principal, pode fazê-lo a qualquer momento, bastando para tal enviar

uma mensagem com o texto “h” ou “H”. Avançando pelas diferentes opções apresentadas nos

menus, o utilizador chega a um ponto em que escolhe o dispositivo que pretende. São apresentadas

as propriedades desse dispositivo e a possibilidade de adicionar ou remover esse dispositivo da lista

de favoritos. Escolhendo uma das propriedades vão ser disponibilizadas as seguintes opções: ver

estado (permite saber qual o valor actual), alterar estado (permite alterar o valor actual), criar/remover

notificação.

Dada a simplicidade dos menus e o facto de existirem poucos níveis para que um utilizador percorra

um ciclo completo de menus, foi criada a hipótese de se retroceder apenas um nível nos mesmos, ou

seja, quando um utilizador se encontra a navegar pelos diferentes menus, caso se engane na escolha

de uma opção, poderá voltar uma vez atrás. Se porventura o utilizador pretender voltar atrás nos

menus mais de um nível, isso não é possível, sendo necessário voltar ao menu principal.

Para implementar este esquema de menus foi criado um objecto “MenuPrincipal” que é chamado

quando é recebida uma mensagem IM e que analisa o seu conteúdo. Inicialmente espera por uma

mensagem que contenha o pedido para aceder ao menu principal. Caso contrário retorna uma

mensagem de ajuda com indicações sobre como o utilizador deve proceder. Para cada menu

apresentado é chamada a função que faz a avaliação do mesmo e que, de acordo com a opção

escolhida, passa ao menu seguinte. Se for escolhida uma opção inválida volta a apresentar o mesmo

menu, havendo sempre a possibilidade de se voltar ao menu principal. Na Figura 3.5 apresenta-se

um fluxograma que demonstra o funcionamento dos menus.

41

Figura 3.5 – Funcionamento dos menus.

43

Capítulo 4

Avaliação da Solução

44

4. Avaliação da Solução

Neste capítulo são apresentados os testes efectuados à aplicação desenvolvida com o objectivo de

avaliar o seu funcionamento.

4.1 Ligação do CommDir

O sistema DomoBus oferece uma infra-estrutura de comunicação que visa facilitar o desenvolvimento

de aplicações e a sua interacção. Essa infra-estrutura inclui um serviço de directório designado

CommDir. Para que uma aplicação se possa ligar ao serviço de directório o seu endereço tem estar

presente no ficheiro de configuração do CommDir, de que se apresenta um exemplo na Figura 4.1. A

Figura 4.2 ilustra o funcionamento do CommDir, com indicação dos endereços das aplicações que

têm autorização para se ligarem.

Figura 4.1 – Representação do registo de aplicação no ficheiro de configurações.

Figura 4.2 – CommDir apresentando as aplicações aut orizadas.

45

A primeira acção que o gateway IM deve realizar é aceder ao CommDir para se registar. Isso poder

ser feito recorrendo ao menu Ligação e clicando sobre Ligar CommDir . Na Figura 4.3 apresenta-se

a janela de ligação ao CommDir. Nesta janela introduzem-se os dados necessários para se efectuar a

ligação, de acordo com a configuração do CommDir, e procede-se então à ligação. Em caso de

sucesso é apresentada a janela indicada na Figura 4.4.

Figura 4.3 – Menu Ligação (Esquerda); Janela de lig ação ao CommDir (Direita).

Figura 4.4 – Ligação efectuada com sucesso.

4.2 Ligação ao Sistema de IM

Após ligação e registo no CommDir procede-se então à ligação ao serviço de IM. Para tal, no menu

Ligação , acede-se a Ligar sendo apresentada a janela ilustrada na Figura 4.5. Preenche-se o Nome

de Utilizador e a Password e efectua-se a ligação. Caso a ligação seja efectuada com sucesso

aparece a janela presente na Figura 4.6 com a lista de contactos disponíveis.

46

Figura 4.5 – Menu Ligação (à esquerda); Ligação ao sistema de IM (à direita).

Figura 4.6 – Ligação estabelecida ao sistema de IM. (os contactos foram tornados ilegíveis por razões de privacidade)

4.3 Ligação do Simulador

Para testar o correcto funcionamento da interacção com a rede de sensores DomoBus, usou-se uma

aplicação já existente para o efeito. Esta aplicação, chamada DomoDevSim, foi criada por dois alunos

do Instituto Superior Técnico. Com a criação do CommDir que veio actualizar o anterior serviço

directório, a aplicação já não suportava o novo formato em que as mensagens eram enviadas, tendo

sido necessário proceder a diversas alterações ao código da mesma, mantendo o seu esqueleto.

O processo de ligação do simulador ao CommDir é semelhante ao da aplicação desenvolvida,

apresentando uma janela igual à desta última. Apresenta-se na Figura 4.7 a janela principal do

47

simulador. Na zona identificada com o número 1 estão as diferentes opções de visualização do

programa – Monitorização, Manipulação, Log Mensagens e Log Interno. No exemplo da Figura 4.7 a

opção que se encontra seleccionada é a de monitorização, com o dispositivo Televisor-Quarto a ser

visualizado. Na zona número 2 apresenta-se a lista de dispositivos seleccionados e prontos a serem

monitorizados ou manipulados, estando todos seleccionados, como se pode ver na parte assinalada

com o número 5. Na zona que se encontra assinalada com o número 3 são mostradas as

características do dispositivo seleccionado. Caso seja seleccionado o modo de Manipulação a área 3

encontra-se divida em duas partes. A primeira apresenta as propriedades que o dispositivo tem e

seleccionando uma delas são apresentadas as definições dessa propriedade havendo a possibilidade

de alterar os valores da mesma.

Assinalada com o número 4 encontra-se uma zona onde é possível visualizar os valores actuais das

propriedades de um dispositivo e alterá-los caso se pretenda.

As opções Log Mensagens e Log Interno (presentes na zona 1) permitem aceder a ecrãs de logs – a

primeira permite ver todas as mensagens trocadas na rede de sensores DomoBus, enquanto a

segunda guarda todas as alterações efectuadas internamente no programa, como os dispositivos a

serem monitorizados.

Figura 4.7 – Janela Principal do Simulador.

4.4 Funcionamento da Gateway IM

Uma vez efectuadas as ligações necessárias para o correcto funcionamento da gateway, procedeu-

se então a uma troca de mensagens para testar o seu funcionamento. Na Figura 4.8 encontram-se as

três primeiras mensagens enviadas, por IM, para a gateway e as respectivas respostas da mesma.

48

Inicialmente a mensagem continha um texto qualquer e foi devolvida uma mensagem em que é

explicado como aceder ao menu principal. Recebida a explicação foi enviado o texto que permite

aceder a esse menu e de seguida escolheu-se a primeira opção relativa à lista de serviços. Como

resposta a gateway envia um menu com todos os serviços disponíveis. De notar que os serviços

apresentados podem variar consoante o ficheiro XML que for carregado na gateway, uma vez que

uma das funcionalidades que se pretendia para esta solução era a versatilidade e simplicidade de

funcionamento. Esta gateway está preparada para receber um ficheiro XML que descreve a

constituição de um sistema, o qual pode incluir qualquer número de dispositivos, serviços, divisões ou

andares.

No caso de ser enviada uma mensagem com uma opção inválida, a aplicação envia novamente o

menu em que o utilizador se encontra até este enviar uma opção válida –

Figura 4.9. O utilizador pode sempre voltar ao menu inicial em qualquer momento, bastando enviar

uma mensagem com o texto h ou H. Na Figura 4.10 ilustra-se o acesso ao serviço Entretenimento ,

indicado pelo número 7, tendo sido recebida uma resposta com os dispositivos pertencentes a este

serviço. Pretendendo interagir com o dispositivo Televisor-Quarto escolhe-se a opção 5. Este

dispositivo possui três propriedades: estado On-Off, Canal e Volume, bem como a opção de se

adicionar o dispositivo aos favoritos do utilizador, seleccionando a opção 4. Foi enviada uma nova

mensagem com o texto 3 para se aceder à propriedade Volume. É agora apresentado um menu com

as acções possíveis de exercer sobre a propriedade Volume do dispositivo Televisor-Quarto. Para

alterar o valor dessa propriedade foi enviada uma mensagem com o texto 2 sendo posteriormente

pedido um novo valor para essa mesma propriedade, ao qual se indicou que se pretendia o valor 25.

Finalmente foi devolvida uma mensagem a indicar o sucesso da operação.

Por outro lado, se o utilizador pretendesse saber qual o valor actual desse dispositivo, enviaria uma

mensagem com o texto 1.Escolhendo a opção 3 seria possível adicionar uma notificação, como

mostra a Figura 4.11. Em primeiro lugar é pedido que se escolha um valor base para a comparação

(no exemplo foi indicado o valor 20). Em seguida é apresentado um novo menu com os tipos de

comparação possíveis. Pretendendo ser notificado sempre que o valor do volume seja igual a 20 foi

enviada uma mensagem com o valor 1 (que corresponde a “igual”). Finalmente foi devolvida uma

mensagem a indicar que a notificação foi criada com sucesso.

Chama-se a atenção que a aplicação faz uma avaliação aos níveis de acesso do utilizador e nível de

acesso necessário para aceder ao dispositivo (informação que também se encontra no ficheiro XML

carregado). Se o utilizador não possuir um nível de acesso suficiente para interagir com o dispositivo

é devolvida uma mensagem a informar que não possui tais privilégios. Caso contrário é enviada uma

mensagem para a rede de sensores DomoBus e, uma vez recebida a resposta por parte da rede, é

enviada uma mensagem ao utilizador com o valor actual da propriedade pedida.

49

Figura 4.8 – Menu Serviços.

Figura 4.9 – Opção Inválida.

50

Figura 4.10 – Alteração do estado de um dispositivo .

Figura 4.11 - Adicionar uma notificação

51

4.5 Verificação das acções realizadas pela gateway IM

Na sub-secção anterior verificámos que, em caso de interacção com o sistema DomoBus, era

enviada para o utilizador uma resposta a indicar o valor actual de determinada propriedade de um

dispositivo ou indicação em como determinada propriedade tinha sido alterada. Na Figura 4.12 é

possível confirmar que foram feitos dois pedidos, um de GET e um de SET e que o valor do volume já

se encontra a 25. Os valores indicados nas mensagens no sistema DomoBus encontram-se no

formato Hexadecimal, pelo que o valor apresentado é 19h (que corresponde a 25 decimal).

Figura 4.12 - Pedidos de GET e SET recebidos e proc essados.

4.6 Privilégios dos utilizadores

Para ilustrar o correcto funcionamento do sistema no que se refere aos privilégios dos utilizadores

apresenta-se em seguida um exemplo. Na Figura 4.13 foi definido o nível de acesso de um utilizador

para o valor 3 (janela do lado esquerdo) e em seguida esse utilizador procura obter o valor de um

dispositivo com nível de acesso superior. Como consequência é devolvida uma mensagem a informar

que o utilizador não tem acesso a este dispositivo (janela da direita na figura).

52

Figura 4.13 – Utilizador sem acesso.

4.7 Apreciação Geral

As imagens apresentadas são referentes apenas a alguns dos testes efectuados com o simulador. No

entanto, para garantir o correcto funcionamento da Gateway desenvolvida, a mesma foi submetida a

uma grande diversidade de testes. Os testes realizados permitiram testar a simplicidade de uso da

aplicação, a flexibilidade a gerar menus para diferentes topologias de rede, bom desempenho quer

para redes constituidas por um elevado número de sensores, como para interacção com um elevado

número de utilizadores em simultâneo.

Pretendendo-se verificar a simplicidade de uso da interface, foi pedido a diferentes utilizadores que

testassem o seu funcionamento sem ter qualquer conhecimento sobre o trabalho que se estava a

realizar, tendo sido bastante simples para todos a interacção. A flexibilidade dos menus foi testada

com diferentes ficheiros XML de descrição da rede de sensores em que variava o número de

sensores, serviços, andares e divisões, verificando-se que os menus surgiam sempre de acordo com

a especificação dada nesses ficheiros. Nos testes de desempenho a aplicação manteve sempre um

bom tempo de resposta, não se notando diferenças em relação a redes com um número mais

reduzido de dispositivos ou interacção com menos utilizadores.

53

Capítulo 5

Conclusão

54

5. Conclusão

As redes de sensores surgiram com o intuito de tornar possível a monitorização e comando, não

presencial, do mais diversificado tipo de dispositivos. No entanto, devido a divergências nas

tecnologias usadas, a gestão e a interacção com estas redes foi sendo desenvolvida de forma

específica pelos respectivos fabricantes, não tendo sido contemplada a compatibilidade entre umas e

outras. Como consequência, o desenvolvimento de aplicações genéricas capazes de aceder e gerir

redes de sensores que incluam dispositivos de diferentes tecnologias, saiu bastante prejudicado.

A solução apresentada no presente trabalho cria a possibilidade de se interagir com uma rede de

sensores em qualquer local sendo apenas necessário a existência de um dispositivo que possa

aceder à internet e que possua um browser ou uma aplicação própria para a troca de mensagens

instantâneas usando o protocolo XMPP, deixando assim de ser necessária a instalação de software

no terminal a usar. Trata-se de uma aplicação que faz uso da solução DomoBus que oferece um

modelo genérico que permite ler e escrever em propriedades do mais variado leque de dispositivos

que sejam dotados de sensores e/ou actuadores sejam quais forem as suas características

específicas, apresentando-se como um modelo versátil e extremamente poderoso. A solução

DomoBus inclui um modelo de especificação das características da rede, em XML, o que contribui em

grande medida para a sua flexibilidade pois permite de uma forma genérica e independente da

tecnologia especificar os elementos constituintes da rede e descrever a suas características. A

solução DomoBus oferece também uma infraestrutura de comunicação que simplifica o

desenvolvimento de aplicações que interagem entre si. A aplicação desenvolvida faz uma tradução

das mensagens que são trocadas com a rede DomoBus para um sistema de menus simples e

intuitivo de usar por qualquer pessoa, permitindo monitorizar e comandar qualquer rede de sensores

e actuadores.

A aplicação foi desenvolvida na linguagem C# que é baseada em programação orientada a objectos.

A utilização desta linguagem de programação constituiu o primeiro obstáculo encontrado para o

desenvolvimento de todo o trabalho. Trata-se de uma linguagem com a qual nunca tinha havido

contacto e de um tipo de programação para o qual não havia preparação prévia a nível do curso. No

entanto, através da consulta de livros e páginas na internet foi possível adquirir as noções

fundamentais que permitiram o desenvolvimento de todo o trabalho.

A solução desenvolvida permite monitorizar e comandar uma rede de sensores sem a necessidade

de instalação de uma aplicação própria pois pode ser usado um browser comum. Pretendia-se ainda

que a interacção com o utilizador fosse simples e intuitiva. Com esse objectivo foi implementado um

sistema de menus, cuja navegação se processa através do envio de mensagens escritas, bastando

para isso o utilizador enviar o número correspondente à opção escolhida. Os menus e toda a

interacção com o utilizador são gerados de forma automática a partir da especificação XML da rede.

Durante a implementação foram encontradas algumas dificuldades na geração das respostas a

devolver ao utilizador. Ao fim de algumas mensagens o servidor começava a devolver uma

55

mensagem de erro no envio da mensagem. Após alguns testes chegou-se à conclusão que tal erro se

devia a uma prevenção contra mensagens enviadas sempre com o mesmo intervalo de tempo em

relação a mensagens recebidas, uma vez que o processamento dos pedidos do utilizador é

extremamente rápido, as respostas eram todas enviadas de imediato. Para ultrapassar esta

dificuldade teve de ser criada uma função que coloca o programa em espera por um curto intervalo

de tempo aleatório..

A solução desenvolvida no presente trabalho vem inovar o modo de interagir com as redes de

sensores DomoBus. Trata-se de um trabalho que permitiu explorar uma forma simples e rápida de o

fazer, havendo a possibilidade de inserir novas funcionalidades na mesma. Actualmente é

relativamente comum estabelecer comunicações áudio e vídeo nos sistemas de IM. No entanto não é

possível ainda estabelecer este tipo de ligações com vários utilizadores diferentes e fontes de vídeo

distintas. Com o surgir de tal funcionalidade a monitorização de uma rede de sensores através de

câmaras de vídeo constituirá um avanço significativo para estes sistemas. A versatilidade dos menus

e do tratamento das mensagens enviadas pelos utilizadores permite criar muitas outras

funcionalidades. Com o avançar das tecnologias será expectável dispor de cada vez mais espaço de

armazenamento de dados em servidores de internet podendo-se alojar dados estatísticos com o

comportamento dos vários sensores existentes na rede, podendo os utilizadores com permissões

adequadas aceder a esses dados.

57

Referências

[1]. Akyildiz, I.F., Su, W., Sankarasubramaniam, Y. and Cayirci, E., “A Suvey on Sensor

Networks”, IEE Communications Magazine, Vol. 40, No. 8, Ago. 2002, pp. 102-114.

[2]. Hoblos, G., Staroswiecki, M., and Aitouche, A., “Optimal Design of Fault Tolerant Sensor

Networks”, IEEE Int’l. Conf. Cont. Apps., Anchorage, AK, Set. 2000, pp. 467-472.

[3]. Bulusu, N., Estrin, D., Girod, L. and Heidemann, J., “Scalable Coordination for Wireless

Sensor Networks: Self-Configuring Localization Systems,” ISCTA 2001, Ambleside, U.K.,

Jul. 2001.

[4]. Intanagonwiwat, C., Govindan, R. and Estrin, D., “Directed Diffusion: A Scalable and Robust

Communication Paradigm for Sensor Networks,” Proc. ACM MobiCom ’00, Boston, MA,

2000, pp. 56–67.

[5]. Pottie, G. J. and Kaiser, W. J., “Wireless Integrated Network Sensors,” Commun. ACM, vol.

43, no. 5, Maio 2000, pp. 551-558.

[6]. Shih, E., Cho, S., Ickes, N., Min, R., Sinha, A., Wang, A. and Chandrakasan, A., “Physical

Layer Driven Protocol and Algorithm Design for Energy-Efficient Wireless Sensor Networks,”

Proc. ACM MobiCom ’01, Rome, Italy, Jul. 2001, pp. 272-286.

[7]. Woo, A. and Culler, D., “A Transmission Control Scheme for Media Access in Sensor

Networks,” Proc. ACM MobiCom ’01, Rome, Italy, Jul. 2001, pp. 221-235.

[8]. Abd-El-Barr, M.I., Youssef, M.A.M. and Al-OTaibi, M.M., “Electrical and Computer

Engineering”, 2005, Canadian Conference on Electrical and Computer Engineering, 1-4 Mai.

2005, pp. 1165-1168.

[9]. Renato Nunes, "Modelo de Especificação e Programação de um Sistema Domótico", IADIS

Conferência Ibero-Americana WWW/Internet 2004, Madrid, Spain, October 2004, pp. 377-

384.

[10]. Renato Nunes, “DomoBus Comm-Api: Comunicação no Sistema DomoBus – Application

Programming Interface”, V1.2, 19 Outubro, 2005

[11]. Renato Nunes, 2004, “A Communication Infrastructure for Home Automation”. CCCT 2004 –

International Conference on Computer, Communications and Control Technologies, Austin,

USA.

[12]. Renato Nunes, “Domobus – A New Approach to Home Automation”, 8CLEEE – 8th

International Congress on Electrical Engineering, Portugal, July 2003, pp. 2.19-2.24.

[13]. The Konnex Association, http://www.konnex.org, Março de 2009.

[14]. A casa inteligente, http://www.acasainteligente.com/index.asp, Março de 2009.

[15]. Echelon, http://www.echelon.com, Março de 2009.

[16]. Lonmark International, http://www.lonmark.com, Março de 2009.

[17]. X10 Europe, http://www.x-10europe.com, Março de 2009.

58

[18]. EuroX10, http://www.eurox10.com/Content/X10SignalTheory.htm, Março de 2009.

[19]. XMPP Standards Foundation, http://xmpp.org/tech/overview.shtml, Agosto de 2009.

[20]. Homepage of DomoBus.net, http://domobus.net, Fevereiro de 2009.

A

ANEXOS

B

A.1 – Ligação ao Sistema de IM

Ao ser pressionado o botão de Ligar na janela de ligação ao serviço de IM é accionada a função

button1_click que se encontra no ficheiro Ligacao.cs. É verificado se o utilizador introduziu os dados

necessários em todos os campos. Caso não preencha os campos nome de utilizador ou password é

informado para o fazer. Preenchidos os campos obrigatórios envia para o servidor um pedido de

autenticação. Se esses dados não forem válidos para o servidor é invocada a função

gtalkGateway_OnAuthError que informa que ocorreu um erro. Caso a ligação seja efectuada

com sucesso é invocada a função gtalkGateway_OnLogin que está encarregue de colocar a flag

de ligação a 1, para não existirem sobreposições de ligação, e de invocar a função que verifica se já

existe um ficheiro XML para o utilizador que está a efectuar a ligação preenchendo ainda os dados da

rede de sensores em memória.

Uma vez estabelecida a ligação, a função gtalkGateway_OnRosterStart é invocada, informando

que vão começar a ser recebidos os contactos existentes na lista de contactos. Envia ainda a

informação sobre o estado do utilizador a cada contacto recebido.

A função Ligacao_OnRosterItem recebe cada um dos contactos existentes na lista de contactos

do utilizador. Por cada contacto que recebe invoca a função criaLista.listaInicial,

encarregue de carregar em memória todos os utilizadores existentes.

Cada vez que um utilizador altera o seu estado é invocada a função Ligacao_OnPresence, esta

por sua vez invoca a função criaLista.actualizaLista que vai actualizar o estado dos utilizadores.

No caso de a ligação ser terminada é invocada a função gtalkGateway_OnClose, chamando de

seguida a função que pára todos os eventos activos - stopEventHandlers.

A.2 – Recepção de uma mensagem

Quando é recebida uma mensagem a função Ligacao_OnMessage é invocada. Verifica se está

activado o modo de resposta automática ou o modo de conversação. Após essa verificação chama a

função encarregue de verificar a existência de um menu ou de uma janela de conversação

(janelaConversa ou UserMenu consoante o caso).

Para verificar a existência de menu ou de janela de conversação para o utilizador que enviou

mensagem o processo é análogo. Pesquisa em todos os objectos criados do tipo correspondente –

janela ou menu – e caso encontre algum cuja identificação corresponda ao username que a enviou a

mensagem entra nesse objecto. Não existindo ainda nenhum, cria um novo.

C

A.3 – Dados de cada utilizador

public string username = null; public string estado = "(Offline)"; public int ninstancias = 0; public List<string> instancias = new List<string>(); public List<DadosInstancia> insts = new List<DadosInstancia>(); public int nivel = 0;

Os dados de cada utilizador são guardados num objecto DadosUtilizador que contém as informações

relevantes para o correcto funcionamento do programa como o seu nome de utilizador, o seu estado

actual, o número de instâncias que este tem ligadas, para o caso de desligar uma e manter as outras

ligadas o estado não ser colocado em offline, os dados de cada instância e o seu nível de acesso à

rede DomoBus. Estes objectos são todos guardados numa lista de objectos DadosUtilizador.

A.4 – XML

A função criaXML verifica se já existe um ficheiro XML com os dados dos utilizadores referentes à

conta que estabeleceu a ligação. Caso este não exista cria-o com o respectivo cabeçalho, guardo o

ficheiro e fecha-o. Em seguida chama o objecto responsável pelo carregamento dos dados da rede

de sensores em memória.

A função XML que se encontra no ficheiro XML.cs recebe os nomes de utilizador, da conta ligada e

do utilizador recebido, chama a função que verifica se o utilizador já existe e no final da execução da

mesma retorna o nível referente a este utilizador. Se o utilizador ainda não existir no ficheiro xml é

invocada a função AdicionaUser que vai adicionar esse utilizador ao ficheiro colocando com nível de

acesso 0. Para alterar o nível de um utilizador acede-se à janela de acessos no programa. Quando é

alterado o nível, é invocada a função novoNivel que recebe um nome de utilizador e o novo nível

do mesmo. Actualiza esse novo valor no ficheiro XML.

gateway entre uma rede de sensores e um sistema de … · as redes de sensores permitem melhorias...

Documents