Ligação Rádio entre Controladores Domóticos

João Carlos Gonçalves Viana Gomes

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

Engenharia Electrotécnica e de Computadores

Orientadores: Prof. Renato Jorge Caleira Nunes

Prof. Paulo Rogério Barreiros D’Almeida Pereira

Júri

Presidente: Prof. Nuno Cavaco Gomes Horta

Orientador: Prof. Renato Jorge Caleira Nunes

Vogal: Prof. Nuno Filipe Valentim Roma

Outubro 2014

i

Resumo

Este projecto aborda a implementação de controladores domóticos que serão a base das redes de

controlo sem-fios DomoBus.

O protocolo DomoBus tem como principal objectivo unificar diferentes tecnologias domóticas num

só protocolo de alto-nível, de modo a criar uma camada de abstração sobre a qual se podem

controlar genericamente vários tipos de dispositivos sem ter que se diferenciar a tecnologia inerente a

cada um. Para além de se integrar com protocolos de automação residencial já existentes, o

DomoBus pretende apresentar a sua própria solução para controladores de baixo-nível,

desenvolvidos tendo em consideração ambientes super-automatizados compostos por múltiplas

redes com dezenas ou centenas de dispositivos.

Os controladores implementados caracterizam-se por serem modulares, facilmente configuráveis,

utilizarem módulos RF disponíveis no mercado e recorrerem a componentes de baixo custo. Estes

controladores têm a capacidade de construir uma rede fiável e segura a um preço acessível, o que

promove a escalabilidade necessária para a criação de redes de controladores de grandes

dimensões.

Adicionalmente, implementaram-se outros dispositivos auxiliares que vieram permitir a integração

destas redes de controladores no DomoBus, ao fazerem a ponte entre o protocolo de alto-nível

(genérico a todas as tecnologias) e o de baixo-nível utilizado neste projecto.

Os dispositivos desenvolvidos permitiram incorporar no sistema DomoBus as capacidades de

monitorização e controlo de uma rede de sensores e actuadores sem-fios robusta, funcional e

altamente personalizável, o que se veio a revelar ser uma mais-valia num sistema que se pretende

flexível e prático.

Palavras-chave

Domótica, DomoBus, ambientes super-automatizados, controladores domóticos, comunicação

sem-fios

ii

Abstract

This project addresses the implementation of a wireless domotic controller to be used as the main

building block of a DomoBus Wireless Control Network.

The DomoBus protocol aims to bring together multiple domotic technologies into a single high level

protocol that will allow the final user to address them all in a common way and thus acting as an

abstraction layer where more powerful functionalities can be built regardless of the underlying

protocols. Besides being able to work with existing technologies, DomoBus aims to implement its own

low-level controllers that are designed specifically to cover the needs on super-automated

environments.

These wireless controllers need to perform a multi-tasking control of its connected devices

(sensors and actuators), to be cost-effective and to be easily configurable. All of these characteristics

are achieved by breaking down each controller to a set of functional models (both in hardware as in

software) that can be interchangeable to allow the construction of custom made low-level wireless

domotic controllers. These controllers are able to form a reliable, secure and easily scalable network

using off-the-shelf RF modules in order to provide the needed base for DomoBus home automation

networks.

Apart from the wireless controllers some additional components have been developed to allow the

interaction between the DomoBus generic high level devices and the low level ones previously

described. All these developed devices allow a reliable and convenient extension of the DomoBus

system functionalities without compromising its flexibility.

Keywords

Home automation, Domotics, DomoBus, super-automated environments, domotic controllers,

wireless communication

iii

Índice

Resumo ................................................................................................................................................i

Palavras-chave .....................................................................................................................................i

Abstract ............................................................................................................................................... ii

Keywords ............................................................................................................................................. ii

Índice .................................................................................................................................................. iii

Lista de figuras ....................................................................................................................................v

Lista de tabelas ................................................................................................................................. vii

Lista de símbolos e abreviações ...................................................................................................... viii

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

1.1 Contexto .............................................................................................................................. 1

1.2 Motivação ............................................................................................................................ 2

1.3 Objectivos ............................................................................................................................ 3

1.4 Estrutura da dissertação ...................................................................................................... 4

2 Estado da arte ............................................................................................................................. 5

2.1 Tecnologias Domóticas ....................................................................................................... 5

2.1.1 CEBus .......................................................................................................................... 6

2.1.2 LonWorks ..................................................................................................................... 7

2.1.3 ZigBee ......................................................................................................................... 9

2.1.4 Z-Wave ...................................................................................................................... 12

2.1.5 Insteon ....................................................................................................................... 14

2.2 Módulos RF ....................................................................................................................... 16

2.2.1 Wi-Fi (802.11) ............................................................................................................ 17

2.2.2 Bluetooth .................................................................................................................... 18

2.2.3 ZigBee ....................................................................................................................... 21

2.2.4 nRF24L01+ ................................................................................................................ 22

2.2.5 nRF905 ...................................................................................................................... 23

2.2.6 RFM12B ..................................................................................................................... 24

2.2.7 RFM22B ..................................................................................................................... 24

2.2.8 CC1000 ...................................................................................................................... 25

3 DomoBus ................................................................................................................................... 26

iv

3.1 Visão Geral ........................................................................................................................ 26

3.2 Tipos de dispositivos ......................................................................................................... 27

3.3 Especificação DomoBus .................................................................................................... 31

4 Descrição da solução proposta ................................................................................................. 37

4.1 Rede .................................................................................................................................. 37

4.1.1 Topologia ................................................................................................................... 38

4.1.2 Segurança ................................................................................................................. 40

4.1.3 Módulo RF ................................................................................................................. 41

4.2 Arquitectura do módulo controlador .................................................................................. 47

4.3 Microcontrolador ................................................................................................................ 49

4.4 Módulos do controlador ..................................................................................................... 52

4.4.1 Módulos de dispositivos ............................................................................................ 52

4.4.2 Módulo de alimentação ............................................................................................. 53

4.4.3 Módulo de rede .......................................................................................................... 55

4.5 Módulo Gateway ................................................................................................................ 55

4.6 SLAG ................................................................................................................................. 56

5 Implementação .......................................................................................................................... 57

5.1 Módulo de controlo ............................................................................................................ 57

5.1.1 Software ..................................................................................................................... 57

5.1.2 Hardware ................................................................................................................... 68

5.2 Módulo gateway................................................................................................................. 70

5.2.1 Software ..................................................................................................................... 71

5.2.2 Hardware ................................................................................................................... 72

5.3 SLAG ................................................................................................................................. 73

5.3.1 Software ..................................................................................................................... 74

5.3.2 Hardware ................................................................................................................... 75

Conclusões ....................................................................................................................................... 76

Bibliografia ........................................................................................................................................ 78

Anexos ............................................................................................................................................. A-1

v

Lista de figuras

Figura 2.1 – Camadas de rede da especificação 802.15 em comparação com o modelo OSI ...... 20

Figura 2.2 – Camadas de rede da especificação ZigBee em comparação com o modelo OSI ...... 22

Figura 3.1 – Módulo gateway e as suas interfaces .......................................................................... 27

Figura 3.2 – Arquitectura de uma rede DomoBus............................................................................ 30

Figura 3.3 – Cabeçalho de uma propriedade ................................................................................... 31

Figura 3.4 – Possíveis estruturas de dados para as propriedades .................................................. 31

Figura 3.5 – Detalhes do endereçamento no protocolo DomoBus .................................................. 33

Figura 3.6 – Estrutura das tramas SL .............................................................................................. 34

Figura 3.7 – Estrutura do Byte CTR nas tramas SL......................................................................... 34

Figura 3.8 – Estrutura das tramas CL .............................................................................................. 35

Figura 3.9 – Estrutura dos endereços DCN (CDev)......................................................................... 36

Figura 4.1 – Estrutura do Byte CTR no CL para as redes DWCN. .................................................. 40

Figura 4.2 – As duas versões mais comuns de módulos RF que utilizam o chip nRF24L01+ ........ 44

Figura 4.3 – Antenas para expandir o alcance de sinais na banda dos 2.4GHz ............................. 44

Figura 4.4 – Formato das tramas geradas pelo protocolo Enhanced Shockburst ........................... 46

Figura 4.5 – Arquitectura do módulo controlador ............................................................................. 47

Figura 4.6 – Modularização do módulo controlador ......................................................................... 49

Figura 4.7 – Relação entre tensão de alimentação do ATMega328P e frequências de relógio ..... 53

Figura 4.8 – Adaptadores de 230VAC para 5VDC .............................................................................. 53

Figura 4.9 – Possíveis alternativas para módulos de alimentação .................................................. 54

Figura 4.10 - Módulos gateway a operarem como periféricos do módulo supervisor ..................... 55

Figura 4.11 - Módulos gateway a operar com ligação ethernet ....................................................... 56

Figura 5.1 – Endereçamento dos nós da árvore .............................................................................. 62

Figura 5.2 – Exemplo de uma rede. ................................................................................................. 63

Figura 5.3 – Exemplo da situação de sobrelotação de todos os canais RF. ................................... 63

Figura 5.4 – Endereçamento CL nas DWCN ................................................................................... 64

Figura 5.5 – Ligação directa entre módulo de supervisão e nRF24L01+ por SPI ........................... 70

Figura 5.6 – Ligação ao módulo gateway por USB.......................................................................... 71

Figura 5.7 – Ligação ao módulo gateway por ethernet .................................................................... 71

Figura 5.8 – Módulos de rede utilizados .......................................................................................... 73

Figura 5.9 – Métodos da classe gateway para lidar com as comunicações .................................... 74

Figura A4.1 – Fluxo principal do módulo controlador simplificado ..................................................... 5

Figura A4.2 – Exemplo do algoritmo de re-estruturação da rede ...................................................... 5

Figura A4.3 – Fluxograma simplificado do algoritmo de pesquisa por endereços ............................ 6

Figura A4.4 – Diferentes camadas de rede e a sua relação com a encriptação dos dados ............. 7

Figura A4.5 – Fluxograma da gestão de temporizações pela classe genericApp ............................. 8

Figura A4.6 – Circuito exemplo de um módulo controlador ............................................................... 9

Figura A4.7 – Circuitos dos módulos de alimentação. ..................................................................... 10

Figura A4.8 – Dispositivos para utilizar com a NApp1 (escrita digital). ........................................... 11

vi

Figura A4.9 - Dispositivos para utilizar com a NApp2 (leitura digital) .............................................. 11

Figura A4.10 - Dispositivos para utilizar com a NApp3 (escrita analógica ou PWM) ...................... 11

Figura A4.11 – Dispositivos para utilizar com a NApp4 (leitura analógica) ..................................... 11

Figura A4.12 – Dispositivos para utilizar com a NApp5 (OneWire) ................................................. 11

Figura A4.13 – Dispositivos para utilizar com a NApp6 (DHT). ....................................................... 12

Figura A4.14 – Dispositivo para utilizar com a NApp7 (receptor de infravermelhos) ...................... 12

Figura A4.15 – Dispositivo para utilizar com a NApp8 (HC-SR04) .................................................. 12

Figura A4.16 – Conectores JST XH 2.54mm de 4 pinos ................................................................. 12

Figura A5.1 – Circuito do protótipo................................................................................................... 13

Figura A6.1 – Fluxograma de como deverá ser utilizado o objecto gateway .................................. 14

Figura A6.2 – Interface gráfica implementada para testar e validar as comunicações ................... 14

vii

Lista de tabelas

Tabela 2.1 - Listagem de chips Wi-Fi predominantes no mercado actualmente ............................. 17

Tabela 2.2 – Comparação do protocolo Bluetooth com o protocolo Bluetooth LE .......................... 19

Tabela 2.3 – Limitações na conectividade dos diferentes chips Bluetooth LE ................................ 20

Tabela 3.1 – Diferentes tipos de propriedades ................................................................................ 31

Tabela 3.2 –Diferentes tipos de OpCodes ....................................................................................... 35

Tabela 4.1 – Diferentes configurações para o amplificador de potência interno ............................. 45

Tabela 4.2 - Comparação entre os requisitos e o microcontrolador ATMega328P ......................... 51

Tabela 5.1 – Tipos de configurações dos módulos controladores ................................................... 61

Tabela 5.2 – Relação entre diferentes métodos de representar o endereço dos nós ..................... 62

Tabela A2.1 - Listagem de módulos Wi-Fi ......................................................................................... 2

Tabela A2.2 – Listagem de módulos ZigBee ..................................................................................... 2

Tabela A2.3 - Listagem de módulos Bluetooth LE ............................................................................. 3

Tabela A2.4 – Listagem de módulos nRF24L01+ .............................................................................. 3

Tabela A2.5 – Listagem de módulos nRF905 .................................................................................... 3

Tabela A2.6 – Listagem de módulos RFM12B, RFM22B, CC1000 e CC1101 ................................. 3

Tabela A4.1 – Diferentes opções que cada aplicação implementa através do objecto genericApp . 7

Tabela A4.2 – Custo do protótipo do módulo controlador ................................................................. 9

Tabela A4.3 – Mapeamento dos portos do ATMega328P ............................................................... 10

Tabela A5.1 – Custo do protótipo multi-funções que permite implementar o módulo gateway ...... 13

Tabela A6.1 – Diferentes métodos de inicialização do objecto Gateway ........................................ 14

viii

Lista de símbolos e abreviações

ACK Acknowledgement ADC Analog to Digital Converter AES Advanced Encryption Standard API Application Programming Interface BLE Bluetooth Low Energy CL Control Level (DomoBus) DC Direct Current DCN DomoBus Control Network DHCP Dynamic Host Configuration Protocol DIP Dual In-line Package DNS Domain Name System DWCN DomoBus Wireless Control Network FSK Frequency-shift keying GFSK Gaussian frequency-shift keying I2C Inter-Integrated Circuit IDE Integrated development environment IP Internet Protocol IRQ Interrupt request ISM Industrial, Scientific and Medical (radio bands) ISP In-System Programming JST Japan Solderless Terminal LAN Local Area Network LED Light-emitting diode LNA Low-noise amplifier MAC Media Access Control NAT Network Address Translation OOK On-off keying OSI Open Systems Interconnection PA Power Amplifier PAN Personal Area Network PCB Printed Circuit Board PHP PHP Hypertext Preprocessor PoE Power over Ethernet PSK Pre-shared key PWM Pulse-width modulation QFN Quad Flat No leads RDEE Rede de distribuição de energia eléctrica RF Radiofrequência RX Receive / Receiver SCK Serial Clock SL Supervision Level (DomoBus) SMA SubMiniature version A (tipo de conector coaxial) SMS Short Message Service SNMP Simple Network Management Protocol SoC System on a chip SPI Serial Peripheral Interface TCP Transmission Control Protocol TTL Transistor–transistor logic TX Transceiver UART Universal asynchronous receiver/transmitter UDP User Datagram Protocol UPnP Universal Plug and Play USB Universal Serial Bus VPN Virtual Private Network WPA Wi-Fi Protected Access XML Extensible Markup Language

ix

kb/s 103 bits por segundo Mb/s 106 bits por segundo KiB 210 Bytes MiB 220 Bytes

1

1 Introdução

1.1 Contexto

A constante procura do ser humano pela satisfação das suas necessidades básicas de bem-estar,

segurança e conforto trouxe-nos ao mundo actual onde a tecnologia se tornou de tal modo

indispensável no nosso quotidiano que é impossível imaginar um futuro próspero sem a mesma. O

século XX notabilizou-se pelos inúmeros avanços tecnológicos nas mais diversas áreas,

nomeadamente na automação industrial que permitiu usar tecnologia de uma forma eficiente para

construir mais tecnologia resultando num aumento das capacidades humanas, individuais e

colectivas, como nunca antes visto na nossa história.

No entanto, dentro das nossas casas, à excepção de grandes descobertas como a electricidade e

tecnologias de comunicação como a televisão ou a internet, os progressos não têm acompanhado o

ritmo de evolução constante do mundo lá fora. A domótica - automação residencial - não depende

propriamente de tecnologia de ponta, e já existem há algum tempo soluções engenhosas como por

exemplo aspiradores inteligentes ou sistemas que actuam por reconhecimento vocal que auxiliam o

ser humano na sua procura por conforto através da eliminação de rotinas do seu dia-a-dia. No

entanto, não se verifica uma ampla utilização de sistemas domóticos nas casas do presente, em

grande parte porque existem diversas soluções para os diversos problemas que acabam por estar

isoladas entre si não permitindo um controlo unificado das tecnologias implementadas, e ainda

porque o preço a pagar pelo conforto extra é maior do que o comum cidadão está disposto a oferecer,

fazendo com que até aos dias de hoje a domótica seja vista como um luxo apenas ao alcance de

alguns.

A utilização de tecnologias domóticas geralmente recai sobre dois tipos diferentes de utilizadores:

os que são curiosos sobre o tema e acabam por aprender as terminologias e especificações relativas

a cada tecnologia sendo assim capazes de construírem e gerirem o seu próprio sistema, ou os que

requisitam uma instalação de um sistema para implementar funcionalidades pré-definidas que

acabam por ser planeados e instalados por empresas especializadas resultando num sistema

estático, difícil de ser reconfigurado para outros fins ou para interagir com outras tecnologias que

poderão vir a ser instaladas no futuro. Este carácter pouco dinâmico numa actualidade em que a

tecnologia está em constante evolução não atrai os consumidores pois dá demasiado peso ao

planeamento inicial e ao investimento que terá de ser feito pelos mesmos.

Assim, continua ainda nos dias de hoje a procura por um verdadeiro padrão globalmente aceite

que permita lidar com as tarefas de baixo nível no contexto da automação residencial, de modo a

permitir criar uma base para que possam ser construídos os dispositivos verdadeiramente

inteligentes, capazes de inferir acções mediante as leituras das suas redes de sensores, e que

permita criar uma rampa de lançamento para todas as potencialidades existentes nesta importante

2

parte da vida quotidiana humana onde a tecnologia ainda não se estabeleceu minimamente ao nível

das suas potencialidades.

1.2 Motivação

No final do século XX começaram a surgir protocolos que pretendiam uniformizar o modo como as

tecnologias do lar interagiam entre si, como por exemplo o X-10 (1975) ou CEBus (1984-1992), e até

aos dias de hoje continuam a sair novos protocolos, sendo que nenhum deles foi amplamente

adoptado mundialmente como um standard global, acabando por existir uns mais comuns numas

partes do mundo e outros noutras. Neste início do século XXI começa-se a notar um esforço não para

criar o derradeiro protocolo que destronará todos os outros, mas para criar sistemas que se integrem

com os diversos protocolos já existentes e consigam abstrair as diferentes tecnologias numa única de

mais alto-nível, de modo a oferecer praticabilidade na implementação de tecnologia no lar. Como

exemplos desta abordagem temos empresas como a Crestron ou a HomeSeer.

É neste contexto que se insere o DomoBus, um sistema que pretende uniformizar as camadas

mais baixas dos dispositivos domóticos, os controladores e encaminhadores, independentemente das

suas especificações e do meio pelo qual comuniquem, numa camada de alto-nível orientada ao

utilizador. Assim pretende-se construir uma base sólida sobre um conjunto de protocolos domóticos,

que permita abstrair das diferentes implementações actualmente existentes de modo a poder unificar

todas estas e proporcionar um controlo centralizado que poderá vir a fornecer a simplicidade que se

procura na gestão integrada das diferentes áreas (climatização, iluminação, segurança, etc.).

Pretende-se assim que seja o utilizador final a poder controlar a sua casa como deseja e não que

seja a tecnologia que adoptou inicialmente a ditar como fazê-lo.

Em simultâneo à construção de uma camada de alto-nível que permita unificar todas as

tecnologias, o DomoBus também especifica um protocolo de baixo-nível elaborado tendo já em mente

as habitações super-automatizadas do futuro, onde existe um grande número de controladores

espalhados pela habitação com diversas funções que poderão ser organizados logicamente e geridos

de formas práticas pelo utilizador, mascarando toda a complexidade inerente às diversas redes

físicas que suportam os conjuntos de sensores e actuadores num simples sistema de cenários,

condições e eventos. Este protocolo de baixo-nível não pretende ser compatível com qualquer

tecnologia domótica já existente, pelo contrário, pretende permitir o desenvolvimento de dispositivos

que se apresentarão como concorrentes a todos os outros já existentes e que colmatem as principais

falhas dos mesmos, nomeadamente no que toca à sua flexibilidade, funcionalidade e custo final.

Assim, o objectivo do DomoBus no alto-nível é permitir a coexistência de todas as tecnologias com

maior expressividade na actualidade e permitir a sistemas já implementados a possibilidade de se

expandirem com controladores domóticos específicos ao protocolo DomoBus baixo-nível de modo a

poder oferecer uma solução mais completa sem necessidade de refazer toda a infraestrutura já

existente.

3

1.3 Objectivos

O objectivo principal deste projecto é o de desenvolver controladores que possuam capacidades

de comunicação sem-fios recorrendo a módulos RF disponíveis no mercado. A comunicação

pretende-se fiável para que não comprometa a experiência do utilizador e para que toda a

configuração e gestão dos nós possa ser feita pelo canal de comunicação criado pelo módulo RF. Os

controladores pretendem-se modulares de modo a poderem facilmente adaptar-se a diversos fins

com o mínimo de configurações possíveis, todas passíveis de serem feitas pelo utilizador final ao

invés de técnicos especializados como grande parte das tecnologias mais completas actualmente no

mercado. A adição e remoção de controladores à rede sem-fios não deverá requerer nenhuma

configuração da rede já existente, facilitando assim a evolução de todo o sistema com o passar do

tempo.

As principais características que se pretendem atingir com estes módulos controladores podem

resumir-se nos seguintes 5 atributos:

Simplicidade (de configuração e de utilização)

Baixo custo que estará associado ao conceito de modularidade, para assim se construírem

soluções à medida permitindo a implementação de grandes redes de sensores e actuadores

personalizadas, no âmbito de habitações super-automatizadas

Flexibilidade para poderem ser adaptados a diversos fins, permitindo que uma rede domótica

evolua, ao trocar ou adquirir novos módulos sem ser necessário substituir os controladores por

inteiro, ou simplesmente alterando as definições abstratas de alto-nível

Fiabilidade, ao recorrer a tecnologias maduras, redundância e técnicas de tolerância a falhas.

Escalabilidade, de modo a permitir que um número elevado de controladores possam

cooperar numa mesma rede sem que esta sofra perdas consideráveis na sua capacidade de

transmitir todos os dados expeditamente, e que várias destas redes possam ser facilmente

agrupadas

O desafio principal consiste em manter um equilíbrio saudável entre as especificações mínimas

necessárias para satisfazer o objectivo de se obter um controlador modular, ao mesmo tempo que se

oferece a capacidade de escalar as funções que este poderá desempenhar. Este equilíbrio poderá

ser também traduzido como a relação entre o custo final do controlador e as suas capacidades de

efectuar diferentes papéis na rede em que se insere.

O controlador poderá então ser visto como um bloco básico na construção de uma habitação

super-automatizada, a que se associa um ou mais módulos de sensores e actuadores e que só

necessita de ser configurado para entrar em funcionamento, sem requerer uma ligação a um

computador para configurações ou programações específicas. A construção do mesmo pretende-se

simples, recorrendo sempre que possível a módulos de hardware já construídos para evitar a

construção de circuitos feitos à medida que atrasariam e aumentariam os custos associados à

prototipagem.

4

Em relação ao módulo RF, não existem requisitos rígidos em relação às suas características como a

distância máxima de comunicação, velocidade de transmissão mínima, métodos de acesso ao meio

ou técnicas de modulação. Mediante os módulos RF analisados, presentes no capítulo 2.2, optar-se-á

pelo que representa um melhor compromisso entre a sua escalabilidade (o potencial que a camada

de rede que está – ou poderá ser - implementada permite atingir, a velocidade de transmissão

máxima e o seu custo unitário) e a sua fiabilidade (em termos de hardware e de transmissão de

dados). A utilização planeada destes módulos RF é em redes domóticas em ambientes super-

automatizados, ou seja, espera-se que existam dezenas de sensores numa única divisão (a distância

máxima de comunicação não deverá ser inferior a cerca de 10 metros) e que serão utilizados por

controladores domóticos, ou seja, não se espera que sejam gerados grandes quantidades de dados

em cada nó da rede, uma vez que a frequência de utilização que este tipo de controladores têm é

reduzida, sendo raras as configurações em que cada controlador necessita de transmitir dados várias

vezes por segundo ou até por minuto.

1.4 Estrutura da dissertação

Após esta introdução apresenta-se o capítulo do Estado da Arte onde se analisam as várias

tecnologias domóticas mais expressivas no mercado com capacidade de operarem via

radiofrequência, as suas vantagens e desvantagens, o que no fundo definiu a base das

especificações para o controlador e respectivo protocolo que se propõe neste projecto. De seguida

apresenta-se uma análise dos módulos RF disponíveis existentes no mercado e melhor dotados para

este contexto de utilização.

Tendo em vista a interoperacionalidade entre diversas tecnologias sob o protocolo DomoBus, as

especificações do protocolo tornam-se de extrema importância para permitir no futuro a interligação

de todos os componentes. Assim o terceiro capítulo pretende introduzir o protocolo DomoBus, as

suas especificações e os seus componentes físicos, tudo aspectos que delinearão o desenvolvimento

do software e do hardware deste projecto.

O quarto capítulo concilia toda a informação anterior e apresenta ideias concretas sobre o modelo

a projectar, definindo em traços gerais a abordagem feita ao problema e justificando as opções

tomadas.

O quinto capítulo detalha a implementação da abordagem que foi seguida. Neste capítulo

descrevem-se os principais componentes do sistema e dentro de cada um destes são analisadas as

componentes de software e de hardware de modo a facilitar a exposição do tema.

5

2 Estado da arte

2.1 Tecnologias Domóticas

Nas últimas quatro décadas têm surgido inúmeros protocolos com o intuito de servirem como base

na implementação de tecnologias de automação nomeadamente no campo da domótica. O ritmo a

que a tecnologia tem avançado nestas últimas décadas justifica a contínuo aparecimento de novos

protocolos em detrimento dos mais antigos, dos quais alguns têm sido adoptados como padrões por

certas entidades governamentais ou legislativas com o intuito de adoptar especificações comuns que

possam uniformizar o mercado. Estes esforços acabam no entanto por se restringir geograficamente

isolando um conjunto de diferentes padrões incompatíveis entre si num mercado cada vez mais

global.

De seguida apresentar-se-á uma análise entre as tecnologias domóticas mais adoptadas que

comuniquem entre si sem-fios, onde se indicará de uma forma sucinta as principais características

que mais importância terão no âmbito da automatização em ambientes super-automatizados: o

número máximo de dispositivos que a arquitectura suporta, a segurança e fiabilidade que oferece ao

utilizador e os custos de implementação. Estas características serão analisadas através do método

de endereçamento adoptado, os tipos de dispositivos diferentes que existem para permitir construir as

respectivas redes, as camadas do modelo OSI (Open Systems Interconnection) implementadas, os

mecanismos de segurança existentes e o hardware utilizado. Algumas tecnologias não são exclusivas

e são apresentadas como padrões que são implementados por empresas no desenvolvimento de

dispositivos compatíveis, o que resulta numa diversidade de produtos com implementações

ligeiramente diferentes. Poderão existir diferenças pontuais em certos produtos nas características

aqui apresentadas.

Não serão aprofundadas tecnologias domóticas como o X10, C-Bus ou KNX por não se

adequarem à construção de redes de controladores para ambientes super-automatizados. No caso

do X10 (o protocolo de automação residencial mais antigo) os seus produtos na vertente sem-fios

resumem-se maioritariamente a comandos de controlo e dadas as limitações no esquema de

endereçamento não poderão existir mais do que 16 dispositivos sem-fios em comunicação directa (o

número de dispositivos possíveis por cada house code). A inexistência de mecanismos de segurança

e o facto de o sistema base necessário à implementação dos dispositivos sem-fios (que assenta

sobre linhas da rede de distribuição de energia eléctrica ou RDEE) ser pouco fiável e demasiado lento

faz com que esta não seja uma solução viável. Quanto ao C-Bus da empresa Clipsal (agora

pertencente à Schneider), um protocolo desenvolvido no início da década de 90, utiliza o meio de

transmissão por radiofrequência apenas como um complemento para as suas redes cabladas,

permitindo a existência de no máximo 30 dispositivos sem-fios em cada rede o que implicaria a

aquisição de dispositivos gateway e network bridges por cada grupo de 30 dispositivos, o que limita

seriamente a sua utilização em redes de grandes dimensões [2]. Por fim o protocolo KNX-RF, que

deriva do protocolo Europeu KNX oficializado no final da década de 90, teve uma adopção muito

baixa [8] principalmente devido às diferenças que foram introduzidas ao protocolo inicial, de modo a

6

melhor se adaptar aos seus transmissores sem-fios: o modo de endereçamento foi alterado do

quebrado a compatibilidade com os endereços padrão KNX, o que implicou a existência de outros

dispositivos que façam o mapeamento de endereços e retirou funcionalidades como o

endereçamento multicast. A criação de dispositivos sem-fios que transmitem e não recebem dados

(de modo a reduzir os custos de produção) eliminou a verificação de dados entregues, afectando a

fiabilidade das comunicações. A inexistência de quaisquer mecanismos de segurança tornam o

sistema altamente inseguro e os preços demasiado elevados não justificam nem o protocolo (que

partiu de uma especificação bastante completa, o KNX, e degenerou-a) nem o hardware utilizado

(microcontroladores de 16 bits MSP320 com transmissores TI CC1101 ou CC1150 na implementação

da Weinzierl). Devido a estes problemas é mais comum utilizar outras tecnologias sem-fios integradas

com o protocolo KNX (como o ZigBee, em produtos da empresa genOHM) do que o protocolo nativo,

o KNX-RF [6, 7].

2.1.1 CEBus

As principais vantagens do CEBus prendem-se com o facto de ser uma arquitectura aberta

(disponível ao público) que define protocolos pelos quais diversos dispositivos podem comunicar

sobre uma série de diferentes meios (incluindo por radiofrequência), implementando uma pilha de

comunicação que segue o modelo OSI sem considerar as camadas de transporte, sessão e

apresentação. Fora os controladores existem outros tipos de dispositivos nas redes CEBus: os

routers, que são utilizados para transmitir informações de controlo entre dois meios de transmissão

cablados diferentes, as data bridges que são utilizadas para transportar dados ou conteúdos

multimédia entre dois meios de transmissão cablados, e os brouters que são utilizados para

interligarem meios de transmissão cablados com meios de transmissão sem-fios. A utilização

combinada destes tipos de dispositivos permite a construção de uma topologia de rede em árvore

dinamicamente reconfigurável (onde a raiz da árvore geralmente assenta num meio de transmissão

cablado) de onde originam ligações a outros meios de transmissão através de routers e brouters.

Esta topologia assenta em dois níveis diferentes: uma topologia física onde se lida com as

interligações físicas permitidas entre nós e se removem ciclos (que no limite podem levar à

desactivação de certos routers ou brouters), e uma topologia lógica que determina como as sub-redes

e os seus nós se encontram interligados logicamente garantindo que só existe um único caminho

entre quaisquer dois nós da rede.

Os endereços dos dispositivos são constituídos por 32 bits que estão divididos entre o endereço

de sistema e o endereço do dispositivo, cada um com 16 bits. O primeiro permite definir dois tipos

diferentes de endereços: os de sistema da casa (que permitem agrupar dispositivos

independentemente do meio de transmissão) e os de zona da casa (que permitem agrupar

dispositivos que partilham o mesmo meio de transmissão). O segundo permite endereçar 57596

controladores distintos dadas as reservas existentes para endereços de grupos (3839), de sistema e

de broadcast. A funcionalidade de endereçar grupos de dispositivos é severamente afectada pelo

facto de os grupos virem configurados de fábrica, o que não permite ao utilizador ter controlo sobre a

forma como agrupa os dispositivos. As configurações relativas ao endereçamento podem ser feitas

7

de uma forma dinâmica, em que um dispositivo pergunta aos outros qual o endereço de sistema e

quais os endereços dos dispositivos disponíveis, ou de uma forma estática em que envolve

configurações manuais (nomeadamente através de botões embutidos no hardware). À parte do

endereçamento de baixo nível descrito, poderão existir diferentes métodos de endereçamento nas

camadas superiores que podem ter 32 ou 128 bits de modo a poderem ser directamente compatíveis

com protocolos como o IPv4 e IPv6.

A especificação prevê a utilização de verificação de integridade dos dados recorrendo a somas de

verificação nas camadas mais baixas, e a retransmissão automática só existe para alguns tipos de

endereçamento uma vez que o endereçamento em broadcast ou multicast ocorre sem verificações de

recepção. Em relação a mecanismos de segurança, a especificação não prevê a utilização de

autenticação dos dispositivos nem encriptação dos dados em nenhum dos meios de transmissão

sobre os quais pode operar. Alguns produtos encriptam os dados ao nível da aplicação, o que gera

diferentes implementações para diferentes produtos.

Quanto ao hardware utilizado, inicialmente apenas uma empresa (Intellon) obteve licenciamento

para a implementação dos protocolos e a produção de dispositivos. Esta empresa possuía o

monopólio do mercado e como resultado da falta de concorrência, aliado à complexidade excessiva

dos dispositivos (que geralmente recorriam a diversos circuitos integrados distribuídos por várias

placas de circuito impresso) os preços dos produtos com certificação CEBus foram sempre

demasiado elevados em comparação com outras tecnologias concorrentes. Não se sabem detalhes

específicos sobre o hardware utilizado.

O CEBus é um protocolo complexo e arrojado para a altura em surgiu (1984, classificado como um

standart em 1995) na medida em que pretendeu apresentar uma solução unificada para todos os

diferentes meios de transmissão e por isso acabou por se tornar numa tecnologia demasiado

complexa cuja vertente sem-fios não consegue nenhuma vantagem significativa sobre as restantes

concorrentes. A existência de uma linguagem de alto-nível própria (Common Application Language)

adiciona alguma flexibilidade em torno do desenvolvimento de produtos, mas a falta de mecanismos

