Rede de Sensores Wireless para Domótica

Miguel Fernandes Hipólito

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

Engenharia Electrotécnica e de Computadores

Júri

Presidente: Prof. Mário Serafim dos Santos Nunes

Orientador: Prof. Renato Jorge Caleira Nunes
Vogal: Prof. Paulo Rogério Barreiros D'Almeida Pereira

Setembro de 2008
 Rede de Sensores Wireless para Domótica Miguel Fernandes Hipólito

1
Agradecimentos

Este trabalho é o culminar de vários anos de estudo, de dedicação e empenho na concretização

de um objectivo pessoal, como tal, gostaria de deixar expressos alguns agradecimentos a todos
aqueles que me auxiliaram neste longo caminho.

Ao professor Renato Nunes, agradeço a oportunidade de realização desta tese, toda a

disponibilidade, ajuda e empenho durante o tempo de realização da mesma.

À minha família, com especial atenção para os meus pais e para as minhas irmãs, um muito
obrigado pela compreensão, suporte e auxilio em todos os momentos da minha existência. Ainda
um especial obrigado ao meu primo e colega de curso Hernâni Fernandes pela companhia, ajuda
e camaradagem ao longo deste período de tese.

Aos meus colegas e amigos agradeço a amizade, as longas conversas e a constante boa
disposição ao longo destes anos.

2
Resumo
Os sistemas de automação residencial são uma tecnologia em expansão que pretende oferecer
aos seus utilizadores um conjunto de funcionalidades que permitem harmonizar a relação
casa/habitante. Apesar dos avanços tecnológicos denotados recentemente, os sistemas
domóticos disponíveis no mercado possuem limitações na capacidade de integração de diferentes
tecnologias e restrições de implementação que justificam a fraca expansão do mercado. Os
sistemas tradicionais usam tipicamente meios de comunicação cablados, o que dificulta a sua
implementação, especialmente em habitações preexistentes. A aplicação de tecnologias sem fios
tarda em se afirmar como uma alternativa aos tradicionais sistemas cablados, faltando em
particular soluções flexíveis e abertas que sejam fáceis de instalar e de integrar com outros
sistemas.

O presente trabalho pretende abordar os sistemas de automação residencial de uma forma

simples, flexível e genérica. É proposto o desenvolvimento de uma camada de serviços que
permita a aplicação de uma rede de sensores sem fios a um sistema domótico. A integração de
diferentes tecnologias é alcançada através da criação de um modelo de representação de
dispositivos domóticos baseado no modelo DomoBus. O protótipo desenvolvido é composto por
variados nós sensores e por um nó raiz ligado a um PC. Para permitir o acesso directo ao sistema
foi desenvolvida uma interface gráfica que disponibiliza operações de actuação, leitura de dados e
configuração de comportamentos do sistema. Para efeitos de teste e demonstração foram
utilizados três tipos de sensores: temperatura, luz e microfone. O protótipo desenvolvido usa nós
MICAz e os serviços foram implementados usando o ambiente TinyOS.

Palavras-chave: Rede de Sensores sem Fios, Domótica, Aquisição de Dados, Aplicação de

controlo e monitorização, TinyOS, ZigBee.

3
Abstract

Home Automation is a new rising technology that offers its users a set of functionalities that help
improve the relation house/resident. Despite the technological advances seen recently, the domotic
systems available in the market reveal poor capability of integration with other technologies and
have implementation restrictions that justify to the slow grow of this market. Traditional domotic
systems use wired communication that renders its implementation in existing building. Wireless
domotic systems are slowly being considerate as an alternative to current systems, although there
is a lack of flexible and open solutions that are easy to install and to integrate with other systems.

This dissertation tackles the development of home automation systems that are simple, flexible and
generic, and proposes a service layer that allows the integration of a wireless sensor network into a
domotic system. A representation model of domotic devices is introduced, which is based on the
DomoBus system and allows different technologies to be applied in a single system. The
developed prototype is composed by a number of sensor nodes and a root node that is connected
to a PC. A graphic user interface was developed that allows direct access to the system and
performs simple actuations, simple readings of sensors and configuration of nodes. Three different
types of sensors: temperature, light and microphone were used for test and demonstration
purposes. The prototype developed has MICAz nodes and the service layer was implemented
using the TinyOS environment.

Keywords: Wireless Sensor Network, Home Automation, Data Acquisition, Monitoring and Control
Applications, TinyOS, ZigBee.

4
Índice
Agradecimentos .......................................................................................................................... 2
Resumo ........................................................................................................................................ 3
Abstract ........................................................................................................................................ 4
Índice.. .......................................................................................................................................... 5
Lista de Figuras ........................................................................................................................... 7
Lista de Tabelas........................................................................................................................... 8
Lista de Abreviações .................................................................................................................. 9
1. Introdução .............................................................................................................................. 10
1.1 Motivação ......................................................................................................................... 10
1.2 Objectivos ......................................................................................................................... 12
1.3 Estrutura da Tese ............................................................................................................. 13
2. Estado da Arte ....................................................................................................................... 14
2.1 Redes de Sensores Sem Fio ........................................................................................... 14
2.1.1 Introdução ................................................................................................................ 14
2.1.2 Componentes da rede.............................................................................................. 15
2.1.3 Modelo funcional ...................................................................................................... 17
2.1.3.1 Estabelecimento da rede ............................................................................................... 17
2.1.3.2 Manutenção ................................................................................................................... 18
2.1.3.3 Aquisição de dados ........................................................................................................ 19
2.1.3.4 Processamento .............................................................................................................. 19
2.1.3.5 Comunicação ................................................................................................................. 20
2.1.3.6 Limitações e Restrições ................................................................................................. 20
2.1.4 Sistemas Operativos ................................................................................................ 21
2.1.4.1 TinyOS ............................................................................................................. 22
2.2 Domótica .......................................................................................................................... 25
2.2.1 DomoBus ................................................................................................................. 27
2.2.1.1 Arquitectura ...................................................................................................... 28
2.2.1.2 Representação de um sistema domótico: Dispositivos e Habitação ............... 29
2.2.1.3 Dispositivos ...................................................................................................... 30
2.2.1.4 Habitação ......................................................................................................... 32
2.2.1.5 Monitorização e Controlo do Sistema .............................................................. 32
2.2.1.6 Definição de comportamento do sistema ........................................................ 33
3. Aplicação de uma Rede de Sensores Sem Fios à Domótica ............................................ 35
3.1 TinyDB .............................................................................................................................. 39
3.1.1 Características Gerais do TinyDB ............................................................................ 40
3.1.2 Componentes do TinyDB ......................................................................................... 42
3.1.3 Disseminação e Encaminhamento .......................................................................... 44
3.1.3.1 Construção da SRT........................................................................................................ 45
3.1.3.2 Manutenção da SRT ...................................................................................................... 46
3.1.4 Mensagens em TinyDB ............................................................................................ 46
3.1.5 Modelo de Dados ..................................................................................................... 47
5
 3.1.6 Características base da linguagem TinySQL .......................................................... 47
3.1.7 Análise do TinyDB e identificação de limitações ..................................................... 53
4. Desenvolvimento de um Sistema Domótico sem Fios ...................................................... 56
4.1 Modo de Funcionamento dos Nós Sensores ................................................................... 57
4.2 Arquitectura Geral do sistema desenvolvido ................................................................... 60
5. Detalhes de Implementação ................................................................................................. 62
5.1 Modelo de Dados ............................................................................................................. 62
5.2 Protocolos de Comunicação ............................................................................................ 64
5.2.1 Disseminação de Dados .......................................................................................... 65
5.2.2 Colecção de Dados .................................................................................................. 66
5.3 Estrutura das Mensagens do Sistema ............................................................................. 68
5.4 Arquitectura Detalhada do Sistema - Modelo Funcional ................................................. 71
5.5 Arquitectura do nó de saída (raiz/sink) ............................................................................ 75
6. Interface Gráfica para Testes Funcionais ........................................................................... 76
7. Conclusão .............................................................................................................................. 82
Referências ................................................................................................................................ 84

6
Lista de Figuras

Figura 1 - Rede de Sensores Sem Fios aplicada à Domótica. ................................................... 11

Figura 2 - Rede de Sensores Sem Fios. ..................................................................................... 15
Figura 3 - Mica2DOT ................................................................................................................... 16
Figura 4 - TelosB ......................................................................................................................... 16
Figura 5 - MICAz ......................................................................................................................... 16
Figura 6 - Placa de Sensores MTS310 ....................................................................................... 16
Figura 7 - Placa Programadora MIB520 ..................................................................................... 17
Figura 8 - Placa Programadora MIB520 com nó......................................................................... 17
Figura 9 - Ligação Configuração – Componentes ...................................................................... 22
Figura 10 - Modelo de Componentes e Interfaces do TinyOS. ................................................... 23
Figura 11 - Relação Aplicação/Componente/Interface com Hardware. ...................................... 24
Figura 12 - Exemplo sistemas de controlo constituintes de habitação automática .................... 26
Figura 13 - Arquitectura do sistema DomoBus ........................................................................... 29
Figura 14 - Modelo DomoBus de dispositivo domótico. .............................................................. 30
Figura 15 - Modelo de representação de uma habitação ........................................................... 32
Figura 16- Modelo de um cenário ............................................................................................... 34
Figura 17 - Propagação de uma query e resultados numa rede de sensores ............................ 39
Figura 18 - TinyDB GUI ............................................................................................................... 42
Figura 19 - Componentes TinyDB ............................................................................................... 42
Figura 20 – Exemplo de SRT: Nós a cinzento indicam os nós que produzem ou encaminham
resultados .................................................................................................................................... 45
Figura 21 – Query activada por interrupção externa (cima) vs. Query baseada em polling
(baixo) .......................................................................................................................................... 49
Figura 22 - Arquitectura do sistema proposto ............................................................................. 60
Figura 23 - Arquitectura detalhada do sistema desenvolvido para os nós sensores. ................ 73
Figura 24 - Modelo funcional do nó de saída .............................................................................. 75
Figura 25 - Aplicação de monitorização e controlo do sistema domótico ................................... 76
Figura 26 - Interface Gráfica: Painel de Interacção .................................................................... 77
Figura 27 - Exemplo de leitura simples dos sensores de temperatura, luz e microfone. ........... 78
Figura 28 - Exemplo de leitura periódica do sensor de luminosidade do nó dois. ..................... 79
Figura 29 - Exemplo de actuação temporizada sobre o led vermelho do nó sensor.................. 79
Figura 30 - Exemplo de configuração de propriedade seguido de remoção dessa mesma
configuração. ............................................................................................................................... 80
Figura 31 - Exemplo de configuração de mensagem de actuação............................................. 80
Figura 32 - Esquema de comunicação entre a aplicação desenvolvida e a rede de sensores. . 81

7
Lista de Tabelas

Tabela 1 - Classificação de redes de sensores segundo a sua configuração ............................ 18

Tabela 2 - Classificação da aquisição de dados por tipos de colecção...................................... 19
Tabela 3 - Principais especificações de protocolos sem fios de aplicação em sistemas de
automação residencial ................................................................................................................ 37
Tabela 4 - Número de mensagens e de bytes transmitidos aquando da execução de 4 tipos de
queries ......................................................................................................................................... 46
Tabela 5 - Parâmetros usados na estimação de tempo de vida de um nó. ............................... 50
Tabela 6 - Descrição das variáveis do modelo de estrutura de dados de representação de
propriedades de um dispositivo................................................................................................... 62
Tabela 7 - Classificação de mensagens do sistema ................................................................... 68
Tabela 8 - Descrição dos operadores disponibilizados para definição de comportamentos do
sistema. ....................................................................................................................................... 72

8
Lista de Abreviações

ACK – Acknowledgments
ASK – Amplitude Shift Keying
CM – Control Module
CSS – Chirp Spread Spectrum
CTP – Collection Tree Protocol
ETX – Expected Transmission
FSK – Frequency Shift Keying
GUI – Graphical User Interface
MAC – Medium Access Control
MAG – Módulo de Actuação Genérica
MCom – Módulo de Comunicação
MIH – Módulo de Interface com Hardware
MLG – Módulo de Leitura Genérica
nesC – Network Embedded Systems C
PSK – Phase Shift Keying
RSSFs – Redes de Sensores Sem Fio
SM – Supervision Module
SRT – Semantic Routing Tree

9
1. Introdução

1.1 Motivação

A tentativa de melhorar a qualidade de vida relacionada com a vivência na habitação tem sido
uma área bastante explorada ao longo dos tempos. Os desenvolvimentos da tecnologia nas
últimas décadas proporcionaram o aparecimento de sistemas e dispositivos especificamente
direccionados para o controlo e monitorização de habitações. Através de um sistema de
automação é possível controlar diversas partes de uma habitação. Estores, portões, sistemas
de rega, iluminação, sistemas multimédia e sistemas de climatização são exemplos de
mecanismos controláveis. As funcionalidades existentes num sistema de automação deste
género vão desde a simples aquisição de dados de um determinado sensor à existência de
comportamentos complexos que permitem actuar em função de condições específicas.

Actualmente a maioria dos sistemas domóticos disponíveis implicam a presença de uma

extensão considerável de cabos que fazem a ligação entre os diversos nós distribuídos pela
habitação e, eventualmente, um controlador central. O principal problema que deriva do uso
deste modelo está no facto de a implementação física de toda a estrutura de cabos ser
extremamente difícil em habitações já construídas, ou seja, é necessário um planeamento ao
nível estrutural que possibilite aplicar toda a cablagem associada ao sistema. A utilização de
redes de sensores sem fios num contexto domótico apresenta-se como uma solução para o
problema levantado, ainda que apresente vários desafios ao nível funcional.

Uma rede de sensores sem fios consiste num conjunto de pequenos nós, de baixo consumo e
custo, que incorporam sensores e permitem a recolha de valores de determinados parâmetros
em lugares específicos, o processamento e a comunicação sem fios dessa informação para
outros nós e/ou para locais fora da rede. Os protocolos de comunicação utilizados são
geralmente multi-salto (multi-hop) e permitem uma utilização eficaz dos recursos energéticos
dos nós, uma vez que é na comunicação que é consumida grande parte da energia disponível.
A cooperação entre nós potencia o nível de processamento suportado pela rede e aumenta o
tempo de vida dos nós sensores.

O domínio de aplicação das redes de sensores sem fios estende-se por diversas áreas como o
controlo de habitats, a monitorização de tráfego de veículos e controlo industrial. A capacidade
de funcionamento sem supervisão e a autonomia elevada diferencia os nós das redes de
sensores sem fios dos utilizados em redes de sensores com fios. Estas características
permitem o uso deste tipo de rede em locais de acesso difícil ou perigoso.

10
A implementação de uma rede de sensores sem fios como constituinte de um sistema de
automação numa habitação é uma área de investigação e de desenvolvimento com enorme
potencial. Os serviços oferecidos pelos nós de uma rede de sensores sem fios satisfazem os
requisitos de nível sensorial e podem também ser usados ao nível da actuação que é
importante no funcionamento de um sistema domótico.

Figura 1 - Rede de Sensores Sem Fios aplicada à Domótica.

11
1.2 Objectivos

A presente tese tem como objectivo identificar e avaliar as diversas funcionalidades de um

sistema domótico e ainda propor e desenvolver uma camada de serviços que permita a
aplicação de uma rede de sensores sem fios à domótica. Este sistema deve responder de
forma eficaz às necessidades funcionais existentes num sistema de automação de uma
habitação. A implementação de uma rede de sensores sem fios no contexto da domótica
corresponde também a uma tentativa de melhoramento dos serviços actualmente disponíveis
neste tipo de sistemas e apresenta-se como uma alternativa válida aos sistemas com fios
existentes.

A integração e adaptação de uma rede de sensores sem fios à domótica implica o

conhecimento das funcionalidades e dos requisitos deste tipo de sistemas. Nesta tese é feito
um estudo de possíveis soluções para suporte à utilização de uma rede de sensores sem fios
no controlo de uma habitação.

A rede de sensores sem fios considerada é constituída por um conjunto de nós sensores
capazes de cooperar entre si no processamento e comunicação da informação da rede e por
um nó sink que se encontra ligado a um sistema com maior capacidade de processamento e
de armazenamento onde existe uma aplicação que permite ao utilizador interagir com a rede.

Os serviços propostos para os nós sensores servem de suporte para o processamento de

dados nos nós, para a interacção com o hardware a nível de sensores e actuadores e para a
comunicação com os outros nós da rede. O nó sink funciona como uma gateway que faz a
ligação entre a rede de nós sensores e o PC.

O utilizador do sistema dispõe de uma interface gráfica cuja utilização o abstrai da camada de
middleware desenvolvida para suporte da rede e de todas as configurações de baixo nível. As
possibilidades de interacção com a rede foram desenvolvidas em consideração com as
necessidades do contexto onde a rede pretende ser aplicada, ou seja, uma habitação. Usando
a interface gráfica criada, o utilizador pode enviar mensagens de actuação, de leitura ou de
configuração para os nós e ainda visualizar a informação proveniente da rede e que tem como
destino o nó sink (gateway).

Após o desenvolvimento dos serviços propostos será feita a sua avaliação e uma identificação
de possíveis desenvolvimentos futuros.

12
1.3 Estrutura da Tese

A presente dissertação está estruturada em 7 capítulos.

No capítulo 2 é apresentada uma descrição do que são redes de sensores sem fios, o seu
desenvolvimento actual, as suas aplicações e capacidades, arquitectura, hardware e modelo
funcional. Ainda neste capítulo é apresentado o conceito de domótica, bem como as suas
funcionalidades e requisitos. O sistema DomoBus é descrito detalhadamente assim como o
respectivo modelo de representação de dispositivos domóticos e que servirá de ponto de
partida para a criação dos serviços propostos para a rede de sensores sem fios..

No seguimento do capítulo anterior, no capítulo 3 são analisados com exaustão os requisitos

para a aplicação de uma rede de sensores sem fios à domótica. É feito um estudo das
soluções existentes actualmente, com especial foco na abordagem TinyDB, sendo descritas as
suas funcionalidades, arquitectura, limitações e grau de aplicabilidade ao controlo de uma
habitação.

Nos capítulos 4 e 5 é explicada a abordagem seguida para atingir os objectivos propostos. É

apresentada detalhadamente a arquitectura da camada de middleware desenvolvida, são
enunciadas as funcionalidades disponibilizadas e são descritas as opções tomadas na
implementação dos serviços criados.

No capítulo 6 é descrita a interface gráfica desenvolvida que permite a um utilizador aceder e

interactuar com a rede de sensores sem fios.

No capítulo 7, são apresentadas conclusões, sendo feita uma análise do trabalho desenvolvido,
é avaliada a validade das opções tomadas e as limitações dos serviços elaborados. É ainda
apresentada uma reflexão sobre possível trabalho futuro.

