Master Thesis

UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Concepção e Desenvolvimento
de uma
Rede Domótica
Pedro Miguel Florindo Miguens Matutino

(Licenciado)
Dissertação para a obtenção do Grau de Mestre em

Engenharia Electrotécnica e de Computadores
DOCUMENTO PROVISÓRIO
Novembro 2001
UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Concepção e Desenvolvimento
de uma
Rede Domótica
Pedro Miguel Florindo Miguens Matutino

(Licenciado)
Dissertação para a obtenção do Grau de Mestre em

Engenharia Electrotécnica e de Computadores
DOCUMENTO PROVISÓRIO
Novembro 2001
Dedico
esta tese
à minha esposa
e à minha família.
Resumo
As redes Domóticas têm vindo a assumir um papel de importância crescente em

diversas áreas, nomeadamente nos edifícios do sector terciário, e têm vindo a expandir-
se ao sector habitacional. O principal objectivo deste trabalho é o desenvolvimento de
uma rede domótica de baixo custo e de fácil implementação para suporte a aplicações de
automação na habitação e nos edifícios.
Com base nas arquitecturas conhecidas propõe-se uma nova arquitectura para um
sistema domótico e uma nova estrutura para os seus nós. Com base na arquitectura
proposta implementou-se um protótipo, ao nível do hardware e do software, tendo por
base um microcontrolador de 8 bit de reduzidas capacidades em termos de memória e de
desempenho.
É proposta uma estrutura de software para o sistema e são definidas regras para a
implementação de aplicações. Adicionalmente é feita uma abordagem à
interoperacionalidade dos vários componentes do sistema e sua supervisão integrada.
São analisados os resultados obtidos, quer em termos de desempenho quer em termos de
recursos usados, concluindo-se da sua adequação ao fim proposto e que a rede pode ser
implementada num microcontrolador comum que possua no mínimo um temporizador,
uma UART, cerca de 2 Kbyte de memória de programa e 60 byte de memória de dados.
i
Abstract
Domotic networks have come to undertake a grown role in several areas, namely in
buildings of the tertiary sector, and has come to expand to residence buildings. The
main objective of this work is the development of a simple and low cost domotic
network to support building and home automation applications.
Based on available systems, a new architecture is proposed for a domotic system
offering a new approach for the structure of its nodes. A prototype was implemented, at
the hardware and software levels, using an 8 bit microcontroller with reduced memory
and performance.
A new software architecture for the system nodes is proposed and rules are defined for
the implementation of applications. Additionally, we look at interoperability issues and
support for an integrated supervision of the system.
The results of our implementation are assessed and we conclude that the proposed
network satisfies our objectives and that it can be implemented on a common
microcontroller that offers at least one timer, one UART, 2 Kbyte of program memory
and 60 byte of data memory.
ii
Palavras-chave
§ Domótica
§ Redes de controlo
§ Aplicações para Domótica
§ Interoperacionalidade
§ Arquitectura de Rede Domótica
§ Edifícios Inteligentes
Keywords
§ Domotics
§ Control networks
§ Domotic applications
§ Interoperability
§ Domotic network architecture
§ Intelligent buildings
iii
Agradecimentos
À minha esposa e à minha família pelo apoio moral e compreensão que me deram ao
longo do tempo que durou o mestrado, em especial pelos últimos meses pois não lhes
prestei a atenção que mereciam.
Desejo expressar o meu especial agradecimento ao Prof. Renato Jorge Nunes pela
confiança demonstrada ao assumir a orientação desta dissertação, pelo apoio e paciência
que demonstrou ter ao longo dos vários anos que trabalhei sob sua orientação, e pela sua
disponibilidade quando me surgiram dúvidas.
Aos meus colegas e amigos que me têm apoiado e ajudado a passar alguns momentos
difíceis ao longo destes anos.
E a todas as pessoas que de alguma forma contribuíram para que este trabalho fosse
concluído, em especial aos colaboradores do IST e do INESC-ID.
iv
Índice
1 INTRODUÇÃO 1
1.1 ENQUADRAMENTO 2
1.2 OBJECTIVOS E CONTRIBUTOS 3
1.3 ORGANIZAÇÃO DA TESE 3
2 ESTADO DA ARTE 5
2.1 INTRODUÇÃO 6
2.2 CEBUS 9
2.2.1 O PROTOCOLO CEBUS E O MODELO OSI 11
2.2.2 MODELO DE COMUNICAÇÃO DISPOSITIVO A DISPOSITIVO 12
2.2.3 FORMATO DA TRAMA 13
2.2.4 ACESSO AO CANAL 13
2.3 EIB 15
2.3.1 TOPOLOGIA 15
2.3.2 ESTRUTURA DOS NÓS 15
2.3.3 TRAMA 16
2.4 LONWORKS 19
2.4.1 ENDEREÇAMENTO 19
2.4.2 CAPACIDADES DO SISTEMA 20
2.4.3 TIPOS DE MENSAGENS 20
3 PROPOSTA 23
3.1 INTRODUÇÃO 24
3.2 ARQUITECTURA PROPOSTA 26
3.2.1 TOPOLOGIA 26
3.3 P ROTOCOLO DE REDE 30
3.3.1 TRAMA 30
v
3.4 CAPACIDADES DA REDE PROPOSTA 36
4 DETALHES DE IMPLEMENTAÇÃO 39
4.1 INTRODUÇÃO 40
4.2 NÍVEL FÍSICO DO PROTOCOLO 41
4.3 METODOLOGIA 42
4.4 ESTRUTURA E FUNCIONAMENTO DO SOFTWARE DE REDE 44
4.5 M ÁQUINA DE ESTADOS DA APLICAÇÃO DE REDE 45
4.6 ESTRUTURA DE DADOS 46
4.6.1 DUAS CAIXAS DE CORREIO POR APLICAÇÃO 47
4.6.2 UMA ÚNICA CAIXA DE CORREIO POR APLICAÇÃO 48
4.6.3 COMPARAÇÃO 50
4.7 APLICAÇÕES 51
4.8 RETRANSMISSÕES 53
4.9 IDENTIFICADOR ÚNICO 53
4.10 TABELA DE ENDEREÇOS 54
4.10.1 ENDEREÇOS SEPARADOS POR APLICAÇÃO 55
4.10.2 ENDEREÇOS VIRTUAIS 57
4.10.3 COMPARAÇÃO 58
4.11 APLICAÇÃO DE SISTEMA 59
4.12 MECANISMO DE DECISÃO DE ENVIO 59
4.13 BRIDGE 61
4.14 GATEWAY 62
4.15 RECURSOS UTILIZADOS PELA APLICAÇÃO DE REDE 63
5 COMPARAÇÃO E RESULTADOS EXPERIMENTAIS 65
5.1 INTRODUÇÃO 66
5.2 COMPARAÇÃO 66
5.2.1 CEBUS 66
5.2.2 EIB 66
5.2.3 LONWORKS 67
5.2.4 REDE PROPOSTA 67
5.3 RESULTADOS EXPERIMENTAIS 68
vi
5.3.1 TEMPOS DE PROCESSAMENTO 69
5.3.2 MEDIDAS DE DESEMPENHO DA REDE 71
6 INTEROPERACIONALIDADE 76
6.1 INTRODUÇÃO 77
6.2 MODELO DE INTERACÇÃO 77
6.3 CENÁRIOS 80
6.4 CONTROLO DE FLUXO DE INFORMAÇÃO 81
7 CONCLUSÕES 82
7.1 CONCLUSÕES 83
7.2 DESENVOLVIMENTOS FUTUROS 84
BIBLIOGRAFIA 86
vii
Índice de Figuras
Figura 2.1 - Distribuição geográfica dos principais sistemas............................................. 7

Figura 2.2 - Ligações entre diferentes meios de transmissão........................................... 10
Figura 2.3 - Camadas constituintes de um dispositivo CEBus......................................... 11
Figura 2.4 - Protocolo CEBus vs. Modelo OSI ................................................................. 11
Figura 2.5 - Comunicação entre dispositivos .................................................................... 12
Figura 2.6 - Formato da trama CEBus ............................................................................... 13
Figura 2.7 - Ilustração do mecanismo de contenção......................................................... 14
Figura 2.8 - Formato da trama EIB .................................................................................... 16
Figura 2.9 - Estrutura de uma palavra EIB ........................................................................ 18
Figura 2.10 - Tempo de palavra EIB.................................................................................. 18
Figura 2.11 - Tempo entre mensagens EIB ....................................................................... 18
Figura 3.1 - Exemplo de uma instalação distribuída......................................................... 25
Figura 3.2 - Exemplo de uma instalação da rede proposta............................................... 26
Figura 3.3 - Agrupamento de nós designado por Ilha ...................................................... 27
Figura 3.4 - Sistema de pequena dimensão, com um só barramento............................... 27
Figura 3.5 - Arquitectura proposta no caso de um sistema de grande dimensão ............ 28
Figura 3.6 - Arquitectura proposta no caso de um sistema de média dimensão ............. 28
Figura 3.7 - Arquitectura proposta com um único troço................................................... 29
Figura 3.8 - Trama proposta ............................................................................................... 30
Figura 3.9 - Endereçamento................................................................................................ 31
Figura 3.10 - Modelo OSI vs. modelo proposto................................................................ 32
Figura 3.11 - Descrição da trama - Campo de controlo.................................................... 33
Figura 3.12 - Descrição do campo de controlo.................................................................. 33
Figura 3.13 - Comunicação entre duas aplicações ............................................................ 34
Figura 3.14 - Tempo de contenção..................................................................................... 36
Figura 3.15 - Gráfico das capacidades da rede proposta .................................................. 38
Figura 4.1 - Esquema de ligações de uma rede EIA-485.................................................. 42
Figura 4.2 - Sistema multitarefa cooperativo .................................................................... 43
Figura 4.3 - Máquina de estados da rede ........................................................................... 45
Figura 4.4 - Estrutura de dados – duas caixas de correio por aplicação .......................... 47
viii
Figura 4.5 - Estrutura de dados - uma única caixa de correio por aplicação................... 49
Figura 4.6 - Endereços separados por aplicação................................................................ 55
Figura 4.7 - Endereços separados por aplicação, exemplo ............................................... 56
Figura 4.8 - Endereços virtuais........................................................................................... 57
Figura 4.9 - Fila de espera de envio de mensagens........................................................... 61
Figura 4.10 - Taxa de ocupação da memória de programa da aplicação de rede............ 63
Figura 4.11 - Taxa de ocupação memória de dados da aplicação de rede ....................... 64
Figura 6.1 - Tabela de mensagens...................................................................................... 79
ix
Índice de Tabelas
Tabela 3-1 - Capacidades teóricas da rede proposta ......................................................... 37

Tabela 4-1 - Tabela de comparação de ocupação da memória - expressões ................... 50
Tabela 4-2 - Tabela de comparação de ocupação da memória - concretização............... 50
Tabela 4-3 - Taxa de ocupação da aplicação de rede........................................................ 63
Tabela 5-1 - Tempo de processamento .............................................................................. 70
Tabela 5-2 - Taxa de ocupação de tempo de processamento ........................................... 70
Tabela 5-3 - Teste com componente aleatória de acesso ao meio e envio de mensagens
com intervalos de 0,5 segundos ................................................................................. 72
Tabela 5-4 - Teste sem componente aleatória de acesso ao meio e envio de mensagens
com intervalos de 0,5 segundos ................................................................................. 73
Tabela 5-5 - Teste com componente aleatória de acesso ao meio e envio de mensagens
sem intervalos.............................................................................................................. 73
Tabela 5-6 - Teste sem componente aleatória de acesso ao meio e envio de mensagens
sem intervalos.............................................................................................................. 74
Tabela 6-1 – Aplicação do modelo genérico a dispositivos comuns ............................... 78
x
Capítulo
1 Introdução
Conteúdo
1.1 ENQUADRAMENTO .................................................................................................... 2
1.2 OBJECTIVOS E CONTRIBUTOS ................................................................................... 3
1.3 ORGANIZAÇÃO DA TESE ........................................................................................... 3
1
Concepção e Desenvolvimento de uma
Rede Domótica Capítulo 1
1.1 Enquadramento
Os sistemas domóticos num futuro próximo virão a ser tão vulgares como os
electrodomésticos que hoje em dia se encontram nas nossas habitações. Para que esta
realidade venha a acontecer o custo deste tipo de sistemas deverá ao longo dos próximos
anos descer substancialmente e deverão ocorrer melhoramentos significativos que
facilitem a sua utilização. As constantes evoluções tecnológicas certamente terão
repercussões nesta área e virão possibilitar o atingir dos melhoramentos desejados.
O custo dos sistemas actuais tem limitado de forma significativa a sua utilização em
larga escala. Além disso, estes ainda se encontram distantes de serem fáceis de
parametrizar e de usar pela generalidade das pessoas.
Os sistemas disponíveis actualmente possuem um domínio de aplicação marcadamente
vocacionado para os grandes e médios edifícios do sector terciário, pois possibilitam,
em particular, uma gestão energética racional, contribuindo para uma redução dos
custos de exploração e de manutenção. Deste modo torna-se possível uma amortização a
médio prazo do investimento realizado.
Nas habitações o objectivo destes sistemas visa preferencialmente o melhoramento do
conforto e da segurança, ficando em segundo plano a gestão de recursos energéticos.
Assim, as possíveis poupanças energéticas são menos significativas pelo que a
amortização do sistema só poderá ser esperada a longo prazo.
Neste contexto, o presente trabalho tem por objectivo o desenvolvimento de um sistema
domótico que procura colmatar aspectos menos positivos dos sistemas actuais,
particularmente no que toca aos custos e à capacidade de interoperação.
2
1.2 Objectivos e contributos
Analisar e criticar algumas das soluções comercias mais divulgadas e propor uma nova
abordagem.
Desenvolver uma rede domótica de baixo custo e facilmente implementável usando um
microcontrolador comum e outros componentes de fácil acesso.
Propor uma nova arquitectura de sistema domótico e definir regras para a construção
dos nós e implementação de aplicações.
Efectuar uma abordagem à interoperacionalidade entre dispositivos por forma a dar
suporte a uma supervisão integrada de todo o sistema.
O presente trabalho dá um contributo para a área da domótica esperando-se que possa

ter repercussões em termos da divulgação e expansão dos sistemas domóticos. Em
particular, é desenvolvido um sistema simples e de baixo custo, facilmente replicável, e
que se constitui como uma plataforma onde é fácil ensaiar novas ideias e soluções. Esta
plataforma permite oferecer um ambiente excelente de experimentação e ser uma fonte
de aprendizagem para futuros interessados neste domínio.
Salienta-se a proposta de uma arquitectura de software para os nós do sistema domótico
que é bastante flexível, facilmente implementável num microcontrolador comum e que
oferece um ambiente multitarefa.
É ainda dado um contributo relativamente à interacção entre aplicações com vista a
favorecer a sua interoperacionalidade e possibilitar uma gestão integrada do sistema
global.
1.3 Organização da tese
A tese encontra-se organizada em 7 capítulos. No capítulo 2 descrevem-se as

tecnologias mais relevantes disponíveis comercialmente, com particular ênfase ao nível
do protocolo de rede e filosofia de sistema.
No capítulo 3 propõe-se uma arquitectura de sistema domótico e detalha-se o protocolo
de rede a utilizar.
3
No capítulo 4 descrevem-se os detalhes de implementação do protocolo, define-se a

estrutura de software dos nós do sistema e os mecanismos oferecidos de suporte à
construção de aplicações e à sua interacção.
No capítulo 5 faz-se uma breve comparação entre a rede proposta e as redes descritas no
capítulo 2 e procura-se analisar aspectos de desempenho do sistema proposto, sendo
discriminados os testes efectuados e tecendo-se alguns comentários críticos.
No capítulo 6 abordam-se aspectos ligados à interoperacionalidade das aplicações e
suporte a uma gestão integrada.
Por fim apresentam-se conclusões, indicando-se os resultados mais significativos que
foram obtidos e propondo-se desenvolvimentos futuros.
4
Capítulo
2 Estado da Arte
Conteúdo
2.1 INTRODUÇÃO ............................................................................................................ 6
2.2 CEBUS ...................................................................................................................... 9
2.3 EIB.......................................................................................................................... 15
2.4 LONWORKS ............................................................................................................ 19
5
2.1 Introdução
O termo Domótica está associado à automatização de habitações e a sua origem