de segurança e o facto de ser demasiado dispendioso aliado à escassez de produtos no mercado

condenaram esta tecnologia que nunca conseguiu ir muito além do seu país de origem, os Estados

Unidos da América.

2.1.2 LonWorks

A tecnologia LonWorks e o seu protocolo LonTalk (Lon de Local Operating Network) são

conhecidos por oferecerem a capacidade de implementar sistemas de controlo distribuídos flexíveis

que permitem uma comunicação sobre uma variedade de meios de transmissão. Cada dispositivo da

rede possui um endereço físico único de 48 bits denominado Neuron ID e um endereço lógico

composto por 3 níveis hierárquicos distintos: domínio (representado por 0, 1, 3 ou 6 Bytes), subnet

(representado por 1 Byte) e endereço do dispositivo (representado por 7 bits). Um dispositivo

geralmente pertence apenas a um domínio (a menos que seja um gateway, permitindo transmitir

dados entre domínios distintos) onde poderão existir 255 diferentes subnets que permitem agrupar

8

logicamente dispositivos que poderão utilizar diferentes meios de transmissão. Adicionalmente existe

ainda a possibilidade de identificar grupos de dispositivos (que poderão abranger várias subnets

dentro do mesmo domínio) onde cada dispositivo poderá no máximo pertencer a 15 grupos distintos.

As topologias de rede que podem ser implementadas variam com as necessidades específicas de

cada instalação e podem ser em barramento, em anel, em estrela ou combinações destas. As tramas

de dados poderão ser endereçadas para um dispositivo específico, para um grupo ou em broadcast

para uma subnet ou para um domínio. Para suportar estas topologias e modos de endereçamento

podem existir até 4 tipos de dispositivos auxiliares distintos: os routers que reencaminham pacotes

seletivamente entre subnets distintas, os repetidores que encaminham todos os dados dentro do

mesmo meio de comunicação (de modo a estender o alcance total), os gateways que permitem

interligar domínios diferentes e as bridges que encaminham todos os dados entre dois meios de

transmissão distintos pertencentes ao mesmo domínio.

O protocolo LonTalk não implementa encriptação de dados, mas no entanto, opcionalmente,

poderá autenticar o nó da rede do qual recebe dados. Este mecanismo recorre a uma chave de 48

bits (não relacionada com o Neuron ID) que não pode ser lida fora de cada nó e é programada de

fábrica, utilizada numa sequência de pergunta e resposta na qual ambos os nós têm conhecimento da

chave e confirmam-no através da manipulação matemática de um número aleatório de 64 bits. Este

mecanismo terá que ser configurado previamente o que implica ter que se saber à partida quais os

intervenientes em todas as comunicações possíveis de modo a proceder à configuração de cada nó

da rede. Qualquer novo par de dispositivos em comunicação implica uma reconfiguração do sistema

e a utilização de autenticação das mensagens mais do que duplica o tráfego na rede.

No hardware reside grande parte do sucesso que a Echelon Corporation, a empresa que

desenvolveu esta tecnologia, obteve com o LonWorks pois produziram (durante muito tempo em

regime de exclusividade aliados à Toshiba) um chip dedicado a implementar toda a pilha de

comunicação LonTalk, a disponibilizar as entradas e saídas físicas do controlador assim como a dar

suporte às aplicações feitas pelos utilizadores através de um sistema operativo próprio (que permite o

desenvolvimento de código numa linguagem que pretende tirar proveito das características

distribuídas do sistema, o Neuron C). Este chip denominado Neuron (ou Neuron Chip) é constituído

por 3 microprocessadores de 8 bits, cada um com a sua funcionalidade específica: o MAC Processor

é responsável pelas camadas física e de enlace, o Network Processor é responsável pelas camadas

de rede, transporte, sessão e apresentação e o Apllication Processor que é onde residem as

aplicações do utilizador assim como as entradas e saídas do sistema (no total 11 portos que podem

assumir funções de entrada ou saída). O seu funcionamento e estrutura não são inteiramente de

conhecimento público e existem versões diferentes, que, segundo a empresa apenas diferem entre si

na quantidade de memória. Actualmente não só existem várias empresas a produzirem o Neuron

Chip como existem outras soluções que implementam o protocolo LonTalk sem ser em hardware

dedicado para o efeito, sendo normalmente utilizados microprocessadores ARM de 32 bits para

implementar toda a pilha de comunicação. O Neuron Chip continua no entanto a ser o dispositivo

mais utilizado para construir as redes LonWorks.

9

A plataforma LonWorks é completa, robusta (pois não centraliza o controlo da rede), relativamente

segura e acima de tudo flexível. O protocolo de comunicação LonTalk implementa todas as camadas

do modelo OSI oferecendo um protocolo de comunicação comum para sensores e actuadores

poderem comunicar de uma forma descentralizada. O facto de terem produzido em regime de

exclusividade o seu hardware foi uma vantagem devido à uniformização que permitiu atingir. No

entanto, de modo a conseguir toda esta flexibilidade nos modos como pode operar exige

configurações complexas que tornam o sistema muito estático e pouco adaptado a sofrer alterações,

assim como exige hardware capaz de lidar com todas as funcionalidades oferecidas que acaba por se

reflectir não só no preço final do produto como no tamanho físico considerável que este assume. As

instalações e configurações terão que ser levadas a cabo por técnicos especializados pois é uma

tecnologia extremamente difícil de configurar (quando comparada com as restantes presentes neste

capítulo) e requer a utilização de software dedicado só disponível mediante o pagamento de

avultadas quantias. Os dispositivos são usualmente adquiridos já com o planeamento feito, que

deverá ser entregue à empresa de modo a poder fornecer os dispositivos juntamente com o software

respectivo para as tarefas especificadas. Devido a estas características acaba por ser utilizado mais

no mundo industrial e empresarial do que no doméstico, pois a complexidade e os elevados preços

afastam o comum consumidor que apenas pretende automatizar certos aspectos da sua casa.

2.1.3 ZigBee

O protocolo ZigBee, inicialmente chamado de HomeRF quando começou a ser planeado na

década de 1990, não se encontra directamente associado à domótica ou à automação em geral, nem

sequer a nenhuma empresa de microelectrónica. Esta tecnologia pretende estabelecer apenas um

protocolo de comunicação sem-fios sem estar associado à produção de hardware, estando apenas

associado à certificação (através da ZigBee Alliance) de produtos que utilizam o protocolo de modo a

tentar garantir melhores condições de interoperabilidade. O ZigBee corre sobre o protocolo IEEE

802.15.4 que define as primeiras duas camadas do modelo OSI (física e de enlace) e que permite a

construção de redes pessoais sem-fios com baixas velocidades de transmissão (LR-WPAN, ou low-

rate wireless personal area network). A forma como se encontra isolado dos fabricantes de hardware

têm as suas desvantagens no modo como a protocolo é ligeiramente adaptado por cada empresa ou

tipos de produtos que acaba por criar vários sub-protocolos para diferentes áreas (ZigBee Light Link,

ZigBee Smart Energy, etc.) que acabam por não ser compatíveis entre si. Existem ainda certos

produtos (como os da marca XBee) que quebram a compatibilidade por alterarem ligeiramente os

cabeçalhos utilizados pela especificação IEEE 802.15.4 tornando-os compatíveis apenas com um

número restrito de outras marcas e sobre certas condições (não se utilizarem certas funcionalidades)

[20]. O facto de existirem várias especificações (a original de 2004 agora considerada obsoleta, a de

2006 considerada como a mais utilizada, e a mais recente de 2007) que não são completamente

retrocompatíveis, e ainda o facto de a última especificação de 2007 se ter desdobrado em duas

diferentes, ZigBee Pro e ZigBee Residental (ou apenas ZigBee), que só são compatíveis sobre certas

condições (para não se quebrar a compatibilidade não se poderão utilizar certas funcionalidades de

ambos os lados) fazem com que nesta tecnologia seja por vezes impossível integrar diferentes

produtos numa mesma rede.

10

Segundo a especificação IEEE 802.15.4, na camada física cada dispositivo possui um identificador

de 64 bits onde contêm entre outros dados, o endereço do nó (16 bits) e o endereço da rede (PAN ou

Personal Area Network) a que pertence (14 bits). Nas comunicações entre nós pertencentes à

mesma rede são utilizados apenas os 16 bits do endereço como identificador. Nesta camada lida-se

com verificações de canais livres e a qualidade da ligação entre outras operações de baixo-nível. São

especificadas duas principais bandas de frequências onde o protocolo poderá operar: abaixo do

1GHz (com frequências específicas consoante o país, que permitem a existência de entre 1 e 10

canais distintos e velocidades de transmissão de 20Kb/s ou 40Kb/s) e na banda de 2.4GHz, a mais

utilizada, que permite a existência de 16 canais distintos e velocidades de transmissão de 250Kb/s. A

especificação introduzida em 2006 permite que em todas as bandas de frequências se possam atingir

velocidades de transmissão de 250Kb/s recorrendo a diferentes técnicas de modulação.

Na camada de enlace são utilizados os endereços de 16 bits previamente apresentados,

resultando num total de 65536 nós por rede, que poderão ser organizados em dois tipos de topologia:

ponto-a-ponto ou em estrela. Esta camada também é responsável por aceder à informação da rede

(PAN) disponibilizada por outros nós, associar e dissociar nós à rede existente, procurar por redes,

encriptação dos dados (recorrendo ao algoritmo AES de 128 bits), sincronização e alocação de

intervalos de tempo. Estes últimos derivam dos dois modos possíveis de uma rede PAN operar:

activado por sinalização (beacon enabled) ou não activado por sinalização (non-beacon enabled). No

primeiro o coordenador envia periodicamente sinalizações pela rede (network beacons) sob a forma

de tramas temporais (que incluem informações sobre a rede, como o seu identificador PAN) o que

permite que todos os nós obtenham um período temporal dentro dessa trama para comunicarem os

seus dados, permitindo definir latências ou larguras de banda fixas para cada nó da rede. No

segundo, o coordenador não emite sinalizações e por isso todos os nós poderão comunicar em

qualquer altura desde que o canal de comunicação não esteja em utilização.

São ainda especificados no protocolo IEEE 802.15.4 dois tipos de nós que diferem entre si na

complexidade da pilha do protocolo que implementam, o que se traduz em diferentes requisitos em

termos de hardware e por sua vez diferentes custos para o consumidor. Estes nós são denominados

por FFD (Full Function Devices) e RFD (Reduced Function Devices), sendo que os primeiros podem

realizar qualquer tarefa na rede (nomeadamente encaminhar pacotes e descobrir caminhos) e os

últimos apenas podem ser utilizados como nós terminais, integrados numa rede em estrela em que

apenas comunicam com um nó FFD. Cada rede (PAN) terá de ter obrigatoriamente um nó do tipo

FFD denominado coordenador (PAN coordinator) independentemente da topologia escolhida. Estes

são responsáveis por gerir a rede, como por exemplo endereçar novos nós, assim como informarem

os restantes nós de informações relativas à própria rede. Podem existir mais nós FFD na mesma

PAN, mas mais nenhum poderá ser o coordenador. A vantagem de utilizar mais nós FFD é a de

permitir topologias de rede mais complexas que uma em estrela, assim como podem ser usados para

conectar vários nós FFD actuando como pontes (PAN bridges) ao formarem uma rede PAN como um

conjunto de sub-redes com topologias em estrela, denominado aglomerado de estrelas (clustered

stars).

11

Quanto ao protocolo ZigBee propriamente dito, este adiciona as camadas de rede e aplicação

oferecendo a capacidade de implementar redes em malha (ponto-a-ponto com diversos saltos, ou

multi-hop), pela sua manutenção através de processos de auto-regeneração (self-healing) e auto-

organização (self-forming), por descobrir caminhos para as tramas de dados e por manter estes

caminhos actualizados em todos os diferentes nós encaminhadores aquando de modificações na

estrutura da rede. Ainda incluí mecanismos que permitem adicionar e remover nós a uma rede (que

interagem directamente com funções da camada abaixo, a de enlace) e que permitem associar

endereços a novos nós seguindo algoritmos distribuídos. A camada de aplicação, a última nesta

especificação, é a que interage directamente com as aplicações do utilizador. É responsável por

entregar os pacotes da camada de rede às aplicações e é composta por dois grandes subsistemas:

APS (Application Support Sub-layer) e ZDO (ZigBee Device Object). A primeira é responsável por

manter as tabelas de ligação (tabelas que mapeiam endereços e terminações (endpoints) de origem

para um ou mais endereços e terminações de destino), encaminhar as mensagens entre dispositivos

interligados, gerir o endereçamento de grupos, converter os identificadores de 64 bits em endereços

de 16 bits utilizados pela camada inferior e fragmentar e reconstruir pacotes. A segunda [ZDO] é

responsável pela gestão de mais alto nível do dispositivo, por inicializar a subcamada APS e a

camada de rede, definir o tipo de funcionamento do dispositivo (coordenador, encaminhador ou nó

terminal), inicializar e responder a pedidos de ligação (para dispositivos interligados) e gerir os

serviços de segurança como a partilha de palavras-chave entre dispositivos (embora tipicamente se

utilize mais uma palavra-chave única para toda a rede do que palavras-chave específicas para cada

ligação entre nós).

O facto de se partilharem as chaves secretas aliado ao facto de os pacotes de reconhecimento

(ACK) serem enviados sem encriptação e sem autenticação são as maiores desvantagens em termos

de segurança neste protocolo. Existe um conjunto de programas denominados KillerBee que

permitem contornar certos mecanismos de segurança em redes ZigBee, mesmo as que utilizam

encriptação [19]. Apesar disto continua a ser o protocolo mais seguro de todo os apresentados neste

capítulo. Deverá ser também um dos mais complexos relativamente à pilha de comunicação que

implementa.

O hardware necessário para implementar o protocolo ZigBee é difícil de especificar pois existem

várias empresas com implementações diferentes da pilha de comunicação assim como os requisitos

são diferentes para o tipo de nó em questão (coordenador, encaminhador ou nó terminal) e para o

tipo de utilização a dar (redes maiores precisam de dispositivos com mais memória). Existem ainda

diferentes especificações (as mais recentes denominam-se ZigBee e ZigBee Pro), diferentes tipos de

antenas e potências que resultam em inúmeras diferentes configurações para uma mesma gama de

produtos. De uma maneira geral pode-se dizer que o mais comum é a utilização de

microprocessadores de 16 bits ou 32 bits (apesar de existirem algumas implementações em

microprocessadores de 8 bits como o CC2530 da Texas Instruments). Em relação à memória

necessária, para a implementação do protocolo ZigBee da Texas Instruments (denominado Z-Stack)

são necessários no mínimo 5KiB de memória RAM (no máximo 7 KiB) e no mínimo 120 KiB de

12

memória Flash (no máximo 160KiB). Estes valores têm como limite a existência de até 20 dispositivos

directamente ligados a cada encaminhador assim como um máximo de 6 encaminhadores no total,

como especificado por defeito no Z-Stack, e não deverão ser vistos como absolutos, pois como já

referido, as necessidades de memória variam consoante a aplicação final [50].

O ZigBee é um protocolo adaptado à automação residencial e é bastante robusto devido ao

grande número de funcionalidades que são assegurados pela pilha de comunicação em si. Possui

excelentes mecanismos de segurança que permitem uma troca de dados segura, e devido aos seus

serviços de partilha de informações sobre o estado da rede (assegurados pelo nó coordenador)

consegue moldar as topologias que implementa conforme são adicionados ou retirados nós da rede

sem interacção por parte do utilizador. Juntamente com o facto de conseguir implementar uma rede

em malha em que cada dispositivo FFD adicionado permite expandir a rede, faz com que seja uma

boa solução para implementar redes complexas com um grande número de dispositivos. No entanto

as incompatibilidades existentes entre diferentes produtos e a enorme complexidade da pilha de

comunicação (que resulta em módulos RF com preços muito elevados) dificulta a sua introdução no

campo da domótica em especial no contexto das habitações super-automatizadas. Adicionalmente o

facto de centralizar o encaminhamento num único nó (o coordenador) prejudica a grande vantagem

relacionada com a robustez nas redes em malha, assim como o facto de não oferecer a capacidade

de se construírem diversas redes no mesmo espaço físico devido à existência de poucos canais

físicos distintos (16) que poderão ser utilizados por uma única PAN. A escalabilidade que poderá

atingir acaba por ser mais teórica do que prática dado que esta é muito interessante quando

analisada na especificação (um máximo de 65536 nós) mas na realidade os dispositivos que se

encontram no mercado são bem mais limitados do que os limites teóricos existentes (no máximo

atingem poucas centenas). Não deixa no entanto de ser o protocolo mais robusto dos analisados, o

que suporta o maior número de nós numa única rede e o único que pode garantir uma largura de

banda fixa a um dado nó.

2.1.4 Z-Wave

Z-wave é o nome dado a um protocolo e ao seu respectivo hardware originalmente concebido por

uma empresa Dinamarquesa chamada Zensys, fundada em 1999 com o intuito de criar uma solução

sem-fios para o mercado da automação residencial. Embora o protocolo seja proprietário e licenciado

apenas às empresas que fazem parte da Z-Wave Alliance, têm havido recentemente implementações

feitas pela comunidade para contornarem o facto de os pacotes de desenvolvimento serem

demasiado dispendiosos para o utilizador comum. Em 2010 surgiu o OpenZWave, um projecto de

código aberto comunitário feito por mais de 900 utilizadores espalhados por todo o mundo que

implementa uma biblioteca que torna possível desenvolver sofware que comunique directamente com

as redes Z-Wave [24]. Este projecto ainda continua activo e permite um maior envolvimento da

comunidade na produção das suas soluções feitas à medida sem terem que investir

significativamente em taxas honorárias (royalties) e kits de desenvolvimento.

A pilha de comunicação é fornecida pré-compilada de modo a que as empresas que produzem

produtos com certificação da Z-Wave Alliance só possam fazer alterações ao nível das aplicações. A

13

rede é suportada por três camadas: camada física, de rede e de aplicação. No nível físico este

protocolo opera na banda ISM (industrial, scientific and medical) abaixo do 1GHz (868.42MHz na

Europa, 908.42MHz nos Estados Unidos da América) com uma velocidade de transmissão original de

9.6 kb/s sendo que os novos dispositivos suportam até 40 kb/s, mantendo a possibilidade de utilizar a

velocidade de transmissão de 9.6 kbit/s por motivos de retrocompatibilidade. No nível de rede a

abordagem seguida para implementar a arquitectura da rede (cuja topologia é em malha) é

semelhante à usada pelo protocolo ZigBee, ou seja, de modo a implementar uma topologia complexa

tentando ao mesmo tempo manter os dispositivos com um baixo custo adoptou-se por diferentes tipos

de nós com funcionalidades distintas. Assim no protocolo Z-Wave existem dois tipos de nós

principais: nós controladores que podem ser estáticos ou móveis e nós escravos que podem ser ou

não encaminhadores.

Os endereços estão organizados por Home IDs e por Node IDs. Os primeiros são constituídos por

32 bits e os últimos são constituídos por 8 bits, estando 24 destes últimos endereços reservados para

comunicações internas e funções especiais, resultando num total de 232 endereços disponíveis por

Home ID para endereçar dispositivos. Nós de diferentes Home IDs não podem comunicar entre si a

menos que se instale um tipo especial de dispositivo denominado bridge controller que consiste

fundamentalmente em dois nós Z-Wave independentes, um em cada rede, contidos no mesmo

dispositivo onde a interacção entre ambas as redes é tratada num nível superior.

Os nós controladores são responsáveis pelo encaminhamento dos dados através de um protocolo

proprietário denominado Source Routing Address. O caminho que os dados terão que percorrer é

determinado na origem (nos nós controladores) e não é descoberto ao longo do caminho como

geralmente é feito numa topologia em malha. Do conjunto de nós controladores existe um primário,

geralmente estático, denominado SUC (Static Update Controller) que é o responsável por manter um

mapa da rede e que está sempre envolvido na adição e remoção de nós da rede assim como é o

único que poderá atribuir o seu Home ID a outros de modo a fazê-los pertencer à sua rede. É

responsável também por atribuir os endereços (ou Node ID, uma vez que têm conhecimento de toda

a rede e pode evitar a duplicação de endereços) e por descobrir e actualizar automaticamente novos

caminhos descobertos que distribuirá pelos restantes nós controladores. Esta descoberta e

distribuição de caminhos embora seja dinâmica, não é ideal para quando existem nós com

capacidades móveis (como por exemplo um controlo remoto) pelo que existem nós controladores

específicos para estes casos, denominados controladores móveis. No entanto, de modo a esta

actualização ser automática é necessária a existência de um SIS (SUC ID Server) que pode

automaticamente distribuir a topologia da rede para os restantes controladores, software que

geralmente necessita de correr num computador. Sem um SIS, sempre que é adicionado ou removido

um nó da rede, o utilizador terá que copiar manualmente os dados do SUC (ou controlador principal)

para os controladores secundários.

Os nós escravos dividem-se entre os que têm capacidades de encaminhar e os que simplesmente

actuam (os de mais baixo custo). As principais diferenças estão no facto de que um nó escravo

encaminhador tem conhecimento parcial da tabela de encaminhamento, fornecido por um nó

14

controlador, de modo a saber à partida os caminhos para os nós com quem sabe de antemão que vai

ter que comunicar. Estes nós podem enviar mensagens não solicitadas, ou seja, podem enviar

mensagens que não sejam resposta a uma mensagem recebida. Os nós escravos normais só podem

responder a mensagens, pois só podem responder utilizando o mesmo caminho que a mensagem

recebida tomou. Como exemplo de um nó escravo encaminhador temos um sensor de infravermelhos

que pode actuar em diversos outros nós (conhecidos à partida). Como exemplo de um nó escravo

normal, temos um interruptor.

Em relação a mecanismos de segurança, originalmente o protocolo incluía a hipótese de encriptar

os dados (em hardware) recorrendo ao algoritmo 3DES de 56 bits. Nas seguintes versões (200 e 300)

esta funcionalidade foi retirada o que gerou descontentamento por parte dos clientes e nas últimas

versões (400 e posteriores) está incluído (também em hardware) novamente um método de

encriptação, agora recorrendo ao algoritmo AES de 128 bits. Não existem mecanismos de

autenticação dos dispositivos. Existe um software denominado Z-Force que permite explorar falhas

no protocolo Z-Wave que foi utilizado para descobrir uma falha em certos produtos (nomeadamente

fechaduras) em que basta analisar o tráfego para obter o Home ID e o Node ID e consegue-se abrir a

porta sem alertar o sistema de controlo [23]. Esta falha descoberta não é no protocolo Z-Wave em si,

apenas em certos produtos.

Quanto ao hardware utilizado, dado que o sistema está contido num chip e é produzido apenas

por uma empresa, não existem diferentes implementações. As últimas versões utilizam um núcleo do

conhecido processador 8051 de 8 bits da Intel com 64KiB de memória OTP (One-time

programmable), 16 KiB de SRAM e 64KiB de NVRAM. As especificações variam ligeiramente

consoante o tipo de dispositivo, especificamente no que toca à memória externa, dados os diferentes

requisitos de memória para gerir as tabelas de encaminhamento

O protocolo Z-Wave é semelhante ao ZigBee em termos de funcionalidades gerais embora

consiga em geral um alcance superior (comparando com ZigBee na banda de 2.4GHz) devido à

diferença na frequência central da portadora a troco de uma menor velocidade de transmissão.

Necessita de mais configurações para ter uma rede operacional e não consegue implementar um

conjunto tão vasto de diferentes aplicações quanto o ZigBee o que se reflecte no hardware utilizado

que é significativamente inferior e requer menos memória por cada nó de rede, dada a menor

complexidade dos algoritmos inerentes ao protocolo. Em termos de escalabilidade esta é limitada

pelo facto de nenhuma gama de produtos analisada conseguir atingir o limite de 232 nós por rede

(por exemplo, os sistemas Vera aconselham no máximo entre 50 e 100 dispositivos [26]) e de o

protocolo estar limitado a um máximo de 4 saltos até atingir o destino. No entanto, na sua última

versão, não deixa de ser um protocolo sem-fios robusto e com uma representação significativa de

produtos no mercado.

2.1.5 Insteon

As grandes vantagens associadas a esta tecnologia são a simplicidade de configuração, o facto de

poder utilizar dois meios de comunicação em simultâneo (RDEE e RF), a compatibilidade com

15

instalações X10 já existentes e o facto de não existirem diferentes tipos de nós, sendo que cada um

destes age como um controlador e um repetidor, reenviando todas as mensagens que recebe. No

meio de transmissão via RDEE esta tecnologia pode coexistir com o protocolo X10, sendo capaz de

enviar e receber mensagens, embora estas não sejam repetidas (propagadas) tal como acontece

com mensagens nativas ao protocolo Insteon. Isto oferece a possibilidade de poder ser integrado com

instalações existentes X10 o que é visto como a grande vantagem desta tecnologia. Esta integração é

no entanto uma funcionalidade extra pois o protocolo não é compatível, apenas o hardware.

As tramas de dados trocadas num sistema Insteon são repetidas por cada nó até que seja atingido

o número máximo de saltos (4) de modo a evitar que as tramas se propaguem infinitamente. Este

método de comunicação é comum aos dois meios (RDEE e RF) e é feito em broadcast em que todos

os nós lêem todas as mensagens e as repetem o que é extremamente ineficaz na utilização dos

canais de comunicação e vinga apenas pela sua simplicidade e inexistência de configurações

relativas aos endereços dos dispositivos na rede. Como as mensagens são transportadas por meios

diferentes com diferentes velocidades de transmissão (RF é mais rápido que a transmissão pela

RDEE) terá que existir uma sincronia comum a ambos de modo a permitir a retransmissão síncrona

de tramas em ambos os meios, simplificando mecanismos de detecção de colisões e detecção de

duplicados. Esta sincronia é obtida a partir da frequência do sinal da RDEE que age como um relógio

global, em que são criadas entidades lógicas denominadas intervalos de tempo baseadas nas

passagens por zero da tensão sinusoidal.

A topologia é apresentada pela empresa como em malha dupla (dual mesh) mas na realidade

dado que não existe necessidade de descobrir caminhos nem nenhum outro tipo de processamento

no encaminhamento de tramas de dados, senão o de descartar tramas cujo número máximo de saltos

tenha sido excedido, na verdade pode ser visto como uma topologia em barramento, em que os

dados são repetidos ao longo do caminho até de dissiparem naturalmente devido ao tempo de vida

limitado pelo número de saltos. Não existe bem o conceito de rede, no sentido de uma unidade lógica

que agrupa todos os dispositivos numa dada área, dado que o endereçamento é fixo e a

comunicação entre diferentes nós é feita através de associações. De modo a oferecer mensagens em

broadcast ao nível da camada de rede para dispositivos do mesmo tipo e o agrupamento lógico de

nós, existe um campo nas tramas de dados que identifica o que se encontra nos 3 Bytes do

endereço: um identificador único (para comunicações ponto-a-ponto), um grupo (número inteiro que

utiliza apenas os 8 bits menos significativos do endereço) ou um trio composto pelo tipo de

dispositivo, subtipo e versão do firmware instalado para o envio de mensagens broadcast.

A instalação de novos dispositivos (criação de ligações entre nós) pode ser feita através de botões

embutidos no hardware, denominado Plug-n-Tap, ou de modo a permitir maior flexibilidade (como

adicionar eventos condicionais ou calendarizações) pode ser feita através de um computador ou de

um controlador dedicado. Todos os dispositivos possuem um endereço de 24 bits associado de

fábrica que não poderá ser alterado. Este número é considerado único e para garantir o correcto

funcionamento do sistema não poderão existir dois iguais, mesmo não estando interligados entre si.

16

Não existe encriptação por defeito dado que esta não foi contemplada na construção da pilha de

rede. No entanto certos produtos no mercado (como fechaduras ou componentes de alarmes)

encriptam dados ao nível da aplicação, resultado apenas no conteúdo de dados da trama encriptado

assim como resulta em diferentes implementações para cada produto, o que torna uma análise mais

detalhada difícil de elaborar. O facto de as ligações entre nós para serem configuradas necessitarem

de acesso físico aos dispositivos (para ter acesso à interface que consiste em botões embutidos no

hardware) e o facto de existir um grande número de possibilidades para os 24 bits do endereço único

que só vêm escritos no próprio produto são apresentados como mecanismos de segurança pela

empresa [27], no entanto estão longe de ser algo mais do que um simples bloqueio a acções

indesejadas por terceiros. Os nós conseguem ver as tramas trocadas uns pelos outros dado que não

existe nada que identifique cada uma das redes (ou dispositivos pertencentes a cada habitação) nem

que codifique os dados, de forma a que para cada uma das redes os dados da rede oposta não

sejam válidos. Isto faz com que os nós possam estar a repetir mensagens da residência vizinha. Os

mecanismos de segurança deste protocolo são por isso considerados inexistentes.

Os requisitos mínimos em questões de memória para o núcleo principal da pilha de comunicação

Insteon são 80 Bytes de memória RAM e 3 KiB de memória ROM. Um dispositivo típico, como um

interruptor, utiliza 256 Bytes de RAM, 256 Bytes de EEPROM e 7 KiB de memória Flash. Os

dispositivos da primeira geração utilizam microcontroladores PIC, nomeadamente o 16F648A que é

um microcontrolador de 8 bits com as capacidades de memória apresentadas anteriormente. Dada a

natureza proprietária da tecnologia é difícil saber se actualmente ainda utilizam o mesmo hardware.

O Insteon é uma tecnologia que vinga pela sua fácil configuração e pela integração nativa com

redes X10 já existentes numa habitação. No entanto a simplicidade oferecida acaba por forçar uma

utilização muito ineficaz do canal de comunicação, que juntamente com o facto de se sincronizar com

a transmissão de dados pela RDEE forçando uma comunicação demasiado lenta limita seriamente a

escalabilidade para redes de grandes dimensões. Possui mecanismos de segurança muito fracos que

se prendem com o bom senso e a boa utilização por parte dos utilizadores. O facto de a sua

arquitectura ser baseada em interligações entre nós oferece alguma fiabilidade ao sistema na medida

em que não necessita de centralizar o controlo num único dispositivo, mas ao mesmo tempo limita as

funcionalidades que se podem obter e a complexidade destas.

2.2 Módulos RF

De seguida listar-se-ão todos os módulos RF encontrados no mercado prontos a utilizar por um

microcontrolador de modo a encontrar o que melhor se adeque a este projecto e aos objectivos

definidos. As principais características que se tiveram em conta para elaborar esta lista foram:

Comunicação com o microcontrolador por I2C ou SPI. Foi dada preferência à comunicação

por SPI pela sua facilidade de implementação, maior velocidade de transmissão e, em geral,

menor sobrecarga do microcontrolador quando existe suporte em hardware para o mesmo

17

Que se encontrem no mercado como módulos e não como um chip isolado de modo a facilitar

o desenvolvimento e teste de protótipos, e por ser mais fácil adquirir módulos RF em

pequenas quantidades

Cujas características, nomeadamente distância máxima de transmissão, consumos

energéticos, camada de rede implementada (ou que seja possível implementar) e preço

unitário se apliquem à sua função de comunicar em espaços interiores com no mínimo um

alcance de algumas dezenas de metros, que permitam a criação de redes que suportem mais

de uma centena de dispositivos com um custo acessível, e que permita criar várias destas

redes num mesmo espaço sem que estas interfiram

Foram apresentados preços dos produtos assim como as lojas onde foram estes foram

encontrados de modo a poder oferecer um método simples (embora pouco preciso) de comparar o

custo que as diferentes tecnologias têm. Os preços apresentados são para serem considerados como

um intervalo, daí terem-se apresentado vários produtos para cada tecnologia e ter sido calculada uma

média aritmética apenas como referência.

No Anexo A3 encontra-se uma tabela que resume as principais características técnicas das

tecnologias analisadas para facilitar uma comparação entre todas elas. De seguida apresentar-se-ão

resumidamente as principais características de cada tecnologia sem entrar em grande detalhe sobre

as especificações técnicas de cada uma.

2.2.1 Wi-Fi (802.11)

Existe actualmente um grande número de módulos RF prontos a inserir num circuito com um

microcontrolador o que torna difícil listá-los a todos. No entanto embora a escolha de módulos Wi-Fi

seja abundante, os chips utilizados recaem usualmente nas mesmas empresas principais: Microchip,

Texas Instruments, Wiznet e Broadcom que depois são encapsulados em circuitos e vendidos como

módulos a partir de um número variado de empresas. Na Tabela 2.1 é possível ver os chips

actualmente mais presentes no mercado sob a forma de módulos RF.

Marca Chip IEE 802.11 Vi Consumos Interface Interr. Versão

IP Segurança

Microchip (Roving)

RN131, RN171

b/g 3.3 4uA sleep 39mA Rx

210/120 mA Tx

UART / SPI

não V4 WPA2-PSK

AES128

Microchip MRF24W b/g 3.3 0.1mA sleep 156mA Rx 240mA Tx

UART / SPI

não V4 WPA2-PSK

AES128

Texas Instruments

CC3000 b/g 3.3 0.5uA sleep

92mA Rx 190mA Tx

SPI sim V4 WPA2-PSK

AES128

Wiznet WizFI210 b/g/n 3.3 34uA sleep 124mA RX 126 mA TX

UART / SPI / I2C

sim V4 WPA2-PSK

AES128

Broadcom WICED b/g/n 5 n.d. UART /

SPI / I2C sim V4

WPA2-PSK AES128

Bluegiga WF111, WF121

b/g/n 3.3

110 uA sleep

240 mA RX 248 mA TX

UART / SPI / I2C

sim V4 WPA2-PSK

AES128

Tabela 2.1 - Listagem de chips Wi-Fi predominantes no mercado actualmente

18

Na Tabela A2.1 em anexo são listadas alguns módulos Wi-Fi organizados por chip e o seu preço

que em média ronda os 30€ por unidade. As características eram demasiadas para estar a

representar numa tabela e acabava por não se justificar pois são todas muito equivalentes mudando