13
2. Estado da Arte

2.1 Redes de Sensores Sem Fio

2.1.1 Introdução

Uma rede de sensores sem fios (RSSFs) é uma rede constituída por um conjunto de nós com
sensores incorporados, autónomos, espacialmente distribuídos, e cuja aplicação tem como
objectivo o controlo, processamento, e a monitorização de condições físicas e ambientais de
diversos sistemas. Os desenvolvimentos recentes da tecnologia permitiram a criação de
dispositivos sensoriais multifuncionais, de tamanho, preço, e consumo reduzido, que
potenciaram o uso prático das redes de sensores sem fios. As primeiras investigações nesta
área foram direccionadas para aplicações num contexto militar, sendo que actualmente as
redes de sensores sem fios estão presentes em inúmeras áreas do contexto civil tais como,
controlo em ambientes industriais, monitorização de tráfego de veículos, monitorização de
habitats e sistemas de segurança. Os objectivos de uma rede de sensores sem fios são a
monitorização e armazenamento de valores de parâmetros físicos de um lugar específico e
ainda a transmissão de dados para um nó com capacidade para exportar a informação para o
exterior da rede.

Os desafios e restrições de uma rede de sensores sem fios revelam-se bastante mais
complexos do que os de uma rede de sensores tradicional. Geralmente este tipo de rede
possui um elevado número de nós sensores com limitações na capacidade energética, e que
necessitam de mecanismos de auto-configuração e adaptação a problemas como falhas de
comunicação e perda de dados. Numa rede de sensores com fios os nós sensores podem por
vezes possuir alimentação proveniente de uma fonte de energia permanente e estar ligados a
uma rede de área local. Uma rede de sensores sem fios permite a utilização de um número
elevado de nós sensores, o que seria impossível de concretizar com uma rede tradicional visto
que implicaria o uso de uma extensão incomportável de fio, situação incomportável em
determinados locais de instalação.

Nas secções seguintes são descritos os componentes constituintes de uma rede de sensores
sem fios, é apresentado o seu modelo funcional e arquitectura, as limitações, os serviços
típicos oferecidos e os sistemas operativos deste tipo de redes.

14
 Figura 2 - Rede de Sensores Sem Fios.

2.1.2 Componentes da rede

Os nós que constituem uma rede de sensores sem fios podem ser de dois tipos distintos, nós
sensores e nós sink (gateway). Os nós sensores são aqueles que, tal como o nome indica,
possuem capacidade para recolher informação do ambiente onde estão colocados, através de
sensores. Para além de executarem funções sensoriais, este tipo de nós efectua
processamento e comunicação de dados. Actualmente existe uma extensa variedade de
sensores, tais como sensores de luminosidade, acústicos, de movimento, de humidade, de
temperatura, de pressão e magnéticos. Os dados recolhidos pelos sensores são alvo de um
processamento local ou colectivo que resulta no armazenamento e/ou transmissão da
informação, ou ainda na tomada de decisões por parte dos nós. Os nós sink fazem a ligação
entre a rede e um dispositivo com maior poder de processamento e capacidade de
armazenamento. A interligação entre a rede e o exterior é efectuada através deste tipo de nós,
podendo os mesmos fazer a ligação com aplicações que permitem a interacção entre a rede e
utilizador.

As intensas investigações na área dos microprocessadores, das comunicações sem fios e dos
sensores permitiu o desenvolvimento de dispositivos de tamanho, custo e consumo energético
reduzido, que ao mesmo tempo apresentam capacidade de processamento elevada. Nas
figuras 3, 4 e 5 são representados três modelos de nós utilizados em redes de sensores sem
fios, o Mica2DOT [1], o TelosB [1] e o MICAz [2], respectivamente. Os dispositivos
apresentados são geralmente designados de motes e foram desenvolvidos pela companhia
norte americana Crossbow Technology, Inc. [1]. Na realização deste trabalho foi utilizado o
mote MICAz em conjunto com a placa de sensores MTS310 [3], figura 6, produto igualmente
desenvolvido pela empresa acima mencionada. A presença de vários sensores num único
dispositivo e que apresentam a capacidade de transmitir informação sem fios é bastante
comum. Estes sensores são chamados de “sensores inteligentes”.

15
 Figura 3 - Mica2DOT Figura 4 - TelosB Figura 5 - MICAz

A placa de sensores MTS310 possui cinco sensores, temperatura, luz, voz, campo magnético e
aceleração, e ainda um actuador de som (besouro). O conjunto mote e placa de sensores
constituem um nó sensor.

Figura 6 - Placa de Sensores MTS310.

O mote MICAz utiliza um microcontrolador de 8 bit - ATMega128L, a funcionar a uma

frequência 7.37 MHz, e inclui memória flash de 512 Kbytes, 128 Kbytes de ROM, 4 Kbytes de
SRAM e um dispositivo de rádio frequência CC2420 compatível com o protocolo de
comunicação ZigBee. A alimentação do nó é feita por duas pilhas do tipo AA. Das
especificações apresentadas verifica-se que existem limitações de memória (código e dados) e
de energia, o que representa importantes características a ter em consideração aquando do
desenvolvimento de software para este tipo de nós. As restrições que caracterizam as redes de
sensores sem fios são descritas detalhadamente no seguimento deste relatório.

Para além da presença de sensores é ainda possível existirem actuadores ligados a motes. O
processamento dos valores recolhidos pelos sensores pode resultar na actuação de
dispositivos controlados pelo próprio nó ou por outros nós da rede.

16
 No caso do mote MICAz (mote utilizado na realização deste trabalho), a ligação entre o nó sink
e o PC é feita através da placa programadora MIB520 - USB GATEWAY da companhia
Crossbow Technology, Inc. – ver figura 7. A MIB520 suporta a programação de motes MICAz e
MICA2 através da sua porta USB, sendo a alimentação da placa também feita por este meio.
Devido ao facto de o mote MICAz não possuir interface para PC, apenas dispõe de um
conector de 51 pinos, a placa programadora funciona como um gateway entre o mote e o PC.
Quando conectados, os motes são alimentados através do conector de 51 pinos. A ligação da
MIB520 a um computador cria duas portas virtuais, que no caso do sistema operativo Linux é
do tipo USB e no sistema Windows é virtualizado como duas portas série, uma para a
programação dos motes e outra para a leitura de dados. Como auxiliares de utilização existem
dois leds, um verde que indica o estado da alimentação da placa (on/off) e outro vermelho que
corresponde a “Programação a Decorrer”. Os motes podem ser reiniciados através do botão de
reset localizado perto do conector USB.

Figura 7 - Placa Programadora MIB520 Figura 8 - Placa Programadora MIB520 com

nó.

2.1.3 Modelo funcional

As principais funcionalidades de uma rede de sensores podem ser divididas em cinco grupos:
estabelecimento da rede, manutenção, sensores e actuadores, processamento e comunicação.

2.1.3.1 Estabelecimento da rede

As aplicações de redes de sensores sem fios envolvem o estabelecimento da rede que se caracteriza
pela actividade de disposição e formação da mesma. As redes de sensores sem fios são redes ad-
hoc, ou seja, redes onde cada nó tem capacidade para encaminhar mensagens para outros nós,
sendo que a escolha do nó para o qual o encaminhamento deve ser feito é realizada dinamicamente
e com base na conectividade da rede.

Na tabela 1 é apresentada uma classificação de redes de sensores segundo a sua configuração.

17
 Tabela 1 - Classificação de redes de sensores segundo a sua configuração [4]

Configuração
Rede composta de nós que apresentam a mesma capacidade de
Homogénea hardware. Eventualmente os nós podem executar software
Composição diferente.
Heterogénea Rede composta de nós com diferentes capacidades de hardware.
RSSF em que os nós estão organizados em grupos (clusters). Cada
Hierárquica grupo terá um líder (cluster-head) que poderá ser eleito pelos nós
Organização comuns. Os grupos podem organizar hierarquias entre si.
Plana Rede em que os nós não estão organizados em grupos.
Todos os nós sensores permanecem no local onde foram
Estacionária depositados durante todo o tempo de vida da rede.
Mobilidade
Rede em que os nós sensores podem ser deslocados do local onde
Móvel inicialmente foram depositados.
Rede que apresenta uma concentração e distribuição de nós por
Balanceada unidade de área considerada ideal segundo a função objectivo da
rede.
Densidade Rede que apresenta uma alta concentração de nós por unidade de
Densa área.
Rede que apresenta uma baixa concentração de nós por unidade de
Esparsa área.
Rede que apresenta uma distribuição não uniforme dos nós na área
Irregular monitorizada.
Distribuição
Rede que apresenta uma distribuição uniforme de nós sobre a área
Regular monitorizada.

As redes de sensores sem fios são sistemas auto-organizados formados por nós e que se agrupam e
adaptam dinamicamente quando ocorrem falhas. Algoritmos de localização podem ser utilizados para
obter o posicionamento dos nós. O endereçamento dos dispositivos é exclusivo, o que significa que
cada nó possui um endereço de rede único. O endereçamento dos dados serve para especificar a
comunicação entre os diversos pontos da rede e disponibiliza informação topológica para uso no
encaminhamento.

2.1.3.2 Manutenção

Durante o tempo de vida da rede são necessárias diversas acções de manutenção para que o bom
funcionamento do sistema seja permanente. A manutenção da rede pode ser de diferentes tipos,
reactivo, preventiva, correctiva ou adaptativa [5]. As características e limitações deste tipo de redes
exigem mecanismos capazes de lidar com problemas de estabelecimento da rede, de aquisição de
dados, de processamento e de comunicação. Devido à capacidade limitada de energia dos nós
sensores é comum surgirem problemas de aquisição de valores dos sensores, de processamento de
informação e de comunicação nestes dispositivos. Aquando de uma falha que provoque a inutilização
de um nó, a rede deve ser capaz de se reorganizar mantendo-se funcional. Em aplicações onde os
nós sensores são estacionários e ocorram falhas a topologia da rede pode mudar e ser necessário
adaptar a mesma às condições correntes. O elevado custo de renovação de recursos dos nós por
causa de falhas torna as actividades de manutenção extremamente importantes.

18
2.1.3.3 Aquisição de dados
A aquisição de dados numa rede de sensores sem fios corresponde a uma amostragem do mundo
real transformada em informação que pode ser tratada computacionalmente. Os dispositivos
sensoriais utilizados nestas redes convertem uma medição de um parâmetro físico num sinal digital
que após processamento permite obter as informações desejadas. A recolha de valores depende de
factores como o tipo de dados medidos, volume de informação e frequência de amostragem. A
escolha e distribuição dos nós sensores deve ser pensada em função da aplicação e adequada à
tarefa a realizar. A área de cobertura dos sensores deve ser alvo de um estudo pormenorizado.
Mecanismos de detecção de falhas nas leituras dos sensores devem ser incluídos nas especificações
da rede de modo a evitar o mau funcionamento da mesma. Como a aproximação do final do tempo de
vida dos nós é possível que os valores lidos pelos sensores destes sejam inválidos.

Na tabela 2, é apresentada uma classificação dos modos de aquisição de dados categorizada por
tipos de recolha de dados.

Tabela 2 - Classificação da aquisição de dados por tipos de recolha. [4]

Aquisição de Dados
Os nós sensores recolhem dados sobre o(s) fenómeno(s) em
Periódica
intervalos regulares.
Continua Os nós sensores recolhem os dados continuamente.
Recolha Os nós sensores recolhem dados quando ocorrem eventos de
Reactiva
interesse ou quando solicitado pelo observador.
Os nós sensores recolhem a maior quantidade de dados possível
Tempo Real
no menor intervalo de tempo.

2.1.3.4 Processamento

O processamento de dados numa rede de sensores é um processo que exige uma boa gestão dos
recursos disponíveis e que deve ser realizado em consideração com um dos objectivos primordiais
das redes sem fios: a maximização do tempo de vida de um nó. Os valores recolhidos pelos sensores
são alvo de um processamento que pode servir para converter a informação lida em dados
manipuláveis e tomar decisões em função do resultado dessa recolha. Em determinadas aplicações o
processamento de dados de sensores é despoletado quando limites pré-definidos são ultrapassados.
A correlação e agregação de informações colectadas de diferentes sensores diminuem a redundância
dos processos de software e da informação transportada pela rede. Processos de manutenção,
comunicação e gestão da rede são igualmente actividades que implicam esforço de processamento
nos nós. Internamente os nós possuem software capaz de gerir de forma eficaz a energia disponível,
processar dados e actuar em função do resultado dessa operação. No caso particular do nó MICAz o
consumo de energia é de 30 µW quando o mote está no estado sleep e de 33 mW no estado activo.

19
2.1.3.5 Comunicação

Geralmente a transmissão de dados numa rede de sensores sem fios é feita por rádio frequência. A
comunicação feita com rádios de baixa potência, como é o caso da maior parte dos motes utilizados
em redes de sensores sem fios, tem um alcance de 20-30m no interior e 70-100m no exterior [4]. A
distância alcançada depende da potência do sinal transmitido e das condições ambientais. Existem
diversos protocolos de comunicação desenvolvidos para utilização neste tipo de redes. Um dos
protocolos mais utilizados é o protocolo ZigBee, protocolo standard de comunicação de alto nível
desenvolvido para rádios de pequena potência e que é baseado no standard IEEE 802.15.4.
Inicialmente este protocolo podia ser usado em comunicações de rádio frequência e de
infravermelhos. As versões mais recentes apenas suportam comunicação rádio frequência.

A comunicação de informação num nó é o processo com maior gasto energético existente, sendo
necessária uma gestão eficaz da utilização dos recursos de transmissão de dados através de
protocolos vocacionados para o efeito. Usualmente diz-se que os protocolos de redes de sensores
são centrados nos dados a recolher, em contradição com os protocolos de redes tradicionais onde a
comunicação é centrada nos endereços. Protocolos de colecção e disseminação são dois exemplos
de protocolos normalmente utilizados em redes de sensores sem fios. A colecção de dados num nó,
sink, é frequentemente utilizada em aplicações de monitorização ambiental. A disseminação de dados
permite que a configuração dos nós da rede seja feita através de um único nó. Os protocolos de
redes de sensores sem fios devem suportar reconfigurações da rede e possuir mecanismo para lidar
com falhas nos canais de comunicação, resultantes da inutilização de determinados nós.

2.1.3.6 Limitações e Restrições

As redes de sensores sem fios caracterizam-se especialmente por possuírem limitações na

capacidade energética de cada nó, limitações ao nível de recursos de processamento e de
armazenamento de informação. Existe ainda a necessidade de mecanismos de auto-configuração e
adaptação a perdas de comunicação e falhas nos nós, que podem provocar erros na aquisição,
processamento e transmissão dos dados recolhidos.

Nas redes com fios o principal objectivo é maximizar a velocidade de transmissão dos dados e
minimizar o número de saltos na comunicação. Pretende-se também estender o tempo de vida dos
nós e aumentar a robustez do sistema.

As principais restrições presentes em redes de sensores sem fios são:

Velocidade de processamento baixa quando comparada com a velocidade de processamento

de um PC. Este facto implica limitações na interpretação e execução de instruções.

20

Largura de banda disponível para comunicação entre nós limitada implica restrições na
transmissão de dados. A velocidade de comunicação é um factor de extrema importância em
sistemas de funcionamento em tempo real.

Nós não possuem fonte de alimentação permanente. O tempo de vida de um nó é um dos

principais problemas das redes de sensores sem fios.

Capacidade de armazenamento reduzida. A capacidade de armazenamento nos nós, em

particular na memória SRAM, é de poucos kilobytes.

Elevado número de nós provoca inúmeras colisões de pacotes e congestionamento na rede

que resulta na perda de mensagens.

Redes onde os nós são móveis implicam um esforço adicional para reorganizar a rede
sempre que exista uma mudança na localização dos dispositivos.

Problemas na segurança da informação transmitida na rede. A integridade, autenticidade e

confidencialidade dos dados são factores cruciais para o bom funcionamento do sistema.

2.1.4 Sistemas Operativos

O objectivo de todo o sistema operativo é promover o desenvolvimento de software de aplicação

robusto através da disponibilização de abstracções úteis e seguras dos recursos de hardware. As
redes de sensores sem fios são redes embebidas que suportam uma variedade de aplicações e
possuem a capacidade de serem implementadas rapidamente em novos ambientes. Os sistemas
operativos de redes de sensores sem fios são desenvolvidos em consideração com as restrições de
recursos e as características especiais deste tipo de redes. A reduzida interactividade das aplicações
existentes é expressa pela não existência de interfaces com o utilizador.

Actualmente existem diversos sistemas operativos que podem ser utilizados no desenvolvimento de
redes de sensores sem fios. Os sistemas Contiki [7], SOS [8], desenvolvido para motes da
Universidade da Califórnia, Los Angeles, e MANTIS OS [9], desenvolvido no departamento Ciências
da Computação da Universidade do Colorado, Boulder, são alguns exemplos de sistemas operativos
que permitem programação em C e que são utilizados neste tipo de redes. Um sistema operativo
especificamente desenvolvido para redes de sensores sem fios utilizado em grande escala é o
TinyOS [6]. Devido ao facto de este sistema possuir características muito interessantes e de estar
disponível para os nós que são utilizados nesta dissertação, é feita uma descrição detalhada do
TinyOS na secção seguinte.

21
2.1.4.1 TinyOS

TinyOS é um sistema operativo open-source desenvolvido para redes de sensores sem fios. Este
projecto nasceu da colaboração entre a Universidade da Califórnia, Berkeley e o grupo Intel
Research. O modelo de execução do sistema TinyOS é baseado em eventos e alia a capacidade de
execução de um elevado número de processos sem necessitar grandes recursos de hardware. Este
modelo permite ainda que o sistema seja energeticamente eficaz. Quando os nós se encontram no
modo sleep mantêm-se vigilantes e podem responder a estímulos. O sistema é não-preemptivo
devido à existência de apenas um stack, o que significa que uma única aplicação é executada em
cada instante.

As aplicações do TinyOS são desenvolvidas na linguagem nesC [10], um dialecto da linguagem de

programação C optimizado para as limitações de memória das redes de sensores. A biblioteca de
componentes do TinyOS inclui protocolos de rede, serviços distribuídos, drivers de sensores e
ferramentas de aquisição de dados. O sistema suporta uma diversidade de plataformas e pode ser
utilizado em diversos modelos de motes.

A linguagem nesC utiliza dois tipos de módulos: configurações e componentes. Um componente usa
e disponibiliza interfaces. As configurações são o método através do qual as declarações dos
diferentes componentes são ligadas. Os módulos definem funções e alocam estados, são portanto
implementações. Configurações ligam interfaces usadas por componentes a interfaces
disponibilizadas por outros componentes.

Configurações

Liga

Componentes ... Componentes

Figura 9 - Ligação Configuração – Componentes