aparenta provir da palavra francesa Domotique. A este conceito estão associadas, em
língua inglesa, as designações Home Automation, Smart Home e Intelligent Home.
Existe um paralelo entre domótica e edifícios inteligentes, havendo objectivos comuns
embora com diferentes ênfases. Enquanto numa habitação o ponto mais importante é o
conforto, nos edifícios o aspecto mais relevante é a gestão dos recursos energéticos. Por
outro lado, os edifícios são funcionalmente mais complexos e envolvem um grande
número de utilizadores. A sua gestão está normalmente a cargo de pessoas
especializadas. Na habitação o panorama é diferente pois o número de utilizadores é
reduzido e são estes que normalmente gerem o sistema. Espera-se assim que os sistemas
domóticos sejam o mais simples possível.
As funcionalidades mais importantes num sistema domótico são:
§ automatização doméstica com vista a um maior conforto
§ segurança (detecção de intrusão)
§ protecção (detecção de incêndio, fugas de gás, fugas de água, etc.)
§ monitorização dos consumos e gestão de energia
A domótica despertou um grande interesse em diversos grupos económicos, tendo

aparecido vários sistemas abertos e não proprietários. Eles possuem diferentes
características e diferentes posicionamentos no mercado, estando distribuídos por zonas
de influência no globo terrestre.
Referem-se em seguida as principais tecnologias intervenientes na domótica e na
automação de edifícios. Nos Estados Unidos os principais sistemas são o X-10, o
CEBus (Consumer Electronics Bus) e o LonWorks (também designado por vezes
por LonTalk visto este ser o nome do protocolo utilizado). Na Europa existem o
BatiBus, o EIB (European Installation Bus) e o EHS (European Home System). No
Japão temos o HBS (Home Bus System).
6
Figura 2.1 - Distribuição geográfica dos principais sistemas
Os sistemas que demonstram uma maior penetração no mercado habitacional e que de

alguma forma competem entre si são o CEBus, o EIB, o LonWorks e o X-10, embora
este último não possa se comparado com os outros sistemas devido às suas limitações
face aos outros. O X-10 encontra-se mais vocacionado para sistemas do tipo "faça você
mesmo". No mercado Norte Americano este tipo de dispositivos está muito divulgado
sendo comum encontrá-los até em supermercados.
O X-10 é um sistema pouco fiável pois é facilmente afectado pelo ruído eléctrico uma
vez que usa a instalação eléctrica existente nas habitações como meio de comunicação.
Além disso, o ritmo de transmissão é bastante inferior aos outros sistemas, demorando
cerca de 1 segundo a transmitir uma trama. A maioria dos dispositivos só tem
comunicação unidirecional.
O CEBus é uma norma Americana produzida pela EIA (Electronics Industries

Association). O comité CEBus foi criado em 1984 com o objectivo de normalizar os
sinais de infravermelhos utilizados pelos comandos remotos dos aparelhos domésticos.
Após um longo percurso um comité veio dar origem à norma ANSI (American National
Standards Institute) /EIA 600.
A norma tem vindo a evoluir em particular na especificação em como os dispositivos
devem actuar, referenciando as especificações de desempenho em termos de tempo de
transmissão, desempenho do protocolo e características eléctricas e físicas da rede.
7
Com esta norma permite-se que várias companhias produzam equipamento compatível
que se interligam de modo a constituir um sistema.
O Sistema EIB é uma marca registada da EIBA (European Installation Bus

Association). O EIB apareceu como a solução para a integração dos vários sistemas
existentes num edifício inteligente. Congregando a gestão de iluminação, controlo de
persianas, sistemas AVAC (Aquecimento Ventilação e Ar Condicionado) num único
sistema global. O EIB assume-se como a solução Europeia para o mesmo problema que
o CEBus tenta resolver nos Estados Unidos.
O LonWorks surgiu em 1980, desenvolvido pela Echelon Corporation, que tinha como
principal objectivo o desenvolvimento de uma plataforma universal ao nível das redes
de controlo. O LonWorks é actualmente a norma ANSI/EIA 709.1 Control Networking
Standard. Como os outros protocolos este tenta solucionar os mesmos problemas e tenta
ser o preferido relativamente aos outros.
Descreve-se em seguida, com mais detalhe, cada um destes protocolos.
8
2.2 CEBus
O Sistema CEBus é constituído por nós designação dada a um dispositivo que usa esta
tecnologia e que se encontra ligado a um meio físico de transmissão.
Um nó tem as seguintes características:
§ tem a capacidade de receber e transmitir mensagens em pelo menos um
meio físico de transmissão;
§ utiliza o protocolo de mensagens CEBus (EIA/600);
§ usa e entende um conjunto mínimo de comandos da linguagem CAL
(Common Application Language), que é a linguagem usada pelos nós para
interactuarem entre si, o CAL foi normalizado como EIA-600.81
(especificação) e EIA-600.82 (Contextos).
Os dispositivos desta tecnologia utilizam ligações esporádicas uns com os outros, de

modo a efectuarem operações de controlo ou verificação de estado. Estas ligações são
conseguidas através do acesso exclusivo ao meio físico de transmissão durante um curto
período de tempo mas suficiente para transmitir o comando ou pedido. Os dispositivos
libertam o meio físico no fim da transmissão. O sistema funciona com poucos conflitos
no meio físico devido à utilização de mensagens curtas, contendo entre 50 a 300 bit e
demorando em média 25 ms. Isso também se deve à pouca frequência de troca de
mensagens entre dispositivos.
O protocolo CEBus utiliza um modelo de comunicação de dispositivo a dispositivo sem
hierarquias nem restrições, usando um barramento comum.
O CEBus define dois tipos de canais de comunicação: um canal de controlo para
mensagens entre dispositivos, e um conjunto de canais de dados para distribuição de
áudio, vídeo ou outro qualquer sinal de banda larga.
A norma CEBus disponibiliza vários meios físicos de transmissão:

§ Linha de energia eléctrica (PL - Power Line);
§ Cabo de par entrançado (TP - Twisted Pair);
§ Cabo coaxial (CX - Coaxial), preferencialmente para dispositivos que
utilizam sinais de áudio e vídeo;
9
§ Rádio frequência (RF - Radio-Frequency), utilizando uma portadora nos 915

MHz;
§ Infravermelhos (IR - Infra-Red);
§ Fibra óptica, ainda não especificado pela norma.
Com a diversidade de meios físicos de transmissão pode-se encontrar nesta tecnologia a
melhor solução para casos muito específicos. Existe só a necessidade de implementar
entre cada dois meios que pretendam interactuar um dispositivo capaz de comunicar
com os dois meios, e que se designa por Router.
Cabo coaxial
S S A
Router
CX - TP
Par entrançado
S A S
Router
PL - TP
Linha de energia eléctrica
A A S
Figura 2.2 - Ligações entre diferentes meios de transmissão
Um nó pode ser dividido em três partes, ver Figura 2.3. A parte designada por
"PROTOCOLO" é igual em todos os dispositivos, sendo esta a encarregue de efectuar a
recepção e transmissão das mensagens pelo meio físico. A parte designada por "CAL"
funciona como intérprete das mensagens CAL. A parte designada por "APLICAÇÃO"
representa a aplicação do nó e é constituída pelo hardware e software que definem a
operação do dispositivo.
10
APLICAÇÃO
CAL
PROTOCOLO
meio de transmissão
Figura 2.3 - Camadas constituintes de um dispositivo CEBus
2.2.1 O protocolo CEBus e o Modelo OSI
O CEBus segue o modelo OSI (Open System Interconnect) mas só implementa as três
primeiras camadas. As restantes camadas ou são ignoradas ou implementadas na
camada de aplicação. A camada de aplicação é a que fica responsável pela camada de
transporte, pelas mensagens de confirmação, pela selecção do tipo de serviço, pela
sequência de tramas e pela detecção da duplicação de tramas.
Modelo OSI Modelo CEBus
Aplicação
Aplicação
Apresentação Transporte
Sessão
Transporte
Rede Rede
Ligação de Dados Ligação de Dados
Física Física
Meio
Figura 2.4 - Protocolo CEBus vs. Modelo OSI
11
2.2.2 Modelo de comunicação dispositivo a dispositivo
Na Figura 2.5 ilustra-se como cada camada de protocolo origem comunica com a
camada de protocolo de destino.
Para entregar uma mensagem o interpretador de linguagem CAL do nó de origem passa
a mensagem para a camada de aplicação. A mensagem ao ser processada por esta
camada produz o APDU (Application Protocol Data Unit). A informação introduzida
por esta camada é referente aos serviços requeridos, como por exemplo se a mensagem
é codificada e se existe um pedido de confirmação da chegada da mensagem.
A camada de rede recebe da camada aplicação a APDU e introduz informação referente
ao percurso que o pacote vai tomar, informação útil para os Router, produzindo a
NPDU (Network Protocol Data Unit). Esta é enviada para a camada de Ligação de
dados. Esta última camada introduz os endereços dos nós de destino e origem, bem
como os possíveis pedidos de confirmação do nó de destino produzindo o DLPDU
(Data Link Protocol Data Unit).
A camada de ligação de dados é a que gere o acesso ao meio. Obtido o acesso este envia
o DLPDU para a camada física de origem. A camada física de origem transmite os
dados para a camada física de destino. Do lado do destino a mensagem efectua um
percurso inverso.
Aplicação Função Aplicação
CAL mensagem CAL CAL
Aplicação Aplicação
APDU mensagem
Rede NPDU APDU Rede
Ligação de Dados DLPDU NPDU Ligação de Dados
Física DLPDU Física
Pacote
Meio Meio
Figura 2.5 - Comunicação entre dispositivos
12
2.2.3 Formato da trama
Como resultado da contribuição das várias camadas do protocolo, obtém-se a estrutura

da trama representada na Figura 2.6.
DLPDU cabeçalho NPDU APDU

Preâmbulo mensagem CAL FCS
Controlo Destino Origem cabeçalho cabeçalho
APDU
NPDU
DLPDU
Figura 2.6 - Formato da trama CEBus
O campo de preâmbulo é constituído por um valor aleatório de 8 bit, este é utilizado

para se efectuar a detecção e resolução de colisões durante o acesso ao canal.
O campo de controlo identifica o tipo de serviços da ligação de dados (DLL - Data Link
Level) que o pacote contém, sendo a sua dimensão de 8 bit.
O campo de destino e origem têm uma dimensão de 32 bit, em que 16 bit correspondem
ao endereço de sistema e os restantes 16 bit correspondem ao endereço de nó.
2.2.4 Acesso ao canal
O acesso ao canal é feito usando o método CSMA (Carrier Sense Multiple

Access)/CDCR (Collision Detection Collision Resolution).
Esta política de acesso permite a existência de muitos nós a acederem e a partilharem o
mesmo meio e obriga à escuta do meio para determinarem quando podem aceder a este.
A sigla CD (Collision Detection), detecção de colisão, indica que os nós têm a
capacidade de detectar quando existe uma colisão. CR vem do inglês Collision
Resolution, ou seja, o protocolo garante que se consegue resolver uma colisão a favor de
um nó.
13
A resolução de colisões é conseguida através da sobreposição de valores lógicos.

Um bit transmitido pode ser representado por um nível superior quando este tem o valor
lógico '1' e um nível inferior quando o valor lógico a representar é o '0'. Nesta
tecnologia o estado superior de envio sobrepõe-se ao estado inferior. Assim, com este
mecanismo, quando um nó transmite um bit no estado inferior e ao escutar o meio
detecta que este se encontra no estado superior, então o nó identifica que existiu uma
colisão e imediatamente pára de transmitir, voltando ao estado de escuta até que o canal
fique livre novamente.
STOP
Nó A 1 0
STOP
Nó B 1 1 0 0
Nó C 1 1 0 1 1 0 ...
Figura 2.7 - Ilustração do mecanismo de contenção
Na Figura 2.7 ilustra-se o mecanismo atrás referido. Neste caso assume-se que os três
nós (A, B e C) começam a transmitir ao mesmo tempo. Como se pode observar o Nó C
é quem ganha o acesso ao meio.
14
2.3 EIB
2.3.1 Topologia
A rede EIB normalmente utiliza dois pares de cabos paralelos. Um é utilizado como
cabo de alimentação e o outro é usado unicamente como cabo de comunicação. Este
último é designado por Bus Line (BL), linha de barramento. Numa BL podem ser
acoplados até um máximo de 64 dispositivos. É possível ter até um máximo de 12 BL
recorrendo à utilização de acopladores de linha (LC - Line Couplers), designando-se
este agregado de dispositivos por área (BA - Bus Area). Pode-se expandir ainda mais o
sistema através do uso de vários BA interligados. Para se efectuar essa interligação
utilizam-se dispositivos designados por BC (Backbone Couplers), existindo um limite
de 15 áreas.
Os LC e BC além de isolarem electricamente as diferentes linhas e áreas contribuem
também para uma melhor eficiência ao nível da comunicação de dados, pois estes
funcionam como filtros não permitindo a passagem de mensagens que não sejam
destinadas àquela linha ou área.
A topologia usada poderá ser em barramento, estrela ou árvore, tal como uma rede de
distribuição de energia. No entanto é necessário garantir que não se formem malhas
fechadas, ou seja, ligações em anel não são permitidas.
2.3.2 Estrutura dos nós
Um dispositivo EIB é composto por um unidade de acoplamento ao barramento

(designada por BCU - Bus Coupling Unit), e por um módulo de aplicação (AM -
Application Module). A entidade BCU é responsável pela interface com a rede e tem
capacidade de armazenamento de informação como, por exemplo, o endereço físico, um
ou mais endereços de grupo e parâmetros do nó. Enquanto a entidade AM é unicamente
responsável pela interface com o utilizador ou dispositivo como, por exemplo, botão de
pressão, interruptores, sensores de temperatura, sensores de presença, etc.
15
2.3.3 Trama
A trama utilizada pelo protocolo EIB é composta por 7 campos, ver figura.
Controlo Endereço Origem Endereço Destino Contador Comprimento Informação úitl Confirmação
8 bit 16 bit 16+1 bit 3 bit 4 bit até 16*8 bit 8 bit
Figura 2.8 - Formato da trama EIB
O campo de controlo da trama tem como objectivo atribuir prioridades de transmissão

em função dos dados.
O campo designado por endereço de origem contém o endereço físico do dispositivo.
Este é composto por 4 bit que definem a área em que se encontra o dispositivo, 4 bit que
definem a linha e os últimos 8 bit definem o próprio dispositivo.
O campo de endereço de destino tem mais um bit do que o endereço de origem para
permitir que se enderece um grupo de dispositivos, sendo o 17º bit utilizado para indicar
se o endereço representado pelos outros 16 bit são de um endereço físico ou de grupo.
O contador é utilizado para permitir que se detecte o número de retransmissões que a
trama já efectuou.
O campo de comprimento, como o próprio nome indica, identifica o número de byte que
o campo de informação útil contém.
O campo de confirmação é utilizado como mecanismo de detecção de erros na
transmissão dos dados. Este campo é utilizado no dispositivo de recepção para validar a
mensagem recebida e poder enviar ao emissor um aviso de confirmação de recepção
correcta.
O campo atrás referido é utilizado para controlar o mecanismo de IACK (confirmação

imediata, IACK - Immediate Acknowledge). Os erros de transmissão podem ocorrer em
qualquer direcção, isto é, um pacote de dados ou uma confirmação podem ser
destruídos. Para cada situação deve tomar-se as seguintes medidas:
§ se o pacote de dados é destruído, a camada de ligação do receptor transmite
um sinal INAK (Immediate Not Acknowledge) e a camada do emissor
retransmite o pacote de dados;
16
§ se a confirmação é destruída, a camada de ligação do emissor retransmite o

pacote de dados, sendo da responsabilidade do receptor detectar se existe
uma duplicação do pacote, de qualquer modo o receptor deve enviar uma
mensagem de confirmação sempre que recebe uma nova mensagem.
O EIB define quatro níveis de prioridade:

§ Prioridade 1 - elevada prioridade, reservada para funções de
sistema
§ Prioridade 2 - reservada para funções de alarme e retransmissões
§ Prioridade 3 - prioridade operacional alta
§ Prioridade 4 - prioridade operacional baixa
No EIB não é possível garantir a não existência de duplicação de mensagem pois um

