FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO
Smart Home - Smart Appliances
Hugo Eduardo Esteves Caldas
Mestrado Integrado em Engenharia Eletrotécnica e de Computadores
Orientador: Professor Doutor Paulo Portugal
Co-Orientador: Doutor David Rua
Co-Orientador: Engenheiro Nuno Moreira da Silva
1 de Dezembro de 2015
c Hugo Eduardo Esteves Caldas, 2015
ii
Resumo
Este documento foi elaborado com o propósito de descrever o trabalho desenvolvido na realização da dissertação intitulada "Smart Home - Smart Appliances". A dissertação decorreu sob
a orientação da Faculdade de Engenharia da Universidade do Porto, do INESC TEC e da Bosch
Termotecnologia SA.
Smart home é a designação dada a uma casa que incorpora sistemas de automação com um
ponto central que monitoriza e controla as Smart Appliances, dispositivos eletrónicos que dispõem
de uma interface que permite a receção de pedidos e ações e o seu processamento. Para possibilitar
a sua gestão, é necessário ter uma rede que permita a todas as Smart Appliances estarem ligadas
nesse ponto. Optou-se pela utilização da tecnologia wireless ZigBee com a integração do perfil
Smart Energy.
Nesta dissertação pretende-se implementar os dispositivos Smart Energy do perfil Smart Energy
da tecnologia wireless ZigBee em equipamentos já existentes tendo a capacidade de serem integrados num ambiente de Smart Home. Os dispositivos a utilizar são um termoacumulador e um
contador MBOX da EFACEC.
Para cumprir este objetivo, foi necessário um estudo aprofundado da tecnologia e do perfil para
que, juntamente com os requisitos definidos, fossem desenvolvidos o hardware e o software para
os dispositivos. Para a validação do desenvolvimento, foi criada uma Gateway a quem compete
criar e gerir a rede. Para demonstração, foi adicionado um bloco de controlo a esta, criado através
de regras, simulando um cenário de um caso possível em ambiente doméstico.
iii
iv
Abstract
This document was written with the intention to describe the work developed in the accomplishment of the master thesis with the subject "Smart Home - Smart Appliances". This project
evolved under the orientation of Faculty of Engineering of University of Porto, INESC Technology
and Science and Bosch Termotechnology SA.
Smart Home is a designation which is given to a house full of automation systems with a
central point that allows monitoring and controling the Smart Aplliances, electronic devices which
has a interface to receive requests and actions and process them. To allow your management, it is
necessary to have a network connecting the Smart Appliances to the central point. The network
was created based on the wireless technology ZigBee with the Smart Energy profile.
This master thesis implements Smart Energy devices of the Smart Energy profile using Zigbee
wireless technology into existing equipments with the ability to be integrated into a Smart Home.
The devices are a water heater and a MBOX meter from EFACEC.
To achieve this objective, an in-depth study of the technology and profile was necessary so
that, together with the defined requirements, the hardware and the software for the devices were
developed. For the validation of the development, a Gateway was created that is responsible for
creating and managing the network. For demonstration, a control block was added to the Gateway
using simple rules which simulates a scenario of a possible case in a domestic environment.
v
vi
Agradecimentos
Gostaria de agradecer aos orientadores que acompanharam esta dissertação, o Professor Doutor Paulo Portugal, o Doutor David Rua e o Engenheiro Nuno Silva pela disponibilidade e apoio
prestado ao longo da dissertação.
Um agradecimento especial à minha família, à Clara e a todos os meus amigos que, durante o
meu percurso académico, estiveram sempre para me apoiar.
A todos o meu muito obrigado!
Hugo Eduardo Esteves Caldas
vii
viii
“The important thing is not to stop questioning.
Curiosity has its own reason for existing.”
Albert Einstein
ix
x
Conteúdo
1
2
3
4
5
Introdução
1.1 Contexto . . . . . . . . .
1.2 Motivação . . . . . . . .
1.3 Objetivos . . . . . . . .
1.4 Metodologia . . . . . . .
1.5 Estrutura da Dissertação
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
3
Estado da Arte
2.1 Smart Appliances . . . . . . . . .
2.2 ZigBee . . . . . . . . . . . . . . .
2.2.1 Modelo OSI / Arquitetura
2.2.2 Topologias . . . . . . . .
2.2.3 Bibliotecas . . . . . . . .
2.3 Perfil Smart Energy . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
9
10
13
Solução proposta
3.1 Arquitetura proposta . . . . . . .
3.2 Análise de Requisitos . . . . . . .
3.2.1 Requisitos funcionais . . .
3.2.2 Requisitos não funcionais
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
19
19
19
Desenvolvimento
4.1 Estudo de mercado . . . . . . . . . . . . . . . . .
4.2 XBee . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Hardware . . . . . . . . . . . . . . . . . . . . . .
4.4 Software . . . . . . . . . . . . . . . . . . . . . . .
4.5 Implementação . . . . . . . . . . . . . . . . . . .
4.5.1 Configuração da rede . . . . . . . . . . . .
4.5.2 Dispositivos Smart Energy implementados
4.6 Validação da proposta . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
26
28
30
30
36
38
Conclusões e Trabalho Futuro
5.1 Apreciação global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Soluções rejeitadas do estudo de mercado
43
B Biblioteca Serial_util
45
xi
xii
CONTEÚDO
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Monitor Cloogy . . . . . . . . . . . . . . . . . .
RE:DY box . . . . . . . . . . . . . . . . . . . .
Modelo OSI da rede ZigBee . . . . . . . . . . .
Período ativo e inativo do método beacon-enabled
Topologias da rede ZigBee . . . . . . . . . . . .
Self healing da rede ZigBee adaptada da figura 2.5
Dispositivo Smart Energy . . . . . . . . . . . .
.
.
.
.
.
.
.
6
6
7
8
10
11
13
3.1
3.2
3.3
Termoacumulador da Bosch . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contador da EFACEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
17
18
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
Esquema de envio de comandos AT . . . . . . . . . . . . . . . . . . . . . . . .
Transmissão de dados entre dispositivos . . . . . . . . . . . . . . . . . . . . . .
Esquema de ligações do termoacumulador . . . . . . . . . . . . . . . . . . . . .
Esquema de ligações do contador . . . . . . . . . . . . . . . . . . . . . . . . . .
Módulo a acoplar ao termoacumulador . . . . . . . . . . . . . . . . . . . . . . .
Módulo a acoplar ao contador . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualização da interface XCTU da DIGI . . . . . . . . . . . . . . . . . . . . .
Upload do firmware Smart Energy para o coordenador . . . . . . . . . . . . . .
Certificado de teste emitido pela CERTICOM . . . . . . . . . . . . . . . . . . .
Esquema da junção de routers e terminais à rede . . . . . . . . . . . . . . . . . .
Comandos do key establishment cluster realizados entre o initiator (terminais) e
responder (coordenador) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demonstração da configuração dos comandos sleep . . . . . . . . . . . . . . . .
Esquema de criação e junção à rede . . . . . . . . . . . . . . . . . . . . . . . .
Esquema da simulação efetuada no laboratório Smart Grids do INESC . . . . . .
Simulação efetuada no laboratório Smart Grids do INESC TEC . . . . . . . . . .
25
25
27
28
29
29
30
31
32
33
4.12
4.13
4.14
4.15
xiii
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
35
36
38
39
xiv
LISTA DE FIGURAS
Lista de Tabelas
2.1
Frame ZCL adaptada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1
3.2
Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
21
4.1
4.2
Lista de componentes utilizados . . . . . . . . . . . . . . . . . . . . . . . . . .
Composição das frames para a transmissão de dados . . . . . . . . . . . . . . .
24
26
A.1
A.2
A.3
A.4
A.5
1x Kit . . . . . . . . . . . .
1x CC Debugger . . . . . .
1x IAR workbench software
1x Kit . . . . . . . . . . . .
2x Microcontroladores . . .
43
43
43
44
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xvi
LISTA DE TABELAS
Abreviaturas e Símbolos
AES
AI
APL
API
APS
CAP
CB
CCA
CFP
CSMA-CA
DSSS
ED
EO
FEUP
FFD
GTS
HAN
Hz
IEEE
INESC TEC
ID
IP
KY
kW
LAN
LLC
LQI
MAC
MHz
NJ
NK
OSI
PC
PDU
PLC
RFD
TCP
V
Advanced Encryption Standard
Association Indication
Application Layer
Application Programming Interface
Application Support Sublayer
Contention Access Period
Commissioning Button
Clear Channel Assessment
Contention Free Period
Carrier Sense Multiple Access with Collision Avoidance
Direct Sequence Spread Spectrum
Energy Detection
Encryption Options
Faculdade de Engenharia da Universidade do Porto
Full Function Device
Guaranteed Time Slot
Home Area Network
Hertz
Institute of Electrical and Electronics Engineers
Instituto de Engenharia de Sistemas e Computadores Tecnologia e Ciência
Extented PAN ID
Internet Protocol
Link Key
kiloWatt
Local Area Network
Logical Link Control
Link Quality Indicator
Media Access Control
Mega Hertz
Node Join Time
Network Encrytion Key
Open Systems Interconnection
Personal Computer
Protocol Data Units
Power Line Communication
Reduced Function Device
Transport Control Protocol
Volt
xvii
xviii
VC
s
SC
SD
SM
SP
ST
ZCL
ZDO
ZDP
ZT
ZU
ZV
ABREVIATURAS E SÍMBOLOS
Verify Certificate
segundo
Scan Channels
Scan Duration
Sleep Mode
Sleep Period
Time before Sleep
ZigBee Cluster Library
ZigBee Device Object
ZigBee Device Profile
Device Implicit Cert
Public Key
Private Key
Capítulo 1
Introdução
Este documento foi elaborado com o propósito de descrever o trabalho desenvolvido na realização da dissertação intitulada "Smart Appliances". A dissertação decorreu sob a orientação da
Faculdade de Engenharia da Universidade do Porto, do INESC Technology and Science e da Bosch
Termotecnologia SA.
Este primeiro capítulo faz um pequeno contexto do título da dissertação (secção 1.1), descreve
a motivação para a escolha da dissertação (secção 1.2), seguindo-se os objetivos (secção 1.3) e a
metodologia (secção 1.4) adotada para o seu desenvolvimento. Por fim, apresenta-se a estrutura
do documento (secção 1.5).
1.1
Contexto
Smart home é a designação dada a uma casa que incorpora sistemas de automação que permitem monitorizar e controlar as Smart Appliances, dispositivos eletrónicos que dispõe de uma
interface que permite receber pedidos e ações e as processe. A existência de tarifas com preços
discriminados (potencialmente dinâmicas), de cargas flexíveis (como é exemplo o termoacumulador) e de sistemas de micro-geração de energia exige que uma casa, para ser eficiente, necessite de
ter controlo sobre as Smart Appliances para que seja possível fazer uma gestão cuidada da energia produzida / consumida reduzindo assim os seus custos associados. É necessária a ligação das
Smart Appliances a uma Gateway, dispositivo central responsável pelas tarefas de monitorização
e controlo. A Gateway representa a interface na qual o utilizador pode realizar essas tarefas. A
monitorização deverá ser feita para assegurar a segurança, os níveis de conforto e eficiência energética da casa. A Gateway deverá possuir um controlo automático para minimizar a necessidade
de intervenção humana ou manual tornando o utilizador um elemento ativo na gestão de energia.
1.2
Motivação
A integração dos equipamentos eletrónicos numa rede habitacional em que o utilizador possa
ter fácil acesso através de uma aplicação tornará a gestão da habitação mais fácil, cómoda e efi1
2
Introdução
ciente. Ter uma Smart Home será uma vontade de todos os que conhecerem os seus benefícios
porque proporciona conforto podendo configurar a sua temperatura, oferece segurança enviando
e-mails das alterações de estado dos sensores presentes e permite a poupança de energia sendo
possível ligar e desligar dispositivos, remotamente.
As faturas de eletricidade tradicionais não contém informação suficientemente detalhada do
que cada equipamento eletrónico consome numa habitação. Tendo em vista esta necessidade,
seria benéfico ter todos os equipamentos eletrónicos com ligação a uma Gateway onde o utilizador poderia fazer uma monitorização do consumo geral e de cada dispositivo. O objetivo seria
consciencializar os utilizadores mostrando gráficos comparativos do consumo de modo a fazê-los
perceber como podem poupar dinheiro reduzindo assim o valor das suas faturas.
1.3
Objetivos
Nesta dissertação pretende-se implementar dispositivos Smart Energy do perfil Smart Energy
da tecnologia ZigBee em equipamentos já existentes tendo a capacidade de serem integrados num
ambiente de Smart Home. Os dispositivos a utilizar nesta dissertação são: um termoacumulador
e um contador MBOX da EFACEC. Os módulos a desenvolver terão que dispôr de uma interface
de comunicações que lhes permita comunicar com uma Gateway e com os dispositivos já mencionados. Enquanto que o contador deverá ser capaz de comunicar as leituras de registos que lhe
forem pedidas, o termoacumulador deverá ser capaz de receber e executar ações e reportar a sua
temperatura atual.
1.4
Metodologia
A metodologia deste trabalho consistiu em:
1. Estudar aprofundadamente a tecnologia ZigBee e o perfil Smart Energy;
2. Projetar o sistema em função dos requisitos;
3. Efetuar um levantamento de soluções para o desenvolvimento do hardware;
4. Após a escolha, desenvolver o hardware;
5. Implementar os dispositivos Smart Energy;
6. Estabelecer a comunicação entre os dispositivos já existente e os módulos a desenvolver;
7. Criação de rotinas automáticas para a gestão dos dispositivos Smart Energy.
De forma a comprovar a correta implementação dos dispositivos Smart Energy foi desenvolvida uma Gateway. Esta é responsável pelo estabelecimento da rede que, através da sua monitorização com o contador, controlará o termoacumulador. Para finalizar foi feita uma validação da
proposta apresentada utilizando as ferramentas do laboratório Smart Grids do INESC TEC para a
simulação de uma rede doméstica.
1.5 Estrutura da Dissertação
1.5
3
Estrutura da Dissertação
No capítulo 1 é feita uma contextualização do problema apresentado, indicando quais as motivações, os objetivos e a metodologia adotada. O capítulo 2 centra-se na descrição do estado da
arte relativo às Smart Appliances e da tecnologia ZigBee juntamente com o perfil Smart Energy.
No capítulo 3 é proposta uma arquitetura juntamente com os requisitos funcionais e não funcionais requeridos. No capítulo 4 é descrito o desenvolvimento do hardware e software necessários
para a implementação dos dispositivos Smart Energy, encerrando-o com a validação da proposta
apresentada. Por fim, o capítulo 5 encerra a dissertação fazendo uma apreciação global ao projeto
desenvolvido finalizando-o com a descrição de possíveis melhorias no presente trabalho e outros
futuros.
4
Introdução
Capítulo 2
Estado da Arte
Neste capítulo será analisado o estado da arte da dissertação indicando Smart Appliances já
existentes no mercado em Portugal (secção 2.1) e descrevendo a tecnologia de comunicação (secção 2.2) e o perfil Smart Energy (secção 2.3) utilizados no desenvolvimento desta dissertação.
Existem várias tecnologias de comunicação disponíveis para a criação da rede que fará a ligação entre as Smart Appliances e a Gateway. De entre as tecnologias disponíveis e apresentadas
em [1], destacam-se a cablada Power Line Communication (PLC) e as wireless Wi-Fi e ZigBee.
PLC é uma tecnologia que utiliza a infraestrutura elétrica para a transmissão de dados. Para se
distinguir dos sinais da rede elétrica que utiliza uma frequência na ordem dos Hz, o PLC utiliza
uma frequência muito diferente, na ordem dos MHz, dispensando assim a utilização de uma nova
infraestrutura. Wi-Fi é a tecnologia wireless mais utilizada em todo o mundo [2] estando presente
na maioria dos aparelhos eletrónicos pessoais como telemóveis e computadores e, atualmente, a
ser incorporado numa grande parte de eletrodomésticos. A tecnologia ZigBee foi desenvolvida
para providenciar comunicações wireless a curto alcance, com limitação de potência, baixo custo
e possuem módulos de comunicação de pequenas dimensões, suficientes para satisfazer os requisitos da maioria dos sistema de monitorização e controlo para aplicações industriais e domésticas
[3]. Esta foi a tecnologia escolhida pelos intervenientes para a implementação desta dissertação
com a utilização do perfil Smart Energy.
2.1
Smart Appliances
Recentemente, o desenvolvimento de Smart Appliances despertou interesse em Portugal. Foram desenvolvidos o Cloogy (figura 2.1) e o RE:DY da EDP (figura 2.2), serviços que permitem
gerir o consumo de casas.
Estas soluções de gestão energética residencial permitem gerir o consumo de energia. Possuem
contadores com ligação ao quadro elétrico e um transmissor que envia a informação do consumo
para o dispositivo central, encarregue de disponibilizar informação aos utilizadores. A monitorização pode ser feita não só global como também localmente utilizando tomadas inteligentes. Estas
podem ser controladas à distância (ligar e desligar) ou possuírem um horário de funcionamento,
5
6
Estado da Arte
Figura 2.1: Monitor Cloogy
Figura 2.2: RE:DY box
ligando e desligando automaticamente, eliminando assim os consumos em standby. Permitem
também a monitorização da micro-geração de energia garantindo o seu correto funcionamento.
Ambos disponibilizam relatórios periódicos com informação dos consumos registados sendo possível conhecer a poupança obtida com a sua utilização.
O Cloogy pode ser instalado por qualquer utilizador comum e possui, para além de serviços
de eletricidade, serviços relacionados com a segurança e sistema de gás: sensores de presença,
de portas e janelas, de fumos, câmaras de vigilância e ainda a medição do nível do tanque de gás
e a leitura automática do contador de gás. Toda a comunicação entre dispositivos do Cloogy é
feita utilizando a tecnologia ZigBee sendo que ao dispositivo central (concentrador) está ligado
um router Wi-Fi para que a monitorização e controlo possa não só ser feita utilizando plataformas
Cloogy mas também através de smartphones, tablets e PCs.
O RE:DY necessita de um técnico EDP para instalar o seu serviço e contém um RE:DY meter
que possibilita a medição de dois circuitos elétricos. Apresenta vantagens para monitorização de
iluminação exterior e partições da casa. Para o RE:DY, o dispositivo central (RE:DY box) comunica
via ZigBee com as tomadas inteligentes (RE:DY Plugs), via PLC com o RE:DY meter e via Wi-Fi
para acesso do utilizador.
2.2
ZigBee
ZigBee (IEEE 802.15.4) é uma tecnologia de comunicação wireless desenvolvida pela ZigBee
Alliance [4] em parceria com o IEEE [5]. O seu funcionamento a baixa potência, a sua robustez e
a existência de kits com preços acessíveis torna esta tecnologia interessante em ambiente doméstico [6]. Em [7] estão especificadas as principais caraterísticas desde a camada física até à camada
de aplicação. Uma das vantagens desta tecnologia é a existência de perfis como por exemplo o
Home Automation e o Smart Energy que permitem a criação de dispositivos ZigBee garantindo
a interoperabilidade com qualquer outro dispositivo. O perfil Home Automation procura proporcionar ao utilizador conforto, segurança e possibilitar a gestão de energia através de controlo em
tempo real de sistemas de iluminação, de controlo de alarmes, de aquecimento dos dispositivos
2.2 ZigBee
7
inseridos na rede [8]. O outro perfil, o Smart Energy será detalhado na secção 2.3. Em [9], U.S.
National Institute for Standards and Technology definiu o ZigBee e o perfil Smart Energy como
os principais standards de comunicação no domínio da rede local das Smart Grids facilitando a
interoperabilidade entre dispositivos de diferentes marcas desde que a conversão deste protocolo
para a marca do dispositivo a controlar esteja disponível.
Para a tecnologia é apresentada a composição das camadas do modelo OSI (subsecção 2.2.1),
a topologia da rede (subsecção 2.2.2) e, por fim, é detalhado o perfil Smart Energy (secção 2.3).
2.2.1
Modelo OSI / Arquitetura
Como é possível observar na figura 2.3, ZigBee é composto por quatro camadas do modelo
OSI: a camada física e a camada ligação de dados definidas pela IEEE 802.15.4 e a camada de
rede e a camada da aplicação desenvolvida pela ZigBee Alliance [10].
Figura 2.3: Representação do modelo OSI da rede ZigBee [7]
A camada física é responsável pela permissão para a transferência de dados (PDU - protocol
data units) [7]. Segundo [11] , esta camada é também responsável por:
• Detetar canais livres (CCA- Clear channel assessment ) utilizando CSMA-CA (carrier sense
multiple access with collision avoidance) para evitar colisões, aumentando a probabilidade
de transmissão de dados;
• Indicar a qualidade da ligação (Link Quality Indicator - LQI) nos pacotes recebidos;
• Detetar energia (Energy Detection - ED ) no canal de comunicação;
• Detetar potência dos canais;
8
Estado da Arte
• Selecionar a frequência dos canais;
• Ativar e desativar o módulo de comunicação.
Em todo o mundo, esta tecnologia utiliza uma frequência de 2.4 GHz com taxas de transmissão
de 250 Kbps e comunica através dos canais 11 ao 26. Na Europa também poderá ser utiliza a
frequência 868 MHz, taxa de transmissão de 20Kbps e utiliza o canal zero [12].
A camada de ligação de dados é encapsulada na camada física. Tem como principal função o
acesso à rede e utiliza dois métodos de acesso aos canais [9]:
• Beacon-enabled;
• Beaconless.
No método beacon-enabled são enviados beacons periódicos ( sinais transmitidos em tempos
iguais indicando que pretende comunicar ) para sincronização dos nós. O tempo entre diferentes
beacons possui dois períodos (figura 2.4) [7] [11] :
• Período ativo dividido em 16 time slots iguais:
Contention Access Period (CAP) que utiliza um mecanismo CSMA-CA para evitar colisões, transmitindo apenas nos canais livres;
Contention-Free Period (CFP) que indica o tempo em que o nó pode transmitir no GTS
(guaranteed time slot) podendo ter até 7 GTSs. O GTS pode ocupar mais que um time slot e
é utilizado pelos dispositivos para transmissões de dados cíclicas;
• Período inativo representando o tempo que os nós estão inoperantes.
CFP ( Contention-Free Period )
GTS
CAP ( Contention Access Period )
1
2
3
4
5
6
7
8
9
10
11
12
13
GTS
14
15
Período inativo
16
Figura 2.4: Período ativo e inativo do método beacon-enabled
Segundo o método beaconless, os dispositivos utilizam o mecanismo CSMA-CA e o IEEE
802.15.4 possibilitando a comunicação unicast, para um único destino [7]. Neste método, os
nós estão ativos todo o tempo. A vantagem do método beacon-enabled em relação a este é que
possibilita que os nós possam entrar no modo sleep permitindo a poupança de energia.
A camada de rede é definida pelo ZigBee. É responsável por iniciar a rede, pela gestão dos
dispositivos lógicos e pela gestão da segurança da rede. Possui três tipos de dispositivos lógicos
[13]:
2.2 ZigBee
9
• Coordenador, que é responsável por iniciar e controlar a rede;
• Routers, funcionam como intermediários entre o coordenador e os terminais, podendo reencaminhar informação entre eles até chegar ao destino - fenómeno multi-hopping. No caso
do reencaminhamento não ser executado retorna mensagens de erros;
• Terminais, que irão utilizar a informação fornecida pelos routers ou coordenador da forma
mais adequada, quer armazenado o conteúdo quer respondendo com informação.
Para cada dispositivo lógico poderá ser utilizado um dos dois tipos de dispositivos, com diferentes funcionalidades:
• Full Function Device (FFD) - podem operar como qualquer tipo de dispositivo lógico;
• Reduced Function Device (RFD) - apenas podem comunicar com os FFD e apenas podem
operar como terminais. São mais simples, de menor complexidade, de menor custo e de
menor consumo de energia.
A camada de aplicação (APL) é a camada superior. Consiste na Application Support Sublayer
(APS), no ZigBee Device Object (ZDO) e nos Application Objects. A subcamada APS é utilizada para implementar os mecanismos de segurança e para que os Application Objects e os ZDO
possam comunicar com a camada de rede para serviços de gestão e de troca de informação. O
ZDO fornece a possibilidade dos Application Objects descobrirem outros dispositivos e serviços,
sendo ele um próprio Application Object implementado no Endpoint 0. Nos Application Objects
é onde residem os 240 Endpoints que poderão ser utilizados para implementação de perfis, como
por exemplo o Home Automation e o Smart Energy.
2.2.2
Topologias
Na figura 2.5 estão apresentadas as topologias da rede ZigBee - estrela, árvore e malha - onde
podemos ver os vários tipos de funcionamento da rede:
Numa rede em estrela, existe um coordenador e terminais. Estes estão dentro do raio de ação
da rede criada pelo coordenador, não necessitando da propagação de sinal efetuada pelos routers.
Como toda a informação é transmitida através do coordenador pode ocorrer congestionamento na
rede por esta estar centralizada apenas num dispositivo.
Numa rede do tipo árvore, o sinal é propagado através de routers até chegar aos terminais,
podendo também estarem associados diretamente ao coordenador. Cada terminal (que, derivado à
estrutura da topologia é chamado de filho) está apenas habilitado a comunicar com o seu parente.
Este tipo de rede apresenta algumas desvantagens tais como: impossibilidade de um filho comunicar com outros dispositivos caso o seu parente avarie; mesmo que um terminal esteja fisicamente
mais próximo de um outro parente, este não poderá comunicar com ele.
Numa rede em malha, todos os dispositivos FFD, desde que tenham alcance, podem comunicar
entre eles. Esta rede ultrapassa as desvantagens da rede do tipo árvore prejudicando a sua complexidade. Com os FFD em malha, pode-se afirmar que a rede possui a caraterística self-healing, ou
10
Estado da Arte
Árvore
Estrela
Malha
Coordenador
Router
Terminal
Figura 2.5: Topologias da rede ZigBee
seja, caso algum router falhe, possibilita a descoberta de outra rota para a entrega da mensagem
- route discovery. Na figura 2.6 podemos observar uma representação dessa mesma caraterística.
Numa comunicação entre o nó 1 e o nó 7 a rede utilizaria a rota 1-3-6-7. Para o caso de o nó 3
ter algum problema que o impeça de estar a funcionar corretamente, a rede é capaz de encontrar
outras rotas, como por exemplo a rota 1-4-6-7 não perdendo o nó 7 da rede. Com as mensagens a
serem transmitidas router por router, a limitação a nível de alcance não torna esta tecnologia uma
tecnologia de curto alcance uma vez que é possível atingir um alcance mais elevado adicionando
routers apesar de ter como entrave o seu custo associado [7] [14].
Os terminais apenas podem transferir pacotes. Os routers podem reencaminhar os pacotes
transferidos para eles e permitir a gestão dos dispositivos na rede. O coordenador executa todas as
funções anteriores e ainda tem a possibilidade de criar uma nova rede. Os routers e coordenadores
terão de ser obrigatoriamente do tipo FFD [9].
2.2.3
Bibliotecas
A tecnologia ZigBee disponibiliza bibliotecas de funcionalidades: ZigBee Device Profile (ZDP)
e a ZigBee Cluster Library (ZCL). O ZDP define uma interface de gestão dos dispositivos ZigBee.
São disponibilizados serviços na camada de rede que permitem ter acesso a informações úteis.
A lista completa está presente em [15] sendo que aqui são apresentados apenas alguns dos mais
importantes:
2.2 ZigBee
11
4
6
7
1
3
5
2
Figura 2.6: Self healing da rede ZigBee adaptada da figura 2.5
• Network Address - permite saber qual o endereço de 16-bit de cada dispositivo na rede
baseado no endereço IEEE de 64-bit;
• IEEE address - permite saber qual o endereço de 64-bit de cada dispositivo baseado no
endereço de 16-bit na rede;
• Simple Description - permite saber a descrição de um determinado endpoint num dispositivo
com um conhecido endereço de 16-bit.
• Active Endpoint - permite saber qual a lista de endpoints ativos.
• Match Description - permite encontrar a lista de endpoints que suportam os clusters desejados.
• Device announce - é automaticamente enviado para o coordenador sempre que um router
ou um terminal se junta à sua rede.
A ZCL é uma biblioteca de clusters da tecnologia ZigBee que disponibiliza aos dispositivos
funcionalidades em vários domínios: gerais (alterar o estado ligar / desligar, obter informações
básicas, configuração de alarmes, sincronização de relógios, entre outros), aquecimento, refrigeração, ar condicionado, iluminação, segurança, entre outros. Contém conjuntos de clusters para
cada área de domínio descritos em [16] e alguns deles são utilizados pelo perfil Smart Energy
como é exemplo o basic cluster.
12
Estado da Arte
O ZCL disponibiliza também comandos gerais para aceder a atributos. A lista completa e
construção das frames ZCL podem ser consultados em [16] sendo que os mais usuais são aqui
apresentados:
• Read Attributes - utilizado para ler remotamente um ou mais atributos num dispositivo.
• Read Attributes Response - resposta ao comando Read Attributes.
• Write Attributes - utilizado para escrever remotamente um ou mais atributos num dispositivo;
• Write Attributes Response - resposta ao comando Write Attributes.
• Discover Attributes - utilizado para descobrir remotamente atributos num dispositivo.
• Discover Attributes Response - resposta ao comando Discover Attributes.
As frames ZCL (tabela 2.1) contém o header e o payload e são inseridos no data payload das
frames ZigBee para serem transmitidas.
Tabela 2.1: Frame ZCL adaptada de [16]
Bits: 8
Frame control
0/16
8
Transaction
Manufacturer code
sequence number
ZCL header
8
Command
ID
Variável
Frame payload
ZCL payload
O frame control é composto por 8-bit sendo que cada quatro deles indicam:
• Se o comando pertence ao perfil Smart Energy ou a um cluster específico;
• Se o header irá conter o código de fabricante;
• Se o comando a ser enviado será feito do cliente para o servidor ou vice-versa;
• Se é pretendido que seja sempre gerada uma resposta por defeito ao comando ou apenas
quando ocorrer um erro.
A existência do Manufacturer Code dependerá do frame control. Caso exista, indicará o código do fabricante e contém 16-bit. O Transaction Sequence Number contém 8-bit e especifica
uma identificação do comando enviado para que, quando seja dada a resposta, este número indique que a resposta dada será ao comando cuja identificação seja semelhante. É incrementado
em uma unidade a cada comando enviado. Quando o valor chega ao seu máximo ( 0b11111111
) este voltará ao início, recomeçando a contagem. É incrementado uma unidade sempre que um
comando é enviado. O Command identifier contém 8-bit e especifica o comando a ser utilizado.
O ZCL payload tem tamanho e descrição variável, dependente de cada comando ou atributo tendo
a necessidade de ser analisado individualmente.
2.3 Perfil Smart Energy
2.3
13
Perfil Smart Energy
O perfil Smart Energy foi desenvolvido para proporcionar interoperabilidade entre dispositivos
ZigBee de diferentes fabricantes de equipamentos elétricos. Destina-se a áreas de aplicações de
medição e gestão de cargas sendo que poderá ser instalado quer numa habitação simples como num
apartamento complexo. O objetivo da sua implementação é permitir a monitorização e controlo de
uma vasta área de aplicações em ambiente residencial com uma rede sem fios de baixa potência:
fazer uma gestão inteligente de cargas, monitorizar o uso de energia, otimizar o seu consumo num
ambiente seguro, entre outros. Com isto, pretende-se reduzir os consumos e, consequentemente,
poupar dinheiro.
A implementação deste perfil é feita a nível da camada de aplicação. O perfil permite tornar
os dispositivos em dispositivos Smart Energy. Em cada dispositivo Smart Energy (figura 2.7)
são implementados clusters, conjuntos de atributos (informação que representa um estado ou uma
quantidade) e comandos quer obrigatórios quer opcionais que especificam uma funcionalidade
[17].
Dispositivo Smart Energy
Cluster
Cluster
Cluster
Comandos
Comandos
Comandos
Atributos
Atributos
Atributos
Figura 2.7: Dispositivo Smart Energy
Cada dispositivo Smart Energy deverá ter implementado os comandos e atributos obrigatórios
dos clusters que são exigidos para todos os dispositivos que pretendam estar autenticados numa
rede ZigBee Smart Energy: Basic e Key Establishment clusters.
O Basic cluster contém informações básicas do dispositivo. Obrigatoriamente contém apenas
um atributo de informação sobre o dispositivo que é a versão da ZigBee Cluster Library. Contudo
tem outros atributos opcionais que poderão ser utilizados: a versão de hardware do dispositivo, o
nome do fabricante, entre outros.
O Key Establishment cluster faz a gestão de uma comunicação segura entre dispositivos Smart
Energy. O método de encriptação utilizado é o AES-CCM* descrito em [18]. Contém um atributo
que especifica o esquema de criptografia utilizado nesse cluster e comandos que representam o
14
Estado da Arte
estabelecimento de uma ligação segura entre os dispositivos. Para maior detalhe, aconselha-se a
leitura do Anexo C de [17].
Os clusters existentes no perfil são:
• Demand Response and Load Control - Utilizando eventos possibilita o controlo de cargas e
termostatos.
• Metering - Utilizado para obter informação acerca do uso de equipamentos de medição de
gás, água e energia.
• Price - Utilizado para obter informação acerca do preço a pagar pelo uso dos equipamentos.
• Messaging - Permite troca de mensagens de texto entre dispositivos ZigBee.
• Tunneling - Fornece a possibilidade de encapsular outros protocolos de comunicação para
equipamentos de medição no payload das frames.
• Prepayment - Possibilita a troca de mensagens relacionadas com o serviço de pré-pagamento.
Utilizado quando o utilizador opta por tarifas de pré-pagamento em que é depositado um
crédito sendo decrementado em função do seu consumo.
Os dispositivos Smart Energy utilizam um outro cluster da ZCL - cluster time - responsável
pela sincronização de relógios dos dispositivos presentes na rede.
Descritos os clusters necessários a todos os dispositivos Smart Energy, particularizou-se os
tipos de dispositivos disponibilizados pelo perfil. Cada dispositivo terá as suas funcionalidades
específicas e é definido como um conjunto de clusters:
• ESP (Energy service portal) - este dispositivo pode residir sozinho ou em conjunto com
outros no mesmo dispositivo físico e liga os restantes dispositivos numa rede Smart Energy
juntamente com a empresa de fornecimento de energia. Este dispositivo implementa obrigatoriamente os clusters: messaging, price, load control e time;
• Metering - é utilizado nos dispositivos de medição para fazer medições de água, eletricidade,
calor, entre outros. Deverá ser capaz de responder imediatamente a pedidos de medições
ou do envio de medições periodicamente. Este dispositivo implementa obrigatoriamente o
cluster metering;
• In-Premise Display - possibilita a apresentação de uma interface gráfica ou de texto que
poderá ser interativa e é responsável pela apresentação de informações ao utilizador do consumo atual, históricos de consumos, preços, entre outros. Implementa obrigatoriamente nenhum cluster mas exige que seja implementado pelo menos um dos opcionais: load control,
time, prepayment, price, metering e/ou messaging;
• PCT (Programmable Communicating Thermostat) - consegue controlar os sistemas de aquecimento e refrigeração. Implementa obrigatoriamente os clusters: load control e time;
2.3 Perfil Smart Energy
15
• Load Control - permite a transmissão de comandos para fazer gestão do consumo. Implementa obrigatoriamente os clusters: load control e time;
• Smart Appliance - utilizado por qualquer dispositivo para poder participar em atividades de
gestão de energia. Implementa obrigatoriamente os clusters: price e time;
• Prepayment Terminal - permite aos utilizadores pagar o seu consumo e mostrar os balanços
energéticos. Implementa obrigatoriamente os clusters: price, time e prepayment;
• Range Extender - é obrigatoriamente um router sendo utilizado para aumentar o raio na
comunicação entre dois dispositivos. O dispositivo físico deverá atuar apenas como range
extender não podendo conter outros dispositivos Smart Energy. É o dispositivo utilizado
para permitir a caraterística multi-hopping. Este dispositivo não implementa obrigatoriamente nenhum cluster.
16
Estado da Arte
Capítulo 3
Solução proposta
Neste capítulo é apresentada a arquitetura proposta (secção 3.1) e os seus requisitos associados
(secção 3.2).
3.1
Arquitetura proposta
Com o objetivo de desenvolver dois dispositivos Smart Energy num termoacumulador (figura
3.1) da Bosch Termotecnologia SA e num contador MBOX (figura 3.2) da EFACEC foi necessário
acoplar um módulo a cada dispositivo já existente para fazer essa implementação.
Figura 3.2: Contador da EFACEC
Figura 3.1: Termoacumulador da Bosch
17
18
Solução proposta
Para a validação da proposta de solução foi desenvolvida uma Gateway para demonstrar que
os dispositivos Smart Energy são monitorizáveis e controláveis.
Propôs-se uma arquitetura (figura 3.3) que envolveria o desenvolvimento de três blocos:
• Contador inteligente que representa o aparelho de medição cuja função será a medição de
informação da rede elétrica;
• Termoacumulador inteligente que representa o dispositivo a ser controlado;
• Gateway que representa a interface visível ao utilizador cuja função será a validação do
perfil Smart Energy e a monitorização e controlo dos dispositivos Smart Energy.
Termoacumulador inteligente
Módulo
Termoacumulador
µC
Gateway
módulo
ZigBee
PC
Contador inteligente
Zigbee
Módulo
Contador
µC
módulo
ZigBee
Figura 3.3: Arquitetura proposta
A Gateway possui os seguintes componentes:
• PC (Personal Computer) - responsável pela gestão da rede, pelos pedidos de informação aos
outros dois blocos e pelo controlo, através de comandos, do termoacumulador;
• Módulo de comunicação ZigBee - responsável pela comunicação bidirecional entre a Gateway e os outros dois blocos utilizando o perfil Smart Energy como standard de comunicação. Funciona como coordenador sendo ele o ponto central da comunicação. Como se trata
de uma rede com apenas dois dispositivos, a topologia da rede é em estrela apresentada na
secção 2.2.2.
Os dois dispositivos inteligentes são compostos por:
3.2 Análise de Requisitos
19
• Microcontrolador - faz a gestão, a nível da aplicação, da resposta aos pedidos do utilizador. É capaz de interpretar a informação recebida pelo módulo de comunicação ZigBee e
convertê-la para poder ser enviada e entendida pelos dispositivos e vice-versa.
• Módulo de comunicação ZigBee - ligado ao microcontrolador, é responsável pela comunicação bidirecional entre a Gateway e os dispositivos utilizando o perfil Smart Energy.
Esta arquitetura é a que mais se adequa ao propósito a servir permitindo também a inclusão de
mais dispositivos. Desta forma, a rede pode ser aumentada até um ambiente de uma Smart Home
de forma rápida e simples.
3.2
Análise de Requisitos
Esta secção tem como objetivo a análise e especificação de requisitos, ou seja, caraterísticas ou
funcionalidades que são requeridos ao projeto a desenvolver. Para cada requisito será especificado
qual o seu tipo ( Funcional, Usabilidade, Design, Segurança, Escalabilidade ou Compatibilidade
), o porquê de ser um requisito e a forma de verificação.
3.2.1
Requisitos funcionais
Os requisitos funcionais especificam as funcionalidades dos dispositivos. Para este projeto
foram delineados os seguintes requisitos funcionais especificando-os com maior detalhe na tabela
3.1:
• Os dispositivos inteligentes a desenvolver deverão ser capazes de comunicar via ZigBee,
utilizando o perfil Smart Energy;
• Os dispositivos inteligentes deverão ser capazes de entrar em modo sleep sempre que estiverem em repouso;
• O contador inteligente deverá, sempre que pedido, responder a pedidos com a leitura de
registos;
• O termoacumulador inteligente terá de, a partir do evento recebido, interpretá-lo;
• O termoacumulador inteligente deverá armazenar até três eventos;
• O termoacumulador inteligente deverá, sempre que pedido, responder a pedidos com a leitura da temperatura.
3.2.2
Requisitos não funcionais
Os requisitos não funcionais correspondem às caraterísticas ou restrições que o projeto a desenvolver deve respeitar. Para este projeto foram delineados os seguintes requisitos não funcionais:
20
Solução proposta
Tabela 3.1: Requisitos funcionais
Código
Tipo
RF1
Funcional
RF2
Funcional
RF3
Funcional
RF4
Funcional
RF5
Funcional
RF6
Funcional
Especificação
Os dispositivos
inteligentes a desenvolver
deverão ser capazes de
comunicar via ZigBee,
utilizando o perfil Smart
Energy.
Os dispositivos
inteligentes deverão ser
capazes de entrar em
modo sleep sempre que
estiverem em repouso.
O contador inteligente
deverá, sempre que
pedido, responder a
pedidos com a leitura de
registos.
O termoacumulador
inteligente terá de, a
partir do evento recebido,
interpretá-lo.
O termoacumulador
inteligente deverá
armazenar até três
eventos.
O termoacumulador
inteligente deverá,
sempre que pedido,
responder a pedidos com
a leitura da temperatura.
Justificação
Verificação
Serem inseridos
numa rede ZigBee.
Criação de uma
rede ZigBee.
Poupança de
energia.
Demonstração.
Funcionalidade do
contador.
Demonstração de
leituras de registos.
Controlo remoto
da carga.
Demonstração de
reações a eventos.
Funcionalidade
exigida pelo perfil
Smart Energy.
Envio de vários
comandos e
respetiva execução.
Controlo remoto
da temperatura.
Demonstração de
uma leitura de
temperatura.
• Os módulos a acoplar deverão possibilitar aos dispositivos já existentes serem integráveis
em ambientes domésticos utilizando uma rede ZigBee Smart Energy;
• Os módulos a acoplar deverão ser integráveis em outros dispositivos;
• Os módulos não deverão ter dimensões elevadas;
• A rede deverá ter uma chave de segurança.
3.2 Análise de Requisitos
21
Tabela 3.2: Requisitos não funcionais
Código
Tipo
RNF1
Usabilidade
Especificação
Os módulos a acoplar
deverão possibilitar aos
dispositivos já existentes
serem integráveis em
ambientes domésticos
utilizando uma rede
ZigBee Smart Energy.
RNF2
Usabilidade
Os módulos a acoplar
deverão ser integráveis
em outros dispositivos.
RNF3
Design
Os módulos não deverão
ter dimensões elevadas.
RNF4
Segurança
A rede deverá ter uma
chave de segurança.
Justificação
Verificação
Garantir a
integrabilidade.
Desenvolvimento
de uma Gateway.
Garantir que o
produto é
expansível a outros
dispositivos.
Fácil adaptação
aos dispositivos.
Garantir segurança.
Testes com outros
dispositivos.
Aprovação dos
intervenientes.
Existência de uma
chave para a
junção à rede.
22
Solução proposta
Capítulo 4
Desenvolvimento
Este capítulo começa por fazer um estudo de mercado ( secção 4.1 ), descreve o módulo de
comunicação ZigBee utilizado (secção 4.2), apresenta o desenvolvimento do hardware ( secção
4.3 ), o software ( secção 4.4 ) e apresentada a implementação ( secção 4.5 ) dos dispositivos
Smart Energy. Para finalizar, é descrita a validação da arquitetura proposta ( secção 4.6 ).
4.1
Estudo de mercado
Foram pesquisados e documentados kits de desenvolvimento e foram também compostas soluções com base em componentes individuais.
Na solução, o microcontrolador teria de ter saídas digitais para a comunicação com os dispositivos eletrónicos, comunicar via porta série para serem programados pelo PC e possuir uma
interface de comunicação com o módulo ZigBee para poder receber os dados recebidos por este.
Quanto ao módulo ZigBee, este apenas deveria suportar o firmware Smart Energy.
De entre as soluções encontradas, foram consideradas três. As duas rejeitadas estão presentes
no anexo A. Na solução no 1, o boosterpack da Anaren tem instalado o Stack Profile ZigBee 2007
PRO. Para conseguir fazer upload do firmware Smart Energy seria necessário a reprogramação do
firmware. Para isso seria indispensável adquirir o hardware CC-DEBUGGER e o software IAR
8051. Este tipo de ferramentas possuem custos associados elevados e não suportados.
A solução no 2 reúne as condições necessárias para a implementação deste projeto. No entanto
foi rejeitada em detrimento da solução apresentada na tabela 4.1 uma vez que esta possui um
reduzido preço comparativo.
Na tabela estão apresentados todos os componentes necessários para o desenvolvimento do
hardware:
4.2
XBee
O XBee é o módulo de comunicação ZigBee que suporta a implementação dos dispositivos
Smart Energy. O firmware Smart Energy apenas pode ser instalado em módulos XBee series
23
24
Desenvolvimento
Tabela 4.1: Lista de componentes utilizados
Qtd.
1
1
2
3
1
1
1
1
1
Componente
Referência (fabricante)
Arduino UNO
A000066 (ARDUINO)
Arduino MEGA
A000067 (ARDUINO)
Shield XBee
A000065 (ARDUINO)
XBee Series 2
XB24-Z7SIT-004 (DIGI)
Transceiver Breakout - RS485 BOB-10125 ROHS (sparkfun)
Cabo RJ11 - RJ11
PS11457 (PRO SIGNAL)
Adaptador XBee-USB
XBee-USB (Gravitech)
Sensor de temperatura
DS18B20 (Maxim)
Relé de comando
SRD-05VDC-SL-C (Songle)
Total
Preço
24,29 e
37,90 e
25,79 e
18,79 e
9,15 e
0,76 e
25,69 e
1,62 e
8,32 e
215,68 e
2. Estes módulos possuem dimensões reduzidas, têm um alcance em interiores até 40 metros,
consomem baixa potência e proporcionam uma comunicação segura entre módulos [19].
O XBee utiliza frames API para a troca de informação quer local quer remotamente.
• AT Command - comando utilizado para alterar as configurações do dispositivo local (figura
4.1). Surte efeito após o envio do comando;
• AT Command - Queue Parameter Value - comando com a mesma função do comando anterior apesar de, para as configurações serem alteradas, precisarem de um comando específico
AC (Apply Changes);
• Explicit Addressing ZigBee Command Frame - comando utilizado para o envio de dados
entre dispositivos (figura 4.2). É através deste comando que os comandos e os atributos são
enviados;
• ZigBee Create Source Route - cria uma rota para envio de dados entre o emissor e o destino;
• ZigBee Register Joining Device - permite que os dispositivos que tenham em comum a chave
KY (link key) se possam juntar;
• AT Command Response - em resposta ao AT Command, indica o estado da alteração da
configuração.
• Modem Status - indica o estado do dispositivo em condições específicas: autenticação completa, junção e dissociação à rede, reset do dispositivo, entre outros.
• ZigBee Transmit Status - em resposta automática ao Explicit Addressing ZigBee Command
Frame, indica o estado do envio da mensagem.
• ZigBee Explicit Rx Indicator - quando uma frame ZigBee é recebida por um dispositivo, ela
chega através deste tipo de comando.
4.2 XBee
25
• Route Record Indicator - indicador recebido quando um dispositivo envia um ZigBee Create
Source Route.
• ZigBee Device Authenticated Indicator - enviado quando um dispositivo é autenticado numa
rede ZigBee Smart Energy.
• ZigBee Register Joining Device Status - enviado quando um dispositivo se junta a uma rede
ZigBee Smart Energy.
• ZigBee Join Notification Status - enviado quando um dispositivo faz uma tentativa de junção
ou dissociação à rede.
AT Command
AT Command Response
Figura 4.1: Esquema de envio de comandos AT
Explicit Addressing Zigbee
Command Frame
Zigbee Explicit Rx Indicator
Zigbee Transmit Status
Figura 4.2: Transmissão de dados entre dispositivos
Na tabela 4.2 é descrita a composição das frames do Explicit Addressing ZigBee Command
Frame. Está exemplificada a leitura de um atributo - a versão do ZCL (0x0000) - do Basic cluster
(0x0000) do XBee com o endereço de 64-bit 0x13A20040690F8D, endereço de 16-bit (0x12A1).
Para informações acerca das restantes frames API, consultar [19].
26
Desenvolvimento
Tabela 4.2: Composição das frames para a transmissão de dados
Start Delimiter
Comprimento
(em bytes)
1
Length
2
0x00 0x19
Frame Type
1
0x11
Frame ID
1
0x01
64-bit Destination
Address
8
0x00 0x13
0xA2 0x00
0x40 0x69
0x0F 0x8D
16-bit Destination
Address
2
0x12 0xA1
Source Endpoint
1
0x5E
1
0x5E
2
0x00 0x00
Profile ID
2
0x01 0x09
Broadcast Radius
1
0x00
Transmit Options
1
Data Payload
5
Checksum
1
0x00
0x00 0x01
0x00 0x00
0x00
0x79
Campos
Destination
Endpoint
Cluster ID
4.3
Exemplo
Descrição
0x7E
Início de uma frame.
Número de bytes entre o Length e o
Checksum.
Identificador de Explicit Addressing
ZigBee Command Frame.
Identificador da frame. Se for 0, não
receberá nenhum feedback da frame
enviada.
Endereço de 64-bit de destino,
identificador do dispositivo.
Endereço de 16-bit de destino do
dispositivo na rede.
Endpoint do dispositivo que transmite
(escolhido arbitrariamente).
Endpoint do dispositivo que irá
receber (escolhido arbitrariamente).
Identificador do cluster a utilizar.
Identificador do perfil suportado pelo
XBee.
Número máximo de saltos que uma
transmissão pode atravessar.
Deverá ser colocado a 0.
frame ZCL cujo payload é a
identificação do atributo (ver a sua
composição na tabela 2.1).
Byte de confirmação do final da frame.
Hardware
Tal como já foi visível na figura 3.3, a arquitetura é composta por três blocos. Para cada um
foi desenvolvido o hardware com os componentes adquiridos e apresentados na secção 4.1.
A Gateway é composta pela ligação de um XBee ao PC com o auxílio do adaptador XBee-USB.
Os esquemas de ligação para os dispositivos inteligentes são mais complexos. O termoacumulador possui um microcontrolador que utiliza o protocolo EWS (Electrical Water Storage) definido
pela Bosch Termotecnologia SA. Através deste protocolo, é possível controlar o termoacumulador em modo manual ( em que são enviados setpoints de temperatura ) ou em modo automático
( é definida a tarifa ) ficando a sua gestão a cargo do microcontrolador da Bosch Termotecnologia SA. Devido às condições do termoacumulador, foi necessário o desenvolvimento de hardware
4.3 Hardware
27
que substituísse os componentes deste, um sensor para medir a temperatura e um relé de controlo para alterar o estado do termoacumulador ( ligar / desligar ). Desta forma, o avanço da
dissertação tornou-se independente do protocolo EWS utilizado pela Bosch Termotecnologia SA
e desenvolveu-se um módulo que é independente da marca do termoacumulador, ou seja, funciona
para qualquer um sendo só necessária a sua instalação.
A ligação entre o contador da EFACEC e o Arduino é feita através de uma porta HAN com
uma entrada RJ-11. Como tal, foi necessária a utilização de um conversor dos níveis lógicos da
UART para a especificação RS-485 de forma bidireccional e que comunica em modo half-duplex,
ou seja, apenas num sentido de cada vez. O protocolo de comunicação com o contador é o Modbus
no modo RTU.
Os esquemas apresentados nas figuras 4.3 e 4.4 centraram-se na apresentação das ligações elétricas entre os microcontroladores e os dispositivos. Para completar a ligação, cada Arduino liga
com o XBee através do Shield XBee e não foi incluído nos esquemas uma vez que apenas os tornaria complicados e de difícil leitura. Com o auxílio dos esquemas apresentados foi desenvolvido
o hardware sendo apresentado o produto final nas figuras 4.5 e 4.6.
Figura 4.3: Esquema de ligações do termoacumulador
28
Desenvolvimento
Figura 4.4: Esquema de ligações do contador
4.4
Software
A Digi disponibiliza um software de seu nome XCTU (figura 4.7) criado para a interação com
os módulos de rádio-frequência produzidos por si. Apresenta uma interface gráfica simples e fácil
de utilizar. Esta aplicação permite enviar uma lista de frames num pequeno período de tempo sem
ter de criar uma aplicação para tal. Esta funcionalidade ajudou no estabelecimento da rede uma
vez que podemos fazer debug aos parâmetros alterados de cada XBee.
Através deste software podemos também:
• Procurar, de forma automática, os XBees que estão ligados ao PC;
4.4 Software
29
Figura 4.5: Módulo a acoplar ao termoacumulador
Figura 4.6: Módulo a acoplar ao contador
• Configurar os parâmetros da rede no XBee detalhados em [19]:
Addressing;
Networking;
Security;
RF Interfacing;
Serial Interfacing;
Sleep Modes;
I/O Settings;
Diagnostic.
• Fazer update do firmware e da função pretendida para o XBee;
• Utilizar ferramentas tais como:
Gerador de Frames - utilizada para a construção das frames;
Interpretador de Frames - utilizada para a interpretação das frames.
Para facilitar a implementação no Arduino foram utilizadas as seguintes bibliotecas:
• Time - utilizada como cronómetro do Arduino para conhecer o tempo atual;
• Software Serial - permite que seja feita a comunicação via porta série em qualquer um dos
pinos digitais do Arduino;
30
Desenvolvimento
Figura 4.7: Visualização da interface XCTU da DIGI
• OneWire - conectado a um pino digital do Arduino, utiliza este protocolo para fazer leituras
dos sensores de temperatura da Maxim;
• Thread e ThreadController - permite a execução de múltiplos eventos no Arduino.
Para o XBee ligado ao PC, o código desenvolvido foi em C++ no editor Notepad++ sendo
que a sua compilação e execução ficaram a cargo do Cygwin Terminal, compilador Linux para o
Microsoft Windows. Como auxílio, foi utilizada uma biblioteca para comunicação via porta série
de nome serial_util facilitando a ligação do XBee ao PC. O anexo B detalha as suas funções e
implementação.
4.5
Implementação
Na implementação, o primeiro passo foi a criação da rede ZigBee Smart Energy (subsecção 4.5.1). De seguida, foram implementados os clusters obrigatórios de cada dispositivo Smart
Energy (subsecção 4.5.2) e, por fim, foi criado um cenário para a validação da proposta (subsecção
4.6).
4.5.1
Configuração da rede
Para começar decidiu-se qual o tipo de dispositivo lógico a implementar em cada XBee: o que
está ligado ao PC será o coordenador e os restantes terminais. Foi necessário fazer upload do
firmware Smart Energy para os XBees. Na figura 4.8 é utilizado como exemplo o upload para o
coordenador XBee.
4.5 Implementação
31
Figura 4.8: Upload do firmware Smart Energy para o coordenador
O próximo passo, antes da configuração dos parâmetros da rede, foi a obtenção de um certificado obrigatório para a implementação de todos os dispositivos Smart Energy. Os certificados de
teste (figura 4.9) são emitidos pela entidade CERTICOM. Uma vez emitido o certificado é necessário instalá-lo nos XBees. Para isso, é necessário enviar três comandos AT com as chaves geradas
no certificado: ZU - CA Public Key, ZT - Device Implicit Cert e ZV - Device Private Key. O XBee
disponibiliza um comando AT VC (verify certificate) que indica se a instalação do certificado foi
realizada com sucesso.
Para iniciar a rede, o coordenador XBee tem de ser configurado alterando os parâmetros necessários: o endereço de 64-bit identificador da rede e a lista de canais que a rede poderá utilizar.
Quando este processo terminar e a rede for criada, o Associated led (pino 15) piscará a uma
frequência de 1 Hz e o XBee emitirá através da UART uma indicação alertando que o coordenador
iniciou a rede. Neste momento, o coordenador terá de dar a indicação aos restantes dispositivos
(routers e terminais) para que se possam juntar à rede num determinado tempo e com uma chave
de autorização, definido pelo utilizador. Os dispositivos irão procurar nos canais o endereço de 64bit ao qual seja permitido juntarem-se à rede. Conhecida a chave, juntam-se à rede e vão procurar
autenticar-se nela. Utilizando comandos ZDP, os dispositivos poderão saber quais os endpoints
que suportam o key establishment cluster realizando assim a autenticação. Quando os dispositivos
se encontram na rede enviam pela UART uma indicação afirmando que a junção foi realizada de
forma correta, piscando o Associated led a 2 Hz. Durante este processo o XBee disponibiliza um
comando que permite ao utilizador ter acesso ao estado dos dispositivos em relação à rede. Na
figura 4.10 está presente um esquema representativo dos passos a efetuar para o estabelecimento
32
Desenvolvimento
Figura 4.9: Certificado de teste emitido pela CERTICOM
da rede.
A configuração do coordenador para iniciar a rede consiste no envio de comandos AT sendo
que este retorna o estado do envio desse comando. Os comandos para formar a rede são:
• ID - define o endereço de 64-bit identificador da rede;
• SC - escolhe a lista de canais que poderão ser utilizados para iniciar a rede sendo escolhido
o canal com energia mínima para que não haja conflitos com outros IDs;
• SD - duração em segundos que determina qual o canal mais adequado para iniciar a rede;
• NK - configura a chave de encriptação da rede com 128-bit;
• KY - configura a chave de ligação de 128-bit definida pelo utilizador.
Neste momento, o Associated Led (pino 15) começa a piscar a uma frequência de 1 Hz e é necessário permitir que os outros dispositivos se juntem à rede. Este passo é concretizado executando
os seguintes comandos:
• Register Joining Device API frame - permite que os dispositivos com o endereço de 64-bit
e chave KY definidas se juntem à rede, quando autorizados;
• NJ - tempo, em segundos, durante o qual o coordenador autoriza a junção de dispositivos à
rede;
• CB - definido com o parâmetro 2, indica o início da contagem de NJ segundos durante o
qual os dispositivos se podem juntar à rede.
A partir deste momento, todos os dispositivos possuem NJ segundos para se juntarem à rede.
Para isto acontecer, os dispositivos terão de executar os seguintes comandos AT:
4.5 Implementação
33
• ID - configurado com o mesmo endereço de 64-bit da rede;
• SC - define em que canais os terminais irão procurar uma ligação a uma rede e deverão
coincidir com os canais configurados no coordenado;
• EO - define o método de encriptação. Para a implementação de um dispositivo Smart Energy
Figura 4.10: Esquema da junção de routers e terminais à rede retirado de [19]
34
Desenvolvimento
este parâmetro deveria ser ativado para poder realizar o Key Establishment cluster garantindo que o dispositivo não só se junte à rede como também se autentique;
• SD - tempo, em segundos, que os terminais possuem para encontrarem ligação à rede, em
cada canal;
• KY - configurado com a mesma chave de ligação de 128-bit;
• CB - definido com o parâmetro 1 indicando que se pretende juntar à rede criada pelo coordenador.
Neste momento, o Associated Led deveria estar permanentemente ligado sendo importante
referir que existe um comando AT, de seu nome Association Indication (AI) que fornece informações sobre o estado da ligação à rede. Este comando é útil uma vez que, consultando-o, é possível
saber o estado atual da ligação. Neste momento, deveria estar com a indicação de falha 0x30 (Discovering Key Establishment Endpoint) à espera que seja encontrado um endpoint disponível para
a execução dos comandos do Key Establishment cluster (figura 4.11).
Figura 4.11: Comandos do key establishment cluster realizados entre o initiator (terminais) e
responder (coordenador) retirado de [15]
Estes comandos não foram concretizados uma vez que a complexidade dos métodos de encriptação não se enquadra no âmbito desta dissertação.
Mantendo o comando EO desativado, configurando o comando AT CB com o parâmetro 1 e
estando todas as configurações corretas, os dispositivos juntam-se à rede estabelecendo assim a
ligação com o coordenador. Para confirmar, o Associated Led começa a piscar a uma frequência
de 2 Hz, o comando AT AI é atualizado com o valor 0x00 (indicador de sucesso) e é enviado ao
4.5 Implementação
35
coordenador o comando ZDP Device announce através do comando Explicit Addressing ZigBee
Command Frame a anunciar a junção à rede.
Como se trata de um terminal, é necessário configurar os comandos sleep permitindo a cada
dispositivo poupar energia enquanto está inativo. Os comandos de configuração são os seguintes
e foram atribuídos com os parâmetros indicados:
• SM - configura o modo de sleep do dispositivo. O parâmetro 4 indica que o dispositivo terá
ciclos fixos de sleep;
• SP - representa o tempo, em segundos, em que o dispositivo é ativado para confirmar se
recebeu ou não alguma mensagem. Foi utilizado o parâmetro 5 segundos;
• ST - representa o tempo, em segundos, em que ele se mantém ativo depois de ter estado em
atividade e foi configurado com o parâmetro 20 segundos.
A figura 4.12 mostra o funcionamento de um terminal utilizando os parâmetros atrás mencionados. Como podemos verificar em períodos fixos de 5 segundos (comando SP), o XBee fica ativo
para verificar se tem alguma frame para receber e quando lhe é enviada uma, ele recebe e fica ativo
durante 20 segundos (comando ST).
Figura 4.12: Demonstração da configuração dos comandos sleep
A figura 4.13 é uma representação dos comandos AT a efetuar para cumprir todo este procedimento. Alguns comandos não estão representados porque os parâmetros default são suficientes e
o facto de os comandos sleep serem executados antes da junção do terminal à rede é apenas uma
questão de otimização, enquanto espera pela autorização do coordenador pode executá-los.
36
Desenvolvimento
Coordenador
Terminais
AT Command - ZU
AT Command - ZU
AT Command - ZT
AT Command - ZT
AT Command - ZV
AT Command - ZV
AT Command – ID
AT Command - ID
Modem Status
AT Command - KY
AT Command - KY
AT Command - EO
Register Joining
Device API frame
AT Command - SM
AT Command - CB
AT Command - SP
AT Command - ST
AT Command - CB
Explicit Addressing
Zigbee Command
Frame – Device
announce
Tempo NJ
Modem Status
Figura 4.13: Esquema de criação e junção à rede
4.5.2
Dispositivos Smart Energy implementados
Criada a rede, os passos seguintes foram a escolha dos dispositivos Smart Energy e a implementação do cluster obrigatório a todos os dispositivos Smart Energy: o Basic Cluster.
Apresentados os dispositivos na secção 2.3, concluiu-se que a utilização dos dispositivos Smart
Energy, o Load Control device e o Metering device seriam os mais adequados uma vez que os
dispositivos a utilizar se tratam de uma carga e de um dispositivo de medição respetivamente.
4.5.2.1
Termoacumulador
Do lado do coordenador, este implementa três comandos de controlo de cargas: Load Control
Event que controla as cargas de acordo com a informação enviada, Cancel Load Control Event que
cancela o controlo de cargas definido pelo comando anterior e o Cancel all Load Control Event
que cancela todos os comandos de um dispositivo.
Do lado do dispositivo Smart Energy, o Load Control Device implementa os seguintes atributos no dispositivo: UtilityEnrolmentGroup que define a qual grupo que o dispositivo está inserido,
StartRandomizeMinutes que representa o número máximo de minutos que o dispositivo pode atrasar o início do evento, StopRandomizeMinutes que representa o número máximo de minutos que
o dispositivo pode atrasar o fim do evento e o DeviceClassValue que indica o tipo de dispositivor.
4.5 Implementação
37
Estes registos são definidos com os valores default podendo, contudo, serem alterados a qualquer
altura, remotamente.
O termoacumulador terá de ser capaz de armazenar até três eventos, executando-os de acordo
com o seu tempo de início e a sua duração. Se receber mais do que três eventos, o dispositivo
ignora-os nesse instante e quando tiver oportunidade deverá utilizar o comando GetSchedulingEvents para recuperar esses mesmos eventos. No dispositivo são implementados dois comandos: o
já mencionado GetScheduledEvents e o ReportEventStatus. O primeiro é utilizado para verificar se
existe algum comando à espera para ser recebido quer quando tem oportunidade de armazenar quer
depois de uma falha de energia que tenha causado reset ao dispositivo. O segundo deteta e envia
ao coordenador informações do estado dos comandos enviados por ele. Para além dos comandos
e atributos associados ao Load Control device, está implementado neste dispositivo o Thermostat
cluster fornecendo à Gateway o registo da temperatura atual da água do termoacumulador lida
através do sensor instalado.
Com os comandos e atributos explicados e implementados, foi criada uma rotina automática
utilizando duas threads:
• Leitura e interpretação dos dados recebidos pelo XBee - apenas considera as frames recebidas de forma correta ( que obedeçam ao seguinte: começa com o start byte 0x7E, o length
confere com o tamanho da frame e o checksum está corretamente calculado ) e mediante a
informação recebida, é armazenado o conteúdo e retornada uma resposta para a Gateway.
O armazenamento de eventos é feito num array de três posições onde os eventos são guardados ordenadamente. Com esta organização, apenas é necessário ter em atenção o evento
posicionado na primeira posição pois será o próximo a ser executado. No caso de receber eventos que colidam temporalmente, o que for recebido mais recentemente é o evento
válido, eliminando todos os anteriores. Quando isso acontece, a Gateway é notificada.
• Execução dos eventos armazenados - em cada evento de duração definida é recebido um
setpoint de temperatura enviado pela Gateway. A temperatura real do termoacumulador é
medida e comparada com esse setpoint. Se for menor, o relé é ativado ligando o termoacumulador. Pelo contrário, se for maior, é desativado. É considerada uma histerese de 2o C
para evitar que o relé esteja constantemente a comutar. Apesar do termoacumulador ter um
termostato interno de proteção, considerou-se uma saturação do setpoint recebido a 70o C
sendo que todos os eventos recebidos com setpoint superior a este valor serão descartados.
4.5.2.2
Contador
Através da porta HAN do contador, é possível saber informações internas ( a data e hora atual,
o seu modelo e o seu identificador) e medir a tensão, a corrente, a energia ativa e reativa, a potência
ativa e reativa e a frequência num determinado ponto na rede.
Do lado do contador, este contém apenas os atributos obrigatórios: CurrentSummationDelivered que representa a soma do valor de energia mais recente entregue ao cliente pela empresa
de fornecimento de energia, o Status que representa os possíveis erros nas medições que poderão
38
Desenvolvimento
estar a ocorrer, o Formatting Attributes que é composto por 3 atributos e representam unidades
de medida e os formatos de apresentação do valor lido. Este dispositivo não contém qualquer comando obrigatório e como apenas se implementou num aparelho de medição não foi considerado
útil a inclusão de nenhum dos opcionais. Do lado do coordenador, este apenas poderá ler estes
atributos. Sempre que tentar escrever este retorna uma mensagem de erro.
Para o contador inteligente está criada uma rotina que periodicamente faz a leitura dos registos
disponíveis no contador e atualiza os atributos de acordo com esses registos. Sempre que é pedido
pelo XBee uma leitura de atributos, responde com os dados requeridos.
O módulo desenvolvido foi testado com outros contadores MBOX comprovando a sua usabilidade em outros dispositivos.
4.6
Validação da proposta
Explicada a implementação dos dois dispositivos Smart Energy e tendo todos os comandos
e atributos a funcionar corretamente, passamos à fase da validação da proposta apresentando um
caso prático em ambiente doméstico.
Com a integração de painéis fotovoltaicos neste ambiente, a necessidade de se fazer uma boa
gestão da energia gerada tornou-se indispensável. Como não compensa armazenar essa energia
devido aos elevados preços de armazenamento e como os incentivos oferecidos pela entidade responsável pela distribuição de energia em Portugal estão a desaparecer, otimizar o seu uso tornou-se
uma necessidade. No caso dos termoacumuladores, equipamentos são termicamente isolados, significando que aquecer a água agora ou mais tarde é praticamente irrelevante e se o pudermos fazer
agora aproveitando a energia gerada, cujo custo de utilização é reduzido (praticamente zero), é de
interesse fazê-lo. Quando a energia é gerada e injetada na rede provoca alterações nesta como por
exemplo a subida de tensão de acordo com a potência injetada.
Na figura 4.14 está presente um esquema representativo do procedimento executado na simulação.
Gateway
Faz o pedido do valor de
Tensão e Temperatura
Contador
Tensão e Temperatura
enviadas à Gateway
Termoacumulador
Envio do comando de
controlo
Figura 4.14: Esquema da simulação efetuada no laboratório Smart Grids do INESC
4.6 Validação da proposta
39
Inicialmente, a Gateway lê a tensão da rede através do contador e a temperatura do termoacumulador de dois em dois segundos sendo essas medidas registadas no gráfico 4.15.
V
ºC
s
Figura 4.15: Simulação efetuada no laboratório Smart Grids do INESC TEC
O controlo foi feito utilizando as seguintes regras:
• A Gateway envia um evento com um setpoint de temperatura de 0o C se a tensão lida:
- For inferior a 217,0 V;
- Estiver entre 217,0 V e 230,0 V durante 10 s.
• A Gateway envia um evento com um setpoint de temperatura de 70o C se a tensão lida:
- Estiver entre 237,0 V e 242,0 V durante 10 s e se a temperatura do termoacumulador
for inferior a 60o C.
- For superior a 242,0 V;
A duração de cada evento é de 60 s (duração mínima) embora haja uma atualização de eventos
a cada 10 s. Sempre que estiver a decorrer um evento e o termoacumulador receber outro que
colida temporalmente, o evento recebido é guardado e executado sendo o atual cancelado. Estes
acontecimentos são reportados à Gateway. Caso não colida, o evento recebido é armazenado no
array de forma ordenada, sendo posteriormente executado.
Podemos observar que inicialmente a tensão é de aproximadamente 233,4 V e que a temperatura do termoacumulador tem valor constante 26,31o C. Numa dada altura, os painéis injetam na
rede 1,5 kW de potência provocando uma sobretensão na rede (subindo de 233,4 V para 238 V
aos 44 s). Como o valor de tensão se manteve entre os 237,0 e os 242,0 V durante 10 s, a Gateway
envia um evento para o termoacumulador com uma alteração do seu setpoint de temperatura 0o C
(desligado) para 70o C (ligar) fazendo com que o termoacumulador ligue e a sobretensão deixe de
ocorrer (descendo a tensão de 238 V para 232,8 V aos 70 s). A potência consumida pelo termoacumulador é de 1,5 kW justificando assim a redução da tensão até ao nível inicial, aproximadamente.
40
Desenvolvimento
Com o termoacumulador ligado, a temperatura começa a subir com um atraso de cerca de 17 segundos. Este atraso deve-se ao facto do sensor estar posicionado no topo do termoacumulador e
da necessidade de aquecer um volume de água de 50 litros.
No momento em que termina o fenómeno de sobretensão, existe uma subtensão (descida da
tensão de 232,8 V para 228,4 V aos 192 s). Como o valor de tensão se manteve entre os 237,0 e os
242,0 V durante 10 s, a Gateway, em reação a esse acontecimento, altera o setpoint de temperatura
dos eventos de 70o C para 0o C fazendo com que o termoacumulador se desligue voltando a tensão
ao estado inicial aos 210 s. Tendo estado o termoacumulador ligado durante 2 minutos, a água
aumentou dos 26,31o C até aos 29o C. Existem dois períodos (120 s e 156 s) em que ocorrem
desvios na leitura da temperatura. Contudo, esses desvios são de aproximadamente 0,5 o C, valor
tolerável e que se encontra na especificação do leitor de temperatura.
Capítulo 5
Conclusões e Trabalho Futuro
Este capítulo faz uma apreciação global do trabalho desenvolvido (secção 5.1) e apresenta
trabalhos futuros (secção 5.2) que poderão utilizar este trabalho como base tornando-o de um
maior valor científico e com margem de desenvolvimento.
5.1
Apreciação global
A tecnologia ZigBee é ainda uma tecnologia em afirmação possuindo grande margem de crescimento a nível doméstico tendo como principais caraterísticas a eficiência energética e o nível
elevado de segurança, favoráveis a este crescimento.
O trabalho desenvolvido nesta dissertação cumpriu os objetivos descritos na secção 1.3. Assim, foram criados os dispositivos Smart Energy que, com o apoio da simulação apresentada
pode-se afirmar que são monitorizáveis e controláveis quando integrados numa rede ZigBee Smart
Energy. Os requisitos definidos mostraram ser os adequados à dissertação sendo que todos foram
cumpridos.
Comparativamente às Smart Appliances de controlo (tomadas inteligentes) apresentadas na
secção 2.1, o dispositivo de controlo desenvolvido possui um mecanismo mais seguro. As tomadas inteligentes apenas obedecem à ação ligar / desligar sendo que, quando houver algum problema
com a rede, manterá o seu estado até a existência de uma intervenção humana. O termoacumulador inteligente recebe setpoints de temperatura e a gestão é feita por si. Se houver problema na
rede, ele fará a sua gestão de forma automática, alterando o estado sempre que as condições de
temperatura o exijam.
Apesar de ter sido desenvolvida uma Gateway de controlo simples, o objetivo era provar que
é possível integrá-la em ambiente doméstico fazendo monitorização de informação da rede e controlo de cargas.
Com este trabalho é também possível concluir que desde que se desenvolva um módulo que
permita comunicar com o dispositivo e que seja compatível com a utilização da tecnologia ZigBee,
é possível a integração desta tecnologia em dispositivos de diferentes marcas.
41
42
Conclusões e Trabalho Futuro
O material utilizado, apesar de ser o mais económico no mercado é ainda significativamente
oneroso. Como cada dispositivo necessitaria de um dos blocos especificados anteriormente na
arquitetura proposta (secção 3.1), o preço multiplicar-se-ia em função da quantidade de dispositivos existentes. Porém, a tecnologia ainda está em fase de crescimento. Com o seu aumento de
popularidade, os componentes vão ficando a um preço mais acessível tal como aconteceu outrora
com outras tecnologias como é exemplo o Wi-Fi.
O estudo e os desenvolvimentos efetuados permitiram uma maior aprendizagem na utilização
da tecnologia wireless ZigBee, adquirir experiência no desenvolvimento de hardware para diferentes tipos de equipamentos e de diferentes marcas e conhecer alguns comportamentos na rede
elétrica.
5.2
Trabalho futuro
Para tornar a implementação dos dispositivos de acordo com o perfil Smart Energy é necessário
autenticá-los na rede concretizando, com sucesso, o envio dos comandos do Key Establishment
Cluster. Os algoritmos para a codificação das chaves são de complexidade elevada e é necessário
um especialista para as codificar antes de serem enviadas por cada XBee.
Recentemente, os benefícios da produção de energia para consumo próprio e da utilização dos
carros elétricos em detrimento dos carros a combustível fóssil está a intensificar a necessidade de
uma melhor gestão da energia. Para trabalho futuro, sugere-se a expansão do cenário demonstrado
na secção 4.6 até um caso mais complexo: uma família que vive num prédio e possui carro elétrico
e micro-geração de energia, para além dos eletrodomésticos usuais numa habitação. Para ter um
sistema de gestão de energia é necessário ter todos estes equipamentos ligados a uma rede. O que
se propõe é a instalação de uma rede ZigBee Smart Energy que permita monitorizar a produção de
energia e fazer uma gestão automática das cargas. A caraterística multi-hopping desta tecnologia
explicada na secção 2.2.1 é de uma maior valia para conseguir que o sinal se consiga propagar do
apartamento da família até à cave e ao terraço do prédio, locais onde se localizam os dispositivos
mais distantes: o carregador do carro elétrico e os painéis fotovoltaicos.
No apartamento seria proveitoso ter um display, substituindo sofesticadamente a Gateway do
trabalho desenvolvido nesta dissertação, que pudesse mostrar aos utilizadores informações acerca
do seu consumo diário e sugestões de como reduzir os seus desperdícios.
Para fazer a ligação entre os equipamentos mais distantes e o display / Gateway seria necessário a existência de routers intermédios, usufruindo da caraterística multi-hopping, sendo que a
quantidade dependeria das caraterísticas do edifício. Em todos eles seria implementado o dispositivo Smart Energy Range Extender.
Anexo A
Soluções rejeitadas do estudo de
mercado
Proposta no 1
Tabela A.1: 1x Kit
Fabricante:
Referência:
URL Fabricante:
Custo:
Kit inclui:
Anaren
A2530E24A-LPZ
https://www.anaren.com/air/cc2530-boosterpack-kit
93,42 e
• Três módulos de comunicação A2530E24A;
• Microcontrolador MSP430G2553IN20;
• Inclui dois suportes de baterias AA para operação remota.
Para reprogramar a Z-Stack:
Tabela A.2: 1x CC Debugger
Fabricante:
Referência:
URL Fabricante:
Custo:
Texas Instruments
CC-DEBUGGER
http://www.ti.com/tool/cc-debugger
43,98 e
Tabela A.3: 1x IAR workbench software
Fabricante:
Referência:
IAR
EW8051
URL Fabricante:
https://www.iar.com/
iar-embedded-workbench/8051/
Custo (licença):
2500 e(multi-user) | 2250 e(pessoal) |
1250 e(educacional)
43
44
Soluções rejeitadas do estudo de mercado
Proposta no 2
Tabela A.4: 1x Kit
Fabricante:
Referência:
URL Fabricante:
Custo:
Kit inclui:
Texas Instruments
CC2530DK
http://www.ti.com/tool/cc2530dk
378,70 e
• 2x módulos de comunicação CC2530;
• 2x placas SmartRF05EB;
• 2x antenas 2,4GHz.
Tabela A.5: 2x Microcontroladores
Fabricante:
Referência:
Texas Instruments
MSP-EXP430F5438
URL Fabricante:
http:
//www.ti.com/tool/msp-exp430f5438
Custo:
150,82 e
Anexo B
Biblioteca Serial_util
45
ANEXO 1
Biblioteca serial_util
1.
O acesso à porta série é realizado através de uma biblioteca específica: serial_util.
Esta é constituída pelos seguintes ficheiros:


serial_util.c, que contém o código das funções
serial_util.h, que contém as definições das funções
serial_open()
serial_config()
serial_read()
serial_write()
serial_close()
API
Driver da porta
série
Buffers: saída
entrada
/dev/ttySx
(x = 0, 1, 2, 3)
Porta série
A correspondência entre as portas série do Linux e do Windows é a seguinte:

/dev/ttyS0 ↔ COM 1

/dev/ttyS1 ↔ COM 2

/dev/ttyS2 ↔ COM 3

/dev/ttyS3 ↔ COM 4

.....
Esta biblioteca disponibiliza um conjunto de funções que permitem aceder de forma simples e
transparente à porta série.
Nota: estas bibliotecas foram desenvolvidas por forma a desactivar o controlo de fluxo das
portas série (RTS e CTS). Por isso os sinais destes pinos não podem ser controlados.
FEUP – DEEC
int serial_open (const char* device);
// Abre a porta
//
// Argumentos:
//
//
//
// Retorna:
//
/
//
//
série /dev/ttySx, x=(0,1,2,3)
device: string (do tipo “/dev/ttySx”) com a identificação
(ie. 'nome')da porta série que se pretende abrir.
>0: sucesso, descritor (identificador interno do
sistema operativo) que identifica qual a porta série utilizada.
<0: erro, não conseguiu abrir a porta.
int serial_read(int fd, uchar *buf, uint bufsize, uint timeout);
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
Lê caracteres da porta série
Argumentos:
Retorna:
Notas:
fd: descritor da porta série (obtido com serial_open()).
buf: buffer para onde os dados são escritos.
bufsize: tamanho do buffer de escrita.
timeout: tempo de espera máximo, em segundos, pela
recepção dos dados.
>=0: sucesso, número de caracteres lidos.
<0: erro, acesso à porta série.
A função bloqueia até um dos seguintes eventos ocorrer (o que
ocorrer primeiro):
- o timeout expirar
- ter recebido o número de caracteres especificado em bufsize
int serial_write(int fd, uchar *buf, uint bufsize);
// Envia caracteres para a porta série
//
// Argumentos:
//
//
//
// Retorna:
//
//
//
// Notas:
//
//
//
//
fd: descritor da porta série (obtido com serial_open()).
buf: buffer onde estão os dados a enviar.
bufsize: tamanho do buffer de envio.
>=0: sucesso, número de caracteres enviados.
<0: erro, acesso à porta série.
A função bloqueia até ter terminado o envio dos caracteres para
o buffer de saída. Não confundir com a transmissão dos mesmos na
interface física (ie. porta série do PC)
FEUP – DEEC
int serial_close (int fd);
// Fecha a porta série
//
// Argumentos:
//
// Retorna:
//
//
//
fd: descritor da porta série (obtido com serial_open()).
>0: sucesso
<0: erro, não conseguiu fechar a porta série
int serial_config(int fd, tcflag_t baudrate, tcflag_t charsize, tcflag_t stopbits,
tcflag_t parity);
// Permite configurar os parâmetros da porta série
//
// Argumentos:
//
fd: descritor da porta série (obtido com serial_open()).
//
baudrate: taxa de transmissão. Valores pré-definidos em:
//
#define DEF_BAUDRATE
//
charsize: número de bits dos caracteres. Valores pré-definidos em:
//
#define DEF_CHAR_SIZE
//
stopbits: número de stop bits. Valores pré-definidos em:
//
#define DEF_STOP_BITS
//
parity: paridade dos caracteres. Valores pré-definidos em:
//
#define DEF_PARITY
// Retorna:
//
>=0: sucesso
//
<0: erro
//
FEUP – DEEC
ANEXO
1.
Introdução
Este anexo tem como função realizar uma introdução simples ao RS-232. Uma melhor descrição
pode ser encontrada no documento RS-232 Chapter que se encontra nos conteúdos da disciplina.
2.
Transmissão Série Assíncrona
A transmissão série (assíncrona) é uma transmissão orientada ao caracter, em que cada caracter
(~byte) é transmitido sob a forma de um sinal digital com as seguintes características:
Caracter transmitido
Mark (1)
D0
D1
D2
D3
D4
D5
D6
D7
Space (0)
Start
bit
Bits de dados
Parity Stop
Bit
Bit
Tempo
Transmissão série assíncrona

