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 ([email protected]) - https://github.com/maniacbug/RF24 Implementa uma classe para aceder ao chip nRF24L01+ e as suas funcionalidades básicas.
DHT por Mark Ruys ([email protected]) - 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 ([email protected]) - 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 ([email protected]) - 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 ([email protected]) - 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
Top Related