dispositivo pode receber mais do que uma vez a mesma mensagem. As retransmissões
têm o mesmo nível de prioridade que as mensagens de alarme e de sistema, logo um
dispositivo pode receber entre as repetições de uma mensagem mensagens de sistema ou
alarme, não sendo possível a este detectar se anteriormente já recebeu a mesma
mensagem, caso em que existe uma duplicação.
O algoritmo de acesso ao bus é do tipo CSMA (Carrier Sense Multiple Access) /CA
(Collision Avoidance). Todos os dispositivos escutam o barramento e, se este estiver
livre, o dispositivo começa a transmitir e ocupa o barramento. Os outros escutam que
existem dados no bus e esperam por novo silêncio. No caso de existir conflito no acesso
ao meio, este é resolvido porque o símbolo ZERO se sobrepõe ao símbolo UM sem que
o primeiro seja destruído. É feito um wired-and (operação lógica &) ao nível da linha.
Logo que o emissor que transmite o símbolo UM detecta que o que lê do bus é um
símbolo ZERO, conclui que ocorreu uma colisão e pára de transmitir, ficando a
aguardar nova oportunidade para transmitir.
17
Cada 8 bit de dados são transmitidos em grupo, formando uma palavra. A palavra é
constituída pelos 8 bit mais um bit inicial ST (Start bit), um bit de paridade Pz (Parity
bit) e um bit final SP (Stop bit). Entre palavras deverá existir uma pausa de 2 bit.
ST D0 D1 D2 D3 D4 D5 D6 D7 Pz SP Pausa ST ...
"Palavra" "Palavra"
Figura 2.9 - Estrutura de uma palavra EIB
Com as condicionantes atrás referidas e com um ritmo de transmissão de 9600 bps (bit
per second), o tempo que demora a transmitir uma palavra é 1,35 ms (ver Figura 2.10).
ST D0 D1 D2 D3 D4 D5 D6 D7 Pz SP Pausa ST ...
1,35 ms
Figura 2.10 - Tempo de palavra EIB
Como a dimensão de um telegrama pode variar entre 9 e 23 byte temos que o tempo de
ocupação do bus por telegrama completo varia entre 20 a 40 ms. Este tempo inclui o
tempo t1 (50 vezes o tempo de bit, neste caso 5,2 ms) de verificação do silêncio no
meio, e o tempo t2 (15 vezes o tempo de bit, sendo este 1,56 ms) necessário para
receber a mensagem de confirmação, ver ilustração na Figura 2.11.
t1 Telegrama t2 IACK
20 - 40 ms
Figura 2.11 - Tempo entre mensagens EIB
18
2.4 LonWorks
A rede LonWorks permite um processamento distribuído, realizado por dispositivos

inteligentes com capacidade de comunicação e de processamento.
É utilizado em diversas áreas nomeadamente em automatização fabril, controlo de
processos, automatização de edifícios, automatização doméstica, equipamento
automóvel e sistemas de transporte.
O LonWorks implementa uma rede de dispositivos com a capacidade de comunicação

entre eles, não necessitando de um dispositivo supervisor para efectuar essa mesma
comunicação. Cada dispositivo tem a capacidade de tomar decisões e se deve ou não
enviar informação para a rede.
O LonWorks elegeu como o seu protocolo o LonTalk. Este protocolo usa pacotes e
suporta ligações ponto a ponto (como é o caso dos protocolos utilizados na Ethernet e
na Internet). O LonTalk é um protocolo publicado como norma EIA e segue o modelo
OSI. Este protocolo foi preferencialmente concebido para uma utilização em sistemas
de controlo, e não em sistema de processamento de dados.
2.4.1 Endereçamento
De modo a simplificar a configuração e gestão da rede, o LonWorks implementa um

mecanismo de endereços lógicos. Cada dispositivo físico ou nó tem um endereço
lógico. Cada endereço tem duas partes distintas. A primeira define o domínio onde o nó
se encontra, sendo o domínio um conjunto de nós ou um sistema como acontece na
maioria dos casos. A segunda parte do endereço é constituída pelo seu endereço de nó
(15 bit de comprimento) ou pelo endereço de grupo (com 8 bit de comprimento).
O pacote transmitido pela rede contém sempre o nó de origem bem como o endereço de
destino quer este seja um nó, um grupo ou um endereço de divulgação (broadcast).
19
2.4.2 Capacidades do sistema
Nós por subrede 127

Subredes por domínio 255
Nós por domínio 32385
Domínios numa rede 248
Número máximo de nós 32K x 248
Número de nós por grupo
sem confirmação ilimitado
com confirmação 63
Número de grupos por domínio 255
Número de canais por rede ilimitado
2.4.3 Tipos de mensagens
O protocolo LonTalk define 4 tipos básicos de mensagens:

§ acknowledged (ACKD). Este tipo define que a mensagem enviada para um
nó ou para um grupo de nós irá receber obrigatoriamente uma confirmação
de cada um dos nós intervenientes. Se por alguma razão uma das
confirmações não chegar ao nó emissor, este ao fim de um tempo de espera
repetirá a mensagem. Este procedimento efectua-se um determinado número
de vezes. O LonTalk permite que o tempo de espera e o número de
repetições seja configurado.
§ request/response (REQUEST). Este tipo de mensagem funciona de forma
análoga ao anterior excepto que em vez de ficar à espera de confirmações
fica à espera de respostas dos nós.
§ unacknowledged repeated (UNACK_RPT). Este tipo de mensagem é
utilizado quando se pretende enviar mensagens para um grande grupo de
nós. Se esta mensagem obrigasse os nós receptores a enviar uma resposta
isso poderia saturar a rede. A mensagem é enviada um número definido de
20
vezes, aumentando assim as probabilidades de todos os nós receberem a

mensagem;
§ unacknowledged (UNACK). Envia uma única vez a mensagem e não fica à
espera de confirmação nem de resposta da parte do receptor.
Como se pode verificar os dois primeiros tipos são utilizados para mensagens com
confirmação sendo os outros dois utilizados para mensagens sem confirmação.
É suposto detectar-se a duplicação de mensagens. Estas duplicações ocorrem quando as
mensagens de confirmação ou de resposta são perdidas e quando se utiliza o tipo de
mensagem unacknowledged repeated. O protocolo define que quando são mensagens do
tipo request/response a duplicação existe porque poderá existir alterações no campo de
dados.
O protocolo LonTalk providencia um serviço de autenticação de mensagens. Este
serviço é útil para prevenir o acesso de nós não autorizados. Este serviço de
autenticação é definido por uma chave de 48 bit definida nos nós no momento da
instalação dos mesmos. O serviço processa-se da seguinte forma: o emissor ao enviar
uma mensagem autenticada é desafiado pelo receptor a responder a um desafio. O
emissor processa esse desafio e encaminha-o para o receptor. Por sua vez este processa
o desafio feito e compara-o com a resposta do desafio. Se a resposta do desafio estiver
correcta o receptor processa o pedido, caso contrário ignora-o.
O acesso ao canal implementado por este protocolo é o CSMA p - persistente. Como é

típico neste tipo de acesso, utilizam-se slots, ou seja, os nós só tentam transmitir num
determinado slot reduzindo desta forma a probabilidade de colisão.
Em carga reduzida são utilizados 16 slots, originando atrasos superiores no acesso.
Quando a carga é elevada utilizam-se 16*n slots, originando atrasos menores no acesso
e diminuindo a probabilidade de colisão. O valor de n é permanentemente actualizado, o
nó que transmite indica quantas respostas ou confirmações espera, assim os nós de
recepção incrementam n e no fim de cada ciclo decrementam n.
21
Não se conseguiu obter mais informação sobre o modo como este protocolo resolve o
problema das colisões.
O protocolo permite estabelecer prioridades ao nível do nó, ou seja, todas as mensagens
que saem desse nó tem a mesma prioridade. Podem existir casos de excepção em que as
mensagens têm outra prioridade. A prioridade varia entre 0 e 127, cada uma destas só
pode ser atribuída a um nó por canal. Normalmente reserva-se a prioridade 1 para o nó
de gestão de rede.
De modo a conseguir uma rápida implantação deste protocolo no mercado, a empresa

responsável pelo desenvolvimento deste (Echelon) concebeu um microprocessador
específico designado por Neuron Chip. Este microprocessador implementa em
"firmware" o protocolo de comunicação, o que evita a necessidade de desenvolvimentos
ou programação nesta área a quem queira desenvolver dispositivos para este tipo de
redes. O Neuron Chip providencia as seis primeiras camadas do modelo OSI, bastando
para isso desenvolver a camada de aplicação, o que obriga a uma normalização dos
dispositivos de diferentes fabricantes e permite um desenvolvimento mais fácil e rápido
de aplicações.
O Neuron Chip é basicamente um sistema num integrado, visto que este é constituído
por 3 microprocessadores, memória RAM (Random Access Memory) e ROM (Read
Only Memory), módulo de comunicação e portos de entrada e saída. A memória ROM
contém um sistema operativo, o protocolo de comunicação LonTalk e funções de acesso
aos portos.
O LonWorks tem um vasto leque de software de gestão e configuração da rede, mas
todo este software é proprietário da Echelon Corporation e esta não o disponibiliza com
facilidade. Assim não foi possível efectuar uma análise mais detalhada do mesmo. O
mesmo acontece com outros pormenores de implementação do protocolo e de outros
pormenores utilizados por esta rede.
22
Capítulo
3 Proposta
Conteúdo
3.1 INTRODUÇÃO .......................................................................................................... 24
3.2 ARQUITECTURA PROPOSTA .................................................................................... 26
3.3 P ROTOCOLO DE REDE ............................................................................................. 30
3.4 CAPACIDADES DA REDE PROPOSTA......................................................................... 36
23
3.1 Introdução
No capítulo anterior foram analisadas três das redes mais divulgadas e foram descritas
as suas principais características. Neste capítulo será apresentado um sistema domótico
alternativo sendo descrita a sua arquitectura e o protocolo de comunicação.
Os sistemas de controlo podem ser divididos em dois grandes grupos: os sistemas

distribuídos e os centralizados. As abordagens descritas no capítulo anterior oferecem
uma abordagem distribuída em que um nó está normalmente associado a um só
dispositivo (sensor/actuador) ou a um número muito reduzido de dispositivos.
Não há dúvidas sobre a flexibilidade e modularidade desta abordagem. Contudo ela tem
desvantagens no que se refere à rentabilização de componentes fundamentais como
sejam o microcontrolador e circuitos de acesso ao meio físico de transmissão, que são
subaproveitados.
Nos sistemas analisados, razões várias impõem o uso de processadores com bom
desempenho e bastante memória, ou mesmo vários processadores, como no caso do EIB
em que são usados tipicamente dois. Nestes casos, normalmente existe um
microcontrolador dedicado exclusivamente para o acesso ao meio físico e o outro
dedicado à aplicação.
A solução centralizada pura, embora possa optimizar os recursos disponíveis, levanta
problemas de fiabilidade (uma falha pode tornar inoperacional todo o sistema) e pode
também levantar problemas em termos de desempenho e capacidade de resposta.
Pretende-se que a rede a implementar seja simples e de fácil utilização, pois deseja-se
que possa ser implementada em nós o mais simples possível, para que o custo seja
reduzido ao máximo.
O que se propõe é uma solução híbrida em que existe distribuição ao nível dos nós, isto
é, é possível ter-se múltiplos nós, cada um numa localização física distinta, mas em que
cada nó controla múltiplos dispositivos (sensores/actuadores), procurando-se
rentabilizar ao máximo os recursos de hardware do nó e possibilitando uma redução
global de custos.
De modo a ilustrar o raciocínio veja-se a Figura 3.1 e a Figura 3.2. A Figura 3.1
representa um sistema distribuído em que existe um nó de controlo (N) associado a cada
dispositivo (D), representados na figura por N/D. Esses nós encontram-se interligados
24
por cablagens que servem de meio de comunicação e de alimentação dos nós.

Eventualmente, pode existir também cablagem de alimentação de potência (230 V AC).
Na abordagem proposta, ver Figura 3.2, a cablagem gasta é inferior pois normalmente
basta um único tipo de cablagem para interligar o dispositivo ao respectivo nó.
Relativamente aos caminhos dos cabos, estes podem ser exactamente os mesmos dado
que normalmente é possível passar vários cabos na mesma conduta.
Notar que existem sistemas (como o EIB) em que é possível usar um mesmo cabo para
alimentação e comunicação. Mesmo neste caso, com a abordagem proposta os gastos
em termos de cablagem são da mesma ordem de grandeza. No que toca aos caminhos de
cabos, os gastos são muito semelhantes ou mesmo iguais, desde que se tire partido da
possibilidade de passar vários cabos numa mesma conduta.
De notar que por vezes até pode ser mais económico ter caminhos de cabos distintos
que se juntam num único ponto visitável do que, como está implícito na Figura 3.1, ter
de dispor de múltiplas caixas de derivação sempre que existe uma junção dos cabos.
Para ilustrar em que medida a solução proposta pode ser mais económica, basta
considerar que um nó pode controlar até 20 dispositivos enquanto na abordagem
totalmente distribuída isso obrigaria ao uso de 20 nós.
2
N/D
2 2 2
2 N/D 2
2
N/D
N/D
N/D
N/D
N/D
Figura 3.1 - Exemplo de uma instalação distribuída
25
1
1 1
D N
N
1
1
D
D D
D
Figura 3.2 - Exemplo de uma instalação da rede proposta
3.2 Arquitectura proposta
3.2.1 Topologia
A rede que se propõe utiliza uma topologia em barramento. Porém, recorre-se à

utilização de vários barramentos físicos (interligados entre si) para explorar o efeito da
localidade das operações. Por exemplo, um interruptor de uma divisão provavelmente
controla uma lâmpada nessa mesma divisão. Logo, para explorar o efeito da localidade,
a comunicação entre estes dois dispositivos deverá ser efectuada num mesmo troço de
rede.
Para isso propõe-se a existência de grupos de nós, designados por ilhas, permitindo
isolar as operações locais de cada área da habitação. Desta forma optimiza-se o tráfego,
face à utilização de um único barramento físico, em que todos os dispositivos
comunicariam pelo mesmo troço. Esta abordagem permite um acréscimo no
desempenho global do sistema, possibilitando diálogos simultâneos, desde que em
troços diferentes. As comunicações locais a uma ilha não influenciam outras ilhas.
26
Nó 0 Nó 1 Nó 2 Nó 3 ... Nó n
ILHA
Figura 3.3 - Agrupamento de nós designado por Ilha
O efeito de localidade é também importante porque a probabilidade de existirem

actuações simultâneas na mesma divisão ou área é relativamente reduzida.
Para que possa existir comunicação entre ilhas, estas são interligadas através de uma
bridge que isola electricamente um barramento de outro e serve em simultâneo de filtro
de mensagens de uma ilha para outra.
Mundo
Gestor do RS232
Sistema
Nó 31 Nó 2
Nó 0 Nó 1 Nó 16
Nó
supervisor
Figura 3.4 - Sistema de pequena dimensão, com um só barramento
Para sistemas de pequena dimensão (definiu-se como pequeno um sistema que seja
constituído por 32 nós no máximo, ver Figura 3.4) é possível usar um único barramento.
Nestes casos não é necessário usar nenhuma bridge. Em sistemas com uma dimensão
superior recorre-se à utilização de vários barramentos interligados por bridges, ver
Figura 3.5.
27
bridge bridge bridge bridge
ILHA 1 ILHA 2 ILHA 4 ... ILHA 15
Figura 3.5 - Arquitectura proposta no caso de um sistema de grande dimensão
Num sistema de média dimensão pode-se dispensar a utilização de uma bridge

utilizando-se o barramento de comunicação entre ilhas para se colocarem nós. Esta
opção tem a desvantagem que o tráfego desses nós influencia a comunicação entre ilhas.
Na Figura 3.6 ilustra-se um exemplo para a topologia atrás referida.
Mundo
Gestor
de
Sistema ILHA 1
Nó
supervisor
RS232
Nó 31 Nó 0 Nó 1 Nó 2 Nó 16
bridge bridge
ILHA 2 ILHA 3
Figura 3.6 - Arquitectura proposta no caso de um sistema de média dimensão
Pode-se concluir que a arquitectura proposta é bastante flexível ao nível da topologia.

Em termos de endereçamento os nós validam quer o endereço de nó quer o endereço de
ilha, pelo que é possível ter no mesmo troço nós de diferentes ilhas. Desta forma
pode-se implementar um sistema com um só troço - ver Figura 3.7. Esta abordagem
permite construir um sistema grande e com baixa latência (as mensagens não necessitam
de atravessar bridges). A desvantagem principal é que todo o tráfego tem de passar por
28
um único troço da rede o que aumenta a probabilidade de colisões. Assim, pode-se

concluir que esta abordagem é a ideal para sistemas com pouco tráfego mas com
exigências ao nível da latência.
Esta abordagem corresponde a considerar que não existe a noção de ilha e que o
endereçamento dos nós é feito forma planar.
Ilha 1 Ilha 2 Ilha 1 Ilha 3 ... Ilha x

Nó 0 Nó 1 Nó 1 Nó 0 Nó y
Figura 3.7 - Arquitectura proposta com um único troço
Antes de prosseguir clarificam-se algumas noções:

§ dispositivo - sensor ou actuador;
§ nó - designação dada a um controlador com um endereço físico, com
capacidade de comunicação e com a possibilidade de controlar um ou mais
dispositivos;
§ ilha - designação dada a um grupo de nós que partilham um mesmo troço
de comunicação;
§ bridge - componente do sistema que permite interligar duas ilhas;
§ módulo supervisão - controlador encarregado de gerir o comportamento dos
nós do sistema; este tem a seu cargo as tarefas de supervisão de nós que
controlam dispositivos, sendo útil quando é necessário tomar decisões ou
desencadear acções complexas que podem envolver múltiplos dispositivos
de diferentes nós;
§ gestor de sistema - PC (Personal Computer) que centraliza toda a
informação sobre o sistema seja de configuração/parametrização seja de
programação de comportamentos.
29
Propõe-se que um nó contenha um único microcontrolador que será responsável pela

comunicação e pelas várias aplicações que um nó possa ter.
Cada aplicação pode controlar vários dispositivos de um mesmo tipo. Por exemplo, uma
aplicação pode controlar vários sensores de temperatura, vários sensores de presença ou
várias saídas digitais.
Para além de controlar um conjunto de dispositivos uma aplicação pode interactuar com
outras aplicações do mesmo nó ou de outro nó qualquer.
3.3 Protocolo de rede
Tendo em conta a arquitectura proposta para o sistema descreve-se em seguida o

protocolo usado. Procura-se que este fosse o mais simples possível, mas que fosse
robusto e flexível.
Existiu o cuidado de procurar tornar as tramas o mais curtas possível para maximizar a
relação entre a informação útil transmitida e o conjunto total da trama.
Convém lembrar que estamos perante aplicações de controlo em que tipicamente a
informação transmitida é muito curta, indicando apenas o estado de um dispositivo ou
dando um comando para colocar um dispositivo num dado estado.
3.3.1 Trama
A Figura 3.8 descreve a trama proposta, que é constituída por 6 campos de informação
distintos.
1 bit 7 bit 4 bit 4 bit 8 bit 8 bit 8 bit 0 - 121 byte 8 bit
Dimen-
0
são
Ilha Ilha Destino Origem Controlo Dados CRC
Destino
Origem
Figura 3.8 - Trama proposta
30
O primeiro campo tem a designação de Dimensão e contém a dimensão total da trama

(número total de byte). O primeiro bit deste campo necessita ser '0' identificando a
presente versão do protocolo e permitindo uma futura expansão. Futuros nós poderão
contemplar o envio e a recepção do actual formato de trama bem como um novo
formato. Os nós actuais ignoram tramas cujo o primeiro bit seja '1'.
Este facto tem como implicação que a dimensão da trama não pode ser superior a 127
byte. Com este formato a trama mais curta possui 6 byte de dimensão.
Em termos do campo de dados é possível enviar até 123 byte. Este valor que é grande
em termos de mensagens de controlo, pode ser útil em situações de troca de informação
como, por exemplo, envio de dados estatísticos.
1 bit 7 bit 4 bit 4 bit 8 bit 8 bit 8 bit 0 - 121byte 8 bit
0 Size Ilha Ilha Destino Origem Controlo Dados CRC

Destino
Origem
A A
Nó Nó
pl pl
5 3 5 3
bit bit bit bit
Figura 3.9 - Endereçamento
É de relembrar que é suposto existirem múltiplas aplicações nos nós e que os diálogos
no sistema são entre aplicações e não entre nós.
O endereçamento é feito de forma planar, opta-se por decompor o campo de endereço
em 3 partes: uma que especifica a ilha, outra que especifica o nó e outra que especifica a
aplicação, ver Figura 3.9. Na prática as tramas são endereçadas a uma dada aplicação
que está num dado nó numa dada ilha.
Com este tipo de endereçamento e com o número de bit utilizados, obtêm-se as
seguintes capacidades máximas:
• 16 ilhas;
• 32 nós por ilha, num total de 512 nós;
• 8 aplicações por nó, embora só possam existir 7 aplicações de controlo de
dispositivos, pois a aplicação 0 é usada para gerir e parametrizar o nó, sendo
identificada como aplicação de sistema.
31
Nós especiais da rede, tais como módulos de supervisão, módulos de interface com
outros meios (gateway) ou módulos bridge com mecanismo de filtro de tramas,
consomem um endereço por cada módulo.
O serviço de divulgação (broadcast) é implementado recorrendo ao endereço ilha 0, nó
0 e aplicação 0. Neste caso todas as placas receberão a trama e a aplicação de sistema de
cada nó irá efectuar o processamento.
O serviço de divulgação (broadcast) é fundamental para permitir a atribuição dinâmica
dos endereços aos nós. Quando um nó é ligado pela primeira vez este envia um
identificador único de placa e fica à espera que alguém lhe responda com uma trama de
divulgação (broadcast) contendo no campo de dados o seu identificador único enviado
anteriormente e explicitando qual passará a ser o seu endereço no sistema.
Com este serviço implementado e possuindo simplesmente a relação dos identificadores
únicos de cada dispositivo que se pretenda instalar pode-se efectuar a configuração de
todo o sistema através de um único ponto de acesso à rede, ou seja, pode-se efectuar
toda a parametrização/configuração de todo o sistema domótico através de um único
módulo de supervisão.
Modelo OSI Modelo Proposto
Aplicação
Aplicação
Apresentação Transporte
Sessão
Transporte
Rede Rede
Ligação de Dados Ligação de Dados
Física Física
Meio
Figura 3.10 - Modelo OSI vs. modelo proposto
Dado que se pretende uma abordagem simples, a rede não oferece camada de transporte
e, como tal, não é possível garantir que não se perdem tramas, nem que não ocorram
32
duplicações de tramas. Para colmatar estes problemas existe um campo de controlo na

trama (ver Figura 3.11), que se destina a ser gerido pela própria aplicação.
Por outro lado, definiu-se que as aplicações devem confirmar ou responder às ordens
que recebem.
Na camada de nível 2 (ligação de dados) existe um mecanismo de confirmação sendo a
trama repetida um certo número de vezes caso essa confirmação não seja recebida .
Com este mecanismo pretende-se aumentar a robustez do protocolo e evitar que a
aplicação tenha de intervir no caso de uma trama não ter chegado ao destino seja devido
a ruído eléctrico, ocorrência de uma colisão, ou outra razão.
A primeira confirmação é dada ao nó emissor pelo nó receptor pelas respectivas
camadas de rede, a segunda é dada ao nível da aplicação. Tomou-se esta opção devido
que esta simplificava bastante a complexidade do mecanismo de envio e recepção bem
como atenuava bastante o tempo de processamento.
1 bit 7 bit 4 bit 4 bit 8 bit 8 bit 8 bit 0 - 121byte 8 bit
0 Size Ilha Ilha Destino Origem Controlo Dados CRC

Destino
Origem
7 6 5 4 3...0
4 4
bit bit
Figura 3.11 - Descrição da trama - Campo de controlo
Comando/
Prioridade Reservado Numeração Código de operação
Resposta
7 6 5 4 3...0
4 bit 4 bit
Figura 3.12 - Descrição do campo de controlo
33
O campo de controlo contém a seguinte informação (ver Figura 3.12):

• prioridade, bit 7 do campo de controlo, permite definir 2 níveis de prioridade
para as tramas;
• numeração, bit 5 do campo de controlo;
• comando/resposta, bit 4 do campo de controlo, identifica se a trama é uma
resposta/confirmação, permitindo a validação de comandos;
• código de operação, bit 0 a 3 do campo de controlo, com estes 4 bit permite
que existam 16 operações por aplicação;
• e 1 bit de reserva (bit 6 do campo de controlo), que poderá vir a ser utilizado
no futuro.
As aplicações comunicam entre si através de mensagens, podendo estas ser

comandos/pedidos e respostas/confirmações. A comunicação entre duas aplicações é
exemplificada na Figura 3.13, sendo ilustrada a confirmação de baixo nível.
Aplicação A Comando Confirmação Resposta Confirmação
tConfirmação
tResposta
Aplicação B Comando Confirmação Resposta Confirmação
Figura 3.13 - Comunicação entre duas aplicações
Como se pode verificar existem dois tempos importantes, um é o tempo que uma
mensagem de confirmação de baixo nível é esperada pelo emissor até considerar que a
mensagem não foi recebida pelo receptor, outra é o tempo de espera de uma resposta a
um pedido.
A confirmação de baixo nível tem um papel muito específico, esta não é considerada
uma trama pois não cumpre os tempos de silêncio, nem tem cabeçalho. Esta
confirmação é enviada dentro de um intervalo de tempo curto e a seguir à trama.
O tempo é contabilizado pela aplicação de rede e está predefinido e é igual para todos os
nós. O segundo tempo é contabilizado pelas aplicações, competindo a cada aplicação
definir o seu valor. Uma aplicação que controle um dispositivo rápido, uma escrita em
34
memória volátil, este poderá ter um tempo inferior ao de uma outra aplicação que tenha
controlo sobre um dispositivo mais lento, uma escrita em memória
EEPROM (Electricaly Erasable Programmable Read Only Memory).
3.3.2 Acesso ao Canal
Estando a utilizar-se uma topologia de rede em barramento comum, é necessário

providenciar um mecanismo de controlo sobre os acessos ao canal, de modo a que,
quando um nó adquire o bus, se estabeleça uma ligação ponto-a-ponto. Por este motivo
optou-se por uma técnica de acesso semelhante ao CSMA (Carrier Sense Multiple
Access) /CD (Collision Detection).Esta abordagem permite em situações normais uma
baixa latência e uma eficiência elevada.
O acesso ao canal efectuado é da seguinte forma: quando um nó deseja enviar uma
trama começa por escutar o meio físico e, se este estiver inactivo durante um
determinado intervalo de tempo, designado por tempo de guarda, este espera mais um
tempo aleatório, designado por tempo de contenção. Findo este tempo, se continuar a
não existir tráfego na linha, então pode aceder ao canal.
O tempo de contenção é composto por uma parte fixa, uma parte variável e uma parte
aleatória. A parte fixa é o tempo de contenção mínimo. A parte variável corresponde a
um valor afectado pela prioridade da mensagem a enviar. Por fim a parte aleatória é
introduzida de modo a diminuir a probabilidade de colisões no acesso ao canal.
35
Tempo de
contenção
F V A
i a l
x r e
o i a
á t
v ó
e r
l i
o
Placa mais prioritária
Placa menos prioritária
Figura 3.14 - Tempo de contenção
Como se pode verificar pela Figura 3.14 o tempo variável de uma mensagem menos
prioritária deverá ser sempre superior ao resultado da soma do tempo variável e do
tempo aleatório de uma mensagem mais prioritária.
Ao verificar-se uma colisão, ambas as tramas são afectadas, sendo perdidas. Cada nó
deverá tentar reenviar a trama.
3.4 Capacidades da rede proposta
Efectua-se um pequeno estudo teórico das capacidades da rede proposta.

Utiliza-se uma trama organizada em bytes que são enviados individualmente em série
recorrendo a uma UART, e usando os seguintes pressupostos:
§ tempo de contenção máximo de 4 ms;
§ tempo de chegada de uma confirmação de 1ms;
§ 10 bit por byte transmitido, 1 bit inicial + 8 bit de dados + 1 bit de fim;
§ ritmo de transmissão de 19200 bps.
36
Utilizando as seguintes formulas calcula-se os valores teóricos do número de mensagens

por segundo e a eficiência em relação a diferentes tamanhos de trama, produzindo-se a
Tabela 3-1 e a Figura 3.15.
1
Mensagens / s =
Tempo de contenção + Tempo de confirmaçã o +
(dim ensão + byte de confirmaçã o ) × número de bit por byte transmitid o
ritmo de transmissã o
Mensagens / s × dim ensão

Eficiência =
ritmo de transmissã o
número de bit por byte transmitid o
Dimensão Mensagens/s Eficiência

6 116 36,14%
8 103 43,01%
10 93 48,54%
12 85 53,10%
16 72 60,15%
20 63 65,36%
32 45 75,12%
40 38 79,05%
50 32 82,51%
60 27 84,99%
70 24 86,85%
80 21 88,30%
90 19 89,46%
100 17 90,42%
127 14 92,30%
Tabela 3-1 - Capacidades teóricas da rede proposta
37
Figura 3.15 - Gráfico das capacidades da rede proposta
Como se pode verificar quanto maior for o campo de dados a transmitir melhor é a
eficiência da rede, mas em contrapartida o número de mensagens decresce. Constata-se
que para o fim pretendido a rede proposta tem uma capacidade teórica de enviar 72
mensagens por segundo com uma dimensão de 16 byte o que à partida é suficiente para
o controlo de uma habitação. Neste valor não estão incluídas as confirmações de alto
nível, pode-se extrapolar e dizer que possivelmente poderão existir 36 diálogos por
segundo. De relembrar que este estudo é para comunicações dentro da mesma ilha, logo,
têm-se nas outras ilhas a mesma capacidade.
38
Capítulo
4 Detalhes de implementação
Conteúdo
4.1 INTRODUÇÃO .......................................................................................................... 40
4.2 NÍVEL FÍSICO DO PROTOCOLO ................................................................................ 41
4.3 METODOLOGIA ....................................................................................................... 42
4.4 ESTRUTURA E FUNCIONAMENTO DO SOFTWARE DE REDE ...................................... 44
4.5 M ÁQUINA DE ESTADOS DA APLICAÇÃO DE REDE .................................................... 45
4.6 ESTRUTURA DE DADOS............................................................................................ 46
4.7 APLICAÇÕES ........................................................................................................... 51
4.8 RETRANSMISSÕES ................................................................................................... 53
4.9 IDENTIFICADOR ÚNICO ........................................................................................... 53
4.10 TABELA DE ENDEREÇOS.......................................................................................... 54
4.11 APLICAÇÃO DE SISTEMA ......................................................................................... 59
4.12 MECANISMO DE DECISÃO DE ENVIO ....................................................................... 59
4.13 BRIDGE ................................................................................................................... 61
4.14 GATEWAY ............................................................................................................... 62
4.15 RECURSOS UTILIZADOS PELA APLICAÇÃO DE REDE ............................................... 63
39
4.1 Introdução
Para se poder implementar a rede existiu a necessidade de implementar um protótipo do

sistema proposto. Para se proceder à sua implementação teve de se inventariar as
necessidades de hardware e software.
A peça fundamental desta implementação é o microcontrolador a utilizar, para isso
identificaram-se as seguintes características fundamentais que este deveria ter:
§ Uma UART de modo que o microcontrolador não necessite de recorrer a
software para transmitir ou receber um byte;
§ Um número elevado de pinos de entrada/saída;
§ Capacidade de memória de programa e dados suficientes;
§ um microcontrolador com desempenho razoável ao nível do processamento.
A opção tomada foi o microcontrolador da ATMEL o AVR AT90S8515. Algumas das

suas principais características são:
§ Arquitectura RISC;
§ 120 instruções em que a maioria são instruções que executam num único ciclo
de relógio;
§ 8 Kbyte de memória Flash para código;
§ 512 byte de memória RAM;
§ 512 byte de memória EEPROM;
§ 32 x 8 registos de uso geral;
§ UART até 115200 bps;
§ 1 contador/temporizador de 16 bit;
§ 1 contador/temporizador de 8 bit;
§ comunicação entre microcontroladores por SPI (Serial Peripheral Interface);
§ 32 linhas de entradas/saídas programáveis;
§ ICSP (In-Circuit Serial Programming) para a sua memória de código poder ser
programada na própria placa.
40
Com o microcontrolador atrás referido foi desenvolvido um nó controlador capaz de