Sinal digital:
o 1 lógico : Mark
o 0 lógico : Space

Start bit (0 lógico): utilizado para indicar o início da transmissão do caracter;

Bits de dados (D0…D7): caracter transmitido. Pode configurado de 5 a 9 bits, dependendo
do código utilizado (ex. código ASCII, 7 bits);

Bit de paridade (parity bit): utilizado para detectar eventuais erros na transmissão. Pode
ser configurado de 5 formas:
o Par (Even): o número de 1s (lógicos) transmitidos (D0…D7 + parity bit) é sempre
par.
o Ímpar (Odd): o número de 1s (lógicos) transmitidos (D0…D7 + parity bit) é sempre
ímpar.
o Mark: é transmitido um 1 lógico.
o Space: é transmitido um 0 lógico.
o Nenhuma: ausente.

Stop bits (1 lógico): utilizado para indicar o fim da transmissão e garantir o espaçamento
temporal entre caracteres consecutivos. Pode ser configurado como 1, 1.5 ou 2 bits;

Taxa de transmissão (baud rate): 300 a 115200 bits/s (porta série do PC).
FEUP – DEEC
A duração de cada bit transmitido = 1 / {taxa de transmissão}.
Transmissão da letra M (código ASCII 77 = 1001101 )
7 bits, paridade par , 1 stop bit
1
Start
bit
0
1
1
0
Bits de dados
0
1
0
Parity Stop
Bit
Bit
Tempo
Exemplo da transmissão da letra M
RS-232
3.
O RS-232 é um protocolo de nível físico definido originalmente para as comunicações entre um
computador ou um terminal (DTE) e um modem (DCE) e que utiliza uma transmissão série
assíncrona (também suporta um modo síncrono).