Um módulo implementa as interfaces que utiliza e disponibiliza, e contém código para lidar com os
eventos e comandos que utiliza. Todo o processamento considerado longo deve estar contido em
tasks. Uma task é um conjunto de acções não preemptivas.

Interfaces são canais bidireccionais de interacção entre dois componentes. Cada interface é
constituída por um conjunto de funções que podem ser implementadas pelo componente que
disponibiliza a mesma, os chamados comandos, e por um conjunto de funções que podem ser

22
implementadas pelos utilizadores das interfaces, eventos. As interfaces são um método simples de
representar interacções complexas entre componentes. São disponibilizadas funcionalidades para o
exterior que são representadas pelos comandos que podem ser executados e pelos eventos que
necessitam de tratamento.

Figura 10 - Modelo de Componentes e Interfaces do TinyOS.

Os programas no TinyOS são compostos por componentes de software que estão ligados entre si
através de interfaces. Uma aplicação é uma configuração de alto nível que especifica um conjunto de
componentes e como é feita a ligação entre os mesmos. A utilização de componentes e interfaces
disponibiliza uma abstracção para pacotes de comunicação, encaminhamento, leitura de sensores,
actuação e armazenamento.

23
 Figura 11 - Relação Aplicação/Componente/Interface com Hardware.

A distribuição do TinyOS inclui um simulador, TOSSIM, ferramenta que permite estudar o

desempenho das aplicações desenvolvidas antes da sua aplicação numa rede real.

24
2.2 Domótica

Domótica é a aplicação de tecnologia moderna no controlo de habitações. O termo Domótica vem do

cruzamento da palavra grega Domus, que significa casa, com Robótica, tecnologia de controlo
automático. Um sistema domótico pretende melhorar a qualidade de vida dos seus utilizadores ao
nível do conforto, da segurança, da economia e da comunicação. Mecanismos de automação podem
ser aplicados em sistemas de iluminação, de climatização, multimédia e de segurança. A
possibilidade de controlo de todos estes sistemas a partir de um único local da residência, ou até
mesmo fora da mesma, é um dos principais atractivos das chamadas “casas-inteligentes”.

Ao nível da iluminação, um sistema domótico permite controlar todos os pontos de luz artificial de
uma casa a partir de um único local. A utilização de sensores de luminosidade possibilita a regulação
da posição dos estores e de intensidade luminosa, por exemplo de um candeeiro, o que resulta numa
redução do consumo energético. Ainda com a preocupação da poupança de energia, podem ser
usados sensores de movimento de forma a detectar quando uma divisão se encontra vazia, e
consequentemente desligar as luzes deixadas acesas. O controlo do sistema de iluminação de uma
habitação pode ser também usado para simular a presença de pessoas no seu interior. Esta
funcionalidade pode ser útil no contexto da segurança, por exemplo quando os proprietários se
encontram ausentes por um período de tempo prolongado.

Ligar o ar condicionado minutos antes de chegar a casa é uma das muitas funcionalidades que a
domótica permite. A automação de um sistema de climatização como o ar condicionado, um
equipamento de aquecimento ou de ventilação, pode ser feita de modo a manter níveis de conforto da
habitação pré-programados. A poupança de energia volta a estar em evidência com a possibilidade
de regulação da climatização em função da temperatura exterior, da humidade e da presença.

Em termos de sistemas multimédia é possível distribuir áudio e vídeo por uma ou mais divisões, bem
como seleccionar qual a fonte a disponibilizar em cada divisão. As imagens recolhidas por câmaras
de segurança podem ser visionadas em qualquer televisão da residência aumentando o nível de
segurança da mesma.

A Domótica permite a automatização de determinadas tarefas diárias. A distribuição de comida e

água a um animal de estimação, a abertura ou fecho da porta da garagem, a rega do jardim e o
funcionamento da bomba da piscina ou jacuzzi, são apenas alguns exemplos de actividades onde a
Domótica é extremamente útil.

A integração e controlo de sistemas de segurança permite detectar diversas situações de intrusão,

tais como movimento dentro e fora de casa, a abertura ou fecho de portas e janelas e o partir de
vidros. Para além de situações de intrusão é também possível detectar incêndios, fugas de gás e
inundações activando consequentemente um alarme que pode ser na forma de luzes a piscar por

25
toda a habitação, para aviso dos moradores, e um alarme para as autoridades. O sistema domótico
pode também ser programado para cortar o fornecimento de gás ou água quando é detectada a
ocorrência de um sinistro deste género. A habitual verificação das portas e persianas efectuada todas
as noites e que antecede cada saída de casa pode tornar-se mais cómoda e segura com a
implementação de um sistema de automação de uma residência.

Uma característica de elevado interesse neste tipo de sistemas é a existência de cenários pré-
estabelecidos que aquando da sua selecção desencadeiam a execução de uma lista de acções que
adaptam a habitação a uma situação particular. Um exemplo de cenário é o visionamento de um
filme. Quando algum dos residentes decide ver um filme é comum fechar as persianas, reduzir, ou
mesmo desligar as luzes, ajustar a temperatura do sistema de climatização e activar o dispositivo que
irá reproduzir o respectivo filme. Todas estas acções podem ser inseridas no sistema como fazendo
parte de um cenário. Desta forma, sempre que o utilizador escolher este modo, o sistema domótico
executa as instruções pré-estabelecidas para o mesmo. Esta funcionalidade pode ser aplicada a
cenários como “sair de casa”, “dormir”, “jantar”, etc.

Os sistemas de automação residencial são bastante úteis na gestão eficaz da geração e consumo de
energias renováveis. O controlo de posição de células fotovoltaicas em função da localização do sol e
o racionamento do consumo de água aquecida com energia solar são dois exemplos de aplicações
da domótica que podem representar uma diminuição nos consumos energéticos de uma habitação.

Todas as funcionalidades existentes numa casa automatizada podem ser acedidas num único local
que proporciona uma interface amigável ao utilizador. A possibilidade de aceder ao sistema através
de um PDA, com ligação Wi-Fi, ou através de um computador com ligação à internet é reveladora do
potencial que a domótica tem.

Figura 12 - Exemplo sistemas de controlo constituintes de habitação automática

Actualmente existem diversos sistemas de controlo de habitações disponíveis no mercado. Algumas

das tecnologias disponíveis são abertas, EIB [11], X10 [12], LonWorks [13], C-Bus [14], enquanto

26
outras são propriedade de empresas, não sendo conhecidos os seus detalhes de implementação. A
incompatibilidade existente entre tecnologias e a inoperação entre dispositivos de diferentes marcas
são uma limitação no desenvolvimento do mercado. Os sistemas mais comuns envolvem a colocação
de fios por toda a residência de forma a estabelecer a rede de nós sensores. Toda a comunicação é
feita através de ligações de alta velocidade que permitem a entrega dos dados recolhidos num nó
central que estabelece a interface com um sistema de maior capacidade de processamento e
armazenamento que os nós da rede. Como referido anteriormente, a instalação de um sistema com
fios pode não ser uma solução viável em situações onde o local de implementação não foi pensado
para o efeito. As obras de adaptação de uma habitação a um sistema deste género podem ser
bastante dispendiosas e por vezes até impossíveis de realizar devido a problemas estruturais da
residência. O uso de uma rede de sensores sem fios como suporte de um sistema domótico pretende
ser uma solução fiável para responder ao problema mencionado.

A possibilidade de modificação do sistema é uma característica importante nos sistemas de

automação de habitações e permite ao utilizador adaptar o sistema adquirido às suas necessidades e
gosto. Disponível no mercado, a tecnologia X10 apresenta uma flexibilidade bastante grande no que
diz respeito a modificações da localização dos nós, uma vez que não utiliza fio para estabelecer
ligação entre os dispositivos mas sim a rede eléctrica já existente na habitação. Apesar das
características com potencial, a simplicidade dos comportamentos disponíveis pelo sistema X10 não
respondem de forma eficaz aos requisitos da domótica. As potenciais funcionalidades de um sistema
de automação de uma habitação necessitam de suporte ao nível de hardware e software que o
sistema X10 não fornece. A investigação na área dos sistemas domóticos e a evolução da tecnologia
têm possibilitado a criação de soluções mais genéricas, com maior potencial e flexibilidade,
promovendo a utilização de serviços de automação residencial.

A dificuldade em definir uma normalização para a representação de um sistema domótico é ainda um

problema actual nesta área. O desenvolvimento do sistema DomoBus constitui uma tentativa de
criação de uma plataforma genérica que representa os dispositivos domóticos através de um conjunto
de propriedades. Em seguida é descrito o modelo de funcionamento e arquitectura deste sistema.

2.2.1 DomoBus

O DomoBus [15] é um sistema de automação residencial desenvolvido no âmbito académico no

Instituto Superior Técnico com o objectivo de responder aos problemas e limitações identificados nos
sistemas domóticos disponíveis no mercado. A iniciativa de realização deste projecto adveio da
dificuldade encontrada aquando da tentativa de implementação e investigação de produtos que
utilizam os standards criados para este tipo de sistemas. Esta arquitectura pretende abordar a
automação residencial de uma forma genérica, flexível, capaz de representar qualquer tipo de
dispositivo independentemente da sua tecnologia e com capacidade para suportar comportamentos
complexos. Preocupações com a facilidade de instalação e adaptação a possíveis alterações no

27
sistema são igualmente partes integrantes do foco do projecto em questão. O modelo DomoBus,
dada a sua generalidade, pode servir de base à interoperação entre diferentes sistemas de diferentes
tecnologias.

Na realização desta tese o estudo do DomoBus centra-se na necessidade de utilização de um

modelo de especificação do sistema domótico que represente uma plataforma genérica para a
integração de novos dispositivos, propriedades e funcionalidades.

2.2.1.1 Arquitectura

O DomoBus apresenta uma arquitectura distribuída, figura 13, composta por dois tipos de módulos,
Módulos de Controlo (CM – Control Module) e Módulos de Supervisão (SM – Supervison Module) que
interagem através de uma rede de comunicação. O sistema está organizado em segmentos
compostos por Módulos de Supervisão, Módulos de Controlo que fazem a interface com sensores e
actuadores, e por um Módulo Router (R) responsável pela comunicação com o Backbone Segment,
segmento através do qual é feita a transmissão de informação inter-segmentos. Este modelo de
comunicação permite que as comunicações locais de cada segmento sejam independentes das
comunicações dos outros segmentos. A expansão do sistema é facilitada devido à sua estrutura de
segmentos.

Os Módulos de Controlo (CM) são constituídos por pequenas placas com microprocessadores que
fazem a interface com o hardware sensorial e de actuação do sistema. Sensores de temperatura, de
luminosidade, microfones, receptores de infravermelhos e interruptores são alguns exemplos de
dispositivos conectados directamente a um CM. A colecta de dados de sensores e o controlo dos
dispositivos de actuação electrónica do sistema são da responsabilidade do CM. Cada CM controla
vários sensores e actuadores, até 20 nos protótipos desenvolvidos, de forma a optimizar os recursos
de hardware disponíveis, e pode executar aplicações específicas, diferentes das existentes noutros
CM’s. A flexibilidade é uma importante característica que distingue este modelo dos restantes, onde
cada módulo controla apenas um dispositivo.

Os protótipos de CM construídos possuem um micro controlador com suporte para código, memória
para dados e vários periféricos para efeitos de temporizações e comunicação. O hardware de um CM
é ainda composto por um transdutor de comunicação (EIA-485) e interfaces para leitura de
interruptores e outros dispositivos de entrada [15].

28
 Figura 13 - Arquitectura do sistema DomoBus

Tal como o seu nome indica, os Módulos de Supervisão são responsáveis pela supervisão e gestão
do sistema. Os SM’s recebem informação dos CM’s, processam-na de acordo com a sua
programação e geram os comandos destinados aos CM’s.

Um sistema DomoBus pode ter tantos SM’s quantos os necessários à execução das suas
funcionalidades. Em sistemas mais simples pode existir apenas um SM que controla CM’s de
diferentes segmentos. No caso apresentado na figura 13 existe um SM por cada segmento DomoBus,
o que significa que a comunicação é directa e local ao segmento do próprio CM. Cada SM pode
controlar qualquer CM do sistema e interagir com os restantes SM’s de forma a partilhar informação.
Essa partilha é feita através de uma rede de comunicação diferente (Ethernet ou Wireless LAN, por
exemplo) com maior largura de banda e suporte de serviços multimédia. Através desta rede é
também possível a interacção com outros sistemas. [15]

2.2.1.2 Representação de um sistema domótico: Dispositivos e Habitação

A representação de um sistema domótico é um processo complexo e bastante importante no

desenvolvimento de um sistema deste género. O modelo DomoBus caracteriza-se pela abstracção,
flexibilidade, generalidade e simplicidade de abordagem à caracterização dos dispositivos domóticos
e da estrutura física de uma habitação, contendo simultaneamente capacidade para descrever as
funcionalidades essenciais de um dispositivo e ser independente da tecnologia utilizada. [16]

29
2.2.1.3 Dispositivos

Cada dispositivo é caracterizado por um conjunto de propriedades, tendo cada propriedade um valor
específico. De um modo geral, os sensores possuem apenas uma propriedade enquanto os
actuadores podem ter várias propriedades, por exemplo, uma televisão pode ter as propriedades:
Ligado/Desligado, Volume e Canal. O uso de várias propriedades permite que quando a televisão é
ligada sejam especificados o volume e canal definidos anteriormente. Caso se pretendam adicionar
novas propriedades controláveis a um dispositivo é possível fazê-lo de forma simples, mantendo a
estrutura funcional do sistema. [16]

Na figura 14, é apresentado o modelo DomoBus para representação de um dispositivo domótico.

Figura 14 - Modelo DomoBus de dispositivo domótico. [16]

Os dispositivos de um sistema domótico podem ser classificados em diferentes tipos, tais como
sensores de temperatura, sensores de presença, lâmpadas, motores de estores, ar condicionados,
etc. A classe TipoDispositivo abstrai os diferentes dispositivos de um determinado tipo. [16]

A classe Serviço permite agrupar tipos de dispositivos cuja funcionalidade é semelhante. As

classificações de serviços existentes num sistema de automação residencial correspondem a serviços
de iluminação, segurança, entretenimento, etc. Um dispositivo pode ser associado a diferentes tipos
de serviços, por exemplo, um sensor de presença pode estar associado a um serviço de segurança e
a um serviço de iluminação. Esta classe oferece a possibilidade de catalogar os diversos dispositivos
associados a um serviço particular. O utilizador do sistema DomoBus pode assim aceder à
informação que identifica todos os dispositivos de um serviço. [16]

Como anteriormente referido, um dispositivo pode ser caracterizado por várias propriedades, o que
significa que cada TipoDispositivo pode ter ligada a si várias classes TipoPropriedade. Existem
propriedades que são comuns a diferentes dispositivos, o que resulta na possibilidade de uma classe

30
TipoPropriedade estar associada a diversas TipoDispositivo. Segundo o modelo DomoBus (ver figura
14) cada TipoPropriedade é composta pelos atributos Nome, ModoAcesso, TipoValor e TipoVar. O
atributo Nome contém a designação da propriedade. O atributo ModoAcesso define o modo de
acesso a uma propriedade, só-leitura, só-escrita ou leitura-escrita. Os valores lidos por sensores
possuem modo de acesso só-leitura, enquanto em alguns actuadores este atributo pode ser definido
como leitura-escrita, como é o caso de uma lâmpada com intensidade luminosa regulável. A
especificação dos diferentes modos de acesso apresentada significa que a interacção do sistema
com os dispositivos físicos é feita apenas lendo ou escrevendo valores em propriedades. [16]

O atributo TipoValor define o tipo de valor através do qual a propriedade em questão se caracteriza.
São considerados três tipos de valor possíveis: Escalar, Enumerado e Vector. O tipo Escalar indica
um valor que pode variar entre um valor mínimo (ValorMin) e um valor máximo (ValorMax). O atributo
Unidades do tipo Escalar fornece informação sobre se a representação do valor é feita por uma
unidade específica, por uma percentagem (escala entre 0 e 100) ou por nenhum tipo de unidades.
Em situações em que o valor necessita de algum género de conversão essa especificação é feita
através do atributo TipoConv ao qual, em caso de efectiva necessidade de conversão de valor, está
associada uma classe Conversão que contém a expressão simbólica a utilizar. [16]

O tipo Enumerado é utilizado em propriedades que possuem um pequeno número de possíveis

valores. Por exemplo, muitos dispositivos contêm a propriedade EstadoLigadoDesligado que apenas
pode assumir dois valores, 0 (desligado) e 1 (ligado). Uma propriedade cujo valor é do tipo
Enumerado está associada a, pelo menos, dois objectos da classe Enumerado. Os atributos
Designação e Valor dessa classe contêm o nome do objecto e o valor do mesmo, respectivamente.
[16]

Propriedades que contenham uma lista de caracteres (representando um texto ou outro tipo de
informação) são consideradas do tipo Vector. [16]

A classe Dispositivo é a classe onde são definidos dispositivos concretos existentes numa habitação.
A associação de um dispositivo a uma classe TipoDispositivo permite identificar de imediato quais as
propriedades que este possui. Os valores correspondentes ao dispositivo físico são armazenados na
classe Propriedade. Um dispositivo terá tantas propriedades como aquelas que fazem parte da
especificação da classe TipoDispositivo à qual está associado. [16]

Este modelo de representação de sistema domótico permite a caracterização genérica de um

dispositivo domótico e torna a introdução de novos dispositivos mais simples e eficaz. A
representação mencionada é executada em duas fases. Inicialmente são definidos tipos genéricos de
dispositivos e são especificadas as suas propriedades. De seguida são indicados os dispositivos
concretos que existem numa habitação e qual o tipo a que estes correspondem. O facto de ser
independente da tecnologia do dispositivo é uma importante característica que torna o sistema flexível
e facilmente adaptável a diferentes cenários de implementação. [16]

31
É importante referir ainda que neste modelo é possível representar o tempo como se de um
dispositivo relógio se tratasse, caracterizado pelas propriedades: minutos, horas, dia da semana, dia,
mês e ano. Esta característica é importante para funcionalidades de automação que necessitem de
programação horária.

2.2.1.4 Habitação

A especificação de um sistema domótico para além de compreender um modelo de representação de

dispositivos deve conter um modo de descrever a estrutura de uma habitação e a localização física
dos dispositivos instalados. Uma residência pode ser dividida em vários pisos que contêm uma ou
mais divisões, podendo cada divisão conter qualquer número de dispositivos domóticos. No sistema
DomoBus é considerado um modelo simples para a representação da estrutura física de uma
habitação, que se encontra representado na figura 15. A classe Dispositivo corresponde à classe com
o mesmo nome apresentada na figura 14. [16]

Figura 15 - Modelo de representação de uma habitação. [16]