apenas consideravelmente nos consumos e velocidades de transmissão que por sua vez variam

conforme com os protocolos implementados: 802.11 a,b,g ou n.

Optar por uma ligação 802.11 Wi-Fi para implementar este projecto vai contra um dos objectivos

base que é o de manter o sistema com um baixo custo. Para se obter um baixo custo terá que se

recorrer apenas aos recursos necessários, e adicionar como canal de comunicação a um simples

controlador um módulo RF constituído por um microprocessador de 32 bits e algumas dezenas de

MiB de memória não é razoável. Apesar de obter as velocidades de transmissão mais elevadas de

todos os módulos RF listados, segurança (WPA2) e sete camadas do modelo OSI implementadas em

hardware, não se pode ignorar que é praticamente impossível um simples microcontrolador de 8 bits

ou 16 bits aproveitar todas estas características. É uma solução muito boa para sistemas num nível

mais alto que necessitem de elevadas velocidades de transmissão e de uma pilha de rede

inteiramente suportada em hardware, mas no que toca à construção de redes distribuídas feitas com

pequenos sistemas embebidos em que cada Byte tem um peso substancial na sua limitada

quantidade de memória, possui demasiados cabeçalhos e protocolos complexos de mais (IP, DHCP,

TCP, etc.) para ter um pequeno impacto. O mesmo se aplica à energia utilizada, demasiada quando

se pretende ter um grande número de nós a funcionar continuamente. O facto de todos os

dispositivos terem de estar em comunicação directa com o nó encaminhador é também uma

desvantagem dado que se torna mais difícil de expandir a rede e assim construir uma rede facilmente

escalável.

2.2.2 Bluetooth

O Bluetooth não foi inicialmente desenvolvido a pensar em redes de grandes dimensões nem em

topologias de rede distribuídas. Possui uma arquitectura mestre-escravo e permite que um máximo

de 7 escravos falem com 1 mestre (alguns dispositivos podem suportar menos escravos)

implementado assim uma topologia em estrela (denominada piconet). Escravos não comunicam entre

si, terá que existir sempre um mestre que pode, no entanto, ir trocando entre os dispositivos. Os

dados trocados entre mestre e escravo são encriptados nas camadas inferiores o que juntamente

com o facto de ter um método de transmissão FHSS (frequency-hopping spread spectrum) que

permite o mascaramento das comunicações através de rápidas variações na frequência tornam o

Bluetooth uma tecnologia considerada segura. Para escalar as redes podem-se juntar várias piconets

e fazer com que um escravo de uma piconet seja o mestre de outra obtendo uma topologia

denominada scatternet. O problema está na degradação da performance com a adição de novas

piconets pois requer sincronização e a partilha da largura de banda para a transmissão de dados

entre piconets. Foi principalmente para lidar com estas limitações que foi originalmente desenvolvida

a especificação IEEE 802.15.4 sobre a qual foi desenvolvido o ZigBee.

19

2.2.2.1 Bluetooth Low Energy

Enquanto que o protocolo Bluetooth continua a evoluir no caminho de ligações cada vez mais

rápidas para conseguir lidar com o aumento das capacidades de processamento dos dispositivos que

o utilizam, geralmente dispositivos de computação pessoal móvel em que a utilização se prende

maioritariamente com transferências de grandes quantidades de dados entre um número muito

limitado de dispositivos, também aumentam os consumos por parte dos novos chips produzidos. Para

combater esta tendência surgiu em 2011 o protocolo Bluetooth Low Energy a partir da especificação

Bluetooth 4.0 que se declara como um protocolo de ultra-baixo consumo energético desenvolvido a

pensar em dispositivos embebidos que operam a bateria. Neste protocolo as trocas de informação

são mais curtas assim como os períodos em que o rádio se encontra em comunicação. Algumas

características são reduzidas de modo a economizar energia como a velocidade de transmissão ou a

potência do pré-amplificador o que resulta em sinais RF com menor alcance. As principais

características como os mecanismos de segurança que recorrem a modos de emparelhamento, o tipo

de autenticação, existência de encriptação assim como a banda de frequências em que opera

mantiveram-se inalteradas. A maior diferença, excluindo o consumo energético, prende-se com o

número não definido de escravos que poderão estar conectados a um mestre que depende da

implementação em hardware específica, esta que por sua vez depende da memória e capacidade de

processamento disponível. Outras alterações importantes encontram-se no sistema de modulação e

numa nova funcionalidade em que um nó escravo pode sinalizar quando têm algo a transmitir para

outros dispositivos que se encontrem em modo de procura (scanning). Resumiram-se as principais

diferenças entre estes dois protocolos na Tabela 2.2.

Característica Bluetooth Bluetooth LE

Alcance máximo < 100 m < 50 m

Velocidade de transmissão 1-3 Mb/s 1 Mb/s

Velocidade real para a camada de aplicação

0.7 a 2.1 Mb/s 0.26 Mb/s

Número máximo de escravos 7 Dependente da implementação

Segurança implementada 56/128 bits

(dependente da versão) 128-bit AES

Latência (de um estado desconectado)

Tipicamente 100 ms 6 ms

Tempo total para envio de dados 100 ms 3 ms

Topologia de rede Scatternet Star-bus

Consumo energético (de referência, sem unidade)

1 0.01 a 0.5

Corrente máxima <30 mA <20 mA Tabela 2.2 – Comparação do protocolo Bluetooth com o protocolo Bluetooth LE

Ambos os protocolos implementam as mesmas camadas e ambos assentam sobre a

especificação IEEE 802.15 que especifica a camada física e de enlace. Na Figura 2.1 pode ver-se a

comparação entre as camadas de rede implementadas pela especificação 802.11 (ou Wi-Fi)

previamente apresentada (que são as do modelo OSI padrão) com as camadas implementadas pela

especificação 802.15 onde é fácil perceber a diferença na complexidade de ambas.

20

Figura 2.1 – Camadas de rede da especificação 802.15 em comparação com o modelo OSI

Comparando os dois protocolos Bluetooth chega-se à conclusão que o Bluetooth LE é mais

indicado para os objectivos pretendidos nomeadamente devido ao número máximo de escravos com

que um nó mestre poderá comunicar. Os consumos energéticos assim como os mecanismos de

segurança também são consideravelmente melhores, a troco de uma menor velocidade de

transmissão e um menor alcance máximo. Por estes motivos não se justificou fazer uma pesquisa de

mercado por módulos que não implementassem a versão Low Energy do protocolo Bluetooth,

também conhecida por BLE ou Bluetooth Smart.

Todos os módulos RF analisados utilizam chips de apenas duas empresas: a Texas Instruments e

a Nordic Semiconductor. A primeira é a mais comum e existem inúmeras empresas a construírem

módulos RF certificados que utilizam os chips CC254x e CC256x que são constituídos por um

microprocessador de 8 bits (8KiB de SRAM e 128 ou 256KiB de memória Flash) com a conhecida

arquitectura 8051 da Intel, o respectivo radio compatível com Bluetooth LE e um acelerador em

hardware para o algoritmo de encriptação AES. O segundo [Nordic Semiconductor] é conhecido pelos

chips nRF8001 e nRF51822 em que o primeiro apenas implementa o rádio BLE com as respectivas

camadas físicas e de enlace necessitando obrigatoriamente de um microcontrolador para operar

como controlador de aplicações, e está restrito ao modo de funcionamento como escravo. O segundo

é um SoC que incluí um microcontrolador com memória reservada para poder ser programado pelo

utilizador para simples aplicações BLE. Este tem por base um processador ARM Cortex M0 de 32 bits

com 256KiB de memória Flash e 16KiB de RAM e não possui funcionalidades suficientes para ser

utilizado como um controlador domótico, não existindo por isso nenhum benefício directo na sua

utilização pelo facto de ser programável. Embora na especificação do BLE não se defina à partida o

número de escravos por limitações da arquitectura, na prática devido à alocação de recursos

necessária os chips definem essas limitações (ver Tabela 2.3) que são de todo insuficientes para se

implementar uma rede de grandes dimensões mesmo recorrendo a métodos como nós com dois

módulos RF ou nós que estejam constantemente em modo de procura a trocar de dispositivos

emparelhados.

Chip Máximo número de escravos

CC2540 3

CC2560 6

nRF51822 8

nRF8001 (apenas pode assumir papel de escravo)

Tabela 2.3 – Limitações na conectividade dos diferentes chips

21

Na Tabela A2.3 em anexo encontram-se listados alguns dos produtos disponibilizados pelas

principais empresas no mercado que utilizam os chips previamente apresentados. A média dos

preços destes produtos é de aproximadamente 14€.

Adoptar por um módulo RF Bluetooth LE é vantajoso na medida em que implementa em hardware

as principais características que se requerem de um protocolo de alto nível (camada de rede e

mecanismos de segurança) mantendo um baixo consumo energético. No entanto as fracas

possibilidades que oferece na construção de redes de grandes dimensões devido ao número

reduzido de dispositivos com que pode interagir, e não implementar uma camada de rede multi-hop,

assim como o reduzido alcance total de cada rádio aliado a um preço elevado acabam por de certo

modo condenar a sua utilização em ambientes super-automatizados.

2.2.3 ZigBee

O ZigBee apresenta-se à partida como um dos melhores protocolos para implementar uma rede

de sensores e actuadores distribuída graças às topologias de rede que permite implementar,

teoricamente com limites muito flexíveis, e a todas as tarefas relativas à gestão dessa própria rede

que efectua nativamente. Tal como o Bluetooth e o Wi-Fi 802.11 são componentes com um custo

elevado pois possuem microprocessadores relativamente potentes e muitos KiB de memória para

permitir a implementação do protocolo e alocar todos os dados necessários. É difícil entrar em

grandes detalhes sobre uma arquitectura específica pois existem inúmeras aplicações por diferentes

empresas que cobrem diferentes especificações ZigBee, implementam diferentes camadas, possuem

ou não mecanismos de segurança, permitem ser utilizados em diferentes modos (FFD ou RFD) e

utilizam variado hardware. Grande parte dos módulos RF analisados utilizam chips da Texas

Instruments (CC253x), Freescale (MC131x e MC132x) ou Atmel (AT86RF23x) mas não se restringem

apenas a estes, existindo também soluções que integram microcontroladores que poderão ser

parcialmente configurados pelo utilizador final. Os módulos mais comuns são os da marca XBee que

recorrem a chips Freescale, e se podem obter por valores entre 20 e 30€ dos quais muitos modelos

permitem ao utilizador final programar algumas funcionalidades básicas directamente no módulo RF.

Actualmente existem inúmeras implementações não oficiais oriundas da China que conseguem

reduzir o preço para cerca de um terço (ver Tabela A2.2 em anexo) e que geralmente recorrem ao

chip CC2530. Todos os módulos RF analisados operam na gama de frequência de 2.4GHz que é a

tipicamente utilizada na área da domótica.

Estes recursos extra necessários trazem benefícios no modo como já estão implementadas várias

camadas do modelo OSI que permitem gerir a troca de dados (tal como o endereçamento e as

retransmissões) assim como o encaminhamento e gestão da rede, onde podem ainda estar

implementados mecanismos de segurança nas camadas superiores referentes à especificação

ZigBee propriamente dita (ver Figura 2.2). A camada de enlace é encriptada recorrendo ao algoritmo

AES-128 e existe uma chave pública partilhada que permite a cada nó identificar de e para onde vão

os pacotes de dados encriptados, conseguindo assim avaliar se estes são fidedignos ou não.

22

Figura 2.2 – Comparação das camadas de rede na especificação ZigBee com as do padrão do modelo OSI

Ao contrário das soluções que implementam Bluetooth e Wi-Fi 802.11, a escalabilidade fica com

nota positiva pois é possível criar topologias não só em estrela como em árvore ou em malha,

dependendo do tipo de dispositivos (FFD ou RFD) e do chip utilizado. A topologia é dinâmica e gerida

totalmente pelos seus nós e pode até ser alterada automaticamente conforme as alterações físicas

que ocorrerem na rede. Estas capacidades de auto-adaptação aumentam consideravelmente a

robustez da rede, no entanto é preciso ter em conta que os dispositivos que permitem este tipo de

funcionalidades requerem mais memória e acabam por ser limitados pela sua arquitectura. Dos chips

apresentados, todos suportam os modos de operação FFD e RFD, e o que consegue maior

flexibilidade é o CC2530 cujas características já foram previamente apresentadas no capítulo 2.1.3.

Assim a escalabilidade é significativamente melhor que os protocolos anteriormente apresentados,

mas dado o ZigBee ser um protocolo também de alto nível e necessitar de bastantes recursos para

implementar todas as funcionalidades e serviços que oferece, esta escalabilidade não permite atingir

facilmente a dimensão das redes existentes nas habitações super-automatizadas enquanto mantêm

os controladores com um preço acessível. O elevado custo de cada um obriga a uma racionalização

dos nós da rede acabando por forçar uma certa centralização dos sensores e actuadores que não se

distribuirão tão livremente pela habitação quanto seriam se o custo fosse mais reduzido.

Fora os problemas de compatibilidade entre diversos produtos (apresentados anteriormente

também no capítulo 2.1.3), a elevada complexidade do protocolo faz com que seja comum que as

topologias que são permitidas dependam do dispositivo adquirido [21], existindo no mercado

hardware que não é capaz de implementar uma verdadeira rede em malha escalável por falta de

capacidade (embora faça parte da especificação). A escolha por um módulo RF ZigBee terá portanto

que ser feita tendo em conta estes factores não facilitando assim a troca de módulos RF ou a

conjugação de diferentes módulos de diferentes modelos para características técnicas distintas (como

por exemplo distâncias máximas de comunicação ou topologias mistas). O ZigBee é assim visto

como um protocolo demasiado complexo que se desdobrou em inúmeras sub-implementações e que

na prática pode acabar por não fornecer a escalabilidade necessária se a escolha pelo módulo RF

não for cuidadosamente feita. Não deixa de ser um protocolo bastante completo e robusto muito útil

para redes com algumas dezenas ou centenas de dispositivos, partindo do pressuposto que se

adquirem produtos compatíveis. O seu elevado preço é visto como a principal desvantagem.

2.2.4 nRF24L01+

Da tabela comparativa apresentada no Anexo A3 o módulo nRF24L01+ é o que apresenta um

melhor balanço entre o seu consumo e as velocidades de transmissão que atinge. Como

23

desvantagem têm o facto de funcionar em bandas de frequências muito altas (na banda dos 2.4GHz

à semelhança dos protocolos apresentados até agora) o que é desfavorável face a outros módulos

RF apresentados (como por exemplo RFM12B ou RFM22B) dado que o sinal é mais atenuado ao

entrar em contacto com paredes e outros materiais de construção assim como é uma banda de

frequências que pode atingir elevados graus de ocupação em certos locais. Por outro lado é uma

banda de uso legal e desprovido de licença em todo o mundo pelo que não existem restrições

geográficas como no caso dos módulos RF que funcionam em frequências abaixo de um GHz. Para

de certa forma contornar este problema da atenuação excessiva existem no mercado diferentes

módulos munidos de pré-amplificadores externos mais potentes, amplificadores de baixo ruído e

antenas SMA (Subminiature version A) que permitem atingir maiores distâncias que podem ser na

melhor das hipóteses triplicadas quando comparadas com o modelo mais comum, com antena plana.

Estes chips da Nordic Semiconductor possuem embutidos no seu firmware uma tecnologia

opcional denominada Enhanced Shockburst que permite gerir automaticamente as tramas e as suas

retransmissões assim como verifica por erros na transmissão. Isto significa que se consegue obter

uma camada de nível 2 no modelo OSI totalmente gerida por hardware no módulo RF.

Adicionalmente existe um porto de interrupção que permite notificar o microcontrolador quando ocorre

uma mudança no estado do módulo RF o que juntamente com a utilização da tecnologia Enhanced

Shockburst permite libertar o microcontrolador de diversas tarefas relativas à gestão do módulo RF.

A grande vantagem desde módulo RF está no seu valor, pois de todos os módulos analisados este

encontra-se a meio caminho entre um rádio com todas as camadas de rede OSI implementadas

(802.11 Wi-Fi) e um rádio cuja gestão caberá toda ao microcontrolador (RFM12B ou RFM22B) e em

termos de preço é o mais barato de todos podendo-se facilmente comprar à unidade por menos de 1€

cada, na versão com antena plana, e menos de 5€ cada na versão com antena SMA (ver Figura 4.2).

Uma vez que implementa apenas o básico indispensável numa rede (primeiras duas camadas, física

e de enlace) oferece uma grande flexibilidade no desenvolvimento de novas camadas sobre as já

implementadas, embora estas tenham que ficar a cargo do microcontrolador. Na Tabela A2.4 em

anexo encontram-se listados alguns produtos encontrados no mercado. Os módulos RF que adoptam

este chip são geralmente feitos pelas empresas que os vendem (como o caso da SeedStudio ou da

Olimex) ou por empresas sedeadas na China que invadiram o mercado com módulos a preços muito

abaixo dos praticados pelas restantes empresas.

Mesmo considerando as velocidades de transmissão elevadas, baixo consumo energético e o seu

preço final estes módulos RF não são ideais pelo facto de não implementarem quaisquer

mecanismos de segurança. A camada de rede fica também por desenvolver, encarregue ao

microcontrolador, o que poderá ser visto como uma vantagem ou uma desvantagem conforme a

utilização final pretendida e as alternativas existentes.

2.2.5 nRF905

É o primeiro dos módulos RF apresentados que opera numa banda de frequência abaixo do GHz,

nas bandas reservadas ISM, utilizando as frequências de 433, 868 ou 915MHz conforme a zona do

24

globo em que se aplique dado as normas em vigor pela União Internacional de Telecomunicações. À

semelhança do módulo RF anterior também possui as duas primeiras camadas de rede do modelo

OSI implementadas utilizando a tecnologia Shockburst que se encarrega da gestão das tramas,

verificação de erros e retransmissões. Só é disponibilizado no formato com antena externa pelo que

apresenta algumas limitações quanto à sua miniaturização, ao mesmo tempo que por esse motivo

cobre distâncias superiores às tecnologias previamente apresentadas e será menos afectado por

obstáculos nomeadamente as paredes das habitações.

A velocidade de transmissão obtida é a menor de todos os módulos RF analisados, o que pode

acabar por limitar a escalabilidade numa rede com uma topologia em que os dados tenham que

atravessar vários nós da rede até chegarem ao seu destino (devido à latência gerada). No entanto

consegue cobrir distâncias maiores pelo que a implementação de redes com topologia em estrela não

se torna tão limitativa quando comparada com os módulos a operarem na banda dos 2.4GHz.

Na Tabela A2.5 em anexo encontram-se listados alguns modelos e os seus preços. O preço médio

por unidade é de cerca de 7€, e à semelhança do módulo RF anterior também não dispõe de

quaisquer mecanismos de segurança ou camada de rede implementados nativamente.

2.2.6 RFM12B

Originalmente desenvolvido pela empresa Hope RF e actualmente disponível sob várias marcas,

como a Alpha RF, é um transmissor sem fios que opera nas bandas de frequência ISM de 433, 868 e

915MHz. Cada canal de comunicação na banda de frequência central de 868MHz (disponível na

Europa) ocupa uma largura de banda de 5KHz o que permite um total de 3808 canais de

comunicação distintos. Em comparação com os restantes módulos RF apresentados até agora este é

de longe o mais básico dado que apenas é constituído pelo rádio e o hardware mínimo necessário o

que significa que o microcontrolador terá que ser responsável por implementar todas as

funcionalidades necessárias e lidar com as respectivas temporizações. Todas as camadas do modelo

OSI necessárias terão por isso que ser implementadas em software no microcontrolador.

Adopta as mesmas vantagens e desvantagens do módulo anterior referentes às bandas de

frequências em que opera, à baixa velocidade de transmissão e mecanismos segurança.

2.2.7 RFM22B

É o modelo que sucede o apresentado anteriormente (RFM12B). É baseado nos chips RF da

Silicon Labs Si4431 e Si4432 e possui um número considerável de novas funcionalidades, de onde se

destacam:

Camada de enlace parcialmente implementada, nomeadamente no que toca ao acesso

partilhado ao meio, denominada EzyMac, que permite adicionar automaticamente os

preâmbulos e Bytes de sincronização e ajustar automaticamente o tamanho da trama

Memórias (buffer) 32 vezes maiores que as do modelo anterior (passaram de 16 bits para 64

Bytes)

25

Maior potência de transmissão e maior sensibilidade na recepção, os melhores parâmetros

de todos os módulos RF analisados

Possibilidade de se optar por um de três diferentes métodos de modulação (FSK, GFSK ou

OOK)

Em contrapartida os consumos são maiores e o preço é ligeiramente mais elevado (em média 10€

contra os 8€ do modelo RFM12B, ver Tabela A2.6). A velocidade de transmissão não é fixa e pode ir

desde os 0.123 até aos 256kb/s, dependendo da modulação utilizada (terá que se optar pela

modulação FSK para se atingir o máximo de 256kb/s).

Dentro dos módulos sem-fios com frequência de transmissão abaixo dos 1GHz este é aquele que

oferece a melhor taxa de transmissão à maior distância (que pode chegar a vários quilómetros com o

hardware correcto). Em relação às vantagens e desvantagens que advém da frequência em que

opera e mecanismos de segurança são as mesmas que as apresentadas para o módulo RF anterior.

2.2.8 CC1000

Neste subcapítulo pretende-se apresentar uma família inteira pelo que seria mais correcto

denominar CC1xxx dados os inúmeros modelos que existem, muitos que não são compatíveis entre

si e que não oferecem as mesmas funcionalidades base. Grande parte são muito semelhantes ao

RFM22B apresentado anteriormente sendo que a maior diferença é a de que este chip permite uma

operação numa maior gama de frequências (todas situadas entre os 300 e 1000MHz) e oferece

menores velocidades de transmissão (à excepção de dois novos modelos que conseguem atingir

1250kb/s: CC1200 e CC1201). Existem também modelos mais recentes com novas funcionalidades

como por exemplo encriptação AES, mas que não foram considerados por não terem sido

encontrados em módulos RF e por só poderem ser adquiridos na forma de circuitos integrados em

grandes quantidades. Apenas se encontraram módulos RF que utilizassem os chips CC1101 e

CC1000 apresentados na Tabela A2.6 em anexo. O preço médio destes módulos RF enquadra-se

sensivelmente no mesmo dos módulos RFM22B e dadas as semelhanças entre ambos os prós e

contras acabam também por ser os mesmos.

26

3 DomoBus

3.1 Visão Geral

O sistema DomoBus e os respectivos protocolos associados foram concebidos tendo em conta a

noção de casas super-automatizadas onde uma habitação pode chegar facilmente às centenas de

dispositivos interligados em possivelmente diferentes redes dispersas por diferentes meios. Foi ainda

considerada a possibilidade de ter não só que coexistir como interagir com outras tecnologias

domóticas pelo que a separação entre protocolos de alto-nível - que irão ser comuns a todas as

tecnologias - e protocolos de baixo-nível - específicos à tecnologia utilizada - ganha um especial

relevo tornando imprescindível que os protocolos sejam flexíveis o suficiente para conseguirem lidar

com a vasta gama de tecnologias a que se propõem, assim como terão que ser rígidos na

implementação da especificação de modo a garantir que o sistema quando integrado como um todo

consegue operar sem perturbações e abstrair com sucesso as camadas mais baixas. Adicionalmente

pretende-se que do ponto de vista do utilizador final o sistema seja fácil de configurar e de gerir,

permitindo o agrupamento lógico de tarefas de baixo-nível de modo a tornar a interacção do utilizador

com a sua habitação simples mas completa, em que uma simples ordem dada no alto-nível se pode

desdobrar em inúmeras acções complexas nos níveis abaixo. Assim pretende-se oferecer uma

solução que assenta em modelos genéricos sobre tecnologia indefinida (ao nível dos controladores)

que permita a construção de sistemas complexos e genéricos que poderão evoluir através de

alterações aos seus modelos de dados, independentemente dos protocolos subjacentes.

No nível mais baixo de todos temos a noção de propriedade, que é a forma de representar os

aspectos funcionais de um determinado dispositivo e que permitem a comunicação com o mesmo.

Qualquer dispositivo genérico é constituído por um conjunto de propriedades que representam o seu

estado e permitem ler valores dos sensores ou dar ordens aos actuadores. O modelo de um

dispositivo genérico pode ser definido de modo a ser reutilizado por todos os dispositivos físicos que

apresentem funcionalidades semelhantes, centralizando assim todas as configurações que o definem

num único local permitindo mais facilmente futuras alterações, uma vez que se estão a lidar apenas

com abstrações do que existe fisicamente na habitação. Estes modelos (denominados Tipos de

Dispositivos) oferecem uma grande flexibilidade na definição de novos dispositivos, que poderá ser

feita a qualquer altura, nomeadamente posterior à instalação do sistema. Considerando o exemplo de

uma lâmpada regulada, esta pode – por exemplo - ser representada por duas propriedades: “Ligar /

Desligar” e “Intensidade” (ambas de leitura e escrita) e poderiam existir no sistema inúmeros

dispositivos do tipo ‘Lâmpada Regulada’ e todos se comportariam do mesmo modo,

independentemente da tecnologia em que estivessem implementados. Por sua vez os dispositivos

podem ser agrupados por funcionalidades em modelos denominados “Serviços”, que podem ser por

exemplo “Iluminação” ou “Sistema de Rega”, ou por localização através da utilização de modelos que

permitem definir a estrutura de uma habitação dividida em pisos e divisões. Esta abstração permite

actuar em conjuntos de dispositivos consoante as suas características e permite facilmente alterar as

propriedades dos respectivos dispositivos através de acções como – por exemplo – “Ligar todas as

luzes reguladas” ou “Desligar todos os dispositivos do primeiro piso”.

27

Até agora foram descritos os métodos de como definir a estrutura de uma habitação e os seus

constituintes, assim como as suas características que permitem os agrupamentos lógicos

apresentados. De seguida apresentar-se-ão os tipos de dispositivos físicos que permitem

implementar o modelo lógico descrito.

3.2 Tipos de dispositivos

Existem três tipos de dispositivos conceptuais nas redes DomoBus que permitem gerir todo o

sistema: os módulos de controlo, os módulos de supervisão e os módulos gateway. Estes módulos

comunicam entre si, cooperando para que o primeiro se encarregue das tarefas de mais baixo-nível,

o segundo se encarregue das tarefas de alto-nível e o terceiro forneça um serviço de tradução entre

os dois primeiros.

Os módulos de controlo são responsáveis por interagir com o meio físico através de sensores e

actuadores. Recebem e enviam dados para outros módulos de controlo dentro da mesma rede de

controladores ou para a aplicação de alto-nível respectiva que fará a ligação com o SL (supervision

level). Estes dados gerados poderão ser respostas a dados recebidos ou poderão ser dados enviados

espontaneamente devido a configurações específicas ou alterações nos valores lidos pelos sensores.

Na prática são pequenos sistemas embebidos com um microcontrolador como parte central do

módulo. Se estes controladores forem nativos ao DomoBus deverão implementar diversas

funcionalidades associadas a NApps, onde cada NApp representa uma entidade no microcontrolador

independente das outras [NApps] e contém o software necessário para interagir com um dado sensor

ou actuador. Cada NApp possui uma lista de dispositivos associados (todos do mesmo tipo) e os

respectivos portos do microcontrolador em que se encontram de modo a interagir directamente com

estes.

O módulo gateway é responsável por fornecer à rede DomoBus o serviço de traduzir o protocolo

utilizado pelos controladores para o protocolo DomoBus CL (control level). Este serviço divide-se

numa componente física ou de hardware e numa componente de protocolo ou de software: a

componente física trata de fornecer o hardware necessário à injeção e captura de tramas de dados

na tecnologia utilizada na sua interface secundária (por exemplo um módulo de rede powerline para

interagir com redes de dispositivos X10). A componente de protocolo é responsável por criar tramas

de dados de acordo com o protocolo DomoBus CL com base nos dados recebidos dos controladores

e vice-versa. Se no CL existir uma rede nativa ao sistema DomoBus (DCN ou DWCN, de DomoBus

Wireless Control Network) não deverá ser necessária a existência desta componente dado que os

controladores já terão sido desenvolvidos tendo em consideração as especificações do protocolo

DomoBus CL.

Figura 3.1 – Módulo gateway e as suas interfaces

28

Os módulos de supervisão são dispositivos físicos que actuam no SL (nomeadamente

computadores pessoais, sistemas embebidos, tablets, etc.) e que alojam as aplicações de alto-nível

(SLA ou Supervision-Level Application). O requisito comum a todas estas aplicações é o de

comunicarem através de tramas UDP sobre o protocolo IP, o que significa que os módulos de

supervisão terão que ter acesso a uma interface de rede (ethernet, Wi-Fi ou outro tipo de hardware

que permita o acesso a uma LAN) por onde comunicam com os outros módulos de supervisão.

Existem três tipos de SLA essenciais ao funcionamento de um sistema DomoBus: (SLA gateway, SLA

de interface com o utilizador e supervisores) que serão detalhadas de seguida.

O supervisor é uma SLA que é responsável por gerir o sistema DomoBus (ou parte deste) e pela sua

supervisão. É no supervisor que são processadas as informações recebidas dos módulos

controladores - via respectivas SLA gateway e módulo gateway – e são aplicadas as regras definidas

pelo utilizador que resultarão em acções personalizadas aplicando assim o comportamento desejado

pelo utilizador na sua habitação. Um supervisor pode reagir a alterações de propriedades na rede

utilizando eventos ou pode reagir a tarefas temporizadas utilizando calendarizações. Um evento

consiste numa associação entre uma propriedade cuja alteração despoleta o evento, uma lista de

condições (que poderão recorrer a qualquer propriedade do sistema DomoBus, assim como poderão

ser utilizadas variáveis de sistema como, por exemplo, o dia da semana) e uma lista de acções que

serão tomadas caso a condição se verifique. Nesta lista de acções poderão constar instruções para

outros módulos controladores ou acções de sistema (como o envio de e-mails ou SMS). Uma

calendarização é em tudo semelhante a um evento, com a excepção de que é uma certa data e hora

que despoletam as acções e não uma propriedade.

As interfaces com o utilizador, denominadas SLUI (supervision-level user interface), permitem que o

utilizador possa, de uma forma centralizada, interagir com o sistema DomoBus: ver o estado dos

dispositivos, tomar acções e configurar todas as parametrizações. Tipicamente uma SLUI comunica

com os supervisores mas poderá não se restringir apenas a estes e interagir com qualquer outra SLA

que se mostre necessário. Existe muita flexibilidade na forma como estas poderão ser implementadas

dado que não se limitam a uma tecnologia ou linguagem de programação. Apenas terá que ser

garantido que comunicam através de UDP, que implementam o protocolo DomoBus SL quando

comunicam com os restantes dispositivos SL e que sabem interpretar os respectivos dados. Estas

SLUI poderão adoptar uma arquitectura server-side centralizando a UI (user interface) sendo

acedidas por outros dispositivos, ou uma arquitectura local através da utilização de pelo menos um

dispositivo HID (Human Interface Device) para agir como método de entrada, como por exemplo um

teclado, ecrã sensível ao toque, microfone, etc. As SLUI são também responsáveis por validar os

utilizadores recorrendo a técnicas de autenticação (que poderão ou não ser simplificadas através do

uso de parâmetros biométricos), e restringir o acesso aos utilizadores conforme as configurações

aplicadas.

Dado o meio de comunicação em que assentam as SLA (nomeadamente as SLUI) ser usualmente

o mesmo utilizado para a ligação à Internet torna-se apenas dependente de configurações locais (e

sem necessitar de hardware adicional) permitir o acesso remoto às interfaces do utilizador que

29

permitem gerir o sistema DomoBus instalado. Isto oferece grandes vantagens em relação a outras

tecnologias domóticas que geralmente necessitam de um dispositivo próprio (hub ou Home Gateway)

que centralize a gestão da respectiva rede domótica e o acesso à Internet. A abordagem adoptada

pelo DomoBus é mais robusta pela sua distribuição, cujo nível poderá ser escolhido pelo utilizador

final (num limite poderá também centralizar-se tudo num único dispositivo, no outro poderá distribuir-

se cada SLA por um módulo supervisor diferente podendo inclusive existirem SLA ou módulos

supervisores redundantes).

Por fim, as SLA gateway (ou SLAG) são aplicações especiais, encarregues de gerir uma dada

rede CL. São endereçadas nos primeiros 16 bits do endereço do dispositivo (Device Address de 32

bits, ver Figura 3.5) e estão encarregues de fazer a tradução entre as tramas SL e as CL em ambos

os sentidos. Como nesta tradução ocorre uma redução dos dados transmitidos no sentido do SL para

o CL, ignorando-se aspectos do endereçamento do SL que não são utilizados pelos módulos

controladores, a SLAG é também responsável por reconstruir as tramas SL a partir de tramas CL

quando o fluxo de dados ocorre no sentido dos módulos controladores para as SLA, tendo para isso

que guardar os respectivos dados inicialmente ignorados e mantendo uma lista de relações entre SLA

e dispositivos de módulos controladores. Uma SLAG estará normalmente acompanhada por um

módulo gateway que permitirá transpor os dados para o meio de transmissão utilizado nativamente

pela rede CL. Não se especifica o tipo de ligação pelo que caberá a cada tecnologia CL definir qual o

meio de comunicação e protocolo (USB, RS232, RS485, etc.) a utilizar para transmitir dados entre o

seu respectivo módulo gateway e a SLAG que gere essa rede CL. A comunicação de dados entre

ambos deverá no entanto respeitar a especificação DomoBus CL de modo a uniformizar o

funcionamento das SLAG permitindo que estas possam ser reutilizadas em diversas tecnologias.

Não existe um limite de supervisores, SLAG ou SLUI. O mesmo depende apenas do tamanho da

rede ou do planeamento por parte do utilizador final. A especificação encontra-se aberta no que toca

a novos tipos de SLA, o que oferece uma grande flexibilidade para inovar no desenvolvimento de