DTE (Data Terminal Equipment)
DCE (Data Circuit-Terminating Equipment)
Exemplos da utilização do RS-232.
Embora tenha sido desenvolvido para ligações DTE↔DCE, é presentemente utilizado quase sempre
para ligações DTE↔DTE.
FEUP – DEEC
3.1. Sinais RS-232
A interface física é implementada utilizando (na maioria dos casos) 1 conector de 9 pinos (DB9) ou
de 25 pinos (DB25) , com os seguintes sinais:
Ficha DB9 macho (PC)
●
●
●
●
●
●
●
Ficha DB25 macho (PC)
DTR (Data Terminal Ready, sinal de saída): o equipamento DTE indica que está ligado.
DSR (Data Set Ready, sinal de entrada): o equipamento DCE (ou o outro equipamento DTE)
indica que está ligado.
DCD (Data Carrier Detected, sinal de entrada): o equipamento DCE (o modem) indica que
detectou a portadora da linha telefónica (sinal sonoro que se “ouve” quando se levanta o
auscultador do telefone). Só tem sentido quando se utilizam modems.
RI (Ring Indicator, sinal de entrada): o equipamento DCE indica que detectou o sinal que
indica que o telefone está a tocar (ring). Só tem sentido quando se utilizam modems.
RTS (Request to Send, sinal de saída): o equipamento DTE indica que está pronto enviar
dados.
CTS (Clear To Send, sinal de entrada): o equipamento DCE (ou o outro equipamento DTE)
indica que está pronto para receber os dados.
TxD (Transmit Data, sinal de saída): o equipamento DTE utiliza esta saída para transmitir
dados.
●
RxD (Receive Data, sinal de entrada): o equipamento DCE recebe os dados nesta entrada.
●
SG (Signal Ground): referência de tensão (0V, massa).
FEUP – DEEC
Exemplo dos sinais disponíveis da porta série de um PC (DTE)
Os sinais na interface física são transmitidos como um sinal digital com as seguintes características
(num PC):
●
●
Mark: -12V
Space: +12V
FEUP – DEEC
3.2. Ligações entre equipamentos
As ligações entre dois equipamentos (DTE) podem ser implementadas da seguinte forma:

Este cabo (Null Modem) é utilizado quando pretende utilizar os sinais de handshake: DSR,
DTR, RTS e CTS. É também por vezes denominado 'cabo cruzado':

Este cabo é utilizado quando não se pretende (ou quando não é necessário) utilizar os os
sinais de handshake. É também por vezes denominado 'cabo de 3 fios':
54
Biblioteca Serial_util
Bibliografia
[1] A. Kailas, V. Cecchi, and A. Mukherjee, “A survey of communications and networking technologies for energy management in buildings and home automation,” Journal of Computer
Networks and Communications, vol. 2012, 2012.
[2] S. Tozlu, M. Senel, W. Mao, and A. Keshavarzian, “Wi-fi enabled sensors for internet of
things: A practical approach,” Communications Magazine, IEEE, vol. 50, no. 6, pp. 134–
143, 2012.
[3] B. Lu and V. C. Gungor, “Online and remote motor energy monitoring and fault diagnostics using wireless sensor networks,” Industrial Electronics, IEEE Transactions on, vol. 56,
no. 11, pp. 4651–4659, 2009.
[4] Z. Alliance, “index @ zigbee.org.” [Online]. Available: http://zigbee.org/
[5] IEEE, “index @ www.ieee.org.” [Online]. Available: https://www.ieee.org/index.html
[6] K. De Craemer and G. Deconinck, “Analysis of state-of-the-art smart metering communication standards,” in Proceedings of the 5th young researchers symposium, 2010.
[7] C. Gomez and J. Paradells, “Wireless home automation networks: A survey of architectures
and technologies,” IEEE Communications Magazine, vol. 48, no. 6, pp. 92–101, 2010.
[8] Z. Alliance, “Zigbee home automation public application profile, 2010,” ZigBee Standards
Organization, 2007.
[9] P. Yi, A. Iwayemi, and C. Zhou, “Developing zigbee deployment guideline under wifi interference for smart grid applications,” Smart Grid, IEEE Transactions on, vol. 2, no. 1, pp.
110–120, 2011.
[10] M. Chen, J. Wan, S. González, X. Liao, and V. Leung, “A survey of recent developments
in home m2m networks,” Communications Surveys & Tutorials, IEEE, vol. 16, no. 1, pp.
98–114, 2014.
[11] A. G. Bajaj and V. R. Bajaj, “Build an ieee 802.15. 4 wireless sensor network for emergency
response notification for indoor situations.”
55
56
BIBLIOGRAFIA
[12] A. Elahi and A. Gschwender, ZigBee wireless sensor and control network. Pearson Education, 2009.
[13] J. Li, X. Zhu, N. Tang, and J. Sui, “Study on zigbee network architecture and routing algorithm,” in Signal Processing Systems (ICSPS), 2010 2nd International Conference on, vol. 2.
IEEE, 2010, pp. 389–393.
[14] D. Liu and H. Yu, “An efficient improvement approach for topology formation in zigbee
network,” in Information and Communication Technologies (WICT), 2012 World Congress
on.
IEEE, 2012, pp. 1081–1085.
[15] Z. Alliance and Z. Specifications, “Zigbee document 053474r17,” ZigBee Specification, ZigBee Alliance, 2008.
[16] Z. Alliance, “Zigbee cluster library specification,” ZigBee Document 075123r04ZB, 2012.
[17] ——, “Zigbee smart energy profile,” ZigBee Document 075356r16ZB, pp. 1–304, 2011.
[18] M. Dworkin, Recommendation for block cipher modes of operation: The CCM mode for
authentication and confidentiality. US Department of Commerce, Technology Administration, National Institute of Standards and Technology, 2004.
R / XBee-PRO R SE ( Smart Energy ) RF Modules, 2012.
[19] Digi International Inc., XBee