A classe Divisão não corresponde forçosamente a uma divisão física na habitação, podendo ser
utilizada em situações em que existe interesse em identificar duas zonas dentro de uma mesma
divisão física de uma residência. Por exemplo, uma divisão física onde existe uma zona de lazer e
uma zona de alimentação. [16]

2.2.1.5 Monitorização e Controlo do Sistema

O modelo de especificação do sistema domótico DomoBus permite que a monitorização e controlo de

uma habitação por parte do utilizador seja simples e ao mesmo tempo possibilita um conjunto de
funcionalidades bastante completas. Com a estrutura genérica de representação de dispositivos
adoptada, a adaptação do sistema a um ambiente personalizado de uma habitação torna-se assim

32
possível. A modificação do sistema é igualmente possível e pode ser executada de forma pouco
complexa.

O sistema pode incluir mecanismos de segurança que são activados em situações pré-estabelecidas
e cujo objectivo é garantir que em caso de esquecimento humano ou outro tipo de falha não sejam
criadas situações que podem pôr em perigo os residentes da habitação ou que possam provocar
danos materiais.

2.2.1.6 Definição de comportamento do sistema

A utilização de um sistema de automação pode ser simplificada pela criação de um modelo de

suporte de definição e execução de comportamentos pré-definidos. Existem situações e tarefas que
são frequentemente executadas pelos habitantes de uma residência. De forma a eliminar a
necessidade de programar o sistema acção a acção é criada a noção de cenário no modelo
DomoBus.

Um cenário corresponde a uma configuração pré-definida dos valores de um conjunto de

propriedades de determinados dispositivos, que é executada por acção do utilizador. Ver TV, Ir Deitar,
Levantar de Manhã, Regar Jardim e Activar Segurança são alguns exemplos de designações de
cenários. Todos os cenários são independentes uns dos outros e não interagem entre si. [16]

A definição de um cenário é feita através de uma cláusula do tipo ([16]):

IF condição THEN lista-acções

O termo condição é uma expressão de complexidade variável que envolve qualquer propriedade de
um dispositivo. Este termo é definido por uma ou mais expressões entre as quais é efectuada a
operação de disjunção ("OR"). As expressões são obtidas a partir da conjunção (“AND”) de uma ou
mais condições (condições simples envolvendo apenas o teste de uma propriedade de um
dispositivo). [16]

A lista-acções é uma sequência de acções que correspondem à atribuição de um valor a uma

propriedade de um dispositivo e que é executada quando o termo condição for verdadeiro. Existem
duas classificações para o tipo de acções a realizar: Acções de Activação e Acções de Desactivação.
Acções de Activação são acções realizadas quando um determinado cenário é activado. Acções de
Desactivação são executadas quando a condição que resultou na activação do cenário
correspondente deixa de se verificar. A figura 16 apresenta uma representação do modelo de um
cenário no sistema DomoBus.

33
Figura 16- Modelo de um cenário. [16]

34
3. Aplicação de uma Rede de Sensores Sem Fios à
Domótica
A automação residencial é uma área em desenvolvimento que tem beneficiado dos recentes
desenvolvimentos tecnológicos que permitiram o aparecimento de novos sistemas, protocolos e
dispositivos especificamente criados para o contexto da domótica. Actualmente, o mercado de
sistemas de automação de habitações disponibiliza diversos sistemas, que comunicam por meio
cablado, que apresentam complexas e atractivas funcionalidades. A utilização de tecnologia sem fios
é uma opção de implementação recente que oferece uma variedade de benefícios mas ao mesmo
tempo levanta novos desafios tecnológicos. Como principal vantagem no uso de sistemas sem fios
identificam-se o menor custo de instalação quando comparados com os sistemas tradicionais que
envolvem a colocação de uma extensão considerável de cabos que fazem a ligação entre os diversos
dispositivos do sistema. Para além desta distinta característica, a tecnologia sem fios permite a fácil
reconfiguração e expansão do sistema quando necessário.

A aplicação de uma rede de sensores sem fios à domótica implica o cumprimento de requisitos
específicos. A principal restrição das tecnologias sem fios está relacionada com a limitada capacidade
energética dos dispositivos utilizados. No caso dos actuadores é praticamente impossível eliminar
todos os fios presentes, uma vez que a actuação física necessita de uma fonte de energia
independente. Contrariamente, os sensores da rede não estão ligados a qualquer espécie de fios, o
que resulta na necessidade de tecnologia de baixo consumo. O tempo de vida de uma bateria de um
nó sensor deve ser extenso, meses ou até anos, visto que devido ao elevado número de nós do
sistema é impraticável substituir frequentemente as baterias dos dispositivos. Uma tentativa de
resolução deste problema é proposta pelo sistema EnOcean [17],[18] que disponibiliza no mercado
interruptores sem fios alimentados a energia solar.

A natureza do meio utilizado para as comunicações limita a capacidade de transmissão de

informação na rede. A maior parte dos dispositivos deste tipo de sistemas comunica entre si através
de ondas rádio, de onde advém a necessidade de avaliar o tipo e localização das divisões a serem
monitorizadas de modo a obter a melhor qualidade na recepção do sinal de rádio.

Os protocolos utilizados para comunicação de dados devem ter em consideração a possibilidade da

coexistência de sistemas implementados numa localização próxima que utilizem uma banda de
frequências que possa causar interferência no sistema domótico. Este facto pode causar atrasos no
tempo de transmissão e perdas de dados. Uma forma de minimizar interferências e maximizar o
alcance nos dispositivos sem fios é a escolha de uma banda de frequência cujas regulações e
características físicas se adaptem às especificações do sistema [17]. Das bandas de frequência ISM
(Industrial, Scientific, Medical), a banda de 2.4 GHz é actualmente uma das mais populares devido à
não necessidade de licença de operação. No entanto, a excessiva utilização da mesma faz com que
esta não seja uma opção que potencie a diminuição de interferências e colisão de dados. Nos

35
sistemas domóticos uma alternativa que pode ser interessante consiste em usar bandas de
frequência mais baixa, sendo as bandas ISM da região dos 900 MHz de maior interesse (863-870
MHz na Europa e 902-928 MHz nos Estados Unidos da América). Esta opção faz aumentar o alcance
nas transmissões de dados.

O facto de o canal de comunicação de um sistema sem fios se encontrar sempre aberto cria
problemas de segurança. Potenciais atacantes podem efectuar incursões sem estarem fisicamente
presentes. A inclusão de algoritmos complexos de cifra nos protocolos de comunicação pode ser no
entanto restringida pelas limitações de energia dos dispositivos.

Os protocolos standards IEEE.802.11 (WiFi) e Bluetooth, desenvolvidos para aplicações com

necessidades de transmissão de dados multimédia (elevadas taxas de transmissão), não são opção
para implementação num sistema domótico devido ao não cumprimento dos requisitos de baixo
consumo energético e de reduzido custo inerentes a este tipo de sistemas. De seguida são
apresentadas algumas tecnologias sem fios aplicáveis a sistemas de automação residencial.

A tecnologia Z-Wave [19] é um protocolo proprietário (os detalhes de implementação não são
livremente conhecidos) desenvolvido para aplicações de automação residencial. O sistema opera na
banda de frequência 908.42 MHz +/- 12 kHz nos Estados Unidos da América, 868.42 MHz +/- 12 kHz
na Europa, usa modulação do tipo FSK (frequency shift keying) e possui uma taxa de transmissão de
9.6 kbit/s. Uma rede desta tecnologia pode conter até 232 dispositivos. [17]

Já mencionado anteriormente, o sistema EnOcean é um sistema comercial inovador que disponibiliza

dispositivos domóticos alimentados a energia solar e botões de pressão energeticamente sustentados
através de elementos piezoeléctricos. Esta tecnologia pretende ser uma solução para as restrições
energéticas presentes em redes de sensores sem fios. O sistema opera a uma frequência de 868.3
MHz e utiliza uma modulação ASK (amplitude shift keying). A taxa de transmissão de 120 kbit/s aliada
a um payload máximo de 6 bytes assegura transmissões curtas que resultam na diminuição do
consumo de energia. O sistema não suporta quaisquer mecanismos de segurança. [17]

O protocolo nanoNET [20] opera a uma frequência de 2.45 GHz e suporta uma taxa de transmissão
até 2 Mbit/s. A modulação utilizada é CSS (Chirp Spread Spectrum), que faz parte de um conceito
mais alargado chamado Multi Dimensional Multiple Access (MDMA), uma combinação de modulação
de fase, amplitude e frequência. Este protocolo disponibiliza encriptação de 128 bits com capacidade
para autenticação de mensagens. O acesso ao meio de transmissão suporta CSMA/CA e TDMA. A
pilha de protocolo do nanoN ET foi desenvolvida para ser implementada em diversos micro
controladores através da separação de código dependente e independente de hardware. [17]

36
O já conhecido protocolo standard de sistemas de automação residencial com fios KNX [21] possui
uma versão específica para operação sem fios, o KNX RF. Este sistema opera na banda de
frequência 868.3 MHz +/- 40-80 kHz, usa modulação FSK e possui uma taxa de transmissão de 16.4
kbit/s. Devido à natureza das comunicações sem fios e ao suporte de dispositivos com capacidades
transmissoras, o KNX RF utiliza um esquema de endereçamento diferente do utilizado no protocolo
KNX. Esta característica implica que a ligação entre os sistemas KNX e KNX RF necessite, para além
de ligação física, de tradução de endereços. Para evitar interferências com outros sistemas cada KNX
RF tem um espaço de endereçamento distinto. O KNX RF não disponibiliza quaisquer mecanismos
de segurança. [17]

Os protocolos IEEE 802.15.4 e ZigBee são protocolos desenvolvidos para comunicações sem fios em
dispositivos de baixos recursos energéticos e de baixo custo. A camada de controlo de acesso ao
meio (MAC – Medium Access Control) e a camada física são definidas pelo IEEE 802.15.4, enquanto
o protocolo ZigBee define as restantes camadas superiores. A camada física do protocolo IEEE
802.15.4 especifica 3 bandas de frequência distintas: 868-868.6 MHz (1 canal, 20 kb/s), 902- 928
MHz (10 canais, 40 kb/s) e 2.40-2.48 GHz (16 canais, 250 kb/s). Todas as bandas de frequência
utilizam modulação PSK (phase shift keying). Estas tecnologias oferecem extenso suporte no controlo
de acesso ao canal, encaminhamento de informação e segurança da rede.

A tabela 3 [17] apresenta uma compilação das principais especificações das tecnologias
mencionadas.

Tabela 3 - Principais especificações de protocolos sem fios de aplicação em sistemas de automação

residencial

Taxa de Nº Máximo de Tipo de

Tecnologia Banda de Frequência Segurança Normalizado
Transmissão Nós Modulação

Z – Wave 868 MHz (EU) 9.6 kbit/s Publicitado Não 232 por rede FSK

EnOcean 868 MHz (EU) 120 kbit/s Não Não 232 ASK

nanoNET 2.4 GHz 2 Mbit/s Sim Não 248 CSS

KNX RF 868 MHz 16.4 kbit/s Não Sim 256 por linha FSK

IEEE 802.15.4/ZigBee 868 MHz (EU), 2.4 GHz 20, 250 kbit/s AES Sim 65536 PSK

Os protocolos enunciados são exemplificativos do tipo de produtos que utilizam tecnologia sem fios
disponíveis no mercado de sistemas de automação residencial. Apesar dos desenvolvimentos
tecnológicos realizados até ao momento, existe ainda uma longa margem de progressão para
sistemas deste género. A falta de protocolos standards, de flexibilidade e de intercooperação entre
sistemas é uma realidade nos produtos actuais. Contudo, as redes de sensores sem fios são uma

37
área de investigação com bastante trabalho desenvolvido no passado e que continua a ser um tema
sobre o qual existem diversos projectos de pesquisa em curso. O total aproveitamento das
potencialidades que a domótica oferece em termos de funcionalidades de automação de uma
habitação necessita de um forte suporte de hardware e software. Os produtos disponíveis
actualmente não oferecem essa possibilidade.

As limitações dos produtos de automação residencial disponíveis no mercado actual demonstram a

necessidade de investigação e desenvolvimento de sistemas mais robustos, flexíveis e com maior
número de funcionalidades. A falta de protocolos standards e o facto dos sistemas comerciais serem
tecnologia proprietária impossibilita um maior avanço no desenvolvimento destes sistemas.

Ao nível aplicacional, e no seguimento do estudo de tecnologias sem fios aplicáveis à automação

residencial, considera-se como hipótese de modelo de suporte de implementação de uma rede de
sensores sem fios à domótica o sistema TinyDB [22]. TinyDB é um processador de queries para
extracção de informação de uma rede de sensores. Este sistema utiliza uma linguagem do tipo query
language designada TinySQL. O propósito do estudo deste modelo deriva do facto de que numa
análise inicial do mesmo se ter considerado que o seu modelo funcional, baseado numa linguagem
de query, seria passível de aplicação directa à domótica. Desta forma, é apresentada de seguida uma
descrição detalhada, à qual se segue uma análise completa da abordagem TinyDB.

38
3.1 TinyDB
TinyDB é um sistema de processamento através de queries para extracção de informação de uma
rede de sensores. Este sistema foi desenvolvido na UC Berkeley para ser executado no sistema
operativo TinyOS e suporta todo o hardware de nós da plataforma Berkeley. O TinyDB tem muitas
características comuns aos tradicionais processadores de queries, como por exemplo a capacidade
para seleccionar, juntar e agregar dados. A utilização de técnicas de aquisição que permitem
minimizar o consumo nos nós e que aumentam a precisão dos resultados das queries é uma
vantagem do TinyDB sobre sistemas baseados em técnicas de não aquisição que não permitem o
controlo sobre quando e onde os dados são recolhidos. [22]

Ao contrário das soluções de processamento de dados existentes para TinyOS, o TinyDB não
necessita que o utilizador escreva código de baixo nível para os nós sensores, incluindo as
complexas interfaces das redes de sensores. A disponibilização de uma linguagem declarativa de
queries, TinySQL, que pode ser usada para extrair dados de uma rede de sensores da mesma forma
que a informação é extraída de uma base de dados, permite eliminar essa necessidade. A partir de
uma query que especifique as características dos dados a recolher, o TinyDB colecta os valores de
interesse nos nós, filtra e a agrega essa informação, e de seguida encaminha-a para o nó remetente
da query – ver figura 17. Todo este procedimento é feito através de algoritmos in-network
energeticamente eficientes. O TinyDB disponibiliza uma JAVA API que torna simples realizar
aplicações que possam enviar queries para a rede e extrair informação da mesma.

Figura 17 - Propagação de uma query e resultados numa rede de sensores. [21]

Em seguida detalham-se as principais características deste sistema de queries.

39
3.1.1 Características Gerais do TinyDB

Gestão de Metadata: O TinyDB disponibiliza um catálogo de metadata (informação

sobre informação) que descreve os atributos e os comandos que estão disponíveis
para querying e invocação na rede de sensores. Os atributos podem ser leituras de
sensor ou parâmetros internos de software/hardware. A especificação de comandos
pode ir desde afinação de parâmetros até actuação física. Os atributos e comandos
são criados através dos componentes TinySchema disponibilizados para o TinyOS.

Queries de Alto Nível: A utilização de uma linguagem de queries declarativa permite

descrever a informação pretendida sem ser necessário especificar o modo como
deve ser obtida essa mesma informação. Esta característica facilita a escrita de
aplicações e ajuda a garantir que estas funcionam correctamente após mudanças na
rede de sensores.

Topologia de Rede: O TinyDB gere a rede de rádio subjacente através da

determinação de nós vizinhos e da manutenção das tabelas de encaminhamento,
garantindo ainda que cada módulo da rede consegue enviar informação para o
utilizador de forma eficiente e garantida.

Queries Múltiplas: O TinyDB permite que múltiplas queries corram em simultâneo no

mesmo conjunto de módulos. As queries podem ter diferentes frequências de
amostragem e aceder a diferentes tipos de sensores. Devido a limitações de memória
a actual versão de TinyDB está limitada a duas queries simultâneas.

Expansão da rede via Query Sharing: Para expandir uma rede de sensores suportada
por TinyDB, é apenas necessário fazer o download do código standard deste sistema
para os novos módulos. Os módulos de TinyDB partilham queries entre si: quando
um módulo “escuta” uma mensagem da rede para uma query que ainda não está a
correr, este pede automaticamente ao emissor dessa informação uma cópia dessa
query executando-a de seguida. Não é necessária programação ou configuração dos
novos módulos.

O sistema TinyDB pode ser dividido em dois subsistemas:

1 - Software de Rede de Sensores: É o centro do TinyDB. Os utilizadores nunca necessitam de

modificar o código presente nesta secção. Este software corre em cada módulo (mote) da rede e é
constituído por diversas partes:

40

Catálogo de Sensores e Schema Manager: O catálogo de sensores é responsável por
localizar o conjunto de atributos, ou tipos de leitura (ex. luz, som, tensão), e propriedades
(ex. network parent, ID do nó) disponíveis em cada sensor. Em geral, esta lista não é
idêntica para cada sensor: uma rede pode ser constituída por uma colecção heterogénea
de dispositivos que apresentam diferentes propriedades.

Processador de Queries: O principal componente do TinyDB consiste num processador

de queries declarativas. O processador usa o catálogo de sensores para obter os valores
dos atributos locais, recebe leituras de sensores de nós vizinhos através de rádio,
combina e agrega estes valores com as suas leituras, filtra a informação indesejada, e
envia o resultado para a rede.

Gestor de Memória, TinyAlloc: O TinyDB estende o TinyOS com um pequeno gestor de

memória dinâmica handle-based, que aloca bytes de uma estrutura de tamanho fixo e
devolve um handle (apontador para um apontador) para essa mesma estrutura. A
utilização de handles permite deslocar a memória dentro da estrutura sem que seja
necessário mudar as referências externas. Esta característica possibilita a redução do
espaço desperdiçado e a compactação de memória.

Gestor de Topologia da Rede: O TinyDB gere a conectividade dos módulos (motes) na

rede de modo a encaminhar de forma eficiente dados e sub-resultados de queries para a
rede.

2 - Interface Cliente em Java: A rede de nós TinyDB é acedida por um PC ligado à mesma através da
Interface Cliente TinyDB, que consiste num conjunto de classes e aplicações Java:

Classe de interface de rede que permite às aplicações injectar queries e escutar os

resultados das mesmas; classes para construção e transmissão de queries;

Classe para extracção de informação sobre os atributos e capacidades dos dispositivos;

Uma aplicação com interface gráfica para construção de queries, que possui uma tabela
e um grafo onde são apresentados os resultados individuais de cada sensor e a topologia
dinâmica da rede.

41
 Figura 18 - TinyDB GUI

3.1.2 Componentes do TinyDB