novas funcionalidades de alto-nível dado que uma SLA não se restringe apenas a estas

funcionalidades apresentadas. Uma SLA pode ser vista como um conceito de um programa de alto-

nível num sistema DomoBus que pode interagir com todas as componentes do sistema, desde as de

mais baixo nível (dispositivos associados aos controladores) como às de mais alto nível (supervisores

e outras SLA) permitindo assim a construção de algoritmos que podem usufruir da camada de

abstração fornecida pelo protocolo DomoBus, de modo a implementarem facilmente manipulações

complexas no sistema em que se inserem. Para implementar a lógica necessária para lidar com

situações mais complexas que não conseguem ser descritas pelos simples conjuntos de regras para

eventos e calendarizações poderão ser criadas SLA para implementarem essa mesma lógica.

Consideremos, por exemplo, que uma habitação possui sensores de movimentos que são utilizados

para o sistema de alarme e que possui algumas lâmpadas ligadas também a módulos controladores.

No caso de se quererem implementar mecanismos de poupança de energia, nomeadamente desligar

lâmpadas que não estejam em utilização, uma SLA poderá implementar contadores para cada

lâmpada ligada que são reiniciados quando é detectado movimento no respectivo detector de

30

movimento. Se uma lâmpada está ligada há mais de um certo tempo, definido pelo contador, sem

existir movimento nas proximidades da mesma então poderá ser desligada. Este é apenas um

exemplo que pretende ilustrar a versatilidade de todo o sistema que se encontra preparado para lidar

com os casos mais comuns no âmbito da domótica mas que não se cinge apenas a estes,

disponibilizando uma plataforma sobre a qual se podem elaborar modelos mais complexos abstraindo

toda a complexidade inerente às comunicações e à interacção das diferentes tecnologias que

poderão compor o sistema DomoBus.

Figura 3.2 – Arquitectura de uma rede DomoBus. Não se limita a forma como são feitas as conecções entre dispositivos excepto no SL

As vantagens de se utilizar como canal de comunicação de alto-nível redes ethernet (IEEE 802.3)

ou Wi-Fi (IEEE 802.11) são muitas, das quais se destacam:

Tecnologia que já existe em grande parte das residências e que poderá ser partilhada com

outras utilizações não relacionadas com o DomoBus (acesso à Internet por exemplo)

Tecnologia estável, de custo reduzido e bastante escalável recorrendo a inúmeros protocolos

que facilitam a implementação deste tipo de redes (DHCP, DNS, UPnP, SNMP, NAT, etc.)

Permite cobrir grandes distâncias e existem inúmeros produtos no mercado para implementar

as mais diversas funcionalidades adicionais (PoE, repetidores, etc.)

Permite configurar acesso remoto à instalação de uma forma simples e com muitas

potencialidades (por exemplo a utilização de VPN para unir diferentes instalações físicas

numa só utilizando a Internet como meio de transporte)

Esta abordagem distingue o DomoBus de quase todas as tecnologias domóticas existentes, na

medida em que é pensado de raiz para lidar com dispositivos flexíveis nas suas funcionalidades e nas

tecnologias que estes utilizam, como para lidar com redes que podem atingir grandes proporções,

indo contra os casos mais comuns que apresentam soluções para pequenas redes de dispositivos

com funcionalidades imutáveis. Poderá dizer-se que o DomoBus será mais indicado para a

construção de grandes redes dinâmicas de sensores e actuadores ao contrário de grande parte das

tecnologias domóticas até aqui apresentadas que se dedicam a usos muito específicos e estáticos.

31

3.3 Especificação DomoBus

De modo a poder especificar um sistema que abrange um vasto leque de tecnologias é importante

ter os conceitos abstratos bem definidos, pois são estes que serão a base comum a interligar todas

as variantes do sistema DomoBus. O conceito de propriedade é o mais elementar pois é sob a forma

de propriedades que os dados são trocados tanto no SL como no CL. As propriedades são

constituídas por um cabeçalho, onde são incluídas informações sobre a propriedade e o seu valor,

seguido pelos respectivos dados.

Figura 3.3 – Cabeçalho de uma propriedade

O cabeçalho ocupa 8 bits e encontra-se dividido como representado na Figura 3.3. São utilizados

2 bits para representar os 3 tipos distintos de propriedades (ver Tabela 3.1) a partir dos quais é

possível obter deterministicamente o tamanho dos dados que se seguem. Para identificar

inequivocamente cada propriedade existem 5 bits reservados para representar um identificador que

poderá assumir um valor inteiro entre 0 e 31. É utilizado ainda 1 bit denominado “Inválido” para

sinalizar um erro relativamente ao processamento do valor da propriedade como por exemplo o valor

não ser o esperado ou o facto de o sensor não ter ainda retornado um valor válido.

Valor Denominação Tamanho dos dados

0 Valor de 8 bits sem sinal 1 Byte

1 Valor de 16 bits sem sinal 2 Byte

2 Vector Domobus Definido no Byte seguinte ao cabeçalho

Tabela 3.1 – Diferentes tipos de propriedades

Assim para guardar dados na forma de propriedades, se os dados contém 1 ou 2 Bytes são

necessários 2 ou 3 Bytes para alocar a respectiva propriedade. No caso de dados com mais de 2

Bytes são necessários mais 2 Bytes, um para o cabeçalho (à semelhança dos anteriores) e um que

surge após o cabeçalho para definir o tamanho dos dados que se seguem. Daqui surge a limitação de

que os dados de uma propriedade nunca poderão exceder 255 Bytes.

Figura 3.4 – Possíveis estruturas de dados para as propriedades. À direita para propriedades do tipo vector, à esquerda as restantes

Embora o modelo utilizado para definir as propriedades permita que estas apenas pertençam a um

de três tipos (8 bits, 16 bits ou vector) foi considerada a existência de modelos de representação e de

conversão de propriedades para que estas possam ser diferenciadas no SL e possam ser

apresentadas ao utilizador com maior detalhe. Mais especificamente existem três modelos genéricos

que permitem alargar o conceito de propriedade assim como a sua utilização:

32

Conversão de valores por fórmulas, que permite criar objectos que definem fórmulas de

conversão de valores no seu estado bruto para o valor convertido e vice-versa. Poderá ser

utilizado, por exemplo, para converter números inteiros em decimais ou para a conversão de

unidades em que um sensor de temperatura poderá retornar o resultado em graus Celsius e

recorrendo a este tipo de objectos transforma-se o valor em graus Fahrenheit no SL e assim

será possível processar todas as regras definidas assim como apresentar os valores ao

utilizador tudo em Fahrenheit.

Conversão de valores por objectos, cujo objectivo é o mesmo do ponto anterior com o extra

de oferecer a flexibilidade necessária quando estão em causa conversões mais complexas

que não podem ser explicitadas por uma única fórmula e terão que ser transformadas

recorrendo a código específico associado a este objecto. Útil, por exemplo, no caso de um

sensor utilizar parte dos bits da propriedade para o valor e outra parte para o sentido da

variação detectada.

Tipos de valores, que permitem ao SL associar automaticamente uma propriedade a um tipo

de valor e a um objecto de conversão de valores por fórmulas ou objectos. Os tipos de

valores permitem por exemplo criar tipos enumerados (associar uma descrição a um valor

específico) ou especificar características que o valor poderá assumir (valor mínimo e máximo,

tamanho do incremento ou decremento unitário, etc.). Estes tipos de valores poderão ser

reutilizados por todo o sistema centralizando assim as definições (torna mais simples mudar

todas as leituras que eram vistas em Celsius para Fahrenheit independentemente do

dispositivo ou da tecnologia em que este opera)

Estes modelos também permitem criar qualquer outro tipo de dados que não seja um número

inteiro sem sinal de 8 bits ou 16 bits a partir do tipo de dados vector. Recorrendo a este último é

possível não só representar novos tipos de dados (por exemplo números de virgula flutuante de 32

bits) como estruturas de dados encapsuladas no campo do valor de uma propriedade do tipo vector, o

que oferece uma flexibilidade extra ao poder lidar com praticamente todo o tipo de dados, impondo

restrições apenas no tamanho que estes podem assumir.

Quanto ao endereçamento no alto-nível, ou SL, são utilizados dois tipos de endereços consoante

o destino dos dados. Se os dados são para ser trocados entre SLA – quaisquer que sejam os seus

tipos – então o endereço utilizado nas tramas SL é representado por 16 bits. É garantido que para

cada um destes endereços SLA de 16 bits existe um par de endereço IP e porto de comunicação

único que permitem endereçar via protocolo IP cada SLA independentemente (a função de converter

identificadores SLA em endereços IP e portos é feita por um serviço de rede dedicado no SL). Se os

dados são para ser enviados para um controlador ou dispositivo, ou seja, para serem passados ao

nível inferior – CL – então é endereçado no campo de dados o dispositivo de origem e de destino

onde cada um é composto por 32 bits, onde os primeiros 16 bits endereçam uma SLA (mais

especificamente uma SLAG) que representa a rede CL respectiva e que é responsável pela troca de

dados entre os níveis SL e CL. Os restantes 16 bits são utilizados para endereçar, dentro dessa rede

CL, o respectivo dispositivo (denominado CDev ou Control Device). Como a tecnologia utilizada no

33

CL não é fixa, estes últimos 16 bits poderão ser livremente utilizados pela SLAG e pelo respectivo

módulo gateway de modo a traduzirem inequivocamente o endereço DomoBus CL de 16 bits (CDev)

num endereço válido para a tecnologia em utilização. No caso específico de redes DCN, ou seja,

redes de baixo-nível nativas ao protocolo DomoBus, estes 16 bits são repartidos pelo endereço do

módulo controlador, da aplicação e do dispositivo, como se detalha na Figura 3.5.

Figura 3.5 – Detalhes do endereçamento no protocolo DomoBus

O endereço do dispositivo (5 bits) define o destino final de uma trama endereçada para uma DCN.

O dispositivo terá um endereço relativo a uma aplicação (ou Node Application, daqui em diante

denominada de NApp para evitar confundir com as aplicações de alto-nível, as SLA) e pode assumir

um número inteiro entre 0 e 31, ou seja, uma NApp poderá ter no máximo 32 dispositivos associados

num dado módulo controlador. O endereço da aplicação (NApp) define o tipo de dispositivo, ou de

outro modo, define a entidade no microcontrolador que possui o código que sabe interagir com o

hardware que o dispositivo representa. As diferentes NApps (no máximo poderão existir 7 distintas

dado que a primeira está reservada para representar o sistema) estão a ser executadas no módulo

controlador. Por fim existe o endereço do módulo controlador (NAddr) com 8 bits que permite

endereçar 256 diferentes controladores dentro da DCN definida pela respectiva SLAG (esta por sua

vez definida pelos 16 bits apresentados como App Gateway).

Como um exemplo ilustrativo poderemos considerar um módulo controlador com dois dispositivos

sensores de luminosidade e com quatro dispositivos constituídos por relés ligados a sistemas de

iluminação. Este módulo controlador terá então pelo menos duas NApps activas, uma respectiva aos

dispositivos sensores de luminosidade e outra relativa aos dispositivos de relés. Para a primeira NApp

existem dois dispositivos – 1 e 2 – e para a última NApp existem os dispositivos 1,2,3 e 4. Todos os

dispositivos poderão ser controlados através das propriedades que estão definidas no tipo de

dispositivo respectivo e para estas [propriedades] serem alteradas as tramas terão de ser enviadas

para os endereços correspondentes (composto pelo endereço do módulo controlador, NApp e

dispositivo). Este método de endereçar oferece uma comunicação ponto-a-ponto entre aplicações SL

(SLA) e dispositivos relacionados com aplicações DCN (NApps).

Relativamente ao formato das tramas SL, estas possuem um Byte para definir o tamanho total da

trama que poderá atingir no máximo 255 Bytes (e que por conseguinte acaba por limitar o tamanho

34

máximo de uma propriedade do tipo vector) seguido de 2 Bytes para o endereço SL de destino e

outros 2 Bytes para o endereço SL de origem. Existem ainda três campos de controlo, o SNum (ou

Sequence Number), o CTR (ou Control Field) e o CRC (Cyclic Redundancy Check) todos de 1 Byte

apenas. O primeiro serve para indicar a posição da trama em tramas consecutivas, o segundo

(apresentado na Figura 3.7) apresenta informação de controlo variada e o último contêm a verificação

de redundância cíclica que permite prevenir erros ocorridos na transmissão do pacote. Resta o

campo de dados cuja constituição depende do tipo de pacote indicado no campo CTR, que pode

assumir os seguintes valores:

GET ou SET para obter ou gravar respectivamente valores em propriedades. No caso de uma

trama do tipo GET o campo value poderá não ser utilizado, sendo preenchido apenas na

resposta. O endereçamento é feito recorrendo ao Device Address previamente descrito que é

composto por 16 bits referentes à SLAG e 16 bits referentes ao endereço CDev.

NOTIFY para notificar da alteração do valor de uma propriedade

EXEC, um tipo genérico que permite aumentar a flexibilidade do tipo de dados trocados e que

pode assumir diferentes funcionalidades

Figura 3.6 – Estrutura das tramas SL

A separação entre os endereços SL das SLA (AppDest e AppOrig) e os endereços SL das SLAG

(primeiros 16 bits de DevAddrOrig e DevAddrDest) permite que no SL as tramas possam ser trocadas

entre vários dispositivos (alterando os campos AppDest e AppOrig) sem nunca se perder a referência

de qual a SLA (SLAG) associada ao controlador com a qual se quer comunicar em última instância,

definida nas tramas do tipo GET, SET e NOTIFY.

À excepção do tipo de trama, ou OpCode (de Operation Code), o Byte CTR contém ainda 4 bits

de sinalização: Prioridade, Retransmissão, Erro e ACK (de reconhecimento ou acknowledgment)

cujos nomes deverão ser autoexplicativos.

Figura 3.7 – Estrutura do Byte CTR nas tramas SL

35

OpCode (bits) OpCode

000 EXEC

001 GET

010 SET

011 NOTIFY

1xx Reservados

Tabela 3.2 – Tipos diferentes de OpCodes

As tramas trocadas no CL são muito idênticas às do SL. A principal diferença reside no modo

como o endereçamento é feito. Neste nível não se endereçam dispositivos do SL, ou seja, não se

endereçam nenhumas SLA, apenas os dispositivos do CL dado que estas tramas [CL] apenas

residem na respectiva rede DCN, entre a SLAG e os módulos controladores. Se for necessário trocar

dados no sentido de uma DCN para o SL então é implícito que o destino será a SLAG responsável

por essa DCN, esta que depois saberá encaminhar os dados para a respectiva SLA que se encontra

associada. Este encaminhamento no sentido ascendente (CL para SL) é feito recorrendo aos bits

relativos à NApp e dispositivo (ADev), uma vez que nem na SLAG nem no módulo gateway existe o

conceito de NApp ou ADev. Assim estes bits são utilizados pela SLAG para estabelecer relações

entre uma SLA e um dispositivo no CL. Estes identificadores viajam pela rede nas tramas CL,

inicialmente no campo CDevOrig, e na resposta são trocados para o campo CDevDest. A SLAG ao

receber uma trama de dados através do módulo gateway utiliza os bits correspondentes à NApp e

ADev do campo CDevDest para procurar numa lista pela SLA que aguarda esses dados. Este

método permite construir uma tradução de endereços directa impondo a restrição de que uma SLAG

só poderá interagir com 223 diferentes SLA dados os 8 bits disponíveis para endereçar NApps e

dispositivos e a reserva da primeira NApp (0) para endereçar a própria SLAG ou gateway (para que

estas possam receber mensagens de configurações).

Figura 3.8 – Estrutura das tramas CL

Assim nas tramas CL, os endereços denominados CdevDest e CDevOrig (ver Figura 3.8)

correspondem aos endereços CDev de 16 bits que especificam o caminho a seguir até ao dispositivo

final (ver Figura 3.9). Por sua vez as tramas do tipo GET, SET e NOTIFY são simplificados devido à

informação sobre o endereçamento que nas tramas SL faziam parte do campo de dados agora

fazerem parte do cabeçalho da trama. Este tipo de tramas agora apenas necessita de endereçar no

campo de dados a propriedade dentro do dispositivo que é referido no cabeçalho e o respectivo valor

36

da propriedade de destino. Os campos de controlo Tlen, SNum e CRC assumem as mesmas

funcionalidades previamente descritas.

Figura 3.9 – Estrutura dos endereços DCN (CDev)

Recorrendo à utilização de propriedades para representar os dados trocados no agregado de

redes do sistema DomoBus e aos tipos de tramas representados é possível obter a flexibilidade

necessária para lidar com os mais variados tipos de situações no contexto da automação residencial

recorrendo às tecnologias nativas do DomoBus (DCN). No caso da interacção com outras tecnologias

domóticas estará a cargo dos gateways fazerem a tradução entre as tramas e a lógica associada a

essa tecnologia para as tramas e lógica associada ao protocolo DomoBus, permitindo assim que os

dispositivos possam todos ser representados por um modelo comum, independentemente da sua

tecnologia ou meio de comunicação.

37

4 Descrição da solução proposta

Neste capítulo serão abordadas as opções tomadas a nível de hardware e software com vista a

implementar uma solução para um módulo controlador genérico sem-fios que se integre no sistema

DomoBus, mais especificamente como um bloco básico de construção das redes DWCN tendo em

conta o que foi anteriormente descrito, nomeadamente os principais objectivos do projecto e a

especificação do protocolo DomoBus. Paralelamente à implementação do módulo controlador será

também necessário desenvolver o módulo gateway e a respectiva SLAG que permitirão implementar

a interface entre o SL genérico do DomoBus e a rede de controlo DWCN desenvolvida.

Primeiro serão apresentadas e justificadas as opções tomadas em relação à rede: quais as

topologias mais indicadas para a finalidade que se pretende, qual o módulo RF escolhido para aplicar

essa topologia e as principais características desse módulo. De seguida apresenta-se uma proposta

para a arquitectura do módulo controlador seguida da justificação pela escolha feita relativamente ao

microcontrolador. Por fim termina-se com alguns detalhes sobre a implementação do módulo

controlador, do módulo gateway e da respectiva SLAG.

4.1 Rede

Como referido nos objectivos deste projecto, não existem requisitos rígidos em relação às

características do módulo RF escolhido, tentando-se encontrar o melhor compromisso entre a

escalabilidade e a fiabilidade oferecidas. Pretende-se encontrar a melhor solução, das disponíveis,

que permita construir redes de controladores com pelo menos uma centena de nós, e que várias

destas redes possam operar no mesmo espaço de modo a favorecer a robustez do sistema. A

velocidade de transmissão máxima estará relacionada com a topologia escolhida para a camada de

rede, dado que a topologia poderá definir se um nó terá que dividir a sua largura de banda com outros

nós a seu cargo, ou se a poderá utilizar integralmente. Por outro lado, uma velocidade de transmissão

demasiado elevada para os requisitos resultará em elevados consumos energéticos sem qualquer

tipo de vantagens. A utilização típica destes módulos RF será em espaços interiores, existindo a forte

possibilidade de ter que coexistir com outros dispositivos a operarem na mesma banda de

frequências caso se optem pelos módulos RF a operar na banda de 2.4GHz.

Dado que um módulo controlador genérico será um dispositivo com diversas funções à partida

desconhecidas (em funcionalidades e número de dispositivos) e que os seus recursos são de

extrema importância para permitirem alocar o máximo número de funcionalidades (de modo a lidarem

com uma vasta gama de dispositivos), irá dar-se um maior relevo a módulos RF que permitam

realizar o maior número de funcionalidades em hardware. Quantas mais tarefas relativas à rede forem

da responsabilidade do módulo RF - como por exemplo gestão dos buffers, validações de integridade

dos dados, reconhecimento de mensagens entregues, etc. – menores serão as tarefas relativas à

rede a serem implementadas no microcontrolador, resultando na possibilidade de se utilizar

praticamente toda essa capacidade para a gestão de dispositivos.

38

De modo a implementar as ligações ponto-a-ponto desejadas (entre SLA e NApps) numa rede

com topologias que permitam aos pacotes percorrerem diversos nós até chegarem ao seu destino

(multi-hop), será necessário no mínimo terem-se implementadas quatro camadas do modelo OSI:

A camada física responsável por lidar directamente com o módulo RF

A camada de ligação de dados ou de enlace responsável pelas ligações ponto-a-ponto e pela

detecção de erros na camada física

A camada de rede responsável por endereçar e encaminhar as tramas de dados entre nós

A camada de aplicação que entregará os dados da trama à respectiva NApp

Por fim, irá tentar-se simplificar ao máximo as configurações necessárias para um módulo

controlador ficar operacional. Idealmente deverá vir originalmente com a capacidade de se adicionar

automaticamente a uma rede já estabelecida e de sinalizar o supervisor dessa mesma rede que se

encontra por configurar. Assim todas as restantes configurações relativas ao módulo controlador

poderão ser configuradas recorrendo ao canal de comunicação já existente sem ser necessário

recorrer a qualquer hardware extra ou a configurações locais no módulo controlador para o colocar

em pleno funcionamento.

4.1.1 Topologia

Como referido anteriormente, pretende-se uma topologia que permita encaminhamento de tramas

multi-hop em detrimento de topologias centralizadas como topologias em estrela. Deste modo ao

adicionarem-se nós à rede está-se ao mesmo tempo a aumentar o alcance total da mesma fazendo

com que os nós se possam auxiliar uns aos outros na entrega de mensagens. Pretende-se que o

encaminhamento seja ponto-a-ponto de modo a utilizar mais eficientemente a infraestrutura da rede

em que opera, em detrimento de métodos como por exemplo o aplicado pela tecnologia Insteon em

que todas as mensagens são trocadas em broadcast e todos os nós repetem o que recebem, o que

não se aplicaria bem a redes para ambientes super-automatizados. Ao mesmo tempo pretende-se

evitar optar por topologias que não favoreçam a escalabilidade da rede ao utilizarem canais de

comunicação comuns a todos os nós (em que cada nó poderá ter que competir com todos os outros

para aceder ao meio de transmissão) ou ao restringirem demasiado a configuração física que a rede

poderá assumir. Assim excluímos topologias do tipo barramento (bus) por partilhar o mesmo canal de

comunicação por todos os dispositivos e topologias do tipo em anel ou em série pois impõe fortes

restrições no posicionamento dos seus nós.

O que se pretende são portanto topologias do tipo árvore ou em malha (mesh). Conceptualmente

uma topologia do tipo em malha seria a melhor solução, pois não restringe de todo o modo como a

rede se poderá encontrar distribuída fisicamente (desde que se respeitem as distâncias máximas de

comunicação) e ainda apresenta as melhores características no que se refere à fiabilidade das

comunicações pois poderá não existir um único caminho para chegar de um nó da rede a outro,

sendo assim mais tolerante a falhas. No entanto, na realidade, esta abordagem é demasiado

complexa pois implica a criação de algoritmos para descobrir caminhos e que cada nó da rede seja

capaz de aplicar estes algoritmos assim como terá que saber quando descartar tramas que poderão

39

ainda estar a ser trocadas na rede depois de já terem sido recebidas pelo nó destinatário. Optar por

esta abordagem seria ir contra o objectivo de conseguir obter módulos controladores genéricos e de

baixo custo pois os recursos necessários para implementar uma verdadeira rede em malha que

pudesse ser escalável no contexto da super-automação seriam consideravelmente maiores,

nomeadamente no que se refere a memória (de programa para os algoritmos, e de dados para alocar

os dados relativos ao encaminhamento) e à capacidade de processamento acrescida para que o

facto de estarem a auxiliar o funcionamento da rede não afectasse as suas tarefas de controlador. A

solução para diminuir custos passaria por, à semelhança do que tecnologias como o ZigBee e Z-

Wave implementaram, optar por diferentes tipos de nós, um que fosse central e comandasse a rede,

outros que pudessem ter a capacidade de encaminhar e ainda outros que apenas comunicassem

com estes últimos. Esta abordagem vai contra o conceito de um controlador genérico, uma base

única para todas as possíveis funcionalidades que agiria como um bloco de construção básico e

flexível de uma habitação super-automatizada não oferecendo assim nenhuma inovação considerável

às tecnologias que existem actualmente. Por estes motivos apresentados decidiu-se favorecer a

simplicidade dos módulos controladores, das suas funções e configurações em prol de se obter uma

topologia de rede mais dinâmica e menos susceptível a falhas. Assim, de modo a manter a

simplicidade necessária no encaminhamento de dados pelos nós da rede é necessário que exista

apenas um caminho para uma trama ir de um nó de origem para um nó de destino, e que o algoritmo

que permita calcular este caminho seja simples, isto é, que cada nó possa facilmente calcular o

caminho único sem necessitar de comunicar com outros dispositivos da rede.

Por todos os motivos apresentados, chegou-se à conclusão que a topologia mais indicada que

favorecesse a escalabilidade através da utilização eficiente dos recursos disponíveis, é a topologia

em árvore. Esta topologia permite que os nós estendam o alcance total da rede ao mesmo tempo que

oferece caminhos únicos de e para qualquer nó na rede. O preço a pagar por esta simplicidade é o de

não oferecer redundância no caso de um dos nós deixar de funcionar, o que poderá ser abordado

através de técnicas de auto-regeneração para reorganizar a árvore de um modo automático ou semi-

automático permitindo assim oferecer algum nível de redundância e aumentado parcialmente a

robustez da rede.

Adicionalmente a tudo o que já foi discutido, será importante que a implementação da topologia

permita oferecer a capacidade de enviar mensagens em broadcast, de modo a permitir introduzir

funcionalidades que não dependam do endereçamento directo de um nó, mas que dependam de

outros parâmetros, como por exemplo, grupos de dispositivos. Esta capacidade poderá também

trazer benefícios em instruções que se queiram dar a toda a rede como por exemplo, alterar

parâmetros de segurança (que se querem uniformizados em todos os nós da rede) ou aplicar

funcionalidades para operações de manutenção da rede. De modo a sinalizar as mensagens que são

para serem enviadas em broadcast foi utilizado o bit que estava reservado no campo de controlo CTR

(ver Figura 4.1 e Figura 3.7).

40

Figura 4.1 – Estrutura do Byte CTR no CL para as redes DWCN. Da esquerda para a direita: Broadcast, Prioridade, Retransmissão e Erro.

4.1.2 Segurança

A encriptação dos dados transmitidos é um dos passos essenciais no estabelecimento de uma

rede de comunicação segura. Quanto mais baixa a camada de rede em que seja implementada a

encriptação mais seguro estará o sistema, pois encriptar os nós de origem e de destino da rede assim

como a restante informação de controlo presente nas tramas é tão importante quanto encriptar os

dados da trama. No entanto os algoritmos de encriptação considerados seguros são algoritmos que

requerem alguma capacidade computacional o que se torna difícil de implementar com pequenos

microprocessadores de 8 ou 16 bits. Por isso mesmo, não é raro recorrer a algoritmos de encriptação

implementados em hardware de modo a não sobrecarregarem o sistema de processamento central

com as tarefas de codificar e descodificar dados.

Com este projecto específico em mente, foi feita uma avaliação dos diversos algoritmos de

encriptação, as suas fraquezas e os seus requisitos em termos computacionais, de modo a decidir se

existiria uma forma viável de implementar a encriptação dos dados recorrendo exclusivamente ao

microcontrolador de modo a conseguir estabelecer um equilíbrio entre a segurança da rede a

implementar e o custo final de cada nó dessa rede. A conclusão a que se chegou foi a de que para se

utilizar um algoritmo considerado inteiramente seguro no sentido criptográfico (por exemplo AES de

128 ou 256 bits) seria necessário recorrer a hardware especializado, pois estes algoritmos são

extremamente complexos e não só necessitam de muito poder computacional como consomem uma

elevada quantidade de tempo e energia. No entanto existem inúmeros outros algoritmos que embora

não sejam considerados inteiramente seguros, são seguros a um nível que é satisfatório e que

quando combinado com outras técnicas, tornam o algoritmo perfeitamente aceitável neste contexto

de aplicação. Independentemente do algoritmo, deverá sempre evitar-se recorrer a números

aleatórios gerados no microcontrolador, pois sem recorrer a sensores de parâmetros físicos do

ambiente, é extremamente difícil obter números aleatórios que não estejam correlacionados entre si,

o que representa uma potencial fraqueza que poderá ser explorada.

Os mecanismos básicos para garantir a segurança de uma rede não terminam com a encriptação

das tramas nas primeiras camadas do modelo OSI. Se não existir nada de único ou de diferente entre

tramas com a mesma origem, mesmo destino e os mesmos dados será fácil para um atacante repetir

um comando, mesmo que não o consiga interpretar. Por melhor que seja o algoritmo de encriptação,

se não existir autenticação dos dispositivos e métodos para proteger de ataques de repetição, o

atacante poderá simplesmente guardar todos os comandos que detecta, mesmo encriptados, para

mais tarde poder injectá-los na rede e ver no que resultam. Para evitar ataques de repetição é preciso

incluir um campo único em cada trama, que poderá ser um número aleatório ou um número

sequencial. Para qualquer bom algoritmo de encriptação bastará uma diferença mínima na entrada

41

para gerar uma saída diferente o suficiente de modo a dificultar a análise estrutural dos dados

encriptados quando estes são analisados em grande número.

O outro problema já referido é o de autenticar o nó da rede que envia a mensagem para saber se

é mesmo este que está a enviar a mensagem ou se a mensagem está a ser injectada por terceiros.

Uma maneira simplista de resolver este problema que não envolva adicionar mais passos na troca de

mensagens ou configurações complexas é a de considerar a existência de um contador em cada

ligação unidirecional entre nós. Este contador fará parte dos campos de controlo da trama podendo

ao mesmo tempo prevenir contra ataques de repetição (pois será incrementado a cada mensagem

trocada). Assim o nó que recebe uma mensagem verifica se o contador tem um valor igual (ou

superior até um certo limite no caso de se terem perdido mensagens) ao que ele espera. Se não, a

mensagem é descartada e o nó é considerado como não autêntico.

Por fim faltam abordar dois tipos de ataques mais comuns e geralmente mais fáceis de

implementar: DoS (Denial of Service) e por interferência (jamming) que poderão em certos casos

sobrepor-se. O primeiro é difícil de efectuar de uma forma direccionada sem saber a palavra-chave

do algoritmo de encriptação, ou seja, saturando os nós da rede com mensagens válidas impedindo

que estes consigam processar as mensagens que realmente interessam, as provenientes de outros

nós autênticos. Assim [sem a palavra-chave] só será eficaz se utilizado com o mesmo propósito do

último, ou seja, saturando o canal de comunicação impedindo que os nós da rede consigam

comunicar. Ambos estes métodos de ataque poderão ser muito eficazes e são difíceis (se não

impossíveis) de combater, apenas podendo ser detectados. Uma técnica que permite facilmente

detectar quando nós de rede ficam indisponíveis é a de forçar uma comunicação periódica entre os

mesmos e a respectiva SLAG. Esta configuração poderia ser diferente de nó para nó para que, por

exemplo, os nós relacionados com o serviço ‘Alarme’ possam ter temporizadores mais rápidos que os

do serviço ‘AVAC’. Assim, quando passava esse tempo configurado sem existir comunicação, a

SLAG poderia emitir um alerta para o supervisor (que por sua vez poderia despoletar uma acção de

sistema como o envio de um SMS). Este tipo de ataques realça a importância de optar por

comunicações cabladas em detrimento das sem-fios quando o uptime é uma prioridade,

nomeadamente na SLAG correspondente ao sistema de alarme que deverá sempre utilizar ethernet

em vez de Wi-Fi de modo a poder sempre conseguir comunicar mesmo quando são introduzidas

propositadamente interferências no canal de comunicação.

4.1.3 Módulo RF

Dos protocolos apresentados no capítulo do estado da arte existem alguns que claramente não se

adequam aos objectivos deste projecto, nomeadamente os de mais alto nível como Wi-Fi, Bluetooth,

Bluetooth Low Energy ou ZigBee. Embora estes ofereçam algumas vantagens, nomeadamente no

que se refere à segurança das comunicações ou à implementação de diversas camadas de rede do

modelo OSI são demasiado complexos o que os obriga a recorrer a microprocessadores de 16 ou 32

bits e grandes quantidades de memória que acaba por se reflectir nos seus consumos e preços.

Apenas o Wi-Fi e o ZigBee seriam capazes de implementar uma rede com mais de uma centena de

nós, e destes apenas o ZigBee o conseguiria fazer de uma forma distribuída. Qualquer destas

42

escolhas torna-se difícil de justificar no contexto de habitações super-automatizadas onde se

pretendem dezenas ou centenas de controladores por divisão obrigando a um dimensionamento

apropriado à utilização final de modo a minimizar os custos de cada nó da rede. Pretende-se atingir

um nível de automação no qual para resolver certas situações se torne mais prático inserir um novo

nó na rede do que estar a colocar fios para posicionar sensores ou actuadores. O objectivo final será

o de construir uma rede de baixo custo simples e com capacidades relativamente básicas que

estejam em constante comunicação com um sistema central (DomoBus SL) de modo a se limitarem a

serem extensões deste sistema distribuindo-o localmente, ao invés de se dar um papel mais

relevante a cada nó com elevadas capacidades de processamento para conseguir actuar

isoladamente de todos os outros nós como é a premissa do IoT (Internet of Things) onde se pretende

que cada nó da rede tenha um IP externo, acessível de fora da LAN, e a sua própria interface de

controlo.

Os módulos RF que melhor se adequam para construir o tipo de rede que se pretende são todos

os restantes (nRF24L01+, nRF905, RFM12B, RFM22B e TI CC1000) dados os seus baixos

consumos e custos reduzidos. Destes destacam-se os da Nordic, nRF24L01+ e nRF905, por

implementarem já em hardware algumas funcionalidades básicas como a detecção de erros nas

tramas ou a retransmissão automática de tramas, sob o nome ShockBurst ou Enhanced ShockBurst,

e que assim evitam sobrecarregar o microcontrolador com estas tarefas sem que o seu preço final