gerir diversos tipos de dispositivos. Desta forma produziu-se uma placa Domótica com
as seguintes características:
§ 20 entradas/saídas digitais com pull-up;
§ rede de comunicação usando EIA-485;
§ programação do microcontrolador na própria placa
§ 1 pino de interrupção externa
§ 2 pinos de contagem
4.2 Nível físico do protocolo
Optou-se pelo uso da norma EIA-485 no tocante aos sinais eléctricos a enviar no meio
físico. As principais razões que levaram a tomar esta opção foram:
§ grande divulgação e facilidade de obtenção;
§ grande imunidade ao ruído (usa comunicação a dois fios);
§ suporta elevados ritmos de transmissão (até 10 Mbps);
§ permite comunicação a grandes distâncias (até 1250 m);
§ baixo custo.
Existem outras alternativas possíveis, como a Ethernet, mas em comparação a interface
em comunicação série em EIA-485 é muito mais simples e económica. Para se poder
utilizar este dispositivo de interface basta que os nós da rede, sejam eles um computador
pessoal ou um microcontrolador, tenham a capacidade de comunicação série assíncrona.
Os transceivers EIA-485 permitem normalmente interligar 32 nós, nalguns casos
permitem que o número de nós se estenda para 256.
A interface EIA-485 usa dois fios, linhas que são designadas por A e B, nestas linhas
normalmente circula o sinal de dados e o seu inverso. Ao utilizar-se esta técnica
permite-se que esta rede seja mais imune a ruídos que possam interferir nela.
Um receptor RS-485 deve verificar a tensão diferencial entre as linhas, esta deve ser de
200 mV entre A e B. Se a tensão em A for pelo menos 200 mV maior que em B, então o
receptor interpreta com sendo o valor lógico '1'. Se B for 200 mV maior que A então o
valor lógico interpretado pelo receptor é '0' . Nos casos em que a diferença seja menor
que 200 mV o valor lógico é indefinido.
41
A utilização deste tipo de interface em distâncias longas requer certos cuidados, tais
como resistências de terminação (normalmente 120 Ω), e resistências de polarização das
linhas.
A maior desvantagem desta abordagem é a necessidade de existir uma massa comum a
todos os nós. Existem transceivers isolados (por transformadores ou optoelectronica)
que não impõe essa restrição.
Na nossa implementação consegue-se garantir esta existência pois não nos encontramos
num ambiente electromagnético ruidoso e os nós encontram-se relativamente perto, e
normalmente têm a mesma fonte de alimentação. Se por acaso tiver-se a necessidade de
interligar nós que não tenham a mesma fonte de alimentação então o cabo de rede
deverá passar a ter três condutores, sendo o condutor adicional utilizado para interligar
as massas dos nós.
Figura 4.1 - Esquema de ligações de uma rede EIA-485
4.3 Metodologia
Como atrás foi referido o objectivo era produzir um sistema de baixo custo. Por isso os
nós permitem desempenhar várias funções.
Assim, optou-se antes por um sistema em que cada módulo permite executar diversas
tarefas em simultâneo (programação concorrente), partilhando assim recursos de
hardware e reduzindo os custos de um sistema deste tipo.
42
De forma a garantir o funcionamento correcto de todas as aplicações dentro de um

mesmo nó, optou-se por implementar um mecanismo multitarefa cooperativo em que
cada tarefa (aplicação) executa durante um intervalo de tempo e, de seguida, cede o
controlo do processador a outra tarefa. É responsabilidade de cada uma delas guardar o
estado em que se encontrava para mais tarde poder prosseguir com as suas acções.
Este sistema apresenta a vantagem de se revelar muito simples de implementar, embora
dependa exclusivamente da colaboração entre as aplicações. Isto é, no caso de uma
aplicação, por mau funcionamento ou por outra razão, não libertar o processador, as
outras aplicações não são executadas. No entanto, em funcionamento normal, para além
de ser muito mais simples de implementar do que um sistema multitarefa preemptivo,
este sistema também tem a vantagem de apresentar uma menor ocupação dos recursos
(nomeadamente memória), não sendo necessário guardar o contexto de execução de
cada tarefa. Para se implementar um núcleo multitarefa este necessitaria de mais
memória de pilha (stack), de modo a salvaguardar todos os dados relevantes de uma
dada aplicação, e iria ser menos eficiente pois algum do tempo de processamento seria
utilizado para este processo de comutação entre aplicações.
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 4
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 4
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 4
t1 t2 t3
Figura 4.2 - Sistema multitarefa cooperativo
Por opção o software que implementa o protocolo de comunicação comporta-se como

uma tarefa. Isto tem como implicação que todas as tarefas terão de executar durante o
tempo de transmissão de um byte, ou seja, o microcontrolador deverá inquirir a
UART (Universal Asynchronous Receiver Transmitter) se esta já recebeu um novo byte
antes desta receber o próximo, de modo que se possa garantir que não se perde nenhum
byte de uma mensagem que esteja a ser recebida.
43
O ritmo de transmissão proposto é de 19.200 bps, o que corresponde a um tempo de bit

de 52 µs. Dado ser usada comunicação séria assíncrona existe um bit inicial
ST (Start bit) e um bit final SP (Stop bit). Não é usado nenhum bit de paridade. Assim,
um byte é transmitido usando 10 bit, pelo que o tempo utilizado é de aproximadamente
520 µs. Por isso o tempo máximo de ciclo de todas as tarefas não deverá exceder cerca
de 500 µs.
4.4 Estrutura e funcionamento do software de rede
A rede de comunicação implementada comporta-se como qualquer outra tarefa do nó,

ou seja, o software de rede está estruturado como uma máquina de estados.
De realçar que este tipo bus introduz a restrição que só um nó pode estar a enviar, logo
um nó nunca pode estar em dois estados simultaneamente, o que retira complexidade à
aplicação de rede.
O mecanismo de divulgação (broadcast) introduz algumas restrições devido às
confirmações. O mecanismo de difusão implementado não fornece garantias que os
receptores recebam a mensagem, porque o emissor poderá não saber quantos
intervenientes existem no sistema e, mesmo que soubesse, o processamento de
confirmações neste caso iria introduzir um grau de complexidade que não se deseja para
a aplicação de rede.
O protocolo implementado não oferece multi-cast. No caso de se necessitar de difundir
ou endereçar grupos (multicast) com confirmação, este serviço deverá ser produzido
recorrendo à utilização uma aplicação específica. Esta fica encarregue de difundir a
mensagem por um grupo de aplicações (a aplicação é que sabe quais as aplicações que
constituem cada grupo). É essa aplicação que depois gere as várias confirmações e
decide o que fazer em caso de uma ou mais confirmações não terem chegado.
44
4.5 Máquina de estados da aplicação de rede
Na figura seguinte apresenta-se a máquina de estados da aplicação de rede.
IDLE
Erro SENDING RECEIVING Erro
Não Não
Terminou? Terminou? broadcast? Sim
Sim Sim
Não
Sim broadcast? broadcast? Sim
Não Não Jamming? Não
Sim
SEND_AGAIN Erro WAIT ACK SEND ACK
JAMMING
Figura 4.3 - Máquina de estados da rede
Pela observação da Figura 4.3 concluísse que a aplicação de rede tem dois grandes
fluxos de controlo, um de recepção e outro de envio.
O estado designado por " IDLE" é um estado onde a rede fica à espera de receber ou à
espera de poder enviar, ou seja, é neste que se realiza o processo de contenção, ou onde
se verifica se este nó começa a receber uma nova trama, transitando para o estado
designado por "SENDING" e "RECEIVING" respectivamente.
45
O fluxo de envio é decomposto em três estados. O primeiro ("SENDING") envia um

byte de cada vez e escuta o que enviou. Se for diferente, gera um erro e transita para o
estado "SEND_AGAIN". Este estado é usado para verificar-se a trama deve ser
reenviada ou não. Ao fim de um certo número de reenvios sem sucesso a trama é
perdida. Quando a decisão é reenvia-la a única operação a executar é decrementar um
contador, no caso contrário a trama é perdida e liberta-se o espaço de dados. Em ambos
os casos a aplicação retorna para o estado de "IDLE".
A máquina de estados da aplicação de rede só comuta do estado "SENDING" para o
estado "WAIT_ACK" quando este termina o envio de todos os byte que compõe a
mensagem e esta não é uma mensagem de difusão.
No estado "WAIT_ACK", a aplicação de rede fica à espera da mensagem de
confirmação de baixo nível enviada pela aplicação de rede do nó de destino, se esta não
chegar dentro de um tempo predefinido a aplicação de rede do nó de origem passa para
o estado "SEND_AGAIN", processando-se da mesma forma como atrás foi descrito.
O comportamento da máquina de estados na recepção é análoga ao comportamento do
envio, pois também se subdivide em três estados, a recepção propriamente dita,
recebendo byte a byte a trama, o estado de "SEND_ACK" e o estado de "JAMMING",
também o comportamento em relação ao tipo de trama é idêntico. O segundo estado
referido é utilizado para o envio da mensagem de confirmação. Os motivos da
existência do estado designado por "JAMMING" são descritos mais a frente neste
capítulo.
4.6 Estrutura de dados
As aplicações dispõem de uma estrutura de dados designada por caixa de correio. A

aplicação de rede ao receber uma mensagem para uma aplicação coloca-a na respectiva
caixa de correio.
De modo a implementar este mecanismo, teve-se em consideração duas abordagens de
implementação deste. Uma tendo em linha de conta uma maior eficiência ao nível do
envio e da recepção de várias mensagens, e a outra de forma a reduzir o consumo dos
recursos do microcontrolador.
46
4.6.1 Duas caixas de correio por aplicação
A primeira abordagem recorre à utilização de uma zona de dados de recepção de uso

exclusivo da rede, e duas zonas de dados por cada aplicação sendo uma de recepção e
outra de composição de mensagens para envio.
UART_AVR
Network
Flags_RX Flags_TX
7 0 7 0
Rx_buffer SYSapp_Mailbox_Rx SYS_app SYSapp_Mailbox_Tx

Size 5+data Size 3+data Size 3+data
App1_Mailbox_Rx App1 App1_Mailbox_Tx

Size 3+data Size 3+data


Figura 4.4 - Estrutura de dados – duas caixas de correio por aplicação
A recepção de todas as tramas independentemente da aplicação de destino são feitas na

caixa de correio da aplicação de rede. E só no fim de se receber toda a trama, se o CRC
estiver correcto e se a caixa de correio de recepção da aplicação estiver livre, então a
aplicação de rede copia a mensagem para a caixa de correio respectiva à aplicação. Se
esta estiver ocupada a trama recebida é descartada.
A aplicação de rede é responsável por marcar o bit respectivo a cada aplicação, no
registo designado por Flags_RX, por forma a indicar à proprietária da caixa de correio
que se encontra uma nova mensagem nesta. A aplicação no fim de processar a
mensagem tem de desmarcar o bit para que possa receber mais mensagens.
Quando uma aplicação pretende enviar uma mensagem é da responsabilidade desta de
marcar bit no registo Flags_TX, de modo a indicar à aplicação de rede que a respectiva
caixa de correio contém uma mensagem para ser enviada. No fim do envio é da
responsabilidade da aplicação de rede desmarcar o bit.
47
As vantagens desta implementação são as seguintes:

§ cada aplicação tem as suas zonas próprias de dados de recepção e de envio;
§ as aplicações podem ter as suas zonas de dados de recepção ocupadas mas a
rede ainda consegue receber uma mensagem para o nó;
§ existe pois uma certa capacidade de “buffering”.
As desvantagens são as seguintes:
§ simplifica a estrutura das aplicações;
§ o dispêndio de memória de dados é significativa pois existe a duplicação de
zonas de dados;
§ o tempo de processamento para cópia de uma zona de dados de recepção
para uma zona de dados da aplicação, correspondendo a uma ineficiência
significativa.
4.6.2 Uma única caixa de correio por aplicação
Efectuou-se uma outra abordagem de modo a tornar mais eficiente e economizar o

recurso mais escasso do microcontrolador que neste caso é a memória de dados (RAM).
Com esse objectivo eliminaram-se as zonas de dados de entrada e saída as quais foram
substituídas por uma única zona de dados por aplicação. Esta zona única de dados por
aplicação serve para o envio, recepção e a composição de dados. Consegue-se esta
partilha pois uma aplicação só consegue efectuar uma acção de cada vez, ou seja, ou
escuta uma pergunta ou responde a uma pergunta.
A principal vantagem desta implementação é a economia, trazendo porém a perda do
mecanismo de buffering. Contudo, em caso de necessidade, isso pode ser implementado
ao nível da própria aplicação.
Na Figura 4.5, ilustra-se a nova estrutura de dados, de realçar que existem novos
registos de controlo, e a existência de uma pequena zona de dados da aplicação de rede.
Esta pequena zona de dados é utilizada pela aplicação de rede para receber o cabeçalho
da trama até poder decidir qual a aplicação de destino, e consequentemente qual a caixa
de correio que deverá utilizar.
48
A recepção de uma trama processa-se da seguinte forma: a aplicação de rede recebe o

cabeçalho da trama (considera-se neste caso que o cabeçalho relevante são os seguintes
campos da trama: dimensão, ilhas, destino), no fim de receber o cabeçalho a rede decide
se a mensagem é para si e se a aplicação pode receber a mensagem. Se esta poder
receber a mensagem a rede passa a utilizar a caixa de correio como sendo a nova zona
de recepção. No fim de receber a trama e de confirmar que o CRC está correcto então a
aplicação de rede marca no registo de controlo que se encontra uma mensagem válida
naquela caixa de correio. Caso contrário, a caixa de correio fica livre para a aplicação
compor ou receber uma mensagem.
O envio processa-se da mesma forma que na primeira abordagem.
UART_AVR
4
Idle_Flags Rx_buffer
Network
Sending_Flags
Receiving_Flags
SYS_app
Rx_Flags
Tx_Flags SYSapp_Mailbox
Size 3+data
App1
App1_Mailbox
Size 3+data
App2
App2_Mailbox
Size 3+data
App7
App7_Mailbox
Size 3+data
Figura 4.5 - Estrutura de dados - uma única caixa de correio por aplicação
49
4.6.3 Comparação
Na Tabela 4-1, X representa o número de aplicações e N representa a dimensão máxima

da mensagem que o nó pode receber ou enviar.
N.º Aplicações X
Duas caixas de (Ap.rede+2.X).N+registos
correio = (1+2.X).N+2
= N+2.X.N+2
Uma caixa de Cabeçalho+registos+X.N
correio = 4+5+X*N
= 9+X.N
Tabela 4-1 - Tabela de comparação de ocupação da memória - expressões
Concretizando as expressões para alguns valores.
N 6 8 16 32
X 2 Cx. C. 1 Cx. C. 2 Cx. C. 1 Cx. C. 2 Cx. C. 1 Cx. C. 2 Cx. C. 1 Cx. C.
1 20 15 26 17 50 25 98 41
2 32 21 42 25 82 41 162 73
3 44 27 58 33 114 57 226 105
4 56 33 74 41 146 73 290 137
5 68 39 90 49 178 89 354 169
6 80 45 106 57 210 105 418 201
7 92 51 122 65 242 121 482 233
8 104 57 138 73 274 137 546 265
Tabela 4-2 - Tabela de comparação de ocupação da memória - concretização
Como se pode verificar pelas Tabela 4-1 e Tabela 4-2 a 2ª abordagem permite uma
economia da memória de dados, tendendo essa economia para metade da utilizada na 1ª.
Este tipo de abordagem levanta um problema, quando surgirem duas mensagens de
seguida para uma mesma aplicação de um determinado nó, pois esta não tem a
capacidade de receber a segunda. Quando ocorre a situação atrás referida o receptor
50
tenta reenviar e não vai conseguir entregar a mensagem, ou seja, o canal fica ocupado
durante o tempo de envio e das retransmissões.
Para não se ter esse tempo perdido implementa-se um mecanismo que produz uma
colisão. O emissor ao detectar uma colisão durante a transmissão aborta-a, libertando o
canal, e verifica se deverá reenviar. Designa-se este mecanismo por jamming e é
utilizado quando o receptor detecta que a zona de dados da aplicação de destino se
encontra ocupado ou que a sua dimensão não permite a recepção da mensagem.
A real vantagem desta implementação é que o emissor pára de transmitir entre o quarto
e o quinto byte da trama. Esta imprecisão deve-se ao facto das máquinas de estados das
aplicações de rede dos diferentes nós não estarem sincronizadas. O benefício desta
abordagem é tanto maior quanto maior for a dimensão das tramas utilizadas.
Este mecanismo não é utilizado nas tramas de difusão (broadcast) porque se este nó não
tem capacidade de receber outros poderão ter, e assim não se estraga a trama que os
outros nós estão a escutar.
4.7 Aplicações
Estabelecem-se regras para a implementação de aplicações de modo que estas se tornem

compatíveis entre si.
Define-se que as aplicações possuem dois fluxos principais de controlo, que são:
• processamento não bloqueante
• processamento de mensagens, que se decompõe em:
1. atendimento de pedidos
2. envio pedidos
Na zona de processamento não bloqueante deverá estar todo o tipo de operações que
sejam necessárias executar sempre, como por exemplo, leitura de sensores. Este
conjunto deverá seguir o modelo de programação em máquinas de estado, necessário a
permitir o correcto funcionamento do núcleo multitarefa cooperativo.
O processamento de mensagens divide-se em dois fluxos mutuamente exclusivos visto
que a aplicação ou responde a um pedido ou é esta a efectuar o pedido (poderá ser um
pedido ou um alarme).
51
Quem necessitar de programar aplicações para esta rede deverá realizar as seguintes
funções por aplicação:
§ void ####_init(void) função de inicialização;
§ void ####_main(void) função de processamento não bloqueante;
§ void ####_procmsg(void) função de atendimento de pedidos;
§ byte ####_cond(void) função de teste de condições;
§ void ####_makemsg(void) função de composição de mensagens.
Em que os #### representam uma sigla de 3 a 5 letras maiúsculas que identificam uma
aplicação. Por exemplo, a aplicação de sistema é representada por SYS.
Definiram-se os seguintes estados por aplicação:

• "IDLE" estado em que a aplicação só executa o processamento não
bloqueante e verifica as condições que podem originar a composição de uma
nova mensagem;
• no estado de "RECEIVING" a aplicação em si está "IDLE" (não efectuando
os testes das condições) mas a rede está a utilizar a sua zona de dados para
efectuar a recepção de uma mensagem;
• o estado "SENDING" tem um comportamento análogo ao estado
"RECEIVING" só que neste caso a rede está a transmitir da zona de dados
da aplicação;
• "RX", encontra-se uma mensagem na caixa de correio para ser processada;
• "TX", encontra-se uma mensagem na caixa de correio para ser enviada;
• "BUSY", a zona de dados encontra-se bloqueada para a composição da
mensagem.
Se as mensagens que se enviam ou se recebem forem críticas, na perspectiva de que se

uma se perder ou se for recebida em duplicado, provocam problemas na aplicação, esta
deverá implementar mecanismos de controlo de fluxo de informação. A aplicação de
rede não fornece este tipo de serviço pois isso iria ocupar muitos recursos, obrigando a
rede a guardar o contexto de todas as comunicações em curso.
52
Por outro lado, a duplicação de tramas não levanta problemas na generalidade dos
casos, pois normalmente as operações são idempotentes. Por exemplo, indicações do
tipo ligar/desligar não originam qualquer problema se existir uma duplicação. Neste
caso, a repetição de uma ordem sobre um dispositivo limita-se a repetir a operação já
efectuada.
As caixas de correio pertencem às aplicações sendo passados ponteiros para essas zonas
para que a aplicação de rede lhes possa aceder.
As aplicações ao iniciarem-se deverão registar o seu espaço de memória na rede por
forma a que esta possa utilizar esse espaço como caixa de correio da aplicação.
4.8 Retransmissões
Identificaram-se as seguintes situações que se definem como erros de transmissão:

• nenhum nó responde;
• trama com CRC errado;
• dimensão da caixa de correio insuficiente para a dimensão da trama;
• aplicação ocupada, ou seja, a caixa de correio encontra-se ocupada.
Na primeira e segunda situação a solução será retransmitir novamente a mensagem. Na

terceira situação, não se deverá retransmitir porque este erro, eventualmente, não poderá
ser corrigido automaticamente.
Na quarta situação a aplicação encontra-se ocupada e por esse motivo não pode receber
a nova mensagem, logo esta deveria ser retransmitida logo que possível.
4.9 Identificador único
Normalmente a configuração dos sistemas de Domótica é feita previamente à instalação

no local definitivo, ou seja, os módulos são configurados isoladamente, um a um, ou
então requer técnicas em que a pessoa têm de se deslocar ao módulo e manualmente
comutá-lo para modo de programação. Ao identificar-se esta limitação nos sistemas
53
existentes propõe-se implementar um sistema de configuração automática dos nós, esta

configuração recorre à utilização de mensagens de difusão.
Ao utilizar-se mensagens de difusão levanta-se um problema de identificar qual o nó ou
nós que queremos configurar. Como solução optou-se por assegurar que todas as placas
têm um identificador unívoco.
Definiu-se que o identificador unívoco seria composto por três campos distintos:
• um campo contendo um número de série, composto por 4 byte
(4.294.967.296 dispositivos);
• um com o tipo de nó (que aplicações contém, exemplo, iluminação,
entradas/saídas, etc.), composto por 2 byte (65536 tipos diferentes);
• e um com a versão, composto também por 2 byte (65536 versões diferentes).
Com os valores atrás referidos permite-se que existam em todo o mundo

264 (1,845x1019) nós.
Com este identificador e com as mensagens de difusão consegue-se parametrizar e
configurar toda a rede de um único ponto de acesso ou a partir de um módulo de
supervisão. A utilidade deste serviço provem de que os nós não têm endereço físico
predefinido, podendo os endereços ser atribuídos dinamicamente com o nó já
incorporado no sistema.
A informação do tipo do nó e versão pode ser usada com outro objectivo, tal como
poder identificar logo o tipo de placa e o tipo de serviços respectivos.
4.10 Tabela de endereços
Como foi referido atrás, as aplicações podem gerar por sua iniciativa própria
pedidos/alarmes, necessitando de saber para onde devem enviá-los.
Pretende-se implementar uma tabela de endereços que possam ser utilizados pelas
diversas aplicações existentes num nó. Esta tabela deverá conter os dados referentes a
endereços de destino (ilha, nó, aplicação).
Estudaram-se duas abordagens possíveis para a implementação desta tabela que se
descrevem em seguida.
54
4.10.1 Endereços separados por aplicação
A tabela de endereços contém os endereços para os quais uma aplicação efectua pedidos
ou envia alarmes. Esta tabela permite configuração global ao nó dos endereços para
todas as aplicações.
Nesta abordagem implementa-se uma tabela em EEPROM contendo os endereços por
aplicação. Quando um nó é inicializado aplicação lê para memória de dados esses
endereços. A gestão da tabela é feita pela aplicação de sistema. Porém se uma aplicação
receber mensagens de parametrização que alterem os endereços de resposta, esta deverá
recorrer ao diálogo com a aplicação de sistema do seu nó de modo a efectuar a alteração
para os novos endereços de resposta.
Na Figura 4.6 esquematiza-se a implementação da tabela proposta. O primeiro byte da
tabela indica o deslocamento a efectuar relativamente aos endereços da primeira
aplicação e indica também o número de aplicações.
Índice
aplicação 1
Índice
aplicação 1
Índice
aplicação 1
Endereço 1_H
Endereço 1_L
Endereço 2_H
Endereço 2_L
Endereço N_H
Endereço N_L
Checksum
Figura 4.6 - Endereços separados por aplicação
Para se aceder a um endereço na tabela recorre-se à seguinte fórmula, não esquecendo

que um endereço físico ocupa na EEPROM 2 byte:
55
( )
endereço x da aplicação y = Índiceaplicação1 + Índiceaplicação y + x × Dimensão do endereço físico
Na Figura 4.7 ilustra-se um exemplo de uma possível tabela.

Esta abordagem permite uma complexidade baixa quer na implementação quer na
gestão. Permite também que cada aplicação possa gerir os seus endereços sem ter de
recorrer a outra entidade.
Como principal desvantagem desta implementação advém da possibilidade das
aplicações utilizarem endereços repetidos, encontrando-se estes replicados na tabela
ocupando memória desnecessariamente.
Endereço 1_1_H
Endereço 1_1_L
Endereço 1_2_H
Endereço 1_2_L
Endereço 2_1_H
Endereço 2_1_L
Endereço 3_1_H
Endereço 3_1_L
Endereço 3_2_H
Endereço 3_2_L
Endereço 3_3_H
Endereço 3_3_L
Checksum
Figura 4.7 - Endereços separados por aplicação, exemplo
Com esta abordagem e com a capacidade total de memória EEPROM disponível no

microcontrolador e tendo 8 aplicações no nó podemos ter uma tabela com 251
endereços no máximo, sendo mais do que suficiente pois representa em média 31
endereços por aplicação. Um valor que se poderá usar como referência será um
endereço de resposta por dispositivo.
56
4.10.2 Endereços virtuais
Esta segunda abordagem deriva da primeira tentando solucionar o problema de

eventuais endereços replicados.
Com esse objectivo cada aplicação funciona com uma tabela de endereços virtuais.
Cada aplicação tem um ou mais endereços que corresponde a um endereço físico. Na
figura é esquematizado as tabelas a armazenar na EEPROM do microcontrolador.
Índice N.º de
Checksum
aplicação 1 Endereços
Índice
Endereço 1_H Endereço 1_L
aplicação 2
Índice Endereço 3_H Endereço 3_L

aplicação N
Endereço 1
Endereço 2
Endereço N_H Endereço N_L

Endereço 1
Endereço 2
Endereço 1 endereços físicos

Endereço 2
Checksum
endereços virtuais
Figura 4.8 - Endereços virtuais
Como se pode observar na figura a gestão de endereços é efectuada por duas tabelas
uma com os endereços virtuais (cada um ocupa 1 byte) e outra com os endereços físicos
(cada um ocupa 2 byte). Estas duas tabelas são armazenadas na memória EEPROM.
57
Com esta abordagem e se não existirem endereços replicados entre aplicações a

capacidade máxima da tabela é de 167 endereços.
(9 + n) + (2 + 2 × n) = 512
501
n= = 167
3
Este valor é inferior ao da abordagem anterior. Porém se existirem endereços

partilhados entre diferentes aplicações a capacidade pode ser superior.
No caso limite, em que todas as aplicações têm um único endereço e este é comum entre
elas, então o espaço ocupado é de 14 byte face aos 25 byte ocupados pela primeira
abordagem.
Ao implementar-se esta tabela deverá ser implementado também um sistema de gestão
de endereços de modo a não existirem duplicações na EEPROM. O sistema de gestão
global de endereços deverá ser implementado no nó de supervisão de modo a retirar
peso computacional do microcontrolador.
Por sua vez no microcontrolador deverá também ser possível gerir a tabela de endereços
reais, a aplicação de sistema deverá ser a responsável por essa gestão de modo a garantir
que não se geram incoerências. No entanto as aplicações poderão gerir a sua tabela
utilizando diálogos com a respectiva aplicação de sistema.
A abordagem possível para gerir o número de índices por um dado endereço físico é
utilizar os 4 bit que não são utilizados na EEPROM pelo endereço físico. De relembrar
que o endereçamento físico só utiliza 12 bit (4 bit para ilha e 8 bit para o endereço de nó
e aplicação).
A principal desvantagem é o acréscimo na complexidade da implementação bem como
da gestão.
4.10.3 Comparação
Como se pode verificar pelos dois pontos anteriores a solução provavelmente a ser
utilizada num sistema de maior dimensão será o de tabelas virtuais pois normalmente os
58
nós irão comunicar com um determinado módulo de supervisão e este é que decidirá
para onde enviar. Isto é, a probabilidade é que todas as aplicações reportem para um
mesmo módulo de supervisão, pois cada nó explora o efeito da localidade e os módulos
de supervisão também deverão ser organizados por forma a contemplar e explorar
também esse efeito.
Ao nível de simplicidade a primeira abordagem é sem sombra de dúvidas a melhor
opção. Na opinião do autor, esta abordagem deverá ser utilizada em sistemas de
pequenas dimensões onde possivelmente não existem módulos de supervisão nem de
gestão.
4.11 Aplicação de sistema
Como já foi referido anteriormente tomou-se a opção de implementar uma aplicação

responsável pela gestão do nó bem como fornecer de raiz alguns serviços globais ao nó.
Os serviços implementados nesta aplicação são os seguintes:
• função pisca-pisca, para visualização de que o nó está operacional, e
interacção com o watchdog;
• gestão de serviços de marcação de tempo para as aplicações;
• gestão da tabela de endereços físicos de notificação;
• processamento das mensagens de difusão (broadcast).
Esta aplicação é responsável pelos diálogos quando o nó não tem endereço lógico
atribuído. Quando o nó se encontra neste estado só responde a tramas de difusão e
utiliza o seu identificador unívoco para sua identificação perante os outros nós (ver
ponto 4.9).
4.12 Mecanismo de decisão de envio
Em certas circunstâncias podem existir várias mensagens pendentes para envio, sendo
necessário definir que política utilizar para resolver este problema. Abordaram-se três
hipóteses possíveis para a sua resolução.
59
A primeira abordagem consiste em verificar se cada aplicação tem alguma mensagem

para transmitir, seguindo-se sempre a mesma ordem. Começa-se sempre pela
aplicação 0 (aplicação de sistema), passando depois para a aplicação 1 e assim
sucessivamente.
Na prática podemos considerar que a aplicação de menor índice é a mais prioritária face
às restantes uma vez que as suas mensagens serão sempre transmitidas primeiro do que
as das restantes aplicações. Esta abordagem é aplicada a cada nível de prioridade. Como
foi definido anteriormente, existem unicamente dois níveis de prioridade. Assim
efectua-se primeiro uma pesquisa pelas aplicações que tem mensagens prioritárias e só
depois se pesquisam as mensagens normais.
Esta abordagem tem a desvantagem que se uma aplicação mais prioritária tiver sempre
mensagens para enviar será essa a única a transmitir.
A segunda abordagem é idêntica à primeira com a diferença de que a procura é feita a
partir da última aplicação que transmitiu em vez de se começar sempre pela aplicação 0.
Como terceira abordagem recorre-se à utilização de uma fila de espera do tipo FIFO
(First In First Out) por cada nível de prioridade. Sempre que uma aplicação pretende
enviar acrescenta o seu identificador (índice) à fila de espera adequada consoante a
prioridade da mensagem.
Esta abordagem permite estruturar melhor a gestão e o controlo das retransmissões de
mensagens. Sempre que uma mensagem não é enviada com sucesso esta é colocada no
fim da fila para retransmissão posterior.
Como se pode verificar pela Figura 4.9, a implementação deste mecanismo é simples.
Cada fila de espera só ocupa no máximo 8 byte visto que no sistema implementado só
existem no máximo 8 aplicações e cada aplicação só pode transmitir uma mensagem de
cada vez (cada aplicação só tem uma zona de dados de envio e recepção). Aproveita-se
esta fila de espera para incluir não só o índice de aplicação bem como o número de
retransmissões já efectuadas.
De salientar que nas duas primeiras hipóteses a ordem de envio está directamente
relacionada como o índice da aplicação, enquanto na última hipótese as mensagens são
enviadas pela ordem em que foram geradas. Esta abordagem é a mais justa das três na
medida em que garante que quem gerou primeiro uma mensagem é quem transmite
primeiro.
60
Número P_leitura P_escrita
Reservados Repetição Aplicação
Figura 4.9 - Fila de espera de envio de mensagens
Na implementação actual, por razões de simplicidade, optou-se pela primeira hipótese

(notar que não se considera muito provável que num mesmo nó existam várias
mensagens pendentes).
4.13 Bridge
Dada a arquitectura proposta para o sistema, em que podem existir múltiplos troços de
rede, torna-se necessário o recurso a uma bridge para interligar dois troços. Esta bridge,
para permitir uma maior largura de banda do sistema global, oferece a capacidade de
filtragem de mensagens de modo a que as mensagens locais a um troço não interferem
com as mensagens noutros troços.
As bridges só deixam passar o tráfego correspondente à sua ilha ou só permitem que
saia dessa ilha o tráfego que pertence a outra ilha que não a sua.
Ao implementar as bridges deve ser dispensada uma atenção cuidada para não
introduzir quebras de desempenho na rede, dado que estas provocam atrasos na entrega
das tramas ao destinatário. As mensagens emitidas, em vez de serem imediatamente
recebidas pelo nó de destino, são recebidas pela bridge que as reenvia para outro troço
de rede.
A bridge comporta-se como um nó especial que recebe a trama e envia a confirmação
de baixo nível. O nó de origem fica apenas à espera da confirmação ao nível da
aplicação.
61
A bridge comunica com o nó de destino, ou com outra bridge, reenviando a trama e

recebendo a confirmação de baixo nível. Caso a trama necessite atravessar outras
bridges, o processo descrito é repetido sucessivamente até que a trama chegue ao nó de
destino. Este mecanismo tem como desvantagem óbvia o aumento do tempo de entrega
das tramas, podendo obrigar a que as aplicações tenham de aumentar o tempo de espera
da resposta. Convém notar que, para a arquitectura proposta, o pior caso corresponde ao
da Figura 3.5, em que a trama necessita atravessar duas bridges.
Como é suposto explorar a localidade das operações o tráfego para fora das ilhas será
diminuto. Logo os atrasos introduzidos não serão significativos no desempenho global
do sistema.
Por forma a implementar a bridge recorre-se à utilização de dois microcontroladores.
Cada um deles é responsável pela comunicação com um dos troços e trocam as
mensagens entre si.
As bridges ao receberem uma trama de difusão deverão enviá-la para o outro troço.
Eventualmente poderão verificar se esta trama contém uma mensagem para ela própria
e, se assim for, deverá ser entregue à aplicação de sistema da bridge. Este mecanismo
permite um diálogo com as bridges e possibilita a sua parametrização.
Notar que nada impede que possam ser criadas bridges com a possibilidade de acesso a
mais do que uma ilha, o que poderá ser útil em topologias mais complexas.
4.14 Gateway
Para permitir a interligação do sistema domótico a outros equipamentos que não sejam
nós recorre-se a um gateway. Este é semelhante a uma bridge ao nível do hardware mas
ao nível do software distingue-se por possuir um endereço.
Quando se pretende comunicar com o exterior comunica-se para esse endereço e para
uma das 7 aplicações possíveis do gateway, permitindo que este tenha até 7 canais
distintos de comunicação com o exterior.
Não existe limite para o número de gateways que um sistema pode conter.
62
4.15 Recursos utilizados pela aplicação de rede
Implementa-se um protótipo da rede descrita tendo constatado que ocupa os recursos