A descrição dos componentes do TinyDB baseia-se na informação disponibilizada em [23].

Informação mais detalhada sobre toda a arquitectura deste sistema pode ser encontrada em [22] e
[24].

Figura 19 - Componentes TinyDB. [24]

42
TinyDBAttr é o componente que liga todos os componentes que implementem atributos embebidos
do TinyDB. Este componente deve ser actualizado sempre que se adicionar um novo componente
que implemente novos atributos no sistema.

TupleRouter é o centro do sistema TinyDB e disponibiliza a funcionalidade de processamento de

queries nos nós. Este componente tem a funcionalidade de encaminhar os dados através de uma
variedade de componentes de processamento local de queries.

O componente TupleRouter executa três tipos de tarefas:

1. Processamento de novas queries.

2. Processamento de resultados de queries de nós vizinhos.

3. Construção de resultados locais e entrega de dados aos nós “pais”.

TinyAlloc é o componente de Gestão de Memória, já mencionado.

NetworkC é o componente responsável pelo encaminhamento na rede de sensores, recebe e envia

dados e mensagens de query entre os nós. As mensagens de dados podem ser tuples ou agregados
de valores.

Tuple é o componente que providencia as ferramentas necessárias para lidar com estruturas do tipo
tuple. Um tuple é um tipo de vector de valores que é preenchido em intervalos de tempo bem
definidos, aos quais se chamam Epochs.

QueryResult é o componente que faz a conversão entre os diferentes tipos de dados do TinyDB,
tuples, strings de bytes e QueryResult. Uma estrutura do tipo QueryResult contém um tuple,
metadata, o identificador da query, um índice do conjunto de resultados e ainda um número de epoch.

SelOperator é o componente responsável pela realização de testes que indiquem a relação entre os
tuples e os critérios de selecção constituintes da query.

AggOperator é um componente que executa a agregação e o tratamento do campo GROUP BY

presente nas queries. A funcionalidade GROUP BY divide os dados segundo um atributo específico.
A agregação de uma query junta as leituras do nó onde é executada com o resultado da agregação
das leituras dos nós filhos e propaga essa informação para o nó pai a que está ligado.

DBBufferC é um componente que opera como um buffer abstracto de output para o TinyDB. Utiliza o
módulo MemAlloc para alocar memória.

43
Query é o componente que providencia uma interface para as queries não particionadas. Uma query
é identificada por um número único global e é composta por um campo que pode servir de predicado
para geração do QueryResult ou para aplicação de agregação de informação. Antes de ser
particionada, todas as partes da query chegam ao TupleRouter. O componente Query disponibiliza
métodos para determinar se uma query contém toda a informação necessária à conversão em query
particionada.

ParsedQuery é o componente que contém todas as interfaces necessárias para a interacção com
uma query em execução.

3.1.3 Disseminação e Encaminhamento

A disseminação de uma mensagem começa pela transmissão de uma query na raiz da rede. Cada
nó, ao “ouvir” a mensagem, deve saber decidir se a query deve ser aplicada localmente ou se deve
encaminhá-la para os outros nós. A importância a nível energético de saber se uma query deve ou
não passar por determinado nó é elevada. A não participação de uma parte da rede no
encaminhamento de uma mensagem contribui para o aumento do tempo de vida dos nós em causa.
A solução para a tomada de decisão sobre a participação, ou não, de nós filhos numa determinada
query reside na existência de atributos fixos, tais como, nodeid ou location. Em TinyDB são usadas
SRT’s, Semantic Routing Tree’s, de forma a manter toda a informação sobre os atributos de cada nó
filho da árvore de encaminhamento, tanto fixos como variáveis. Numa árvore de encaminhamento um
nó escolhe um nó pai que é por definição um nó que se encontra um nível mais próximo da raiz da
árvore.

Por norma, na construção de uma árvore de encaminhamento os nós escolhem os seus pais pelo
critério de melhor qualidade de ligação. Com a utilização de SRT’s a escolha deve também considerar
algumas propriedades semânticas dada a possibilidade da existência de nós com qualidade de
ligação semelhante. É utilizado um algoritmo de selecção baseado na qualidade da ligação que pré-
filtra os nós a ser usados na SRT.

Considere-se que A é o atributo de cada nó que é usado para tomar a decisão de participação numa
determinada query. Cada nó contém um intervalo unidimensional de valores de A que representa o
alcance dos seus nós filhos. Quando uma query chega a um nó, este verifica se algum dos valores de
A dos seus nós filhos é superior ao valor de A da query recebida. Caso isso aconteça o nó deve
receber resultados e encaminhar a query. Caso contrário, a query não é encaminhada. Em situações
onde a query é aplicada localmente (sendo aplicada aos seus nós filhos ou não) a execução da
mesma deve ser efectuada. Se a query não se aplica localmente, nem a nenhum dos nós filhos, a
query é ignorada – ver figura 20.

44
 Figura 20 – Exemplo de SRT: Nós a cinzento indicam os nós que produzem ou encaminham resultados.

3.1.3.1 Construção da SRT

A construção de uma SRT inicia-se através da inundação da rede com um SRT build request, que
contém o nome do atributo sobre o qual se deve construir a árvore, e que é retransmitido por todos os
nós até a totalidade da rede ter recebido a mensagem. Se um nó tiver nós filhos, deve enviar o
pedido para os mesmos e espera que estes respondam. Caso o nó não possua filhos, deve escolher
o seu nó pai e reportar o valor de A a esse mesmo nó através de uma mensagem de parent selection.
No caso dos nós com filhos deverá ser guardado o valor de A juntamente com a sua identificação e,
após receber as respostas de todos os seus nós filhos, enviar o alcance em valores de A que ele e os
seus filhos cobrem. Porque os filhos podem falhar ou mudar de posição, existe um timeout que
corresponde ao máximo tempo que um nó espera por uma resposta de um nó filho. Após este
período o nó filho é removido da lista de nós filhos desse nó. Caso a resposta de um nó filho seja
dada fora do período de timeout, então este é incorporado na SRT como se de um novo nó se
tratasse.

Uma SRT é análoga aos índices numa base de dados tradicional. O comando para criar uma SRT em
TinyDB é CREATE SRT:

CREATE SRT loc ON sensors (xloc,yloc) ROOT 0.

Onde ROOT indica a identificação do nó para o qual a SRT deve ser encaminhada.

45
3.1.3.2 Manutenção da SRT

Apesar de estar limitada a atributos fixos, podem ocorrer várias modificações numa SRT. Em
particular, nós podem desaparecer, podem aparecer novos nós ou existir uma mudança na qualidade
das ligações.

O aparecimento de nós e a mudança da qualidade da ligação podem obrigar à mudança de pais de

um determinado nó. Para que tal possa ser feito o nó deve enviar uma mensagem de parent selection
ao novo nó pai avisando-o da modificação no alcance de valores de A. O desaparecimento de um nó
filho é controlado através dos atributos query id e last epoch. Nesta situação o nó deve recolher
informação sobre o novo valor de alcance de A dos seus restantes filhos e comunica-lo ao seu nó pai.
Todas as actualizações efectuadas aos alcances dos nós filhos devem ser comunicadas aos nós
pais, mantendo assim toda a rede actualizada sobre qualquer mudança.

As vantagens do uso de SRT’s dependem do conjunto de valores escolhidos como suporte da SRT.
Atributos de localização são geralmente bons candidatos para a construção de SRT’s devido à
possibilidade de agregação de valores de nós pais e filhos. O uso de SRT’s tem benefícios relevantes
mas os custos de construção e manutenção podem ser consideráveis. [23]

3.1.4 Mensagens em TinyDB

O número de mensagens transmitidas na rede como resultado da construção e execução de uma

query é igual ao número de cláusulas que compõem essa mesma query. Uma mensagem tradicional
do sistema TinyOS possui 36 bytes. No TinyDB estas mensagens são expandidas para 56 bytes. Na
tabela 4 é apresentado o número de mensagens e de bytes correspondentes a 4 exemplos de
queries deste sistema. [25]

Tabela 4 - Número de mensagens e de bytes transmitidos aquando da execução de 4 tipos de queries.

Query Nº de msgs Nº de Bytes

SELECT nodeid, light, temp

3 168
FROM sensors
SELECT nodeid, light FROM
Sensors WHERE temp<512 5 280
AND nodeid>50
SELECT MAX(light)
2 112
FROM sensors
SELECT parent, MAX(light)
FROM sensors 3 168
GROUP BY parent

46
3.1.5 Modelo de Dados

Os dados recolhidos por cada nó são armazenados numa tabela de nome sensors por um período de
tempo reduzido, apenas o necessário para satisfazer os requisitos da query, ou então encaminhados
para fora da rede através de um Gateway. Existe a possibilidade de armazenar os dados dos
sensores por um período de tempo superior através de pontos de materialização. Na tabela sensors
cada linha corresponde a um sensor e cada coluna corresponde a um atributo que cada dispositivo
pode produzir. Caso o dispositivo não possua capacidade de recolher informação sobre determinado
atributo, isto é, não possua o sensor que recolhe esse tipo de dados, é designado o valor NULL para
esse campo. Fisicamente, a informação contida na tabela sensors está distribuída por todos os
motes. Cada mote produz e armazena a informação recolhida pelos sensores que possui. Quando é
necessária fazer a comparação de valores de diferentes motes, essa informação é enviada para um
ponto comum na rede, por exemplo, a raiz da rede.

3.1.6 Características base da linguagem TinySQL

A linguagem utilizada por TinyDB é muito semelhante à linguagem de pesquisa declarativa, SQL. Os
seus comandos base são SELECT-FROM-WHERE-GROUPBY. Para além destas características a
linguagem de queries em TinyDB acrescenta algumas capacidades adicionais.

Os dados recolhidos dos sensores são produzidos em intervalos de amostragem definidos pelas
queries.

SELECT nodeid, light, temp

FROM sensors
SAMPLE PERIOD 1s FOR 10s

Exemplo 1 – Exemplo de especificação de uma query.

A query apresentada no exemplo 1 permite recolher informação sobre a identificação do nó, valor do
sensor de luz e valor do sensor de temperatura de todos os nós com um período de 1 segundo
durante um intervalo de tempo de 10 segundos. Os resultados são recolhidos da tabela sensors e
enviados para a raiz da rede. Todos os nós da rede usam um protocolo de sincronismo de forma a
estabelecer uma base de tempo global que possibilita que a aquisição de dados seja executada
sincronamente em toda a rede. O output dos dados caracteriza-se por um fluxo de informação
dividido por intervalos de 1 segundo. Quando uma query é produzida é-lhe atribuído um identificador
que pode ser usado para parar essa mesma query através do comando “STOP QUERY id”.

Dado que a tabela de dados sensors não tem limites, é um fluxo contínuo de informação, não é
possível realizar operações bloqueantes, como sort ou symmetric join. A solução para esta situação

47
está em criar pontos de materialização, ou seja, pequenos buffers de dados que permitam armazenar
informação relativa aos sensores e que pode ser acedida por outras queries. Os pontos de
materialização localizam-se num único nó. De seguida apresenta-se um exemplo de criação de um
ponto de materialização:

CREATE
STORAGE POINT recentlight SIZE 8
AS (SELECT nodeid, light FROM sensors
SAMPLE PERIOD 10s)

Exemplo 2 – Query que permite a criação de um ponto de materialização.

A agregação de informação reduz a quantidade de dados a transmitir na rede. A agregação no

TinyDB é realizada in-network de acordo com uma função de agregação e um valor base de
particionamento especificado pela query.

SELECT AVG(volume),room FROM sensors

WHERE floor = 6
GROUP BY room
HAVING AVG(volume) > threshold
SAMPLE PERIOD 30s

Exemplo 3 – Agregação

No exemplo 3 é demonstrado como se pode agregar informação segundo um determinado critério. O

resultado produzido pela query exemplificada é dado na seguinte forma, <group id,aggregate value>.
A grande diferença entre o output de uma query em TinyDB e uma query SQL é o facto de o primeiro
ser um fluxo de informação enquanto o segundo é um simples valor agregado.

O TinyDB possibilita a utilização de eventos para iniciar a recolha de informação. Os eventos são
gerados de forma explícita, através de uma query ou através de uma parte de baixo nível do sistema
operativo.

ON EVENT bird-detect(loc):
SELECT AVG(light), AVG(temp), event.loc
FROM sensors AS s
WHERE dist(s.loc, event.loc) < 10m
SAMPLE PERIOD 2 s FOR 30 s

Exemplo 4 – Evento.

48
No exemplo 4, de cada vez que um evento bird-detect ocorre (aproximação de um pássaro a menos
de 10 metros de um sensor de proximidade) é enviado uma query do nó detector e é recolhida
informação sobre a temperatura e luz média dos nós vizinhos a cada 2 segundos durante 30
segundos.

A existência de eventos permite que o sistema esteja num estado adormecido até à ocorrência de
uma condição externa que accione um evento e os faça acordar. A presença de linhas de interrupção
externa na maior parte dos microprocessadores permite acordar um dispositivo adormecido de forma
a iniciar o processamento.

Em termos energéticos o método de queries baseadas em eventos, activadas através da linha de

interrupção externa do microprocessador, revela-se bastante mais eficaz quando comparado com o
método de queries baseadas em eventos cuja activação é efectuada por uma segunda query que
testa a veracidade de determinada condição (polling).

Na figura 1 é possível verificar a diferença de consumo energético entre os dois métodos.

Figura 21 – Query activada por interrupção externa (cima) vs. Query baseada em polling (baixo)

Eventos podem ser usados como condições de paragem para queries. Através do comando STOP
ON EVENT(param) WHERE cond(param) é possível parar uma query aquando da chegada de um
evento e da verificação de uma determinada condição. Uma query pode ser usada para activar um
evento. No exemplo 5 é demonstrada uma query que sinaliza um evento quando a temperatura lida
por um sensor ultrapassa um valor previamente estipulado.

SELECT nodeid,temp
WHERE temp > thresh
OUTPUT ACTION SIGNAL hot(nodeid,temp)
SAMPLE PERIOD 10s

Exemplo 5 – Query que sinaliza um evento.

49
Com a sinalização de eventos através de queries perde-se a mais-valia da poupança de energia
descrita anteriormente. Na implementação corrente de TinyDB, os eventos são sinalizados apenas no
nó local.

Em situações particulares é importante basear o processamento de queries em função do tempo de

vida do nó sensor. O TinyDB disponibiliza um modo de executar esta opção nas suas mensagens. O
comando SAMPLE PERIOD pode ser substituído pelo comando QUERY LIFETIME <X>, onde x é a
duração em dias, semanas ou meses. Este tipo de comando tem maior aplicação em sistemas de
monitorização de habitats onde o principal interesse é a duração da observação e não a taxa de
amostragem.

SELECT nodeid, accel

FROM sensors
LIFETIME 30 days

Exemplo 6 – Lifetime-Based Query

No exemplo 6 pretende-se que a query seja executada com uma taxa de amostragem o mais alto
possível de forma a conseguir atingir o objectivo de execução durante 30 dias. A satisfação da
condição imposta pelo comando LIFETIME é possível devido à execução de uma estimativa de tempo
de vida efectuada pelo TinyDB. O objectivo da estimativa de tempo de vida de um nó é obter o valor
para a taxa de amostragem e taxa de transmissão dado o número de Joules de energia restantes
nesse mesmo dispositivo.

Tabela 5 - Parâmetros usados na estimativa de tempo de vida de um nó.

O primeiro passo a efectuar na estimativa de tempo de vida de um nó é calcular a potência disponível

por hora:
(1)

De seguida é calculada a energia necessária para receber e transmitir uma amostra simples, es:

(2)

50
A energia correspondente a uma amostra é o custo de ler todos os sensores presentes no nó, mais
receber os resultados dos nós filhos, mais o custo de transmitir de forma satisfatória tanto os
resultados dos nós filhos como os seus próprios resultados. Finalmente, é calculada a máxima taxa
de transmissão, T (amostras por hora):

(3)

Dado que os nós necessitam de dormir entre a recolha de amostras, é importante que emissores e
receptores tenham os seus ciclos de despertar sincronizados. O facto de num nó apenas serem
permitidas transmissões quando os seus nós pais estiverem acordados e a ouvir mensagens da rede,
permite a sincronização. A máxima taxa de transmissão da rede está limitada à taxa de transmissão
da raiz da rede. Caso um nó necessite de transmitir a uma taxa inferior à taxa da raiz da rede esse
valor será um divisor inteiro do valor da taxa da raiz da rede. De forma a transmitir a uma determinada
taxa cada nó pai deve incluir nas queries que envia para os seus nós filhos, o valor correspondente a
esse parâmetro.
O comando MIN SAMPLE RATE r permite especificar a taxa mínima de transmissão para uma
determinada query. Caso a taxa de transmissão calculada através da estimação de tempo de vida,
com vista a atingir o objectivo pretendido com o comando LIFETIME, seja superior à taxa
especificada com o comando MIN SAMPLE RATE r, então a taxa aplicada será a de valor superior.

A estimativa de consumo de energia deve ser efectuada periodicamente devido a mudanças na rede
que podem acontecer ao longo do tempo.

Existem cinco tipos de queries disponíveis no sistema TinyDB:

Queries de Monitorização: Queries usadas para recolher valores de um ou mais atributos de

forma contínua e periódica.

Queries de Saúde da Rede: Queries que permitem saber o estado de cada nó da rede. No
exemplo 7 apresenta-se uma query que reporta quais os sensores da rede cuja voltagem da
bateria é inferior ao valor especificado por k.

SELECT nodeid,voltage
WHERE voltage < k
FROM sensors
SAMPLE PERIOD 10 minutes

Exemplo 7 – Query de Saúde da Rede.

Queries de Exploração: Queries que permitem saber o status de um nó num determinado

instante de tempo. No lugar do comando SAMPLE PERIOD usa-se ONCE.

51
 SELECT light,temp,volume
WHERE nodeid = 5
FROM sensors
ONCE

Exemplo 8 – Query de Exploração.

Queries de Actuação: Query que permite ao utilizador efectuar uma acção física em resposta
a uma determinada condição. O comando OUTPUT ACTION é usado com esse propósito.

SELECT nodeid,temp
FROM sensors
WHERE temp > threshold
OUTPUT ACTION power-on(nodeid)
SAMPLE PERIOD 10s

Exemplo 9 – Query de Actuação.

No exemplo 9, o comando power-on é uma porção de código de baixo nível que força o
output de um pin do microprocessador ao nível High, fechando o circuito de relay que passa a
fornecer energia a um dispositivo externo.

Queries de Entrega: Queries que permitem ao utilizador guardar informação que é gerada a
uma velocidade superior à velocidade de transmissão dos dados através de rádio. Em
TinyDB os resultados são guardados na memória EEPROM para entrega offline. Este
mecanismo é implementado através dos pontos de materialização descritos anteriormente.