difira muito dos restantes. Todos os outros (RFM12B, RFM22B e CC1000) operam na mesma gama

de frequências que o nRF905 sem ganhos significativos quando comparados a este, muito devido à

implementação da tecnologia ShockBurst anteriormente referida.

Entre os módulos nRF24L01+ e nRF905 a escolha não recaí apenas sobre a banda de

frequências a utilizar. Há que ter em consideração que enquanto o nRF905 implementa a tecnologia

ShockBurst como anteriormente referido, o nRF24L01+ implementa a tecnologia Enhanced

ShockBurst que difere principalmente no sentido de que possibilita a existência de vários canais de

comunicação (no máximo 6) onde pode escutar por tramas válidas em simultâneo o que permite uma

maior flexibilidade na criação de topologias de rede. O nRF905 terá a capacidade de ter o seu

microcontrolador interno (derivado do núcleo 8051 da Intel) e o respectivo conversor analógico-digital

de 10 bits disponível para ser programado e poder executar algumas tarefas simples, mas os

recursos disponíveis não são os suficientes para que todas as funcionalidades de um módulo

controlador possam ser implementadas directamente no módulo RF. Esta funcionalidade extra seria

útil para auxiliar o microcontrolador principal, por exemplo disponibilizando o seu conversor analógico-

digital ou para implementar algumas camadas do modelo OSI directamente no módulo RF, o que de

certa forma já é o que o nRF24L01+ faz.

Todas as características que o módulo RF nRF24L01+ apresenta aliadas ao seu baixo preço

(facilmente adquirido pelo preço final de menos de 1€) foram decisivas na escolha final. Não só é o

módulo mais barato como em muitos aspectos é o mais indicado para o projecto por conseguir

implementar por si a camada física e de enlace que serão sempre necessárias e são geralmente as

mais difíceis de lidar devido às temporizações que é necessário respeitar, e por deixar a camada de

43

rede a cargo do módulo controlador que oferece uma maior liberdade na implementação da mesma, a

troco de passar algum processamento extra para o microcontrolador (quando comparado com

módulos RF mais completos). O facto de conseguir ler vários canais (ou endereços físicos) ao mesmo

tempo também é uma vantagem na implementação de várias topologias em que um nó comunique

directamente com mais do que um outro nó.

4.1.3.1 nRF24L01+

O chip nRF24L01+ (ou nRF24L01P, de plus) da Nordic Semiconductor é uma versão melhorada

do chip nRF24L01 que surgiu por volta de 2005 e que por sua vez teve origem no chip TXRX24G. É

um chip que incluí num só pacote QFN de 20 pinos (4x4 mm) uma solução completa para um

transmissor de 2.4GHz com o sintetizador RF, gestão de acesso ao meio e da camada física assim

como uma interface SPI para comunicar com o microcontrolador. Foi a melhor solução encontrada

para implementar redes de grandes dimensões sem-fios dado o seu preço extremamente baixo, o

seu reduzido consumo energético, boas velocidades de transmissão e o facto de poder implementar

em hardware a camada de enlace do modelo OSI. Opera na banda de frequência ISM de 2.4GHz que

poderá ser utilizada em todo o mundo e ainda possui uma velocidade de transmissão máxima de

2Mb/s que supera todos os módulos RF analisados na relação entre velocidade de transmissão e

consumo energético. A existência de 6 canais distintos (denominada tecnologia MultiCeiver) permite

mais facilmente construir sistemas de comunicação complexos dado que pode escutar em simultâneo

nestes 6 canais (em que cada um corresponde a um canal lógico no canal físico RF, cada um com o

seu endereço físico), o que permite nativamente a implementação de topologias em estrela (1:6).

Os chips da família nRF24 possuem todos dois modos de funcionamento: o modo directo, em que

é oferecido ao microcontrolador que opera o chip RF o completo controlo da camada física (muito

utilizado para construir scanners permitindo interagir de uma forma muito limitada com outros

protocolos na mesma banda como por exemplo Wi-Fi e Bluetooth) e um modo denominado Enhanced

ShockBurst que oferece suporte a comunicações de tramas de dados bidirecionais o que permite

libertar o microcontrolador das tarefas de rede de mais baixo nível como será detalhado mais à frente

neste capítulo. A existência deste protocolo noutros produtos que utilizam diferentes frequências

permite também aumentar a portabilidade do código para vários transmissores RF dentro dos

produtos da Nordic Semiconductor.

O chip necessita de muito pouca electrónica adicional, apenas um oscilador, resistências,

condensadores e bobines, e encontram-se disponíveis diversas implementações. A mais adoptada

utiliza uma antena plana directamente impressa no PCB (printed circuit board) mas também existem

versões que possuem pré-amplificadores e conectores SMA para permitir a ligação a antenas

externas que permitem aumentar a potência do sinal emitido (Ver Figura 4.2).

O alcance total depende muito do ambiente em que será utilizado, nomeadamente se existe um

caminho livre entre ambos os transmissores, ou no caso de existirem barreiras, o material por que

estas são compostas. Para aumentar o alcance sem proceder a trocas de hardware (diferentes

versões) ou alterações físicas (como mudar a antena) existe sempre a hipótese de configurar a

44

velocidade de transmissão para 250kb/s (denominado modo de longo alcance, ou Long Range Mode)

e configurar o rádio para utilizar a potência máxima de saída. O tamanho das tramas trocadas

influência a fiabilidade das comunicações que por sua vez influência a distância máxima a que os

dispositivos se podem encontrar pois o número de tentativas de retransmissão é finito e ao

utilizarmos tramas maiores aumentamos a probabilidade de erros de transmissão. Com velocidades

de transmissão de 250kb/s a utilizar a máxima potência é possível cobrir um máximo (anunciado) de

100 metros sem obstáculos com os módulos RF de antena plana.

Figura 4.2 – As duas versões mais comuns de módulos RF que utilizam o chip nRF24L01+. À esquerda a versão com antena impressa no PCB, à direita a versão com pré-amplificação e antena SMA

Para aumentar o alcance recorrendo a alterações de hardware pode-se utilizar o módulo com pré-

amplificação e mecanismos extra de redução de ruído com antena externa SMA que obtém um

alcance máximo (anunciado) de 1Km com caminho livre. Para aumentar esta distância máxima

podem ainda utilizar-se antenas do tipo BiQuad (ou 2-Quad) que permitem ganhos na ordem dos

11dBi (e feixes com uma largura de cerca de 50º) e que permitem alcances máximos de 2Km com

velocidades de transmissão de 250kb/s [45], o que é impressionante tendo em conta a potência que o

módulo de RF utiliza. De modo a aumentar ainda mais o alcance pode obter-se uma combinação de

uma antena BiQuad com uma antena parabólica, o que é muito utilizado para estender sinais Wi-Fi

por grandes distâncias, permitindo cobrir distâncias máximas (direccionais) de mais de 10km [46], o

que deverá ter pouca utilidade dentro de uma habitação mas poderá ser útil para a construção de

redes no exterior como por exemplo para implementar alarmes de perímetro ou automatismos

relativos à captação de água, agricultura, portões, etc.

Figura 4.3 – Antenas BiQuad (esquerda) inseridas em antenas parabólicas (direita) de modo a expandir o alcance de sinais na banda dos 2.4GHz

A principal desvantagem desta banda de frequência de 2.4GHz é que, em parte devido à sua

disponibilidade a nível global, será em princípio mais populada obrigando à partilha com outros tipos

de dispositivos que poderão gerar interferências conforme a utilização dos canais, ou seja, a posição

das diferentes portadoras dentro da banda de frequências 2.4GHz a 2.45GHz, o mesmo problema

que pode afectar a fiabilidade das ligações Wi-Fi, ZigBee ou Bluetooth. O chip nRF24L01+ pode

operar nas frequências entre 2.4GHz e 2.525GHz e o modo como esta gama de frequências é

utilizada varia consoante a velocidade de transmissão, pois esta influencia os canais que existem,

45

estes que por sua vez determinam a frequência exacta da portadora. Para velocidades de

transmissão de 250kb/s e 1Mb/s os canais ocupam uma largura de banda de 1MHz, para 2Mb/s

ocupam o dobro (2MHz). Obviamente que, para dois módulos RF nRF24L01+ distintos estarem a

comunicar, terão que estar configurados para o mesmo canal e para a mesma velocidade de

transmissão. Existem assim 126 diferentes canais RF que não se sobrepõem, ou 63 no caso de se

utilizar a velocidade de transmissão de 2Mb/s.

O pré-amplificador embutido (os módulos RF com ligação SMA podem ter ainda o seu pré-

amplificador externo antes da ligação com a antena) pode ser configurado para permitir diferentes

potências de saída. Os valores que pode assumir apresentam-se na Tabela 4.1.

Nome do nível Potência de saída RF Consumo de corrente

PA_HIGH 0 dBm 11.3 mA

PA_MED -6 dBm 9.0 mA

PA_LOW -12 dBm 7.5 mA

PA_MIN -18 dBm 7.0 mA

Tabela 4.1 – Diferentes configurações para o amplificador de potência interno

Uma das grandes vantagens deste módulo RF, como já referido, é a existência do protocolo

Enhanced ShockBurst que permite uma gestão mais eficaz das camadas de baixo nível da rede e

será apresentado de seguida. Não irá ser abordado o modo de funcionamento directo, ou sem a

utilização deste protocolo, dados os benefícios que este oferece no âmbito deste projecto. Durante a

transmissão e a recepção este protocolo trata de lidar com as tramas de dados (encapsular e

desencapsular) e de temporizar as acções ao nível do bit. Na recepção só considera um pacote

válido para adicionar à lista FIFO se o endereço e o CRC forem ambos válidos. A partir do momento

em que o microcontrolador configura os registos internos do chip para o envio ou recepção de dados

não precisa de se tomar mais nenhuma acção relacionada com a troca de dados entre os nós

envolvidos, os seus reconhecimentos (ACK) ou a integridade dos dados, apenas necessitando de

verificar o valor do registo de estado (status register) através de polling ou da utilização de

interrupções externas para saber o resultado da operação efectuada. Certos parâmetros como o

número máximo de retransmissões ou o intervalo de tempo entre retransmissões são configuráveis.

Pode também ser activado um componente do Enhanced Shockburst denominado MultiCeiver que

permite ao chip quando em modo de recepção estar a escutar até 6 diferentes canais, cada um com o

seu endereço. Todos os canais podem implementar o protocolo Enhanced Shockburst e podem ser

configurados individualmente à excepção das seguintes configurações, que são comuns a todos os

canais: configurações relativas ao tamanho do CRC, tamanho do endereço, frequência da portadora

e velocidade de transmissão. Por defeito apenas estão activos os primeiros dois canais, os restantes

quatro terão que ser explicitamente configurados. Quanto aos endereços, a escolha é livre para o

primeiro canal e para o segundo, mas os restantes quatro serão iguais ao segundo canal excepto no

Byte menos significativo, que terá obrigatoriamente de ser diferente.

A trama construída pelo protocolo, a de mais baixo nível, é constituída por 5 campos distintos (ver

Figura 4.4) que são:

46

Preâmbulo: uma sequência de bits, de duas possíveis, cuja função é a de sincronizar o

desmodulador do(s) receptor(es) para o fluxo de bits a receber. O primeiro bit do endereço

define qual dos preâmbulos a utilizar pois terão que ser garantidas transições suficientes para

estabilizar o receptor

Endereço: um identificador único para cada dispositivo nRF24L01+ (ou a cada canal do

dispositivo no caso de se utilizarem múltiplos canais) que é configurado num registo

específico. Este endereço pode ter 3, 4 ou 5 Bytes e a escolha do endereço deverá ser de tal

forma que implique algumas variações nos bits que o constituem de modo a tornar a

comunicação mais imune ao ruído

Campo de controlo: constituído pela dimensão dos dados (6 bits) em Bytes, pelo identificador

do pacote (2 bits) que permite detectar retransmissões e um bit para sinalizar a utilização ou

não do autoreconhecimento de tramas (ACK) que é configurável

Dados: onde são incluídos os dados até um máximo de 32 Bytes. Onde irá residir a camada

de rede

CRC: a verificação de redundância cíclica pode ter uma dimensão de 1 ou 2 Bytes (ou zero

se desactiva) que é calculada com base nos valores do endereço, campo de controlo e

dados.

Figura 4.4 – Formato das tramas geradas pelo protocolo Enhanced Shockburst

O uso de endereços com 5 Bytes e CRC de 2 Bytes é aconselhável para diminuir a detecção de

falsos positivos (a menos que se esteja a tentar optimizar a comunicação para conseguir a máxima

largura de banda possível) . Isto é especialmente importante quando se está a partilhar a banda dos

2.4GHz com outras tecnologias como por exemplo redes Wi-Fi. Utilizando 5 Bytes para o endereço,

ou 40 Bits, resulta em mais de 1000 biliões de endereços possíveis. No entanto, como já referido, o

endereçamento deverá ser feito de modo a ser o mais imune ao ruído possível pelo que se devem

evitar endereços com nenhuma ou apenas uma transição entre níveis lógicos, para evitar serem

confundidos com ruído ou com outros endereços. Mesmo considerando que nem todo o espaço de

endereçamento deverá ser utilizado, na prática não existem limites impostos ao número de endereços

físicos que podem existir num determinado canal RF.

Considerando que o mínimo número de Bytes de informação de controlo a ser agregada aos

dados são 9 Bytes (preâmbulo de 1 Byte, endereço de 5 Bytes, controlo de aproximadamente 1 Byte

e 2 Bytes para CRC), que se transporta o máximo de dados possível por pacote (32 Bytes), que não

existem atrasos entre tramas, e ainda que numa situação ideal as tramas são todos entregues com

sucesso sem qualquer retransmissão temos uma utilização de

32

32 + 9= 78%

Fórmula 1 – Utilização efectiva dos dados ignorando os Bytes de controlo

47

O que corresponde a uma velocidade de transmissão máxima de 1.56Mb/s, nas situações ideais

referidas. Para uma utilização como a planeada, que consiste na troca de pequenos segmentos de

dados esporádica, dada a relação entre a largura de banda disponível e a distância máxima que os

dados podem percorrer, compensa sacrificar a primeira pela última e obter maiores distâncias a custo

de uma redução para 250kb/s que na realidade, seguindo a mesma lógica anterior, se reduziriam no

melhor dos casos a 195kb/s.

Os módulos disponíveis no mercado que utilizam o chip nRF24L01+ têm todos uma interface com

8 pinos, 4 dos quais destinados à comunicação SPI (com uma frequência de relógio máxima de

8MHz), 1 para sinalizar interrupções, 1 chip-enable e 2 de alimentação. Todos os pinos, excepto os

de alimentação, são tolerantes a tensões de 5V o que é de extrema utilidade num sistema que opera

a 3.3V pois simplifica o seu uso por microcontroladores que funcionem a 5V pondo de parte a

necessidade de proceder a transformações dos níveis de lógica TTL (transistor–transistor logic). A

tensão de alimentação terá que ser entre 1.9 e 3.6V e o pino IRQ (interrupt request) é o único cuja

utilização não é obrigatória e poderá ser configurado para ser activo em qualquer combinação dos

seguintes eventos: existe pelo menos um pacote para ser lido, os dados foram enviados e entregues

ou o número máximo de retransmissões foi atingido e os dados não foram entregues.

Todas as configurações, acções de controlo ou leitura de valores do chip são feitas através de

registos acedidos através da interface SPI. O estado do pino chip-enable permite ao chip actuar

perante essas configurações.

4.2 Arquitectura do módulo controlador

A arquitectura proposta para o módulo controlador divide-se em quatro blocos lógicos principais:

Rede, Sistema, Propriedades e Aplicações. Estes blocos interagem entre si através de interfaces bem

definidas de modo a conseguir compartimentar as diferentes funcionalidades do módulo controlador

facilitando possíveis alterações que poderão surgir de futuro.

Figura 4.5 – Arquitectura do módulo controlador

No bloco lógico denominado Rede encontram-se apenas as rotinas de comunicação com o

módulo de rede. Pretende-se definir uma interface genérica para que seja simples trocar o módulo RF

proposto por um outro bastando apenas fazer com que o novo módulo de rede siga a mesma

interface de modo a poder ser utilizado de uma forma transparente pelo bloco lógico Sistema.

O bloco lógico denominado Propriedades é responsável por alocar e gerir a memória necessária

para guardar as propriedades. Apresentará uma interface com funções básicas de pesquisa,

inserção, remoção e actualização de valores. Assim será possível de futuro alterar o tipo de memória

48

onde se guardam as propriedades assim como o meio de comunicação com a mesma no caso de se

optarem por outros dispositivos de armazenamento. Será possível também fazer melhoramentos

relacionados por exemplo com a procura dos dados ou com a compactação dos mesmos sem ser

necessário alterar as restantes funcionalidades do controlador desde que se respeite novamente a

interface definida.

Os blocos lógicos denominados de App (de Aplicação) representam objectos alocados em

memória que competem entre si pelos recursos do microcontrolador de modo a poderem realizar o

trabalho para os quais estão configurados. A cada Aplicação poderão estar ligados vários dispositivos

através dos portos de entrada ou saída do microcontrolador e as Aplicações (denominadas NApps no

contexto do DomoBus) deverão ser construídas utilizando a pequena API (Application Programming

Interface) que os restantes blocos lógicos fornecem como base, permitindo assim que cada uma

consiga elaborar funções mais complexas sem necessidade de repetir código entre as mesmas que

implemente funcionalidades elementares. Ao separar cada Aplicação como uma classe, permite-se

não só compartimentar melhor o sistema de modo a facilitar futuras alterações ou mesmo novas

aplicações de raiz, como permite que estas classes herdem certas particularidades de uma classe

mãe, de modo a conter nesta última todo o código que é comum a todas as aplicações.

Por fim, o bloco lógico denominado Sistema é o responsável por unir todos os outros, alocando os

recursos necessários às várias aplicações e implementado um ambiente multitarefa onde é dado

controlo sobre o microcontrolador, propriedades e interface de rede a cada Aplicação recorrendo a

um simples processo de escalonamento como por exemplo o Round-Robin. É responsável ainda pela

gestão dos temporizadores, gestão de interrupções e pela gestão das configurações.

Na prática os módulos controladores são pequenos sistemas embebidos com um microcontrolador

como parte central do módulo. Estes controladores pretendem-se flexíveis, de modo a poderem

assumir diferentes funcionalidades não especificadas originalmente, ou seja, poderem assumir

diferentes papéis na rede em que se inserem através de meras configurações ao mesmo tempo que

se encontram dimensionados para terem um baixo custo e consumos reduzidos. De modo a permitir

esta flexibilidade é necessário proceder a uma modularização das suas componentes, de modo a que

seja fácil e intuitivo adicionar ou alterar módulos de dispositivos de sensores ou actuadores e

proceder à configuração do módulo controlador para conseguir lidar com as suas novas

funcionalidades. Esta configuração pretende-se simples e sem necessidade de recorrer a

reprogramações da memória do microcontrolador ou de recorrer a computadores ou outro tipo de

dispositivos que tenham que se ligar a cada módulo controlador a configurar. Todas as configurações

pretendem-se feitas pelo canal de comunicação único a cada módulo controlador, o que o liga aos

restantes controladores e por conseguinte à rede DomoBus. Assim é de extrema importância que a

rede seja fiável e que se minimize ao máximo a probabilidade de serem recebidos dados incorrectos,

provenientes de ruído ou de outro tipo de situações erróneas, e que a rede ofereça um meio seguro

de comunicação de modo a minimizar a exposição dos módulos controladores a ataques exteriores

que poderiam no limite levar a perdas materiais conforme os actuadores presentes nos mesmos.

49

Figura 4.6 – Modularização do módulo controlador

Dada a capacidade de que os módulos controladores terão de ter para lidar com diferentes

dispositivos e diferentes combinações entre estes, são esperadas capacidades de processamento

multitarefa de modo a distribuir os recursos computacionais de uma forma equitativa pelos diversos

módulos de dispositivos instalados. Esta abordagem é significativamente mais económica que as

adoptadas por outras tecnologias domóticas pois permite que um único módulo controle mais de uma

dezena de dispositivos assim como não restringe à partida – de um número fixo de dispositivos

disponíveis – os dispositivos a serem controlados, tornando-os mais práticos para serem aplicados no

contexto de habitações super-automatizadas.

4.3 Microcontrolador

O microcontrolador é o núcleo do controlador domótico e deverá ser juntamente com o módulo RF

o componente que mais planeamento exige pois é necessário manter o equilibro entre capacidade de

processamento, memória disponível, funcionalidades e preço final. Consideraram-se as principais

marcas no mercado como a Intel, Microchip, Atmel ou a Texas Instruments. A pesquisa começou

naturalmente por uma listagem de requisitos que se detalha de seguida:

Microcontrolador de 8 bits pois para as tarefas que irá executar não será preciso maior

precisão ajudando assim a manter um baixo custo. Na frequência do sinal de relógio existe

uma folga maior pois o controlador domótico não será sensível a atrasos na ordem das

dezenas de milissegundos, no entanto será benéfico usufruir da velocidade de comunicação

máxima possível com o módulo RF (relógio SPI a 8MHz)

Uma quantidade considerável de memória de programa (pelo menos 16KiB) pois quanto

maior a memória maiores serão as possibilidades de expandir as funcionalidades do

controlador

Pelo menos 2KiB de RAM pelos motivos apresentados anteriormente. Terá que conseguir

alocar os recursos necessários para lidar com os diversos modos de funcionamento que

poderão ser configurados. Uma arquitectura dinâmica e configurável terá o seu preço em

memória RAM necessária.

Oferecer suporte em hardware ao protocolo de comunicação SPI de modo a evitar

sobrecarregar o microprocessador com técnicas de bit-banging

Possuir um conversor Analógico-Digital (ADC) de pelo menos 8 bits para evitar ter que

adquirir um separadamente. Este é fundamental para lidar com sensores analógicos

50

Um número considerável de portos de entrada/saída, no mínimo 10, para permitir uma

expansão relevante das funcionalidades do controlador ao interagir com um maior número de

dispositivos (sensores ou actuadores)

Possuir pelo menos 2 saídas PWM para permitir, por exemplo, o controlo da luminosidade ou

de velocidade de motores eléctricos

Possuir pelo menos um temporizador de 8 bits que será responsável por manter o controlo da

passagem do tempo, permitindo implementar um mecanismo de relógio relativo pelo qual

todo o controlador se rege evitando assim a necessidade de adquirir um circuito de relógio.

Existem ainda requisitos que embora não sejam obrigatórios para a implementação da

arquitectura planeada são desejáveis de se ter, como a existência de memória persistente de leitura e

escrita no próprio chip (por exemplo memória EEPROM) de modo a poder guardar as definições

configuradas pelo utilizador, ter um baixo consumo e possuir modos de poupança de energia

(qualquer poupança terá um impacto significativo dado o elevado número de controladores

existentes), possuir mecanismos de tolerância a falhas (nomeadamente temporizador watchdog),

possuir capacidade para detectar pelo menos uma interrupção externa de modo a permitir uma

utilização mais eficiente do módulo RF, e que exista em encapsulamentos próprios para um

manuseamento e prototipagem mais simples (por exemplo DIP, ou dual in-line package).

Seria demasiado extenso fazer uma comparação entre os microcontroladores existentes para

cada uma das marcas referidas pois cada uma delas tem pelo menos uma família de

microcontroladores que satisfaz os requisitos apresentados. Assim irão apresentar-se apenas alguns

dos microcontroladores analisados e os motivos que conduziram à escolha final.

A Texas Instruments possui variantes do TMS370 que se adaptam, nomeadamente o

TMS370C256A. No entanto não é possível obter encapsulamentos DIP para permitir um

manuseamento mais fácil assim como é difícil obter estes microcontroladores em pequenas

quantidades. A Intel possui inúmeras configurações nos microcontroladores da conhecida família

8051 mas não se encontrou nenhum que suporte nativamente a memória necessária (apenas a

capacidade de a endereçar) sendo necessário recorrer a módulos externos de memória. A aquisição

destes microcontroladores em pequenas quantidades também é difícil e não oferece um preço

competitivo com os restantes analisados. A Microchip dentro das famílias que possui de

microcontroladores de 8 bits apenas a família PIC18 possui microcontroladores que satisfazem os

requisitos, existindo muitos modelos à escolha dentro desta família. Por fim, a Atmel possui uma

família de microcontroladores de 8 bits denominada ATMega que possui inúmeros microcontroladores

que satisfazem os requisitos impostos. Assim a decisão recaiu, como quase sempre no contexto de

implementação de sistemas embebidos a um nível amador e em pequenas quantidades, entre a

Microchip e a Atmel, mais especificamente entre a família PIC18 e ATMega. No geral conseguem-se

encontrar modelos idênticos em todas as variantes pelo que o desempate não foi feito através de

funcionalidades. Os principais factores que influenciaram a decisão a favor da Atmel foram os

seguintes:

51

O ambiente de desenvolvimento superior, na medida em que utiliza o GCC em vez de vários

compiladores, cada um com as suas peculiaridades, todo o software é livre de quaisquer

custos o que se reflecte num melhor apoio aos utilizadores. Permite a programação

recorrendo a código C padrão o que permite utilizar as bibliotecas padrão do GCC o que

facilita a portabilidade do código (importante para desenvolver código para os módulos

controladores e módulos supervisores)

A rápida expansão que nos últimos anos a plataforma Arduino têm tido (todas as variantes

utilizam microcontroladores da Atmel) o que permitiu essencialmente obter preços mais

baixos através da elevada oferta existente, e inúmeras bibliotecas disponíveis para os mais

variados sensores e actuadores, feitas por utilizadores comuns que devido ao facto de as

publicarem como código aberto (open source) faz com que resultem em bibliotecas estáveis e

de qualidade que facilitam muito a implementação dos mais diversos módulos de dispositivos,

o que permite facilmente expandir as funcionalidades destes controladores domóticos no

futuro

Dentro da família ATMega acabou-se por escolher o microcontrolador ATMega328P-PU por ser o

que apresentou um melhor equilíbrio entre as funcionalidades requeridas e preço, o que será

apresentado na forma de tabela (ver Tabela 4.2).

Requisito ATMega328P-PU

Número de bits do barramento 8 bits 8 bits

Frequência do relógio - 8 a 20MHz

Memória de programa (FLASH) ≥ 16 KiB 32 KiB

Memória RAM (SRAM) ≥ 2KiB 2 KiB

Protocolos comunicação em hardware SPI / I2C SPI, I2C, USART

Conversor analógico-digital ≥ 8 bits 10 bits

Número de portas E/S ≥ 10 23

Número portas com suporte PWM ≥ 2 6

Temporizadores ≥ 1 3

Memória persistente (EEPROM) ≥ 128 B 1024 B

Modos de poupança de energia (existir) 6 modos de poupança de energia

Temporizador watchdog (existir) Sim, com oscilador próprio

Número de interrupções externas ≥ 1 2

Encapsulamento DIP (existir) PDIP28

Preço unitário (baixo) 1.64€

Tabela 4.2 - Comparação entre os requisitos e o microcontrolador ATMega328P . Preço retirado da loja Futurlec

De notar que para se ter um sistema compatível com a plataforma Arduino de modo a se poderem

utilizar bibliotecas desenvolvidas para o mesmo e assim usufruir de todo o ecossistema criado à volta

desta plataforma, é necessário incluir bibliotecas próprias que no fundo encapsulam funções já

existentes (da biblioteca avr-libc) de um modo mais simples (funcionando como uma API) o que trás

alguma sobrecarga em termos de memória utilizada e tempo de processamento, o que se considerou

negligenciável perante os benefícios de ter à partida bibliotecas convenientes para praticamente

todos os tipos de sensores e actuadores mais comuns. Este é um ponto-chave que permite oferecer o

nível de modularização desejado nos controladores domóticos sem ter que desenvolver de raiz todas

52

as rotinas necessárias para lidar com o respectivo hardware. No entanto é preciso ter atenção para

não quebrar a compatibilidade dado que são assumidos alguns pressupostos por parte de diversas

bibliotecas, como configurações dos fusíveis do microcontrolador ou configurações específicas de

certas funcionalidades (como temporizadores), enquanto outras funcionalidades poderão ser

removidas se não se justificarem (como o bootloader por exemplo). Outra vantagem é a de se poder

utilizarem as funções da API incluídas de modo a facilitar a portabilidade do código desenvolvido,

utilizando apenas quando necessário acesso directo a registos específicos do ATMega328P-PU.

Desde modo poderá manter-se grande parte do código desenvolvido para este projecto numa

migração para outro microcontrolador suportado pela plataforma Arduino bastando alterar a

respectiva API.

4.4 Módulos do controlador

A modularização das funcionalidades de um controlador foi a solução encontrada para permitir a

existência de um módulo controlador genérico, ou seja, um controlador único para qualquer que seja

a sua função na rede DomoBus, e para deste modo reduzir os custos de implementação. Através da

configuração por módulos o utilizador final poderá configurar cada controlador para o fim específico

que deseja sem necessitar de adquirir funcionalidades extra que poderá acabar por não utilizar. O

utilizador poderá também ter a liberdade de a qualquer altura alterar a sua rede DomoBus DWCN e

poder reconfigurar ou reutilizar módulos de dispositivos e módulos controladores.

4.4.1 Módulos de dispositivos

Os diferentes módulos de dispositivos que disponibilizam os sensores e actuadores que permitem

aos módulos controladores interagirem com o ambiente que os rodeia podem ser categorizados

através das suas ligações ao microcontrolador (analógicos, digitais ou PWM) ou através das suas

funcionalidades. Neste último caso interessa dividir os módulos controladores em dois grupos

principais: dispositivos básicos e extras.

Os dispositivos básicos não necessitam de nenhum tratamento especial por parte do

microcontrolador, ou seja, são vistos como simples leituras ou escritas analógicas ou digitais. O

módulo fornece o hardware necessário para implementar a funcionalidade desejada tendo em conta

as limitações do microcontrolador. Como exemplos de dispositivos básicos temos relés, interruptores

ou sensores analógicos como fotoresistências ou termorresistências. A conversão de valores para

unidades físicas específicas ou para mapear os valores para outros intervalos ficará a cargo do

supervisor mediante as configurações para o tipo de dispositivo criado.

Os dispositivos extra são geralmente mais complexos e necessitam de código adicional por parte

do microcontrolador para – por exemplo – temporizar acções ou pré-interpretar os dados gerados

antes de os comunicar ao supervisor. Este tipo de dispositivos usualmente necessita da utilização de

bibliotecas que permitem fazer a interface com o dispositivo. Como exemplos deste tipo de

dispositivos poderemos ter protocolos dedicados (por exemplo o OneWire da Dallas), interacção com

outros dispositivos digitais ou dispositivos que necessitem de mais de um porto e por isso precisam

de código especialmente adaptado à sua funcionalidade.

53

De modo a que todos os dispositivos possam ser utilizados nos respectivos portos é necessário

desenvolver uma interface física fixa que sirva para todos os portos e dispositivos. Para diferenciar

dispositivos com necessidade especiais, como o caso de dispositivos que necessitem de portos PWM

ou acesso ao ADC, poderão ser utilizados códigos de cores ou simbólicos para especificar que o

dispositivo em causa só poderá funcionar quando instalado de uma certa forma.

4.4.2 Módulo de alimentação

O microcontrolador apresentado anteriormente (Atmel ATMega328P) poderá ser alimentado num

intervalo relativamente grande de tensões (entre 1.8 e 5.5V). A tensão da alimentação irá definir não

só as frequências de relógio que este pode atingir (ver Figura 4.7) como irá definir o consumo total do

microcontrolador.

Figura 4.7 – Relação entre tensão de alimentação do ATMega328P e frequências de relógio a que pode operar

Optou-se por utilizar uma alimentação de 5V justificada pelo facto de ser compatível com a maioria

dos módulos de dispositivos que utilizam uma lógica TTL de 5V. Reduzir a tensão de alimentação

para 3.3V, a tensão utilizada pelo módulo RF, iria diminuir os consumos e seria portanto uma

vantagem, mas no entanto limitaria muito o tipo de dispositivos com que poderia interagir. Utilizar uma

tensão de 5V também facilita bastante a alimentação do módulo controlador através da RDEE devido

à ampla utilização de transformadores com interface USB existentes e o preço e tamanho final que

estes apresentam. É possível obter por menos de 1€ adaptadores de 230V alternos para 5V

contínuos que suportam uma corrente máxima de 1A (ver Figura 4.8, lado esquerdo).

Figura 4.8 – Adaptadores de 230VAC para 5VDC

Ter a alimentação dos módulos controladores com uma interface USB é uma vantagem não só

pelas vastas opções em termos de adaptadores como pela utilização de cabos USB que são hoje em

dia adoptados por vários equipamentos portáteis sendo fáceis de encontrar a custos relativamente

baixos. Por todos estes motivos a alimentação por USB é vista como o padrão para o módulo de

alimentação dos controladores. No entanto, dado que a alimentação do módulo controlador será feita

por um módulo destacável, nada impede o desenvolvimento de diferentes tipos de alimentações para

que um mesmo módulo controlador possa ser alimentado por um adaptador USB, ou um adaptador

com ficha de alimentação DC, baterias ou até mesmo um sistema que inclua um painel solar para

54

utilizações exteriores à habitação. Mediante o número de módulos de alimentação disponíveis caberá

ao utilizador final utilizar o que melhor se adaptar à sua situação sendo que não é necessário fazer

alterações de hardware ou software ao módulo controlador para se alterar o tipo de alimentação

deste. Apenas será necessário trocar os respectivos módulos de alimentação, estes que terão no

entanto que ser sempre acompanhados pelo dispositivo que lhes fornece energia para o qual são

dimensionados.

Figura 4.9 – Possíveis alternativas para módulos de alimentação

Em todos os casos, com especial atenção aos casos em que a alimentação é feita através de

pilhas, bateria ou energias renováveis, é sempre possível desenvolver um módulo de dispositivo que

utilize uma porta analógica do microcontrolador e recorra a hardware adicional (como por exemplo um

simples divisor de tensão) para monitorizar a tensão a que está a ser alimentado. Isto permite que o