discriminados na Tabela 4-3 e nas Figura 4.10 e Figura 4.11.
Ocupado Livre
Byte % Byte %
Memória Código 1940 23,68
de 6252 76,08
Programa Constantes 20 0,24
Memória
Variáveis 56 10,94 456 89,06
de Dados
Tabela 4-3 - Taxa de ocupação da aplicação de rede
Figura 4.10 - Taxa de ocupação da memória de programa da aplicação de rede
63
Figura 4.11 - Taxa de ocupação memória de dados da aplicação de rede
Como se pode constatar, os recursos ocupados são mínimos existindo bastantes recursos
livres para a implementação de aplicações. Deste modo os objectivos propostos foram
atingidos.
64
Capítulo
5 Comparação e resultados experimentais
Conteúdo
5.1 INTRODUÇÃO .......................................................................................................... 66
5.2 COMPARAÇÃO......................................................................................................... 66
5.3 RESULTADOS EXPERIMENTAIS ............................................................................... 68
65
5.1 Introdução
Neste capítulo efectua-se um pequeno resumo e comparação entre as principais

tecnologias disponíveis actualmente e a nossa proposta. Referem-se as capacidades de
endereçamento, a taxa de transmissão e o comprimento máximo da linha de rede.
Descreve-se também como foram efectuados alguns testes e analisam-se os resultados
obtidos.
5.2 Comparação
5.2.1 CEBus
O CEBus tem um endereçamento planar composto por:

§ endereço de sistema (SA) - 16 bit
§ endereço de nó (NA) - 16 bit
Permitindo uma capacidade total de endereçamento de 65.536 (216) dispositivos por
habitação.
A taxa de transmissão usando par entrançado é de 10.000 bps. O comprimento máximo

cabo de rede é de 1520 m.
5.2.2 EIB
As capacidades de um sistema EIB são:

§ dispositivos por segmento de linha - 64
§ dispositivos por segmento de linha com a inclusão de
4 repetidores - 256
§ segmentos lógicos ligados por "Line Couplers" (LC) - 12
§ áreas ligadas por "Bus Area" (BC) - 15
Sendo a capacidade total de endereçamento de 46.080 (256 × 12 × 15 ) dispositivos.
Contudo, nem todos os dispositivos podem comunicar entre si, pois existe um número
máximo (esse número é 6) de repetidores de linha, LC e BC que uma trama pode
66
percorrer. Assim, o número total de dispositivos quando se pretende que todos possam
comunicar com todos fica reduzido a 11.520 dispositivos.
A taxa de transmissão usada é de 9.600 bps. A linha da rede de comunicação tem um
comprimento máximo de 1000m, com uma distância máxima entre dois dispositivos de
700m.
5.2.3 LonWorks
O LonWorks permite ter:

§
Nós por subrede 127
§
Subredes por domínio 255
§
Nós por domínio 32385 (127 × 255 )
§
Domínios numa rede 248
Com as capacidades atrás descritas é possível ter 32 K × 2 48 como o número máximo de
nós .
A taxa de transmissão é de 78 kbps. O comprimento máximo de uma linha é de 1330 m,
com uma distância máxima entre dois dispositivos de 500m.
5.2.4 Rede proposta
A rede proposta que o sistema tenha:

§ ilhas - 16
§ nós por ilha - 32
A capacidade de endereçamento total é de 511 nós. Porém, cada nó pode conter até 7
aplicações (índice de 1 a 7) genéricas (a aplicação 0 está reservada para funções de
gestão do próprio nó). E cada aplicação pode controlar um número variável de
67
dispositivos apenas limitado pelos recursos de hardware disponíveis (por exemplo, o

número de entradas/saídas existentes).
Para o protótipo implementado, esse limite é de 20 entradas/saídas. Se tivermos em
consideração este valor, temos como o número máximo de dispositivos 10.220
(511× 20 ) .
Teoricamente, será possível que cada aplicação possa aceder até 28 dispositivos (visto
que, internamente às aplicações será usado um byte para identificar os seus dispositivos)
e portanto o valor teórico máximo é de 1.785 (511 × 7 × 255) .
A taxa de transmissão é de 19.200 bps, a linha de rede sem recorrer a repetidores de
linha permite um comprimento máximo de 1200m.
Pode-se concluir que a rede proposta possui uma capacidade de endereçamento mais
reduzida ao nível dos nós, mas os pontos de controlo que esta permite ter são da mesma
ordem de grandeza do EIB.
Dados os objectivos principais deste sistema serem: o mais simples e económico
possível, e estar vocacionado preferencialmente para as habitações. Assim, pode
concluir-se que o número de pontos de controlo é perfeitamente suficiente para a
aplicação pretendida.
5.3 Resultados experimentais
Apresentam-se em seguida alguns resultados experimentais relativamente ao tempo de

processamento e outras medidas de desempenho da rede, os quais são pormenorizados
nos pontos 5.3.1 e 5.3.2 respectivamente.
Para se efectuarem testes na rede existiu a necessidade de utilizar vários protótipos de
nós bem como implementar mecanismos automáticos para produzirem estatísticas das
grandezas que se pretendem analisar.
Utilizou-se nos testes o seguinte hardware:
§ 1 backplane - módulo que funciona como um troço de rede, permitindo a
interligação de cinco nós, fornecendo também a alimentação aos nós;
§ 5 nós genéricos;
68
§ 1 sniffer - módulo que escuta todos os byte transmitidos na rede e os envia

para um PC por forma a monitorizar a rede; este módulo é constituído por
dois microcontroladores idênticos aos usados nos nós, um que escuta a rede
e outro que comunica com o PC.
5.3.1 Tempos de processamento
Um dos pontos fundamentais a monitorizar nos nós é o tempo de processamento

inerente às aplicações de rede e de sistema. Monitoriza-se o tempo máximo de
processamento de cada uma das aplicações referidas, o que permite determinar o tempo
de processamento disponível para as restantes aplicações. Este tempo é calculado
subtraindo o tempo medido ao valor máximo anteriormente definido de cerca de 500 µs
(ver ponto 4.3).
A medida é efectuada contabilizando o tempo entre a chamada à aplicação e a saída
desta. Determina-se o tempo mínimo e máximo gasto, sendo este último o valor mais
relevante pois é este que limita o tempo disponível.
Implementou-se a seguinte plataforma de testes: utilizam-se cinco nós, em que quatro
(Nó 1 a Nó 4) incluem a aplicação de rede, a aplicação de sistema e uma aplicação que
envia mensagens para uma aplicação noutro nó. O quinto nó (Nó 5) contém quatro
aplicações que recebem mensagens dos nós 1 a 4, e contém também as aplicações de
rede e de sistema.
Todas aplicações de sistema respondem a mensagens de divulgação transmitindo os
dados monitorizados.
Os nós 1 a 4 são idênticos, sendo o seu código igual excepto no endereço. Utilizou-se
cada nó para contabilizar um valor em particular. Assim, o nó 1 contabiliza o tempo
total de processamento, o nó 2 o tempo da aplicação de sistema, o nó 3 contabiliza a
aplicação que envia mensagens e, por fim, o nó 4 contabiliza o tempo da aplicação de
rede. Optou-se por esta abordagem pois o cálculo deste tempo consome diversos
recursos do microcontrolador e, deste modo, efectua-se uma distribuição do
processamento pelos diferentes nós.
69
De seguida apresentam-se em tabela os resultados práticos obtidos e efectuam-se alguns