52
A sintaxe das queries utilizadas pela linguagem TinySQL é apresentada de seguida:

[ON [ALIGNED] EVENT event-type[{paramlist}]

[ boolop event-type{paramlist} ... ]]
SELECT [NO INTERLEAVE] <expr>| agg(<expr>) |
temporal agg(<expr>), ...
FROM [sensors | storage-point], ...
[WHERE {<pred>}]
[GROUP BY {<expr>}]
[HAVING {<pred>}]
[OUTPUT ACTION [ command |
SIGNAL event({paramlist}) |
(SELECT ... ) ] |
[INTO STORAGE POINT bufname]]
[SAMPLE PERIOD seconds
[ [FOR nrounds] |
[STOP ON event-type [WHERE <pred>]]]
[COMBINE { agg(<expr>)}]
[INTERPOLATE LINEAR]] |
[ONCE] |
[LIFETIME seconds [MIN SAMPLE RATE seconds]]

3.1.7 Análise do TinyDB e identificação de limitações

O detalhado estudo realizado sobre o sistema TinyDB permite avaliar com clareza a possibilidade de
utilização deste modelo como suporte à implementação de uma rede de sensores sem fios à
domótica.

O sistema TinyDB permite a programação de uma rede de sensores através do uso de uma
linguagem de queries similar à linguagem SQL. A disponibilização de uma interface de abstracção
dos detalhes de baixo nível da rede de sensores transforma esta rede num conjunto virtual de tabelas
relacionais, resultando num menor esforço de programação do sistema. [25]

Contudo, o TinyDB apresenta algumas limitações que restringem a sua capacidade de suporte a uma
rede de sensores aplicada a um sistema domótico. A mudança constante das aplicações da rede
(queries a correr nos nós) devido à natureza da linguagem utilizada, queries, não se adequa a
sistemas de automação residencial, onde maioritariamente se pretende que um nó execute uma
tarefa específica, mantendo no entanto a flexibilidade de adaptação da rede a novas funcionalidades.

O facto de a linguagem utilizada por TinyDB, TinySQL, não proporcionar ferramentas de execução
que sejam computacionalmente completas, Turing Complete, limita o controlo da rede de sensores.

53
Estas limitações de TinySQL juntamente com limitações da capacidade de processamento in-network
(apenas é suportada a agregação de informação) do TinyDB tornam necessário considerar extensões
ao sistema. No entanto, modificações ao funcionamento do TinyDB implicam um esforço considerável
devido à necessidade de uma complexa reformulação do sistema. Conclui-se assim que possíveis
extensões funcionais para dar adequado suporte à aplicação na domótica, mostram-se de difícil
execução com o TinyDB. [25]

Dependendo da aplicação pretendida, seria interessante a criação de funções específicas para

determinados comportamentos existentes num sistema domótico. O TinyDB não suporta a criação de
funções definidas pelo utilizador.

É ainda importante referir que este sistema não é suportado na versão actual de TinyOS, 2.x, sendo
apenas executável na versão 1.x, o que constitui uma grave restrição pois todos os novos
desenvolvimentos se verificam para a versão 2.x.

As restrições descritas demonstram que o TinyDB não é uma hipótese válida para o suporte da
implementação de uma rede de sensores sem fios a um sistema domótico. Numa primeira análise as
funcionalidades de aquisição de dados dos sensores, da utilização de eventos activados em função
de determinadas condições pré-definidas, de actuação física e de gestão eficiente da energia nos nós
revelaram as potencialidades deste sistema. Mas, após um estudo mais aprofundado conclui-se que
a pouca flexibilidade do TinyDB no que diz respeito a eventuais modificações, adaptações e
introdução de novas funcionalidades no seu modelo funcional, não se adequa à implementação numa
rede de sensores sem fios de um sistema domótico. A utilização de uma linguagem de queries revela-
se limitadora na possibilidade de interacção do utilizador com o sistema. Uma rede de sensores sem
fios implementada num sistema de automação residencial é uma rede que está sempre ligada, ou
seja, é uma rede à qual o utilizador pretende ter acesso em qualquer instante. A arquitectura do
TinyDB revela, após o estudo realizado, que este sistema direcciona-se para redes autónomas onde
o acesso à informação das mesmas é feito não de uma forma contínua, como numa situação de uma
habitação, mas de uma forma esporádica, eventualmente muito espaçada no tempo.

O facto de o TinyDB não ser um sistema comercial faz com que seja expectável a existência de
pequenas falhas no seu funcionamento. Para além das limitações na arquitectura e especificações do
TinyDB é ainda possível identificar a não existência e o mau funcionamento de várias funcionalidades
anunciadas na documentação disponibilizada pelos criadores deste projecto [22].

De acordo com [23] determinadas opções da linguagem TinySQL revelaram falhas no seu
comportamento, bem com algumas funcionalidades de TinyDB:

A opção ONCE, que numa situação normal deveria produzir resultados durante uma epoch,
não tem qualquer efeito na query em que é especificada.

54

A opção SAMPLE PERIOD 1 FOR 10s, cujo objectivo é produzir resultados de 1s em 1s
durante 10s, não funciona. A inclusão desta opção não tem qualquer efeito na query onde é
aplicada.

A opção SAMPLE PERIOD 10s, produzir resultados apenas para 10s, não funciona. A query
continua a entregar resultados após os 10s especificados.

A opção CREATE BUFFER permite a criação de um buffer mas não possibilita a recolha de
dados do mesmo.

A opção HAVING não está implementada na versão corrente do TinyDB. Este facto foi
confirmado por um dos criadores deste sistema, Samuel Madden. Apesar de incluída na
documentação esta opção não está de facto disponível no TinyDB. [23]

A agregação de valores não produz resultados correctos. Os valores resultantes da

agregação são iguais para dois nós diferentes na mesma epoch. Por vezes o valor mínimo da
operação de agregação é superior ao valor máximo obtido.

Ainda dentro do contexto do tratamento de dados de uma rede de sensores sem fios, o
TinyDB não possibilita a transferência dos dados recolhidos para um gestor de bases de
dados. Esta operação é necessária para a manipulação correcta da informação da base de
dados.

A hipótese de utilização de TinyDB como modelo de suporte para uma rede de sensores sem fios
aplicada a um sistema domótico é assim invalidada. A inexistência de sistemas domóticos sem fios
com características de flexibilidade, robustez e adaptabilidade que sejam concordantes com os
requisitos de um sistema deste género motivam o desenvolvimento de um conjunto de serviços capaz
de cumprir com tais exigências e especificações. Na secção seguinte é apresentada a proposta de
desenvolvimento e respectivos detalhes de implementação da presente tese.

55
4. Desenvolvimento de um Sistema Domótico sem Fios

O presente trabalho propõe o desenvolvimento de uma camada de serviços que dê suporte ao uso de
uma rede de sensores num contexto domótico. Os serviços disponibilizados pretendem implementar
nos nós sensores da rede funcionalidades concordantes com as necessidades específicas de um
sistema domótico. O sistema proposto deve ser genérico o suficiente para permitir a integração em
diferentes plataformas de hardware, deve ser extensível de forma a permitir a inclusão de novos
dispositivos e novas funcionalidades com relativa facilidade, e deve ainda ser flexível permitindo
satisfazer às necessidades dos utilizadores, as quais vão evoluindo com a passagem do tempo.

Pretende-se ainda disponibilizar uma interface gráfica que corre num PC ligado a um nó sink
(Gateway) que permita enviar mensagens para os nós da rede de forma a serem executadas acções
de leitura, actuação e configuração do sistema. Esta aplicação permite também visualizar resultados
enviados pelos nós em resposta às acções anteriormente descritas ou informação enviada de forma
autónoma (por exemplo, assinalando um evento ou um alarme). Ao utilizador do sistema é
disponibilizada a opção de visualização dos diferentes tipos de sensores e actuadores disponíveis em
cada nó, bem com informação sobre as configurações existentes nos vários nós da rede.

Neste trabalho é também proposto um modelo de especificação de um sistema de automação

residencial que envolve uma definição genérica de dispositivos domóticos e respectivas propriedades.
A elaboração deste modelo teve por base o modelo de abstracção de dispositivos proposto pelo
sistema DomoBus, cujo objectivo é representar de forma simples e genérica qualquer dispositivo
domótico de um sistema. Cada dispositivo é caracterizado por diversas propriedades, tendo cada
propriedade um valor que pode ser lido ou modificado de um modo normalizado. O modelo DomoBus
será adaptado e implementado numa rede de sensores sem fios.

O software realizado no âmbito desta tese é executado em ambiente TinyOS e desenvolvido na

linguagem nesC. O hardware utilizado para implementação e realização de testes é composto por nós
sem fios MICAz, uma placa de programação MIB520 e uma placa de sensores MTS310. As
características destes dispositivos encontram-se descritas na secção 2.1.2.

O desenvolvimento dos serviços descritos foi realizado após um estudo e uma sistematização das
funcionalidades existentes ou desejáveis num sistema de automação residencial, o que se apresenta
em seguida. De seguida são apresentados os diferentes comportamentos considerados na
elaboração dos serviços propostos.

56
4.1 Modo de Funcionamento dos Nós Sensores

Os nós sensores da rede sem fios sob a qual se pretende implementar um sistema de automação
residencial devem possuir a capacidade de executar diferentes comportamentos de interacção com o
nó sink, nó que desempenha a função de Gateway com um PC, e comportamentos de
processamento de dados pré-definidos.

Existem diversos comportamentos que caracterizam um sistema domótico, tanto a nível dos nós
como a nível de acções possíveis de execução por parte do utilizador do sistema:

Em qualquer instante o utilizador pode pedir informação sobre qualquer sensor ou

actuador existente na habitação (rede de sensores).

Um nó sensor deve ser capaz de avisar a raiz da rede (nó sink) aquando da detecção
de uma situação previamente programada (por exemplo, que o valor do sensor
ultrapassou, ou está abaixo, de determinado limiar). Deve também ser possível definir
uma gama de valores (através da explicitação de um limite superior e um limite
inferior) fora da qual o nó deve avisar a raiz.

Um nó da rede deve ser capaz de avisar a raiz quando detecta uma alteração no
valor dos seus sensores. Deverá ser possível definir qual a variação mínima no valor
lido que resulta num envio de mensagem à raiz. Essa variação corresponde à
diferença entre o último valor que foi comunicado e o valor actual. Caso essa
diferença seja superior a um valor pré-definido, então o nó deve reportar ao PC.

Um nó deve ser capaz de enviar dados de forma periódica. A utilização deste

comportamento deve ter em consideração as restrições de energia existentes numa
rede de sensores sem fios.

Deve ser possível detectar o estado de funcionamento de um nó para que o sistema

saiba que este ainda está activo. Desta forma, se não receber nenhuma informação,
o sistema pode concluir que ocorreu uma falha no nó. Este mecanismo pode usar
mensagens dedicadas (do tipo KeepAlive) ou mensagens comuns com informação
relevante sobre o estado do nó. Em alternativa ao descrito, em que o nó tem a
iniciativa, pode ser a aplicação existente no PC que inquire o nó de forma periódica.

Um nó pode ter contagem de tempo no seu microprocessador de forma a detectar

quanto tempo passou, por exemplo, desde que detectou a presença de alguém. Esta
característica torna o sistema mais robusto e mais suave do ponto de vista de
utilização. Um exemplo de aplicação é uma situação de controlo de uma luz de uma

57
 divisão. Caso não seja detectada presença nessa divisão, a luz só seria desligada
após, por exemplo, 3 minutos depois da pessoa ter saído. Evita-se que a luz se
desligue e a pessoa apenas se tenha ausentado por poucos instantes e queira voltar
à divisão em questão. A utilização de contagem de tempo num nó serve também para
que seja possível programar actividades em função de um determinado horário. Um
nó pode incluir um Real Time Clock – RTC e deste modo suportar comportamentos
mais complexos. Caso não tenha RTC, a capacidade de contagem de tempo poderá
ser restringida a poucas dezenas de minutos por razões de precisão.

Um nó deve conter informação actualizada sobre os seus actuadores, ou seja, que

dispositivos estão ligados, desligados ou qual o valor de actuação no instante actual.
E, sempre que o estado de um actuador é alterado, isso deve ser comunicado para o
nó sink/PC.

Um nó deve poder receber instruções para actuar sobre qualquer dispositivo que
esteja sob seu controlo.

Um nó pode ter capacidade de armazenamento de informação, por exemplo consumo

eléctrico num determinado aparelho, variação da temperatura, consumo de água, etc.
Esta funcionalidade é útil em caso de falha na comunicação do nó, permitindo
guardar leituras dos sensores. Os dados podem ser guardados com informação
temporal e com informação sobre qual o nó de onde foi recolhida a informação. Os
nós podem ainda enviar os seus dados para nós vizinhos. Se um nó tem capacidade
de ter Real Time Clock então é possível ter informação sobre a amostragem dos seus
sensores com elevada precisão. Caso não exista RTC, o nó possui apenas
informação sobre o tempo entre amostras, sendo mais difícil enviar informação para
os nós vizinhos devido à perda de informação temporal.

Um nó pode ter capacidade de processamento e de decisão. Aquando da detecção

de uma situação previamente definida, o nó é capaz de actuar localmente ou de
enviar mensagens para actuadores de outros nós. Para que o nó possa tomar
decisões ele necessita ser informado, ou inquirir, o estado dos sensores e actuadores
relevantes.

Um nó pode ter incorporado um mecanismo de segurança que previne situações de

potencial perigo ou estragos materiais. Em situações onde é necessário controlar
com fiabilidade e segurança um determinado dispositivo é necessário implementar
um mecanismo de segurança. O exemplo da rega automática é bastante elucidativo
desta característica. Numa situação em que se pretende ligar a rega do jardim
durante um intervalo de tempo relativamente longo é necessário poder desligar a

58
 água a qualquer instante. Em caso de falha na comunicação com o nó responsável
por esta operação a actuação que se encontra a decorrer deve ser desactivada. Para
que tal seja possível o nó deve ter um intervalo durante o qual deve receber uma
confirmação da instrução inicial que reactive a actuação. Caso não receba uma
confirmação dentro deste intervalo de tempo de segurança, a actuação deve acabar
(dispositivo deve desligar-se). O nó que comunicou a instrução deve enviar uma
mensagem a confirmar a mesma dentro do intervalo de tempo de segurança de forma
a manter activa a actuação. Esta característica previne que, no caso ilustrado da rega
automática, numa situação de falha de comunicação com o nó actuador, a água
permaneça aberta indefinidamente. Evitam-se assim situações de danos materiais e
de perigo para os residentes. Considere-se outro exemplo, relativo ao comando de
um forno eléctrico. Se a actuação não for reactivada periodicamente, o dispositivo
desliga-se automaticamente ao fim de um certo intervalo de tempo, evitando
possíveis situações perigosas.

Para suporte das funcionalidades identificadas acima basta o uso de três classes de interacções com
os nós:

Actuação simples ou temporizada em qualquer dispositivo da rede;

Leitura de valor de qualquer sensor ou actuador disponível na rede;

Configuração de comportamentos de execução nos nós: limites, temporizações,

gama de variação, comparações.

O desenvolvimento de software específico para os nós sensores está restringido às limitações do

hardware utilizado, nomeadamente a reduzida capacidade de armazenamento e capacidade
energética.

59
4.2 Arquitectura Geral do sistema desenvolvido

O sistema desenvolvido propõe uma abordagem simples, genérica, extensível e funcional aos
sistemas de automação residencial. A arquitectura do sistema a implementar nos nós sensores é
composta por quatro módulos distintos (ver figura 22): Módulo de Comunicações (MCom); Módulo de
Actuação Genérica (MAG); Módulo de Leitura Genérica (MLG); e Módulo de Interface com Hardware
(Sensores e Actuadores) (MIH).

Figura 22 - Arquitectura do sistema proposto

Pretende-se com a criação destes módulos que a execução do sistema seja independente da
tecnologia dos dispositivos utilizados. O Módulo de Interface com Hardware possui métodos
específicos para interacção com os dispositivos a controlar, sensores e actuadores. Desta forma, os
restantes módulos têm um funcionamento genérico, não necessitando de informação sobre as
especificações do hardware utilizado. Esta característica possibilita o uso da mesma implementação
dos restantes módulos em todos os nós sensores da rede, necessitando apenas de um Módulo de
Interface com Hardware específico para os dispositivos de cada nó. Os detalhes de configuração de
aquisição de valores dos sensores (frequência e duração da amostragem) fazem parte das
especificações contidas neste módulo.

O Módulo de Comunicação é responsável pela gestão das comunicações do nó com o exterior e

pelas mensagens locais do mesmo. As mensagens transmitidas na rede obedecem a um protocolo
desenvolvido para este sistema e que é descrito no capítulo 5. Este módulo deve ser capaz de
identificar a origem, destinatário, tipo e respectiva composição de todas as mensagens que processa.

Todos os comandos de actuação dos dispositivos de um nó são emitidos pelo Módulo de Actuação
Genérica (MAG). Este módulo executa as acções respeitantes aos actuadores do nó, enviando
comandos para o MIH com informação sobre qual o dispositivo alvo da actuação e respectivo valor.
Os modos de funcionamento complexo (actuação temporizada, etc.) são controlados a partir do MAG.

60
Os valores dos sensores são adquiridos pelo MIH de forma periódica e armazenados em memória. O
Módulo de Leitura Genérica é responsável pela aquisição dessa informação e tem a capacidade de
fornecer esses dados sempre que necessário. Este módulo suporta ainda a execução de
comportamentos mais complexos, como por exemplo a leitura periódica do valor de sensor
específico. Sempre que o valor de um actuador é alterado o MLG inicia o processo de notificação do
nó sink sobre tal acontecimento.

Os módulos MCom, MAG e MLG funcionam, como já referido, de forma independente da tecnologia
dos dispositivos do nó. A presente arquitectura inclui a possibilidade de existência de mensagens
locais resultantes de comportamentos definidos no nó. Como resultado da leitura de um valor de um
sensor o MLG pode criar uma mensagem de actuação local que o MCom deverá ser capaz de
interpretar e encaminhar para o MAG.

61
5. Detalhes de Implementação

5.1 Modelo de Dados

O modelo de especificação de sistema domótico proposto pretende tornar a representação dos

dispositivos (sensores e actuadores) simples e genérica. Cada dispositivo é caracterizado por um
conjunto de propriedades, sendo cada propriedade representada por uma estrutura de dados que
agrega informação de configuração da propriedade.

A estrutura de dados desenvolvida para representar uma propriedade é a seguinte:

typedef struct Property {

uint8_t Empty;
uint8_t PropId;
uint16_t Current_Value;
uint8_t Test_Op;
uint16_t Aux_Value;
uint8_t MsgId;
} Property;