supervisor possa ser programado para tomar acções com base no estado da tensão de alimentação.

Quanto à frequência do sinal de relógio, para a tensão de alimentação de 5V escolhida este

poderá assumir qualquer dos valores disponíveis entre 4MHz e 20MHz. O ATMega328P possui um

oscilador interno de 8MHz (que poderá operar também a 1MHz) que não foi utilizado pela sua fraca

precisão (10% que poderão ser reduzidos mediante calibrações feitas no registo OSCCAL), a sua

sensibilidade à temperatura que pode oscilar severamente consoante a utilização dos portos do

microcontrolador e ainda de modo a utilizar a frequência máxima possível nas comunicações SPI com

o módulo RF (limite de 8 MHz para a frequência SCK imposto pelo chip nRF24L01+). O facto de os

consumos do microcontrolador, comparando a utilização com o oscilador interno e com um externo,

não terem uma diferença significativa (ambos em torno de 5,5mA) e de que o consumo de corrente

quando a operar a 16MHz é menor que o dobro do consumo quando a operar a 8MHz justificaram a

opção por um oscilador de quartzo de 16MHz. Embora a corrente consumida seja praticamente o

dobro, a velocidade de processamento também duplica assim como se pode utilizar mais

eficientemente o módulo RF (na sua frequência máxima) e mantêm-se um consumo reduzido, abaixo

dos 50mW.

55

4.4.3 Módulo de rede

Em termos de software está planeado um isolamento do código relativo ao módulo RF de modo a

poder facilmente utilizar-se o mesmo módulo controlador com outro módulo de comunicação. No

entanto é mais difícil padronizar a interface de ligação física ao microcontrolador dado que é

necessário assumir alguns pressupostos, como por exemplo o protocolo de comunicação entre o

microcontrolador e o respectivo módulo de rede assim como a potência máxima que o módulo de

rede poderá consumir. Ainda se acrescenta a necessidade, quando a posição dos pinos não é a

mesma, de uma camada de hardware entre o módulo controlador e o módulo de rede que sirva

apenas para fazer a conversão da posição dos pinos de modo a ser compatível com o módulo de

rede utilizado. Adicionalmente, o módulo de rede é o único tipo de módulo dos três apresentados que

não poderá ser trocado por outro sem se proceder a uma reprogramação do microcontrolador.

4.5 Módulo Gateway

O módulo gateway é responsável por interligar a rede de controlo com a respectiva SLAG que a

gere. No caso específico de uma rede DWCN o módulo gateway, do ponto de vista da rede de

controlo, vai ser a raiz da árvore, o nó onde todas as comunicações que são trocadas entre a rede de

controladores e a SLAG estrangulam. Dado que este projecto terá que se conjugar com outros

sistemas dentro do DomoBus, e que muito possivelmente no futuro a SLAG aqui referida poderá estar

alojada num módulo de supervisão com outras SLA, de modo a não se introduzirem limitações

excessivas no hardware que poderá ser utilizado para alojar a SLAG, entre outros detalhes, foram

considerados vários protocolos de comunicação para o módulo de supervisão comunicar com o

módulo gateway, cada um com as suas vantagens e desvantagens.

No caso em que a rede CL se encontra no mesmo lugar físico que módulo de supervisão, o

módulo gateway poderá ser um periférico ligado directamente a uma das portas do dispositivo (como

por exemplo portas USB). Esta situação deverá ser mais comum em pequenas redes onde existe um

número reduzido de diferentes redes CL e os dispositivos que operam no SL se encontram próximos

dos dispositivos que operam no CL.

Figura 4.10 - Módulos gateway a operarem como periféricos do módulo supervisor

No caso em que o módulo de supervisão que aloja a SLAG (ou múltiplas SLAG) é responsável por

gerir redes CL que se podem encontrar dispersas por uma área mais vasta, os módulos gateway

poderão ter a interface primária associada a um canal de comunicação ethernet onde possa ser

utilizado o protocolo UDP (IP) para comunicar com a respectiva SLAG. Neste caso, a existência de

diferentes redes CL não implica que tenha de existir um módulo de supervisão (que normalmente são

56

dispositivos mais dispendiosos) perto de cada rede CL pois essa função poderá ser delegada a um

pequeno dispositivo (o módulo gateway ethernet) que tratará apenas de fornecer a interface entre os

dois meios, servindo de ponte de ligação entre a SLAG e os dispositivos da rede CL. No caso limite,

em que a rede CL esteja muito distante do módulo de supervisão que aloja a SLAG, poderá ser

utilizada a Internet como meio de transporte intermediário recorrendo à utilização de VPN e

equipamento de rede adequado.

Figura 4.11 - Módulos gateway a operar com ligação ethernet

A existência destas duas diferentes vertentes pretende minimizar as limitações nas escolhas que

podem ser feitas a montante (do lado SL) no sistema DomoBus para lidar com redes DWCN e

permite adaptar melhor o sistema às necessidades do utilizador resultando num maior leque de

escolhas que poderá reduzir o custo de implementação do sistema. Considerando uma habitação

super-automatizada onde existem inúmeras redes CL, num extremo temos a centralização de todo o

SL num único módulo supervisor e a dispersão das redes CL por módulos gateway ethernet a favor

de uma implementação de mais baixo custo, no outro extremo temos um módulo supervisor por cada

rede CL para favorecer a robustez da rede ao oferecer um maior grau redundância.

4.6 SLAG

A SLAG será a componente de mais alto-nível desenvolvida e que deverá estar encarregue de

gerir as ligações entre SLA e controladores da rede DWCN que estão a seu cargo, fazer a tradução

entre tramas SL e CL (em ambos os sentidos) e de aplicar os algoritmos que não necessitam de

intervenção do utilizador (como respostas automáticas a certos tipos de tramas de controlo).

Adicionalmente terá que se especificar pelo menos um módulo supervisor de testes que aloje esta

SLAG desenvolvida, módulo este que ainda irá ser utilizado para injectar e capturar dados sob a

forma de tramas SL no contexto de depuração e testes ao sistema completo.

Como já referido anteriormente, um dos objectivos no desenvolvimento da SLAG (e do respectivo

módulo gateway) é o de minimizarem as limitações impostas na forma como pode ser construído o

SL genérico do DomoBus uma vez que não se define à partida o tipo de dispositivos que

correspondem aos módulos supervisores (não se define arquitectura do microprocessador, tipo de

protocolos ou portas que suporta) e de modo a não introduzir restrições noutras componentes do

sistema DomoBus fora do âmbito deste projecto.

57

5 Implementação

Neste capítulo serão discutidos os aspectos práticos da implementação do que foi descrito no

capítulo anterior recorrendo a algoritmos e hardware específico de modo a implementar o módulo de

controlo, o módulo gateway e a respectiva SLAG.

5.1 Módulo de controlo

5.1.1 Software

Um dos principais desafios ao implementar uma arquitectura que se pretende dinâmica num

dispositivo muito limitado em termos de memória e sem sistema operativo, ou seja, sem mecanismos

de gestão de memória implementados, é o de utilizar e acima de tudo alocar eficientemente a

memória. Ao lidar com um vasto leque de modos de operação como é o caso, foi impossível

implementar uma gestão eficiente da memória sem utilizar alocações de memória dinâmicas. Estas

alocações dinâmicas deverão ser feitas em momentos especiais de modo a evitar a fragmentação da

memória dado que nestes pequenos microcontroladores a memória só é libertada se estiver contígua

com o apontador para a posição da heap, ou seja, não é possível libertar memória que se encontre

no meio de blocos de memória alocada sem proceder a uma reorganização manual de toda a

memória. Estes factores fazem com que seja muito má prática alocar e libertar memória no decorrer

da execução normal do programa excepto em situações muito específicas, e assim determinaram

uma importante característica do programa implementado: a memória alocada é feita somente no

início da execução do programa, antes deste iniciar o seu ciclo principal de execução. A quantidade

de memória alocada depende das configurações do controlador que são carregadas da memória

EEPROM e que definem o comportamento do mesmo. Isto implica que, ao reconfigurar o controlador

(por exemplo adicionar um dispositivo que corresponde a uma NApp que ainda não têm nenhum

dispositivo associado) seja necessário reiniciar o mesmo para que o objecto relativo à NApp seja

carregado em memória. Dada a hipótese de reiniciar o controlador remotamente, esta característica

não precisa de atenção especial por parte do utilizador, desde que seja propriamente tratada pelo SL

quando recebe novas configurações para aplicar aos módulos controladores. No entanto não deixa

de ser uma importante característica da arquitectura adoptada para evitar que a pilha de execução e

a heap colidam e forcem um reiniciar do controlador.

Por outro lado, as configurações não são automaticamente gravadas na memória EEPROM

quando são alteradas. À semelhança do comando para reiniciar um nó, existe outro para gravar as

configurações feitas (presentes na memória RAM) para a memória EEPROM. Esta abordagem

permite que o utilizador (ou o SL automaticamente) definam um estado considerado seguro para o

módulo controlador, estado este que é carregado sempre que o nó é reiniciado. Deu-se preferência a

esta abordagem em detrimento de gravar sempre todas as alterações feitas pois quando um

controlador volta a ser ligado não sabe quanto tempo passou desligado, e pode não fazer sentido

voltar ao último estado que tinha configurado. Isto faz especial sentido não só quando estão em jogo

dispositivos que poderão estar a consumir energia desnecessariamente (por exemplo lâmpadas) mas

também quando um módulo controlador lida com aspectos de segurança como fechaduras ou

58

alarmes. Assim, aquando da instalação de um novo módulo controlador os primeiros passos após a

configuração física do mesmo (instalação dos módulos de alimentação, de rede e de dispositivos)

deverão ser as configurações base do módulo controlador (o denominado estado seguro) seguidas

do comando de guardar na memória EEPROM.

Como referido anteriormente, uma das vantagens que se pretendia era a da compatibilidade com

a plataforma Arduino, de modo a se poder utilizar o vasto repositório de bibliotecas que se encontram

disponíveis para lidar com os mais variados tipos de sensores e actuadores. De modo a não quebrar

esta compatibilidade e poder de futuro actualizar as bibliotecas utilizadas sem ter que as modificar (ou

até mesmo utilizar novas bibliotecas) configurou-se o temporizador 0 com as mesmas configurações

(prescaler) nativas do Arduino dado que este temporizador é utilizado para sinalizar a passagem de

tempo (em milissegundos) através de uma variável global e é utilizado por diversas bibliotecas. Este

mecanismo também acabou por ser usado para tarefas relativas à temporização das diversas

aplicações (NApps). As bibliotecas utilizadas, por inteiro ou parcialmente, encontram-se descritas no

Anexo A1 com os devidos créditos para os seus autores.

5.1.1.1 Sistema

O sistema (ou NApp0) é onde se incluí todo o código que gere e interliga as restantes

componentes da arquitectura: rede, propriedades e aplicações. Este é responsável pelo ciclo principal

de execução onde são chamadas as rotinas da interface de rede e são chamados os objectos das

NApps que estão carregados em memória. Cabe também à NApp0 lidar com as interrupções,

métodos de poupança de energia, temporizadores watchdog local e de rede, configurações globais e

respectivas interacções com a memória EEPROM, e ainda gerir a ligação entre portos físicos do

microcontrolador e aplicações.

Quanto às interrupções utilizadas poderão existir três tipos principais:

A interrupção gerada pelo temporizador 0 cuja função é a de contabilizar o número de

microssegundos e milissegundos de modo a poder actualizar a respectiva variável global e

poder ser utilizado por funções nativas ao Arduino como millis, micros e delay.

A interrupção externa gerada pelo módulo RF para sinalizar uma mudança no seu registo de

estado. Esta interrupção não está por defeito a ser utilizada de modo a libertar um porto do

microcontrolador. No entanto em muitas utilizações que não requeiram um constante

processamento por parte do módulo controlador, poderá adaptar-se as definições

RF24_INTERRUPT e RF24_INTERRUPT_PIN para a utilização do porto PD2 ou PD3 de

modo a favorecer uma melhor gestão energética do módulo controlador, assim como permite

maior flexibilidade na utilização das técnicas de poupança de energia. Aconselha-se a

utilização desta opção sempre que não se pretenda utilizar todos os 15 portos do

microcontrolador.

Interrupções geradas pelo temporizador 1 ou 2 que poderão ser livremente configuradas

pelas NApps desde que não colidam. De momento apenas se desenvolveu uma NApp que

utilize: a responsável pela leitura de sinais infravermelhos.

59

A variável global que aloca o contador de milissegundos possui 32 bits (sem utilização de sinal) o

que permite atingir o valor máximo de pouco mais de 49 dias (49 dias 17 horas 2 minutos e 24

segundos) antes de ocorrer um overflow e retornar a zero. Esta passagem a zero não afectará o

funcionamento do módulo controlador e das tarefas agendadas devido à utilização de variáveis sem

sinal, o que fará com que o cálculo da diferença entre o contador actual de milissegundos e o valor

esperado seja sempre coerente, mesmo quando ocorre um overflow. As temporizações das NApps

(tempo de atraso até iniciar e tempo de espera até repetir), temporização das mensagens temporárias

para a SLAG (denominadas Network Keep Alive) e tempo máximo sem contactar a respectiva SLAG

até que entre no modo de auto-regeneração da rede, estão também limitadas a este valor máximo.

Quanto aos métodos de poupança de energia no ATMega328P, existem 6 métodos distintos de

poupar energia sendo que quanto mais profundo é o método de poupança de energia, mais

subsistemas do microcontrolador se encontrarão desactivados e maior será o tempo que o

microcontrolador levará até repor o seu normal funcionamento. Dada a dependência de todo o

sistema nas temporizações geradas pelo temporizador 0 (que mantém a contagem de

milissegundos), desenvolveu-se um algoritmo que utiliza o temporizador watchdog (que está sempre

activo) para sinalizar a passagem de tempo quando o microcontrolador está em modos de poupança

de energia que desabilitam o oscilador do temporizador 0, de modo a não comprometer o

funcionamento das NApps temporizadas. Para a utilização dos modos de poupança de energia não

comprometer o correcto funcionamento do módulo controlador, deverá ter-se sempre o módulo de

rede a operar utilizando uma interrupção externa do microcontrolador. Existem duas funcionalidades

distintas implementadas que dão acesso aos modos de poupança de energia do microcontrolador:

O acesso remoto directo ao registo PRR (Power Reduction Register) que permite activar ou

desactivar componentes do microcontrolador como o temporizador 1, temporizador 2, USART

ou ADC se estes não forem utilizados. Uma tarefa que caberá ao SL (SLUI) deduzir a partir

das configurações fornecidas pelo utilizador para um dado módulo controlador, dada a

complexidade da tarefa perante todas as combinações possíveis de modos como um

controlador poderá estar a operar

A capacidade de activar o modo adormecido, que fará com que no final de correr todas as

NApps seja chamada uma rotina que verifica todas as NApps a correrem no próximo ciclo, e

no caso de nenhuma estar continuamente activa (ou seja, todas se encontram temporizadas)

calcula o tempo máximo que pode adormecer tendo em conta a próxima NApp a iniciar e as

temporizações pré-definidas que poderá configurar no temporizador watchdog para acordar o

microcontrolador. Quando o módulo controlador utiliza modos de poupança de energia, o

temporizador watchdog está continuamente a ser reconfigurado: no modo adormecido

encontra-se configurado para gerar uma interrupção na qual actualiza o contador de

milissegundos, no modo activo está configurado para reiniciar o microcontrolador se o

contador não for reiniciado.

Em termos de poupança de energia relativamente ao módulo RF não foram tomados nenhuns

passos devido a ser o único canal de comunicação de cada módulo controlador e por isso ser uma

60

acção irreversível (teria sempre que se esperar o tempo pré-determinado para o módulo RF voltar a

estar activo). Adicionalmente apenas as folhas da árvore poderiam entrar neste modo sem sacrificar o

tráfego de dados uma vez que os restantes nós da árvore são responsáveis por encaminhar

mensagens entre os nós directamente ligados e que por esse motivo não conseguem prever quando

precisarão de estar activos. Os consumos reduzidos do módulo de rede não levaram a que se

contemplassem quaisquer compromissos no sentido de reduzir os consumos a troco de sacrificar a

prontidão de cada nó da rede para encaminhar mensagens.

Em relação aos mecanismos de tolerância a falhas implementados estes assentam em duas

vertentes, a local e a de rede. A nível local encontra-se configurado o temporizador watchdog para

supervisionar o funcionamento do módulo controlador e garantir que este não se desvia do fluxo do

programa principal desejado. O valor temporal do temporizador poderá ser configurado remotamente

e está com o valor por defeito de 4 segundos, de modo a garantir que no limite máximo, quando todos

os dispositivos se encontram na mesma NApp (aquela que mais tempo necessita, que é esperado

que seja na fase de inicialização) esta tenha tempo para inicializar todos os dispositivos sem que o

temporizador atinja o seu valor máximo. A nível da rede, sempre que é recebida uma trama de dados

é actualizada uma variável global cuja finalidade é a de contabilizar o tempo que passou desde a

última comunicação com o supervisor respectivo. Quando este temporizador supera o valor definido

como uma configuração global do nó (Network Keep Alive), é enviada uma trama especial para o

supervisor de modo a obter uma resposta do mesmo, resposta que se não chegar num período de

tempo especificado levará o módulo controlador a reiniciar-se. Esta configuração permite que o SL

saiba quando algum nó está incontactável e poderá ser configurada com valores diferentes para cada

módulo controlador.

Por fim resta referir o modo como são geridas as configurações do módulo controlador. No início

do programa é carregada uma classe denominada Configs que é responsável por estabelecer a

interface do programa com as diversas configurações possíveis e interagir com a memória EEPROM.

Grande parte das configurações só são necessárias esporadicamente em tarefas de inicialização, e

para todas estas os seus valores são lidos directamente da memória EEPROM em detrimento de as

guardar em memória RAM. Apenas as que são necessárias ao longo do funcionamento do programa

(como o endereço do nó) são guardadas como atributos dessa mesma classe. Existem ainda

atributos que não têm a ver com configurações que possam ser alteradas directamente através da

rede mas com vectores de dados necessários para definir o comportamento do controlador e que

poderão ser parcialmente configuradas pela rede, necessitando de serem explicitamente gravados na

memória EEPROM para serem utilizadas após um reiniciar do sistema (o estado seguro previamente

apresentado). Nestes vectores de dados incluem-se a lista de aplicações (NApps) carregadas em

memória no iniciar do programa, a relação entre portos do microcontrolador e respectivas NApps e as

configurações próprias a cada dispositivo de cada NApp.

Existem três níveis distintos de configurações que diferem entre si no modo como as tramas são

endereçadas e a que subsistema do controlador se aplicam (ver Tabela 5.1).

61

Tipo de configuração Característica de endereçamento Descrição

Configurações globais NApp = 0 e ADev = 0 Configurações globais ao nó como endereço de rede, canal RF, etc.

Configurações gerais de uma NApp

NApp ≠ 0 e ADev = 0 Configurações globais de uma NApp,

que são da responsabilidade da mesma

Configurações de um dispositivo específico

NApp = 0 e ADev ≠ 0 Configurações de um dispositivo

específico como se este está activo, o porto utilizado, temporizações, etc.

Tabela 5.1 – Tipos de configurações dos módulos controladores

O único modo de endereçamento não listado na Tabela 5.1 é quando a trama é endereçada para

uma NApp e ADev diferentes de zero. Neste caso está-se a interagir directamente com o dispositivo

de uma aplicação através da respectiva propriedade endereçada no campo de dados. Na Figura A4.1

em anexo é possível ver um fluxograma simplificado do ciclo principal do módulo controlador.

5.1.1.2 Propriedades

Salvo raras excepções, nomeadamente dados que são acedidos em todos os ciclos de execução

como as configurações principais (flags) de cada dispositivo e as configurações globais do

controlador, os dados são todos guardados sob a forma de propriedades. Cada dispositivo terá ao

seu dispor 32 propriedades independentemente da NApp a que corresponde. Para que as NApps

possam aceder a estes dados de uma forma padronizada, optou-se por implementar o subsistema

das propriedades como uma classe, cujo único atributo é o seu buffer onde guarda os dados e cujos

métodos são rotinas de pesquisa e inserção de dados que lidam com os tipos de dados mais comuns.

Uma vez atingido o limite máximo de propriedades que se conseguem alocar, o módulo

controlador começará a retornar erro a cada nova configuração que exija alocar uma nova

propriedade. Optou-se por um buffer único em vez de um para cada NApp pois permite gerir melhor o

espaço disponível, na medida em que se cada NApp tivesse o seu próprio buffer poderiam existir

NApps já sem espaço enquanto outras não utilizavam o seu. Deste modo todas competem por um

espaço em memória que é comum a todas, facilitando a idealização do pior caso possível em termos

de ocupação de memória.

5.1.1.3 Rede

Dadas as características do módulo RF escolhido que permite a existência de 6 canais de

comunicação em simultâneo, 5 dos quais terão que obrigatoriamente partilhar todos os Bytes excepto

o menos significativo (que será incrementado uma unidade para cada canal seguinte), estas tornam-

se extremamente úteis para a criação de redes com topologia em árvore pois um canal (o 0, sem

restrições no seu identificador) poderá fazer a ligação com o nível superior da árvore enquanto os

restantes 5 canais (1 a 5) que terão de ter endereços semelhantes poderão ser utilizados para os

filhos do nó em questão. No nível abaixo, o endereço de cada nó terá o seu canal 0 relacionado com

o endereço dos filhos do nó anterior, e os seus filhos representarão novas gamas de endereços

semelhantes distintas daquelas do seu pai. Assim, estas características da tecnologia Enhanced

ShockBurst MultiCeiver permitem facilmente implementar uma topologia em árvore em que cada nó

poderá ter no máximo 5 filhos. Cada canal criado ao nível da camada física terá apenas dois nós a

62

comunicar numa única direção, cada um no seu nível da árvore, o simplifica consideravelmente o

algoritmo de encaminhamento. Cada nó poderá em simultâneo verificar por mensagens nos 6 canais:

do seu pai (mensagem para encaminhar para um dos filhos) ou de um dos 5 filhos (mensagem para

encaminhar para um outro filho ou para o pai). Para endereçar cada um destes 5 filhos são

necessários 3 bits, resultando num total de 8 endereços e portanto gerando um desperdício de 3

endereços por nível. De modo a tornar o encaminhamento o mais directo possível considera-se que o

endereço de cada nó encontra-se dividido por níveis da árvore, em que cada nível são utilizados 3

bits.

Figura 5.1 – Endereçamento dos nós da árvore

Assim apenas através da leitura do endereço de destino de uma trama um nó da rede consegue

através de máscaras, simples operações de AND, OR e bit shifts, saber se o endereço de destino da

trama que recebeu é para encaminhar para um dos filhos (se parte do endereço até ao seu nível é

igual) ou para o seu pai (restantes casos). No pior dos casos uma trama terá que viajar até ao nó raiz

(0) para ser encaminhada para um ramo diferente. Para se saber até que nível da árvore o endereço

se encontra definido é necessário utilizar um dígito (diferente dos 5 já utilizados) para indicar que

esse nível não se encontra identificado no endereço de modo a evitar casos dúbios e até mesmo

repetições de endereços. Para esta representação foi escolhido o dígito 0, que reduz o desperdício

de endereços por nível da árvore para 2 (os dígitos 6 e 7 em cada nível).

Para simplificar a identificação dos nós é útil recorrer à representação octal (ou base 8) pois esta

representação em binário corresponde aos 3 bits utilizados em cada nível facilitando assim a leitura

do endereço, podendo associar logo o nó à sua posição na rede. Assim do endereço dos nós em

octal, interpretando da esquerda para a direita, é possível perceber facilmente a posição do nó como

se encontra exemplificado na Tabela 5.2. Em todas as interacções com o utilizador implementadas

são sempre referidos os endereços em octal por simplicidade.

Binário Octal Decimal Descrição

000 000 001 1 1 Filho 1 do nó 0 (raiz)

000 100 001 41 33 Filho 4 do filho 1 do nó 0

010 100 001 241 161 Filho 2 do filho 4 do filho 1 do nó 0

Tabela 5.2 – Relação entre diferentes métodos de representar o endereço dos nós

Deste modo adoptou-se por um método de encaminhamento que produz rotas de

encaminhamento únicas (dada a topologia da rede em árvore adoptada) e em que cada nó poderá

rapidamente encaminhar as mensagens sem necessitar de recorrer a tabelas de encaminhamento ou

de comunicar com outros nós da rede (ver Figura 5.2). O número de níveis escolhidos para a árvore

foram 3 de modo a permitir uma utilização mais eficiente dos 16 bits de endereçamento especificados

no protocolo DomoBus para os endereços CL. Estes 3 níveis permitirão um máximo de 155

endereços excluindo a base.

63

∑5𝑖 =

3

𝑖=1

155

Fórmula 2 – Cálculo do número de nós numa topologia em árvore com 3 níveis excluindo a raiz

Figura 5.2 – Exemplo de uma rede com topologia em árvore. Endereços em octal e em binário.

O total de 155 endereços foi considerado um número aceitável para uma rede sem-fios pois não

se deverá descurar o facto de que se um nó cessa o seu normal funcionamento afecta todos os nós

cujo encaminhamento dependem dele (o que levou ao planeamento de técnicas que permitam à rede

recuperar de situações anómalas, descritos adiante). Ao mesmo tempo a arquitectura escolhida para

as redes DWCN permite facilmente e com custos reduzidos criar novas redes recorrendo a módulos

gateway, sem que estes necessitem obrigatoriamente de novos módulos de supervisão, aumentado

assim a resiliência total da rede DomoBus. É preciso ter ainda em consideração o número elevado de

canais RF distintos (126) distribuídos na gama de frequências que se situa entre os 2400MHz e os

2450MHz permitindo que – no caso de todas as bandas se encontrarem livres de interferências – a

utilização de 126 DWCN a partilharem o mesmo espaço físico em que cada canal RF está no alcance

de todos os outros (caso contrário poderiam-se reutilizar canais que não se sobrepusessem), o que

permite uma densidade de redes (e por sua vez de nós) por unidade de área bastante considerável:

Assumindo a distância máxima de transmissão dentro de habitações de 10m, então cada rede

DWCN teria que ter pelo menos um nó a menos de 10 metros de distância de pelo menos um nó de

todas as outras redes nos restantes 125 canais RF. Ou seja, numa área circular de aproximadamente

78m2 teríamos que ter no mínimo 126 nós de 126 diferentes DWCN, cada uma no seu canal RF.

Figura 5.3 – Exemplo da situação de sobrelotação de todos os canais RF. Cada nó laranja simboliza

aproximadamente 3 nós com canais RF distintos.

O limite máximo teórico de módulos controladores neste caso limite em que não se podem repetir

canais RF pois todos se vêm uns aos outros devido à má distribuição geográfica das redes DWCN é

64

de 155 nós para cada um dos 126 canais o que resulta num total (teórico) de 19530 módulos

controladores. De notar que este é o menor número máximo de nós considerando todos os canais RF

livres. É portanto sensato considerar que embora todos os nós partilhem o mesmo meio de

comunicação a abordagem escolhida é bastante escalável ao ponto de a escalabilidade ser

bloqueada devido à sobrelotação do meio de transmissão antes de se observaram limitações

impostas pela arquitectura.

A forma como se distribuem os 16 bits do endereçamento CL foi ligeiramente alterada da forma

como é feita nas DCN devido às características específicas das DWCN nomeadamente no que toca

ao endereçamento.

Figura 5.4 – Endereçamento CL nas DWCN

Dos 512 endereços disponíveis relativos os 9 bits necessários para representar os 3 níveis da

árvore apenas se utilizam 155, resultando num desperdício de 356 endereços que correspondem às

combinações possíveis de endereços com dígitos inválidos em cada nível da árvore. Será o preço a

pagar de modo a implementar um método de encaminhamento que seja simples e eficaz e que

dependa apenas de simples operações lógicas, evitando recorrer a complexas funções matemáticas

para efectuar conversões de endereços. Estes 512 endereços poderão ainda ser utilizados como

endereços de grupos quando o bit broadcast do campo de controlo CTR se encontra activo. Cada

módulo controlador consegue lidar no máximo (devido a limitações de memória) com 225 grupos que

podem encontrar-se distribuídos de qualquer forma pelos dispositivos, ou seja, um dispositivo pode

pertencer a 225 grupos distintos e nenhum outro dispositivo poderá pertencer a um grupo, ou num

caso de equilíbrio, cada um dos 15 dispositivos (existem 15 portos disponíveis no módulo controlador)

poderá pertencer a 15 grupos distintos. Todos os dispositivos dentro do mesmo grupo terão que ser

do mesmo tipo (associados à mesma NApp) pois a mensagem será igual para todos (será

referenciada a mesma propriedade) e todos terão que a interpretar da mesma forma.

Ao se desejar que um módulo controlador genérico possa ser inteiramente configurado pela

interface de rede, é necessário que este se consiga inserir automaticamente numa rede já

estabelecida de modo a sinalizar o supervisor que aguarda uma configuração. Para tal o módulo

controlador necessita de ter configurado o mesmo canal RF que uma das redes estabelecidas, assim

como precisa de um endereço nessa mesma rede que não esteja a ser utilizado. Para abordar este

problema sem ter que assumir parâmetros por defeito que podem limitar demasiado o sistema

(assumir um canal RF por defeito que pode ser demasiado ruidoso ou assumir um endereço na

árvore - que teria de ser na primeira camada - e restringir assim um ramo inteiro da árvore)

desenvolveu-se um algoritmo de procura por nós que foi usado não apenas na configuração inicial de

cada módulo controlador, como em tarefas relativas à reestruturação da rede quando um nó cessa o

65

seu funcionamento (de modo a não afectar todos os nós que dele dependem). Esta pesquisa

percorre, para um dado canal RF, 31 endereços diferentes para varrer a árvore em direção à raiz, e

pressupõe que os quintos filhos dos nós da 2ª camada do primeiro canal RF em utilização

(denominado canal principal, através do qual se deverão configurar os novos dispositivos) não são

utilizados, reduzindo em 25 o número total de nós nessa rede (para 130). Esta suposição foi feita

para garantir que no primeiro canal RF que um controlador encontre (a começar de 0 até 125) este

pode assumir um endereço no terceiro nível para tentar contactar cada um dos nós no segundo nível

sem correr o risco de se sobrepor a nenhum nó. Assim o algoritmo que procura por um endereço para

o primeiro canal RF encontrado:

Tentar fazer-se passar por um nó da terceira camada (sempre o 5º filho) começando pelo

endereço 0555 (octal) e tentar comunicar com o respectivo pai. Existem 25 possíveis pais (os

nós da segunda camada)

Se não existir ligação com nenhum nó da segunda camada é porque esta não se encontra

definida pelo que passam a assumir endereços da segunda camada e tenta comunicar com

os seus pais. Existem 5 possíveis pais (os nós da primeira camada)

Se não existir ligação com nenhum nó da primeira camada é porque esta não se encontra

definida e tentará assumir o endereço 5, da primeira camada, e tentar comunicar

directamente com a raiz

Se não conseguir contactar nenhum nó, parte-se do pressuposto que este canal RF não se

encontra em utilização e parte para o próximo

O algoritmo termina quando existe um nó que responde num dado canal RF, situação em que se

volta um passo atrás e se alteram as definições de retransmissão para os valores normais

(anteriormente relaxados para acelerar a pesquisa) de modo a confirmar que não existe mesmo

ligação com o endereço do nó que vai assumir. Se esta verificação ocorrer com sucesso o nó assume

o endereço encontrado como temporário e sinaliza a SLAG que se encontra à espera de

configuração. O SL poderá então configurar este nó para o endereço pretendido (que poderá ser

noutro canal RF) ou deixar o endereço descoberto automaticamente. Este método de endereçamento

tem a desvantagem de poder depender da posição geográfica do nó a configurar no caso de a rede

DWCN se encontrar muito dispersa, situação na qual o nó a configurar não deverá ser colocado junto

à base mas junto aos nós terminais da árvore estabelecida para evitar que este obtenha comunicação

com um nível inferior da árvore e não consiga contactar com o nível superior devido à elevada

distância a que este se encontra. Quando um nó se encontra no estado desconfigurado, à procura de

endereços, é importante que este não tente encaminhar mensagens que recebe enquanto assume

endereços temporários de modo a permitir que existam vários nós em pesquisa ao mesmo tempo.

Assim, embora um nó temporário possa oferecer uma resposta (ACK) a outro nó temporário não

conseguirá encaminhar a trama de teste do mesmo para a SLAG fazendo com que o segundo nó

pense que se está a ligar a parte de uma rede isolada e continue na sua pesquisa por endereços

válidos.

66

O tempo médio de varrimento de um canal RF vazio em busca de endereços é de 371

milissegundos, o que significa que no pior caso possível (existir apenas uma rede DWCN no canal RF

126 e não existir ainda nenhum nó na primeira camada da árvore) são necessários aproximadamente

47 segundos para um nó desconfigurado encontrar um endereço válido.

Por fim, de modo a oferecer alguma tolerância a falhas na estrutura da rede foi implementado um

método de reestruturar a rede quando um módulo controlador não consegue obter comunicação por

um período superior a um limite configurado pelo utilizador. Por defeito esta funcionalidade encontra-

se desactivada por não ser determinística e não garantir que a reestruturação da rede resultante é a

mais indicada e que todos os nós conseguirão uma ligação à árvore. O resultado nunca será pior que

a situação de erro uma vez que no pior dos casos nenhum nó conseguirá ligar-se (no caso de a falha

ocorrer no único nó que estabelecia a ligação entre dois segmentos da árvore muito distantes), o

problema poderá residir na reestruturação que assume uma direcção no sentido da raiz para as

folhas e que a escolha de endereços poderá limitar a conectividade de nós da árvore que se

encontram nos níveis abaixo (mais longe da raiz). O valor do temporizador que define este

comportamento, denominado de NRT (Network Reestablish Timeout), é uma configuração local a

cada módulo controlador mas é definida para toda uma DWCN não existindo hipótese de definir

