Desenvolvimento de um Protótipo de um Sistema Domótico · 2.1.1 Estrutura genérica de um...
79
Desenvolvimento de um Protótipo de um Sistema Domótico Francisco Daniel Matos Pinto Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Professor Doutor Nuno Cavaco Gomes Horta Orientador: Professor Doutor Renato Jorge Caleira Nunes Co-Orientador: Professor Doutor António Manuel Raminhos Cordeiro Grilo Vogal: Professor Doutor Alberto Manuel Ramos da Cunha Outubro de 2010
Transcript of Desenvolvimento de um Protótipo de um Sistema Domótico · 2.1.1 Estrutura genérica de um...
Desenvolvimento de um Protótipo de um Sistema
Domótico
Francisco Daniel Matos Pinto
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Professor Doutor Nuno Cavaco Gomes Horta
Orientador: Professor Doutor Renato Jorge Caleira Nunes
Co-Orientador: Professor Doutor António Manuel Raminhos Cordeiro Grilo
Vogal: Professor Doutor Alberto Manuel Ramos da Cunha
Outubro de 2010
III
Agradecimentos
Gostaria de agradecer a todos aqueles que me apoiaram nesta dissertação e também ao longo
da minha vida académica.
Ao Professor Renato Nunes, orientador da presente dissertação, pelo apoio, orientação e
disponibilidade.
Aos meus Pais e irmã, o meu profundo agradecimento pela possibilidade de obter este Curso e
pelo acompanhamento e apoio incondicional ao longo de toda a minha vida.
À Magui, por toda a compreensão, preocupação, dedicação e enorme ajuda a ultrapassar os
obstáculos encontrados.
Aos meus colegas e amigos, em especial ao Diogo Primor, Gilberto Rodrigues, Jorge Carola,
Luís Pragosa e Rafael Ferreira, pela amizade e pelo acompanhamento durante o percurso
académico. Gostaria também de agradecer ao Marco e ao Miguel e a todos os meus colegas
da Sala de TFC da Área Científica de Electrónica.
IV
V
Resumo
A automação de habitações – domótica – é um assunto que suscita o interesse da população
em geral. A existência de sistemas para realizar tarefas rotineiras, tornar a habitação mais
segura e ao mesmo tempo permitir poupar recursos como energia eléctrica, alicia o comum dos
consumidores. Um sistema domótico agrega um conjunto de tecnologias e de mecanismos que
funcionam em conjunto e como tal, necessitam de ser facilmente integráveis para melhor
servirem o utilizador. As soluções disponíveis actualmente possuem diversas restrições das
quais se destacam a sua incapacidade de interactuarem com outras tecnologias, dificuldade de
evoluírem e de se adaptarem a novas necessidades dos utilizadores e possuírem um elevado
custo.
Este trabalho foi desenvolvido no contexto do sistema DomoBus que tem como principais
objectivos ser flexível, integrável e de baixo custo, assim como oferecer mecanismos de
suporte à interoperação com outras tecnologias. No sentido de dar um contributo para melhorar
o sistema DomoBus foi desenvolvido trabalho ao nível dos seus Módulos de Controlo os quais
são implementados por sistemas embebidos de muito baixo recursos em termos de memória e
capacidade de processamento. Foi desenhada uma nova a arquitectura de software para os
módulos tendo como principais objectivos reduzir a complexidade das aplicações, simplificar o
seu desenvolvimento, torná-las mais fiáveis, oferecer capacidades multitarefa e garantir
características de tempo real. Adicionalmente foram desenvolvidas facilidades de comunicação
robustas que suportam retransmissões, optimizam o uso da largura de banda disponível e
evitam congestionamentos. Isto constituiu um desafio muito significativo devido aos recursos
extremamente limitados do microcontrolador usado, particularmente ao nível da memória. A
solução desenvolvida mostrou-se flexível e robusta, sendo facilmente portável para outras
plataformas embebidas dada a sua generalidade e independência quer do microcontrolador
usado quer de outros recursos específicos, nomeadamente ao nível da comunicação.
Palavras-chave:
Domótica, DomoBus, sistemas embebidos, aplicações domóticas, protocolos de comunicação,
sistemas de tempo real.
VII
Abstract
Home automation - domotics - is a subject on which the population in general is interested. The
existence of systems with the possibility of performing routine chores and, at the same time, of
making resources saving, such as electrical energy, attracts a typical consumer. A domotic
system aggregates a group of technologies and mechanisms that work together and so, should
be easily integrable to better serve the user. The solutions that currently exist have some
restrictions namely the incapacity to interact with other technologies, difficulties to upgrade and
to adapt to the new needs of the users and are expensive.
This work was developed in the context of the domotic system DomoBus which intends to be a
flexible, integrable and low cost solution for home automation, and to provide mechanisms that
support interoperation with other technologies. The main objective of this dissertation is to
enhance the DomoBus system, developing a new version of the Control Modules that are
implemented by embedded systems with very low memory and processing resources. The goal
of this work is to design and implement a new software architecture that provides multitask and
real-time capabilities and reduce the complexity of applications, simplifying their development
and enhancing their reliability. Additionally it was also developed a new communication software
module that ensures robust communications that support retransmissions, optimizes bandwidth
usage and avoids congestions. The fulfillment of these features was very challenging due to the
extremely low memory resources available on the microcontroller used. The developed solution
proved to be flexible and robust, and easily portable to other embedded platforms due to its
generality and independence of specific hardware features offered by the microcontroller,
namely at the communication level.
Key-words:
Domotics, DomoBus, embedded systems, domotic applications, communication protocols, real-
time systems.
IX
Índice
Agradecimentos............................................................................................................................ III
Resumo ......................................................................................................................................... V
Abstract ....................................................................................................................................... VII
Índice ............................................................................................................................................ IX
Lista de tabelas ............................................................................................................................ XI
Lista de figuras ............................................................................................................................ XII
Lista de abreviações ................................................................................................................. XIV
1 Introdução ............................................................................................................................. 1
1.1 Enquadramento ............................................................................................................. 1
1.2 Objectivos ...................................................................................................................... 2
1.3 Estrutura da dissertação ............................................................................................... 3
2 Trabalho relacionado ............................................................................................................ 5
2.1 Protocolos no domínio da Domótica ............................................................................. 5
2.1.1 Estrutura genérica de um protocolo de comunicação ........................................... 5
2.1.2 Protocolos de comunicação vocacionados para domótica ................................... 6
2.1.3 Suporte à interoperação ........................................................................................ 9
2.1.4 Outros protocolos de comunicação ....................................................................... 9
2.1.5 Comparação de tecnologias com aplicabilidade domótica ................................. 12
2.2 Sistemas Operativos e ambientes de desenvolvimento ............................................. 13
2.3 Microcontroladores ...................................................................................................... 16
2.4 Sistema DomoBus ....................................................................................................... 19
3 Sistema DomoBus .............................................................................................................. 21
3.1 Componentes do sistema ............................................................................................ 21
3.2 Rede do sistema DomoBus e acesso ao meio ........................................................... 22
3.3 Hardware dos módulos ............................................................................................... 24
3.3.1 Módulos de Controlo ........................................................................................... 24
3.3.2 Módulos de Supervisão ....................................................................................... 25
3.4 Software dos Módulos de Controlo ............................................................................. 26
4 Arquitectura de software dos Módulos de Controlo ........................................................... 29
4.1 Núcleo de tempo real .................................................................................................. 29
4.2 Comunicação ............................................................................................................... 30
4.3 Suporte das aplicações DomoBus .............................................................................. 32
4.3.1 Módulo de Gestão das Propriedades .................................................................. 35
4.3.2 Módulo de Tratamento das Mensagens .............................................................. 35
4.3.3 Módulo de acesso à EEPROM ............................................................................ 37
4.4 Aplicações DomoBus implementadas ......................................................................... 37
4.4.1 Aplicação de gestão do nó .................................................................................. 37
4.4.2 Aplicação Relay – Actuações ligar/desligar ........................................................ 37
X
4.4.3 Aplicação Switch – Leitura de interruptores ........................................................ 38
5 Detalhes de Implementação ............................................................................................... 39
5.1 Comunicação ............................................................................................................... 39
5.2 Suporte das aplicações DomoBus .............................................................................. 42
5.2.1 Módulo PROP ...................................................................................................... 42
5.2.2 Módulo MSG ........................................................................................................ 45
5.3 Arquitectura das aplicações DomoBus implementadas .............................................. 48
6 Avaliação e testes ............................................................................................................... 51
6.1 Impacto da adição de um campo novo nas tramas .................................................... 51
6.2 Utilização de respostas só com o número de sequência ............................................ 53
6.3 Impacto da utilização de respostas super-prioritárias ................................................. 56
6.4 Melhorias introduzidas com o ajuste do tempo de acesso ao meio ........................... 58
6.5 Análise dos resultados ................................................................................................ 59
7 Conclusões ......................................................................................................................... 61
7.1 Trabalho futuro ............................................................................................................ 62
8 Referências ......................................................................................................................... 65
XI
Lista de tabelas
Tabela 1 - Campos das tramas do tipo Data Frames do sistema CAN Bus ............................... 11
Tabela 2 - Principais características de diferentes tecnologias com aplicabilidade domótica ... 13
Tabela 3 - Lista de operações para tratamento das propriedades ............................................. 20
Tabela 4 - Características da placa de desenvolvimento CS-EP930x relevantes para a função
de supervisão ..................................................................................................................... 26
Tabela 5 - Funções de manipulação de eventos e propriedades do módulo PROP .................. 44
Tabela 6 - Funções implementadas no módulo MSG ................................................................. 47
Tabela 7 - Tempo de trama e débito para tráfego reduzido e para os vários tipos de
propriedade ......................................................................................................................... 51
Tabela 8 - Tempo de trama e débito para tráfego elevado e para os vários tipos de propriedade
............................................................................................................................................ 52
Tabela 9 - Tempo de trama e débito para tráfego reduzido para as condições descritas na
secção 6.2 (tráfego reduzido) ............................................................................................. 54
Tabela 10 - Tempo de trama e débito para tráfego elevado para as condições descritas na
secção 6.2 (tráfego elevado) .............................................................................................. 55
Tabela 11 – Comparação do tempo de trama e débito para a situação descrita na secção 6.3
(tráfego reduzido) ............................................................................................................... 56
Tabela 12 - Tempo Comparação do tempo de trama e débito para a situação descrita na
secção 6.3 (tráfego elevado) .............................................................................................. 57
XII
Lista de figuras
Figura 1 - Protocolo de comunicação OSI 5
Figura 2 - Transmissão de bits no X10 ......................................................................................... 7
Figura 3 - Tempo de acesso ao meio para o envio de um pacote de dados [9] ........................... 8
Figura 4 - Tempo de acesso ao meio com a existência de pacotes prioritários [9] ...................... 8
Figura 5 – Trama do tipo Standard [23] ...................................................................................... 10
Figura 6 – Trama do tipo Extended [23] ...................................................................................... 10
Figura 7 - Método do CAN Bus para atribuição do barramento ao dispositivo de transmissão
[23] ...................................................................................................................................... 11
Figura 8 - Funções de um Sistema Operativo ............................................................................ 14
Figura 9 - Placa AT90USBkey .................................................................................................... 18
Figura 10 - Placa ATAVRAUTO100 ............................................................................................ 18
Figura 11 - Placa AVR Butterfly .................................................................................................. 18
Figura 12 - Placa AVRRAVEN .................................................................................................... 19
Figura 13 - Placa Arduino Uno .................................................................................................... 19
Figura 14 - Componentes e arquitectura do sistema DomoBus ................................................. 21
Figura 15 - Intervalos de tempo para acesso ao meio ................................................................ 23
Figura 16 – Formato da trama DomoBus .................................................................................... 23
Figura 17 - Módulo de Controlo................................................................................................... 25
Figura 18 - Placa de desenvolvimento CS-EP930X utilizada como Módulo de Supervisão ...... 26
Figura 19 - Comunicação Série Assíncrona ............................................................................... 30
Figura 20 - Controlo de congestionamento através do algoritmo AIMD ..................................... 32
Figura 21 - Integração das aplicações com os diferentes módulos ............................................ 33
Figura 22 – Estrutura de uma mensagem DomoBus normalizada ............................................. 34
Figura 23 - Aplicação Relay ........................................................................................................ 38
Figura 24 - Aplicação Switch ....................................................................................................... 38
Figura 25 - Esquema simplificado da máquina de estados da NET ........................................... 41
Figura 26 – Exemplo de array de eventos e respectiva ordenação por tipo (Byte (B), Word (W)
ou Array (A)), aplicação (A), número de propriedade (P) e dispositivo (D) ........................ 43
Figura 27 - Byte de controlo que permite indicar a validade do valor de uma propriedade e o
número de sequência para emparelhar mensagens .......................................................... 43
Figura 28 - Byte que indica o valor atribuído aos eventos .......................................................... 44
Figura 29 - Procedimento para obter da EEPROM o esqueleto da mensagem pretendida ....... 46
Figura 30 - Representação simplificada da máquina de estados do módulo MSG .................... 47
Figura 31 - Comparação do débito de tramas com e sem número de sequência no campo de
dados (tráfego reduzido)..................................................................................................... 52
Figura 32 - Comparação do débito de tramas com e sem número de sequência no campo de
dados (tráfego elevado) ...................................................................................................... 53
Figura 33 - Comparação do débito utilizando mensagens nas condições descritas na secção
6.2 (tráfego reduzido) ......................................................................................................... 54
XIII
Figura 34 - Comparação do débito utilizando mensagens nas condições descritas na secção
6.2 (tráfego elevado) ........................................................................................................... 55
Figura 35 - Comparação do débito para a situação descrita na secção 6.3 (tráfego reduzido) . 57
Figura 36 - Comparação do débito para a situação descrita na secção 6.3 (tráfego elevado) .. 58
XIV
Lista de abreviações
AIMD Additive-Increase, Multiplicative-Decrease
API Application Programming Interface.
BACnet Building Automation and Control Networks.
CAN Controller Area Network.
CPU Central Processing Unity
CRC Cyclic Redundancy Check.
CSMA/CD Carrier Sense Multiple Access with Collision Detection.
EEPROM Electrically-Erasable Programmable Read-Only Memory
EHS European Home Systems Protocol.
EIB European Installation Bus.
FIFO First In First Out
KNX Konnex Networks.
MMC MultiMediaCard
OSI Open Systems Interconnection.
RAM Random Access Memory
RISC Reduced Instruction Set Computing
SD Secure Digital
SDRAM Synchronous Dynamic Random Access Memory
SPI Serial Peripheral Interface Bus
UART Universal Asynchronous Receiver/Transmitter
UPnP Universal Plug and Play.
XML Extensible Markup Language.
1
1 Introdução
1.1 Enquadramento
A domótica congrega um conjunto de tecnologias que têm como principal objectivo a
automação de uma habitação e que permitem, para além da realização de algumas tarefas
rotineiras, proporcionar segurança, gerir o consumo de energia e de outros recursos, conforto e
integração de serviços aos utilizadores do sistema.
Existem pontos convergentes entre a domótica e a automação de edifícios – edifícios
inteligentes ou imótica – mas continua a ser possível distingui-los. Enquanto no primeiro caso o
objectivo principal é o de dotar o lar de um maior conforto e segurança, no caso dos edifícios a
área de actuação é distinta visto que os objectivos são diferentes. Os edifícios inteligentes
podem permitir, entre outras funcionalidades, gerir os elevadores, controlar o estacionamento e
os acessos, manter a climatização adequada e poupar energia. Obviamente que nas
habitações automatizadas também podem existir sistemas para controlar acessos e para
conseguir uma poupança energética mas, estes sistemas têm características e especificações
completamente diferentes das dos edifícios inteligentes.
A possibilidade de um sistema domótico ter a capacidade de tomar decisões e de se adaptar
ao meio em que está inserido e aos seus utilizadores permite poupar tempo, esforço e dinheiro.
Estes pressupostos aliados à introdução de um maior conforto e segurança motivam o
interesse da população em geral que vê também neste conjunto de tecnologias, uma mais-valia
para tornar mais independentes pessoas idosas ou portadoras de deficiências [1].
Apesar do interesse da população nos sistemas domóticos, estes continuam longe de estar
presentes na maioria dos lares. A ausência de um único meio de comunicação comum a todos
os dispositivos obriga à utilização da cablagem já existente ou à instalação de soluções
proprietárias que hipotecam a expansão do sistema, sendo uma explicação para a existência
deste cenário. Anteriormente, a cablagem que existia nas habitações limitava-se ao
fornecimento de energia eléctrica e ao serviço de telefone sendo que com o aparecimento de
produtos como sistemas de alarmes ou videovigilância, estes tiveram de ser instalados com
uma rede de fios própria levando à existência de uma habitação com um conjunto de fios sem
a capacidade de dialogar entre si. Esta situação piora com o facto de os fios de telefone, por
exemplo, não terem capacidade para comunicações de velocidade elevada nem flexibilidade
para configurações. Os fios utilizados para a instalação eléctrica precisam igualmente de um
isolamento conveniente para não causarem interferências ou ruído, potencialmente
problemáticos, quando utilizados para automação de habitações [3]. Neste momento, com o
advento de novos serviços de telecomunicações, que necessitam de uma rede específica e
muitas vezes com cabo coaxial, cada vez mais lares dispõem de um meio de comunicação
2
fiável e de elevado débito e que, apesar de não ser possível aproveitá-lo para fins de
alimentação eléctrica ou para comunicações internas, pode ser utilizado para as soluções
domóticas comunicarem com o exterior oferecendo possibilidades de gestão e supervisão do
sistema.
O meio de comunicação surge como aspecto diferenciador dos vários sistemas domóticos
existentes no mercado sendo que a especificidade das aplicações (com necessidades de
consumo e de largura de banda diferenciados) e das próprias habitações, assim como o facto
de muitas vezes se ter de recorrer a diferentes meios de comunicação para a implementação
do sistema, torna difícil o estabelecimento de uma norma e compromete ainda mais a
implementação em larga escala dos sistemas domóticos [2]. O preço é também influenciado
pelos aspectos citados e surge igualmente como um problema para a adesão a estas
tecnologias [1].
1.2 Objectivos
O cenário descrito na secção anterior serviu de ponto de partida para o desenvolvimento de um
sistema domótico denominado por DomoBus, no qual se baseia este trabalho, e que tem como
finalidade possibilitar a integração com outros sistemas, ter capacidade de expansão e muito
baixo custo. Esta dissertação pretende demonstrar que utilizando microcontroladores de muito
baixos recursos, interligados numa rede de sensores e actuadores, é possível criar um sistema
domótico com um elevado grau de funcionalidades, com um custo muito reduzido e com uma
elevada fiabilidade e robustez. Torna-se também possível a ligação a outras redes permitindo
uma monitorização e comando locais ou remotos e oferecendo suporte a mecanismos de
interoperação [19].
A disponibilização de dispositivos de muito baixo custo e que se interligam em rede abre
caminho à implementação de sistemas de grande dimensão (com um elevado número de
dispositivos) permitindo soluções de super-automatização dotadas de um conjunto sofisticado
de funcionalidades e oferecendo um suporte adequado à criação de ambientes inteligentes.
Dado o objectivo de se usarem microcontroladores com recursos bastante limitados,
principalmente em termos de memória, isso constitui um desafio para a criação de uma
plataforma de software que simplifique o desenvolvimento das aplicações e permita reduzir a
dimensão do seu código. Em consonância com este objectivo, pretende-se também
desenvolver um novo módulo de comunicação fiável que suporte retransmissões, e que
optimize a largura de banda disponível, minimizando as colisões e oferecendo mecanismos de
controlo de congestionamento. Pretende-se deste modo desenvolver mecanismos de
comunicação bastante fiáveis e eficientes, o que representa um desafio muito significativo
considerando a reduzida capacidade de memória dos microcontroladores usados – 512 bytes.
3
Os desenvolvimentos a realizar seguem o modelo DomoBus, pretendendo-se oferecer às
aplicações um conjunto de serviços que simplificam a leitura e a alteração das propriedades
associadas a cada dispositivo domótico. Dada a generalidade do modelo, pretende-se que
muitas operações possam ser realizadas de forma automática (por exemplo, a leitura de
propriedades ou a notificação de alterações) sem que a aplicação tenha de se preocupar com
esses detalhes.
A solução a desenvolver deverá também ser facilmente portável para outras plataformas e
microcontroladores, pelo que serão apenas usados recursos básicos disponíveis na
generalidade dos microcontroladores (um temporizador e uma UART) e evitando-se o recurso
a hardware específico como, por exemplo, controladores de comunicação.
1.3 Estrutura da dissertação
No segundo capítulo desta dissertação é feito o levantamento de protocolos com aplicabilidade
domótica, de sistemas operativos para sistemas embebidos e apresenta-se uma listagem de
microcontroladores e de placas de desenvolvimento em que estes se encontram inseridos. É
também feita uma introdução ao sistema DomoBus.
Dado que este trabalho se centra sobre o sistema DomoBus este será aprofundado no terceiro
capítulo, sendo descrita a sua arquitectura e os principais componentes que o constituem,
assim como o protocolo de comunicação usado.
No quarto capítulo é proposta a nova arquitectura de software para os Módulos de Controlo,
sendo abordado o sistema operativo, o módulo de comunicação e a plataforma de suporte às
aplicações DomoBus.
O quinto capítulo descreve os detalhes da implementação dos módulos de software.
A contribuição deste trabalho é validada no sexto capítulo onde são feitos testes e
apresentados resultados seguidos da respectiva análise.
As conclusões da dissertação e propostas para trabalhos futuros são apresentadas no sétimo
capítulo.
5
2 Trabalho relacionado
2.1 Protocolos no domínio da Domótica
2.1.1 Estrutura genérica de um protocolo de comunicação
Para haver comunicação, é sempre necessária a existência de uma fonte (emissor), de uma
mensagem e de um receptor. Um protocolo de comunicação descreve formalmente o formato
da mensagem a ser transmitida e as respectivas regras de transmissão relativamente à sintaxe,
semântica e sincronização da comunicação. Assim, em 1984 foi desenvolvido pela International
Organization for Standardization (ISO) uma norma de comunicações entre redes de
computadores distribuído por sete camadas, ou níveis, (física, lógica, rede, transporte, sessão,
apresentação e aplicação) para definir as diferentes fases pelas quais a informação passa de
um dispositivo para outro através de uma rede. Este modelo tem o nome de Open Systems
Interconnection (OSI).
Figura 1 - Protocolo de comunicação OSI
As três primeiras camadas consideram-se a base para definição das características da rede de
dados e aqui não existe qualquer interacção directa com os utilizadores finais. A primeira,
camada física, tem a função de conseguir transmitir correctamente um bit sobre o meio físico
de interligação e é necessário ter em conta as características de propagação do sinal para
definir este nível. O nível lógico utiliza os serviços da camada física para enviar pacotes de
dados entre duas máquinas ligadas à mesma rede física. Aqui, é muito importante controlar a
multiplexagem do meio de transmissão para ser possível enviar a trama e garantir que os
dados enviados são recebidos correctamente sem serem adulterados por falhas no meio físico.
O método de detecção mais utilizado (baseado em códigos polinomiais) é o Cyclic Redundancy
Code (CRC) já que a sua implementação em hardware é simples. No receptor são executadas
6
as operações inversas de modo a ser possível extrair a informação. A camada de rede, ao
contrário da camada lógica, considera a rede como uma entidade lógica que interliga máquinas
independentemente das redes físicas a que estão ligadas. A rede passa então a considerar-se
como resultante da interligação de várias redes físicas ou sub-redes. Este nível é também
responsável por suportar os mecanismos necessários ao encaminhamento dos pacotes de
dados entre quaisquer sistemas que a ele se encontram ligados, independentemente da rede
física. O nível de transporte oferece um serviço de transmissão de mensagens que permite a
comunicação entre utilizadores finais do sistema de comunicação. Para garantir uma
comunicação fiável, o nível de transporte tem de detectar a existência de faltas e assegurar a
sua recuperação. As faltas podem ter origem na corrupção dos dados, na perda de
mensagens, na sua duplicação ou na eventual recepção de mensagens dos níveis inferiores
numa ordem incorrecta. A recuperação de faltas efectua-se retransmitindo a mensagem. A
camada de sessão permite multiplexar várias instâncias de comunicação sobre a mesma
ligação de transporte. Em muitas arquitecturas este nível não existe ou então está parcialmente
englobado noutra camada. O nível de apresentação permite compatibilizar a informação entre
sistemas diferentes pois a representação de dados relativa a cada sistema, depende da
arquitectura dos processadores, unidades aritméticas e também das linguagens e
compiladores utilizados. Por fim, o nível de aplicação engloba as funcionalidades relativas às
aplicações propriamente ditas [1].
Existem diversos protocolos de comunicação com potencial para serem utilizados numa
aplicação domótica. Para além daqueles que são específicos para a automação habitacional,
existem outros que devido à sua versatilidade podem ser igualmente utilizados. Apresenta-se
de seguida a descrição de alguns protocolos com aplicabilidade domótica.
Os protocolos mais comuns usados em domótica apenas possuem as camadas física, lógica e
de rede passando de imediato para a camada de aplicação.
2.1.2 Protocolos de comunicação vocacionados para domótica
Konnex Networks (KNX) – é uma norma (EN 50090, ISO/EIC 14543) e resulta da
convergência de três protocolos anteriores: European Instalation Bus (EIB), European Home
System Protocol (EHS) e Batibus. Herdou do EIB a pilha de protocolos de comunicação tendo
esta sido complementada com a camada física dos outros dois sistemas. Devido ao facto de
contemplar vários meios de comunicação (rede eléctrica, par entrelaçado, rádio frequência,
infravermelhos e Ethernet) e de existir a possibilidade de incluir gateways para outros meios,
torna-se um sistema flexível. Tal como esperado, a taxa de transferência deste sistema varia
consoante o meio de comunicação utilizado: na rede eléctrica situa-se nos 1200 bps e esta
taxa aumenta quando se utiliza rádio frequência e par entrelaçado atingindo nestes casos os
valores de 16 kbps e 9600 bps, respectivamente [5]. Este sistema é bastante fiável mas tem a
desvantagem de a sua implementação ter, normalmente, um custo elevado [1].
7
X10 – este protocolo utiliza a instalação eléctrica existente numa habitação para comunicar
entre dispositivos permitindo a sua utilização em casas já existentes, sem necessidade de
utilizar cabos adicionais. Este aspecto torna-o um dos sistemas de maior aceitação e
acessibilidade económica [1][2]. Cada dispositivo possui uma identificação e reage apenas aos
comandos que lhe são endereçados. O bit “1” corresponde a uma rajada de 120 kHz e o bit “0”
corresponde à ausência desta. No primeiro caso, cada rajada (com duração de 1 ms) é enviada
com um desfasamento máximo de 200 µs. De modo a melhorar a relação sinal/ruído e para
diminuir a probabilidade de o ruído eléctrico poder ser confundido com um sinal válido, optou-
se por enviar sempre o bit seguido do seu complemento. Assim, o bit “1” é representado por
uma rajada (120 kHz) seguida de um 0 (ausência de sinal) e o bit “0” por silêncio (ausência de
sinal) seguido de uma rajada (120 kHz). Desta maneira conseguem-se transmitir 50 bps numa
rede eléctrica de 50 Hz. Uma transmissão padrão deste protocolo inclui os quatro seguintes
campos [2]:
• Código de início: todos os comandos devem ser iniciados com o código “1110” de
modo a ser sinalizado o início de uma trama. Ao contrário de todos os outros campos,
esta sequência não é acompanhada do envio dos seus bits complementares;
• Código de casa: identifica a casa. São utilizados 4 bits (mais os seus valores
complementares). No total existem 16 combinações possíveis;
• Código de dispositivo ou função: 4 bits (mais respectivos bits complementares). São
portanto possíveis 16 combinações diferentes;
• Dispositivo/Função: indica se o código anterior corresponde a um dispositivo ou a uma
função. É utilizado um bit seguido do seu valor complementar.
Figura 2 - Transmissão de bits no X10
São necessários 11 períodos do sinal da rede eléctrica para transmitir uma mensagem
completa. O envio do código de início demora 2 ciclos, o código da casa necessita de 4 ciclos e
o código de Dispositivo/Função demora 4 ciclos a ser transmitido. Entre comandos, deve existir
uma pausa de 3 ciclos e este facto leva a que exista uma latência que se torna perceptível e
faz com que este protocolo seja ineficiente para interacção com utilizadores [24].
LonWorks – criado pela Echelon Corporation, este protocolo é especialmente dirigido ao
desempenho e fiabilidade das aplicações de controlo. Suporta vários meios físicos de
comunicação tais como: par entrançado, fibra óptica e rádio frequência. Esta tecnologia
8
implementa as sete camadas do modelo de redes de comunicação Open Systems
Interconnection (OSI) e tem diversas características tais como: detecção de mensagens
duplicadas, prevenção de colisões, retransmissão automática e detecção e correcção de erros.
Para além destas características, o LonWorks tem um modo de acesso ao meio denominado
por Predictive p-Persistent CSMA. À semelhança de qualquer protocolo Carrier Sense Multiple
Access (CSMA), os dispositivos LonWorks acedem ao meio após um período de tempo com
uma componente fixa e outra aleatória. Deste modo evita-se, ou pelo menos minimiza-se, a
colisão de dados. Mais concretamente, este sistema divide a componente aleatória em partes
iguais de tempo e portanto quando um dispositivo tiver uma mensagem para enviar, fá-lo-á
num determinado intervalo com uma probabilidade p que será ajustada de acordo com o nível
de tráfego da rede, Figura 3.
Figura 3 - Tempo de acesso ao meio para o envio de um pacote de dados [9]
Numa situação de rede inactiva, o tempo de espera aleatório é dividido em 16 partes e portanto
os dispositivos aguardam em média 8 fatias de tempo. À medida que o tráfego na rede for
aumentando, o número de divisões de tempo será multiplicado por uma constante com um
valor entre 0 e 63. Assim, o máximo tempo de espera para um dispositivo aceder ao meio é o
equivalente a 1008 (63 * 16) fatias de tempo. A percepção do estado da rede está relacionada
com o número de confirmações recebidas pelos dispositivos após o envio de uma mensagem.
É também disponibilizado um mecanismo para melhorar a transmissão de pacotes críticos
privilegiando o acesso ao meio a dispositivos prioritários, Figura 4, já que estes serão
transmitidos em primeiro lugar.
Figura 4 - Tempo de acesso ao meio com a existência de pacotes prioritários [9]
O sistema LonWorks apresenta débitos os seguintes débitos: 78.13 kbps para cabo
entrançado, 5.4 kbps para redes eléctricas de 60 Hz e 3.6 kbps para redes eléctricas de 50 Hz.
9
Tem, contudo, a grande desvantagem de ser necessário utilizar um processador específico, o
Neuron [9].
2.1.3 Suporte à interoperação
Building Automation and Control Networks (BACnet) – desenvolvido para permitir
comunicação entre sistemas de aplicação Domótica, este protocolo (ISO 16484-5) começou a
ser desenvolvido em 1987. BACnet define um número de serviços que são utilizados para
comunicar entre dispositivos (“Who-Is”, “I-Am”, “Who-Has”, “I-Have”). Este protocolo pode
comunicar, por exemplo, por Ethernet ou RS-232 e ser incluído em redes com outros sistemas
tais como o LonWorks ou KNX [6].
Universal Plug and Play (UPnP) – este conjunto de protocolos (ISO/IEC 29341) utiliza as
portas TCP 5000 e UDP 1900 e tem como objectivo permitir que os dispositivos se liguem de
uma forma transparente e simplificada permitindo uma maior facilidade para dotar uma
habitação de partilhar de ficheiros, comunicações e entretenimento. A razão para o nome desta
tecnologia tem a ver com o facto de após a ligação de um dispositivo, este poder
dinamicamente obter um endereço, ter acesso aos serviços disponíveis e comunicar com
outros dispositivos. Os dispositivos UPnP têm, para além destas, outras características:
• Dispositivos independentes do meio: um dispositivo pode ser utilizado em diversos
meios (com ou sem fios) com suporte IP;
• Possibilidade de utilização de um qualquer Sistema Operativo e linguagem de
Programação – UPnP não restringe o desenvolvimento de Application Programming
Interface (API);
• Escalabilidade: cada dispositivo pode ter serviços específicos definidos pelos
fabricantes;
• A interface disponibilizada ao utilizador pode ser acedida através de um navegador
Web.
A descrição UPnP para cada dispositivo é escrita em Extensible Markup Language (XML) e
inclui informações como nome do fabricante, nome e número de série. Inclui também uma lista
de serviços embebidos assim como de comandos aos quais o dispositivo responde [10].
2.1.4 Outros protocolos de comunicação
Controller Area Network (CAN) BUS – originalmente desenvolvido nos anos 80 para que os
diversos dispositivos electrónicos que constituem um automóvel pudessem comunicar entre si
e efectuar toda a gestão do funcionamento do veículo. A parte mais divulgada do protocolo
CAN BUS reside na camada lógica do modelo de redes de comunicação OSI e tem
actualmente outras áreas de aplicação que não apenas no contexto dos veículos como, por
exemplo, automação industrial, equipamento médico e Domótica.
10
A norma define a existência de quatro tipos de tramas:
• Data Frame: utilizada para enviar informação genérica de um dispositivo para outro;
• Remote Frame: este tipo de trama é utilizado pelo dispositivo receptor para pedir ao
dispositivo emissor a transmissão de uma mensagem;
• Error Frame: geradas e transmitidas pelo hardware e utilizada para indicar a
ocorrência de um erro durante a transmissão;
• Overload Frame: utilizada pelo dispositivo receptor para indicar que ainda não está
preparado para receber tramas.
As Data Frames são as mais comuns e as mais importantes para o utilizador interagir com o
sistema e podem ser do tipo standard frame ou extended frame, que diferem no número de bits
que compõe o campo que identifica o dispositivo, 11 bit ou 29 (11+18) bit, respectivamente
(Figura 5 e Figura 6).
Figura 5 – Trama do tipo Standard [22]
Figura 6 – Trama do tipo Extended [22]
A descrição dos campos que compõem a trama encontra-se na Tabela 1.
11
Tabela 1 - Campos das tramas do tipo Data Frames do sistema CAN Bus
Campo Descrição Dimensão
Start of
Frame
Indica o início da trama e está
presente nas Standard Frame e
Extended Frame
1 bit
Arbitration Indica a prioridade da trama de
modo a resolver conflitos quando
vários dispositivos iniciam o envio
de mensagens para o meio
11 bit para Standard Frame e
29 bit para Extended Frame
Control Indica o número de bytes do campo
Data na mensagem a ser enviada
6 bit (2 bit são reservados)
Data Contém a mensagem a ser
transmitida
Pode variar entre 0 e 64 bit
CRC Utilizado para verificar a
integridade da mensagem
transmitida
16 bit
ACK Indica que a mensagem foi
correctamente recebida
2 bit
Cada nó pode enviar ou receber mensagens (não simultaneamente) e é disponibilizado um
sistema para arbitrar as prioridades: se o barramento estiver livre, qualquer nó pode transmitir
mas, se dois ou mais dispositivos tentarem iniciar o envio da mensagem ao mesmo tempo, a
mensagem com o identificador dominante (com mais bits dominantes – zeros) terá acesso ao
barramento caso contrário, entrará no modo de recepção. Na Figura 7, o bit 8 do nó 2 tem um
valor recessivo - 1- enquanto os restantes têm um valor dominante. Este nó entra portanto no
modo de recepção (representado a cinzento na figura). O décimo bit do nó 1 está no estado
recessivo enquanto o do nó 3 está no estado dominante. Assim, o nó 3 ganha acesso ao
barramento e pode transmitir os dados livremente e o nó 1 altera o seu estado para recepção.
Figura 7 - Método do CAN Bus para atribuição do barramento ao dispositivo de transmissão [22]
12
Cada nó necessita de um processador, onde os sensores e actuadores estão ligados e onde a
mensagem recebida vai ser interpretada e a mensagem a enviar vai ser escolhida, um
controlador CAN, que no caso de recepção guarda os bits e no caso de envio envia para o
barramento de forma série e um transceiver (integrado ou não no controlador) que faz a
adaptação entre os níveis do sinal de barramento e o do controlador CAN. Para distâncias
inferiores a 40 m o débito máximo é de 1 Mbps [11] baixando para 40 kbps para uma distância
de 1000 m (máxima). O CAN tem a grande desvantagem de, tal como referido, ter de recorrer a
um controlador próprio o que eleva os custos de aquisição do hardware [22]. É relativamente
fácil encontrar microcontroladores que incluem um controlador de comunicações CAN mas
estes possuem um custo mais elevado face a microcontroladores equivalentes sem CAN.
PROFIBUS – protocolo pertencente à família FieldBus - rede de computadores para controlo
distribuído em tempo real e utilizada predominantemente em aplicações industriais – seguindo
a norma EN 50170 e contando com três variantes principais:
• PROFIBUS-DP (Descentrallised Periphery): solução de alta velocidade, voltada
essencialmente para sistemas de controlo com tempo crítico e recorrendo ao meio
físico RS-485 ou fibra óptica. Esta variante é indicada para o chão de uma fábrica,
onde existe um grande volume de informações;
• PROFIBUS-FMS (Fieldbus Message Specification): evolução da variante anterior e
utilizada para redes de controladores programáveis - PLCs - e PCs;
• PROFIBUS-PA (Process Automation): versão mais recente do PROFIBUS e tem como
principal característica a possibilidade de transferir dados através da cablagem de
alimentação.
Recorrendo ao meio físico RS-485, a comunicação pode ser efectuada com um débito entre
9.6 kbps (até 1200 m) a 12 Mbps (até 100 m) e permite 32 dispositivos por segmento, até ao
total de 127 dispositivos [12].
2.1.5 Comparação de tecnologias com aplicabilidade domótica
A Tabela 2 contém os principais aspectos que normalmente são tidos em conta na altura de
optar por uma solução domótica. O CAN Bus não sendo específico para domótica, pode ser
utilizado. Já em relação ao PROFIBUS, dada a sua natureza industrial e o reduzido número de
dispositivos que suporta, não se conhece nenhuma utilização na automatização de habitações.
13
Tabela 2 - Principais características de diferentes tecnologias com aplicabilidade domótica
Número máximo
de dispositivos
Duração típica
de uma trama
(ms)
Ritmo de
Transmissão Custo
KNX 65536 20 a 40
Par entrançado:
9.6 kbps;
Linha eléctrica:
1.2 kbps;
Rádio
frequência: 16
kbps
Elevado
LonWorks 248 4
Par entrançado:
78 kbps;
Linha eléctrica:
5.4 kbps a 60 Hz
e 3.6 kbps a 50
Hz
Elevado
X10 256 940 50 bps Baixo/médio
CAN 2048 0.118 a 1 Mbps
e 12.3 a 9.6 kbps
1 Mbps até 40 m
40 kbps até 1000
m Médio
PROFIBUS 127
0.163 a 12 Mbps
e 203 a 9.6 kbps
(tramas até 244
bytes)
12 Mbps até 100
m
9.6 kbps até 1200
m
Elevado
2.2 Sistemas Operativos e ambientes de desenvolvimento
Um sistema operativo é uma plataforma de software que gere as diferentes aplicações e
implementa a interface entre estas e todos os componentes de hardware. Dado que a cada
momento várias tarefas e/ou periféricos necessitam dos recursos do sistema a fim de os seus
pedidos serem processados, cabe ao sistema escalonar, atribuir, intercomunicar e gerir as
tarefas, a memória, o processador e os restantes recursos. A gestão do sistema de ficheiros e
das interfaces de comunicação, a abstracção do hardware para que o programador não tenha
de conhecer todos os seus detalhes no momento de desenvolvimento das aplicações e o
fornecimento de uma interface de aplicação (API) aos programadores, são outras das funções
genéricas do sistema operativo [7].
14
Figura 8 - Funções de um Sistema Operativo
No caso dos sistemas embebidos, os sistemas operativos de tempo real são bastante
utilizados pois existem grandes restrições de latência ao nível das tarefas que vão ser
executadas. Se o sistema tiver tarefas concorrentes ou seja, que disputam a ocupação dos
recursos do sistema, é necessário que exista um escalonamento das tarefas de modo a que
estas possam ser executadas no tempo necessário e que a utilização dos recursos disponíveis
seja o mais eficiente possível. O escalonamento pode ser realizado de um modo preemptivo ou
não preemptivo [7]:
• Preemptivo – o escalonador, através de um algoritmo, determina qual o processo a ter
acesso aos recursos do sistema e é executado durante um intervalo máximo de tempo
estabelecido. Findo este tempo, se o processo ainda não tiver terminado a sua
execução, é suspenso e o escalonador atribui o acesso aos recursos a outro processo
(se existir). Dado que este método requer marcação de tempos e uma rotina associada
à interrupção do clock do processador para que no fim do tempo estabelecido o
escalonador volte a ser executado e haja salvaguarda do contexto, nem sempre é
trivial, ou mesmo possível, implementar este método principalmente em processadores
de baixos recursos. Nessa situação, o modo não preemptivo é a alternativa.
• Não preemptivo – é determinado o processo ao qual vão ser entregues os recursos do
sistema e este é executado até bloquear (seja por aguardar uma acção de I/O ou
esperar por outro processo) ou libertar voluntariamente o CPU. Ao recorrer a este
modo, o programador tem de ter noção do tempo de execução das diversas tarefas de
modo a que estas sejam executadas através de uma ordem e intervalo de ocupação
dos recursos correctos. Uma grande desvantagem deste modo é que se houver
alguma anomalia e um processo bloquear, este vai causa o bloqueio integral do
processador já que o escalonamento é realizado ao nível do processo e não do
sistema operativo.
Como um sistema embebido de pequena dimensão à partida não necessita de todas as
funcionalidades de um sistema operativo típico, o custo do dispositivo é inferior visto utilizar
15
menos recursos. É importante recorrer a uma solução feita à medida para que todas as
necessidades sejam correspondidas.
Relativamente aos sistemas embebidos, têm surgido recentemente microkernels como opção
viável. A ideia surgiu na década de 70 e baseia-se em colocar todos os serviços do sistema
operativo fora do kernel (código que corre em modo privilegiado do processador) correndo em
modo de utilizador. Esta medida tem como objectivo aumentar a fiabilidade e robustez que são
premissas dos sistemas embebidos [8].
De entre os diversos sistemas operativos (de utilização livre) existentes para sistemas
embebidos, destacam-se os seguintes:
• TinyOS – este sistema operativo foi desenvolvido para aplicações em redes de
sensores sem fios e é vocacionado para microprocessadores de baixos recursos. O
TinyOS utiliza um escalonador First In First Out (FIFO) não preemptivo de dois níveis
(alta prioridade para eventos e baixa prioridade para tarefas) embora exista a
possibilidade de aplicações criadas pelos utilizadores, substituírem o escalonador de
tarefas de modo a experimentarem novos métodos de escalonamento. A linguagem de
programação utilizada para este sistema é nesC e é baseada em C. Para além da
comunicação sem fios, este sistema operativo suporta também uma aplicação de nome
TinyDB que fornece uma plataforma para comunicação com a rede de sensores tendo
a enorme vantagem de o programador não necessitar de escrever o código referente
[13].
• eCOS – desenvolvido tendo em vista sistemas com necessidades de execução em
tempo real e reduzida memória RAM, este sistema é implementado em C/C++ e possui
dois modos de escalonamento preemptivo. Tem igualmente uma camada de
abstracção de hardware, modos de gestão de memória, pilha protocolar TCP/IP e
suporte para controladores PCMCIA, PCI e USB: Este sistema operativo permite ao
utilizador escolher as funcionalidades que realmente necessita reduzindo assim o
código a executar e fazendo com que o sistema tenha uma aplicabilidade muito
próxima da pretendida. O eCOS pode ser utilizado numa grande variedade de
plataformas de 16, 32 e 64 bits [14].
• Contiki – igualmente vocacionado para redes de sensores sem fios e
microprocessadores de capacidade de memória reduzida, o Contiki é altamente
portável, tem suporte multitarefa e escalonamento preemptivo. Suporta o protocolo
TCP/IP, um sistema gráfico para monitorização (com suporte internet) e necessita
apenas de 2 kbytes de memória de dados e 40 kbytes de memória de programa numa
utilização típica. Os programas são escritos em linguagem C [15].
16
• FreeRTOS – este sistema operativo foi desenvolvido de modo a ser simples e ocupar
pouca memória. Tem suporte para 27 arquitecturas de processadores e inclui um modo
de escalonamento preemptivo e a possibilidade de criar processos e semáforos para
melhorar a comunicação entre tarefas. A linguagem de programação deste sistema
operativo é C e são necessários pelo menos 4 kbytes de memória de programa para
permitir o seu funcionamento [16]. Uma explicação da quantiade de memória
necessária para utilizar o FreeRTOS pode ser encontrada em [17].
Considerando a capacidade de memória referente ao microcontrolador utilizado neste trabalho,
AT90S8515 [18], nenhum dos sistemas operativos referidos se mostra adequado.
2.3 Microcontroladores
Microcontroladores são microprocessadores orientados para o controlo (operações com bits,
interacção entre sensores e actuadores, comunicação entre dispositivos e utilizadores) e estão
presentes na grande maioria dos equipamentos electrónicos utilizados diariamente
(principalmente em sistemas embebidos). Um microcontrolador é um computador e como tal
tem um processador (normalmente até 32 bits), memória de programa (Flash) e de dados
(RAM) e dispositivos de entrada e saída de informação sendo por isso autónomo. Ao contrário
dos computadores de utilização doméstica e/ou de trabalho que estão preparados para
executar uma grande variedade de aplicações, os microcontroladores têm uma utilização muito
específica e incluem algumas ou a totalidade das seguintes características:
• Inclusão de diversos periféricos: temporizadores, conversores analógicos/digitais,
watchdog, geradores de relógio e dispositivos de comunicação série;
• Inclusão de memória de dados e de programa no mesmo circuito integrado;
• Possibilidade de o programador ter acesso directo aos pinos do circuito;
• Existência de instruções especializadas para operações comuns em sistemas
embebidos tais como manipulação de bits. Isto permite melhorar o desempenho do
sistema.
O facto de os periféricos e a memória estarem localizados no mesmo circuito integrado, permite
reduzir o número de componentes diminuindo a área, o consumo e o preço da implementação.
O acesso aos pinos do microcontrolador permite aos programas monitorizarem de uma forma
mais simples e directa os diversos sensores, controlar os actuadores e transferir dados entre
outros dispositivos.
Um microcontrolador deve ser escolhido de acordo com a funcionalidade pretendida e devem
ser tidos em conta aspectos como o custo, consumo de energia e software necessário ao
desenvolvimento das aplicações. No caso específico da domótica, e dado o elevado número de
dispositivos que vão necessitar de microcontroladores, o custo deve ser reduzido. A qualidade
do ambiente de desenvolvimento e as ferramentas disponíveis são também deveras
17
importantes para permitir a actualização e expansão do sistema e como tal, o seu custo de
aquisição deve também ser tido em conta.
Para aplicação em sistemas embebidos, podem ser consideradas várias arquitecturas
baseadas em Reduced Instruction Set Computing (RISC) ou seja, as instruções demoram
aproximadamente o mesmo tempo a serem executadas pois são executadas directamente pelo
hardware de modo a melhorar o desempenho. As arquitecturas Advanced RISC Machine
(ARM), Microprocessor without Interlocked Pipeline Stages (MIPS) e Atmel AVR são as mais
utilizadas sendo que algumas famílias destes processadores recorrem a uma arquitectura de
Harvard separando a memória do programa e de dados. Isto permite programar o
microcontrolador apenas uma vez na memória não volátil (Flash) ficando este com o código
armazenado durante o seu tempo de vida útil.
Para aplicações domóticas, largamente baseadas em sensores e actuadores, a velocidade não
é à partida o requisito mais importante. Deste modo, qualquer um dos microcontroladores de 8
ou 16 bits das arquitecturas acima citadas tem um desempenho adequado à aplicação. No
caso de um controlador global ou de um supervisor que controla vários nós de um sistema
domótico, e já que são necessários mais recursos, pode-se optar por um microcontrolador com
mais meios ou então por um PC.
Optou-se, no presente trabalho, por dar continuidade ao hardware já existente e utilizado
noutros projectos e como tal, o código foi desenvolvido para o microcontrolador AT90S8515 de
8 bits da Atmel. Este fabricante disponibiliza, de forma gratuita, ferramentas de
desenvolvimento de elevada qualidade (compilador GNU para C/C++, GDB para depuração de
erros e o ambiente AVRSTUDIO que permite simular o microcontrolador). A Atmel tem uma
elevada aceitação porque para além da qualidade dos recursos disponibilizados que permitem
a utilização de programação em linguagem C, tem uma grande variedade de hardware e é
possível encontrar os seus microcontroladores em diversas placas de demonstração de baixo
custo que incluem tudo o que é necessário para começar a executar o protótipo visto que estas
para além do microcontrolador já incluem as memórias, acesso aos portos do microcontrolador,
botões, controladores para comunicação com um PC e, em alguns casos, sensores de diversos
tipos e LEDs.
Apresentam-se em seguida alguns microcontroladores de 8 bits da família AVR (Atmel) assim
como placas de desenvolvimento onde é possível encontrá-los:
• AT90USB1287 – este microcontrolador possui 128 KB de memória Flash, um
conversor analógico/digital de 10 bit e interface JTAG e USB. A placa de demonstração
AT90USBKey inclui este microcontrolador e possui também um joystick, botões, LEDs
e um sensor de temperatura. Dado o baixo custo face aos recursos disponibilizados e a
18
versatilidade do equipamento, esta placa é largamente utilizada no desenvolvimento de
protótipos.
Figura 9 - Placa AT90USBkey
• ATCAN128 – com este microcontrolador, a implementação de uma rede CAN é
facilitada já que possui o controlador. A placa ATAVRAUTO100 inclui este
microcontrolador com 128 kBytes de memória Flash e tem particular interesse para ser
utilizado numa aplicação automóvel.
Figura 10 - Placa ATAVRAUTO100
• ATmega169PV – possui 16 Bytes de memória Flash, um conversor analógico/digital de
10 bits e 8 canais e está disponível na placa AVR Butterfly. Esta contém um ecrã LCD
e permite expandir a memória Flash para 512 kBytes. Tem também um joystick e
sensores de luz, temperatura e tensão e uma interface série RS-232 sendo por isso
bastante versátil.
Figura 11 - Placa AVR Butterfly
• ATmega3290P – este microcontrolador tem 32 kBytes de memória Flash e um
conversor analógico/digital de 10 bits. Possui também interface JTAG. Pode ser
encontrado em conjunto com o microcontrolador ATmega1284P na placa AVRRAVEN.
O primeiro controla os sensores e permite a interface com o utilizador. O segundo é o
responsável pela comunicação sem fios, possuindo a placa um transceiver ZigBee.
19
Figura 12 - Placa AVRRAVEN
• ATmega328 – este microcontrolador possui 14 pinos de entrada/saída e tem um
funcionamento a 16 MHz e 32 kB de memória. As placas Arduino Uno bastante
conhecidas pela sua versatilidade e baixo custo, utilizam este microcontrolador.
Figura 13 - Placa Arduino Uno
2.4 Sistema DomoBus
O DomoBus é um projecto académico, no qual se baseia este trabalho, e pretende ser uma
solução domótica de muito baixo custo mas com capacidade de expansão e possibilidade de
integração com outros sistemas [19]. Ao ser utilizado um microcontrolador de baixo custo, é
possível implementar sistemas em rede com um elevado número de dispositivos – super-
automatização – abrindo caminho para o adequado suporte à criação de ambientes
inteligentes.
Nesta solução domótica os dispositivos são entidades abstractas descritas através de um
conjunto de propriedades (do tipo byte, word ou array), sendo o valor destas lido ou alterado
através de operações normalizadas GET, SET, NOTIFY e FORWARD – Tabela 3 – e cujas
mensagens são geradas a partir de eventos. Esta abordagem permite uma utilização bastante
eficiente da memória visto que ao contrário de outros sistemas que possuem filas para dar
suporte às várias mensagens a tratar, é utilizada a EEPROM do microcontrolador para
armazenar o esqueleto das mensagens que, em caso de necessidade, serão posteriormente
geradas de novo. É igualmente possível definir as características de um sistema DomoBus
através de um ficheiro em XML [23] e cuja especificação está dividida em duas partes: uma
define os tipos abstractos e as suas propriedades e outra define o sistema em concreto
explicitando a estrutura física da habitação, serviços existentes e dispositivos reais instalados.
20
Tabela 3 - Lista de operações para tratamento das propriedades
Operação Função
GET Ler o valor de uma propriedade
SET Alterar o valor de uma propriedade
NOTIFY Notificar a alteração do valor de uma
propriedade (as notificações são enviadas
normalmente para uma aplicação de
supervisão)
FORWARD Reencaminhar mensagens para outros
dispositivos
O sistema DomoBus está dividido em dois níveis: de controlo e de supervisão. No primeiro
caso, os Módulos de Controlo interagem com o meio através dos sensores e actuadores que a
ele se ligam. O nível de supervisão possibilita a gestão e supervisão do sistema através dos
Módulos de Supervisão e podem ter a seu cargo diversos Módulos de Controlo, recebendo e
processando informações provenientes destes. As aplicações DomoBus trocam mensagens
entre si – de uma forma local ou remota – a um débito de 19200 bps, com suporte de
retransmissões e mecanismos para controlar tráfego, o que acrescenta fiabilidade e robustez a
esta solução domótica de baixo custo. O presente trabalho centrou-se no sistema DomoBus e
como tal, este será detalhado no próximo capítulo.
21
3 Sistema DomoBus
3.1 Componentes do sistema
O sistema domótico DomoBus é constituído por Módulos de Controlo (CM), Módulos de
Supervisão (SM) e de interligação: bridge (B) ou gateway (A). Estes componentes permitem
formar uma arquitectura flexível e de fácil expansão e podem ser visualizados na Figura 14 que
representa a arquitectura do sistema DomoBus.
SM SM
A
CM
Interacção com o meio físico (sensores e actuadores)
BB
CMCMCMCMCM
Ethernet
DomoBus DomoBus
DomoBus
RS-232
Utilizador
Interação
Remota
...
Figura 14 - Componentes e arquitectura do sistema DomoBus
A possibilidade de ligação a um PC permite o comando, supervisão e interacção com outras
tecnologias incluindo Internet.
Os Módulos de Controlo, programados em linguagem C, são aqueles que efectivamente
interagem com o meio físico em que se encontram e são responsáveis pela leitura de sensores
e pelo comando de actuadores. Para efeitos de comunicação utilizam um transceiver EIA-485 e
podem comunicar directamente com outros módulos ligados ao mesmo barramento ou, por
intermédio dos bridges, com o resto do sistema. Cada módulo pode ter diferentes aplicações
(até um máximo de oito) e como tal, realizar funções distintas. Esta característica distingue o
DomoBus de outras tecnologias nomeadamente o X10, KNX e LonWorks, já que nestas um
Módulo de Controlo está tipicamente associado a apenas um dispositivo, e permite reduzir o
custo de um sistema domótico Estes módulos devem ser o mais autónomos possível para
tornar o sistema mais robusto e diminuir o tráfego na rede. Pode-se dar o exemplo de um
módulo de controlo de iluminação: este deve estar também associado aos interruptores pois
em caso de avaria do sistema, os módulos de controlo continuam a executar as suas funções.
22
Os módulos de supervisão têm a seu cargo a gestão e supervisão do sistema. Ao receberem
dados dos módulos de controlo, processam-nos de acordo com o comportamento esperado e
devolvem o comando apropriado. Num sistema de pequenas dimensões pode utilizar-se
apenas um módulo enquanto em sistemas mais complexos pode-se dotar cada segmento com
um Módulo de Supervisão tal como ilustrado na Figura 14. Deste modo, os eventos gerados
por um módulo de controlo ligado a um determinado segmento da rede podem ser recebidos e
processados directamente pelo módulo de supervisão associado permitindo uma supervisão
distribuída e aumentando a fiabilidade da rede.
Um Módulo de Supervisão pode também contactar qualquer Módulo de Controlo e de
supervisão presente no sistema e é possível que estes recorram a uma rede diferente com
maior largura de banda (por exemplo Ethernet) e com suporte de outras tecnologias e serviços
para permitir a interoperabilidade com outras soluções. Em termos de interface com o
utilizador, esta é sem dúvida beneficiada com a existência de um PC pois este tem a
capacidade de mostrar uma interface gráfica para monitorização e programação mas, como as
acções de supervisão e gestão de controlo estão presentes nos Módulos de Supervisão, este
pode ser eliminado sem prejuízo da fiabilidade do sistema [19].
Os módulos de interligação têm uma função extremamente importante no sistema: os módulos
bridge interligam os diferentes segmentos e têm de ter capacidade de reconhecer e
encaminhar as mensagens. O módulo gateway permite que todos os módulos possam
comunicar com este dispositivo e enviar e receber mensagens via PC.
3.2 Rede do sistema DomoBus e acesso ao meio
Existe uma interligação entre todos os dispositivos do sistema DomoBus através dos
barramentos. Entre estes, a ligação é assegurada por intermédio dos módulos bridge e de
supervisão.
O barramento ao qual estão ligados os módulos de controlo recorre no nível físico à norma
EIA-485 em modo half-duplex e no caso dos módulos de supervisão, estes estão ligados por
Ethernet já que é necessária uma taxa de transferência mais elevada e também porque permite
a introdução de outras funcionalidades para o sistema para além do controlo e automação. A
estrutura da rede permite independência, robustez e expansão do sistema.
Para se aceder ao meio, e já que este é partilhado com outros dispositivos, recorre-se ao
método CSMA/CD. Assim, o meio de comunicação é permanentemente observado para
detectar o período de silêncio exigido para o início da transmissão. Este período, tal como é
visível na Figura 15, é constituído por uma parcela fixa e outra aleatória.
23
Figura 15 - Intervalos de tempo para acesso ao meio
A primeira está associada aos atrasos da linha de transmissão que dependem da distância e
da velocidade de propagação no meio físico e o segundo evita colisões geradas por
comunicações simultâneas (isto ocorre porque o meio é partilhado por vários dispositivos).
Quando ocorre uma colisão, detectada quando o bit enviado não é igual ao recebido, os
dispositivos envolvidos param a transmissão e aguardar novamente pelo período de silêncio.
Tal como é visível na Figura 16, as tramas DomoBus são constituídas por 5 Bytes (40 bits) de
cabeçalho, 0 a 121 Bytes de dados e um Byte de CRC para verificação da integridade da
mesma.
Figura 16 – Formato da trama DomoBus
Os Bytes que constituem o cabeçalho da trama DomoBus são os seguintes:
1º Byte: o primeiro bit indica o tipo da trama e os restantes 7 bits indicam a sua dimensão;
2º Byte: os quatro primeiros bits indicam o segmento de destino e os restantes o segmento de
origem da trama;
3º Byte: cinco bits indicam o nó a que se destina a trama e os restantes três bits indicam a
aplicação a que se destina;
4º Byte: os cinco primeiros bits indicam o nó de origem da trama e os restantes bits a aplicação
que os originou;
5º Byte: o primeiro bit não é utilizado, os três bits seguintes são utilizados para controlo da
trama e os restantes quatro bits referem o código da operação a ser realizada. As opções de
controlo da trama, são as seguintes:
bit p refere a prioridade da trama (0 – baixa, 1 – alta);
bit r indica se a trama é uma retransmissão (0 – não, 1 – sim);
bit a indica se a trama é uma resposta (0 – não, 1 – sim).
24
A indicação de que se está a usar uma trama DomoBus é dada pelo bit mais significativo do
primeiro Byte e o seu valor deverá ser 0. É possível que outras tecnologias utilizem este meio
de comunicação usando para isso este bit com o valor 1. Os restantes bits do primeiro Byte
indicam a dimensão total da trama que pode ter até 127 Bytes (5 Bytes de cabeçalho, 121
Bytes de dados e um Byte de CRC).
A partir do formato da trama verifica-se que é possível identificar até 16 segmentos, 32 nós e 8
aplicações referentes a cada um dos nós. No último bit do cabeçalho estão disponíveis quatro
bits para identificar a operação pretendida estando já definidas as seguintes:
• GET (“0000”): permite saber o valor de uma propriedade de um dispositivo;
• SET (“0001”): altera o valor de uma propriedade de um dispositivo;
• NOTIFY (“0010”): reporta, perante situações específicas e normalmente para um
dispositivo de supervisão, a alteração do valor de uma propriedade de um dispositivo e
que possa ter implicações noutros nós;
• FORWARD (“0011”): reencaminha mensagens para outros nós, normalmente Módulos
de Supervisão.
O campo de dados tem um formato definido de quatro Bytes (código de controlo, dispositivo,
propriedade e valor) e no total pode ter 121 até Bytes. O Byte CRC permite verificar a
existência de erros na transmissão da trama.
Este modo de endereçamento permite identificar todos os componentes do sistema. Os nós
estão contidos nos segmentos e executam aplicações que interagem com diferentes
dispositivos e cada um destes tem propriedades próprias.
3.3 Hardware dos módulos
A função dos módulos de controlo e de supervisão é distinta e como tal, o seu hardware
também. Tal como foi descrito anteriormente, os Módulos de Controlo estão vocacionados para
interagir com o meio físico e devem portanto ser capazes de ler sensores e de comandar
actuadores. Os Módulos de Supervisão devem gerir o sistema recebendo e processando dados
provenientes dos Módulos de Controlo.
3.3.1 Módulos de Controlo
Estes módulos, Figura 1, utilizam o microcontrolador da ATMEL AT90S8515 (8 bits e
funcionamento a 8 MHz) com memória Flash, para armazenar programas, de 8 KBytes, 512
Bytes de memória de dados SRAM e 512 Bytes na EEPROM. Tem também outras
características que o tornam apto a funcionar num ambiente domótico tais como: dois
temporizadores (8 bits e 16 bits), comparador analógico, quatro portos I/O de 8 bits, uma UART
25
e interface SPI para comunicação com o exterior. Apesar de simples e de muito baixos
recursos nomeadamente em termos de capacidade de memória, este microcontrolador torna
perfeitamente possível a leitura de sensores e a geração de sinais e sendo de muito baixo
custo, permite a utilização de diversos sensores e actuadores numa habitação repartidos por
vários módulos de controlo.
O microcontrolador encontra-se embutido num circuito integrado contendo também um
transceiver EIA-485 ligado à UART do AT90S8515, interface de comunicação com a rede
DomoBus, um circuito para watchdog que permite fazer a inicialização (mediante um botão de
pressão) e também acesso aos pinos do microcontrolador e alimentação do circuito.
Figura 17 - Módulo de Controlo
3.3.2 Módulos de Supervisão
No sistema DomoBus o conjunto de sensores e de actuadores é ligado exclusivamente aos
Módulos de Controlo levando a que estes possam potencialmente existir em número muito
elevado. Os Módulos de Supervisão, por seu turno, existem em quantidade muito menor já que
estes podem ser responsáveis pela supervisão de muitos Módulos de Controlo. Assume-se que
uma habitação comum, com um bom nível de automatização, pode ser gerida eficientemente
por apenas um ou dois Módulos de Supervisão. Assim, o factor custo não é preponderante
visto que é mais relevante dotar estes dispositivos de elevadas capacidades de processamento
e comunicação, seja por TCP/IP, USB ou Ethernet 10/100, recaindo normalmente a escolha
para placas que suportem Linux embebido.
A placa de desenvolvimento CS-EP930X, Figura 18, é um exemplo de um dispositivo utilizado
e as suas características mais relevantes para a função de supervisão podem ser consultadas
na Tabela 4.
26
Figura 18 - Placa de desenvolvimento CS-EP930X utilizada como Módulo de Supervisão
Tabela 4 - Características da placa de desenvolvimento CS-EP930x relevantes para a função de supervisão
CPU MCU: EP9302 ARM920T com funcionamento
a 200MHz
Memória SDRAM externa – 32 MB
Flash externa – 16 MB
Suporta cartões de memória SD/MMC
Comunicações Ethernet 10/100
Duas portas USB
Dois conectores RS232
Infravermelhos
Sistema Operativo Linux 2.4, Linux 2.6 e NetBus
(disponibilizados em conjunto com a placa)
3.4 Software dos Módulos de Controlo
Quando este trabalho foi iniciado, o sistema DomoBus contava já com algumas versões
funcionais e encontravam-se também implementadas várias aplicações que continham pelo
menos duas máquinas de estados (uma para receber, enviar e tratar as mensagens
transmitidas entre os diferentes dispositivos e outra para implementar a funcionalidade
pretendida para a aplicação). Esta situação levava a que ao implementar as diversas
aplicações se repetisse imenso código pois apesar de terem algumas funcionalidades
específicas, existia uma grande duplicação de código associado ao tratamento das
mensagens. Num microprocessador de baixos recursos como aquele que foi utilizado,
AT90S8515, este tipo de situação dá azo a um desperdício significativo de memória que pode
comprometer ou invalidar a implementação das funcionalidades pretendidas.
27
O módulo software de comunicações existente, apesar de ter implementado um método para
reduzir colisões entre nós, usa uma política simples e estática que deixa de ser eficaz quando
se aumenta o número de nós e para situações com tráfego significativo.
Existe portanto bastante espaço para melhoramento do software dos Módulos de Controlo,
sendo esse um dos objectivos deste trabalho. No próximo capítulo apresentar-se-ão as
propostas desenvolvidas para aperfeiçoar a comunicação e o suporte ao desenvolvimento de
aplicações domóticas robustas.
29
4 Arquitectura de software dos Módulos de Controlo
4.1 Núcleo de tempo real
Devido aos parcos recursos do microcontrolador nomeadamente em termos de memória e
capacidades de processamento, optou-se por não se utilizar nenhum dos sistemas operativos
de tempo real analisados pois, no geral, implicavam um gasto demasiado elevado de recursos
do processador e limitavam a portabilidade do código pois esta apenas seria fácil para onde o
sistema operativo já estivesse disponível. Caso contrário, existiria uma complexidade bastante
elevada para portar esse sistema operativo para outro processador/placa de desenvolvimento.
Com vista a identificar a solução mais adequada foram considerados os seguintes aspectos
[20]:
• Utilização de um escalonamento cooperativo (as tarefas libertam o processador por sua
iniciativa dando oportunidade a que outras possam correr). Esta abordagem permite
simplificar os aspectos relacionados com sincronização e acesso a recursos comuns.
Como contrapartida, as aplicações necessitam de ser estruturadas em máquinas de
estados e, em certos casos, acções muito longas podem necessitar de ser divididas em
duas ou mais partes para garantir uma utilização equitativa do processador por todas
as tarefas. Não obstante a restrição indicada, esta abordagem permite uma
implementação simples das tarefas e oferece uma solução muito eficiente. Salienta-se
que a utilização de um escalonamento preemptivo introduz um nível de complexidade
demasiado elevado para os sistemas de baixo recursos com que se está a lidar, pelo
que esse aspecto não foi contemplado;
• Inexistência de prioridades considerando todas as tarefas com igual importância;
• Utilização de interrupções apenas quando indispensáveis, sendo usadas tipicamente
para tratar ocorrências associadas ao hardware e situações com requisitos estritos de
tempo;
Considerando todos os aspectos anteriores, decidiu-se utilizar tarefas executadas de uma
forma cíclica e recorrendo a uma política Round-Robin – cada tarefa recebe uma fatia de
tempo de utilização do CPU e findo este tempo, o processo é enviado para o fim da fila de
execução. Assim, é importante assegurar, no momento de transição de cada tarefa, a
salvaguarda de contexto para que quando a tarefa for retomada esta continue do ponto em que
se encontrava no momento em que a tarefa a executar foi comutada.
Tal como referido anteriormente, a marcação de tempos foi um dos aspectos considerados no
momento de optar por esta abordagem, pois é muito importante calcular o tempo esperado de
execução de cada tarefa para melhor distribuir os recursos de processamento do sistema. Ao
somar os tempos máximos de todas as tarefas, é possível fazer uma estimativa da frequência
com que estas vão ser executadas e determinar o correcto ritmo de polling das entradas do
30
sistema. É também possível optar por associar as entradas do sistema à geração de
interrupções do processador. Contudo, o seu tratamento interfere na normal execução das
tarefas e na contabilização da frequência de execução destas e como tal, convém usar este
recurso apenas quando indispensável e colocar o mínimo código possível nas rotinas de
tratamento das interrupções.
4.2 Comunicação
Os módulos de controlo que compõem o sistema DomoBus, necessitam de comunicar com as
diversas aplicações sejam locais (presentes no próprio módulo) ou remotas (presentes noutros
módulos). A tarefa “NET” implementa o rede de comunicação DomoBus através de uma
máquina de estados (tem a função da camada lógica e de rede). A um nível superior, a troca
de informação entre aplicações é assegurada através da utilização de um buffer, mailbox, que
é utilizado tanto para a recepção como para a transmissão de tramas DomoBus.
O facto de se utilizar apenas uma mailbox por aplicação, devido a restrições da memória
disponível, tem como consequência que a comunicação tenha de ser feita em modo half-duplex
já que não se pode enviar e receber uma mensagem em simultâneo. As tramas DomoBus são
constituídas por sequências de caracteres que são enviadas através usando uma comunicação
série assíncrona com 8 bits de dados, enviados com ao ritmo de 19200 bps. É normalmente
utilizada a UART interna do microcontrolador (apesar de existir a possibilidade de se usar uma
UART externa) e recorre-se a um transceiver EIA-485 para gerar e receber os sinais enviados
pelo meio físico (camada física do protocolo). A activação da Interrupção 0 (INT0) do
microcontrolador denuncia o início de uma comunicação pois o bit que indica o início de um
novo carácter (start bit) possui o valor 0. Após o conjunto dos 8 bits de informação é enviado
um bit a 1 (stop bit) que sinaliza o fim do carácter. Por cada conjunto de 8 bits de dados úteis
são portanto enviados 10 bits.
Figura 19 - Comunicação Série Assíncrona
A tarefa “NET” está permanentemente a observar o meio de comunicação para detectar o inicio
de uma nova mensagem. Se não houver nada para receber verifica se as aplicações existentes
no nó possuem mensagens para enviar. Durante todo o processo de comunicação, é
necessário recorrer a temporizadores que vão sincronizar as acções de recepção/envio de
31
tramas e, em caso de erros, é retomado o estado inicial da tarefa “NET” ficando a aguardar o
início de uma nova mensagem.
Durante a recepção de uma mensagem, começam por ser analisados os três primeiros bytes
que indicam a dimensão da mensagem e o endereço destino (Figura 16). Com base nessa
informação verifica-se se a mensagem se destina ao nó e se a aplicação destino tem a mailbox
livre e possui dimensão suficiente para guardar a mensagem. Em caso afirmativo, a recepção
prossegue sendo a informação recebida escrita directamente na mailbox da aplicação. Se a
mailbox estiver ocupada, é enviado um byte de jamming para a rede para gerar uma colisão e
interromper o envio desnecessário do resto da mensagem o que vai permitir melhorar o débito
do canal de comunicação. Caso a recepção completa da mensagem se venha a verificar, e se
esta não tiver erros (verificados pelo cálculo do CRC), é enviado um Byte a confirmar o
sucesso de recepção (ACK). No caso de existirem erros, envia-se um Byte com o significado
de insucesso (NACK).
Aquando do envio de uma mensagem, o módulo “NET” escuta o meio de comunicação para
verificar a ocorrência de colisões, o que implica a necessidade de reenviar a mensagem. Caso
todos os Bytes tenham sido enviados com sucesso, o módulo “net” evolui para um estado em
que espera pela confirmação de recepção da mensagem. Se esta confirmação for recebida
(ACK), retoma-se ao estado inicial da máquina de estados. Caso contrário (recepção de um
NACK), tenta-se um reenvio da mensagem (com número de tentativas limitado).
O ritmo de polling dos registos para verificação de mensagens novas para serem recebidas
tem de ser o correcto tendo em conta a frequência de relógio do microcontrolador (8 MHz) e o
ritmo utilizado para a comunicação série (19200 bps). Tal como descrito anteriormente, a UART
transmite 10 bits por cada byte de dados e assim a taxa de transferência situa-se nos 1920
byte/s o que significa que é necessário fazer polling aos registos 1920 vezes por segundo
(aproximadamente a cada 520 µs). Dada a frequência do microcontrolador e a dimensão das
aplicações, o valor é adequado já que é possível executar 4166 instruções entre cada polling
dos registos.
O incremento do número de mensagens enviadas e recebidas pode provocar o
congestionamento da rede devido ao aumento do tráfego a um nível superior à capacidade do
canal, tendo como consequência a ocorrência de atrasos no envio das mensagens. Dado que
se pretende que um sistema domótico seja fiável e com um tempo de actuação reduzido, esta
é uma situação que deve ser evitada ou minimizada a todo o custo. A Internet, por exemplo,
tem implementado um mecanismo que força os sistemas a baixar a taxa a que enviam pacotes
de dados para a rede nos períodos críticos em termos de congestionamento. Os nós que
enviam as mensagens apercebem-se da situação crítica da rede ao deixarem de receber as
respostas de baixo nível, ACK, que servem de confirmação daquilo que foi enviado para os nós
32
de destino pelo que reduzem a taxa de transmissão. Por outro lado, numa situação de melhoria
das condições da rede (quando são recebidas respostas de baixo nível de pacotes anteriores),
torna-se possível aumentar a taxa de envio de pacotes permitindo que esta se aproxime dos
valores máximos aceitáveis. Este mecanismo é conhecido como algoritmo AIMD (Additive-
Increase, Multiplicative-Decrease) [21].
Débito
Figura 20 - Controlo de congestionamento através do algoritmo AIMD
No caso do sistema DomoBus, o acesso ao meio é assegurado através do protocolo CSMA/CD
que, tal como referido anteriormente, antes de iniciar o envio de informação escuta o meio de
transmissão de modo a detectar o silêncio necessário para o início do envio das mensagens e
que é composto por uma parcela fixa (relacionada com as características do meio de
transmissão) e por uma parcela aleatória - para evitar que dispositivos diferentes enviem
informação ao mesmo tempo e provoquem uma colisão. A componente fixa do tempo de
silêncio depende da prioridade da trama (se esta for prioritária tem um tempo de espera
inferior) e a componente aleatória é ajustada ao longo do tempo, variando em função do
número de colisões detectadas.
As mensagens presentes na rede são contabilizadas durante um período de tempo e finda a
amostragem, tem-se uma percepção do estado da rede comparando o número de mensagens
com valores pré-estabelecidos para situações de tráfego reduzido, médio e elevado. No caso
de o número de mensagens ultrapassar os valores estabelecidos para as situações de tráfego
médio ou elevado, força-se um certo tempo de espera antes do envio da trama o que visa
evitar o congestionamento da rede.
4.3 Suporte das aplicações DomoBus
Com a implementação actual do DomoBus resultante da contribuição deste trabalho, as
aplicações passam a conter apenas código que diz unicamente respeito à sua funcionalidade e
ao tratamento de mensagens não normalizadas. O tratamento de mensagens normalizadas
(mensagens que manipulam as propriedades dos dispositivos) é feito recorrendo a uma tarefa
comum a todas as aplicações (MSG) e que por sua vez acede a funções de uma biblioteca que
33
disponibiliza as estruturas que permitem gerir as propriedades (PROP). Estes módulos em
conjunto com o módulo de comunicações abordado na secção anterior suportam as aplicações
DomoBus, Figura 21.
Figura 21 - Integração das aplicações com os diferentes módulos
Tipicamente uma aplicação DomoBus, e em termos genéricos a maioria dos sistemas
domóticos, tem como finalidade operações relacionadas com a leitura de sensores e com o
comando de actuadores (pode, por exemplo, pensar-se num conjunto de aplicações que
mediante a leitura de um sensor que mede a intensidade luminosa ou a temperatura, ordene o
fecho ou abertura de uma janela). Um Módulo de Controlo pode executar até 8 aplicações e
possibilita a ligação de até 32 dispositivos. Uma aplicação deve conter propriedades (do tipo
byte, word ou array de 8 bits) consonantes com a especificidade, a área de actuação e a
característica dos dispositivos para que se alcance o melhor desempenho e fiabilidade
possível. Pensando na situação anterior, em que existiria um sensor de luminosidade e por
exemplo um relé para abrir ou fechar a janela, seria necessário criar uma aplicação para fazer
a leitura do sensor de luminosidade, outra para ler o valor de temperatura e ainda uma
aplicação para actuar os relés para a posição desejada. Uma aplicação DomoBus típica trata
logo vários sensores e actuadores do mesmo tipo e no exemplo anterior, as propriedades
necessárias para as três aplicações seriam, respectivamente, as seguintes:
• Aplicação 1: Propriedade que indica o valor medido pelo sensor de luminosidade;
• Aplicação 2: Propriedade que indica o valor medido pelo sensor de temperatura;
• Aplicação 3: Propriedade cujo valor indica a posição do relé para a actuação desejada
(subir/descer estore ou repouso).
A abordagem mais óbvia seria a de criar apenas uma aplicação para a concretização deste
objectivo mas, por outro lado, ao serem criadas aplicações distintas o sistema torna-se mais
modular. Com efeito, deste modo é possível que uma aplicação leia logo um conjunto de
34
sensores e que outra controle um grupo de relés. No exemplo anterior, a aplicação para fazer a
leitura do valor de temperatura poderia também ser utilizada, por exemplo, por outra aplicação
para activar um alarme no caso de se atingir um determinado valor de temperatura. De outro
modo, a alternativa seria criar uma aplicação que lesse e controlasse os diversos sensores e
actuadores mediante as necessidades do momento, o que acrescentaria dificuldade ao
desenvolvimento e à gestão. As aplicações desenvolvidas seriam executadas pelos Módulos
de Controlo e caberia ao Módulo de Supervisão a ordenar a actuação dos componentes
actuadores mediante os valores lidos pelos sensores.
Foi desenvolvido um mecanismo para as aplicações gerarem e enviarem mensagens, através
de eventos associados a uma propriedade em particular. Ao activar um evento, torna-se
possível construir automaticamente a mensagem, permitindo por conseguinte o envio de
comandos de leitura ou escrita de valores nas propriedades (a cada propriedade está
associado apenas um evento e uma mensagem). Tendo em consideração alguns dos
objectivos do sistema DomoBus (flexibilidade, fiabilidade e escalabilidade), ao ser activado um
evento é necessário associar-lhe um valor que para além de sinalizar se o mesmo já foi
confirmado, indica também se a mensagem a ser gerada deve ser imediata e o número de
retransmissões (rápidas ou lentas) que esta deverá ter. As retransmissões lentas permitem que
as tentativas de envio da mensagem não afectem a rede visto que são bastante espaçadas no
tempo. É também possível a opção Repeat Forever, para que a mensagem seja enviada até
ser recebida a respectiva resposta. Estão disponíveis operações que são discriminadas nas
mensagens enviadas entre aplicações: GET, SET e NOTIFY. Regressando ao exemplo
anterior, seria adequado existir uma notificação, gerada sempre que houvesse uma alteração
do valor de temperatura ou no caso de o sensor ler um valor considerado elevado, de modo a
poderem ser tomadas as acções necessárias. A estrutura das mensagens normalizadas, pode
ser observada na Figura 22. Estas contêm um número de sequência para permitir o
emparelhamento unívoco das respostas às mensagens e indicam também o dispositivo, a
propriedade e o valor.
Figura 22 – Estrutura de uma mensagem DomoBus normalizada
Estando já introduzidas as noções de propriedade e evento e as três operações
disponibilizadas, descrevem-se em seguida de uma forma mais extensa e profunda as
restantes tarefas que suportam as aplicações DomoBus (a tarefa “NET” já foi descrita
anteriormente, na secção 4.2).
35
4.3.1 Módulo de Gestão das Propriedades
As propriedades são entidades intrínsecas ao nó a que dizem respeito já que são altamente
dependentes dos dispositivos e da funcionalidade pretendida. Para que as aplicações possam
ir de encontro com as funcionalidades pretendidas e para que seja possível de uma forma
flexível lidar com diferentes níveis de precisão, optou-se por dotar este sistema de três tipos
(dimensões) possíveis para o valor das propriedades (byte, word e array de valores de 8 bits).
A definição das estruturas de dados necessárias assim como as funções de leitura e escrita
dos valores das propriedades podem ser encontradas em PROP sendo este considerado uma
biblioteca de funções e estruturas, com o objectivo de uniformizar o acesso e manipulação das
propriedades. O módulo PROP será usado tanto pelas aplicações como pelo módulo de
geração de mensagens de modo a ser possível aceder ao valor das diversas propriedades.
O módulo PROP contém igualmente estruturas de dados que permitem contabilizar o número
de eventos activos por aplicação (aqueles que estão sinalizados para o envio de mensagem ou
que ainda não esgotaram o número de tentativas de reenvio) e guardar um valor associado a
cada um dos eventos que para além de conter o código de sequência utilizado para o
emparelhamento das respostas às mensagens que lhes deram origem, indica se o valor da
propriedade é valido ou não.
Em suma, PROP tem como objectivo guardar as estruturas de dados que dão suporte às
propriedades e aos eventos e também conter funções que os permitem manipular (ler e
escrever valores de propriedades, activar e desactivar eventos e assinalar que um determinado
valor de uma propriedade é válido ou inválido).
4.3.2 Módulo de Tratamento das Mensagens
As funções que possibilitam o envio e recepção de mensagens normalizadas e as estruturas de
dados que lhes dão suporte, encontram-se implementadas no módulo MSG. Esta
implementação é bastante vantajosa pois permite isolar das aplicações os procedimentos de
envio e recepção de mensagens. Isto abre caminho a que estas tenham apenas operações
relativas à funcionalidade pretendida na sua unidade funcional. Assim, estas tornam-se
bastante mais simples do ponto de vista de implementação e compreensão e permitem
também poupar memória ao sistema, cujos recursos são bastante limitados (o hardware dos
módulos de controlo encontra-se descrito em 3.3.1).
Em termos genéricos, as aplicações activam os eventos e isso despoleta o envio de
mensagens através do módulo MSG. Este módulo é portanto responsável pelo preenchimento
das mailboxes das aplicações e estas são posteriormente transmitidas pela rede através de
chamadas a funções presentes na tarefa NET. Este método permite poupar drasticamente a
memória do sistema visto que não são criadas filas de mensagens mas antes eventos cujo
36
valor vai posteriormente permitir a construção das mensagens. Desta maneira, ao invés de se
utilizarem buffers para armazenar cada uma das mensagens com dimensão de cerca de 10
bytes (cabeçalho e campo de dados), apenas existe um evento cujo valor ocupa apenas um
byte e descreve se a mensagem deve ser enviada e também o número de retransmissões que
lhe estão associadas. Em conjunto com esta abordagem, foi implementada uma estrutura
associada aos eventos contendo temporizadores que indicam o instante em que a
retransmissão da mensagem deve ocorrer.
Descreve-se em seguida, de uma forma sucinta, o comportamento do módulo MSG e das
aplicações face às três operações normalizadas presentes neste sistema:
• GET (Código de operação 0): a operação permite obter o valor de uma propriedade
(torna-se portanto necessário conhecer de antemão o tipo - byte, word ou array - pois
existem três tipos diferentes) e fazer a leitura do seu valor. Quando um nó envia este
comando (por intermédio do módulo MSG), recebe como resposta o valor da
propriedade. Como este só interessa e diz respeito à aplicação que despoletou o envio
do GET, o resultado é-lhe passado de modo a ser convenientemente tratado. No caso
de o nó estar a receber um comando GET, MSG obtém ele próprio (através da leitura
das estruturas de dados correspondentes) o valor da propriedade e responde enviando
o resultado, sem que seja necessária a intervenção da aplicação;
• SET (Código de operação 1): com a operação SET é possível alterar o valor de uma
propriedade e portanto. Ao enviar este comando através de MSG, um nó recebe uma
resposta que confirma que a operação foi efectuada (isto anula o evento evitando que
sejam efectuadas retransmissões). No caso da recepção, MSG activa a propriedade
correspondente, escreve o valor e envia a resposta (de confirmação da operação);
• NOTIFY (Código de operação 2): uma aplicação pode enviar um comando NOTIFY
que tipicamente notifica sempre que ocorrer uma alteração de valores das
propriedades. Numa situação de envio do comando e ao chegar a resposta de
confirmação, MSG anula o evento que motivou a operação. No caso de recepção do
comando, e como MSG não sabe tratar, envia a mensagem para a aplicação pois só a
ela faz sentido.
A existência de confirmações por parte das aplicações é fundamental pois só assim é possível
garantir que a mensagem foi entregue visto que a tarefa “NET” efectua retransmissões mas
desiste quando o número de tentativas se esgota. Se MSG receber mensagens
desconhecidas, fora deste conjunto de operações normalizadas, passa-as para as aplicações
de modo a serem adequadamente processadas.
37
4.3.3 Módulo de acesso à EEPROM
Neste módulo encontram-se todas as funções necessárias para ler e escrever dados na
EEPROM do microcontrolador. Esta é uma memória adicional e persistente e pode ser alterada
em qualquer momento, tendo-se optado por recorrer à EEPROM para guardar o esqueleto das
mensagens, de modo a poupar memória. De modo a melhorar a eficiência das operações de
leitura e escrita, a tarefa foi implementada através de uma máquina de estados, pois a
operação de escrita na EEPROM é demorada e não pode ser uma acção bloqueante porque
afectaria o restante funcionamento do sistema.
O esqueleto das mensagens normalizadas está escrito na EEPROM interna do
microcontrolador e contém o destino destas e a operação a realizar sendo apenas preciso, nos
casos adequados, preencher o valor da propriedade que se pretende enviar de modo a gerar a
mensagem completa. O acesso a esta memória é concretizado somando o respectivo número
do evento ao endereço de base da EEPROM.
4.4 Aplicações DomoBus implementadas
As aplicações para o sistema DomoBus que se seguem são apenas dois exemplos que
demonstram a implementação da leitura de entradas e os respectivos comandos de actuação.
Estas encontravam-se já implementadas seguindo a anterior filosofia (a máquina de estados
relativa ao tratamento de mensagens e respectivo envio e recepção coexistia com a máquina
de estados específica da aplicação), o que introduzia enorme complexidade visto que
necessitava de tratar de vários procedimentos desde a composição de mensagens até ao seu
envio, validação das respostas e eventuais retransmissões. Foram portanto novamente
desenvolvidas segundo a nova metodologia e neste momento possuem apenas a máquina de
estados intrínseca ao seu funcionamento, tendo ficado muito mais simples.
4.4.1 Aplicação de gestão do nó
Esta aplicação (designada de SYS) deverá estar presente em todos os nós já que é
responsável por várias funções de gestão tais como controlar os LED do sistema, activar o
watchdog, monitorizar erros ocorridos nas outras aplicações, receber mensagens de broadcast
e obter um endereço para o nó no caso de ainda não lhe ter sido atribuído um.
4.4.2 Aplicação Relay – Actuações ligar/desligar
Com esta aplicação, o sistema consegue comandar um conjunto de relés e assim ligar ou
desligar equipamentos ligados ao sistema. Após a recepção da mensagem contendo o
comando, faz-se a respectiva actuação e gera-se uma mensagem NOTIFY de modo a fazer a
notificação da alteração.
38
Figura 23 - Aplicação Relay
4.4.3 Aplicação Switch – Leitura de interruptores
O objectivo desta aplicação é ler um conjunto de interruptores e botões de pressão para poder
desencadear, por exemplo, actuações sobre lâmpadas. Por razões relacionadas com a rapidez
de execução, em cada ciclo apenas é tratado um interruptor. Os botões de pressão encontram-
se normalmente inactivos, alterando o seu estando quando o utilizador os pressiona e os
interruptores possuem dois estados que, gerando a mensagem respectiva, afectam
directamente o estado da lâmpada, Figura 24. No caso de o utilizador carregar de uma forma
breve nos botões de pressão, o estado da lâmpada (ligada/desligada) deverá ser comutado e
na eventualidade de o botão ser pressionado longamente, a intensidade da lâmpada deverá
variar.
Para implementar esta aplicação, quando os botões de pressão são activados é feita uma
contagem do tempo e se esta for inferior a uma constante denominada por tempo de toggle, é
gerada uma mensagem para alterar o estado da lâmpada. Se, por outro lado, o tempo de
toggle for ultrapassado, a intensidade da lâmpada é regulada e é feita uma leitura periódica
para gerar a mensagem que indica o novo valor da lâmpada sem se deixar de pressionar o
botão, Figura 24.
Figura 24 - Aplicação Switch
A estrutura de uma aplicação típica DomoBus será detalhada no capítulo seguinte.
39
5 Detalhes de Implementação
5.1 Comunicação
O protocolo de comunicação (camada de ligação de dados e acesso ao meio) foi implementado
através de uma máquina de estados que contempla o acesso ao meio físico, o processo de
envio e de recepção, o envio de retransmissões (nível 2) para tornar a rede mais fiável e
robusta. Para optimizar a utilização de largura de banda e permitir débitos maiores,
implementou-se um mecanismo que mediante a percepção do nível de utilização da rede e do
número de colisões, vai gerindo o tempo aleatório de acesso ao meio de transmissão e o fluxo
de dados enviado para evitar congestionamentos.
O estado inicial – IDLE – verifica a existência de actividade no meio físico, que denuncia a
existência do start bit de um novo carácter. Em caso afirmativo evolui-se para o estado
RECEIVE_FIRST_BYTE onde o primeiro byte é recebido e guardado. Este estado, após a
recepção do primeiro byte da trama, lê-o de modo a detectar a existência de framming error –
erro relacionado com o encapsulamento do bit - que obrigaria a máquina a retomar ao estado
IDLE. Sendo o byte recebido válido, guarda-se o primeiro byte preparando a recepção dos
seguintes através do estado RECEIVING. Existe também um tempo considerado máximo para
a espera do byte e que quando ultrapassado, faz a máquina retomar ao estado IDLE.
RECEIVING é o estado que vai recebendo os bytes que constituem a trama. Caso seja
detectado um erro de recepção (framming error), retorna-se ao estado IDLE. Não havendo
problemas com a integridade do byte recebido, este é processado assumindo que os bytes são
recebidos por uma determinada ordem. É analisado o endereço de destino da trama e esta é
ignorada se não for coincidente com o endereço do nó que está a receber. Após este passo, é
fundamental saber que aplicação vai efectuar a recepção, se a mailbox desta tem espaço para
guardar a trama e se está livre. No caso de ser necessário evitar o envio do resto da trama pois
o espaço disponível da mailbox da aplicação não é suficiente ou está ocupada, é feito jamming
para provocar colisão e segue-se para o estado WAIT_TX_COMPLETE. Para minimizar o
número de mensagens abortadas pela eventualidade de a mailbox estar ocupada, é feita uma
distinção entre mensagens de resposta e mensagens de iniciativa própria. Estas podem ser
geradas novamente mais tarde (recorrendo ao mecanismo de eventos implementado) e
portanto, podem ser ignoradas. Quando se está a efectuar a recepção da trama, a mailbox da
aplicação correspondente altera o seu estado para ocupada e no final, após a leitura do CRC,
passa-se para o estado SEND_ACK para enviar a confirmação da correcta recepção ou para
SEND_NACK para indicar a existência de um erro.
40
SEND_ACK e SEND_NACK são estados que têm como objectivo o envio de um byte de
indicação de correcta ou incorrecta recepção da trama e a evolução para o estado onde vai ser
feita a desactivação do transceiver, WAIT_TX_COMPLETE.
Se no estado IDLE não for detectado o carácter inicial, verifica-se a existência de mensagens
para serem enviadas. Na eventualidade de existirem, procura-se, de forma circular, a aplicação
que vai enviar a mensagem e é seguida uma política em que se dá maior prioridade a
respostas, depois a mensagens prioritárias e por fim, a mensagens de prioridade normal. De
acordo com o mecanismos de controlo de congestionamento implementado e dependendo do
tráfego existente, as mensagens podem estar sujeitas a um tempo de espera para não
sobrecarregarem a rede. Antes de iniciar a transmissão da mensagem é feita uma nova
verificação ao meio físico e se esteve estiver activo, avança-se para o estado
RECEIVE_FIRST_BYTE. Se, pelo contrário, for detectado silêncio no meio de comunicação,
verifica-se o destino da mensagem e inicia-se o envio da mesma. No caso de a mensagem ser
local ao nó, é feita uma cópia para a mailbox libertando-a de seguida mas se esta tiver como
destino outro nó, escreve-se o primeiro byte da trama (indicação da dimensão) e o cabeçalho
pois vai ser usado para confirmar aquilo que se enviou. Depois destes passos, avança-se para
o estado SENDING onde se faz o envio da trama – com excepção do primeiro byte que é
enviado logo no estado IDLE.
O estado SENDING, de modo a detectar colisões, tem implementado um sistema de eco ou
seja, tudo aquilo que envia é lido posteriormente. À semelhança de outros estados, aqui
também é feita uma verificação a existência de framming error que existindo, pode ser devido a
um jamming devido à mailbox do nó destino estar ocupada ou a uma colisão. Neste estado o
tratamento desta situação é diferente das demais pois aqui é aumentado o atraso de envio por
parte do nó para contribuir para reduzir a probabilidade de uma nova colisão e é feita a
passagem para o estado TEST_SEND_AGAIN onde é testado se a mensagem deve ser
retransmitida ou se foram esgotadas as tentativas de reenvio. Findo o envio de todos os bytes,
desactiva-se o transceiver e segue-se para o estado WAIT_ACK. No caso de ser enviada uma
mensagem de broadcast não se aguarda pelo ACK e a mailbox é imediatamente libertada.
No estado WAIT_ACK recebe-se o byte de resposta à mensagem enviada. Se este for de
confirmação do sucesso do envio, ACK; limpa-se a mailbox da aplicação e, já que esta
situação pode querer indicar uma melhoria na fluidez da rede, o tempo de espera de acesso ao
meio é reduzido retornando-se ao estado IDLE. Na eventualidade de ser receber um byte de
insucesso, NACK ou outra coisa que não ACK, não faz sentido aumentar o tempo de acesso
ao meio pois à partida essa ocorrência deve-se a um erro do CRC causado por ruído no meio
de comunicação e não um problema de contenção de acesso ao meio. A Figura 25 contém um
esquema (muito simplificado devido à sua complexidade) da máquina de estados
implementada.
41
IDLE
SENDINGRECEIVE_FIRST_BY
TE
recepção envio
RECEIVING
WAIT_TX_COMPLETE
mailbox ocupada
SEND_NACKSEND_ACK
CRC incorrecto
CRCcorrecto
TEST_SEND_AGAIN WAIT_ACK
colisão envio terminado
Figura 25 - Esquema simplificado da máquina de estados da NET
Pela descrição da máquina de estados é possível identificar a existência do mecanismo que
permite gerir o tráfego da rede aumentando a fiabilidade, a robustez e a eficiência mas em
seguida faz-se uma descrição mais pormenorizada da implementação do mesmo.
A solução desenvolvida tem uma percepção do estado da rede para poder intervir
convenientemente. Utiliza-se um temporizador que durante a marcação do tempo contabiliza o
número de mensagens presentes na rede. Assim, quando se inicia a recepção ou o envio de
uma trama, este contador é incrementado. Atingido o tempo estabelecido, compara-se a
contagem do contador com os três níveis estabelecidos que ditam o estado da rede (tráfego
reduzido, tráfego normal e tráfego elevado) e actua-se em concordância atribuindo um tempo
menor ou maior para a pausa que antecede o acesso ao meio de transmissão. Após esta
intervenção, o contador de mensagens retoma o valor 0 e é iniciado um novo período de
amostragem.
Para possibilitar que as aplicações enviem mensagens de forma equitativa, a pesquisa é feita
de forma circular ao invés de começar sempre a partir da aplicação 0. Existem três níveis de
prioridade das mensagens que permite estabelecer o tempo que estas têm de aguardar antes
de a sua transmissão ser iniciada. As mensagens de prioridade muito alta (super-prioritárias)
42
aguardam um tempo de guarda, estabelecido de acordo com as características do meio,
adicionado a uma componente fixa de tempo relacionada com a prioridade. No caso das
mensagens de prioridade alta e normal, para além o tempo de guarda e da componente fixa
estabelecida de acordo com a prioridade, aguardam também um valor aleatório. No primeiro
caso, a gama de valores aleatórios para o tempo é mínima enquanto no segundo caso esta
depende do nível de tráfego da rede e vai aumentando ou diminuindo de acordo com as
colisões (indicador do estado da rede). Este ajuste é feito no estado SENDING ao ser
detectado um framming error, eventualmente relacionado com uma colisão ou jamming e no
estado WAIT_ACK ao ser transmitida uma mensagem com sucesso que pode indicar uma
melhoria na rede. A maioria das mensagens enviadas vai ter prioridade normal mas como
todas as mensagens devem ser respondidas, as mensagens de resposta devem ter prioridade
face às demais mensagens e como tal, utilizam-se mensagens super-prioritárias como
resposta. Esta abordagem contribui para aumentar o débito da comunicação e reduzir o
número de colisões.
5.2 Suporte das aplicações DomoBus
As aplicações activam os eventos durante o funcionamento do sistema e é através destes que
o envio de mensagens é despoletado. Para poupar memória, a EEPROM do microcontrolador
contém o esqueleto das mensagens e no momento do envio, este é copiado para a mailbox
para ser devidamente preenchido e ficar pronto para ser enviado. O módulo MSG é o
responsável pelo tratamento das mensagens normalizadas devendo as aplicações tratar as
mensagens que forem específicas. Para que todos estes módulos funcionem correctamente e
devido à especificidade de cada nó, é fundamental que seja configurado o ficheiro que contém
as definições globais do nó.
5.2.1 Módulo PROP
Esta biblioteca contém as estruturas de dados e as funções necessárias para a manipulação
de eventos e de propriedades. Como existem três tipos de propriedades relacionados com a
dimensão do valor que lhes é referente (byte, word e array), algumas funções, apesar de
análogas, foram triplicadas para o correcto mapeamento de todas as propriedades. A uma
propriedade está associado um só evento e uma só mensagem, existindo uma estrutura de
dados global aos três tipos de propriedades e que guarda o valor de todos os eventos. Este
array está ordenado por tipo de propriedade (P), aplicação (A), número de propriedade (P) e
dispositivo (D), Figura 26.
43
Figura 26 – Exemplo de array de eventos e respectiva ordenação por tipo (Byte (B), Word (W) ou Array (A)), aplicação
(A), número de propriedade (P) e dispositivo (D)
É absolutamente necessário moldar o sistema de acordo com os recursos disponíveis, as
especificidades do nó e o funcionamento pretendido. Recorre-se, para isso, ao ficheiro que
contém as definições globais a serem aplicadas ao nó. É aqui que são indicadas e distribuídas
(de acordo com as regras de configuração) as propriedades referentes aos diversos
dispositivos, sendo fundamental distingui-las consoante a sua dimensão.
Os eventos são activados pelas aplicações e é importante fazer uma contabilização do número
de eventos activos assim como a sua distribuição por aplicação. No primeiro caso, existe um
contador global mas para distribuir a contagem de eventos por aplicação, utilizou-se um vector
cuja dimensão corresponde ao número de aplicações. Optou-se também por implementar uma
estrutura de dados, Figura 27, que indica se um determinado valor de uma propriedade é valido
ou não assim como um número de sequência utilizado para emparelhar as mensagens que
permite saber se a resposta/confirmação recebida pertence efectivamente à mensagem
enviada. Esta abordagem de colocar simultaneamente no byte de controlo o número de
sequência e a validade do valor deve-se a um esforço para poupar memória.
Figura 27 - Byte de controlo que permite indicar a validade do valor de uma propriedade e o número de sequência para
emparelhar mensagens
Sempre que for necessário aceder a uma propriedade é fundamental saber o correcto índice
que a mesma ocupa na estrutura de dados global e portanto desenvolveu-se uma função para
cada tipo de propriedade, que ao receber o número do dispositivo e da propriedade, devolve o
índice. Ao ser devolvida esta informação, é possível fazer a leitura ou atribuição de valores a
propriedades mas no entanto, antes de escrever um novo valor é necessário saber se o valor
lido é válido ou não. Para lidar com essa situação, existem funções para testar o byte de
controlo representado na Figura 27 e indicar a validade do valor da propriedade. Se o valor for
inválido, deve ser ignorado.
No momento em que a activação dos eventos é originada pelas aplicações - chamando a
função correspondente da biblioteca PROP - é atribuído um valor ao evento, Figura 28. Este
44
valor permite indicar se o evento foi confirmado (já foi recebida a sua mensagem de resposta),
se deve ser enviada uma mensagem e o número de retransmissões (rápidas ou lentas) que
devem ser enviadas. É também possível indicar o envio de uma mensagem até ser recebida a
mensagem de resposta (Repeat Forever) atribuindo o valor 1 todos os bits referentes a Slow
Repeat.
Figura 28 - Byte que indica o valor atribuído aos eventos
No módulo PROP existe também uma função que permite desactivar um evento activo
afectando as variáveis que contabilizam o número de eventos activos (global e por aplicação).
Foi também implementada uma função que recebe como parâmetro um número de sequência,
testa os eventos e devolve o índice respectivo em caso de sucesso.
A Tabela 5 lista as funções de manipulação de eventos e propriedades citadas anteriormente:
Tabela 5 - Funções de manipulação de eventos e propriedades do módulo PROP
Função Descrição
PROP_set_byte_index(device, property)
PROP_set_word_index(device, property)
PROP_set_array_index(device, property)
Através da indicação do dispositivo e da propriedade,
devolve o índice para aceder correctamente ao array de
propriedades e eventos.
PROP_get_byte()
PROP_get_word()
PROP_get_array()
Devolve o valor da propriedade definida pela função
PROP_set_”tipo”_index()
PROP_set_byte(value)
PROP_set_word(value)
PROP_set_array(value)
Atribui o valor às propriedades definidas pela função
PROP_set_”tipo”_index()
PROP_set_event(event_value) Função chamada pelas aplicações e que activa o evento
cujo índice foi determinado através de
PROP_set_”tipo”_index()
PROP_clr_event(event_index) Elimina o evento passado como parâmetro
PROP_set_value_invalid() Assinala que o valor da propriedade definida através de
PROP_set_”tipo”_index() é inválido e deve ser ignorado
PROP_set_value_valid() Assinala que o valor da propriedade definida através de
PROP_set_”tipo”_index() é válido
PROP_value_is_invalid() Retorna um valor que indica se a propriedade defnida
através de PROP_set_”tipo”_index() contém um valor
válido ou não
PROP_search_seq_code(seq_code) Pesquisa o array que contém o número de sequência
dos eventos e devolve o índice respectivo
PROP_save_and_set_event_byte()
PROP_save_and_set_event_word()
PROP_save_and_set_event_array()
Função chamada pelas aplicações quando for lido um
novo valor de uma propriedade que deve ser guardado e
activado
45
5.2.2 Módulo MSG
O módulo MSG implementa as funcionalidades associadas ao envio e recepção de
mensagens. As respostas de confirmações a comandos de NOTIFY e SET são
automaticamente processadas e o valor das propriedades é afectado. Este módulo gera
também automaticamente confirmações/respostas para as mensagens com operações GET e
SET. As aplicações activam eventos que por sua vez vão despoletar o envio de mensagens
cujo procedimento é feito por este módulo (acesso e preenchimento da mailbox, envio e
eventuais retransmissões). Este módulo foi implementado através de uma máquina de estados.
O estado IDLE verifica a existência de mensagens recebidas por tratar. No caso de existirem,
percorre as aplicações de modo a encontrar uma com mensagens e evolui para o estado de
recepção RX_1 onde, testando o valor do bit correspondente ao campo de resposta de
mensagem, identifica o seu tipo – resposta/confirmação ou um comando. Se a mensagem for
uma resposta a um comando SET ou NOTIFY, o evento é anulado caso contrário, a mensagem
é enviada para a aplicação que a deve tratar ou apagar da mailbox regressando a máquina de
estados ao estado IDLE. Se a mensagem não for uma resposta mas sim um comando GET ou
SET, esta será processada e será gerada uma resposta com a devolução do valor da
propriedade ou fazendo a alteração do mesmo, respectivamente. No caso de a mensagem
recebida ser um comando NOTIFY ou uma outra mensagem não normalizada, é deixada na
mailbox e enviada para a aplicação que a deverá tratar convenientemente. Após a recepção, é
retomado o estado IDLE. O envio de uma mensagem de resposta é assegurado pelo estado
REPLY.
Na eventualidade de não existir nenhuma mensagem recebida a aguardar tratamento, é
chamada uma função para verificar se um evento está activo mas não marcado para envio ou
seja, existe a indicação para ser retransmitido e ainda não foi esgotado o contador de
retransmissões. Em caso afirmativo, analisa o temporizador do evento para saber se já foi
atingido, activando nesse caso a flag correspondente para desencadear o envio da mensagem
correspondente, decrementando o número de retransmissões (rápidas ou lentas) e definindo
um novo valor para o temporizador no caso de os contadores ainda não terem esgotado as
retransmissões possíveis. De seguida retorna ao estado IDLE para verificar se existem
aplicações com eventos activos e se a mailbox destas está livre. No caso de ter encontrado
aplicações com eventos activos, avança para o estado TX_1 para enviar a mensagem
correspondente.
O estado TX_1 começa por reverificar se a mailbox da aplicação ainda se encontra livre e
identifica o evento a tratar, começando por aqueles que são relativos a propriedades do tipo
byte. No caso de não encontrar, pesquisa por eventos do tipo word e array. A pesquisa é feita
através de uma função que recebe dois parâmetros: um número de evento para iniciar e outro
para terminar a pesquisa. A função devolve o número do evento quando o tiver encontrado. A
46
mailbox é então reservada e é dada a indicação, através das flags correspondentes, que não
contém uma mensagem de resposta mas sim de comando. Se o número de tentativas de
reenvio de uma mensagem tiver sido esgotado, este estado actualiza o número de eventos
activos (contador geral e por aplicação) passando de seguida para o estado TX_2.
Ao chegar ao estado TX_2 já foi escolhida uma aplicação, seleccionado um evento e reservada
a respectiva mailbox. Aqui é chamada a função para compor a mensagem acedendo a
EEPROM, Figura 29, e adicionando o índice do evento ao endereço de base daquela memória.
O esqueleto da mensagem presente na EEPROM é acedido e copiada para a mailbox para
preencher os campos em falta, avançando-se em seguida para o estado TX_3 onde se vai
chamar uma função do módulo NET para enviar a mensagem.
Figura 29 - Procedimento para obter da EEPROM o esqueleto da mensagem pretendida
A Figura 30 contém um esquema simplificado da máquina de estados implementada para o
módulo MSG.
47
IDLE
RX_1 TX_1
recepção envio
mensagem não
normalizada
(envia para a
aplicação)
RX_1
é necessário
responder
TX_2
TX_3
Escolhida aplicação e
evento para enviar
A mensagem já foi
composta
Figura 30 - Representação simplificada da máquina de estados do módulo MSG
A tabela seguinte contém a lista de funções que constituem o módulo MSG.
Tabela 6 - Funções implementadas no módulo MSG
Função Descrição
MSG_compose_msg() Lê o esqueleto da mensagem da EEPROM e faz a
composição da mesma para envio
MSG_process_event_timeouts() Verifica se um evento está activo mas não marcado para
envio e controla as retransmissões
MSG_tx_abort(app_index, app_mask) Sinaliza que o envio da mensagem da aplicação
app_index foi abortado e activa a flag correspondente
para que a mensagem seja novamente gerada
MSG_find_event(start_event, limit) Procura um evento marcado para envio. Inicia a pesquisa
em start_event e termina em limit
MSG_init() Faz a inicialização da máquina de estados do módulo
MSG
MSG_task() Implementa a máquina de estados que trata da recepção
e envio de mensagens. Trata também das
retransmissões de mensagens que não foram
confirmadas.
48
5.3 Arquitectura das aplicações DomoBus implementadas
Com a realização deste trabalho, as aplicações deixaram de fazer o envio, recepção e
tratamento de mensagens normalizadas – responsabilidade do módulo MSG – e passaram
apenas a conter uma máquina de estados que implementa a sua funcionalidade.
Após a leitura do sensor e obtenção de um novo valor, a aplicação tem de activar o evento
correspondente no caso de o valor lido ser válido. Este aspecto surgiu na actual
implementação pois anteriormente assumia-se sempre que os valores lidos eram válidos, o que
nem sempre correspondia à realidade. Adicionalmente, neste momento o sistema está
preparado para suportar propriedades do tipo byte, word e array e não apenas do tipo byte
como acontecia anteriormente. O pseudo-código seguinte permite descrever de uma forma
genérica uma aplicação DomoBus, ilustrando-se a leitura de um sensor.
Código 1 – Estrutura genérica de uma aplicação DomoBus (leitura de sensor)
if(PROP_set_byte_index(device_index, PROP_NUM_0)) /* define índices*/
{
/* erro do dispositivo ou propriedade*/
}
ler sensor "device_index";
if( ...invalid...) /* valor inválido */
{
if(PROP_value_is_invalid() == 0) /* valor anterior era válido*/
{
PROP_value_is_invalid(); /* definer valor como inválido */
PROP_set_event(_REPEAT_3_TIMES); /* para enviar mensagem */
}
}
else /* valor lido é válido */
{
if(PROP_value_is_invalid()) /* valor anterior era invalid */
{
PROP_set_value_valid();
PROP_set_byte(value);
PROP_set_event(_REPEAT_3_TIMES); /* para enviar mensagem*/
}
else /* valor anterior era válido */
{
old_value = PROP_get_byte();
if(value != old_value)
{
PROP_set_byte(value);
PROP_set_event(_REPEAT_3_TIMES); /*para enviar msg*/
}
}
}
49
Como se observa, a estrutura das aplicações ficou bastante simplificada e já contemplam a
possibilidade de ocorrer uma falha ou avaria num sensor e terem de lidar com valores
inválidos. Neste momento é também possível lidar de uma forma simplificada com uma gama
variada de sensores e actuadores pois já são suportados todos os tipos de propriedades
possíveis do DomoBus e não apenas valores do tipo byte.
51
6 Avaliação e testes
6.1 Impacto da adição de um campo novo nas tramas
Com a realização deste trabalho alterou-se o formato do campo de dados das tramas
DomoBus passando este a indicar para além do dispositivo, da propriedade e do valor, um
número de sequência do evento. Os motivos que levaram a esta implementação estão
relacionados com o correcto emparelhamento da resposta com a mensagem e a presente
secção pretende analisar o impacto que a abordagem teve no tempo de transmissão da trama
e no respectivo débito da comunicação.
Podendo as propriedades ser de três diferentes tipos relacionados com a dimensão do valor
que lhes diz respeito, a dimensão do campo de dados da trama é variável. Para efeitos de
testes contemplaram-se os três tipos de propriedades (byte, word e array).
Na presente abordagem o campo de dados da trama ocupa 40 bits1 no caso de ser referente
ao valor de uma propriedade do tipo byte (inclui número de sequência, dispositivo, propriedade
e valor). Se a propriedade for do tipo word, serão ocupados 50 bits e 80 bits para uma
propriedade do tipo array de quatro elementos (notar que um valor do tipo array ocupa N+1
bytes, sendo N o número de bytes que contém, e utiliza um byte extra para indicar o número de
elementos do array). As tabelas seguintes contêm os resultados obtidos para a simulação e
considerando dois tempos de acesso ao meio aleatórios (1.5 e 7.5 unidades de tempo de 200
µs) referentes a dois níveis de tráfego diferentes – reduzido e elevado.
Tabela 7 - Tempo de trama e débito para tráfego reduzido e para os vários tipos de propriedade
Tempo de acesso aleatório médio: 1.5 * 200 µs = 0.3 ms
Byte Word Array (4 elementos)
Tempo de trama
sem número de sequência (ms)
8.2
8.8
10.3
Débito (msg/s) 121.5 114,3 97.0
Tempo de trama
com número de sequência (ms)
8.8
9.3
10.8
Débito (msg/s) 114.3 107.9 92.3
Variação percentual do débito -6.0 % -5.6 % -4.8 %
1 Recorda-se que cada byte útil corresponde ao envio de 10 bits na linha de comunicação.
52
Figura 31 - Comparação do débito de tramas com e sem número de sequência no campo de dados (tráfego reduzido)
Tabela 8 - Tempo de trama e débito para tráfego elevado e para os vários tipos de propriedade
Tempo de acesso aleatório médio: 7.5 * 200 µs = 1,5 ms
Byte Word Array (4 elementos)
Tempo de trama
sem número de sequência (ms)
9.4
10.0
11.5
Débito (msg/s) 106.1 100.5 86.0
Tempo de trama com número de sequência
(ms)
10.0
10.5
12.0
Débito (msg/s) 100.5 95.5 83.1
Variação percentual do débito
-5.2 % -5.0 % -4.3 %
53
Figura 32 - Comparação do débito de tramas com e sem número de sequência no campo de dados (tráfego elevado)
É possível verificar que ao acrescentar o número de sequência no campo de dados da trama
DomoBus o débito tem uma redução entre 4.3% e 6.0%. Esta abordagem abre no entanto
caminho a novas funcionalidades: o byte de número de sequência pode ser eventualmente
utilizado numa implementação futura para semente de cifra um algoritmo de encriptação de
dados. A robustez da comunicação entre as aplicações sai também beneficiada porque a
unicidade do número de sequência, elimina as situações em que havia a possibilidade de com
uma falha na transmissão, se confundirem as respostas às mensagens e se apagarem eventos
com uma mensagem antiga.
6.2 Utilização de respostas só com o número de sequência
As tramas DomoBus possuem um bit que indica se a mesma é uma mensagem de resposta.
No caso das mensagens referentes a uma operação SET ou NOTIFY, a resposta enviada é
exactamente igual à mensagem que lhe deu origem, com excepção do bit de resposta que
deverá estar activo. Se a mensagem enviada for relativa a um comando GET, a mensagem de
resposta terá obviamente de conter o valor da propriedade a que diz respeito, para além do bit
de resposta activo.
A simulação realizada na presente secção pretende verificar o impacto resultante da introdução
de tramas contendo apenas o número de sequência, surgindo como resposta a tramas com os
quatro campos e comparar com aquelas que contêm apenas o dispositivo, a propriedade e o
valor. Fez-se a simulação para os cenários de tráfego reduzido e elevado.
54
Tabela 9 - Tempo de trama e débito para tráfego reduzido para as condições descritas na secção 6.2 (tráfego reduzido)
Tempo de acesso aleatório médio: 1.5 * 200 µs = 0.3 ms
Byte Word Array (4 elementos)
Tempo de trama e resposta
sem número de sequência (ms)
16.5
17.5
20.6
Débito (msg/s) 60.8 57.1 48.5
Tempo de trama e resposta apenas
com número de sequência (ms)
15.9
16.5
18.0
Débito (msg/s) 62.7 60.8 55.5
Variação percentual do débito
+3.3 % +6.3 % +14.5 %
Figura 33 - Comparação do débito utilizando mensagens nas condições descritas na secção 6.2 (tráfego reduzido)
55
Tabela 10 - Tempo de trama e débito para tráfego elevado para as condições descritas na secção 6.2 (tráfego elevado)
Tempo de acesso aleatório médio: 7.5 * 200 µs = 0.3 ms
Byte Word Array (4 elementos)
Tempo de trama e resposta
sem número de sequência (ms)
18.9
19.9
23.0
Débito (msg/s) 53.0 50.3 43.4
Tempo de trama e resposta apenas
com número de sequência (ms)
18.3
18.9
20.4
Débito (msg/s) 54.5 53.0 49.0
Variação percentual do débito
+2.8 % +5.5 % +12.8 %
Figura 34 - Comparação do débito utilizando mensagens nas condições descritas na secção 6.2 (tráfego elevado)
Verifica-se que o débito da comunicação sai beneficiado com a introdução de respostas com
apenas o número de sequência em comparação com respostas com a indicação dos campos
de dispositivo, propriedade e valor com um aumento do débito superior a 14.5%.
56
6.3 Impacto da utilização de respostas super-prioritárias
O sistema DomoBus prevê a existência tramas de três prioridades diferentes – normais,
prioritárias e super-prioritárias – que diferem no tempo de acesso ao meio físico (fixo e
aleatório). Com o presente trabalho, decidiu-se optar pela utilização de tramas super-
prioritárias como resposta a tramas de prioridade normal.
De modo a determinar o impacto desta abordagem, simulou-se o envio de uma trama de
prioridade normal sem envio do número de sequência (apenas os campos dispositivo,
propriedade e valor) e resposta normal com os mesmos campos enviados. Fez-se a
comparação com o envio de uma mensagem de prioridade normal com os campos de número
de sequência, dispositivo, propriedade e valor e com resposta super-prioritária com apenas o
número de sequência. À semelhança das simulações das secções anteriores, os testes foram
efectuados para as situações de tráfego reduzido e elevado. Os resultados são visíveis nas
tabelas e gráficos seguintes.
Tabela 11 – Comparação do tempo de trama e débito para a situação descrita na secção 6.3 (tráfego reduzido)
Tempo de acesso aleatório médio: 1.5 * 200 µs = 0.3 ms
Byte Word Array (4 elementos)
Tempo de trama e resposta
sem número de sequência (ms)
16.5
17.5
20.6
Débito (msg/s) 60.8 57.1 48.5
Tempo de trama e resposta super-
prioritária apenas
com número de sequência (ms)
14.9
15.5
17.0
Débito (msg/s) 66.9 64.7 58.8
Variação percentual do débito
+10.2 % +13.2 % +21.2 %
57
Figura 35 - Comparação do débito para a situação descrita na secção 6.3 (tráfego reduzido)
Tabela 12 - Tempo Comparação do tempo de trama e débito para a situação descrita na secção 6.3 (tráfego elevado)
Tempo de acesso aleatório médio: 1.5 * 200 µs = 0.3 ms
Byte Word Array (4 elementos)
Tempo de trama e resposta
sem número de sequência (ms)
18.9
19.9
23.0
Débito (msg/s) 53.0 50.3 43.4
Tempo de trama e resposta super-
prioritária apenas
com número de sequência (ms)
17.3
17.9
19.4
Débito (msg/s) 57.7 56.0 51.5
Variação percentual do débito
+8.8 % +11.4 % +18.6 %
58
Figura 36 - Comparação do débito para a situação descrita na secção 6.3 (tráfego elevado)
A introdução de respostas super-prioritárias acrescenta melhorias muito significativas em
termos de débito, que pode atingir aumentos de débito superiores a 20%. Esta abordagem
associada a respostas com o envio de apenas o número de sequência, permite melhorar ainda
mais o débito de comunicação.
6.4 Melhorias introduzidas com o ajuste do tempo de acesso ao meio
Durante o tempo de funcionamento do sistema é expectável que o tráfego no meio de
comunicação seja variável. Com o aumento do número de nós a transmitirem dados, o número
médio de colisões aumenta também e torna-se necessário tomar medidas para melhorar a
eficiência da comunicação e optimizar a utilização da largura de banda disponível. Por outro
lado, é igualmente necessário reajustar o tempo de acesso ao meio quando houver uma
melhoria das condições de transmissão.
Um nó quando pretende iniciar uma transmissão tem de aguardar um tempo fixo para aceder
ao meio e um tempo aleatório para evitar que colida com outro nó que também esteja a tentar
transmitir. Na presente implementação, o tempo de acesso aleatório correspondente a um
intervalo de 3, 7 ou 15 unidades de 200 µs consoante o nível de tráfego - reduzido, médio e
elevado, respectivamente. Este tempo é aumentado quando é detectada uma colisão no
processo de envio e é reduzido quando é notada uma melhoria na fluidez da rede – recebido
um ACK a uma mensagem enviada.
59
Apesar de não ser possível medir com rigor a melhoria que esta implementação introduziu
apenas com simulações, em termos teóricos o número de colisões vai diminuir e a utilização da
largura de banda disponível vai ser optimizada porque vai existir uma gama ajustável de
intervalos de tempo em que a comunicação pode ser efectuada.
6.5 Análise dos resultados
A opção pela introdução do número de sequência nas mensagens foi feita com o objectivo de
dar suporte a uma comunicação mais fiável e permitir eliminar mensagens duplicadas ou
confundir respostas atrasadas com a que se espera. Considere-se o seguinte exemplo: um
evento gerou a mensagem M1 e enviou-a, a resposta R1 foi gerada mas não foi possível enviá-
la. Se um novo evento gerar uma mensagem nova - M2 - e esta for enviada, na eventualidade
de se receber a resposta R1 pode-se erradamente considerar que está a confirmar a
mensagem M2. A introdução do número de sequência nas mensagens pretende mitigar esta
situação devido à unicidade do valor em relação aos eventos activos. A utilização do número
de sequência pode também abrir caminho à sua utilização como semente de cifra de um
algoritmo de encriptação.
Como desvantagem, a utilização do número de sequência diminui o débito da rede entre 4.3%
e 6.0% mas considerando que todas as mensagens têm de ser respondidas, a introdução de
mensagens de resposta que enviam apenas o número de sequência no campo de dados da
trama, traz melhorias no débito entre 2.8% e 14.5% (par mensagem e resposta).
Adicionalmente, a utilização de respostas super-prioritárias permite melhorar ainda mais o
débito da comunicação (melhoria entre 8.8% e 21.2%).
61
7 Conclusões
Com a presente dissertação analisou-se em detalhe o sistema DomoBus que pretende ser um
sistema fiável, robusto e de baixo custo para Domótica. O contributo deste trabalho centrou-se
no software para os Módulos de Controlo, os quais são constituídos por sistemas embebidos
que utilizam o microcontrolador AT90S8515 que possui diminutos recursos, particularmente em
termos de memória, mas tem um custo muito baixo. Os Módulos de Controlo são responsáveis
pela ligação aos sensores e actuadores permitindo monitorizar e actuar sobre o meio
envolvente.
Nesta tese foi seguido o modelo DomoBus que descreve os diferentes dispositivos domóticos
através de um conjunto de propriedades que podem ser lidas ou modificadas usando um
conjunto normalizado de mensagens. Foi desenvolvida uma nova arquitectura de software para
os Módulos de Controlo que permitiu simplificar o desenvolvimento de aplicações domóticas e
ao mesmo tempo oferecer características multi-tarefa e suporte fiável para as comunicações. A
nova abordagem revelou-se mais robusta e compacta em termos de código face à versão
anterior pois centralizou todo o tratamento de mensagens, o que antes tinha de ser realizado
aplicação a aplicação. Em particular, aspectos como o envio de respostas e o tratamento de
certas mensagens passaram a ser feitas de forma automática pelo módulo MSG, sem a
necessidade de intervenção das aplicações, o que simplifica bastante o seu desenvolvimento.
Este aspecto permite também poupar bastante memória, que é um recurso muito escasso nos
microcontroladores usados.
O módulo MSG trata ainda dos aspectos ligados à construção das mensagens a partir do
índice de um dado evento e tendo como base esqueletos das mensagens presentes em
EEPROM. É também o módulo MSG que trata das retransmissões de mensagens caso não
sejam recebidas as respectivas respostas. Para tal recorre-se ao mecanismo de eventos
descrito e à capacidade de facilmente voltar a gerar as mensagens, evitando a abordagem
típica de guardar em memória as mensagens enviadas e cuja resposta está pendente, o que
era incomportável por falta de memória.
A implementação realizada permite lidar com valores inválidos resultantes de erro na leitura ou
da avaria dos sensores, o que não se verificava anteriormente. Adicionalmente estão já
contemplados todos os tipos de valores de propriedades suportados pelo DomoBus – Byte,
Word e Array – sendo o seu tratamento feito de forma transparente recorrendo ao módulo
PROP.
Foi também implementado um novo módulo de comunicações que permitiu aumentar a
fiabilidade da comunicação introduzindo retransmissões, minimizando as colisões e
controlando o fluxo de modo a optimizar a utilização da largura de banda disponível. É agora
62
possível ter uma percepção do estado da rede tomando as medidas necessárias para manter
uma transmissão robusta. Os objectivos propostos foram atingidos e foram introduzidos
mecanismos para melhorar as respostas às tramas (envio do número de sequência para além
do dispositivo, da propriedade e do valor, possibilidade de resposta usando apenas o número
de sequência e introdução de respostas super-prioritárias). Foi também acrescentado um
método ajustável para controlar o tempo de acesso ao meio e assim evitar colisões e ainda um
mecanismo para controlar o débito do canal de modo a evitar congestionamento. As melhorias
introduzidas foram simuladas recorrendo a fórmulas de cálculo, gráficos e tabelas e a um
simulador pois é muito difícil quantificá-las na prática. Foi possível verificar que o envio do
número de sequência nas tramas faz baixar o débito da comunicação mas em contrapartida
permite um emparelhamento mais fiável das respostas às mensagens na eventualidade da
ocorrência de uma falha no envio. Adicionalmente, a introdução de respostas contendo apenas
o número de sequência do evento e super-prioritárias, traz benefícios e aí o débito é
claramente beneficiando quando se efectua a comparação com a implementação anterior em
que as respostas tinham uma prioridade normal e os dados eram integralmente enviados. Os
mecanismos de acesso ao meio e de controlo de débito da comunicação acrescentaram
igualmente melhorias pois permitiram reduzir os problemas associados ao aumento do número
de colisões – associado ao incremento do número de nós a transmitir – e ainda reduzir o
congestionamento verificado em situações de tráfego superior à capacidade do canal.
Por último destaca-se a generalidade e portabilidade da solução desenvolvida que permite
oferecer mecanismos multi-tarefa com características de tempo-real e comunicação fiável
usando uma quantidade mínima de memória de dados (512 bytes) e reduzida memória de
código (8 Kbytes). O software desenvolvido necessita apenas de recursos hardware básicos do
microcontrolador, nomeadamente um temporizador e uma UART para a comunicação,
podendo pois ser adaptado à generalidade dos microcontroladores disponíveis, incluindo os de
menor custo.
7.1 Trabalho futuro
Após a realização deste trabalho continua a existir espaço para introduzir melhorias na solução
domótica DomoBus. Refere-se em particular melhoramentos ao nível da segurança com a
introdução de encriptação do campo de dados das tramas. Salienta-se que o facto de ter sido
introduzido o campo ‘S’ (número de sequência) nas tramas abre a possibilidade de no futuro
este campo poder vir a ser usado como semente de um algoritmo de cifra que se aplicaria aos
campos seguintes. Deste modo poder-se-ia ter a garantia de que elementos externos ao
sistema não teriam acesso ao estado dos dispositivos nem teriam a capacidade de alterar esse
mesmo estado.
A modificação do formato das tramas dificultou a realização de testes que permitiriam
quantificar na prática as melhorias introduzidas com o trabalho desenvolvido, pois isso impediu
63
que pudesse ser usado um gateway já existente para ligação dos módulos a um PC. Sem essa
infra-estrutura para, de um modo fácil, enviar mensagens para os módulos e monitorizar as
mensagens geradas por estes, não foi possível efectuar uma quantificação de aspectos como o
número de colisões, o número de retransmissões, o número de mensagens confirmadas, o
débito efectivo atingido no meio de comunicação e o impacto dos novos mecanismos
desenvolvidos. Em particular não foi possível, por exemplo, identificar o impacto de ajustes de
alguns dos parâmetros como o grau de aumento do valor aleatório aquando da ocorrência de
uma colisão, ou em que medida o sistema é rápido a adaptar-se a variações significativas de
tráfego. A adaptação necessária do software do gateway e do respectivo software no PC
relevou-se bastante complexa e morosa, o que implicaria o prolongamento significativo do
presente trabalho, situação se mostrou incompatível com compromissos entretanto já
assumidos. Adicionalmente, existia ainda a restrição de o número de módulos de controlo
disponíveis ser bastante reduzido, não sendo viável a realização de novos módulos num prazo
de tempo curto, sem os quais não seria possível o teste efectivo dos mecanismos de controlo
de congestionamento. Futuramente será pois desejável a realização de testes exaustivos do
sistema que permitam avaliar o desempenho dos mecanismos implementados e possibilitem o
seu ajuste, o que deverá envolver, idealmente, um número bastante elevado de módulos de
controlo. Desse modo seriam obtidos resultados mais rigorosos e fiáveis face às simulações
realizadas.
65
8 Referências
[1] António Manuel L. Quadros Flores, “A criação de valor no binómio: “casa inteligente” / consumidor”, 9th SPANISH PORTUGUESE CONGRESS ON ELECTRICAL ENGINEERING, Julho 2005.
[2] Renato Nunes, “Análise Comparativa de Tecnologias para Domótica”, JEACI 2002- III Jornadas de Engenharia de Automação, Controlo e Instrumentação, EST Setúbal, Maio 2002.
[3] Danny Briere, Pat Hurley, Smart Homes for Dummies 3rd
Edition, Wiley Publishing, 2007
[4] José Alves Marques, Paulo Guedes, Tecnologia de Sistemas Distribuídos, FCA, 1998.
[5] EIB (1999) System Specifications - Release 3.0.
[6] H. Merz, T. Hansemann, C. Hübner, Building Automation, Springer, 2009.
[7] Andrew S. Tanenbaum, Modern Operating Systems, Prentice Hall, 1996.
[8] Gernot Heiser, "Microkernels rule!", http://www.embedded.com/ . Acedido em Julho de 2010.
[9] Echelon, “Introduction to the LonWorks® Platform - Revision 2”, 2009.
[10] UPnP, “Understanding Universal Plug and Play”, 2000.
[11] Microchip “Controller Area Network (CAN) Basics”, 1999.
[12] PROFIBUS, http://www.profibus.com/. Acedido em Setembro de 2010.
[13] Philip Levis “TinyOS Programming”, 2006.
[14] eCos, “eCos User Guide”, eCosCentric Ltd ,2003.
[15] Contiki, “The Contiki Operating System”, 2010.
[16] RTOS, “Real-Time Operating Systems - RTOS”, 2006.
[17] FreeRTOS, http://www.freertos.org/FAQMem.html/. Acedido em Julho de 2010.
[18] ATMEL, “AT90S8515 Datasheet”, 1998
[19] Renato Nunes, “DomoBus - A New Approach to Home Automation”, in: 8CLEEE - 8th International Congress on Electrical Engineering, Portugal, pp.2.19-2.24, Julho 2003.
[20] Renato Nunes “Implementing Tiny Embedded Systems With Networking Capabilities”, IADIS International Conference on Applied Computing 2005, Algarve, Portugal, Fevereiro 2005.
[21] James F. Kurose, Keith W. Ross Computer Networking – A Top-Down Approach Featuring the Internet (Third Edition), Pearson Education, 2005.
[22] Dogan Ibrahim, Advanced PIC Microcontroller Projects in C, Newnes, 2008.
[23] Renato Nunes, “Especificação XML de um Sistema DomoBus”, Instituto Superior Técnico, Dezembro de 2006.
[24] Renato Nunes, "Análise Comparativa de Quatro Tecnologias Domóticas", Instituto Superior Técnico, 2010.