Para além de conter informação que permite identificar a propriedade (PropId) e conhecer o seu valor
actual (Current_Value), a estrutura Property, através das variáveis Test_Op, Aux_Value e MsgId,
armazena configurações sobre o modo de processamento da propriedade. Estas especificações
permitem definir comportamentos do sistema em função do valor actual da propriedade. A utilização
de variáveis de 16 bit para representação do valor actual e valor auxiliar deve-se ao facto de estes
valores necessitarem de um maior número de bits para a sua representação. Os detalhes sobre o
modelo funcional associado ao processamento de propriedades são descritos na secção 5.4. Na
tabela 6 é feita uma descrição das variáveis da estrutura Property.

Tabela 6 - Descrição das variáveis do modelo de estrutura de dados de representação de propriedades de

um dispositivo

Variável Descrição
Empty Contém informação sobre o estado da estrutura: 0 (Preenchida) e 1 (Vazia)
PropId Identificador da propriedade
Current_Value Valor actual da propriedade
Test_Op Identificador do operador definido para a propriedade
Aux_Value Valor associado ao operador definido por Test_Op
MsgID Identificador da mensagem associada ao operador definido

A informação sobre todas as propriedades dos dispositivos de um nó sensor é armazenada numa

matriz de estruturas de dados do tipo Property de tamanho 5 x 10. Neste trabalho o tamanho desta
matriz corresponde às necessidades de implementação e de teste do sistema desenvolvido. O
tamanho desta estrutura de dados deve ser escolhido em função das necessidades do sistema a

62
implementar e das limitações de recursos do nó. Noutro tipo de plataforma, com menos restrições,
optar-se-ia pelo uso de alocação dinâmica de memória em vez de impor uma estrutura de dados de
dimensão fixa.

63
5.2 Protocolos de Comunicação

A aplicação de uma rede de sensores sem fios num sistema domótico necessita de mecanismos que
garantam fiabilidade e segurança nas comunicações entre dispositivos. A utilização de protocolos de
comunicação que garantam o cumprimento dos requisitos existentes é necessária na construção de
um sistema robusto. A transmissão de dados deve cumprir requisitos de segurança que garantam a
integridade, confidencialidade e autenticação da informação comunicada. O âmbito deste trabalho
não abrange o desenvolvimento de complexos protocolos de comunicação para transmissão de
mensagens entre nós. Para garantir uma correcta funcionalidade do sistema desenvolvido são
utilizados dois protocolos disponibilizados no ambiente TinyOS 2.0: Disseminação (entrega fiável de
um pacote de dados a todos os nós da rede) e Colecção de dados (entrega de pacotes de informação
aos nós raiz da rede). A integração de ambos os protocolos nos serviços desenvolvidos não implicou
qualquer modificação aos mesmos.

A transmissão de mensagens do nó raiz para os restantes nós da rede é feita utilizando o protocolo
de disseminação de dados. Através da existência de um identificador de destinatário apenas o nó
especificado interpreta a mensagem recebida, sendo a mesma ignorada pelos restantes nós da rede.

A comunicação de informação proveniente dos nós sensores com destino ao nó raiz é realizada
segundo o protocolo de colecção de dados. Os dados transmitidos são entregues apenas ao nó sink,
que encaminha os mesmos para a aplicação executada no PC ao qual se encontra ligado. A entrega
dos dados adquiridos nos sensores dos nós é suportada por este protocolo.

64
5.2.1 Disseminação de Dados

O protocolo de disseminação de dados [26] é um protocolo de redes de sensores básico que permite
a entrega fiável de dados a todos os nós da rede. A reconfiguração, inquirição e reprogramação da
rede é facilitada com a utilização deste protocolo. A fiabilidade da comunicação de dados torna o
sistema robusto a desconexões temporárias e a perdas de pacotes. Ao contrário dos tradicionais
protocolos de inundação, a disseminação de dados utiliza uma abordagem contínua que permite
detectar quando um nó tem informação em falta. A disseminação de um pequeno número de dados
requer um protocolo diferente do utilizado quando se pretende disseminar eficazmente um elevado
número de dados.

O protocolo de disseminação é composto por duas partes: controlo (Control Traffic) e dados (Data
Traffic). O tráfego de dados depende fortemente no tamanho dos dados enquanto o tráfego de
controlo tende a manter-se constante ao longo do tempo de vida da rede.

Devido às limitações de memória do tipo RAM nos nós utilizados no sistema TinyOS o protocolo de
disseminação considera os pacotes de dados como versões. A informação propagada na rede pelo
protocolo corresponde à versão mais recente. Esta característica implica que caso um nó perca
ligação com a rede durante um determinado período de tempo no qual a versão dos dados é
actualizada várias vezes, no momento em que este entra novamente na rede apenas recebe a versão
mais recente da informação transmitida. A actualização das versões de dados deve ser
correctamente coordenada, uma vez que quando dois nós executam uma actualização da versão
simultaneamente apenas um deles é bem sucedido.

65
5.2.2 Colecção de Dados

O protocolo de colecção de dados é um mecanismo de envio de dados de diversas fontes para nós
que se anunciam na rede como nós raiz. Neste trabalho foi utilizado o protocolo CTP (Collection Tree
Protocol) [27] e considerada apenas a existência de um nó de saída (nó raiz ou nó sink). Trata-se de
um protocolo de endereço livre, onde os nós sensores não enviam dados para um nó em particular,
escolhendo implicitamente o nó raiz a partir do nó especificado para o próximo encaminhamento. A
utilização de colecção de dados é comum na implementação de redes de sensores onde se pretende
recolher num único local os dados adquiridos pelos sensores durante um determinado período de
tempo.

O protocolo CTP assume que possui estimativas da qualidade das ligações aos seus nós vizinhos.
Esta característica permite estimar o número de transmissões necessárias para que a informação
chegue ao nó de saída. Este protocolo incorpora vários mecanismos que têm por objectivo melhorar a
fiabilidade da entrega de dados, não garantindo no entanto 100% de entrega. O CTP foi desenvolvido
para redes com tráfego relativamente baixo.

O protocolo de colecção de dados baseia-se em árvores, sendo os nós sensores considerados folhas.
Os nós sensores devem recolher a informação dos sensores e encaminhá-la para a árvore de modo a
que esta seja transmitida para um nó de saída. Quando um nó recebe informação proveniente de
outros nós, deve encaminhá-la na direcção do nó raiz.

O protocolo implementado, CTP, utiliza um gradiente de encaminhamento (routing gradient) para

definir o próximo salto na transmissão de informação. A presença de um campo denominado
“transmissões esperadas” (ETX – Expected Transmissions) define o gradiente de encaminhamento.
Os nós de saída da rede possuem um valor de ETX de 0. O valor de ETX de um nó é o valor de ETX
do seu nó pai mais o valor de ETX da sua ligação ao seu nó pai. A escolha de encaminhamento é
feita pelo caminho com menor valor de ETX.

A possibilidade de existência de ciclos infinitos de encaminhamento é um problema que pode emergir

da utilização do protocolo CTP. Esta situação ocorre geralmente quando um nó escolhe um novo
caminho que possui um valor de ETX significativamente mais elevado do que o anterior em resposta
a uma falha de conectividade de um nó pai candidato ao encaminhamento. Se o novo caminho incluir
um nó que é seu descendente, é iniciado um ciclo infinito. O protocolo CTP possui mecanismos para
lidar com este tipo de problemas. Sempre que um nó recebe um pacote com um gradiente de
encaminhamento inferior ao seu é detectada uma inconsistência na árvore. Este nó inicia um
processo de tentativa de resolução do problema detectado através do envio broadcast de uma
beacon frame para a rede com o objectivo de esta ser recebida pelo nó responsável pelo mau
encaminhamento da informação e resultar na correcção do erro detectado.
A implementação do protocolo CTP divide-se em três partes:

66

Um estimador de qualidade da ligação responsável por estimar o valor de ETX,
correspondente ao encaminhamento de informação para nós vizinhos realizado num
único salto.

Um mecanismo de gestão de caminhos que utiliza estimativas de ligação e

informação da rede para decidir para que nó vizinho devem ser encaminhados os
dados.

Um mecanismo de encaminhamento que mantém uma fila de pacotes para envio,

estando encarregue da decisão de transmissão dos mesmos. Este mecanismo é
responsável pelo tráfego que chega ao nó e pelo tráfego gerado no próprio nó.

67
5.3 Estrutura das Mensagens do Sistema

A comunicação entre nós da rede de sensores que serve de suporte para um sistema domótico é feita
através de rádio frequência e é complementada através do uso de protocolos de comunicação. As
mensagens enviadas obedecem a uma formatação criada para permitir a transmissão de informação
de forma eficaz e completa.

No sistema desenvolvido existem quatro tipos de mensagens: Actuação, Leitura, Configuração e

Informação.

Tabela 7 - Classificação de mensagens do sistema

Tipo de Mensagens Mensagens (Operação)

SET
Actuação

SET Temporized

GET
Leitura
GET Temporized

STOP GET Temporized

CONFIG
Configuração
DEL CONFIG

MSG CONFIG

REPORT
Informação

ACK (Acknowledgment)

Todas as mensagens são enviadas para um buffer cujo tamanho varia em função do protocolo
utilizado para transmissão da informação. Cada campo de uma mensagem tem 16 bit. No protocolo
de disseminação o buffer utilizado tem um tamanho fixo de 208 bit (máximo de 13 campos), 26 bytes.
No caso do protocolo de colecção o tamanho do buffer é 112 bit (máximo de 7 campos), 14 bytes. As
mensagens entre nós sensores dispõem de um buffer de 144 bit (máximo 9 campos), 18 bytes. A
variação no tamanho do buffer utilizado deriva do facto de que as mensagens enviadas por colecção,
mensagens com destino ao nó sink, são apenas mensagens de informação que necessitam de um
menor número de campos.

As mensagens de actuação, tal como indica o nome, são mensagens utilizadas para actuação em
dispositivos dos nós. São disponibilizados duas formas de actuação: simples (SET) e temporizada
(SET Temporized). Actuação temporizada é uma operação de actuação que é executada num
intervalo de tempo limitado, por exemplo a activação de um sistema de rega durante trinta minutos.
Após o período de tempo especificado para a actuação o dispositivo em causa é desligado.

As mensagens de actuação SET e SET Temporized são processadas de forma semelhante. O valor
definido para actuação é armazenado na estrutura de dados que contém informação sobre todas as

68
propriedades dos dispositivos e é efectuada a actuação pretendida. No caso da operação SET
Temporized é ainda executada a configuração de temporização da actuação. Esta configuração
realiza-se através da definição do operador associado à propriedade sob a qual é efectuada a
actuação. O valor da variável Test_Op que caracteriza esta propriedade, é definido de forma a
corresponder ao operador de temporização. Na variável Aux_Value é armazenado o tempo de
actuação pretendido e em MsgId é definida a mensagem a enviar quando a condição definida pelo
operador (Test_Op) for verdadeira. Através destes operadores são definidos os comportamentos do
nó sensor em função do valor das propriedades dos dispositivos. As mensagens de actuação têm a
seguinte estrutura:

SET:

Source Destiny Operation DeviceId PropId EventId Data

SET Temporized:

Time
Source Destiny Operation DeviceId PropId EventId Data
Interval

A leitura de valores de um actuador ou sensor de um nó é feita através da execução de mensagens

de leitura. Existem dois tipos de leitura possíveis: simples (GET) e periódica (GET Temporized). A
anulação da instrução de leitura periódica é feita através da mensagem STOP GET Temporized. A
estrutura das mensagens de leitura é a seguinte:

GET:

Source Destiny Operation DeviceId PropId EventId

GET Temporized:

Time
Source Destiny Operation DeviceId PropId EventId
Interval

STOP GET Temporized:

Time
Source Destiny Operation DeviceId PropId EventId
Interval

A configuração dos comportamentos do sistema é feita através da execução de mensagens de

configuração. A definição de novas configurações é realizada através de mensagens CONFIG. A
eliminação de configurações existentes no nó implica a execução da mensagem DEL CONFIG. As
mensagens do tipo MSG CONFIG permitem a configuração das mensagens associadas aos

69
operadores definidos para as propriedades. Os campos finais deste tipo de mensagens dependem da
mensagem que se pretende configurar. A estrutura das mensagens é a seguinte:

CONFIG:

Source Destiny Operation DeviceId PropId EventId Test_Op Aux_Value MsgId

DEL CONFIG:

Source Destiny Operation DeviceId PropId EventId Test_Op Aux_Value MsgId

MSG CONFIG:

Source Destiny Operation EventId msgNumber

msgInput msgDestiny msgOperation DeviceId PropId
Test_Op Aux_Value MsgId
Data Time Interval
Time Interval
Data

Os parâmetros de configuração das mensagens associadas a operadores definidos para as

propriedades são msgNumber, msgInput, msgDestiny, msgOperation, DeviceId e PropId. Os valores
definidos por msgNumber e msgInput correspondem ao identificador da mensagem a armazenar e ao
indicador de necessidade de inclusão de um valor de uma propriedade na mensagem,
respectivamente. Os restantes campos da mensagem MSG CONFIG são em tudo idênticos ao
formato definido para as mensagens correspondentes às operações disponibilizadas.

Os nós sensores enviam mensagem de REPORT sempre que é executado um pedido de leitura do
valor de um actuador ou sensor, quando o valor de um actuador é alterado e quando comunicam
novos valores de sensores. Qualquer mensagem enviada para um nó da rede é seguida pelo envio
de uma mensagem ACK que confirma a recepção de uma instrução por parte da aplicação. Estas
duas mensagens são designadas de mensagens de informação. A estrutura destas mensagens é a
seguinte:

REPORT:

Source Destiny Operation DeviceId PropId EventId Data

ACK:

Source Destiny Operation DeviceId EventId

70
5.4 Arquitectura Detalhada do Sistema - Modelo Funcional

O inicio de actividade de um nó sensor caracteriza-se pela criação de estruturas de dados que

servem de suporte para a informação tratada e pela inicialização do hardware de comunicação e de
aquisição de dados. É criada uma matriz de estruturas de dados do tipo Property (apresentada na
secção 5.1) responsável pelo armazenamento de informação sobre todas as propriedades dos
dispositivos do nó sensor. Os nós sensores não necessitam de receber quaisquer configurações
externas para iniciar a sua actividade. Após a execução dos processos de configuração inicial, o nó
inicia a sua actividade de aquisição de dados e encontra-se preparado para receber instruções da
rede de sensores sem fios. O modelo funcional do sistema desenvolvido é apresentado na figura 23.

Quando uma nova mensagem é recebida num nó sensor da rede, é efectuada uma análise à
informação que esta contém. A primeira acção executada pelo nó receptor da mensagem é o envio
de uma mensagem de ACK para o remetente especificado. Este mecanismo foi criado com o
propósito de melhorar a fiabilidade da transmissão de mensagens entre aplicações. Efectuado o
envio da mensagem de ACK e identificada a operação associada à mensagem recebida, dá-se inicio
ao processamento da instrução recepcionada.

Existem dez operadores possíveis de associar às propriedades dos dispositivos de cada nó. Na
tabela 8 é feita a descrição dos operadores disponibilizados para definição de comportamentos do
sistema desenvolvido.

As mensagens especificadas por MsgId correspondem a acções que se pretendem executar sempre
que a condição definida pelo operador se verificar verdadeira, podendo ser mensagens externas ou
internas (locais ao nó). O sistema possui um mecanismo de retransmissão de mensagens que
permite o reenvio de mensagens cuja respectiva mensagem de ACK não foi recepcionada. Caso se
trate de uma mensagem interna não é efectuada qualquer retransmissão. Este mecanismo é
implementado através das funções setEvent(eventId) e clearEvent(eventId). É definida uma matriz de
eventos na qual é armazenada informação sobre as mensagens enviadas para a rede que carecem
de confirmação de recepção. Sempre que uma mensagem ACK é recebida o evento correspondente
à mensagem original é eliminado da matriz de eventos.

71
 Tabela 8 - Descrição dos operadores disponibilizados para definição de comportamentos do sistema.

Valor do Operador Operador Descrição

0 NOP Nenhuma operação a realizar
Qualquer alteração ao valor da propriedade resulta na execução
1 ANY
da mensagem definida pela variável MsgId
Temporização – Iniciado timer de disparo único com período
igual ao valor armazenado na variável Aux_Value. Quando o
2 ∆t
timer expira é executada a mensagem definida pela variável
MsgId.
Variação – Sempre que o valor da propriedade sofre uma
3 ∆v variação superior à definida pelo valor da variável Aux_Value é
executada a mensagem definida pela variável MsgId.
Comparação entre o valor actual da propriedade e o valor
4 == definido pela variável Aux_Value. Caso sejam iguais é executada
a mensagem definida pela variável MsgId.
Comparação entre o valor actual da propriedade e o valor
definido pela variável Aux_Value. Caso o primeiro seja maior que
5 >
o segundo é executada a mensagem definida pela variável
MsgId.
Comparação entre o valor actual da propriedade e o valor
definido pela variável Aux_Value. Caso o primeiro seja maior, ou
6 ≥
igual, que o segundo é executada a mensagem definida pela
variável MsgId.
Comparação entre o valor actual da propriedade e o valor
definido pela variável Aux_Value. Caso o primeiro seja menor
7 <
que o segundo é executada a mensagem definida pela variável
MsgId.
Comparação entre o valor actual da propriedade e o valor
definido pela variável Aux_Value. Caso o primeiro seja menor, ou
8 ≤
igual, que o segundo é executada a mensagem definida pela
variável MsgId.
Comparação entre o valor actual da propriedade e o valor
definido pela variável Aux_Value. Caso estes valores sejam
9 <>
diferentes é executada a mensagem definida pela variável
MsgId.

A amostragem dos sensores dos nós é efectuada periodicamente. O período de amostragem

especificado no software desenvolvido tem o valor de 2 segundos. Neste trabalho são utilizados três
sensores diferentes: temperatura, luz e microfone. Os valores adquiridos são armazenados na matriz
de propriedades do sistema. Sempre que é executada esta actualização de valores, são igualmente
verificadas as condições definidas pelos operadores das propriedades dos dispositivos sensores. No
caso da validação de qualquer uma das condições é realizado o envio da mensagem indicada por
MsgId, tal como descrito anteriormente.

72
Figura 23 - Arquitectura detalhada do sistema desenvolvido para os nós sensores.

73
A recepção de mensagens de leitura de dados implica a criação e envio de mensagens do tipo
REPORT que posteriormente são enviadas para o requerente da informação. A leitura simples do
valor actual de uma propriedade é consequência da recepção de uma mensagem de GET. A leitura
periódica do valor de uma propriedade, GET Temporized, resulta no envio periódico de uma
mensagem de REPORT até ao momento de recepção de uma mensagem de STOP GET Temporized
que implica a anulação da instrução anterior.