diferentes valores para cada nó, uma vez que todos os valores se encontram relacionados. A

configuração é feita por broadcast e cada nó somará um valor que terá em conta o seu nível na rede,

o endereço do seu pai e o seu próprio endereço de modo a garantir que a reorganização da rede será

feita partindo do primeiro nó mais perto da raiz que perdeu a conectividade até ao último

maximizando as hipóteses de a rede resultante ter uma estrutura o mais semelhante possível à

anterior. Este valor incrementado estará relacionado com o tempo máximo que cada nó precisará

para procurar um novo endereço dentro do seu canal RF. No Anexo A4.2 encontra-se um exemplo de

uma reestruturação e um fluxograma simplificado deste algoritmo.

Para implementar a encriptação dos dados ao nível da camada de enlace optou-se pelo algoritmo

XXTEA ou Corrected Block TEA que originou do algoritmo original Block TEA, ambos desenvolvidos

pela dupla Roger Needham e David Wheeler, primeiro apresentado em 1997 e depois refeito para

corrigir algumas fraquezas no algoritmo original, o que originou o XXTEA em 1998. O algoritmo utiliza

como estrutura uma cifra Feistel desequilibrada e não requer um tamanho fixo para os blocos desde

que seja um múltiplo de 32 bits (tamanho da palavra) e garantindo que tenham no mínimo duas

palavras (64 bits). Utiliza uma palavra-chave de 128 bits e não requer um número de ciclos fixo,

sendo que este depende do tamanho do bloco a codificar. Devido à sua simplicidade algorítmica e à

necessidade de recorrer a pouca memória é um algoritmo especialmente viável para ser utilizado em

sistemas computacionais embebidos, como é o caso, resultando num algoritmo implementado em

poucas linhas de código, que requer escassos Bytes de RAM e que pode ser executado em poucos

ciclos quando comparado com outros que implementem um grau comparável de segurança.

A única fraqueza reportada prende-se com um tipo de ataque muito específico: o atacante

necessita de obter mensagens descodificadas e a sua respectiva codificação (chosen-plaintext

attack), para poder obter informações de modo a reduzir o nível de segurança do sistema

67

criptográfico [47]. O ataque publicado em 2010 requer 259 mensagens descodificadas e as suas

respectivas codificações de modo a obter a palavra-chave de 128 bits. Considerando que neste

contexto se torna difícil obter as mensagens descodificadas e a sua respectiva codificação (pelos

motivos apresentados relacionados com ataques de repetição) e que a fraqueza do algoritmo

apresentada requer um tipo muito específico de ataque díficil de efectuar tanto em termos

computacionais como físicos (de modo a obter os dados dos quais o ataque depende) não será

completamente despropositado afirmar que o algoritmo apresenta um elevado nível de segurança.

Apesar disso foi implementado um método de alterar a palavra-chave numa rede DWCN de uma

única vez, permitindo que o SL possa gerir de forma mais eficiente a segurança do sistema,

nomeadamente a SLAG correspondente ou um supervisor. Ao mesmo tempo nada impede que cada

rede DWCN possua a sua própria palavra-chave permitindo, num caso de ataque, compartimentar os

subsistemas comprometidos. O código utilizado foi o original sem qualquer modificação de modo a

não comprometer a segurança do algoritmo. A encriptação é aplicada na camada de rede deixando

apenas sem encriptação os campos de controlo da camada de enlace que é gerida pelo módulo RF

(ver Anexo A4.4). A protecção contra ataques de repetição e a implementação de um método básico

de autenticação dos nós é feita recorrendo ao campo SNum na camada de rede como descrito no

capítulo anterior.

5.1.1.4 Node Apps

Todas as NApps têm por base um objecto pai denominado genericApp. Este objecto implementa

não só a interface que todas as NApps deverão respeitar como o código que é comum a todas as

NApps, nomeadamente tudo o que é relativo a temporizações e comunicações com o supervisor ou

com outros controladores. No Anexo A4.6 encontra-se um fluxograma da lógica associada às

temporizações implementadas pelo objecto genericApp.

Para dispositivos que implementem sensores cujas leituras poderão ser rápidas (várias vezes num

curto espaço de tempo) existe a opção de se definir um valor limite para que o módulo controlador

faça a comparação e notifique o supervisor apenas quando esse valor é cruzado (em ambos os

sentidos) em vez de ser o supervisor a fazer essa comparação, de modo a não sobrecarregar a rede.

A comunicação directa com outros controladores é feita através de uma funcionalidade a que se

chamou Direct Link. Esta funcionalidade foi desenvolvida para permitir comunicações que se querem

com uma latência o mais baixa possível e entre nós da mesma rede evitando que os dados tenham

que passar antes no supervisor. Se um dispositivo está configurado para utilizar a funcionalidade

Direct Link, terá que ser dado um conjunto de dados que o permitirão comunicar com outro módulo

controlador. Entre estes dados incluem-se o endereço do dispositivo de destino de 16 bits (CDev), o

dispositivo que despoleta a acção e os dados a enviar na trama. Está limitada a existência de apenas

uma acção por dispositivo para apenas um outro módulo controlador que poderá ser ele mesmo.

Independentemente de o Direct Link estar ou não configurado para um dado dispositivo as

notificações são sempre enviadas para o supervisor.

Existem opções genéricas para todos os dispositivos que são definidas num cabeçalho guardado

pelo objecto de configurações (dado que são necessárias a cada ciclo principal do programa),

68

evitando assim sobrecarregar o microcontrolador ao obter esses dados indirectamente através de

propriedades. Essas opções correspondem a diferentes funcionalidades (ver Anexo A4.5) e são

representadas por bits que sinalizam se estão activas ou não. São todas geridas internamente pelo

módulo controlador mas algumas podem ser manipuladas remotamente, permitindo assim um maior

controlo do SL sobre as acções que o módulo controlador toma por defeito. Nem todos os dispositivos

poderão utilizar estas funcionalidades da mesma forma, e para que cada dispositivo possa forçar um

dado modo de funcionamento existe um método chamado antes de iniciar cada aplicação para cada

dispositivo que permite forçar certas opções. Por exemplo, um sensor que necessita de um dado

tempo para obter os seus dados pode forçar a que o valor dos temporizadores seja sempre superior a

esse valor.

5.1.2 Hardware

Recorrendo a software dedicado ao desenvolvimento de circuitos implementou-se um circuito-

exemplo para um protótipo com base nos requisitos descritos no manual do microcontrolador (ver

Anexo A4.7). Este terá que ser implementado numa placa de circuito impresso de duas camadas

dado o número de pistas existentes. A dimensão final deste protótipo sugerido é de 62 por 80mm e

como referido anteriormente, não se utilizou por defeito o porto IRQ do módulo RF de modo a não

utilizar um porto do microcontrolador que poderá ser utilizado para um módulo de dispositivo. No

Anexo A4.9 encontra-se o mapeamento de portos feito entre os portos do microcontrolador

disponíveis para alocar módulos de dispositivos e a nomenclatura utilizada pelo módulo controlador

nas suas configurações.

Na interface física com os módulos de dispositivos tomou-se uma abordagem que disponibiliza

para cada dispositivo o acesso ao porto do microcontrolador e os 3 níveis de tensão disponíveis no

módulo controlador: 0, 3.3 e 5V. Assim pretende-se cobrir todas as necessidades que um módulo

poderá necessitar da placa do controlador. A interface física adoptada no desenvolvimento do

protótipo, recorrendo a fichas do tipo JST (Japan solderless terminal) XH 2.54mm (ver Figura A4.16),

não foi a ideal por não se ter adoptado um espaçamento igual entre todos os portos de modo a

padronizar as ligações para facilitar a utilização de dispositivos que utilizem múltiplos portos. Para

auxiliar a configuração física dos módulos controladores seria benéfico que o SL implementasse uma

aplicação para auxiliar na configuração que permitisse dar indicações ao utilizador de modo a

prevenir certas situações que poderiam comprometer o hardware, ou seja prevenir certas

combinações entre módulos de alimentação com conjuntos de módulos de dispositivos dado que o

SL terá acesso a estas informações a partir das configurações fornecidas pelo utilizador.

Quanto ao módulo de alimentação foram desenvolvidos apenas dois módulos de modo a

demonstrar as vantagens da abordagem modular que se adoptou. Um dos módulos assume uma

entrada de 5V contínuos através de uma interface USB provenientes do adaptador previamente

apresentado (ver Figura 4.8) e outro que assume uma maior variedade de tensões de entrada (entre

7 e 35V contínuos) através de uma ficha DC comum de 2,5mm (com polaridade positiva) ou de

terminais com parafusos para ser utilizado com transformadores usuais (ver Anexo A4.8). A interface

de ligação física entre este módulo e o módulo controlador é feita recorrendo ao mesmo tipo de fichas

69

utilizado anteriormente, mas desta vez apenas com 3 condutores, as 3 tensões utilizadas: 0, 3.3 e 5V.

Os componentes utilizados foram os que melhor se adaptarem mediante as suas características e o

seu custo, nomeadamente os reguladores lineares de tensão AZ1117T (para alimentar a linha de

3.3V) e L7805CV (para regular a tensão de entrada para 5V no caso do segundo módulo de

alimentação) e os componentes passivos recomendados para filtrar as entradas e saídas nos

respectivos manuais. Teve-se em conta,

A corrente máxima do módulo RF que corresponde a um pico de 12.3mA quando a receber

dados e a operar com a velocidade de transmissão máxima (2Mb/s) que não deverá ocorrer

mas foi visto como o pior caso possível correspondendo a 40mW de potência. Os valores

médios esperados são de 8.0mA para a transmissão e 8.4mA para a recepção pelo que se

considerou o valor de 10mA, valor para o qual o regulador de tensão AZ1117 com uma

alimentação de 5.0V garante uma tensão de saída entre 3.267 e 3.333V a 25ºC. Esta

utilização (10mA) corresponde a 1% do limite recomendado pelo fabricante (1A) motivo pelo

qual se disponibilizou a linha de 3.3V para os dispositivos.

A corrente máxima de alimentação que o ATMega328P suporta é de 200mA, não sendo

recomendado passar os 20mA por porto até um limite de 40mA. Isto poderá impor algumas

restrições no modo como são utilizados os portos quando se encontra um grande número de

dispositivos instalados (mais uma vez poderá ser uma situação automaticamente detectada

pelo SL)

Considerando a utilização do módulo de alimentação por ficha DC com uma tensão de

entrada superior a 7,5V (para superar a tensão de droupout máxima), um transformador com

corrente máxima superior a 1.5A, a linha de 3.3V apenas com o módulo RF conectado e

tendo em conta a corrente de fuga máxima do AZ1117T (20mA), a utilização do LT7805CV

fica em cerca de 13%. Sobram 1.3A que podem ser distribuídos pelos módulos de

dispositivos

Considerando a utilização do módulo de alimentação por USB o consumo máximo estará

dependente do adaptador utilizado. No conjunto utilizado está limitado a 1A, sobrando cerca

de 800mA para os dispositivos.

O módulo RF utilizado é muito sensível ao ruído na sua alimentação pelo que para se obter um

funcionamento estável em certos protótipos foi necessário filtrar o sinal à entrada do mesmo

recorrendo a um condensador electrolítico de 10µF com o intuito de estabilizar a tensão de saída do

regulador de tensão. Adicionalmente acabou-se por adicionar em todos os protótipos, pois como não

se saberá à partida o número de dispositivos a utilizar a linha de 3.3V, é sempre útil precaver o

módulo RF para ambientes mais ruidosos. Este condensador foi soldado directamente nos pinos de

alimentação do módulo RF de modo a aumentar a sua eficiência.

Relativamente ao módulo RF, poderia ter sido implementado uma simples forma de aumentar a

distância máxima de transmissão e a fiabilidade da mesma nos módulos RF com antena plana

através de simplesmente ter optado por uma ligação flexível (por exemplo utilizando um cabo de 8

70

condutores juntamente com um material mais rígido não metálico) de modo a poder direcionar a

posição da antena sem afectar a posição de todo o módulo controlador.

Quanto aos módulos de dispositivos, desenvolveram-se 8 tipos de dispositivos básicos que se

julgaram úteis no campo da domótica, apenas com o intuito de demonstrar o sistema em

funcionamento e apresentar a utilização da API por parte de NApps como exemplo, mas não serão

detalhados pois não fazem parte dos objectivos principais do projecto. Os dispositivos básicos

implementados foram simples saídas e entradas digitais e analógicas. Os dispositivos extra

implementados foram sensores distância supersónicos, sensores de temperatura DS18B20 da Dallas

(protocolo OneWire), sensores digitais de humidade e temperatura DHT e por fim receptores de

infravermelhos. No Anexo A4.10 encontram-se alguns detalhes, como imagens e custos.

5.2 Módulo gateway

O módulo gateway é o que permite fornecer ao SL o acesso a uma determinada rede DWCN ao

criar a ponte entre um método de comunicação primário que garante a ligação à respectiva SLAG e

um secundário que é sempre um módulo nRF24L01+ configurado para o canal RF relacionado com a

rede DWCN e com o endereço 0 de modo a representar a raiz da rede com topologia em árvore. Não

se definiu à partida um canal de comunicação primário pois pretende-se oferecer flexibilidade no

modo como a rede é construída que poderá variar consoante o tamanho da mesma, o nível de

redundância pretendido, a quantidade de dinheiro a investir ou as características locais da habitação

que poderão forçar diferentes localizações para os dispositivos conforme o espaço, organização ou

cablagem já existente. Assim o canal de comunicação primário poderá ser feito através dos seguintes

protocolos:

SPI, onde o módulo gateway propriamente dito não passa de um módulo nRF24L01+, ou seja, o

módulo de supervisão (que aloja o SLAG) deverá ser um sistema embebido com acesso a portos

SPI (ou a emulá-los através de portos de utilização geral) e necessita de uma alimentação de

3.3V. Útil para quando se pretende um supervisor por rede DWCN ou se têm uma instalação com

um número reduzido de redes todas próximas do módulo de supervisão.

Figura 5.5 – Ligação directa do módulo de supervisão que aloja a SLAG ao(s) módulo(s) RF através do protocolo SPI

USB, que permite uma conexão directa a uma maior variedade de módulos de supervisão e

permite uma maior distância do gateway a estes (5 metros no máximo a menos que se utilizem

hubs para estender até um máximo de 5 níveis) assim como transporta a alimentação juntamente

com as linhas de dados

71

Figura 5.6 – Ligação ao módulo gateway por USB. Permite maior flexibilidade que por SPI

Ethernet, que oferece o máximo de flexibilização ao utilizar um canal de comunicação que já terá

de existir na habitação (para o SL) e que permite cobrir maiores distâncias até ao limite de existir

apenas um módulo de supervisão e múltiplas redes DWCN distribuídas por módulos gateways

Figura 5.7 – Ligação ao módulo gateway é feita por ethernet permitindo uma maior flexibilidade no posicionamento dos mesmos sem ter que replicar dispositivos do SL. A azul representa-se uma wireless bridge.

Deste modo consegue-se manter a flexibilidade do protocolo DomoBus e não se têm que definir à

partida um tipo de módulo de supervisão específico para alojar a(s) SLAG(s) ou um canal de

comunicação específico para distribuir as tramas SL pelas diversas redes DWCN. Dos três métodos

apresentados previamente apenas dois necessitam de recorrer a um módulo gateway dado que a

ligação do módulo RF por SPI é feita directamente no módulo supervisor que aloja a SLAG e será

abordada no capítulo reservado à mesma. Assim neste capítulo serão abordadas as soluções que

implementam um módulo gateway que utilize comunicação por USB ou ethernet na sua interface de

rede primária.

5.2.1 Software

A grande diferença nas duas abordagens (USB e Ethernet) é a de que no caso da versão ethernet

existe uma partilha de dois dispositivos no mesmo protocolo (SPI) o que força a existência de uma

máquina de estados bem definida e de memória extra para guardar os dados entre estados pois os

dispositivos não poderão ser acedidos simultaneamente. Poderia ter sido tomada uma abordagem

diferente no caso da versão com comunicação em série (via protocolo USB), mas manteve-se a

mesma estrutura de modo a utilizar o mesmo código base evitando diferenciar duas soluções que

poderiam convergir numa só, simplificando assim o software do módulo gateway que precisará

apenas de uma recompilação com diferentes parâmetros de modo a assumir uma das duas

abordagens apresentadas. Como a abordagem com comunicação série é a que exige menos

memória (de dados e de programa), será seguro assumir que o mesmo sistema que implementa a

versão ethernet conseguirá lidar sem problemas com a abordagem de comunicação série desde que

possua os portos de comunicação UART necessários (RX e TX).

Em termos de configurações, a abordagem por USB não necessita de nenhuma configuração para

o canal de comunicação poder ser utilizado, partindo do pressuposto que a velocidade de

72

transmissão é fixa e conhecida à partida pela SLAG. O mesmo não se passa com a abordagem por

ethernet que necessita de ter um endereço IP válido de modo a poder utilizar o seu canal de

comunicação, pelo que foi necessário implementar um estado desconfigurado no qual os dispositivos

vêm originalmente. Ao contrário de todos os dispositivos abordados (módulo controlador, módulo

gateway USB e módulo de supervisão que aloja a SLAG) em que foi feito um esforço para que não

existisse nada de único em cada instância do software de modo a tornar um sistema totalmente

reconfigurável em que qualquer dispositivo poderia assumir o papel de qualquer outro, no caso do

módulo gateway ethernet terá que ser utilizado um endereço MAC (Media Access Control) único em

cada dispositivo de modo a garantir a operacionalidade do mesmo. Isto não implica que módulos

gateway não possam ser trocados e assumir as mesmas funções, mas cada um terá a sua própria

versão do software que irá diferir apenas no endereço MAC. Num estado desconfigurado as

comunicações são todas feitas em broadcast sem existir um IP atribuído, semelhante ao que é feito

no protocolo DHCP. O protocolo utilizado é muito simples e foi desenvolvido especificamente com

esta aplicação em mente não tendo nenhuma relação com as especificações do DomoBus. A

configuração é feita recorrendo a um programa auxiliar (testado no módulo de supervisão) e decorre

em 3 passos:

1. Módulo gateway ethernet transmite uma trama em broadcast onde refere o seu endereço MAC e

indica que espera configuração

2. O programa captura a trama e responde com o mesmo endereço MAC (para direccionar a

resposta a um dispositivo apenas e permitir que existam vários a serem configurados

simultaneamente) seguido do endereço IP a utilizar, endereço IP do gateway de rede, endereço

IP e porto da SLAG com quem irá comunicar e o canal RF em que irá operar

3. O módulo gateway ethernet guarda as configurações na EEPROM e reinicia de modo a iniciar

fora do estado desconfigurado e assume o seu modo de funcionamento normal.

Uma vez tendo um IP válido e estando num estado operacional, as mesmas configurações feitas

por broadcast poderão ser alteradas, recorrendo a configurações globais semelhantes às dos

módulos controladores. Embora o modo de configurar apresentado seja manual (através da linha de

comandos), é apresentado apenas como um exemplo, pois uma vez que este projecto se encontre

integrado num sistema DomoBus completo, será benéfico se for o SL a configurar automaticamente

sem intervenção do utilizador, de modo a simplificar todo o processo e tornar todo o sistema mais

simples de implementar. Isto é no entanto uma tarefa para o nível mais alto do sistema DomoBus

onde se sabe quantas redes CL existem, os seus módulos gateway e os detalhes da rede ethernet.

5.2.2 Hardware

Para implementar o módulo gateway recorreu-se ao mesmo microcontrolador utilizado para o

módulo controlador dadas as semelhanças nos requisitos de ambos os sistemas, e de modo a

simplificar o desenvolvimento ao poder reutilizar-se o código já implementado para lidar com o

módulo RF, assim como permite utilizar o mesmo ambiente de desenvolvimento e não requer a

aquisição de hardware adicional à excepção do módulo de rede primário, um módulo Ethernet

compatível com redes 10/100/1000 Base-T (embora só utilize na camada física o acesso a 10 Mbit

73

com suporte aos modos full-duplex e half-duplex), ou um módulo FTDI que permita a ligação série

(via USB) com o módulo supervisor que aloja o SLAG.

O módulo ethernet utilizado têm como base o chip ENC28J60 da Microchip que pretende oferecer

uma solução de baixo custo para implementar as camadas físicas e de acesso ao meio (MAC), com

suporte à retransmissão automática de tramas no caso de colisões e gestão da integridade das

tramas. A tensão de alimentação é de 3.3V (em certos modelos poderá ser de 5V) com as entradas

tolerantes a 5V. A interface de comunicação com o microcontrolador é feita pelo protocolo SPI. Este

módulo foi escolhido pelo seu baixo custo e por as especificações do protocolo DomoBus referirem a

utilização de tramas UDP, pelo que possibilita a utilização de chips que tratam apenas das camadas

mais baixas do protocolo IEEE 802.3, e permitem ao mesmo tempo a utilização de

microcontroladores com baixos requisitos de memória pois não é necessário implementar as

camadas mais complexas associadas, por exemplo, ao protocolo TCP e aos protocolos que

funcionam com base neste nas camadas superiores.

O módulo gateway USB utiliza um módulo conversor de USB para RS232 que permite uma

ligação directa entre uma porta USB e os portos UART do microcontrolador. O modelo adquirido tem

como base o chip FT232RL e dispensa a existência de um módulo de alimentação dado que se

podem obter as tensões de 5 e 3.3V directamente deste módulo de rede. Uma vez que a

especificação USB 1 e 2 suportam até um máximo de 500mA por porto, a especificação USB 3

suporta um máximo de 900mA e que da linha de tensão 3.3V fornecida pelo chip FT232RL se pode

obter um máximo de 50mA é seguro alimentar todo o módulo gateway a partir do módulo supervisor e

assim transportar os dados e alimentação num único cabo. A comunicação série é feita utilizando os

parâmetros 57600/8N1.

Figura 5.8 – Módulos de rede utilizados: ethernet (à esquerda) e USB (à direita)

No Anexo A5 apresenta-se o esquema de um módulo gateway. Optou-se por implementar um

circuito mais completo do que o estritamente necessário para um módulo gateway de modo a poder

obter um protótipo que pudesse estar adaptado a várias funcionalidades com a finalidade de testar

diferentes abordagens. Para isso incluíram-se jumpers que permitem configurar os pinos SS (slave

select) do protocolo SPI e um porto de comunicação ISP (In-system programming) para mais

facilmente reprogramar o microcontrolador. Deste modo pretendeu-se obter as seguintes

funcionalidades deste protótipo: módulo gateway ethernet e USB, e módulo controlador.

5.3 SLAG

Para completar a implementação de uma DWCN foi necessário desenvolver a respectiva SLAG, a

componente de mais alto nível no projecto, que é responsável pela conversão entre as tramas

genéricas SL do DomoBus (provenientes de outras SLA) e a rede DWCN. De modo a se poder testar

74

mais eficientemente a SLAG desenvolvida e por conseguinte todo o sistema DWCN que esta interliga

desenvolveram-se também alguns programas auxiliares, destinados a serem utilizados no SL.

5.3.1 Software

O software que implementa a SLAG foi desenvolvido recorrendo a chamadas de sistema POSIX

pelo que deverá poder ser compilado para sistemas operativos compatíveis com tais normas. No

entanto existe uma componente que foi implementada para um hardware específico (descrito no

próximo capítulo) que foi a comunicação SPI que apenas será suportada no hardware apresentado

(ou compatível) e em sistemas operativos Linux (ou Unix) pois o acesso ao dispositivo é feito

recorrendo ao sistema de ficheiros deste sistema operativo (/dev/<device>). Para tornar o software

compatível com outro hardware será necessário adaptar a biblioteca RF24 que faz a interface entre a

camada de rede (RF24NetworkLayer) com o módulo RF físico através do chip BCM2835 ou alterar o

ficheiro bcm2835.c para o novo chip que suporte a comunicação SPI mantendo a sua interface

inalterada.

O núcleo do software que implementa a SLAG é uma classe que implementa a lógica necessária

na conversão de tramas em ambos os sentidos. Esta classe interliga as bibliotecas necessárias que

oferecem suporte a sockets, interface SPI, bibliotecas RF24 e RF24NetworkLayer entre outras

auxiliares. Para implementar esta classe existem diversos ficheiros main em que cada um a inicializa

de uma forma diferente para utilizações diferentes que se resumem em duas principais: com

utilização de um módulo gateway externo (por ethernet ou USB) ou com ligação directa ao módulo RF

via SPI. Independentemente do protocolo de comunicação utilizado, as principais funcionalidades são

comuns a todos (ver Figura 5.9) nomeadamente a interpretação dos dados CL e SL e o envio de

dados para o CL e para o SL, sendo depois as entradas e saídas destas funções adaptadas ao

protocolo utilizado.

Figura 5.9 – Métodos da classe gateway para lidar com as comunicações

A classe, denominada Gateway, é utilizada de uma forma muito simples, em apenas dois passos:

inicialização e ciclo de comunicações (ver Figura A6.1 em anexo). É suposto depois de inicializada

ser chamado o método comms() num ciclo infinito de modo a manter a operacionalidade do

programa. Todas as chamadas de sistema bloqueantes utilizam temporizadores de modo a que,

quando integrado num programa (simulado pelos ficheiros main apresentados) permita a este ter o

seu ciclo principal de execução sincronizado com a SLAG e poder realizar outras tarefas.

A Makefile é responsável pela criação dos diferentes executáveis (SLAG_ETH, SLAG_USB e

SLAG_RF) com base na classe Gateway e ainda pelos seguintes programas auxiliares:

XXTEA, que permite testar a encriptação e desencriptação de dados pela linha de comandos

75

NETWORK_SECURITY que permite alterar os parâmetros de segurança numa rede DWCN

para evitar os riscos associados ao fazê-lo manualmente nó a nó, que poderiam resultar

numa rede parcialmente bloqueada (se diferentes controladores ficassem com diferentes

configurações).

BROADCAST_CONFIG que permite configurar os módulos gateway ethernet para a rede

(ethernet) onde se irão inserir através de tramas broadcast.

Estes programas auxiliares apresentam-se como exemplos do que poderá vir a ser desenvolvido

pelos níveis superiores à SLAG, e não se enquadram directamente nos objectivos deste projecto.

Sempre que se achou proveitoso isolaram-se as funções desenvolvidas que poderão ser reutilizadas

(como por exemplo o envio de tramas SL) numa biblioteca denominada DWCNLib de modo a facilitar

implementações futuras que possam interagir com este projecto.

Por fim, de modo a facilitar os testes feitos com a rede DWCN implementada e dado que não

existem SLUI ou supervisores implementados no SL que possam ser utilizados com este projecto, foi

desenvolvida uma pequena interface gráfica (recorrendo a um pacote de software LAMP: Apache,

mySQL e PHP) que permite injectar tramas SL e exibir as respectivas respostas de uma forma

intuitiva assim como implementa algumas funcionalidades adicionais úteis para depuração (ver Anexo

A6.1).

5.3.2 Hardware

O módulo de supervisão utilizado para desenvolver a SLAG foi um Raspberry Pi por este incluir

num único sistema de baixo custo (inferior a 40€) uma interface ethernet 10/100, portos USB e SPI

através do chip BCM2835 da Broadcom. Adicionalmente é um sistema capaz de efectuar mais tarefas

paralelamente como correr outras SLA (ou múltiplas SLAG) e implementar a pilha de software LAMP

que oferece o suporte necessário a uma interface gráfica. Pelos motivos apresentados achou-se ser a

plataforma ideal para testar as componentes do projecto relacionadas com o SL, recorrendo ao

sistema operativo Raspbian (Linux kernel 3.12). Adicionalmente o código desenvolvido para a SLAG

foi também testado num Asus EEE com um processador Intel Atom N270 1.6GHz utilizando o sistema

operativo Debian Wheezy (Linux kernel 3.2) recorrendo a módulos gateway ethernet e USB para

fornecerem a interface necessária com o módulo RF nRF24L01+.

76

Conclusões

O presente projecto constitui um complemento do sistema DomoBus, o qual já inclui interfaces

com o utilizador e supervisores, de modo a implementarem a lógica necessária ao controlo da rede

de sensores e actuadores. O trabalho desenvolvido implementou controladores de baixo-nível para o

protocolo DomoBus cujas principais vantagens se encontram na sua modularidade, que permite a

implementação de redes dinâmicas que poderão evoluir (ao contrário das soluções estáticas

encontradas no mercado), e no baixo custo inerente à arquitectura escolhida tanto para os módulos

controladores como para os módulos gateway e de supervisão que permitem mais facilmente

construir diversas redes de sensores e actuadores de grandes dimensões. Os controladores,

principalmente ao nível da sua comunicação sem-fios, encontram-se a meio caminho entre soluções

demasiado simples que só permitem interacções reduzidas entre dispositivos muito limitados (como

por exemplo X10 ou Insteon) e soluções demasiado complexas para as simples tarefas que se

pretende que executem (como controladores que recorrem a tecnologias de comunicação como Wi-Fi

ou ZigBee) e que por isso acabam por ser demasiado dispendiosas para implementar redes com um

grande número de dispositivos. Neste projecto tentou-se encontrar um novo balanço entre

funcionalidades, fiabilidade, escalabilidade e custo final que não se encontra disponível actualmente.

Durante toda a fase de implementação deste projecto deu-se especial ênfase à modularização do

software desenvolvido recorrendo à utilização de classes, à apresentação de documentação

detalhada e à exportação de funções que poderão ser reutilizadas através da biblioteca denominada

DWCNLib. Foram também desenvolvidos programas a título de exemplo para se integrarem nos

níveis superiores do DomoBus. Esta abordagem teve como objectivo tirar proveito das características

modulares da arquitectura implementada, dado que poderão ser desenvolvidos no futuro novos

módulos de rede ou de dispositivos de modo a estender as capacidades actuais. Pretende-se assim

facilitar a reutilização futura das componentes deste projecto e a integração do mesmo com outros

projectos no contexto do DomoBus.

Uma desvantagem encontrada no sistema desenvolvido é a da que, ao contrário de quase todas

as tecnologias domóticas sem-fios abordadas no capítulo do estado da arte, esta não contempla a

existência de controladores móveis dada a natureza da topologia de rede escolhida. No entanto, não

se valorizou esta limitação uma vez que todos os controladores móveis analisados têm como

objectivo implementar uma interface com o utilizador, geralmente sob a forma de um telecomando, o

que no protocolo DomoBus é feito num nível superior e que poderá perfeitamente ser implementado

num dispositivo móvel, recorrendo a tecnologias como Wi-Fi ou UMTS. Adicionalmente, nada impede

a implementação de novos protocolos de comunicação sem-fios sobre a rede de controladores

proposta, o que já foi de certa forma feito através da utilização de sensores de infravermelhos, de

modo a permitir a utilização de telecomandos directamente nos controladores.

Qualitativamente, perante os testes efectuados recorrendo a 8 protótipos, o sistema mostrou um

desempenho adequado às expectativas na medida em que se encontra funcional e não apresenta

atrasos temporais perceptíveis (no contexto das diferentes redes de teste implementadas que

77

variaram entre 1 e 3 níveis). Todas as NApps e respectivos sensores e actuadores agiram como

esperado em todas as combinações testadas, e todas as funcionalidades (Direct Link, temporizações,

algoritmo de procura de endereço, algoritmo de regeneração da rede, configurações, grupos, etc.)

foram testadas com sucesso.

Quantitativamente, mostrou-se muito difícil testar o módulo controlador de modo a obter dados

úteis e representativos devido às características modulares do mesmo. Fazer análises quanto à taxa

máxima a que um módulo controlador consegue receber mensagens, o tempo que uma mensagem

demora a se propagar na rede ou a carga máxima que a rede poderá suportar (nomeadamente na

raiz e nos nós da primeira camada que serão em principio os mais afectados) irá depender das

configurações específicas do controlador, pois ao fim de receber a terceira trama (enchendo o buffer

do módulo RF) o que irá ter impacto nos cálculos será o tempo necessário ao módulo controlador

para retirar tramas de dados e processá-las, o que irá estar directamente relacionado com o número

de funcionalidades que estiverem configuradas e a frequência das mesmas. Adicionalmente existem

várias configurações (como o número de tentativas de retransmissão ou o tempo de espera entre

estas) que são configuradas pelo SL o que resulta num número elevado de possibilidades para serem

analisadas. Por sua vez, os consumos de energia de cada módulo também são fortemente

influenciados pelas configurações de cada módulo controlador, não só nas funcionalidades que

estará a implementar e na sua frequência, como nas diversas configurações fornecidas pelo SL que

permitem poupar energia desligando certos subsistemas do microcontrolador ou fazendo com que o

mesmo entre em modos de poupança de energia. Mais uma vez, estes diferentes modos de operação

resultam num elevado número de possibilidades a ter em conta. Pelos motivos apresentados, não se

investiu na obtenção de dados quantitativos em parte pela sua fraca expressividade (na medida em

que seriam apresentados intervalos de valores apenas para certas situações muito específicas) e em

parte por falta de tempo para implementar ferramentas de teste automatizadas que permitissem

auxiliar a obtenção de dados em massa para todas as diferentes configurações.

Fica no entanto como trabalho futuro testar uma rede com um número elevado de controladores e

verificar o seu funcionamento para um fluxo elevado de dados, nomeadamente nos nós mais perto da

raiz. É expectável que a partir de uma certa taxa de recepção de novas tramas de dados, para cada

nó, o número de funcionalidades que este implementa assim com a sua frequência de funcionamento

terão um impacto directo no número máximo de tramas que conseguirá encaminhar por unidade de

tempo. Isto poderá obrigar a que os nós da primeira camada não sejam demasiadamente

sobrecarregados com dispositivos, a partir do momento em que um dos ramos que este origina

exceda um dado tamanho ou que algum nó seu descendente comunique dados a uma taxa superior a

um certo limite.

Não obstante os vários melhoramentos que poderão vir a ser realizados de futuro, a solução

implementada apresenta uma grande utilidade ao sistema DomoBus na medida em que permite

expandir as funcionalidades deste, recorrendo a controladores projectados para satisfazer os