cálculos para se obter o tempo de processamento disponível.
µ s]
Máximo [µ µ s]
Mínimo [µ
Nó 1 - tempo total 193 52
Nó 2 - aplicação de sistema 30 17
Nó 3 - aplicação de teste 52 17
Nó 4 - rede (a enviar) 162 21
Nó 5 - rede (a receber) 126 20
Tabela 5-1 - Tempo de processamento
Na Tabela 5-2 apresenta-se a taxa de ocupação de tempo de processamento,

relativamente ao máximo possível de 500 µs.
Máximo Mínimo
[% ocupação] [% ocupação]
Nó 1 - tempo total 38,60 10,40
Nó 2 - aplicação de sistema 6,00 3,40
Nó 3 - aplicação de teste 10,40 3,40
Nó 4 - rede (a enviar) 32,40 4,20
Nó 5 - rede (a receber) 25,20 4,00
Tabela 5-2 - Taxa de ocupação de tempo de processamento
Como se pode verificar pelas tabelas, a rede e as aplicações implementadas ocupam

uma parcela aceitável dos recursos de processamento disponíveis. Na pior situação, rede
a enviar, esta ocupa 32,4 % do tempo total de processamento disponível, ficando livre
67,6 % para as restantes aplicações (o que corresponde a 338 µs). Quem desenvolver as
aplicações para um nó terá a responsabilidade de assegurar que esse tempo não é
ultrapassado.
O valor disponibilizado pode parecer reduzido, mas quando se pretende efectuar
aplicações de uma maior complexidade, a coexistência desta com outras aplicações no
mesmo nó não será muito provável. Pois normalmente quando se tem uma aplicação
70
mais exigente ao nível do tempo de processamento, esta também o é relativamente aos

outros recursos do microcontrolador, tais como memória de programa, memória de
dados e provavelmente em relação ao número de entradas/saídas.
5.3.2 Medidas de desempenho da rede
Com o objectivo de conhecer detalhes sobre o comportamento da rede implementou-se

um mecanismo que contabiliza as seguintes situações:
§ número de colisões, só detectado no emissor, porque este é o único que pode
detectar esta situação;
§ número de mensagens perdidas na emissão;
§ número de retransmissões;
§ número de vezes que expira o tempo para recepção da confirmação de baixo
nível;
§ número de mensagens enviadas com sucesso, i. e., aquelas em que o emissor
recebe a confirmação de baixo nível;
§ o número de jamming efectuados devido à aplicação estar no estado de
"busy", tramas comuns;
§ o número de confirmações enviadas, útil para se detectar perdas de
confirmações de baixo nível.
Efectuaram-se ensaios de modo a obter resultados práticos, utilizando-se a mesma

plataforma de testes atrás descrita. Abordaram-se duas situações distintas com o
objectivo de avaliar o benefício de usar uma componente aleatória no acesso ao meio.
Assim, efectuaram-se testes com e sem essa componente, em situações de carga normal
e muito elevada.
Considerou-se como carga normal cada nó enviar uma mensagem de meio em meio
segundo. Na situação de carga muito elevada, as aplicações estão sistematicamente a
enviar mensagens, bastando para tal que tenham a caixa de correio disponível.
Os nós 1 a 4 enviam mensagens com dimensão 10 byte. Utilizou-se este valor pois a
mensagens de controlo são normalmente reduzidas, pelo que se considerou um campo
71
de dados de 4 byte o que permite identificar um dispositivo, definir uma acção e

fornecer um valor de 16 bit.
Foram efectuados múltiplos ensaios, repetidamente, de modo a obter uma amostra
representativa das medidas de desempenho da rede.
Tramas sem confirmação

Confirmações enviadas
Envio com Sucesso
Tramas Perdidas
Retransmissões
Colisões
Nó 1 0 119 0 0 0 0
Nó 2 0 119 0 0 0 0
Nó 3 0 120 0 0 0 0
Nó 4 0 119 0 0 0 0
Nó 5 0 0 477 0 0 0
Total 0 477 477 0 0 0
Tabela 5-3 - Teste com componente aleatória de acesso ao meio e envio de

mensagens com intervalos de 0,5 segundos
72

Envio com Sucesso
Tramas Perdidas
Retransmissões
Colisões
Nó 1 0 120 0 0 0 0
Nó 2 0 119 0 0 0 0
Nó 3 0 119 0 0 0 0
Nó 4 0 119 0 0 0 0
Nó 5 0 0 477 0 0 0
Total 0 477 477 0 0 0
Tabela 5-4 - Teste sem componente aleatória de acesso ao meio e envio de

mensagens com intervalos de 0,5 segundos
Envio com Sucesso
Tramas Perdidas
Retransmissões
Colisões
Nó 1 15 1834 0 17 0 2
Nó 2 310 1612 0 304 6 0
Nó 3 126 1734 0 148 0 2
Nó 4 125 1717 0 131 2 8
Nó 5 0 0 6916 0 0 0
Total 576 6897 6916 600 8 12
Tabela 5-5 - Teste com componente aleatória de acesso ao meio e envio de

mensagens sem intervalos
73

Envio com Sucesso
Tramas Perdidas
Retransmissões
Nó 1 Colisões 58 1730 0 60 1 3
Nó 2 502 1583 0 463 39 0
Nó 3 444 1858 0 456 14 1
Nó 4 270 1738 0 262 16 8
Nó 5 0 0 6933 0 0 0
Total 1274 6909 6933 1241 70 12
Tabela 5-6 - Teste sem componente aleatória de acesso ao meio e envio de

mensagens sem intervalos
Analisando as tabelas pode-se concluir que, em situação de carga normal, a existência

da componente aleatória no acesso ao meio não é significativa pois, como se pode
verificar, nos ensaios realizados não se detectou nenhuma colisão.
O mesmo não se verifica quando se passa para carga muito elevada. Neste caso, o
número de colisões aumentou significativamente, passando de 576 para 1274 (aumento
de 221%).
Um aspecto interessante que convém notar quando se retira a componente aleatória no
acesso ao meio, é que ocorreu um ligeiro aumento do número de mensagens enviadas
com sucesso, tendo passado de 6897 para 6909 (aumento de 1%). Isto pode ser
justificado pelo acesso ao meio ser menos demorado, o que possibilita o envio de mais
tramas no mesmo intervalo de tempo. Porém, convém realçar que o número de tramas
perdidas, ou seja, as que nunca chegam ao destinatário, passa de 8 para 70, o que é
bastante negativo, podendo este aumento ser justificado pelo elevado número de
colisões.
Desta forma conclui-se que existe um claro benefício em usar a componente aleatória
no acesso ao meio físico, particularmente nas situações de tráfego muito elevado.
74
Por análise da Tabela 5-5 conclui-se que durante um minuto foram enviadas 6897
tramas com sucesso, o que corresponde a cerca de 114 tramas por segundo. Este valor
parece-nos perfeitamente adequado aos objectivos propostos.
75
Capítulo
6 Interoperacionalidade
Conteúdo
6.1 INTRODUÇÃO .......................................................................................................... 77
6.2 MODELO DE INTERACÇÃO ...................................................................................... 77
6.3 CENÁRIOS ............................................................................................................... 80
6.4 CONTROLO DE FLUXO DE INFORMAÇÃO................................................................. 81
76
6.1 Introdução
Pretende-se oferecer uma abordagem ao nível do sistema global e não apenas ao nível
da rede de comunicação. Esta última apenas oferece o meio para a interacção mas não
especifica como é que essa interacção ocorre.
Para que um grupo de dispositivos possam ser designados de sistema, necessitam de
poder cooperar e interagir uns com os outros, ou seja, é necessário existir um suporte à
interoperação.
Com este objectivo deve ser desenvolvida uma forma genérica de diálogo ao nível das
aplicações. Para tal, propõe-se o desenvolvimento de uma pseudo linguagem para
diálogo entre aplicações.
Esta implementação deverá permitir que um dispositivo tenha a capacidade de informar
alterações do seu estado e de modificar estados de outros dispositivos. Adicionalmente
pretende-se que isso possa ocorrer sem necessitar recorrer a uma entidade superior que
actue como um nó central de tomada de decisões. Pretende-se, por exemplo, que uma
entrada digital tenha a capacidade de informar que o seu estado mudou e,
eventualmente, modificar o estado de outro dispositivo.
6.2 Modelo de interacção
A capacidade de interacção entre dispositivos consegue-se introduzir nos nós através da

parametrização das aplicações para enviar mensagens predefinidas sempre que um
dispositivo muda para um determinado estado.
Para uniformizar estas mensagens definiu-se um modelo genérico de dispositivo.
Segundo este modelo, um dispositivo é considerado como um objecto que pode estar
em um de entre vários estados e esses estados podem ter um número variável de
atributos.
Com o modelo atrás definido pretende-se que a aplicação de origem não necessite
conhecer pormenores acerca da aplicação de destino, mas unicamente necessite saber
para que estado o dispositivo deve mudar e quais os atributos desse estado.
77
Em seguida exemplifica-se a aplicação deste modelo a dispositivos comuns:
Dispositivo Estados Atributos

Ligada 0 atributos --------------------------
Lâmpada 3 estados Desligada 0 atributos --------------------------
Regulada 1 atributo intensidade
Sensor de Desligado 0 atributos --------------------------
2 estados
temperatura Operacional 1 atributo valor da temperatura
Desligado 0 atributos --------------------------
temperatura desejada
Ar-condicionado 2 estados
Ligado 2 atributos velocidade de
ventilação
Tabela 6-1 – Aplicação do modelo genérico a dispositivos comuns
As mensagens de interacção são endereçadas a uma dada aplicação, referenciam um

dispositivo desta e explicitam um dos seus estados com os respectivos atributos.
Este modelo de interacção pode ser utilizado de duas formas. Pode ser utilizado numa
aproximação simples em que as aplicações podem ser configuradas de modo a enviarem
mensagens predefinidas sempre que um dispositivo passa para um dado estado. Esta é a
solução mais adequada para sistemas com interacções simples onde as acções
desencadeadas não dependem de múltiplas condições. Neste caso, é possível dispensar o
uso de nós de supervisão.
Quando se necessita de um sistema com interacções mais complexas e em que as acções
são desencadeadas em função de múltiplas condições, é necessário recorrer a um ou
mais nós de supervisão. Nesta aproximação as aplicações informam o nó de supervisão
sempre que um dispositivo muda de estado, sendo da sua responsabilidade verificar se
as condições definidas se verificam e, em caso afirmativo, desencadear as acções
estipuladas.
As mensagens predefinidas deverão ser armazenadas numa tabela de mensagens, de

preferência em memória do tipo EEPROM. Ao implementar-se a tabela atrás referida
78
deve-se ter em conta a possibilidade de existirem mensagens replicadas, pelo que

convém optimizar a organização desta, devendo contemplar a utilização da mesma
mensagem por vários dispositivos.
Na Figura 6.1 ilustra-se uma solução possível para armazenar a tabela atrás referida.
Deslocamento N.º de
Checksum
1ª Aplicação Mensagem
Deslocamento
Mensagem 1
2ª Aplicação
Mensagem 2
Deslocamento Mensagem 3
nª Aplicação
Mensagem 4
Mensagem 1
Mensagem 2
Mensagem N
Mensagem 1
Mensagem 2
Mensagem 1
Mensagem 2
Checksum
Índices Mensagens predefinidas

de
mensagens
Figura 6.1 - Tabela de mensagens
A tabela é constituída por duas partes distintas. Uma contém as mensagens predefinidas
e a outra contém índices para estas, por aplicação/dispositivo. Para se determinar qual é
a mensagem para um dado dispositivo indexa-se a tabela de mensagens recorrendo ao
índice de aplicação e ao índice de dispositivo dentro da aplicação.
79
Assim, ao implementar-se esta forma de interacção, permite-se que uma aplicação

dialogue com outras sem necessidade desta entender o que está a enviar (por exemplo,
uma aplicação não necessita saber se está a lidar com uma lâmpada ou com um motor,
limitando-se a enviar a mensagem guardada na tabela).
Este aspecto poderá ser interpretado como uma desvantagem o que na realidade para o
tipo de utilização que se pretende dar ao sistema não é, pois o conhecimento está no
gestor do sistema ou nos nós de supervisão, permitindo simplificar os nós comuns.
Além disso, permite que ao desenvolver-se novas aplicações a interoperacionalidade
entre elas continue a existir, necessitando apenas de se parametrizar quais as novas
mensagens que devem ser enviadas.
Compete à entidade de supervisão global do sistema definir quais as mensagens que

cada nó deve enviar e em que circunstâncias. De notar que, após a parametrização dos
nós, estes podem funcionar autonomamente, independentemente se o nó de gestão se
encontra activo ou não.
6.3 Cenários
A abordagem seguida é simples mas possui limitações caso se pretenda desencadear

mais do que uma acção quando um dispositivo atinge um determinado estado. Por
exemplo, pode haver a necessidade de ligar uma lâmpada e accionar um sinal sonoro
quando um interruptor é pressionado. Isto não é possível num nó comum, sendo
necessário recorrer a um nó de supervisão.
Por outro lado, pode haver necessidade de certas acções só serem realizadas caso se
verifiquem várias condições em simultâneo. Neste caso torna-se também necessário
recorrer a um nó de supervisão.
Para lidar com as situações indicadas acima propõe-se o uso de cenários. Um cenário é
definido como um conjunto de acções que são desencadeadas quando se verificam
determinadas condições.
Os cenários são geridos por nós de supervisão. Para que eles possam realizar esta tarefa
necessitam de ser informados sempre que um dispositivo muda de estado. Isso é
80
conseguido parametrizando os dispositivos, definindo que mensagens predefinidas estes

devem enviar e para que endereços (neste caso, para o nó de supervisão).
O nó de supervisão deverá ainda poder lidar com condições de tempo para permitir que
sejam desencadeadas acções a determinada hora ou ao fim de certo tempo.
6.4 Controlo de fluxo de informação
A rede implementada apenas consegue garantir que esta faz o melhor que pode para
entregar as mensagens. As mensagens ao fim de 3 retransmissões sem sucesso são
eliminadas, não existindo pois qualquer garantia de entrega.
Para que exista tal garantia é necessário que exista confirmação ao nível da aplicação
(só depois de receber uma ordem/pedido e de a executar é que informa que já fez).
Porém, esta solução também pode levantar alguns problemas caso, por exemplo, uma
confirmação se atrase muito. Neste caso o emissor pode tornar a efectuar a
ordem/pedido e receber a confirmação relativa à ordem anterior.
Como solução para este problema sugere-se que seja implementado um mecanismo de
numeração de tramas. Este mecanismo deve ser implementado sempre que se está em
presença de operações não idempotentes. As aplicações devem estabelecer um canal de
comunicação entre si e controlar o fluxo de mensagens usando numeração. Isto, na
prática, corresponde à implementação de um nível de transporte, de acordo com o
modelo OSI.
81
Capítulo
7 Conclusões
Conteúdo
7.1 CONCLUSÕES .......................................................................................................... 83
7.2 DESENVOLVIMENTOS FUTUROS .............................................................................. 84
82
7.1 Conclusões
No presente trabalho, após estudo das características fundamentais das principais

tecnologias aplicáveis à domótica, propôs-se uma nova abordagem, sendo definida uma
arquitectura de sistema e um protocolo de comunicação.
Em termos de domínio de aplicabilidade, a nossa proposta encontra-se essencialmente
vocacionada para o controlo e automação de edifícios habitacionais. Nos casos onde o
volume de dados seja elevado, a rede proposta não é a mais adequada sendo preferível,
por exemplo, recorrer à utilização de uma rede Ethernet. Neste caso, já seriam possíveis
serviços mais exigentes que envolvessem, por exemplo, a transmissão de sinais de voz e
vídeo ou a transmissão de grandes quantidades de informação.
A nossa proposta oferece uma solução de muito baixo custo e que pode ser facilmente
replicada usando componentes comuns. Porém, não se descuidou o aspecto do
desempenho, garantindo-se uma boa aplicabilidade a tarefas de controlo e automação.
O sistema é constituído por nós que comunicam entre si e cada um destes tem a
capacidade de controlar múltiplos dispositivos (sensores/actuadores). Propôs-se uma
estrutura de hardware onde os nós são constituídos essencialmente por um
microcontrolador e um transceiver EIA-485 para o acesso ao meio físico de
comunicação.
Definiu-se também uma estrutura de software para os nós que suporta a execução de
múltiplas tarefas. Cada tarefa pode controlar vários dispositivos. Deste modo é possível
rentabilizar ao máximo os recursos hardware de um nó. O número de dispositivos
controlados por um nó está apenas limitado pelas capacidades do microcontrolador
usado, em particular pelo número de entradas/saídas e memória disponível.
A rede implementada usa tramas constituídas por caracteres que são enviados usando
comunicação série assíncrona a um ritmo de 19.200 bps.
O protocolo de comunicação realizado consome cerca de 2 Kbyte de memória de
programa e cerca de 60 byte de memória de dados. Estes valores são suficientemente
baixos para permitir a sua implementação na generalidade dos microcontroladores
disponíveis actualmente. Outros requisitos importantes são a existência de uma UART e
de um temporizador.
83
Foram efectuados testes de desempenho da rede de comunicação, destacando-se a

capacidade de envio de um máximo de cerca de 114 tramas por segundo, tendo cada
trama um comprimento de 10 byte.
Tendo por base os diversos ensaios efectuados, concluímos que a rede desenvolvida
atinge os objectivos a que nos tínhamos proposto. Adicionalmente, este trabalho teve o
mérito de permitir uma compreensão detalhada e profunda das opções de outros
sistemas, bem como equacionar novas soluções à medida que os problemas iam sendo
identificados. Os desenvolvimentos efectuados permitem dispor de uma plataforma
excelente para implementação e teste de aplicações no domínio da domótica,
constituindo-se também como uma plataforma didáctica para todos aqueles que se
interessam por esta área de investigação.
7.2 Desenvolvimentos futuros
Não foi possível no âmbito do presente trabalho efectuar todos os desenvolvimentos

necessários para que no fim deste se tivesse um sistema completo e acabado, dada a
vastidão de áreas de intervenção. Refere-se em particular a interacção entre aplicações
onde apenas se definiu um modelo de abordagem ao problema não tendo sido possível
implementá-lo e testá-lo.
Sugerem-se em seguida alguns desenvolvimentos futuros. Um primeiro ponto a abordar
refere-se à implementação de nós de supervisão, para o que, numa primeira abordagem,
poderiam ser usados PC’s embebidos (embedded PCs) ou mesmo PC’s comuns. Isso
permitiria a implementação e teste do modelo de gestão do sistema domótico tendo por
base o uso de cenários.
Outro aspecto que futuramente faz sentido abordar refere-se ao uso de diferentes meios
de comunicação como, por exemplo, infravermelhos ou rádio frequência. Neste
momento estas tecnologias ainda não conseguem competir ao nível da facilidade de
obtenção, da simplicidade de implementação e do custo, relativamente ao uso de
transceivers EIA-485.
Refere-se também o interesse de explorar a interacção do sistema proposto com outros
sistemas (domóticos ou não) e o recurso a TCP/IP como protocolo preferencial de
interligação.
84
Ao nível da segurança sugere-se que sejam implementados mecanismos de modo a ser

possível detectar tentativas indevidas de acesso ao sistema. Por exemplo, será
conveniente ter a capacidade de detectar que alguém introduziu um nó com o intuito de
executar operações não autorizadas ou aceder a informação restrita.
Por fim, deverá ser desenvolvido trabalho na área das ferramentas de software, quer na
configuração e parametrização do sistema, quer na sua gestão. Em particular, deverá ser
despendida especial atenção na interface com o utilizador, de modo a que seja o mais
fácil e intuitivo possível o uso do sistema pela generalidade das pessoas. Ao nível da
interacção será também interessante explorar meios que permitam o uso do sistema por
pessoas com necessidades especiais recorrendo, por exemplo, a comandos por voz.
85
Bibliografia
86
Rede Domótica Bibliografia
[1] - Grayson Evans, "The CEBus Standard User's Guide", 1996
[2] - http://www.cebus.org
[3] - Norma EIA-600 - EIB
[4] - http://www.eiba.org
[5] - Handbook of Building System Engineering - EIB
[6] - EIB Technical Information
[7] - Gerd E. Keiser, "Local Area Networks", McGraw-Hill,1989
[8] - Bhargav P. Upender , Philip J. Koopman Jr., Communication Protocols for

Embedded Systems, Embedded Systems Programming, 7(11), November 1994, pp. 46-
58.
[9] - http://www.atmel.com
[10] - "Introduction to the LonWorks Platform", Echelon Corporation, extraido do

CD-ROM de documentação da Echelon Corporation
[11] - www.echelon.com
[12] - Hans-Peter Messmer, "The Indispensable PC Hardware Book", Second Edition,

1995, Addison-Wesley
[13] - www.x10.com
[14] - R. Nunes, C. Sêrro, “Edifícios Inteligentes: Conceitos e serviços”, Técnica –

Revista de Engenharia, n.º 3, Setembro de 1996, pp. 5-15
87
Rede Domótica Bibliografia
[15] - Manuel Mota Ferreira, “Sistema Integrado para Casa Inteligentes”, Tese de
Mestrado em Engenharia Electrotécnica e de Computadores, Instituto Superior Técnico,
Dezembro de 1995
[16] - Renato Nunes, José Delgado, "An Architecture for a Home Automation System",
ICECS'98 - International Conference on Electronics, Circuits and Systems, Setembro
1998, pp.259-262.
[17] - Renato Nunes, José Delgado, "An Internet Application for Home Automation",
MELECON 2000, Maio 2000, pp.298-301.
88

Master Thesis

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Master Thesis

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE TÉCNICA DE LISBOA

INSTITUTO SUPERIOR TÉCNICO

Pedro Miguel Florindo Miguens Matutino

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

INSTITUTO SUPERIOR TÉCNICO

Pedro Miguel Florindo Miguens Matutino

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

As redes Domóticas têm vindo a assumir um papel de importância crescente em

5 COMPARAÇÃO E RESULTADOS EXPERIMENTAIS 65

Figura 2.1 - Distribuição geográfica dos principais sistemas............................................. 7

Tabela 3-1 - Capacidades teóricas da rede proposta ......................................................... 37

1.2 Objectivos e contributos

O presente trabalho dá um contributo para a área da domótica esperando-se que possa

1.3 Organização da tese

A tese encontra-se organizada em 7 capítulos. No capítulo 2 descrevem-se as

No capítulo 4 descrevem-se os detalhes de implementação do protocolo, define-se a

O termo Domótica está associado à automatização de habitações e a sua origem

A domótica despertou um grande interesse em diversos grupos económicos, tendo

Figura 2.1 - Distribuição geográfica dos principais sistemas

Os sistemas que demonstram uma maior penetração no mercado habitacional e que de

O CEBus é uma norma Americana produzida pela EIA (Electronics Industries

O Sistema EIB é uma marca registada da EIBA (European Installation Bus

Descreve-se em seguida, com mais detalhe, cada um destes protocolos.

Os dispositivos desta tecnologia utilizam ligações esporádicas uns com os outros, de

A norma CEBus disponibiliza vários meios físicos de transmissão:

§ Rádio frequência (RF - Radio-Frequency), utilizando uma portadora nos 915

Linha de energia eléctrica

Figura 2.2 - Ligações entre diferentes meios de transmissão

Figura 2.3 - Camadas constituintes de um dispositivo CEBus

2.2.1 O protocolo CEBus e o Modelo OSI

Modelo OSI Modelo CEBus

Ligação de Dados Ligação de Dados

Figura 2.4 - Protocolo CEBus vs. Modelo OSI

2.2.2 Modelo de comunicação dispositivo a dispositivo

Aplicação Função Aplicação

CAL mensagem CAL CAL

Rede NPDU APDU Rede

Ligação de Dados DLPDU NPDU Ligação de Dados

Física DLPDU Física

Figura 2.5 - Comunicação entre dispositivos

2.2.3 Formato da trama

Como resultado da contribuição das várias camadas do protocolo, obtém-se a estrutura

DLPDU cabeçalho NPDU APDU

Figura 2.6 - Formato da trama CEBus

O campo de preâmbulo é constituído por um valor aleatório de 8 bit, este é utilizado

2.2.4 Acesso ao canal

O acesso ao canal é feito usando o método CSMA (Carrier Sense Multiple

A resolução de colisões é conseguida através da sobreposição de valores lógicos.

Figura 2.7 - Ilustração do mecanismo de contenção

2.3.2 Estrutura dos nós

Um dispositivo EIB é composto por um unidade de acoplamento ao barramento

Figura 2.8 - Formato da trama EIB

O campo de controlo da trama tem como objectivo atribuir prioridades de transmissão

O campo atrás referido é utilizado para controlar o mecanismo de IACK (confirmação

§ se a confirmação é destruída, a camada de ligação do emissor retransmite o

O EIB define quatro níveis de prioridade:

No EIB não é possível garantir a não existência de duplicação de mensagem pois um

2.3.4 Acesso ao canal

Figura 2.9 - Estrutura de uma palavra EIB

Figura 2.10 - Tempo de palavra EIB

Figura 2.11 - Tempo entre mensagens EIB

A rede LonWorks permite um processamento distribuído, realizado por dispositivos

O LonWorks implementa uma rede de dispositivos com a capacidade de comunicação

De modo a simplificar a configuração e gestão da rede, o LonWorks implementa um