Os comportamentos do nó são executados sempre que a condição definida para a propriedade em

análise é verdadeira. O valor da variável MsgId indica qual a mensagem a ser enviada como
resultado desse teste. A configuração das mensagens definidas por esta variável é feita através de
mensagens do tipo MSG CONFIG. Ao utilizador é permitida a configuração de cinco mensagens
(valor escolhido em concordância com as limitações de memória dos nós utilizados) que podem ser
executadas em função do teste da condição definida pelos operadores das propriedades. As
mensagens CONFIG permitem configurar propriedades através da definição das variáveis Test_Op,
Aux_Value e MsgId. Sempre que o utilizador desejar remover qualquer definição de comportamento
de uma determinada propriedade deverá enviar uma mensagem DEL CONFIG para o nó pretendido.
Para que a remoção da configuração seja efectuada com sucesso a informação contida nesta
mensagem deve ser igual à informação da mensagem CONFIG que deu origem à configuração no
primeiro momento.

74
5.5 Arquitectura do nó de saída (raiz/sink)

O nó de saída do sistema desenvolvido funciona como gateway entre a rede de sensores e a

aplicação de monitorização e controlo do sistema domótico executada no PC. As mensagens
enviadas da aplicação estão num formato diferente do formato das mensagens circulantes na rede de
sensores sem fios, pelo que foi criado um mecanismo de conversão entre estes dois formatos. Na
Figura 24 é representado um esquema das operações realizadas pelo nó de saída.

Figura 24 - Modelo funcional do nó de saída

O nó de saída tem a funcionalidade de receber mensagens da aplicação de monitorização e controlo,

converter para o formato da rede de sensores sem fios e enviar através de rádio frequência a
informação para a rede de sensores sem fios. O processo de conversão inverso realiza-se quando o
nó de saída recebe mensagens da rede de sensores com destino à aplicação existente no PC. As
mensagens provenientes do PC são enviadas para o nó de saída através da ligação por porta USB
estabelecida entre o PC e a placa programadora MIB520. Este nó encontra-se ligado à placa
programadora, sendo omissos os detalhes de transmissão de informação entre estes dois
dispositivos.

75
6. Interface Gráfica para Testes Funcionais

Num sistema de automação residencial interessa poder controlar todos os dispositivos do sistema a
partir de um único local. No seguimento do trabalho desenvolvido nesta tese, foi criada uma
aplicação, em linguagem de programação Java, que corre no PC que se encontra ligado ao nó raiz
(sink). Esta aplicação possibilita a interacção do utilizador com o sistema. Desta forma, é possível
configurar a rede de sensores e testar o comportamento dos nós sensores.

A aplicação desenvolvida permite o envio de mensagens num formato pré-definido (descrito na

secção 5.3), a visualização de informação sobre os diferentes tipos de sensores e actuadores
presentes nos nós da rede e informação sobre quais as configurações definidas nos nós do sistema
até ao momento.

Figura 25 - Aplicação de monitorização e controlo do sistema domótico

Na figura 25 é apresentada a aplicação desenvolvida para monitorização e controlo do sistema

domótico. Esta aplicação possui dois painéis principais: painel de interacção e painel de visualização.
O painel de interacção (figura 26), situado no lado esquerdo da janela, é composto por três painéis
secundários: Send Message, Node Properties, Existing Node Configurations, Window options.

76
 Figura 26 - Interface Gráfica: Painel de Interacção

O painel Send Message permite ao utilizador definir os parâmetros que compõem a mensagem que
este pretende enviar para a rede. Existem sete tipos de mensagens disponíveis: SET, SET
Temporized, GET, GET Temporized, STOP GET Temporized, CONFIG e DEL CONFIG (que já foram
descritas anteriormente). A escolha do tipo de mensagem é feita na caixa com o título Type of
Message, sendo que os parâmetros disponíveis para preenchimento são específicos para cada tipo
de mensagem. O envio da mensagem é feito através do botão SEND. Sempre que é enviada uma
mensagem é apresentado no painel de visualização a composição da mesma.

O painel Node Properties permite obter informação sobre quais os dispositivos existentes num
determinado nó do sistema. O utilizador deve especificar o nó e o tipo de dispositivo, sensor ou
actuador, e de seguida pressionar o botão SHOW. A informação pretendida é disponibilizada no
painel de visualização da aplicação.

A visualização de informação sobre as configurações existentes em qualquer nó do sistema é

controlada no painel Existing Node Configurations. Neste painel o utilizador escolhe o nó sobre o qual
deseja conhecer a informação, pressiona o botão SHOW e de seguida é apresentado no painel de
visualização da aplicação o resultado pretendido. Sempre que o utilizador envia uma mensagem de
configuração para um determinado nó, essa informação é armazenada na aplicação.

O painel Window Options disponibiliza dois botões, CLEAR WINDOW e EXIT, que permitem eliminar
todo o texto presente no painel de visualização e terminar a aplicação, respectivamente.

77
Toda a informação requisitada pelo utilizador no painel de interacção é apresentada no painel de
visualização. As mensagens enviadas pelos nós da rede de sensores para o nó sink são
encaminhadas para a aplicação desenvolvida e apresentadas no painel de visualização. Apenas as
mensagens especificadas no protocolo elaborado são direccionadas para a aplicação.

Figura 27 - Exemplo de leitura simples dos sensores de temperatura, luz e microfone.

O utilizador pode obter informação sobre quais os sensores disponíveis num determinado nó e
executar uma instrução de leitura periódica do valor desses mesmos sensores. Na figura 28 é
apresentado um exemplo de utilização da interface gráfica desenvolvida onde foi emitida uma
instrução de leitura periódica do sensor de luminosidade do nó dois, sendo de seguida anulada
através de uma mensagem STOP GET PERIODIC.

78
 Figura 28 - Exemplo de leitura periódica do sensor de luminosidade do nó dois.

A actuação periódica é outra das operações possíveis de realizar com o sistema desenvolvido. O
utilizador deve definir qual o actuador que pretende controlar e qual o intervalo de tempo durante o
qual o pretende fazer. O exemplo da figura 29 representa a actuação sobre o led vermelho do nó
sensor durante três segundos (no programa o valor de tempo é introduzido em milissegundos). Após
o intervalo de tempo especificado o led é desligado e o nó sensor informa o utilizador da mudança de
estado do actuador (última linha do painel de visualização).

Figura 29 - Exemplo de actuação temporizada sobre o led vermelho do nó sensor.

79
 Figura 30 - Exemplo de configuração de propriedade seguido de remoção dessa mesma configuração.

Na figura 30 é demonstrada a acção de configuração de uma propriedade de um nó sensor, seguida

da acção de remoção dessa mesma configuração. Para que a configuração de uma propriedade seja
executada de forma completa é necessário especificar qual o comportamento do nó que se deseja
que o nó execute quando se verificarem as condições programadas. A figura 31 apresenta um
exemplo de execução de uma mensagem de MSG CONFIG.

Figura 31 - Exemplo de configuração de mensagem de actuação.

80
A comunicação entre a aplicação desenvolvida e o nó raiz é feita através de uma placa programadora
MIB520 ligada ao PC por USB. A programação desta aplicação (linguagem Java) utiliza um protocolo
de comunicação específico do ambiente TinyOS para comunicação com um programa gestor de
pacotes de portas série e USB - Serial Forward. Este programa funciona como um gateway entre a
porta USB e a aplicação desenvolvida. A principal vantagem de utilização do Serial Forward é a
possibilidade de estabelecimento de ligação com múltiplas aplicações, executadas no PC onde se
encontra a ligação com o nó ou noutra plataforma que possua ligação à internet, que utilizam este
programa para interagir com a porta especificada. Esta característica pode ser proveitosa numa
potencial situação de controlo do sistema domótico a partir de uma localização fora da habitação.

Sempre que uma mensagem é enviada pela aplicação para o nó de saída é iniciada a contagem de
um tempo de retransmissão, caso a aplicação não receba uma mensagem de ACK, dentro deste
período de tempo, a confirmar a recepção da instrução, então a mensagem original é reenviada.
Definiu-se que a aplicação retransmite uma mensagem no máximo cinco vezes. Sempre que não é
necessária a execução do mecanismo de retransmissão o número do evento associado à mensagem
enviada é o valor fixo, 111, escolhido especificamente para este propósito.

Figura 32 - Esquema de comunicação entre a aplicação desenvolvida e a rede de sensores.

81
7. Conclusão

Na presente tese foi concebida e desenvolvida uma camada de serviços para permitir o uso de uma
rede de sensores sem fios no contexto da automação residencial. Para atingir este objectivo foi
efectuado um estudo das funcionalidades e especificações dos sistemas domóticos que permitiu
estabelecer os requisitos a cumprir na implementação sobre uma rede de sensores sem fios. Foi
igualmente efectuado um estudo das características das redes de sensores sem fios de modo que a
decisão sobre o modelo a adoptar fosse a mais adequada face às especificidades deste projecto.
Foram também estudadas aplicações já disponíveis em redes de sensores sem fios, no sentido de
verificar se eram adequadas ou de fácil adaptação aos nossos objectivos. Este estudo incidiu
particularmente sobre o software TinyDB que, numa primeira abordagem, foi considerado como
hipótese para modelo de suporte da implementação de uma rede de sensores sem fios num sistema
domótico. Aparentemente o TinyDB oferecia funcionalidades de aquisição de dados dos sensores, de
utilização de eventos activados em função de determinadas condições pré-definidas e de actuação
física que pareciam poder satisfazer às nossas necessidades. No entanto, o resultado da
investigação realizada permitiu concluir que as características do TinyDB não se adequavam às
necessidades deste projecto. E, por outro lado, foi constatada muito pouca flexibilidade do TinyDB no
que diz respeito a eventuais modificações e adaptações do seu modelo funcional, assim como uma
reduzida capacidade de interacção do utilizador com o sistema. Por último, foi ainda identificado que
nem todas as funcionalidades documentadas estavam efectivamente e correctamente
implementadas. O TinyDB, no seu modo de funcionamento típico, direcciona-se a redes de sensores
que adquirem dados e os armazenam internamente, sendo o acesso à informação feito de uma forma
esporádica, por solicitação, e não de uma forma contínua como se deve verificar numa habitação,
para assegurar a sua correcta gestão.

Neste trabalho foi elaborada uma lista de funcionalidades necessárias de existir nos nós sensores de
uma rede sem fios para que a sua aplicação num sistema de automação residencial permita a
execução de processos que possibilitem ao utilizador usufruir de todo o potencial que a domótica
oferece. A identificação dessas funcionalidades revelou-se extremamente importante para o
desenvolvimento de um sistema com as características especificadas neste projecto.

Tendo por base a análise efectuada, optou-se pelo desenvolvimento de uma abordagem baseada no
modelo DomoBus que oferece uma representação simples, flexível e genérica dos dispositivos
domóticos e permite a integração de tecnologias diversas num mesmo sistema, característica em falta
nos actuais sistemas de automação residencial disponíveis no mercado. O sistema desenvolvido
possibilita a implementação de uma rede de nós sensores sem fio numa habitação, permitindo o
controlo de diversos dispositivos de forma automatizada e localizada.

82
Os serviços disponibilizados implementam diversas funcionalidades necessárias num sistema
domótico, que vão desde actuação simples, temporizada, leitura de valores simples ou leitura
periódica e configuração de comportamentos complexos em função dos valores lidos pelos sensores.

Foi ainda desenvolvida uma interface gráfica que corre num PC que se encontra ligado a um nó raiz
(sink) da rede de nós sensores. Através deste nó são enviadas instruções de
actuação/leitura/configuração para toda a rede.

A programação dos nós sensores foi efectuada em ambiente TinyOS 2.0 e realizada na linguagem
nesC. A interface gráfica foi desenvolvida na linguagem java.

A implementação das funcionalidades pretendidas implicou um esforço ao nível da programação dos

nós sensores e permitiu identificar algumas limitações de utilização do sistema operativo TinyOS 2.0.
A possibilidade de configuração dinâmica do comportamento associado a propriedades dos nós do
sistema resulta na necessidade de uma gestão cuidadosa dos recursos de hardware disponíveis.
Esta característica revela-se especialmente nas operações que envolvem temporização. Os serviços
disponibilizados permitem ao utilizador definir actuações temporizadas para todas as propriedades
dos dispositivos actuadores do nó. A utilização de timers específicos para cada operação implica a
declaração prévia dos mesmos. Esta limitação pode ser ultrapassada com a criação de um
mecanismo de gestão temporal que permita a contagem de tempo suportada apenas por uma base
temporal. Devido a limitações temporais na concretização deste projecto e à complexidade dos temas
envolvidos não foi possível desenvolver tal mecanismo. São disponibilizados apenas dez timers, cinco
para actuação e outros cinco para leitura de dados. A opção tomada não restringe a execução do
sistema, permitindo mesmo o teste das capacidades do mesmo. Considera-se interessante a criação
futura do mecanismo descrito.

No contexto desta dissertação não é efectuado um estudo aprofundado de protocolos de

comunicação que assegurem a melhor gestão da informação transmitida no que diz respeito a
segurança e poupança de energia nos nós. Um sistema de automação residencial comercial
constituído por uma rede de sensores sem fios deve ter considerações de segurança que assegurem
a autenticidade, confidencialidade e integridade das comunicações. As limitações energéticas dos
nós sensores implicam uma gestão eficiente de todos os processos executados nos nós. Considera-
se que futuros desenvolvimentos no âmbito deste projecto devem considerar a implementação de
serviços de segurança e de gestão energética nos nós sensores.

83
Referências

[1] Crossbow Technology, Inc., http://www.xbow.com

[2] Crossbow Technology, Inc., “MPR-MIB Users Manual”, Revision A, June 2007.

[3] Crossbow Technology, Inc., “MTS/MDA Sensor Board Users Manual”, Revision A, June 2007.

[4] Linnyer Beatrys Ruiz, Luiz Henrique A. Correia, Luiz Filipe M. Vieira, Daniel F. Macedo, Eduardo F.
Nakamura, Carlos M. S. Figueiredo, Marcos Augusto M. Vieira, Eduardo Habib Mechelane, Daniel
Camara, Antonio A.F. Loureiro, José Marcos S. Nogueira, Diógenes C. da Silva Jr., “Arquiteturas para
Redes de Sensores Sem Fio”, SBRC Tutorial Maio 2004, Capitulo 4, páginas 167-218.

[5] António A.F. Loureiro, José Marcos S. Nogueira, Linnyer Beatrys Ruiz, Raquel Aparecida de
Freitas Mini, Eduardo Freire Nakamura, Carlos Maurício Seródio Figueiredo “Rede de Sensores sem
Fios”, Simpósio Brasileiro de Redes de Computadores, Natal, RN, Março de 2003.

[6] Philip Levis, “TinyOS Programming”, June 28, 2006.

[7] Contiki Operating System for Networked Embedded Systems, http://www.sics.se/contiki/

[8] SOS Embedded Operating System, https://projects.nesl.ucla.edu/public/sos-2x/doc/

[9] MANTIS Operating System, http://mantis.cs.colorado.edu/index.php/tiki-index.php

[10] David Gay, Phil Levis, Rob von Behren, Matt Welsh, Eric Brewer, and David Culler, “The nesC
Language: A Holistic Approach to Networked Embedded Systems”, in Proceedings of Programming
Language Design and Implementation (PLDI) 2003, June 2003.

[11] EIB, http://www.eib.org

[12] X10, http://www.smarthomeusa.com/info/x10theory/#theory

[13] LonWorks, http://www.echelon.com/developers/lonworks/default.htm

[14] C-Bus, http://www.clipsal.com/

[15] Renato Nunes, "DomoBus - A New Approach to Home Automation", 8CLEEE - 8th International
Congress on Electrical Engineering, Portugal, July 2003, pp.2.19-2.24.

84
[16] 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.

[17] Christian Reinisch, Wolfgang Kastner, Georg Neugschwandtner, Wolfgang Granzer, “Wireless
Technologies in Home and Building Automation”, 2007 5th IEEE International Conference on
Industrial Informatics, 23-27 June 2007, pp. 93-98.

[18] EnOcean, http://www.enocean.com

[19] Z-Wave, http://www.z-wave.com

[20] nanoNET, http://www.nanonet.org.uk

[21] KNX RF, http://www.knx.org

[22] Samuel Madden, Michael J. Fraklin, Joseph M. Hellerstein, Wei Hong, “TinyDB: An Acquisitional
Query Processing System for Sensor Networks”, 2005, ACM Trans. Database Syst., 30, 122-173.

[23] Leif Morten Kofoed, “Enhancing sensor network programming: Extending TinyDB with HAVING
and aggregation, and investigating TinyDB reliability”, Master Thesis, University of Oslo – Department
of Informatics, 1 November 2007.

[24] Samuel Madden, Joe Hellerstein, Wei Hong, “TinyDB: In-Network Query Processing in TinyOS”,
Version 0.4, September 2003.

[25] René Müller, Gustavo Alonso,“A Virtual Machine For Sensor Networks”,in Proceedings of the
EuroSys 2007 Conference, Lisbon, Portugal, March 21-23, 2007.

[26] Philip Levis, Gilman Tolle, “TEP 118: Dissemination”, Net2 Working Group, TinyOS Community,
version 1.7, 14 June 2007.

[27] Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Sukun Kim, Philip Levis, Alec Woo, “TEP
123: The Collection Tree Protocol (CTP)”, Network Working Group, TinyOS Community, version 1.8,
28 February 2007.

[28] Renato Nunes, “A Communication Infrastructure for Home Automation”, International Conference
on Computer, Communications and Control Technologies, Austin, USA, August 2004, pp. 56-61.

[29] Renato Nunes, “Implementing Tiny Embedded Systems with Networking Capabilities”, IADIS
International Conference on Applied Computing 2005, Algarve, Portugal, February 2005.

85
[30] Renato Nunes, "Decentralized Supervision for Home Automation", MELECON 2006 - The 13th
IEEE Mediterranean Electrotechnical Conference, Benalmádena, Spain, May 2006.

[31] Vincent Ricquebourg, David Menga, David Durand, Bruno Marhic, Laurent Delahoche, Christophe
Logé, “The Smart Home Concept : our immediate future”, 2006 1ST IEEE International Conference on
E-Learning in Industrial Electronics, Page(s): 23 – 28, 18-20 December. 2006.

[32] Philip Levis, Cory Sharp, “TEP 106: Schedulers and Tasks”, Core Working Group, TinyOS
Community.

[33] Philip Levis, “TEP 107: TinyOS 2.x Boot Sequence”, Core Working Group, TinyOS Community.

[34] Ben Greenstein and Philip Levis, “TEP 113: Serial Communication”, Core Working Group, TinyOS
Community.

[35] Cory Sharp, Martin Turon, David Gay, “TEP 2: Timers”, Core Working Group, TinyOS Community.

86