requisitos específicos à integração do DomoBus em ambientes super-automatizados e oferecendo a

capacidade de comunicação sem fios.

78

Bibliografia

[1] LuísFilipe Gomes da Silva, Universidade de Aveiro, “Automação em Ambientes Residenciais”

2008. Disponível em https://ria.ua.pt/bitstream/10773/2527/1/2010000495.pdf

[2] Clipsal, “C-Bus Wireless Systems: Control and Management System”, 2006. Disponível em

http://www.noushouse.com.au/brochures/Clipsal/Wireless/C-Bus%20Wireless%20Brochure2.pdf

[3] Serge Robin and Christian Gossé, KNX Scientific Conference, “KNX RF Multi”, 2010. Disponível

em http://www.knx.org/fileadmin/downloads/05%20-%20KNX%20Partners/03%20-

20Becoming%20a%20KNX%20Scientific%20Partner/2010-

11%20Conference/Presentations/Session%205.pdf

[4] Joost Demarest, Wireless Congress Munich, “Konnex Radio Frequency”, 2005. Disponível em

http://www.knx.org/media/docs/downloads/What-is-KNX/00%20-

%20General%20KNX%20and%20KNX%20Association/KNX%20RF.zip

[5] Dr. Thomas Weinzierl, Weinzierl Engineering, “Stack Implementation for KNX-RF”, 2005.

Disponível em http://www.knx.org/media/docs/downloads/KNX-Partners/03%20-

%20Becoming%20a%20KNX%20Scientific%20Partner/2005-

9%20Scientific%20Conference%20Papers%20Pisa/06_Weinzierl%20Eng_KnxRf.pdf

[6] Reinisch, Granzer, Neugschwandtner, Praus, Kastner, KNX Scientific Conference, “Wireless

Communication in KNX/EIB”, 2006. Disponível em

https://www.auto.tuwien.ac.at/downloads/knxsci06/reinisch-wireless-knxsci06-website.pdf

[7] Woo Suk Lee, Hanyang University, Automation Science and Engineering “KNX — ZigBee

gateway for home automation” 2008

[8] Joost Demarest, KNX Association Diegem , “KNX RF–Then, Now, Future” 2012. Disponível em

http://www.knx-professionals.nl/UploadBestanden/01%20Joost%20Demarest%20-

%20KNX%20Association.pdf

[9] Richard Newman , University of Florida - Powerline Communication, “CEBus”, 2013. Disponível

em http://www.cise.ufl.edu/~nemo/plc/slides/part_5c_CEBus.ppt

[10] Echelon Corporation, “Introduction to the LonWorks System (Version 1.0)”, 1999. Disponível

em https://support.dce.felk.cvut.cz/pub/hanzalek/_private/ref/IntroLonWorks.pdf

[11] Echelon Corporation, “LonTalk Protocol Specification (Version 3.0)”, 1994. Disponível em

http://www.enerlon.com/JobAids/Lontalk%20Protocol%20Spec.pdf

[12] Leo Selavo, University of Virginia, “Wireless Sensor Networks – Introducing Zigbee”, 2006.

Disponível em http://www.cs.virginia.edu/cs651-wsn/lectures/Zigbee_Intro_v5.ppt

[13] “ZigBee”, acedido a 12/07/2014. Disponível em http://en.wikipedia.org/wiki/ZigBee

[14] Ian Poole, “ZigBee Technology Tutorial”, acedido a 12/07/2014. Disponível em

http://www.radio-electronics.com/info/wireless/zigbee/zigbee.php

[15] “IEEE 802.15.4”, acedido a 12/07/2014. Disponível em

http://en.wikipedia.org/wiki/IEEE_802.15.4

[16] José Mauricio Santos Pinheiro, “As redes com ZigBee”, acedido a 16/07/2014. Disponível em

http://www.projetoderedes.com.br/artigos/artigo_zigbee.php

79

[17] Dr. José A. Gutierrez, Eaton Corporation, “IEEE Std. 802.15.4 – Enabling Pervasive Wireless

Sensor Networks”, 2005. Disponível em http://www.cs.berkeley.edu/~prabal/teaching/cs294-11-

f05/slides/day21.pdf

[18] ZigBee Alliance, “ZigBee and Wireless Radio Frequency Coexistence”, 2007. Disponível em

https://docs.zigbee.org/zigbee-docs/dcn/07-5219.PDF

[19] “KillerBee”, acedido a 22/09/2014. Disponível em https://code.google.com/p/killerbee/

[20] Digi, "XBee, ZigBee, and 802.15.4 Compatibility", acedido a 12/07/2014. Disponível em

http://www.digi.com/support/kbase/kbaseresultdetl?id=2158

[21] Digi, “XBee Family Features Comparison”, 2013. Disponível em

http://www.digi.com/pdf/chart_xbee_rf_features.pdf

[22] Z-Wave, “Z-Wave Technical Basics (Version 01.06.2011)”, 2011. Disponível em

https://www.domotiga.nl/attachments/download/1075/Z-Wave%20Technical%20Basics-small.pdf

[23] Behrang Fouladi, Sahand Ghanoun, "Security Evaluation of the Z-Wave Wireless Protocol",

2013. Disponível em

http://research.sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluatio

n%20of%20Z-Wave_WP.pdf

[24] "openZwave", acedido a 13/08/2014. Disponível em http://www.openzwave.com/

[25] Rongjun, "Z-Wave security model". Acedido a 22/09/2014. Disponível em

http://rongjun21600.blogspot.pt/2008/06/z-wave-security-model.html

[26] “MiOS FAQ”. Acedido a 12/07/2014. Disponível em: http://faq.mios.com/content/1/6/en/how-

many-z_wave-devices-can-be-added.html

[27] Insteon, “Insteon Whitepaper: The details (Version 2.0)”, 2013. Disponível em

http://www.insteon.com/pdf/insteondetails.pdf

[28] Insteon, “Insteon Whitepaper: Compared (Version 2.0)”, 2013. Disponível em

http://www.insteon.com/pdf/insteoncompared.pdf

[29] "BLE Overview". Acedido a 17/07/2014. Disponível em: http://www.summitdata.com/blog/ble-

overview/

[30] Nordic Semiconductor, “nRF905 Single Chip 433/868/915 MHz Transceiver (Revision 1.5)”,

2008. http://www.nordicsemi.com/eng/nordic/download_resource/8075/1/81091541

[31] HopeRF Electronic, “RFM12B Universal ISM Band FSK Trancseiver“, 2006. Disponível em

http://www.hoperf.com/upload/rf/RFM12B.pdf

[32] Hope RF Electronic, “RFM22B/23B ISM Transceiver Module (V1.1)”, 2006. Disponível em

https://www.sparkfun.com/datasheets/Wireless/General/RFM22B.pdf

[33] Renato Nunes, International Conference on Computer, Communications and Control

Technologies, “A Communication Infrastructure for Home Automation”, 2004. Disponível em

http://domobus.net/papers/04-CCCT04.pdf

[34] Renato Nunes, 8th International Congress on Electrical Engineering, “DomoBus - A New

Approach to Home Automation”, 2003. Disponível em http://domobus.net/papers/03-CLEEE03.pdf

80

[35] Renato Nunes, IADIS International Conference on Applied Computing, “Implementing Tiny

Embedded Systems with Networking Capabilities”, 2005. Disponível em

http://domobus.net/papers/05-IADIS05-long.pdf

[36] Renato Nunes, MELECON 2006 - The 13th IEEE Mediterranean Electrotechnical Conference,

“Decentralized Supervision for Home Automation”, 2006. Disponível em

http://domobus.net/papers/06-MELE06.pdf

[37] Renato Nunes, IADIS Conferência Ibero-Americana WWW/Internet 2004, “Modelo de

especificação e programação de um sistema domótico”, 2004. Disponível em

http://domobus.net/papers/04-CIAWI04.pdf

[38] Renato Nunes, AveiroDomus, “DomoBus - The User in Control. A Domótica e a Casa do

Futuro”, 2006. Disponível em http://domobus.net/docs/06-AveiroDomus06.pdf

[39] Renato Nunes, “DomoBus Architecture”, 2014.

[40] Neil, CGAR Lab - University of Victoria , “nRF24L01 Report”. Acedido a 16/07/2014.

Disponível em: http://nrqm.ca/nrf24l01/

[41] Microchip Technology Inc., “ENC28J60 Data Sheet (DS39662A)”, 2004. Disponível em

http://ww1.microchip.com/downloads/en/devicedoc/39662a.pdf

[42] STMicroelectronics, “L7800 series - Positive voltage regulators (Rev. 13)”, 2006. Disponível

em http://datasheet.octopart.com/L7805CV-STMicroelectronics-datasheet-7264666.pdf

[43] BCD Semiconductor, “AZ1117 1A Low Dropout Linear Regulator Rev. 2.8”, 2012

[44] Atmel , “ATmega48PA/88PA/168PA/328P (Rev. 8161D–AVR–10/09)”, 2010. Disponível em

http://www.atmel.com/Images/doc8161.pdf

[45] Martin, "Biquad Antenna Construction". Acedido a 22/09/2014. Disponível em

http://martybugs.net/wireless/biquad/

[46] Prof. Trevor Marshall, "BiQuad 802.11b Antenna". Acedido a 22/09/2014. Disponível em

http://www.trevormarshall.com/biquad.htm

[47] Elias Yarrkov, “Cryptanalysis of XXTEA”, 2010. Disponível em

http://eprint.iacr.org/2010/254.pdf

[48] David J. Wheeler, Roger M. Needham, Cambridge University, “Correction to XTEA”, 1998.

Disponível em http://www.movable-type.co.uk/scripts/xxtea.pdf

[49] Atmel, “Tips and Tricks to OptimizeYour C Code for 8-bit AVR Microcontrollers”, 2011.

Disponível em http://www.atmel.com/images/doc8453.pdf

[50] Texas Instruments, “Z-Stack Developer’s Guide”, 2011. Disponível em

http://webstaff.itn.liu.se/~qinye/tne090/Z-Stack%20Developer%27s%20Guide.pdf

[51] FTDI, “FT232RUSB UART IC Datasheet Version 2.10”, 2010. Disponível em

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

[52] Nordic Semiconductor , “nRF24L01+ Single Chip 2.4GHz Transceiver - Product Specification

v1.0”, 2008. Disponível em

https://www.nordicsemi.com/eng/nordic/download_resource/8765/2/1512422

A-1

Anexos

A1. Bibliotecas utilizadas

A1.1. Integralmente

Bibliotecas base do Arduino - http://arduino.cc/en/Reference/Libraries Utilizadas para oferecer um sistema compatível com a plataforma Arduino. Incluem-se aqui as bibliotecas SPI e EEPROM

RF24 por J.Coliz (maniacbug@ymail.com) - https://github.com/maniacbug/RF24 Implementa uma classe para aceder ao chip nRF24L01+ e as suas funcionalidades básicas.

DHT por Mark Ruys (mark@paracas.nl) - https://github.com/markruys/arduino-DHT Implementa uma classe para comunicar com sensores de temperatura e humidade DHT11, DHT22, AM2302 e RHT03.

OneWire por Paul Stoffregen (paul@pjrc.com) - http://www.pjrc.com/teensy/td_libs_OneWire.html

Biblioteca para comunicar com dispositivos OneWire da Dallas (requisito da biblioteca DallasTemperature)

DalltasTemperature por (originalmente) Miles Burton (miles@mnetcs.com) - https://github.com/scott-42/DallasTempOneWireLib

Implementa uma classe que consegue comunicar com vários dispositivos DS18B20, DS18S20 e DS1822 da Dallas num barramento a utilizar apenas um porto do microcontrolador

EtherCard por (originalmente) Pascal Stang - https://github.com/jcw/ethercard

Conjunto de bibliotecas que permitem comunicar com módulos de rede que utilizem o chip ENC28J60 da Microchip

XXTEA por David Wheeler and Roger Needham - http://en.wikipedia.org/wiki/XXTEA

Algoritmo utilizado para codificar e descodificar dados foi o proposto originalmente

jQuery por jQuery Foundation - http://jquery.com/ Framework utilizada para construir o GUI em Javascript nomeadamente em chamadas AJAX e na interactividade dos elementos HTML.

bcm2835 por Mike McCauley - http://airspayce.com/mikem/bcm2835/

Biblioteca utilizada para simplificar acesso ao portos de uso geral e SPI do Raspberry Pi

A1.2. Parcialmente

RF24Network por J.Coliz (maniacbug@ymail.com) - https://github.com/maniacbug/RF24Network Utilizou-se o método de criar endereços de baixo nível de modo a fornecer endereços com suficientes transições lógicas de modo a serem mais imunes ao ruído.

baseConverter por Faisal Salman - https://gist.github.com/faisalman Utilizou-se este código como base do conversor numérico auxiliar em Javascript

IRremote por Ken Shirriff - https://github.com/shirriff/Arduino-IRremote

Reduziu-se a biblioteca apenas à leitura de commandos genéricos independentemente do protocolo utilizado

A-2

A2. Preços de módulos RF analisados

Na listagem de produtos que se apresenta de seguida só se consideraram dispositivos que

comuniquem por SPI ou I2C. Esta listagem não pretende ser exaustiva mas apenas uma amostra dos

diferentes produtos que as empresas mais presentes no mercado disponibilizam e os respectivos

preços. A lista encontra-se ordenada pelo chip que integra o módulo vendido pelo fabricante e

poderão existir diferenças nas especificações técnicas dentro de módulos com o mesmo chip como

por exemplo o tipo de antena suportado. Deu-se maior importância ao chip em si do que aos detalhes

de implementação pois é este que define grande parte das especificações técnicas que determinam

as principais funcionalidades do módulo RF e que acaba por ter mais peso no preço final do produto.

Chip Fabricante Modelo Loja Preço

RN131

Microchip (Roving) RN-131 PICtail Mouser 37.31 €

Microchip (Roving) RN131C/RM Farnell 34.95 €

Microchip (Roving) WIFLY GSX (RN131C/RM) Digikey 37.36 €

RN171

Microchip (Roving) RN171XVS-I/RM Farnell 28.01 €

Sparkfun RN-XV WiFly Module Sparkfun 27.75 €

Microchip (Roving) RN171XVW-I/RM Digikey 33.35 €

MRF24WB0M

Microchip MRF24WB0MA/RM Digikey 22.64 €

Microchip MRF24WB0MA/RM AliExpress 21.77 €

mikroElektronika MIKROE-1135 Mouser 37.35 €

CC3000

Sparkfun WRL-12072 Sparkfun 27.75 €

Free Trade CC3000 Wifi Shield

(MD0371) AliExpress 24.21 €

mikroElektronika MIKROE-1527 Mouser 34.86 €

WizFi210

WIZnet WizFi210 Mouser 28.43 €

n.d. WizFi Shield Seedstudio 43.62 €

n.d. WizFi Shield AliExpress 44.25 €

WICED Murata SyNode 8200 Digikey 23.70 €

Murata SyNode 8000 Mouser 20.09 €

WF111 BlueGiga WF111-E DigiKey 18.78 €

BlueGiga WF111-E Mouser 21.79 €

WF121 BlueGiga WF121-A Mouser 24.90 €

BlueGiga WF121-A Digikey 25.69 €

Tabela A2.1 - Listagem de alguns módulos Wi-Fi disponíveis para os principais chips apresentados. A média dos valores fica em 29,46€ e a mediana em 27,75€

Quanto aos módulos RF ZigBee existem demasiadas versões com demasiadas características

pelo que se optou por não representar os módulos mais comuns, denominados XBee, que se

encontram todos no mercado com um preço entre 20 e 30€. Assim apresentam-se apenas os

módulos ZigBee com o menor preço encontrados que são implementados com o chip TI CC2530.

Chip Fabricante Modelo Loja Preço

CC2530 n.d. n.d. Aliexpress 11.73 €

n.d. n.d. Aliexpress 14.89 €

Tabela A2.2 – Listagem de módulos ZigBee com menor preço encontrados no mercado

A-3

Chip Fabricante Modelo Loja Preço

CC254x

Panasonic PAN1720 Farnell 12.36 €

Panasonic PAN1720 Mouser 14.19 €

n.d. HM-10 Aliexpress 11.26 €

CC256x

Panasonic PAN1325B Digikey 12.16 €

n.d. n.d. Aliexpress 14.08 €

Panasonic PAN1325B Mouser 11.64 €

nRF51822

RedBear

Seedstudio 31.70 €

Free Trade MD0325 Aliexpress 6.67 €

n.d. BLE Micro Seedstudio 13.41 €

nRF8001 Olimex MOD-nRF8001 Olimex 9.95 €

Adafruit nRF8001 Breakout Adafruit 15.40 €

Tabela A2.3 - Listagem de alguns módulos que implementem chips Bluetooth LE. A média dos valores fica em 13,89€ e a mediana em 12,36€

Chip / Versão Fabricante Modelo Loja Preço

nRF24L01+

DX NRF24L01 Aliexpress 0.81 €

n.d. n.d. Seedstudio 2.30 €

Olimex MOD-NRF24LR Mouser 13.94 €

nRF24L01+ LNA + PA

n.d. n.d. Aliexpress 4.03 €

n.d. n.d. Seedstudio 5.47 €

Tabela A2.4 – Listagem de alguns módulos RF com o chip nRF24L01+. A média dos valores fica em 5.68€ e a mediana em 2.30€ para módulo com antena plana e em 4.75€ de média para versão com LNA, PA e antena SMA

Chip Fabricante Modelo Loja Preço

nRF905

Freezone99 FZ0124 Aliexpress 4.98 €

n.d. n.d. Hobbyking 6.58 €

n.d. PTR8000 Amazon 7.14 €

Tabela A2.5 – Listagem de módulos RF com o chip nRF905. A média de valores fica em 6.23€ e a mediana em 6.58€

Rádio / Chip Fabricante Modelo Loja Preço

RFM12B

Quasar UK RFM12B-433/RFM12B-866 Farnell 9.96 €

Sparkfun WRL-12031 Sparkfun 5.51 €

n.d. RFM01 Aliexpress 8.45 €

Hope RF RFM12B Futurlec 7.06 €

RFM22B

n.d. n.d. Aliexpress 9.92 €

n.d. n.d. Futurlec 10.23 €

Sparkfun WRL-10153 Sparkfun 9.47 €

CC1000 n.d. RF19 VegaRoboKit 3.85 €

Propox MMcc1000 Propox 13.42 €

CC1101

Amber Wireless AMB8420 Farnell 21.27 €

Anaren A1101R08A00GM Farnell 11.56 €

Freezone99 FZ0691 Aliexpress 5.69 €

Tabela A2.6 – Listagem de módulos RF RFM12B, RFM22B e módulos baseados no chip CC1000 e CC1101. As médias de preços são respectivamente 7.75€, 9.87€, 8.64€ e 12.84€

A-4

A3. Comparação de módulos RF

RFM12B RFM22B Bluetooth Bluetooth LE Wireless ZigBee nRF905 nRF24L01+ TI CC1000

Especificação IEEE

802.15.1

802.11 a/b/g/n 802.15.4

Alcance máximo < 300m < 800m < 100m < 50m < 75m <100m ou

<1.5km <300m

<200m ou < 1km

<100m

Velocidade de Transmissão

115.2 kb/s < 256 kb/s < 3 Mb/s < 1 Mb/s < 54 Mb/s 250 kb/s 50 kb/s 2 Mb/s 76.8 kb/s

Frequência 433, 868, 915

MHz

433,470,868,91

5 MHz 2.4 GHz 2.4 GHz 2.4 GHz 2.4 GHz

433, 868, 915

MHz 2.4 GHz

315, 433, 868, 915 MHz

Frequência mínima 860.48 MHz 848 MHz 2.4 GHz 2.4 GHz 2.412 GHz 2.4 GHz 863 MHz 2.4 GHz 300 MHz

Frequência máxima 879.51 MHz 888 MHz 2.524 GHz 2.524 GHz 2.484 GHz 2.485 GHz 873 MHz 2.4835 GHz 1000 MHz

Modulação FSK FSK, GFSK,

OOK GFSK GFSK

DSSS, CCK, OFDM

DSSS, OQPSK GFSK GFSK FSK OOK

Protocolos Implementados

EzyMac Bluetooth (V1.0

até V4.1) Bluetooth Low

Energy IP, TCP, UDP...

ZigBee, IP ShockBurst Enhanced

ShockBurst SmartRF

Interface SPI SPI SPI SPI SPI SPI SPI SPI SPI

Encriptação (sem

encriptação) (sem

encriptação) SAFER/E0/AES AES-128

WPA-PSK, AES-128

AES (128 bit) (sem

encriptação) (sem

encriptação) (sem

encriptação)

Suporte de tramas software hardware hardware hardware hardware hardware hardware hardware software

Tamanho das tramas 66 Bytes 64 Bytes 672 Bytes (up to

65535) < 23 Bytes (payload)

1500 Bytes 1 to 104 Bytes

(payload) 1 to 32 Bytes

(payload) 1 to 32 Bytes

(payload) 1 to 128 Bytes

Manipulação de tramas software hardware hardware hardware hardware hardware hardware hardware software

Camada de rede software software hardware hardware hardware hardware software hardware software

Network groups /canais 250 23 n.d. 40 11 16 170 126 n.d.

Número máximo de nós n.d. n.d. 8 n.d. > 1000 > 1000 n.d. > 1000 n.d.

Topologias de rede implementadas

p2p p2p p2p, scatternet p2p, star-bus p2p, star p2p, star, mesh p2p p2p, 1:6 star p2p

Alimentação 2.2-3.8 V 1.8-3.6 V 1.7 - 3.6 V 2.0 - 3.6 V 3.1 - 3.6 V 2.8 - 3.4 V 1.9-3.6 V 1.9-3.6 V 2.1-3.6

Corrente standby 0.3 uA 0.45 uA 0.8 uA 0.5 uA < 2uA < 10 uA 2.5 uA 0.9 uA 0.2 uA

Corrente RX 14 mA 18.5 mA 47 mA 15.8 mA 215 mA 55 mA 12.5 mA 8.4 mA 7.4 mA

Corrente TX 27 mA 30 mA 57 mA 18.6 mA 219 mA 215 mA 30 mA 8.0 mA 10.4 mA

Potência de emissão máxima

+5 dBm +20 dBm +4 dBm

(Classe 2) +3 dBm

+18 dBm (11 Mb/s)

+20 dBm (ZigBee PRO)

+10 dBm +20 dBm

(versão c/ amp.) +10 dBm

Sensibilidade máxima do receptor

-110 dBm -121 dBm -86 dBm

(Classe 2) -98 dBm

-88 dBm (11 Mb/s)

-98 dBm (ZigBee PRO)

-100 dBm -104 dBm

(versão c/ amp.) -110 dBm

Esta tabela apresenta-se apenas como uma referência para comparação entre as tecnologias. Alguns campos (como por exemplo o consumo de energia) foram retirados de modelos específicos enquanto que propriedades como a encriptação reflectem o que se encontrou de melhor, independentemente do modelo. Quando são referidas topologias de rede são as que podem ser suportadas directamente pelo hardware Existe ZigBee para outras frequências que não foram consideradas por serem pouco utilizadas no contexto da domótica

A-5

A4. Módulo Controlador

A4.1. Fluxograma principal

Figura A4.1 – Fluxo principal do módulo controlador simplificado

A4.2. Reestruturação da rede

Figura A4.2 – Exemplo do algoritmo de re-estruturação da rede. Endereços em representação octal

Se por exemplo, tendo em conta a Figura A4.2, o nó 1 deixa de estar operacional por um período

superior ao configurado, os nós 11, 21, 121 e 321 irão tentar reorganizar-se de modo a se inserirem

A-6

de novo no segmento da árvore que ainda se mantém conectado à respectiva SLAG. A

reestruturação irá iniciar-se pelo nó 11 (o primeiro a reagir) que irá assumir o endereço do seu pai (1)

e verificará se consegue ligação à SLAG. Partindo do pressuposto que consegue comunicar com o nó

0, assume o endereço [1] como seu e quando os restantes nós (21,121,321) entrarem no processo de

regeneração da rede verificarão que o problema já foi resolvido e abortam, mantendo os mesmos

endereços. Caso não consiga comunicar com o nó 0 assumindo o endereço 1, assume o endereço

555 e vai descendo a árvore em busca de uma ligação à SLAG. Os nós 21, 121 e 321 irão depois

seguir os mesmos passos (tentarem fazer-se passar pelo seu pai e se não resultar procuram um novo

endereço no mesmo canal RF). Se o nó 1 era o único capaz de fornecer uma ligação à SLAG (devido

à sua proximidade) então os 4 nós que ficaram desconectados ficarão à procura de endereço até

encontrarem um. Sempre que um nó consegue contactar a SLAG após uma mudança de endereço,

notifica-a com uma mensagem especial a referir o seu antigo endereço para que o SL possa tomar

conta da ocorrência e proceder às reconfigurações necessárias

A4.3. Pesquisa por endereços

Figura A4.3 – Fluxograma simplificado do algoritmo de pesquisa por endereços

A-7

A4.4. Camadas de rede

Figura A4.4 – Diferentes camadas de rede e a sua relação com a encriptação dos dados

A4.5. NApps - Configurações

Funcionalidade Aplica-se a Descrição

Start Sensores e actuadores Define se a aplicação irá iniciar no próximo ciclo ou não

StartAt Sensores e actuadores Define se a aplicação se encontra temporizada para um atraso fixo antes de iniciar

RepeatAt Sensores e actuadores Define se a aplicação se encontra temporizada para uma repetição após terminar. Funciona em conjunto com a funcionalidade StartAt

Threshold Sensores

Define se o valor lido pelo sensor será comparado com a leitura anterior e com um limite pré-definido para saber se passou esse limite. Só nesse caso é que comunicará o valor ao supervisor

Direct Link Sensores

Define se quando existe um valor para reportar para o supervisor este terá que ser previamente enviado para outro módulo controlador na mesma rede. O controlador e dispositivo de destino assim como a propriedade e o seu valor são previamente configurados

PropertyChange Sensores e Actuadores Define se existiu alguma alteração a propriedades afectas ao dispositivo a que se refere

OnlyOnce Sensores e Actuadores

Define se no final da execução o sinalizador Start é desactivado para forçar a aplicação a só correr quando ocorrem alterações nas propriedades respectivas ou quando alterado explicitamente pelo utilizador. Faz mais sentido utilizar-se com actuadores para certificar que as acções são aplicadas apenas uma vez e não ficam a ser aplicadas continuamente

Tabela A4.1 – Diferentes opções que cada aplicação implementa através do objecto genericApp

A-8

A4.6. Fluxograma da temporização de NApps

Figura A4.5 – Fluxograma do código do objecto genericApp que gere as temporizações. A azul encontram-se estados que dependem de sinalizadores únicos a cada dispositivo. A vermelho a variável que decide se a aplicação irá

correr no ciclo actual.

A-9

A4.7. Circuito-exemplo do protótipo

Figura A4.6 – Circuito exemplo de um módulo controlador (62mm x 80mm)

Tabela A4.2 – Custo do protótipo do módulo controlador

Qt. Componente Preço

2 22 pF Condensador cerâmica 0,01 €

2 0.1 uF Condensador cerâmica 0,01 €

1 Cristal 16 MHz 0,06 €

1 10k Resistencia 1/4 W 0,01 €

1 Placa PCB pré-furada 2.54mm (7x3cm) 0,51 €

1 Socket 28-pin 0,09 €

1 Atmel ATmega328P 1,75 €

17 4 pin 2.54mm header fêmea 0,08 €

1 3 pin 2.54mm header fêmea 0,06 €

1 Módulo NRF24L01+ 0,92 €

4,80 €

A-10

A4.8. Circuitos-exemplos de módulos de alimentação

Figura A4.7 – Circuito do módulo de alimentação por USB (esquerda) e do módulo de alimentação por conector DC de polaridade positiva ou terminal com parafuso (direita).

A4.9. Mapeamento dos portos

Porto Microcontrolador

Porto ATMega

Função Porto Módulo Controlador

1 RESET

2 PD0 DIGITAL/RX 1

3 PD1 DIGITAL/TX 2

4 PD2 DIGITAL 3 *

5 PD3 DIGITAL/PWM 4 *

6 PD4 DIGITAL 5

7 VCC

8 GND

9 OSC

10 OSC

11 PD5 DIGITAL/PWM 6

12 PD6 DIGITAL/PWM 7

13 PD7 DIGITAL 8

14 PB0 DIGITAL NRF ENABLE

15 PB1 DIGITAL/PWM 9

16 PB2 SPI: SS

17 PB3 SPI: MOSI

18 PB4 SPI: MISO

19 PB5 SPI: SCK

20 VCC

21 AREF

22 GND

23 PC0 ANALOG 10

24 PC1 ANALOG 11

25 PC2 ANALOG 12

26 PC3 ANALOG 13

27 PC4 ANALOG/I2C 14

28 PC5 ANALOG/I2C 15

DIGITAIS

ANALÓGICAS ou DIGITAIS

DIGITAIS (PWM)

Tabela A4.3 – Mapeamento dos portos do ATMega328P para os portos utilizados no módulo controlador. *Porto que pode ser associado a uma interrupção externa

A4.10. Exemplos de módulos de dispositivos

De seguida listar-se-ão alguns exemplos de módulos de dispositivos possíveis de serem utilizados

com as NApps desenvolvidas como uma forma de validar o conceito apresentado. Existirão muitos

mais dispositivos que poderão ser utilizados, principalmente com as primeiras 4 NApps que são mais

genéricas. Não se abordarão detalhes de funcionamento de cada NApp, apenas as suas capacidades

testadas.

A-11

Alguns dos dispositivos apresentados como componentes terão que ser introduzidos em placas de

circuito impresso cuja interface de ligação física deverá ser igual à utilizada pelo módulo controlador.

Para os dispositivos já adquiridos como módulos, a tradução entre as interfaces pode ser feita pelo

próprio cabo de ligação que assim poderá ter que ser específico para cada módulo.

Figura A4.8 – Dispositivos para utilizar com a NApp1 (escrita digital). Módulo de relés duplo (à esquerda, obtido por 1.17€), simples (obtido por 0.66€), um simples LED e laser 5V (obtido por 0.84€). Todos foram testados.

Figura A4.9 - Dispositivos para utilizar com a NApp2 (leitura digital). Módulo de botão de pressão (à esquerda, 0.42€), módulos de botões capacitivos ao centro (um botão por 0.99€ e 4 botões por 1.79€), módulo sensor de

infravermelhos (por 0.73€) e à direita sensor de efeito de Hall (chip A3144, por 1.48€). Todos foram testados

Figura A4.10 - Dispositivos para utilizar com a NApp3 (escrita analógica ou PWM). À esquerda um regulador de intensidade para lâmpadas LED com tensões entre 8 e 24V e corrente máxima de 5A. À direita um LED. Apenas se

testou com o LED

Figura A4.11 – Dispositivos para utilizar com a NApp4 (leitura analógica). À esquerda uma fotoresistência (0.05€ já com a resistência necessária incluída, não presente na imagem), seguido de um sensor de corrente (baseado no chip ACS712T, obtido por 1.62€), seguido de um sensor de humidade do solo (obtido por 0.55€) e à direita um microfone

obtido por 0.90€. Todos os sensores apresentados foram testados, incluindo outros não referidos.

Figura A4.12 – Dispositivos para utilizar com a NApp5 (OneWire). À esquerda um sensor de temperatura DS18B20 normal obtido por 0.64€, à direita o mesmo sensor encapsulado para ser utilizado em líquidos, obtido por 1.51€.

Ambos testados, tanto isolados como vários no mesmo porto.

A-12

Figura A4.13 – Dispositivos para utilizar com a NApp6 (DHT). À esquerda sensor DHT11 obtido por 0.92€ e à direita DHT22 obtido por 2.52€ . Ambos foram testados.

Figura A4.14 – Dispositivo para utilizar com a NApp7 (receptor de infravermelhos, à esquerda) obtido por 0.11€ e testado com telecomandos de televisões.

Figura A4.15 – Dispositivo HC-SR04 (sensor de distância untra-sónico) para utilizar com a NApp8. Obtido por 1.05€ e testado

Figura A4.16 – Conectores JST XH 2.54mm de 4 pinos que só se conseguem ligar na direcção correcta para interligar componentes

A-13

A5. Módulo gateway

Figura A5.1 – Circuito do protótipo que permite implementar um módulo gateway ou um módulo contolador (58.5mm x 90mm).

Qt. Componente Preço

1 Módulo controlador 4.80 €

2 5 pin 2.54mm header

fêmea 0,12 €

1 Módulo ENC28J60 3,27 €

(Versão ethernet) 8,31 €

1 FT232RL USB to RS232 2,74 €

(Versão USB) 7,54 €

Tabela A5.1 – Custo do protótipo multi-funções que permite implementar o módulo gateway

A-14

A6. Módulo de supervisão – SLAG

Figura A6.1 – Fluxograma de como deverá ser utilizado o objecto gateway

Utilização Argumentos de inicialização

RF24 por SPI

Endereço SLA da SLAG Endereço RF24 do nó (0 por defeito) Canal RF24 a utilizar Utilização de autenticação Palavra chave da rede (se NULL não utiliza encriptação)

Módulo gateway ethernet Endereço SLA da SLAG Endereço IP do módulo gateway Porto UDP para comunicação com o módulo gateway

Módulo gateway USB Endereço SLA da SLAG Dispositivo USB (por exemplo “/dev/ttyATM0” em Linux ou “\\.\COM12” em Windows)

Tabela A6.1 – Diferentes métodos de inicialização do objecto Gateway

A6.1. Aplicação para testar comunicações

Na Figura A6.2 apresenta-se a interface gráfica utilizada para testar as comunicações no SL. Em

cada canto existe um menu de apoio em que é permitido: converter valores entre diferentes

representações, aceder a informações sobre estrutura de certos dados e propriedades utilizadas por

NApps, possibilidade de gravar (e carregar) tramas da base de dados e assistentes para construir

tramas relativas a configurações

Figura A6.2 – Interface gráfica implementada para testar e validar as comunicações