Você está na página 1de 100

Faculdade de Engenharia da Universidade do Porto

Interface Homem-Mquina para


Domtica baseado em tecnologias Web
Joo Alexandre Oliveira Ferreira

VERSO PROVISRIA

Dissertao realizada no mbito do


Mestrado Integrado em Engenharia Electrotcnica e de Computadores
Major Automao

Orientador: Prof. Dr. Mrio de Sousa

Julho de 2008

Joo Ferreira, 2008

Resumo
A instalao de um sistema de automao numa casa ou num edifcio vem adquirindo uma
importncia crescente numa sociedade moderna e evoluda.
A automatizao de tarefas que at agora eram feitas de uma forma manual, proporciona
uma melhor qualidade de vida aos utilizadores deste tipo de sistemas.
O conjunto de servios prestados pelos equipamentos que automatizam essas tarefas
direccionado gesto de quatro funes essenciais: o conforto, a eficincia energtica, a
segurana e as comunicaes. sobre este ltimo aspecto que esta dissertao se vai
focar.
A evoluo das redes de transmisso de dados, da microelectrnica, e o aparecimento de
novas tecnologias ou metodologias destinadas integrao Web de servios, contriburam
para a manifestao de novas possibilidades abrangidas pelo campo das comunicaes na
domtica.
Num mundo onde as pessoas esto em constante movimento, objectivo do sistema de
domtica tornar a vida e o trabalho um pouco mais fceis - fornecendo, por exemplo, um
interface intuitivo que fornea ao utilizador a autonomia de poder controlar todas as
funes de gesto da sua habitao, casa de frias ou escritrio via PDA, telemvel,
smartphone, computador ou qualquer outro dispositivo com acesso Internet, quer esteja
em casa ou em viagem.
Nesta dissertao iro ser estudadas diversas tecnologias que serviro de base a uma
plataforma de baixo custo, baixo consumo e sem cdigo proprietrio, cuja funo
essencial monitorizar e controlar uma instalao de domtica do standard KNX via Web
atravs de qualquer dispositivo com acesso Internet.
Com base no estudo efectuado, sero propostas vrias abordagens para a concepo de
uma arquitectura funcional base para o sistema.
Depois de uma anlise das vantagens e desvantagens de cada uma das abordagens
propostas, ser escolhida a que rena as melhores caractersticas, de acordo com os
objectivos propostos.
Na fase seguinte, dar-se- o processo de implementao de um exemplo da arquitectura
escolhida e, por fim, a validao do mesmo.

iii

Abstract
The installation of an automation system in house or a building has been assuming a major
role in a modern and developed society.
The automation of tasks, which used to be performed manually, offers a better quality of
life to those who use this kind of systems.
The set of services performed by the equipments responsible for the automation of these
tasks is directed towards four main functions: comfort, energetic efficiency, safety and
communications. This dissertation will be focusing this last aspect.
The development of data transmitting networks, of microelectronics, and the coming out
of new technologies or methodologies whose aim is the Web integration of services have
contributed to the emergence of new possibilities in the field of communications in home
automation.
In a world in which people are absorbed in a constant movement, it is the aim of the home
automation system to make life and work easier allowing the possibility of an intuitive
interface, for instance which provides the user with the autonomy of controlling every
single management function of his house, holiday home or office by means of PDA,
mobile phone, smartphone, personal computer or any other device connected to the
internet, while remaining at home or travelling.
This dissertation will focus the study of a wide range of technologies which will work as a
basis for a low-cost platform, low-consumption and no proprietary code, whose main
function is to monitor and control a home automation installation of KNX standard via
Web by means of any device connected to the internet.
Based on the study performed, some approaches for the conception of a basis functional
architecture for the system will be outlined.
After detailed analysis of advantages and disadvantages of each approach presented, the
one with the best characteristics, according to the aims previously set, will be chosen.
The next stage will focus on the implementation process of an example of the chosen
architecture, as well as the validation of the referred example.

Ao meu Av, Famlia e Amigos

vii

Agradecimentos
Ao longo deste trabalho foram vrios os que contriburam para que fosse possvel a
realizao desta dissertao.
Agradeo, em primeiro lugar, ao meu orientador, o Professor Doutor Mrio de Sousa, por
todo o apoio prestado ao longo das vrias etapas desta dissertao.
Agradeo Faculdade de Engenharia pela disponibilizao de todos os meios necessrios,
e ao tcnico Nuno Guerra pelo apoio prestado no laboratrio.
Agradeo, em particular, aos meus primos, Rita e Filipe, por todo o apoio prestado,
necessrio para a concluso desta dissertao.

ix

ndice
1.

Introduo

1.1 Enquadramento ...............................................................................................................1


1.2 Motivao .......................................................................................................................2
1.3 Objectivos .......................................................................................................................3
1.4 Estrutura do relatrio .......................................................................................................4

2.

Domtica

2.1 Introduo .......................................................................................................................5


2.2 Arquitectura ....................................................................................................................5
2.3 Funcionalidades...............................................................................................................8
2.3.1 O conforto.................................................................................................................8
2.3.2 A eficincia energtica ..............................................................................................9
2.3.3 A segurana ..............................................................................................................9
2.3.4 As comunicaes .................................................................................................... 10
2.4 Sistemas comerciais ...................................................................................................... 11

3.

Tecnologias

15

3.1 O standard KNX/EIB .................................................................................................... 15


3.1.1 Introduo ............................................................................................................... 15
3.1.2 Principais caractersticas ......................................................................................... 16
3.1.3 Topologia da rede.................................................................................................... 17
3.1.4 Meios de transmisso ..............................................................................................18
3.1.4.1 Par entranado .................................................................................................. 19
3.1.4.2 Rede elctrica ................................................................................................... 20
3.1.4.3 Wireless ............................................................................................................ 20
3.1.4.4 IP ...................................................................................................................... 21
3.1.5 Modos de configurao ........................................................................................... 22
3.1.5.1 Modo S ............................................................................................................. 22
3.1.5.2 Modo E ............................................................................................................. 22
3.1.5.3 Modo A ............................................................................................................ 23
3.1.6 Modo de endereamento de dispositivos .................................................................. 23

xi

XII

NDICE
3.1.7 Comunicao entre dispositivos .............................................................................. 24

3.2 Tecnologias Web........................................................................................................... 26


3.2.1 JavaScript ............................................................................................................... 26
3.2.2 AJAX ..................................................................................................................... 28
3.2.3 jQuery..................................................................................................................... 29
3.2.4 CGI......................................................................................................................... 30
3.2.5 JAVA ..................................................................................................................... 31
3.2.6 PHP ........................................................................................................................ 34
3.3 Sistemas Embebidos ...................................................................................................... 35
3.3.1 Sistemas Operativos para sistemas embebidos ......................................................... 35
3.3.1.1 Linux embebido ................................................................................................ 36
3.3.2 Cross-Compiling ..................................................................................................... 37

4.

Arquitectura Funcional

39

4.1 Primeira abordagem ...................................................................................................... 39


4.1.1 Primeira alternativa ................................................................................................. 40
4.1.2 Segunda alternativa ................................................................................................. 41
4.1.3 Terceira alternativa ................................................................................................. 42
4.2 Segunda abordagem ...................................................................................................... 43
4.3 Terceira abordagem ....................................................................................................... 44
4.3.1 KNX @ HOME ...................................................................................................... 44
4.3.1.1 KNXService ..................................................................................................... 44
4.3.1.2 KNXWeb ......................................................................................................... 45
4.3.1.3 KNXAdmin ...................................................................................................... 46
4.4 Escolha da arquitectura funcional .................................................................................. 46
4.4.1 Consideraes sobre a primeira abordagem ............................................................. 47
4.4.2 Consideraes sobre a segunda abordagem.............................................................. 47
4.4.3 Consideraes sobre a terceira abordagem............................................................... 47
4.4.4 Concluso ............................................................................................................... 48

5.

Validao experimental

49

5.1 Descrio do hardware.................................................................................................. 49


5.1.1 Sistema embebido para a plataforma do servidor ..................................................... 49
5.1.1.1 ICnova AP7000 Base........................................................................................ 49
5.1.1.2 Picotux ............................................................................................................. 51
5.1.1.3 Router .............................................................................................................. 52

NDICE

XIII

5.1.1.4 Avaliao da plataforma para o servidor ............................................................ 54


5.1.2 Sistema de testes ..................................................................................................... 55
5.1.3 Gateway KNX/EIB ................................................................................................. 58
5.1.4 Topologia do sistema de monitorizao e controlo Web........................................... 59
5.2 Software ........................................................................................................................ 60
5.2.1 Primeira fase ........................................................................................................... 60
5.2.1.1 Aplicao CGI de interface com a rede KNX/EIB .............................................60
5.2.1.2 Interface Web exemplo para a validao ............................................................62
5.2.2 Segunda fase ........................................................................................................... 65
5.3 Testes e resultados ......................................................................................................... 67
5.3.1 Primeira fase ........................................................................................................... 67
5.3.2 Segunda fase ........................................................................................................... 67

6.

Concluso e Perspectivas de Desenvolvimento

ANEXO 1

69
75

LISTA DE FIGURAS

XV

Lista de Figuras
FIGURA 2.1 ARQUITECTURA CENTRALIZADA ..............................................................................6
FIGURA 2.2 ARQUITECTURA DESCENTRALIZADA ........................................................................7
FIGURA 2.3 ARQUITECTURA DISTRIBUDA ..................................................................................7
FIGURA 2.4 ARQUITECTURA DO SISTEMA VIVIMAT [37] ......................................................... 12
FIGURA 2.5 VISO GERAL DO CONTROLO WEB DO SISTEMA DOMUS-INT [38]......................... 13
FIGURA 2.6 CONSOLA TCTIL DO SISTEMA CARDIO [40] ......................................................... 14
FIGURA 3.1 TOPOLOGIA DE UMA REDE KNX/EIB ..................................................................... 18
FIGURA 3.2 TOPOLOGIA DOS ENDEREOS FSICOS ..................................................................... 23
FIGURA 3.3 NVEIS DOS ENDEREOS DE GRUPO......................................................................... 24
FIGURA 3.4 INTERACO ASSNCRONA DAS APLICAES AJAX [16] ......................................... 29
FIGURA 3.5 INTERACO SNCRONA DAS APLICAES WEB TRADICIONAIS [16] ....................... 29
FIGURA 3.6 DIAGRAMA DE SEQUNCIA CGI SIMPLES ................................................................ 31
FIGURA 3.7 SEQUNCIA DE UM PROGRAMA JAVA SIMPLES ...................................................... 33
FIGURA 3.8 PICOTUX [26] ......................................................................................................... 37
FIGURA 4.1 ARQUITECTURA PROPOSTA NA 1 ALTERNATIVA DA 1 ABORDAGEM ....................... 40
FIGURA 4.2 ARQUITECTURA PROPOSTA NA 2 ALTERNATIVA DA 1 ABORDAGEM ....................... 41
FIGURA 4.3 ARQUITECTURA PROPOSTA NA 3 ALTERNATIVA DA 1 ABORDAGEM ....................... 42
FIGURA 4.4 ARQUITECTURA PROPOSTA NA 2 ABORDAGEM ....................................................... 43
FIGURA 4.5 KNXWEB .............................................................................................................. 45
FIGURA 4.6 KNXADMIN ........................................................................................................... 46
FIGURA 5.1 ICNOVA AP7000 .................................................................................................... 50
FIGURA 5.2 PICOTUX ................................................................................................................ 51
FIGURA 5.3 ROUTER OEM DISPONVEL PARA DESIGNS DE TERCEIROS ........................................ 52
FIGURA 5.4 ROUTER COMERCIAL DISPONVEL PARA O UTILIZADOR FINAL ................................. 54
FIGURA 5.5 VISTA FRONTAL DO PAINEL EIB ............................................................................. 56
FIGURA 5.6 VISTA TRASEIRA DO PAINEL EIB ............................................................................ 56
FIGURA 5.7 LEGENDA DA INSTALAO EIB .............................................................................. 57
FIGURA 5.8 GATEWAY IP SIEMENS N148/21 .............................................................................58
FIGURA 5.9 TOPOLOGIA DO SISTEMA DE MONITORIZAO E CONTROLO WEB ............................ 59
FIGURA 5.10 ESTRUTURA DE APLICAO DO SERVIDOR ............................................................ 60
FIGURA 5.11 DIAGRAMA DE EXECUO DO CGI ....................................................................... 61

XVI

LISTA DE FIGURAS

FIGURA 5.12 INTERFACE WEB COM DISPOSITIVO DESACTIVADO ............................................... 62


FIGURA 5.13 INTERFACE WEB COM DISPOSITIVO ACTIVADO ..................................................... 63
FIGURA 5.14 INTERFACE WEB COM ERRO NO DISPOSITIVO ........................................................ 63
FIGURA 5.15 NOVA TOPOLOGIA DO SISTEMA DE MONITORIZAO E CONTROLO WEB ............... 66

LISTA DE TABELAS

XVII

Lista de Tabelas
TABELA 3.1 TIPOS DE DADOS EIS ............................................................................................. 25
TABELA 5.1 HARDWARE ICNOVA AP7000 ................................................................................. 50
TABELA 5.2 SOFTWARE ICNOVA AP7000 .................................................................................. 50
TABELA 5.3 HARDWARE PICOTUX ............................................................................................. 51
TABELA 5.4 SOFTWARE PICOTUX .............................................................................................. 51
TABELA 5.5 HARDWARE ROUTER OEM ...................................................................................... 53
TABELA 5.6 SOFTWARE ROUTER OEM ....................................................................................... 53
TABELA 5.7 HARDWARE ROUTER LINKSYS WRT54G ................................................................. 53
TABELA 5.8 DISPOSITIVOS PRESENTES POR DIVISO NA SIMULAO ......................................... 55

XVIII

LISTA DE TABELAS

LISTA DE ACRNIMOS

Lista de acrnimos
API - Application Programming Interface
AVAC - Aquecimento, Ventilao e Ar Condicionado
EIS - EIB Interworking Standards
EIBA - European Installation Bus Association
EIB - European Installation Bus
ETS - EIB Tool Software
EHS - European Home System
FEUP - Faculdade de Engenharia da Universidade do Porto
GSM - Global System for Mobile communications
GPRS - General Packet Radio Service
HSDPA - High-Speed Downlink Packet Access
HTML - HyperText Markup Language
IP - Internet Protocol
KNX/EIB - Protocolo aberto da associao Konnex
ODM - Original Design Manufacturer
OEM - Original Equipment Manufacturer
PC - Computador pessoal (personal computer)
PDA - Personal Digital Assistant
SMS - Short Message Service
TCP - Transmission Control Protocol
UMTS - Universal Mobile Telecommunication System
UPS - Uninterruptible Power Supply
WAP - Wireless Application Protocol
WWW - World Wide Web
XML - Extensible Markup Language

XIX

Captulo 1

1. Introduo
1.1 Enquadramento
Este trabalho surge no seguimento de outros projectos j desenvolvidos na FEUP no
mbito da domtica de baixo custo. Nestes projectos foram desenvolvidos mdulos
sensores e actuadores de baixo custo, um servidor compatvel com a norma KNX/EIB e
um painel de simulao didctico com tecnologia EIB da Siemens. De modo a poder
interligar todos estes projectos entre si e a oferecer a possibilidade de monitorizao e
controlo remoto sobreveio a ideia deste projecto.
Nesta dissertao iro ser estudadas diversas tecnologias que serviro de base a uma
plataforma de baixo custo, baixo consumo e sem recorrer a cdigo proprietrio, cuja
funo essencial supervisionar, monitorizar e controlar uma instalao de domtica do
standard KNX/EIB via Web atravs de qualquer dispositivo com acesso Internet.
Para tal, sero estudadas as tecnologias que permitem suportar esta implementao e, com
base neste estudo, sero propostas vrias abordagens para a arquitectura funcional do
sistema. Depois de escolhida a melhor arquitectura, proceder-se- sua implementao e
validao com um exemplo de aplicao.

CAPTULO 1: INTRODUO

1.2 Motivao
A motivao principal para a realizao deste trabalho resulta da importncia crescente
que a automao de casas e edifcios vem adquirindo numa sociedade moderna e evoluda.
So coisas simples - como a reduo do tempo gasto nas rotinas dirias, a reduo dos
consumos de energia (tornada possvel por uma maior eficincia na regulao da
iluminao e climatizao) e a segurana oferecida pela deteco de possveis inundaes,
fugas de gs, incndios e intrusos - que possibilitam uma melhoria significativa na
qualidade de vida e na autonomia da populao, principalmente em pessoas que requerem
cuidados especiais.
Contudo, os custos de uma instalao de domtica so elevados e, normalmente, so
utilizados sistemas proprietrios, muito pouco flexveis, e que tornam o aumento das suas
capacidades inicialmente projectadas muito difcil e dispendioso.
Desde h alguns anos para c, com a constante evoluo da electrnica no campo dos
sensores/actuadores e das redes de comunicaes de dados, -nos possvel, agora, dispor
de uma grande variedade de equipamentos com preos competitivos e com a capacidade
de se integrarem numa rede de comunicao.
Tudo isto, juntamente com a massificao dos servios de Internet de banda larga e a
evoluo das redes mveis de alto dbito 3G e 3.5G, UMTS e HSDPA respectivamente
(que disponibilizam acesso Internet em qualquer lugar para PDAs, Smartphones,
telemveis e computadores), abre caminho possibilidade de controlar um edifcio em
qualquer lugar e a qualquer hora, dispondo de um acesso Internet e de um Web browser.
Deste modo, com um sistema de controlo baseado na Web, possibilitada aos utilizadores
uma elevada autonomia no que respeita ao controlar um edifcio distncia.
Procedimentos como o acesso s imagens das vrias cmaras de videovigilncia, gesto de
alarmes de intruso, fogo, inundaes, fugas de gs e controlo do sistema de rega de uma
moradia, so agora possveis, enquanto os seus habitantes se encontram calmamente de
frias do outro lado do mundo.
Esto, ento, reunidas as condies para que, face tecnologia existente, haja
possibilidade para que uma implementao de baixo custo (sem recorrer a sistemas
proprietrios que comportam custos elevados) e que fornea a possibilidade de controlar
uma instalao de domtica distncia, seja mais atractiva e fomente a massificao da
domtica.

CAPTULO 1: INTRODUO

1.3 Objectivos
O objectivo deste trabalho consiste no estudo das tecnologias Web actuais, das
implementaes j existentes ou em desenvolvimento para o interface de uma instalao
de domtica com a WWW, das plataformas de hardware que possam suportar estas
implementaes e dos aspectos fundamentais do protocolo de domtica KNX/EIB.
Depois, com base no estudo efectuado, projectar uma arquitectura funcional para o
sistema, implement-la e, por fim, valid-la.
Os objectivos especficos deste trabalho so os seguintes:
Estudo das tecnologias Web actualmente existentes numa perspectiva de
proporcionar uma comunicao do tipo cliente-servidor e que permita interagir
com uma instalao de domtica KNX/EIB com a maior eficincia possvel.
Estudo das implementaes existentes actualmente ou em desenvolvimento, na sua
verso de cdigo livre, que possam servir parcial ou totalmente para o suporte da
interface de comunicao com uma rede fsica de domtica KNX/EIB e da
interface Web para o seu controlo distncia.
Estudo da arquitectura base do protocolo de comunicao KNX/EIB para redes de
domtica.
Com base no estudo efectuado, propor diversas abordagens para o problema da
concepo de uma arquitectura funcional para o sistema a implementar, e,
dependendo das vantagens e desvantagens de cada uma dessas abordagens,
seleccionar a mais conveniente.
Estudo das plataformas de hardware de baixo custo e baixo consumo energtico
existentes no mercado que permitam suportar a implementao de um sistema de
controlo distncia para instalaes KNX/EIB de acordo com a abordagem
escolhida.
Aps a definio da arquitectura funcional, passar fase da implementao da
mesma.
Por fim, validar a implementao com um exemplo de aplicao simples.

CAPTULO 1: INTRODUO

1.4 Estrutura do relatrio


Esta dissertao encontra-se estruturada em 6 captulos dos quais, o primeiro composto
por esta introduo ao trabalho.
No segundo captulo apresentado o conceito de domtica, as arquitecturas possveis
deste tipo de sistemas e uma abordagem sobre as suas funcionalidades.
No terceiro captulo sero estudadas diversas tecnologias que podero servir de base ao
problema proposto, bem como o essencial do standard aberto KNX/EIB.
No quarto captulo, com base no estudo do captulo anterior, so propostas diversas
arquitecturas funcionais para a implementao do sistema e escolhida a mais conveniente.
No quinto captulo ser feita a implementao de um exemplo prtico simples, de modo a
poder validar a abordagem seleccionada sobre a concepo da arquitectura funcional e os
principais resultados dessa implementao.
O sexto e ltimo captulo contm as concluses gerais sobre o que foi feito neste trabalho.

Captulo 2

2. Domtica
Neste captulo ser apresentado o tema domtica juntamente com as suas principais
caractersticas.

2.1 Introduo
A palavra domtica deriva das palavras Domus (casa) e Robtica (controlo automatizado
de algo), ou seja, a domtica define-se como a possibilidade do controlo de forma
automtica de habitaes, tornando-as no que vulgarmente se costuma designar por casas
inteligentes.
Podemos observar este conceito a partir de duas posies distintas.
Do ponto de vista de um utilizador de uma habitao automatizada, a domtica pode ser
vista como um sistema que lhe proporciona uma melhor qualidade de vida atravs do uso
das novas tecnologias, oferece uma reduo do trabalho domstico, um aumento do bemestar e da segurana dos habitantes e uma melhor racionalizao no consumo energtico
da habitao.
Do ponto de vista tecnolgico, a definio de domtica pode ser vista como um sistema
que integra diversos equipamentos domsticos que tm a capacidade de comunicar entre si
atravs de um canal de comunicao, para que possam desempenhar tarefas de forma
autnoma, que at agora eram feitas de forma manual [1][2][3].

2.2 Arquitectura
Tanto os sistemas de automao de habitaes (normalmente instalaes de pequena
escala no contexto residencial), como os sistemas de automao de edifcios (tipicamente
instalaes de elevada dimenso como hotis e centros comerciais) visam uma melhoria
da interaco e da comunicao entre os dispositivos encontrados normalmente nestes
edifcios.
5

CAPTULO 2: DOMTICA

Os requisitos, a complexidade e o tipo de arquitecturas inerentes a estas duas situaes so


diferentes, mas em ambos os casos bvia a necessidade de comunicao entre os
sensores e os respectivos actuadores. Para isso utilizaram-se barramentos de comunicao
de dados, com vrias semelhanas das j bastante disseminadas, redes de campo
(utilizadas no domnio da automao industrial).
A classificao da arquitectura dos sistemas de automao feita com base no local onde
se encontra a inteligncia do sistema domtico. Podemos dispor de uma arquitectura
centralizada, uma arquitectura descentralizada, uma arquitectura distribuda e uma
arquitectura que um misto das anteriores.
Num sistema de domtica, uma arquitectura centralizada significa que existe um
controlador central que, de acordo com o programa nele executado, os dados que recebe
dos sensores e a informao introduzida pelos utilizadores, actua em conformidade nas
sadas - os actuadores.

SENSOR

SENSOR

ACTUADOR

CONTROLADOR
CENTRAL

SENSOR

ACTUADOR

ACTUADOR

INTERFACE

Figura 2.1 Arquitectura centralizada

Numa arquitectura descentralizada, ao contrrio da arquitectura anterior, existem vrios


controladores distribudos (cada um com os seus sensores e actuadores locais),
interligados entre si por um barramento de dados para trocarem informao.

CAPTULO 2: DOMTICA

ACTUADOR

ACTUADOR

SENSOR

SENSOR

barramento
CONTROLADOR

CONTROLADOR

SENSOR

SENSOR

INTERFACE

SENSOR

barramento

CONTROLADOR

INTERFACE

INTERFACE

SENSOR

ACTUADOR

Figura 2.2 Arquitectura descentralizada

Num sistema de domtica, uma arquitectura distribuda caracteriza-se pelo facto de cada
elemento do sistema, seja ele um sensor, um actuador ou um simples interface, ser
tambm um controlador capaz de actuar e enviar informao para um barramento de dados
- de acordo com o algoritmo nele executado, de acordo com os dados adquiridos por ele
prprio (sensor, por exemplo) e de acordo com os dados recebidos de outros dispositivos
do barramento (actuador, por exemplo) [4].

Figura 2.3 Arquitectura distribuda

CAPTULO 2: DOMTICA

2.3 Funcionalidades
Como j anteriormente referenciado, a domtica pode ser vista como um conjunto de
servios prestados por um equipamento automtico ou dispositivos com um certo nvel de
"inteligncia" dentro de uma habitao, direccionados gesto de quatro funes
essenciais: o conforto, a eficincia energtica, a segurana e as comunicaes.
A proporo do investimento feito em cada uma destas funes, aquando da instalao de
uma rede de domtica, depender de qual a finalidade do edifcio. Diferentes
necessidades, requerem diferentes meios.
Apesar de, em muitos aspectos, as quatro funes atrs referenciadas se sobreporem,
vamos tentar diferenciar o domnio de cada uma delas [1][2][3].

2.3.1 O conforto
O conceito de conforto essencialmente destinado s instalaes AVAC
(aquecimento, ventilao e ar condicionado), embora tambm se possam incluir nesta rea
todos os outros sistemas que possam contribuir para a comodidade e bem-estar dos
utilizadores dos edifcios que integram redes de domtica.
Na dcada de 70, foi efectuado um grande investimento nos sistemas AVAC, uma vez que
foram estes os primeiros sistemas de edifcios a serem electronicamente controlados.
Apesar da importncia do controlo de sistemas AVAC tambm abranger, em grande
parte, o consumo de energia, esta deve-se fundamentalmente presena deste tipo de
sistemas em quase todas as instalaes efectuadas hoje em dia. Devido sua topologia,
torna-se necessrio que o controlo deste tipo de sistemas seja o mais distribudo possvel,
ou seja, que em cada diviso ou local exista um sistema de controlo individual.
Para alm dos sistemas AVAC, podemos exemplificar outras funes clssicas, aplicveis
no domnio do conforto:
Controlo por infravermelhos dos vrios automatismos presentes no edifcio
Automatizao da irrigao de jardins
Abertura e fecho automtico de portas
Controlo e superviso de todos os sistemas do edifcio
Accionamento automtico de vrios sistemas com base em dados do meio
ambiente, como por exemplo a recolha de toldos e o fecho de persianas e janelas
em caso de tempestade ou vento forte.

CAPTULO 2: DOMTICA

2.3.2 A eficincia energtica


A exigncia da optimizao dos consumos energticos uma realidade que implica no a
ausncia do consumo, mas sim a sua gesto e quando necessrio e sua racionalizao
(falhas de energia recorrendo a uma UPS, por exemplo). O grande objectivo o de
satisfazer necessidades domsticas com o mais baixo custo.
O aproveitamento da energia e reduo do seu consumo um dos aspectos mais
importantes da instalao de um sistema de domtica. As aces destinadas a reduzir o
consumo esto intimamente ligadas integrao de todos os dispositivos da habitao no
sistema de domtica e, destas, podemos destacar:
O aproveitamento das tarifas bi-horrias de energia para agendamento do uso dos
equipamentos domsticos com cargas mais elevadas como, por exemplo, mquinas
de lavar roupa e lavar loua;
Deteco de fontes de perdas nos sistemas de climatizao como, por exemplo, a
suspenso do funcionamento do sistema em zonas onde sejam detectadas portas ou
janelas abertas;
Reduo do consumo do ar condicionado, na ausncia de utilizadores nas vrias
divises atravs da deteco automtica de presena;
Actuao sobre as persianas de modo a que seja aproveitada a luz solar, no caso do
pr-aquecimento de uma diviso juntamente com o sistema de ar condicionado, por
exemplo;
Monitorizao dos consumos de gua e/ou de gs por zonas, podendo, desta forma,
detectar possveis fugas ou actos de vandalismo num edifcio pblico.

2.3.3 A segurana
Actualmente, a segurana constitui uma preocupao crescente, sendo cada vez maior o
nmero de interessados que colocam o assunto Segurana no topo das suas prioridades.
Esta funo, a segurana, pode ser dividida em duas reas: a segurana de pessoas e a
segurana de bens.
Na categoria da segurana de pessoas podem ser includas tarefas como:
Iluminao automtica em zonas de risco. Detectando a presena de uma pessoa e
avaliando o grau de luminosidade da rea, possvel calcular o grau de risco e
actuar em conformidade com a situao. A ttulo de exemplo, se um utilizador se
levantar durante a noite com o intuito de se dirigir casa de banho, o sistema
detecta automaticamente a pessoa no corredor e o grau de luminosidade no local, e
actua sobre as luzes de presena no corredor.

10

CAPTULO 2: DOMTICA

Deteco de fugas de gs em vrias divises crticas de uma habitao (por


exemplo, os quartos), abrindo vlvulas de emergncia para extrair o gs para o
exterior.
Alarmes de emergncias mdicas. Em caso da existncia de pessoas com
necessidades especiais (como idosos e pessoas incapacitadas), existem
accionamentos de emergncia cuja activao gera um aviso pr-definido
anteriormente para o telemvel de um familiar ou para os servios de emergncia.
Na categoria da segurana de bens podem-se destacar funes como:
Deteco de intrusos com diversos sensores de presena no interior da habitao e
sensores magnticos de deteco de abertura de portas e janelas;
Deteco de possveis focos de incndio no interior de uma habitao, actuando
sobre os aspersores de emergncia na diviso onde foi detectada a anomalia;
Alarmes de inundaes e fugas de gs;
Simulao de presena na habitao, aquando de uma ausncia prolongada desta
por parte dos proprietrios, actuando sobre a iluminao e os estores de uma forma
aleatria.

2.3.4 As comunicaes
Neste sentido, existem vrias possibilidades, dependendo do tipo de edifcio.
A evoluo e o surgimento de novas tecnologias no domnio das telecomunicaes e das
redes de transmisso de dados, bem como o facto de sistemas domticos avanados
poderem ser baseados no uso destes tipos de redes, faz com que este seja um terreno frtil
para a investigao e o desenvolvimento de novas arquitecturas e sistemas de integrao.
Como j foi referenciado, a evoluo das redes de transmisso de dados, a evoluo da
microelectrnica, com um elevado nvel de integrao na rea dos semicondutores e o
aparecimento de novas tecnologias ou metodologias destinadas integrao Web de
servios, contriburam para a manifestao de novas possibilidades abrangidas no campo
das comunicaes na domtica.
De entre todas as possibilidades abrangidas nesta rea, so alvo de particular investimento
e desenvolvimento as iniciativas de superviso, controlo e monitorizao das instalaes
de domtica distncia.

CAPTULO 2: DOMTICA

11

Dentro desta rea podemos destacar dois mtodos:


Controlo de instalaes de domtica atravs de mensagens SMS, que consiste na
implementao da tecnologia GSM/GPRS para o controlo remoto da instalao de
domtica. O sistema poder responder para o telemvel do utilizador com a
informao de vrios alarmes. Por exemplo, se for detectada uma intruso no
edifcio, pode ser enviada uma imagem da cmara de segurana da diviso onde foi
detectada a presena indesejada.
Controlo de instalaes de domtica atravs via TCP/IP usando um browser e
tecnologias Web para a implementao de servios. Este mtodo ser o foco desta
dissertao.

2.4 Sistemas comerciais


Actualmente, existem numerosas solues comerciais baseadas em vrios protocolos
criados para o efeito dos sistemas de automao de edifcios.
Podem ser utilizados sistemas inicialmente desenvolvidos nos Estados Unidos, como o X10, o CEBus (Consumer Electronics Bus), o Smart House e o LonWorks, ou sistemas
inicialmente desenvolvidos na Europa, como o BatiBUS, o EIB (European Installation
Bus) e o EHS (European Home Systems).
J no final de dcada de 90, surge a associao Konnex, que resulta da fuso entre a EIBA,
BCI e EHSA, associaes responsveis pelo sistema EIB, BatiBUS e EHS,
respectivamente. Esta nova associao tinha por objectivo, definir um nico protocolo,
aberto e padronizado internacionalmente, para os sistemas de automao de habitaes e
edifcios, o KNX. O estudo presente nesta dissertao vai-se focar sobre este protocolo.
Existem, tambm, vrios sistemas comerciais que utilizam protocolos proprietrios,
podendo, ou no, oferecer compatibilidade com os protocolos standards j definidos.
Dos sistemas disponveis em Portugal, capazes de oferecer a monitorizao e o controlo da
instalao de domtica via Web, podemos destacar:
A) VIVIMAT
O sistema domtico VIVIMAT um sistema proprietrio desenvolvido pela empresa
espanhola Dinitel, e utiliza o protocolo RS-485 como o nvel fsico de transmisso.
Este um sistema centralizado que pode ser ampliado com a introduo de mdulos
adicionais, interligados atravs de um barramento de comunicao.
Ajusta-se, portanto, s necessidades de todo o tipo de casas de nova construo, e permite
o controlo e manuteno local e remota atravs de teclado, computador, painel de
visualizao, telefone, WAP e Internet [35][36].

12

CAPTULO 2: DOMTICA

Figura 2.4 Arquitectura do sistema VIVIMAT [37]

B) DOMUS-INT
Este sistema proprietrio, desenvolvido em Portugal pela empresa JG Domtica, baseia-se
num ecr tctil que incorpora o processamento da informao. A este painel ligado um
cabo bifilar, ao qual esto ligados em anel os mdulos sensores. Em cada diviso da casa
instalado um destes mdulos - que incorpora como entradas um receptor de
infravermelhos, um sensor de movimento, um sensor se luminosidade e um sensor de
temperatura, e, como sadas, um emissor de infravermelhos, dois interruptores para
controlo de iluminao e um outro para controlo de aquecimento. As persianas so
controladas por mdulos centralizados num quadro prprio (com uma ligao ao painel
tctil). Este sistema pode ser controlado por painel tctil, SMS, Internet e a visualizao
do estado do sistema pode ser feita na televiso. As suas limitaes assentam na
impossibilidade de regulao da intensidade luminosa [35][38][39].

CAPTULO 2: DOMTICA

13

Figura 2.5 Viso geral do controlo Web do sistema DOMUS-INT [38]

C) CARDIO
O CARDIO um sistema proprietrio desenvolvido pela empresa canadiana SECANT
Home Automation. um sistema centralizado, controlado localmente por uma consola
tctil, e pode facilmente acoplar-se instalao elctrica de uma vivenda (tanto em
construo, como j construda), com algumas modificaes relativamente instalao
normal. Alm disso, permite controlar qualquer dispositivo do protocolo X10, injectando
sinais na rede elctrica atravs do interface X10 fornecido [35][40][41].
O controlo de todas as funes deste sistema pode fazer-se de vrias formas:
A partir da consola tctil colocada em qualquer ponto da habitao. Uma srie de
cones e submenus guiam o utilizador para efectuar o controlo da sua casa de
forma directa e personalizada.
A partir de uma consola tctil mvel, onde o utilizador pode movimentar-se pela
casa e controlar assim as funes da mesma.
De qualquer telefone da casa, sendo guiado por uma voz em portugus atravs de
menus de opes.

14

CAPTULO 2: DOMTICA

De qualquer telefone exterior (incluindo telemveis).


De um computador (interior ou exterior atravs da Internet).

Figura 2.6 Consola tctil do sistema CARDIO [40]

Captulo 3

3. Tecnologias
Para a elaborao deste projecto, foi feita, numa primeira fase, uma anlise prvia do tipo
de tecnologia disponvel de modo a suportar os objectivos pretendidos. Neste captulo,
sero abordadas algumas das tecnologias mais importantes que podero ser aplicadas no
caso em estudo.

3.1 O standard KNX/EIB


3.1.1 Introduo
Em Maio de 1999, membros das associaes BatiBUS Club International (BCI), da
European Installation Bus Association (EIBA) e da European Home Systems Association
(EHSA) fundaram a Konnex Association. O objectivo principal desta associao era a
promoo de um novo e comum standard para a implementao de sistemas de automao
de edifcios e habitaes. Este standard, denominado KNX, baseado na tecnologia j
bem estabelecida do EIB, mas agora alargado com os mecanismos de configurao e
meios fsicos do BatiBUS e EHS.
A Konnex Association, detentora do standard KNX, uma organizao internacional sem
fins lucrativos sedeada em Bruxelas, Blgica, e representa mais de uma centena de
empresas lderes mundiais na rea dos sistemas de electrnica para a automao de
edifcios [5].

15

16

CAPTULO 3: TECNOLOGIAS

3.1.2 Principais caractersticas


Interoperabilidade Garante que os produtos de diferentes fabricantes utilizados
em diversas aplicaes iro operar e comunicar uns com os outros. Isto permite um
alto grau de flexibilidade na expanso e na modificao de instalaes.
Qualidade do produto A Associao Konnex requer um alto nvel de controlo de
qualidade durante todas as etapas da vida do produto. Assim, todos os produtos
desenvolvidos pelos membros da Konnex que ostentam a marca KNX tm de
demonstrar compatibilidade com a norma ISO 9001.
O KNX pode ser utilizado para todas as aplicaes no controlo de habitaes e
edifcios: desde o controlo da iluminao e persianas at vrios sistemas de
segurana, aquecimento, ventilao, ar condicionado, controlo de gua, gesto de
energia, monitorizao e alarme.
O KNX est apto para ser utilizado em diferentes tipos de edifcios. Este pode ser
utilizado em construes novas e, mesmo, nas j existentes. As instalaes KNX
podem tambm ser utilizadas num edifcio de qualquer dimenso, desde uma
simples habitao at edifcios de vrios andares, como hotis, centros comerciais,
blocos de apartamentos, hospitais e escolas.
O KNX suporta vrios tipos de modos de configurao: O S-Mode: O mtodo de
configurao mais poderoso, realizado atravs de um computador ligado ao
barramento, o A-Mode: mtodo de configurao automtico mas bastante limitado
e o E-Mode: mtodo de configurao por um controlador de dispositivo, no
barramento de dados.
O KNX suporta vrios meios fsicos de comunicao: Par entranado (TP), Rede
elctrica (Powerline), Rdio Frequncia (RF) e IP/Ethernet
A expanso, mudanas e actualizaes so possveis, sem que se verifique a
necessidade de redesenhar e reconstruir a instalao.
Ferramenta de configurao independente do fabricante - A ferramenta de software
ETS (Engineering Tool Software), ferramenta de configurao independente do
fabricante, permite o planeamento, engenharia e a configurao de todos os
produtos KNX certificados. Esta ferramenta nica permite ao integrador do
sistema combinar produtos de diferentes fabricantes na mesma instalao. As bases
de dados de produtos com material certificado de todos os fabricantes KNX podem
ser importadas para o ETS.

CAPTULO 3: TECNOLOGIAS

17

A norma KNX, devido ao facto de ser uma fuso de trs sistemas j existentes
anteriormente com as suas respectivas vantagens, no apresenta grandes desvantagens.
Podemos, ento, destacar como pontos mais desfavorveis desta tecnologia a relativa
complexidade das instalaes e custo tambm relativamente elevado do equipamento
certificado.

3.1.3 Topologia da rede


O KNX define-se como uma rede totalmente distribuda, uma vez que no requer um
controlador central na instalao e todos os dispositivos que se ligam ao barramento de
comunicao de dados tm o seu prprio microprocessador integrado e toda a electrnica
de acesso ao meio. Esta topologia distribuda pode acomodar at 65.536 dispositivos,
correspondendo a um espao de endereo individual de 16bits. Numa rede KNX, cada
segmento elctrico pode conter at um mximo de 64 dispositivos ligados, sendo que dois
ou mais segmentos podem ser interligados atravs de um repetidor, formando um
segmento lgico designado por linha.
Uma linha pode incluir at 4 segmentos elctricos interligados entre si por repetidores,
resultando numa capacidade mxima de 256 dispositivos. O uso de mais do que um
segmento elctrico s deve ter lugar para aumentar a capacidade de instalaes j
existentes.
Como ilustrado na figura 3.1, as vrias linhas podem ser interligadas numa linha
principal, fazendo uso de acopladores de linha, tendo este agrupamento a designao de
rea. Todo o domnio de uma rede KNX formado por um mximo de 15 reas, que so
conectadas entre si atravs de uma linha de rea, sendo a ligao da linha principal linha
de rea feita atravs de um acoplador de rea [6].

18

CAPTULO 3: TECNOLOGIAS

Figura 3.1 Topologia de uma rede KNX/EIB

3.1.4 Meios de transmisso


A tecnologia KNX/EIB suportada por diversos tipos de meios de transmisso, como, por
exemplo, o par entranado, a rede elctrica, IP, rdio frequncia e infravermelhos.
Juntamente com este meios, existe ainda a possibilidade de fazer uma interligao com
outro tipo de dispositivos, como o caso de um modem GSM, para a transmisso de
alertas de situaes de emergncia para o telemvel de responsvel do edifcio, seja ele
uma habitao familiar ou um edifcio comercial. Esta interligao de dois meios
diferentes possibilitada atravs de uma unidade conversora, o gateway.
Diferentes aplicaes requerem diferentes solues. Isto especialmente verdade nos
vrios meios fsicos de comunicao. Enquanto o par entranado um sistema com a

CAPTULO 3: TECNOLOGIAS

19

mxima fiabilidade e o mais baixo custo (logo aplicado na grande maioria das
instalaes), a opo de comunicao pela rede da instalao elctrica aplicvel se no
houver outra opo vivel. Esta ltima opo normalmente utilizada em edifcios onde a
instalao de rede KNX/EIB posterior construo do edifcio, onde nunca foi pensada
a possibilidade da automao do edifcio em questo.
Se nenhuma rede elctrica estiver disponvel no local da instalao ou se esta for
demasiado complexa, a rdio frequncia uma boa soluo, embora seja menos acessvel
financeiramente. A opo IP inestimvel para aplicaes onde seja necessria uma
grande largura de banda e/ou haja j instalado no edifcio um backbone de rede IP (como
grandes edifcios de escritrios, hotis, centros comerciais e hospitais). De seguida,
apresenta-se um breve resumo das principais caractersticas dos vrios meios de
comunicao.

3.1.4.1 Par entranado


Existem dois tipos de especificaes na norma KNX/EIB para a implementao do meio
fsico recorrendo ao par entranado, o TP0 e o TP1.
O modo TP0 foi herdado do sistema BatiBUS, muito popular em Frana. Os produtos
certificados KNX TP0 podem operar no mesmo barramento dos dispositivos BatiBUS,
mas no podem trocar informao entre si. Este modo, com uma taxa de transferncia
4800 bit/s, est a desaparecer, uma vez que a maioria dos fabricantes de equipamento est
a mudar para TP1.
O modo TP1 foi introduzido com o EIB e usado actualmente por mais de 90% dos
produtos KNX. O KNX TP1 combina a transmisso de dados com elevada qualidade com
o baixo custo do hardware que o implementa. Devido a estes factos, a grande maioria das
instalaes utiliza o TP1 como meio fsico de comunicao. A topologia do TP1 bastante
flexvel: linear, em estrela, em rvore ou como uma combinao entre as trs. A taxa de
transferncia de 9600 bit/s e os dispositivos ligados a uma rede TP1 podem ser
alimentados pelo barramento, se tal for necessrio. Os equipamentos certificados como
EIB e KNX TP1 podem operar e comunicar entre si no mesmo barramento. Em ambos os
casos implementado um mecanismo que controla o acesso ao canal de comunicao, de
modo a detectar colises, o CSMA/CD (Carrier Sense Multiple Access with Collision
Detection) [5][7][8].

20

CAPTULO 3: TECNOLOGIAS

3.1.4.2 Rede elctrica


Neste meio fsico utilizada a instalao rede elctrica do edifcio como canal de
comunicao. Este meio maioritariamente adoptado em situaes onde a instalao da
rede de domtica posterior da construo do edifcio, uma vez que permite a utilizao
da instalao elctrica j existente no mesmo. Contudo, este meio fsico apresenta algumas
limitaes (rudo, interferncias, atenuao) que impedem que a taxa de transmisso seja
elevada.
Tal como acontece com o par entranado, referido anteriormente, existem duas
especificaes para este meio fsico: o PL110 e o PL132.
A especificao PL110 foi igualmente tomada do EIB. Embora neste momento, apenas
alguns fabricantes apoiem a PL110, eles continuam a oferecer uma gama completa de
dispositivos para controlo de iluminao, estores e aquecimento.
A informao digital transmitida na rede atravs da modulao em frequncia SFSK
(Spread Frequency Shift Keying) com uma taxa de transmisso de 1200 bit/s.
Os dispositivos EIB PL110 podem operar e comunicar com dispositivos KNX/EIB PL110.
A especificao PL132 foi herdada do EHS (European Home System), e est actualmente
a ser utilizada apenas por alguns fabricantes. Esta especificao tambm utiliza a rede
elctrica para a transferncia de dados, mas com uma modulao diferente, a MSK
(Minimum frequency-shift keying) com uma taxa de transmisso de dados de 2400 bit/s.
Uma vez que praticamente no existem produtos para este meio e os dispositivos
KNX/EIB PL132 no podem comunicar com dispositivos EHS PL132, a especificao
PL132 pode vir a desaparecer no futuro [5][7][8].

3.1.4.3 Wireless
O KNX/EIB permite a utilizao do ar como meio de comunicao. Na norma esto
definidos dois tipos de redes que utilizam o ar como meio de transmisso dos dados: por
rdio frequncia e por infravermelhos.
A especificao que define a rdio frequncia (KNX RF) como mtodo de comunicao
ainda relativamente recente na especificao KNX. Embora ainda seja apoiada apenas
por alguns fabricantes, esto em processo de desenvolvimento e de certificao novos
produtos de vrios outros fabricantes, que em breve estaro no mercado.
O KNX RF envia as tramas KNX atravs de sinais rdio na banda de frequncia dos 868
MHz e com uma potncia na ordem do 25 mW (dispositivos de curto alcance). Com uma
taxa de transmisso de 16384 bit/s, pode ser transmitido um nmero de tramas equivalente

CAPTULO 3: TECNOLOGIAS

21

ao KNX TP1. Para a utilizao do KNX RF, podem ser utilizados componentes de baixo
custo e de baixo consumo elctrico, que permitam uma implementao de comunicao
bidireccional ou unidireccional. Para instalaes de tamanho pequeno e mdio, geralmente
no so necessrios repetidores para garantir a qualidade do sinal.
O KNX RF tambm muito importante, na medida em que permite a expanso e a
renovao de redes de cabo j existentes, em que os custos de refazer ou renovar toda a
instalao seriam incomportveis.
A especificao da utilizao dos infravermelhos como meio de comunicao est
definida na norma EIB (EIB.IR), e manteve-se na especificao KNX, sem que qualquer
alterao fosse efectuada. Neste mtodo de transmisso, o sinal transmitido por
infravermelhos at uma distncia de cerca de 12 metros, e a comunicao pode ser
unidireccional ou half-duplex bidireccional com a transmisso assncrona de pacotes de
dados. O tipo de modulao do sinal transmitido ASK (Amplitude-shift keying) com uma
frequncia de 447.5 kHz, com uma taxa de transmisso de 1300 bit/s para o modo
unidireccional e com uma taxa de transmisso de 7000 bit/s para a transmisso
bidireccional.
Neste tipo de sistema, os sinais infravermelhos (IR) so transmitidos por emissores IR ou
por controlos remotos ao accionar um interruptor ou um boto, respectivamente. Um
receptor IR, quando recebe um sinal, encaminha-o para um descodificador interno, onde
os sinais so convertidos em tramas KNX/EIB e enviados para o barramento [5][7][8][9].

3.1.4.4 IP
A especificao do KNX/EIB herda do EIB a especificao EIBnet/IP, que define a
integrao do protocolo EIB sobre as redes IP (Internet Protocol). A norma agora
denominada por KNXnet/IP especifica que as tramas KNX/EIB possam ser encapsuladas
em pacotes IP. Desta maneira, as redes LAN (local area network), bem como a Internet,
podem ser utilizadas como meio de transmisso para tramas KNX/EIB.
Considerando a massificao das redes IP e infra-estruturas de suporte das mesmas, estas
representam um backbone interessante e bem adequado para as instalaes EIB/KNX. As
redes IP oferecem, comparativamente com as redes EIB/KNX, vantagens para aplicaes
onde seja necessria uma elevada largura de banda e velocidade e/ou haja j instalado no
edifcio um backbone de rede IP (como os grandes edifcios de escritrios, hotis, centros
comerciais e hospitais), possibilitando ainda o acesso remoto, o controlo, a superviso e
mesmo a sua configurao remota.
A utilizao deste meio fsico normalmente acompanhada com outro meio fsico como
por exemplo o KNX/EIB TP1. A norma KNXnet/IP define um servidor que funciona
como um gateway e que interliga a rede KNX/EIB (TP1, normalmente) a uma rede IP
[5][7][8].

22

CAPTULO 3: TECNOLOGIAS

3.1.5 Modos de configurao


Depois de um dispositivo KNX ser ligado ao meio, ele configurado para se integrar na
instalao KNX. Uma vantagem adicional do KNX o nmero de modos de configurao
que este protocolo suporta.
A norma KNX permite, tambm, que cada fabricante possa seleccionar o modo de
configurao ideal, de acordo com o mercado alvo ao qual o produto se destina.

3.1.5.1 Modo S
O System mode ou S-Mode foi o primeiro modo de configurao a ser estabelecido, e j
foi especificado pelo EIB. Este modo necessita do software de configurao oficial da
Konnex Association, o ETS (Engineering Tool Software) para levar a cabo o processo de
configurao. Este modo o mais poderoso e oferece o mais alto grau de flexibilidade
para a realizao de funes de controlo de edifcios, devendo ser aplicado nas instalaes
de maior complexidade. Neste modo de configurao, o fabricante deve fornecer uma base
de dados do produto com as funes e propriedades de todos os seus dispositivos
KNX/EIB, que ser carregada pelo ETS. Este mecanismo de configurao destina-se a
instaladores especialmente treinados em redes KNX/EIB e com conhecimentos sobre a
configurao de funes avanadas de controlo em edifcios [5][7][8].

3.1.5.2 Modo E
O Easy mode ou E-mode um novo modo de configurao introduzido com o KNX, que
no necessita de um computador com o ETS para a configurao da rede, embora oferea
funes mais limitadas do que o modo de configurao referido anteriormente. Neste
modo, as propriedades dos dispositivos ligados na rede podem ser lidas atravs do
barramento, dispensando tambm a necessidade da base de dados do fabricante com as
propriedades do produto. Este mtodo de configurao est dividido em dois diferentes
modos, o easy controller mode e o easy push button mode.
No primeiro modo, necessrio um controlador de dispositivo na rede KNX, que realiza o
processo de configurao de acordo com regras de conexo definidas.
No segundo modo, a configurao no requer dispositivos ou ferramentas auxiliares, e
pode ser realizada por cada dispositivo, dispondo cada um deles de um boto integrado
necessrio sua prpria configurao. Este mtodo de configurao destinado aos
instaladores com treino KNX/EIB bsico, e os dispositivos esto j pr-programados e
carregados por omisso com um conjunto de parmetros de funcionamento [5][7][8].

CAPTULO 3: TECNOLOGIAS

23

3.1.5.3 Modo A
Existe, ainda, um terceiro modo, denominado automatic mode, que foi recentemente
especificado na norma KNX. Este modo oferece um processo de configurao plug-andplay sem qualquer interaco por parte do utilizador, e destina-se normalmente aos
utilizadores menos experientes. Como este mtodo apresenta funcionalidades muito
limitadas, a oferta no mercado dos dispositivos que suportam este modo reduzida
[5][7][8].

3.1.6 Modo de endereamento de dispositivos


A gesto dos dispositivos conectados num barramento de rede KNX/EIB pode ser
efectuada de 2 modos: o endereamento fsico e o endereo de grupo.
Cada dispositivo ligado ao barramento identificado por um endereo fsico nico (dois
ou mais dispositivos no podem partilhar o mesmo endereo).
O endereo fsico de 16 bit constitudo por um nmero de rea (4bits), de linha (4bits) e
de dispositivo no barramento (8bits), que descreve a sua localizao e define
univocamente cada dispositivo na rede. Este tipo de endereamento apenas usado como
endereo de destino para a inicializao, para a programao e para as operaes de
diagnstico.

Figura 3.2 Topologia dos endereos fsicos

24

CAPTULO 3: TECNOLOGIAS

Para alm do endereo fsico, cada dispositivo pode ter um ou mais endereos lgicos,
denominados de endereos de grupo.
Os endereos de grupo estabelecem quais os dispositivos ligados ao barramento que vo
actuar em sintonia entre si, isto , que sensor controla cada actuador ou conjunto de
actuadores.
O modo de endereamento de grupo corresponde ao modo de funcionamento normal da
rede. Este modo associa funcionalmente os dispositivos no barramento, uma vez que todos
os dispositivos que tenham o mesmo endereo de grupo recebem as mesmas mensagens.
Os elementos transmissores de uma instalao KNX/EIB, os sensores, apenas podem
transmitir telegramas para um endereo de grupo distinto, ao contrrio dos elementos
actuadores, que podem ter vrios endereos de grupo, o que lhes permite reagir a diversos
sensores.
O endereamento de grupo oferece bastante flexibilidade, uma vez que permite adicionar
um dispositivo ao barramento de uma maneira muito simples, bastando lig-lo ao
endereo de grupo correcto.
Os endereos de grupo podem ter duas formas, de acordo com as necessidades na
hierarquizao das funes do sistema, endereo de nvel 2 e endereo de nvel 3. Os
endereos de nvel 2 dividem-se em dois campos: o grupo principal e subgrupo, enquanto
os de nvel 3 se dividem em trs campos: grupo principal, grupo intermdio e subgrupo,
como se pode observar na figura 3.3 [7][8][10][11].

Figura 3.3 Nveis dos endereos de grupo

3.1.7 Comunicao entre dispositivos


Para que dois dispositivos possam comunicar entre si, estes devem partilhar um dialecto
comum - de modo a que os dados trocados entre ambos tenham o mesmo significado para
os dois dispositivos - e garantir a mxima compatibilidade entre dispositivos de diferentes

CAPTULO 3: TECNOLOGIAS

25

fabricantes. Para isso, os dispositivos KNX/EIB esto ligados logicamente entre si por
meio de objectos de comunicao. Estes objectos contm informaes importantes sobre o
estado do dispositivo, por exemplo, se uma lmpada est ligada ou desligada, a
temperatura de um sensor ou se foi pressionado um interruptor. Cada dispositivo pode ter
um ou mais objectos de comunicao.
Assim, de modo a normalizar a comunicao entre os diversos dispositivos, estabeleceu-se
o EIS (EIB Interworking Standard), que contm 15 tipos de dados (formato, estrutura)
teis para cada funo atribuda aos objectos de comunicao para controlar os diversos
dispositivos.
A seguinte tabela resume os diferentes tipos de dados EIS que esto disponveis.

Tabela 3.1 Tipos de dados EIS


TIPO EIS

Funo EIB

Dimenso

Descrio

EIS 1

SWITCHING

1bit

Acendido / Apagado, ON/OFF, TRUE/FALSE

EIS 2

DIMMING

4bit

Aumenta (+)/ Diminui(-), Valor

EIS 3

TIME

3bytes

Dia da semana, hora, minutos e segundos

EIS 4

DATE

3bytes

Dia / ms / ano

EIS 5

VALUE

2bytes

EIS 6

SCALING

8bit

EIS 7

CONTROL DRIVE

1bit

Mover baixo/cima, Abrir/Fechar

EIS 8

PRIORITY

1bit

Activado / Desactivado

EIS 9

FLOAT VALUE

4bytes

Codificao de um nmero em vrgula flutuante

EIS 10

16BIT COUNTER

2bytes

Representa os valores de um contador de 16 bits

EIS 11

32BIT COUNTER

4bytes

Representa os valores de um contador de 32 bits

EIS 12

ACCESS

4bytes

Cdigo de acesso de segurana

EIS 13

CHARACTER ASCII

8bit

Codificao de caracteres ASCII

EIS 14

8BIT COUNTER

8bit

Representa os valores de um contador de 8 bits

14bytes

Transmite uma string at 14 bytes

EIS 15

CHARACTER
STRING

Para enviar valores fsicos como Temperatura,


Intensidade luminosa, Tenso, Corrente
Utiliza-se para transmitir valores relativos com uma
resoluo de 8 bits (Humidade Relativa=100%)

26

CAPTULO 3: TECNOLOGIAS

Normalmente, os dispositivos podem dispor de vrios objectos de comunicao, que


podem ser de diversos tipos EIS. Por exemplo, um interruptor de duas teclas para controlo
de iluminao pode dispor de objectos do tipo EIS 1, para as funes de comutao
(acender/apagar) e de objectos de regulao, do tipo EIS 2, para o envio de ordens de
incremento/decremento de intensidade luminosa.
Cada objecto de comunicao tem um endereo de grupo associado, que nico se se
tratar de um objecto de comunicao emissor (elemento sensor), ou que podem ser vrios,
se se tratar de um objecto de comunicao receptor (elemento actuador).
Um objecto de comunicao emissor e um receptor ligam-se entre si, associando o mesmo
endereo de grupo, desde que ambos os objectos sejam do mesmo tipo.
Quando o valor no elemento sensor se altera, este transmite o novo valor para o endereo
de grupo associado. Todos os objectos de comunicao receptores que tenham o mesmo
endereo de grupo reagem a esta alterao e actuam de acordo com a sua funo. Por
exemplo, supondo que o objecto de comutao de um interruptor est ligado ao endereo
de grupo 1/2/3, o objecto de comutao de um actuador responsvel por ligar uma
lmpada, tambm deve estar ligado ao endereo de grupo 1/2/3 [7][8][10][11][12].

3.2 Tecnologias Web


3.2.1 JavaScript
O enorme crescimento da World Wide Web levou a uma grande procura de pginas Web
dinmicas e interactivas, capazes de oferecer ao utilizador uma boa experincia de
navegao. Para atrair a ateno de possveis clientes, as empresas apostam cada vez mais
na Internet, como forma de mostrarem ao mundo os seus produtos e/ou os seus servios.
Como forma de tornar isto possvel, importante que este meio, a pgina Web, seja o mais
agradvel e intuitiva possvel, possibilitando um nvel de interactividade elevado e capaz
de cativar todo o possvel cliente.
O HTML, em si, esttico, e apenas permite uma mnima interaco com os utilizadores.
Como consequncia disto, as pginas Web que se desejem verdadeiramente interactivas e
funcionais no podem utilizar somente o HTML. Face necessidade de uma nova
abordagem para introduzir alguma dinmica num contedo que era esttico at data,
surgiu o JavaScript.
O JavaScript uma linguagem de programao interpretada, desenvolvida, inicialmente,
pela Netscape em 1995, e , na maioria das vezes, usada para o desenvolvimento de
aplicaes Web que se executam do lado do cliente.

CAPTULO 3: TECNOLOGIAS

27

Isto significa que qualquer cdigo escrito em JavaScript entregue juntamente com a
pgina HTML, e executado dentro do browser do cliente, em vez de correr directamente
no servidor que est a disponibilizar essa mesma pgina.
O JavaScript, apesar do nome, no est relacionado com o Java tradicional, apenas partilha
alguma semelhana na sua sintaxe, sendo totalmente diferente no conceito e no uso.
Uma das mais frequentes utilizaes do JavaScript a validao dos dados introduzidos
por utilizadores num formulrio. Isto significa que os dados que foram inseridos so
verificados, com o intuito de concluir se so os mais adequados para o campo de
preenchimento em questo. No caso de os dados no estarem correctamente inseridos, o
preenchimento do formulrio no dever prosseguir at que sejam correctamente
inseridos. Esta aco de grande importncia, principalmente em servidores que sirvam
centenas ou mesmo milhares de pginas por minuto, uma vez que no necessrio um
poder de processamento adicional por parte destes para a validao dos dados do
formulrio e reenvio da pgina com uma notificao de erro ao utilizador.
A verificao dos dados por parte do servidor, apesar de esporadicamente necessria, (para
uma consulta base de dados, por exemplo) usa largura de banda til que, numa altura de
grande carga, pode mesmo diminuir o nmero de utilizadores ligados a esse mesmo
servidor.
Como os formulrios incorrectamente preenchidos no so submetidos para o servidor,
uma vez que so validados na mquina cliente, o utilizador no tem de estar espera que
os dados sejam enviados, validados e reenviados de volta com possveis mensagens de
erro, contribuindo assim para uma experincia de navegao mais agradvel e eficaz para
o utilizador final.
Porm existem alguns inconvenientes no seu uso. O cdigo JavaScript pode facilmente
adicionar dezenas ou mesmo centenas de linhas de cdigo a uma pgina Web, tornando a
sua manuteno extremamente complicada e de difcil compreenso.
Esta desvantagem pode ser facilmente ultrapassada, guardando as vrias seces de cdigo
JavaScript num ficheiro com a extenso .js e incluindo-o no cabealho de todas as pginas
HTML que necessitem deste cdigo. Fica assim, desta maneira, separado o cdigo
JavaScript do contedo HTML da pgina propriamente dita. [13][14]

28

CAPTULO 3: TECNOLOGIAS

3.2.2 AJAX
medida que a World Wide Web se vai expandindo e a largura de banda das ligaes vai
aumentando, as pessoas procuram cada vez mais e melhor contedo, aplicaes mais
inteligentes e com respostas mais rpidas.
At muito recentemente, medida que a complexidade das aplicaes ia crescendo, os
utilizadores comearam a deparar-se com sistemas lentos e com dificuldade de resposta,
onde pginas inteiras tinham de ser recarregadas apenas para se actualizar um nico
elemento. A plataforma Web mostrava-se, ento, frgil e pouco eficaz para as aplicaes
mais exigentes.
De modo a ultrapassar estas dificuldades e possibilitar o desenvolvimento de pginas com
melhor tempo de resposta, interactivas e dinmicas, com uma maior eficcia, adoptou-se
uma nova metodologia, o Ajax.
Tornando-se popular em 2005 com o Google Suggest, o Ajax ou Asynchronous
JavaScript and XML no mais do que uma combinao de vrias tecnologias standard
j existentes como o JavaScript, o DHTML/HTML e o XML.
O objecto XMLHttpRequest o componente fundamental do Ajax, e o que o torna to til.
Ele proporciona um mecanismo que permite ao cliente, atravs do JavaScript, trocar
informao directamente com o servidor Web. A informao recebida pode ser processada
em background e usada para, dinamicamente, actualizar elementos numa pgina Web, sem
a necessidade de recarregar toda a pgina. Desta forma, a informao circula em
background e as pginas so actualizadas como se se tratassem de aplicaes standalone
tpicas, ao invs das aplicaes Web tradicionais, disponveis at altura.
A parte assncrona do termo Ajax (figura 3.4) significa que o browser no vai esperar pela
informao que vai ser devolvida pelo servidor, mas vai process-la apenas quando esta
for enviada pelo servidor. Esta a parte crucial do Ajax, na qual a aplicao Web no fica
num estado de espera, aguardando o retorno da informao do servidor. Se a aplicao
parar espera da informao (aplicaes tradicionais), essa aplicao ser sncrona (figura
3.5), e com ligaes Internet lentas, isso pode representar um problema [15][16].

CAPTULO 3: TECNOLOGIAS

29

Figura 3.4 Interaco assncrona das aplicaes Ajax [16]

Figura 3.5 Interaco sncrona das aplicaes Web tradicionais [16]

3.2.3 jQuery
jQuery uma biblioteca JavaScript poderosa e extremamente leve, que permite aos
programadores e aos Web designers o adicionar de elementos dinmicos e interactivos s
suas pginas, atenuar as inconsistncias dos vrios browsers e reduzindo fortemente o
tempo de desenvolvimento das aplicaes, promovendo a produtividade.
Criado por John Resig, o jQuery um projecto open-source que promove uma maneira
diferente de escrever cdigo em Javascript e que proporciona um instrumento essencial
para fornecer uma compatibilidade robusta multi-plataforma e simplificar a maneira de
como se percorrem os documentos HTML, a manipulao de eventos, o executar de
animaes e o adicionar de interaces Ajax numa pgina Web [17].

30

CAPTULO 3: TECNOLOGIAS

3.2.4 CGI
Common Gateway Interface, ou CGI, um conjunto de regras (standard) que descreve a
forma como um servidor Web comunica com outras aplicaes que correm na mesma
mquina, e como estas comunicam com o servidor Web. Sem este standard bem definido
e suportado por parte dos servidores, seria impossvel aumentar as funcionalidades destes
e gerar contedo dinmico sem recorrer a metodologias proprietrias do servidor ou
modificar o cdigo do servidor. Esta ltima tarefa requer que o cdigo fonte do servidor
esteja disponvel (o que nem sempre possvel); requer, ainda, um extenso conhecimento
tcnico em redes/programao para a implementao das novas funcionalidades e, por
fim, se houver a necessidade de mudar estas implementaes para uma nova plataforma,
ser necessrio refazer grande parte do cdigo ou despender bastante tempo a fazer o port
do cdigo para a nova plataforma.
O CGI proporciona uma soluo simples e robusta para estes problemas. Com a
especificao deste protocolo, e atravs de servidores Web que o implementem, qualquer
aplicao desenvolvida numa qualquer linguagem de programao pode comunicar
directamente com qualquer servidor Web, uma vez que esta comunicao tratada atravs
do standard input e do standard output. Esta simplificao, significa que qualquer
programador que saiba ler e imprimir dados para o standard input/output,
respectivamente, usando uma linguagem de programao, capaz de implementar uma
aplicao CGI no servidor Web sem despender muito esforo extra.
De todo um conjunto de linguagens, h duas que so maioritariamente utilizadas nas
aplicaes CGI, o C e Perl. Estas duas linguagens inserem-se em duas categorias
diferentes: as linguagens compiladas e as linguagens interpretadas, respectivamente. Cada
um destes dois tipos tem as suas vantagens e as suas desvantagens. Nas linguagens
compiladas, como o C/C++, o cdigo fonte do programa traduzido pelo compilador para
um cdigo mquina capaz de ser interpretado pelo CPU. Deste processo resulta um cdigo
muito eficiente, que pode ser executado todas as vezes que forem necessrias sem haver
necessidade de repetir, novamente, o processo de compilao. Depois da execuo deste
processo, que apenas ocorre uma vez, o cdigo gerado apenas precisa de ser carregado e
executado, sem nenhum overhead adicional.
Contudo, existem algumas desvantagens, como uma maior dificuldade na programao, na
depurao e na actualizao das aplicaes, traduzindo-se num maior tempo despendido
no desenvolvimento destas.
No caso das linguagens interpretadas como o Perl ou o PHP, o cdigo fonte tem de ser
analisado, interpretado e executado de cada vez que os programas correm, ao invs de uma
nica compilao inicial, acrescentando um maior overhead execuo destes. Por este

CAPTULO 3: TECNOLOGIAS

31

motivo, os programas interpretados so geralmente menos eficientes do que os programas


compilados. A grande vantagem das linguagens interpretadas que estas permitem
geralmente um desenvolvimento mais rpido, uma maior facilidade na actualizao e na
depurao das aplicaes. Normalmente, a deciso de se usar uma linguagem deste tipo
baseada na facilidade de futuras alteraes, ou quando h restries ao nvel do tempo
disponvel para o desenvolvimento da aplicao.
Normalmente, uma aplicao CGI um pequeno programa que executado em tempo real
no servidor, podendo este produzir contedo dinmico com o intuito de o incorporar numa
pgina Web esttica.
Um exemplo muito frequente da utilizao desta tecnologia na gesto de base de dados,
em que a aplicao CGI pode fazer consultas, inserir, remover ou alterar a informao
com base nos dados introduzidos num Web browser cliente. O browser envia os dados
introduzidos no formulrio HTML para o servidor Web, submetendo este a informao
para o programa CGI. O programa CGI executado nesse instante, processa os dados
recebidos e retorna o resultado deste processamento de volta para o servidor Web, que, por
sua vez reencaminha esta informao para o browser. Esta sequncia pode ser observada
na seguinte figura [18][19].

Figura 3.6 Diagrama de sequncia CGI simples

3.2.5 JAVA
Foi a meio da dcada de 90 que a Internet viu o seu crescimento aumentar
exponencialmente em nmero de servidores disponveis e pginas alojadas, bem como o
aparecimento das primeiras aplicaes comerciais na Web.

32

CAPTULO 3: TECNOLOGIAS

Estas primeiras aplicaes disponveis recorriam a simples formulrios e a programas CGI


(como foi elucidado na seco CGI) como primeiro passo para trazer a interactividade e o
dinamismo necessrio execuo deste tipo de aplicaes. No entanto, a utilizao de
formulrios no trouxe, por si s, uma verdadeira interactividade s pginas Web: a
comunicao (pedido/resposta HTTP) entre o cliente e o servidor, onde efectuada a
execuo e o processamento, faz com que no existia uma resposta directa e
verdadeiramente em tempo real s aces do utilizador.
O aparecimento da tecnologia JAVA veio imprimir profundas mudanas World Wide
Web tradicional e mudar de forma decisiva este cenrio. Para esta mudana contribuiu a
introduo de pequenos programas que corriam do lado cliente (browser): os applets
(abordados, posteriormente, nesta seco), que podiam ser embutidos directamente no
cdigo HTML das pginas Web para realizar alguns tipos de tarefas como animaes ou
algum tipo processamento local de informao.
O JAVA uma linguagem de programao orientada a objectos com uma sintaxe
semelhante ao C/C++, desenvolvida pela Sun Microsystems e que surgiu na altura da
massificao da World Wide Web, em meados da dcada de 90.
Esta linguagem difere das linguagens mais tradicionais, como o C ou C++, em que o
cdigo fonte compilado directamente para cdigo mquina.
Em JAVA seguida uma filosofia diferente. Como existe cdigo transferido pela Internet
que ser executado localmente numa grande variedade de plataformas clientes, o JAVA
foi projectado para ser multi-plataforma, tanto no cdigo fonte do programa como no
ficheiro binrio, depois de compilado.
Uma vez que no possvel correr o mesmo ficheiro binrio (por exemplo, em
plataformas Windows, Linux ou MAC OS), o JAVA compila o seu cdigo fonte para um
ficheiro intermdio independente da plataforma, o bytecode. Este ficheiro ser interpretado
aquando da sua execuo por uma mquina virtual. Esta mquina virtual (JAVA Virtual
Machine ou JVM) o ncleo onde se encontra o motor responsvel por executar o
bytecode do programa JAVA e especfica para cada plataforma. Desta maneira e, apenas
trocando a JVM para o sistema operativo e arquitectura de hardware em causa, ser
possvel correr a mesma aplicao sem necessidade de a recompilar numa grande
variedade de plataformas, write once, run anywhere. Na figura 3.7 podemos observar
uma sequncia simples da criao de um programa JAVA.

CAPTULO 3: TECNOLOGIAS

33

Figura 3.7 Sequncia de um programa JAVA simples

Em JAVA h uma distino entre alguns tipos de aplicaes, sendo os de maior


importncia as programas standalone, os applets e os servlets.
Os programas standalone so os programas tpicos de uso geral, que desempenham as
mesma funes que os programas escritos numa qualquer outra linguagem de
programao.
Um applet um programa JAVA compilado, que se integra numa pgina Web. Ao ser
realizado o acesso com um browser quela pgina, o bytecode carregado atravs da Web,
sendo, de seguida, executado na mquina local onde reside o browser cliente.
Os applets so usados, normalmente, para fornecer interactividade a aplicaes Web onde
o simples HTML no capaz de o fazer por si s. Como j foi referido anteriormente,
quem vai interpretar e executar a aplicao a JVM presente na mquina cliente que
carregou a aplicao. Deste modo, a independncia da plataforma est garantida, podendo
funcionar em ambientes Windows, Linux, Mac OS entre outros.
Um servlet JAVA pode ser encarado como um applet, mas a correr do lado do servidor
Web. semelhana de outras tecnologias que executam do lado do servidor, como o CGI
ou o PHP, este programa JAVA manuseia dinamicamente pedidos e respostas tipicamente
em HTML com um cliente, permitindo, assim, adicionar contedos dinmicos a uma
aplicao Web.
Um servlet JAVA requer um servidor de aplicao especial que proporciona o ambiente
para este executar em cooperao com o servidor Web. Um exemplo deste servidor de
aplicao, e que implementa as especificaes definidas pela Sun Microsystems, o
Apache Tomcat desenvolvido pela Apache Software Foundation [20][21].

34

CAPTULO 3: TECNOLOGIAS

3.2.6 PHP
Como j foi referenciado anteriormente, neste captulo, foi a meio da dcada de 90 que se
deu a grande expanso da World Wide Web.
At ao aparecimento do PHP, a soluo para criar pginas Web dinmicas passava
maioritariamente pelo recurso s aplicaes CGI, tambm j atrs descritas neste captulo.
Isto significava escrever bastante cdigo em C e compilar cada vez que se fazia uma
alterao aplicao, o que, dependendo da dimenso e complexidade da aplicao,
poderia tornar-se uma tarefa bastante penosa em termos de tempo de desenvolvimento
despendido.
segundo este contexto que surge o PHP, um acrnimo recursivo para PHP: Hypertext
Preprocessor. Esta nova tecnologia uma linguagem de programao interpretada,
orientada a objectos, livre e utilizada para gerar contedo dinmico em pginas Web de
uma maneira relativamente rpida. O cdigo PHP tem uma sintaxe semelhante do
C/C++ e do JAVA, e pode fazer tudo o que uma aplicao CGI era capaz de fazer at
agora, como recolher dados de formulrios e interagir com bases de dados. Os blocos de
cdigo PHP so embutidos directamente no cdigo HTML e so executados no servidor
quando este recebe o pedido de um cliente para carregar a pgina.
Quando algum visita uma pgina concebida com esta tecnologia, o servidor Web
processa, inicialmente, o cdigo PHP; depois, analisa quais as partes que deve mostrar aos
visitantes (contedos, imagens), ocultando os blocos do cdigo PHP depois de
interpretados e executados. So nestes blocos executadas as operaes como, por exemplo,
o acesso a bases de dados, clculos numricos e operaes sobre ficheiros. No fim desta
sequncia, no servidor, o cdigo resultante traduzido para um ficheiro HTML que a
pgina que vai ser enviada para o browser cliente.
O PHP pode ser utilizado numa grande variedade de sistemas operativos e compatvel
com a maior parte dos servidores Web existentes nas suas variantes livres ou comerciais.
O PHP considerado uma das linguagens mais fceis de aprender e de utilizar para o
desenvolvimento de aplicaes Web dinmicas. A simplicidade e facilidade de
desenvolvimento do PHP, juntamente com uma grande comunidade e repositrios de
bibliotecas PHP de cdigo aberto, fazem desta linguagem a favorita de programadores e
de Web designers a nvel mundial [22][23].

CAPTULO 3: TECNOLOGIAS

35

3.3 Sistemas Embebidos


Um sistema embebido um sistema computacional que parte integrante de um
dispositivo destinado execuo de aplicaes especficas. Devido s suas funes
limitadas, estes dispositivos podem ser optimizados para as suas necessidades particulares.
O termo embebido significa que o sistema se encontra dentro de um outro sistema e faz
parte deste, como por exemplo uma televiso ou um automvel.
Tradicionalmente, a maior parte deste tipo de dispositivos era utilizado para controlo de
processos, medidas e aquisio de dados. Contudo, devido ao enorme desenvolvimento da
indstria da microelectrnica, hoje possvel atingir um nvel de integrao muito elevado
ao nvel da construo de circuitos integrados. Alm da integrao dos mais diversos tipos
de perifricos (como, por exemplo, interfaces para diversos barramentos de comunicaes,
processadores dedicados ao processamento de streams de vdeo e processadores udio
multicanal), h ainda um aumento capacidade de poder de processamento com um
reduzido consumo elctrico e um baixo custo.
O primeiro sistema embebido moderno reconhecido como tal foi o sistema de navegao e
orientao da Misso Apollo, sendo a aplicao da primeira produo em massa o sistema
de orientao dos msseis balsticos intercontinentais Minuteman I e II da Boeing, em
1960. Devido produo em larga escala dos circuitos integrados usados neste sistema, os
preos caram de 100$ at aos 3$ cada, levando, na dcada de 80, a uma massificao do
uso deste tipo de sistemas nas mais diversas aplicaes [24].

3.3.1 Sistemas Operativos para sistemas embebidos


Os sistemas operativos destinados a este tipo de dispositivos podem ser classificados em
duas categorias distintas: os sistemas operativos de tempo-real e os sistemas operativos
tradicionais sem requisitos de tempo real.
Os sistemas operativos de tempo real (RTOS) so sistemas operativos que garantem
respostas a cada evento, dentro de um intervalo de tempo definido. Este tipo de sistemas
usado principalmente em sistemas crticos que necessitam de ter um comportamento
determinstico, isto , o prazo de execuo de uma tarefa no pode ser violado. Dentro
deste tipo de sistemas operativos, os que mais se destacam so o VxWorks e o RTlinux, e
tm aplicaes em diversas reas como, por exemplo, os robots industriais, a indstria
automvel, espacial, aeronutica e o controlo industrial.

36

CAPTULO 3: TECNOLOGIAS

Os sistemas operativos tradicionais sem requisitos de tempo real so sistemas operativos


geralmente de uma utilizao mais generalizada em que estes, ao contrrio dos RTOS, no
garantem tempos de resposta bem definidos aos eventos recebidos. So exemplos destes
sistemas operativos diversas distribuies de Linux destinadas ao mercado dos
computadores embebidos.

3.3.1.1 Linux embebido


O poder, a fiabilidade, a flexibilidade e escalabilidade do Linux, combinados com o seu
suporte a uma imensido de arquitecturas de microprocessadores (e respectivo hardware
circundante) e protocolos de comunicao, estabeleceram o Linux como uma plataforma
de software cada vez mais popular para um vasto leque de projectos e de produtos.
Porque o cdigo fonte do Linux est aberto e livremente disponvel, muitas variaes e
configuraes do sistema operativo e seu respectivo software de suporte tm evoludo no
sentido de dar resposta s diversas necessidades dos mercados e aplicaes para os quais o
Linux est sendo adaptado. Existem verses adaptadas para dispositivos de muito baixa
capacidade, bem como verses especiais para aplicaes de tempo real. Apesar das
origens do Linux como sistema operativo para a arquitectura dos computadores pessoais
(IBM PC compatible), existem diversos ports para um sem nmero de arquitecturas que
no x86, incluindo ARM, MIPS, PowerPC, SPARC e mesmo alguns microcontroladores.
O uso do Linux abrange todo o espectro de aplicaes computacionais, desde o
computador mais pequeno do mundo, o Picotux (figura 3.8) - que apenas ligeiramente
maior do que um conector de rede RJ45 -, passando pelos dispositivos de comunicaes
portteis como os telemveis e smartphones, pelos sistemas de entretenimento (como
leitores/gravadores DVD de sala e a Set-top Box da televiso por cabo), passando tambm
por praticamente todos os equipamentos de suporte de redes de dados (como os routers,
firewalls, pontos de acesso wireless), marcando presena, tambm, em sistemas de
controlo de automveis, na indstria aeroespacial, na rea da automao industrial, na
instrumentao mdica e, por fim, terminando nos supercomputadores mais avanados do
mundo [24][25].

CAPTULO 3: TECNOLOGIAS

37

Figura 3.8 Picotux [26]

3.3.2 Cross-Compiling
Ao contrrio dos computadores pessoais, os sistemas embebidos no so, habitualmente,
programados na plataforma onde a aplicao a desenvolver ser executada. De modo a
efectuar a compilao de um programa tendo como destino uma outra arquitectura
computacional, so necessrios toolchains (conjunto de ferramentas de software que so
usadas para construir aplicaes) especiais com o Cross-compiler especfico para essa
mesma arquitectura. O termo Cross-compiler representa um compilador capaz de gerar um
cdigo executvel para uma plataforma diferente daquela em qual o compilador corre.
A sua razo de existncia deve-se ao facto de os sistemas embebidos - plataforma alvo
destas compilaes - disporem de recursos de hardware bastante limitados, como a
memria no voltil para o armazenamento das aplicaes (e sistema operativo caso esteja
disponvel), a memria RAM e, tambm, o processador (que no seria capaz de compilar
as aplicaes mais complexas com a celeridade desejada).
Dependendo das necessidades das aplicaes, existem abordagens diferentes para
implementar o software. Uma possibilidade a de controlar directamente o hardware
nas aplicaes. Esta a abordagem com o mais alto desempenho, mas exige mais
conhecimento sobre a arquitectura e perifricos utilizados, relativamente utilizao de
um sistema operativo. Por outro lado, a existncia de um sistema operativo proporciona
funcionalidades para multitarefas, alocao de memria e permite que o programador
desenvolva as suas aplicaes com independncia da arquitectura de hardware subjacente
[27].

38

Captulo 4

4. Arquitectura Funcional
Como resultado do estudo anterior, foram seleccionadas um conjunto de tecnologias
disponveis, que permitiram obter diferentes abordagens para a concepo de uma
arquitectura funcional capaz de cumprir os objectivos inicialmente propostos.
Neste captulo sero abordadas as vrias solues encontradas com base no estudo
efectuado.

4.1 Primeira abordagem


Nesta primeira abordagem, a implementao do sistema seria efectuada com base num
conjunto de APIs JAVA, denominado de Calimero. Estas APIs, desenvolvidas na Vienna
University of Technology, permitem o estabelecimento de um tnel de comunicao sobre
uma rede IP com um gateway KNX, processo denominado KNXnet/IP Tunnelling. O
gateway um dispositivo que permite fazer o interface entre uma rede IP e uma sub-rede
KNX/EIB - TP1. Assim sendo, no necessrio um conhecimento detalhado sobre o
protocolo KNXnet/IP, permitindo uma abstraco para as camadas de aplicao superiores
a esta API.
Como esta API j se encontra desenvolvida em JAVA, a aplicao da camada superior que
a vai utilizar ter de ser, tambm, desenvolvida nesta linguagem de programao.

39

40

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.1.1 Primeira alternativa


Nesta primeira alternativa, dispomos de um servidor Apache Tomcat, que executa duas
funes distintas.
A primeira funo executada a de servidor Web, responsvel por carregar para os
clientes a pgina HTML com o applet JAVA, com todas as informaes e controlos
necessrios para fazer a interface com a rede de domtica KNX/EIB.
A segunda funo do servidor correr um servlet JAVA que utiliza a API Calimero, j
atrs mencionada. Este ir ser o responsvel por toda a gesto da rede de domtica e da
comunicao com o applet que executado no browser cliente.
Do lado do cliente o applet JAVA recebido executado. Este interage com o servlet que
est a correr no servidor via pedidos e respostas HTTP, enviando-lhe as aces feitas pelo
utilizador do cliente.

SERVIDOR

CLIENTE

Apache Tomcat
WWW

Servlet JAVA

Applet
JAVA

HTML
Javascript
AJAX

API Calimero

IP
IP / EIB
Gateway

KNX / EIB TP1

KNX / EIB
Device

KNX / EIB
Device

KNX / EIB
Device

Figura 4.1 Arquitectura proposta na 1 alternativa da 1 abordagem

Browser

CAPTULO 4: ARQUITECTURA FUNCIONAL

41

4.1.2 Segunda alternativa


A segunda alternativa uma pequena variao da referida anteriormente.
Nesta alternativa, continua a ser carregado para o browser do cliente um applet JAVA que
contm a API responsvel pela comunicao com a instalao de domtica atravs de um
tnel de comunicao sobre a rede IP, o Calimero.
Agora, em vez de ser um servlet JAVA a executar do lado do servidor para controlar e
gerir a instalao de domtica, ser o applet JAVA a comunicar directamente com o
gateway IP/KNX da instalao.
Nesta alternativa, tero de ser analisadas as limitaes impostas por detrs do conceito de
applet JAVA, e se esto, ou no, em condies de impossibilitar a satisfao dos
objectivos impostos.

CLIENTE
SERVIDOR
API Calimero

Webserver

WWW

Applet
JAVA

HTML
Javascript
AJAX

IP
IP / EIB
Gateway

KNX / EIB TP1

KNX / EIB
Device

KNX / EIB
Device

KNX / EIB
Device

Figura 4.2 Arquitectura proposta na 2 alternativa da 1 abordagem

Browser

42

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.1.3 Terceira alternativa


A terceira alternativa segue um mtodo ligeiramente diferente.
Nesta opo, continuamos a ter um servlet JAVA a correr no servidor, tal como na
primeira alternativa. A diferena que agora existe uma base de dados que serve de
camada intermdia entre cliente e servidor. nesta base de dados relacional que o cliente
vai registar as ordens a passar para o servidor executar, permitindo tambm ficar com um
histrico sobre as aces tomadas. Neste histrico, por uma questo de segurana,
poderiam ficar registadas a data, a hora, o elemento actuado, o valor actuado, o utilizador
que efectuou a aco e o IP de origem do qual o cliente interagiu sobre o servidor.
No servidor, o servlet JAVA ir consultar a base de dados, atravs da API JDBC (Java
Database Connectivity), sempre que h uma interaco com o cliente ou uma mudana de
estado de um elemento da instalao de domtica. Nessa consulta base de dados, o
servlet verifica se h novas ordens do cliente para executar e actualiza o estado dos
elementos da rede KNX/EIB.

SERVIDOR
Apache Tomcat

WWW
SQL

JDBC

Servlet JAVA

API Calimero

Aces a
executar
+
Histrico das
aces

Dispositivos
+
Info
instalao
Utlizadores

HTML
Javascript
AJAX

IP
Browser

IP / EIB
Gateway

KNX/EIB TP1

KNX / EIB
Device

KNX / EIB
Device

KNX / EIB
Device

Figura 4.3 Arquitectura proposta na 3 alternativa da 1 abordagem

CLIENTE

CAPTULO 4: ARQUITECTURA FUNCIONAL

43

4.2 Segunda abordagem


A segunda abordagem para a concepo da arquitectura funcional recaiu sobre um tipo de
tecnologia diferente, o CGI.
Nesta arquitectura, o browser cliente interage com um programa CGI que reside no
servidor Web. Este programa CGI, por sua, vez utiliza um cliente KNX/EIB de interface
para estabelecer um canal de comunicao sobre uma rede IP com um gateway que
efectua o interface entre e rede de dados IP e o barramento KNX/EIB - TP1 da instalao
domtica. Este gateway tambm poder ser um, capaz de fazer o interface com outros
meios de comunicao utilizados nas instalaes KNX/EIB, como por exemplo a rede
elctrica.

SERVIDOR
CLIENTE

WW W

HTML
Javascript
AJAX

IP
IP / EIB
Gateway

KNX / EIB TP1

KNX / EIB
Device

KNX / EIB
Device

KNX / EIB
Device

Figura 4.4 Arquitectura proposta na 2 abordagem

Browser

44

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.3 Terceira abordagem


A terceira abordagem sobre o problema da concepo da arquitectura funcional recaiu
numa linha de pensamento bastante diferente das anteriores abordagens.
Esta abordagem visa utilizar uma plataforma j desenvolvida no mbito de uma tese de
Stephan Wuchterl na University of Applied Sciences Deggendorf, Center for Innovative
Communication Systems orientada pelo Professor Dr-Ing. Andreas Grzemba.
Esta plataforma, o KNX@HOME, conta actualmente com cerca de sete colaboradores que
continuaram a desenvolver o trabalho iniciado por Stephan Wuchterl.

4.3.1 KNX @ HOME


O KNX@HOME um projecto de cdigo aberto e desenvolvido com o intuito de
controlar instalaes de domtica KNX/EIB via HTTP.
Este projecto baseado em JAVA, uma vez que utiliza a API Calimero, j referida
anteriormente; futuramente, os autores esperam introduzir AJAX, de modo a trazer um
maior dinamismo e eficincia.
O KNX@HOME constitudo por trs programas separados: o KNXService, KNXWeb e
o KNXAdmin.
Esta terceira abordagem visa a adaptao desta aplicao, tendo em vista os objectivos
inicialmente propostos para este projecto.

4.3.1.1 KNXService
O KNXService o ncleo desta aplicao. Este mdulo o responsvel por toda a gesto
da rede KNX/EIB, da gesto de uma base de dados relacional HSQL e do estabelecimento
de um tnel de comunicao sobre a rede IP com um gateway IP / KNX. Foi neste mdulo
que o autor utilizou a API Calimero para a comunicao sobre IP com o gateway IP/KNX,
embora esta tenha sofrido algumas modificaes de modo a melhor satisfazer os
objectivos desta aplicao.

CAPTULO 4: ARQUITECTURA FUNCIONAL

45

4.3.1.2 KNXWeb
Este componente a aplicao Web na qual os utilizadores do KNX@Home podem
configurar e interagir com o sistema de uma forma visual. O KNXWeb permite, ainda, a
diferenciao de um utilizador normal e de um utilizador com privilgios de administrador
- que o responsvel por criar e configurar a informao que ser disponibilizada via Web,
bem como gerir as contas dos diversos utilizadores e respectivos privilgios sobre a
actuao na instalao de domtica.
As aces de controlo neste interface com o utilizador so enviadas para o KNXService
que as vai interpretar e enviar os comandos respectivos para o barramento da rede
KNX/EIB.

Figura 4.5 KNXWeb

da

46

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.3.1.3 KNXAdmin
Este terceiro componente do KNX@Home permite gerir tudo o que se passa no
barramento EIB/KNX.
Esta ferramenta permite-nos monitorizar todas as mensagens / eventos trocados entre o
KNXService e a rede EIB/KNX, podendo ficar, assim, com um histrico sobre o estado do
sistema, principalmente por razes de segurana.
tambm com esta aplicao que os utilizadores adicionam, removem e configuram os
endereos de grupo e os respectivos tipos de dados EIS associados, j referenciados na
seco 3.1.7.

Figura 4.6 KNXAdmin

4.4 Escolha da arquitectura funcional


Depois da apresentao das abordagens propostas para a arquitectura funcional,
necessrio compreender as vantagens e as desvantagens de cada uma destas arquitecturas
propostas.

CAPTULO 4: ARQUITECTURA FUNCIONAL

47

4.4.1 Consideraes sobre a primeira abordagem


Analisando as trs alternativas propostas na primeira abordagem, podemos optar por
seleccionar a mais eficiente, num processo de eliminao sequencial.
Primeiramente, podemos excluir a segunda alternativa, devido a facto de, no conceito de
applet JAVA, por questes de segurana, no ser possvel este carregar ou importar
bibliotecas externas de outros packages excepto java.* e, tambm, devido ao facto de o
applet no poder comunicar ou transferir informao sem ser com a mquina de onde este
foi transferido. Deste modo, o applet no pode integrar a API Calimero dentro deste e nem
pode comunicar directamente com o gateway IP da rede KNX/EIB.
De seguida, a terceira alternativa pode tambm ser excluda. Das trs alternativas, esta era
a que envolvia uma maior complexidade e exigia uma maior quantidade recursos por parte
do servidor, no sendo a melhor opo para ser implementada num sistema embebido com
capacidade limitadas partida.
Resta-nos a primeira alternativa, que, de todas as propostas, a mais equilibrada para o
uso da tecnologia JAVA.

4.4.2 Consideraes sobre a segunda abordagem


A segunda abordagem apresenta-se como uma proposta extremamente eficiente no que
respeita s exigncias de recursos computacionais. Esta caracterstica possvel graas
adopo de aplicaes CGI desenvolvidas em C, trazendo uma maior eficincia na
execuo no cdigo.

4.4.3 Consideraes sobre a terceira abordagem


Na terceira abordagem, a adaptao do projecto KNX@Home apresenta alguns factores
limitativos. Toda a documentao disponvel sobre o projecto e parte do interface Web
encontra-se escrita em alemo, no existindo qualquer verso na lngua inglesa, e que,
aliada complexidade do prprio projecto e aos requisitos computacionais mnimos
necessrios para o servidor do projecto (>1GHz, >256MB RAM e 200MB livres), torna
esta abordagem praticamente invivel.

48

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.4.4 Concluso
Depois de terem sido apresentadas as vrias abordagens e respectivas consideraes,
avanou-se para uma soluo final.
A alternativa JAVA limita, em parte, o domnio dos dispositivos capazes de receber a
aplicao Web, uma vez que coloca todo o peso do interface do lado do cliente. Esta
soluo restringe partida grande parte dos PDAs, smartphones, telemveis e outros
dispositivos portteis onde no h uma Java Virtual Machine bem definida, standard e
sem custos para o utilizador como existe para as plataformas desktop comuns por parte da
Sun Microsystems. A mesma limitao referente mquina virtual pode tambm ser
observada no servidor, se se recorrer a uma plataforma embebida com hardware mais
extico, como o caso da grande parte dos sistemas embebidos.
A terceira abordagem, apesar estar funcionalmente completa apresenta as limitaes j
referidas nas consideraes sobre a mesma. De todas estas limitaes, so
fundamentalmente os requisitos mnimos de hardware necessrios para o servidor, que
inviabilizam a escolha desta proposta. Seria necessrio ter um PC disponvel e sempre
ligado (com o respectivo consumo elctrico) para alm do valor envolvido na sua compra.
Esta soluo no seria compatvel com o baixo consumo e o baixo custo para a plataforma
de hardware do servidor, tal como o definido nos objectivos propostos inicialmente.
A segunda abordagem proposta para a implementao da arquitectura funcional demonstra
um bom compromisso entre a eficincia de execuo das aplicaes CGI, como foi
evidenciado na seco 3.2.4, e uma complexidade de implementao compatvel com o
tempo disponvel para a realizao deste projecto. Devido sua melhor eficincia, esta
abordagem apresenta os menores requisitos em termos de hardware. Esta abordagem
demonstra tambm a maior abrangncia no suporte a dispositivos clientes, uma vez que a
base do interface de controlo apenas depende de elementos simples HTML e do JavaScript
(disponvel em praticamente todos os browsers).
Com base nesta anlise, a proposta escolhida para a implementao da arquitectura
funcional do sistema foi a segunda abordagem apresentada.

Capitulo 5

5. Validao experimental
Este captulo dedicado implementao prtica de um exemplo simples e apresentao
dos resultados experimentais que permitem validar a arquitectura funcional proposta no
captulo anterior. O exemplo prtico ilustrativo do funcionamento desta arquitectura
consiste no comando de um dispositivo KNX/EIB do tipo EIS1 via Web.

5.1 Descrio do hardware

5.1.1 Sistema embebido para a plataforma do servidor


De modo a suportar a aplicao de servidor relativa a este projecto, necessria a escolha
de uma plataforma de hardware que cumpra os objectivos propostos no que respeita ao
baixo custo e ao baixo consumo elctrico desta.
Foram seleccionadas trs opes que cumprem estes objectivos e so apresentados de
seguida:
A) ICnova AP7000 Base
B) Picotux
C) Router

5.1.1.1 ICnova AP7000 Base


Esta seco dedicada apresentao do sistema embebido ICnova AP7000 (figura 5.1)
da empresa In-Circuit [28], cujas principais caractersticas se encontram descritas nas
tabelas 5.1 e 5.2. Esta plataforma tem um custo unitrio de 95.

49

50

CAPITULO 5: VALIDAO EXPERIMENTAL


Tabela 5.1 Hardware ICnova AP7000

CPU

Atmel AVR32 @ 140MHz

RAM

64 MB

Flash

8 MB

Ethernet

10/100Mbit

Interfaces

USB-UART via CP2102

Alimentao

Conversor DC/DC integrado

Tabela 5.2 Software ICnova AP7000


Sistema
Operativo

uClinux 2.6.24

Shell

Busybox 1.0

Aplicaes

Servidor Web, Telnet, SSH deamon

Figura 5.1 ICnova AP7000

CAPITULO 5: VALIDAO EXPERIMENTAL

51

5.1.1.2 Picotux
Outro sistema embebido que cumpre os objectivos estabelecidos para o presente trabalho
o Picotux (figura 5.2) da empresa Kleinhenz Elektronik [26], tendo um custo unitrio de
142. As principais caractersticas desta plataforma encontram-se nas tabelas 5.3 e 5.4.
Tabela 5.3 Hardware Picotux
CPU

32-bit ARM 7 Netsilicon NS7520 @ 55mhz

RAM

8 MB

Memria Flash

2 MB

Ethernet

10/100Mbit

Interfaces

Srie TTL, at 230.400 bps

Alimentao

250mA @ 3,3V

Tabela 5.4 Software Picotux

Sistema Operativo

uClinux 2.4.27

Shell

Busybox 1.0

Sistema de ficheiros

CRAMFS, JFFS2, NFS

Aplicaes

Servidor Web, Telnet

Figura 5.2 Picotux

52

CAPITULO 5: VALIDAO EXPERIMENTAL

5.1.1.3 Router
O principal requisito para uma plataforma de monitorizao e controlo Web um acesso
sempre disponvel de banda larga Internet. Como a generalidade dos ISPs (Internet
Service Providers) fornece um router para os servios de banda larga, e, como j foi
referido na seco Sistemas embebidos do captulo 3, a maioria dos equipamentos de rede
(onde se encaixam os routers) baseada em Linux, surgiu a ideia de poder utilizar o
router como plataforma para a aplicao do servidor. Esta opo no requer mais nenhum
equipamento extra, como o caso das duas opes anteriormente mencionadas,
beneficiando da ausncia do custo de aquisio da plataforma, da ausncia do consumo
extra de energia por parte de uma segunda plataforma e da liberdade oferecida para o
controlo local atravs de plataformas mveis (PDAs, Smartphones, etc), proporcionada
pelas capacidades wireless da generalidade dos routers disponveis no mercado.
A) Router OEM
Existem empresas que se dedicam exclusivamente ao desenvolvimento e concepo de
equipamentos de rede, que fornecem em regime de OEM/ODM outsourcing a vrios
clientes, nomeadamente a grandes empresas do sector de redes de computadores, como a
Linksys, Cisco, Dlink (entre outras), sendo estas que fazem o desenvolvimento de todo o
software, a comercializao e fornecem o suporte deste tipo de equipamentos ao utilizador
final.
A opo seleccionada para esta hiptese o router wireless ilustrado na figura 5.3. Este
equipamento baseado num projecto da Accton [43], empresa situada em Taiwan e
dedicada principalmente concepo e fabrico de equipamentos de rede para terceiros
(OEM/ODM), como j foi referido.

Figura 5.3 Router OEM disponvel para designs de terceiros

CAPITULO 5: VALIDAO EXPERIMENTAL

53

Tabela 5.5 Hardware router OEM


CPU

Atheros AR2315 @ 180MHz

RAM

16 MB

Memria Flash

8 MB

Ethernet

10/100Mbit

Wireless

IEEE 802.11b / 802.11g (at 54 Mbps)

Tabela 5.6 Software router OEM


Sistema Operativo

OpenWRT (linux)

Shell

Busybox 1.0

Sistema de ficheiros

JFFS2

Aplicaes

Servidor Web, Telnet, SSH deamon

B) Router comercial
Existe tambm a possibilidade de se usar um router comercial, j disponvel no mercado
para o utilizador final. Como opo para esta hiptese, seleccionou-se o router wireless
Linksys WRT54G. Este modelo um dos equipamentos de maior sucesso no mercado,
devido sua boa relao funcionalidade / qualidade / preo. Este modelo existe desde
Dezembro de 2002, tendo, at actualidade, sofrido vrias revises de hardware ao nvel
da memria e do processador. Apesar de o fabricante no divulgar as especificaes
tcnicas no que respeita ao hardware e ao software, possvel, atravs da cooperao de
uma comunidade online com vrios utilizadores deste modelo recolher informao sobre o
hardware envolvido nas vrias actualizaes.
Tabela 5.7 Hardware router Linksys WRT54G
CPU

Broadcom 5354 @ 240Mhz

RAM

8 MB

Memria Flash

2 MB

Ethernet

10/100Mbit

Wireless

IEEE 802.11b / 802.11g (54Mbps)

54

CAPITULO 5: VALIDAO EXPERIMENTAL

Figura 5.4 Router comercial disponvel para o utilizador final

5.1.1.4 Avaliao da plataf orma para o ser vidor


A plataforma picotux (figura 5.2) apresenta-se como boa soluo, uma vez que dispe de
um reduzido consumo elctrico (< 1W) e os interfaces necessrios. Contudo, esta
plataforma dispe de um sistema de armazenamento demasiado pequeno (2MB Flash)
para o armazenamento da aplicao Web, tendo ainda de partilhar 720KB com o S.O. Esta
situao acaba por inviabilizar a escolha desta soluo.
A plataforma da empresa alem In-Circuit [28], ICnova AP7000 Base (figura 5.1), apesar
de ser bastante recente, apresenta argumentos fortes, como: CPU bastante rpido (pode
funcionar at 200MHz), memria RAM oito vezes superior ao picotux, memria Flash
para armazenamento quatro vezes superior. Apesar de o seu consumo elctrico ser no
mximo trs vezes superior (< 2,5 W ), este mantm-se numa gama de valores aceitvel
para estar sempre ligado, aproximadamente 0.09 por ms (picotux) e 0,21 por ms
(ICnova AP7000).
A escolha de um router na sua vertente comercial como plataforma para o servidor no
trivial. Apesar de ser, sem dvida, uma plataforma eficaz (pelas razes j atrs
mencionadas), esta opo pode apresentar problemas de legalidade dbia. Para os
fabricantes dos routers disponveis no mercado, no geralmente vantajoso que
aplicaes externas sejam executadas nos seus equipamentos, pelo que optam pela
proteco dos mesmos contra essa eventualidade. Isto implica que qualquer aco que
tenha como objectivo o ultrapassar destas restries possa ser encarada pelo fabricante
como uma violao da sua propriedade intelectual.
Para ultrapassar estas possveis dificuldades e tornar a escolha de um router como uma
opo vivel (com vantagens tambm ao nvel da personalizao do software e ao nvel da
conteno dos custos), seria necessrio adquirir o equipamento directamente na origem
(onde tipicamente concebido o hardware), da mesma forma que as grandes empresas (j

CAPITULO 5: VALIDAO EXPERIMENTAL

55

atrs enunciadas) fazem, antes de estas lhe colocarem o seu software proprietrio, e
disponibilizar o produto final nos seus revendedores oficiais.
Existe, no entanto, um outro problema decorrente desta soluo: a elevada diversidade do
hardware envolvido neste tipo de equipamentos, nomeadamente na arquitectura dos
microprocessadores que os equipam. Devido a esta caracterstica, os programas
desenvolvidos para uma plataforma podero no ser compatveis com outros
equipamentos, mesmo sendo do mesmo fabricante, e inclusive, do mesmo modelo. No
modelo pr-seleccionado como opo - o router comercial Linksys WRT54G - a situao
descrita pode ser verificada. Neste modelo, desde que foi lanado (Dezembro 2002) at
actualidade, o hardware tem vindo a sofrer vrias alteraes ao nvel da memria,
perifricos e, principalmente, ao nvel dos processadores. Estes tm sido alterados de
acordo com o evoluir dos novos processos de fabrico (com a respectiva melhoria da
eficincia energtica e da capacidade de processamento) e da integrao de novas
tecnologias (USB por exemplo) por parte dos diversos fabricantes deste tipo de
microprocessadores. Ao longo desta evoluo, o fabricante do router em questo
(Linksys) optou por usar processadores de diversos fabricantes diferentes (Broadcom,
Atheros, Texas Instruments), conforme lhe fosse mais vantajoso em termos de custos e de
funcionalidades oferecidas. Esta diversidade levou a diversas incompatibilidades no
software entre as vrias revises do mesmo modelo.
Podemos, ento, concluir, que a plataforma mais adequada (e primeira opo dentro das
disponveis) ao objectivo do caso em estudo a ICnova AP7000 Base.

5.1.2 Sistema de testes


De modo a poder validar fisicamente o comportamento da arquitectura proposta, foi
utilizado um painel didctico com uma instalao de domtica EIB da Siemens,
construdo na FEUP no mbito de um projecto anterior [10].
Este projecto pretendia simular um auditrio duplo e de uma diviso de controlo
denominada por rgie. A lista de dispositivos por diviso apresentada tabela 5.1.
Tabela 5.8 Dispositivos presentes por diviso na simulao

Auditrios
2

Lmpadas incandescentes regulveis (Halogneo)

Lmpadas fluorescentes compactas regulveis

Lmpadas fluorescentes compactas fixas

Lmpada incandescente fixa

Simulador de estores elctricos

Touch Panel Vision

Receptor de infravermelhos

Dispositivo de comando qudruplo

Dispositivo de comando qudruplo

Rgie

56

CAPITULO 5: VALIDAO EXPERIMENTAL

Figura 5.5 Vista frontal do painel EIB

Figura 5.6 Vista traseira do painel EIB

CAPITULO 5: VALIDAO EXPERIMENTAL

Legenda:

Fonte de alimentao

Filtro Indutivo

Ligador de duas ligaes

Descodificador de
infravermelhos

Sada binria

Controlo de estores

Regulador de Fluxo de
Lmpadas Fluorescentes

Regulador de Fluxo de
Lmpadas Fluorescentes

Gateway RS-232

Figura 5.7 Legenda da instalao EIB

57

58

CAPITULO 5: VALIDAO EXPERIMENTAL

5.1.3 Gateway KNX/EIB


Como j foi referido inmeras vezes ao longo deste relatrio, um gateway um
dispositivo que permite fazer o interface entre duas redes que utilizam diferentes
protocolos de comunicao, de modo a permitir a interoperabilidade entre dois sistemas
distintos.
O gateway necessrio para a aplicao ao caso em estudo teria de permitir a interligao
entre o barramento KNX/EIB TP1 (par entranado) e as redes de dados que utilizam o
protocolo IP, de modo a que computadores ou outros equipamentos possam trocar dados
com dispositivos KNX/EIB.
O gateway IP escolhido foi o Siemens N148/21 (figura 5.8)

Figura 5.8 Gateway IP Siemens N148/21

Este gateway IP utiliza a norma KNXnet/IP Tunneling, que possibilita o envio de tramas
KNX/EIB atravs de uma rede IP, permitindo configurar, monitorizar e controlar a rede
KNX/EIB remotamente.
A conexo fsica ao barramento KNX/EIB - TP1 do painel de simulao, apresentado na
seco anterior, estabelecida atravs de um terminal de duas ligaes (conector branco e
vermelho na figura 5.8). Para a ligao rede de dados (IP atravs de 10BaseT) o
dispositivo contm um conector RJ45. O gateway pode ser alimentado por 24V AC/DC
(conector vermelho e preto da figura 5.8) [29][30].

CAPITULO 5: VALIDAO EXPERIMENTAL

59

5.1.4 Topologia do sistema de monitorizao e controlo


Web
Na figura 5.9 podemos observar a topologia dos diversos equipamentos que integram o
sistema de configurao, monitorizao e controlo Web.
No domnio da habitao (ou edifcio a controlar), a instalao KNX/EIB TP1 est
ligada rede IP do edifcio via gateway IP (Siemens N148/21). nesta rede de dados que
esto ligados os diversos dispositivos que compem o sistema, entre eles o sistema
embebido com a aplicao de servidor (que ir ser apresentada na prxima seco), os
clientes locais (PC, PDA ou smartphone) e o modem/router, que fornece ao exterior do
domnio do edifcio, o acesso rede local e instalao KNX/EIB.

Figura 5.9 Topologia do sistema de monitorizao e controlo Web

60

CAPITULO 5: VALIDAO EXPERIMENTAL

5.2 Software
5.2.1 Primeira fase
A primeira fase tem como objectivo a implementao da estrutura de aplicao do
servidor. Nesta fase, a implementao ter como destino a execuo num PC, facilitando
assim o desenvolvimento da aplicao e o debug de possveis erros.

SERVIDOR

IP
IP / EIB
Gateway

KNX / EIB TP1


KNX / EIB
Device

KNX / EIB
Device

KNX / EIB
Device

Figura 5.10 Estrutura de aplicao do servidor

5.2.1.1 Aplicao CGI de interface com a rede KNX/EIB


O objectivo principal da aplicao CGI a implementar o de receber os dados
introduzidos pelo utilizador no browser e actuar em conformidade na rede KNX/EIB.
No diagrama da figura 5.11, podemos visualizar de forma grfica o comportamento desta
aplicao.
Primeiramente, um evento no browser efectua um pedido assncrono ao servidor, via Ajax,
com os dados relevantes para a aco a efectuar (endereo de grupo e valor). Na chamada
da aplicao CGI so recolhidos os dados por um dos dois mtodos disponveis: GET ou

CAPITULO 5: VALIDAO EXPERIMENTAL

61

POST. De seguida, existe uma rotina que analisa o contedo dos dados e verifica se estes
so vlidos, isto , se so coerentes com os dispositivos KNX/EIB. Em caso afirmativo,
efectuado um tnel de comunicao na rede IP tendo como destino o gateway IP/KNX.
Depois de ser efectuada uma conexo vlida, a trama KNX/EIB com os dados recebidos
do cliente, encapsulada numa trama IP e enviada para o gateway. Este fica responsvel
por fazer o processo inverso, ou seja, retirar da trama IP a trama KNX/EIB, e ento,
inject-la no barramento KNX/EIB TP1 para que esta actue sobre o dispositivo
endereado. Depois de a comunicao ter sido efectuada com sucesso, a ligao com o
gateway IP terminada e actualizado o novo estado do dispositivo na pgina Web.
Cham ada do CG I
c o m o s d a d o s , v ia
X M L H ttp R e q u e s t

No
D a d o s c o e re n te s ?

M ensagem de
e r r o (A J A X )

S im

A b r e c o n e x o v ia IP
c o m o g a t e w a y IP /K N X

S em sucesso

C om sucesso

E n v ia t r a m a K N X /E IB
e n c a p s u la d a n u m a
tra m a IP

S em sucesso
M ensagem de
e rro (A J A X )

C om sucesso
S em sucesso
Fecha conexo com
o g a te w a y IP /K N X

C om sucesso

A c tu a liz a e s ta d o d o
d is p o s it iv o n o b r o w s e r
(A J A X )

Figura 5.11 Diagrama de execuo do CGI

De modo a que a aplicao CGI possa fazer a conexo ao gateway IP/KNX, necessrio
um cliente KNX/EIB que estabelea um tnel de comunicao IP at este.
Chegados a esse ponto, temos duas hipteses: implementar um cliente KNX/EIB ou usar
um cliente j desenvolvido que fornea os mtodos necessrios.
Uma vez que a hiptese da implementao seria incompatvel com o tempo disponvel
para a realizao deste projecto, devido fundamentalmente necessidade de um estudo

62

CAPITULO 5: VALIDAO EXPERIMENTAL

mais profundo e exaustivo do standard KNX/EIB, optou-se pelo uso de um cliente j


desenvolvido.
Nesta rea existem duas hipteses disponveis, o eibnetmux [31] e o eibd [32]. Ambos so
clientes KNX/EIB de cdigo aberto, que fornecem mtodos em C e PHP que permitem
aceder aos dispositivos na rede, abstraindo o utilizador da complexidade do protocolo
KNXnet/IP Tunnelling.
Para este projecto foi utilizado o eibd porque o cliente que conta com uma maior
maturidade, ao contrrio do mais recente eibnetmux que ainda se encontra numa verso
experimental, demonstrando alguma instabilidade no seu funcionamento.

5.2.1.2 Interface Web exemplo para a validao


De modo a facultar ao utilizador a actuao de um dispositivo na rede KNX/EIB-TP1, foi
elaborado um interface Web simples, que implementa uma funo do tipo EIS1
Switching para ligar/desligar uma lmpada, com toda a tecnologia escolhida para esta
aplicao.
Este interface, ilustrado na figura 5.12, permite inserir um endereo de grupo e mudar o
seu valor. Quando accionado o boto, submetido para o servidor um pedido assncrono
(Ajax) com o endereo e o valor requeridos. A aplicao CGI, no servidor, interpreta os
dados recebidos e actua sobre a rede, tal como foi explicado na seco anterior. No final
da execuo do CGI, se todos os passos tiverem sido correctamente efectuados - isto ,
sem erros - o novo estado dinamicamente alterado na pgina Web, sem ser efectuado um
novo carregamento desta. A figura 5.13 ilustra a mudana no estado do dispositivo no caso
de uma actuao efectuada com sucesso, e a figura 5.14 ilustra um caso de erro no
processo de mudana de estado ou uma falha no dispositivo.

Figura 5.12 Interface Web com dispositivo desactivado

CAPITULO 5: VALIDAO EXPERIMENTAL

Figura 5.13 Interface Web com dispositivo activado

Figura 5.14 Interface Web com erro no dispositivo

63

64

CAPITULO 5: VALIDAO EXPERIMENTAL

De modo a ultrapassar as pequenas discrepncias existentes entre os diversos browsers,


facilitar a seleco de elementos de uma pgina e a reduzir ao mximo a complexidade das
comunicaes assncronas, a interaco em Ajax com o servidor foi implementada
recorrendo a biblioteca jQuery, j brevemente resumida no captulo 3.
Foi utilizado o mtodo jQuery.get() presente nesta biblioteca para implementar o pedido
assncrono ao servidor.
Este mtodo encontra-se definido na documentao oficial da biblioteca [17]:
jQuery.get( url, [data], [callback] )
O parmetro url representa o caminho relativo para uma pgina a carregar, sendo, neste
caso em estudo, o caminho para a aplicao CGI no servidor.
O parmetro data representa as variveis que sero enviadas para o servidor, que, neste
caso, sero os trs nveis do endereo de grupo do dispositivo e o valor a actuar neste.
O parmetro callback representa a funo que ser invocada quando os dados forem
carregados com sucesso.
Os parmetros [] so opcionais.

$("#accionar").click(
function(){
var val ;
if( $("#val_off").attr('checked')==true){val=0;}
if( $("#val_on").attr('checked')==true){ val=1;}
$.get("/cgi-bin/cgi_eis1.cgi",
{g_addr_1 : $("#g_addr_1").val() ,
g_addr_2 : $("#g_addr_2").val(),
g_addr_3:$("#g_addr_3").val(), val : val},
function(data){ $("#imagem").html(data); })
})

O cdigo acima mencionado representa a implementao efectuada deste mtodo no caso


em estudo. O selector $( ) do jQuery permite-nos seleccionar de forma fcil todos os

CAPITULO 5: VALIDAO EXPERIMENTAL

65

elementos constituintes de uma pgina Web. A aco de um click no boto com a


identificao accionar ir seleccionar os radio buttons e verificar o seu estado. De
seguida, ser chamada a aplicao CGI do servidor com os dados relevantes. Quando
receber a resposta do servidor, o elemento HTML com a identificao de imagem ser
actualizado com os novos dados. Este elemento ser a imagem que representa o estado
dispositivo.

5.2.2 Segunda fase


Aps a implementao efectuada na primeira etapa, a segunda fase tinha como por
objectivo o port da implementao efectuada na etapa atrs descrita, para o sistema
embebido escolhido na seco 5.1.1, a placa ICnova AP7000.
Aps o estudo efectuado sobre o mtodo e as ferramentas de cross-compiling, foi
elaborado um guia de cross-compiling da aplicao para a plataforma escolhida (AVR32),
que se encontra como anexo deste relatrio. Este guia tem todos os passos necessrios
para a compilao de toda a aplicao do servidor para um sistema embebido.
Espera-se, tambm, que este guia seja til para a grande maioria dos sistemas embebidos,
uma vez que apenas ser necessrio mudar a varivel host que passada como argumento
aos vrios scripts de configurao das bibliotecas utilizadas.
A aplicao CGI de teste, o cliente KNX/EIB de interface com o gateway IP/EIB e todas
as bibliotecas necessrias por estas, foram compiladas com sucesso de acordo com o guia
desenvolvido e apresentado como anexo deste relatrio.
Aps a fase de compilao ter sido efectuada sem grandes problemas, na fase de
execuo da aplicao onde foram encontrados os problemas mais relevantes, tendo como
consequncia desta situao, o dispndio de uma poro de tempo importante.
A execuo do cliente KNX/EIB no sistema embebido gera um erro (segmentation fault),
que faz com que toda a aplicao termine, sem efectuar qualquer aco no sistema.
Aps um longo perodo testes, e com a cooperao do programador que desenvolveu o
cliente, foi possvel isolar o problema. O problema do segmentation fault era causado por
uma biblioteca externa utilizada pelo cliente KNX/EIB, denominada de GNU Pth - The
GNU Portable Threads . A compilao das rotinas de teste presentes nesta biblioteca e a
sua execuo na plataforma embebida puderam comprovar a fonte do problema: sempre
que estas eram executadas, causavam o erro j descrito.
Aps uma breve pesquisa pela Internet, pde-se observar que este problema j no novo,
havendo algumas situaes de segmentation fault com a biblioteca GNU Pth em sistemas
equipados com o microprocessador AVR32.
Como ambos os clientes (eibnetmux e eibd) disponveis para a integrao com a aplicao
CGI, capazes de estabelecer o tnel de comunicao sobre IP com o gateway, utilizam na

66

CAPITULO 5: VALIDAO EXPERIMENTAL

sua concepo a mesma biblioteca, GNU Pth, no foi possvel a substituio de um cliente
pelo outro, uma vez que o problema se iria manter.
Numa tentativa de perceber a origem do segmentation fault na execuo do cliente
KNX/EIB, e, juntamente com a colaborao do responsvel deste e do responsvel da
Atmel pelo port do Linux para a plataforma AVR32, chegou-se concluso que o
problema estaria no software do sistema embebido ICnova AP7000 (ao nvel do kernel ou
das bibliotecas presentes no S.O.). At ao presente momento, no foi possvel descobrir a
exacta localizao do problema, bem como a sua resoluo.
De modo a poder continuar com o principal objectivo da segunda fase da implementao,
foi utilizada a opo do router OEM, j atrs mencionada como uma alternativa possvel.
Disto resultou uma pequena variao da topologia do sistema de monitorizao e controlo
Web apresentado na seco 5.1.4. A nova topologia apresentada na figura 5.15.

Figura 5.15 Nova topologia do sistema de monitorizao e controlo Web

A grande diferena nesta nova alternativa encontra-se ao nvel da plataforma onde


executada a aplicao do servidor.
Aps o estudo do hardware (nomeadamente o processador e a sua arquitectura interna)
presente no router OEM j atrs mencionado (figura 5.3), um CPU Atheros AR231X

CAPITULO 5: VALIDAO EXPERIMENTAL

67

(MIPS), foi utilizado o toolchain disponvel para esta plataforma, para recompilar a
aplicao do servidor, tal como havia sido feito para a plataforma ICnova AP7000.
A compilao para esta plataforma da aplicao CGI, do cliente KNX/EIB e das
bibliotecas requeridas por estes foi executada com sucesso, utilizando o guia j
desenvolvido anteriormente.
Nesta plataforma, ao contrrio da ICnova AP7000, a aplicao funcionou sem qualquer
tipo de problema. A nica limitao encontra-se no suporte passagem de parmetros
pelos mtodos GET ou POST das aplicaes CGI, imposta por parte do servidor Web.
Para isso foi utilizado um outro servidor Web, o Boa Webserver [42]. Esta opo
utilizada numa grande variedade de sistemas embebidos devido sua simplicidade, sua
eficcia e ao suporte total para aplicaes CGI.

5.3 Testes e resultados


5.3.1 Primeira fase
Os objectivos da primeira fase de desenvolvimento - a implementao da estrutura de
aplicao do servidor, tendo como plataforma de execuo um PC, e do interface de
controlo apresentado na seco 5.2.1.2 - foram completados com sucesso. A partir do
interface Web desenvolvido, foi possvel actuar em vrios dispositivos do tipo EIS1, os
actuadores binrios ON/OFF (Siemens N561) das lmpadas do painel didctico EIB, de
acordo com o exemplo definido para a validao da arquitectura implementada.

5.3.2 Segunda fase


A segunda fase tinha como objectivo o port da aplicao desenvolvida na etapa anterior,
bem como todos os componentes necessrios execuo da mesma, tendo como destino o
sistema embebido seleccionado para o efeito.
Apesar da escolha inicial ter recado sobre o sistema embebido ICnova AP7000, os
problemas encontrados ao nvel do software desta plataforma no permitiram avanar com
esta para a soluo final. Para continuar com o processo de validao da arquitectura
proposta, foi escolhida a opo de utilizar um router OEM como plataforma de suporte
para aplicao desenvolvida.
Os novos problemas encontrados com passagem para o novo sistema foram resolvidos e
toda a aplicao ficou, agora, num estado funcional. Deste modo, a soluo final que
permitiria validar a arquitectura funcional proposta estava concluda.

68

CAPITULO 5: VALIDAO EXPERIMENTAL

Para a validao final do sistema foi testado, mais uma vez, o controlo dos vrios
dispositivos EIS 1 do painel didctico EIB, via interface Web. As aces sobre este
sistema de domtica foram efectuadas, com sucesso, atravs de um browser de um PC e
de um browser de um PDA. As interaces assncronas implementadas em Ajax entre
cliente servidor funcionaram com o comportamento desejado, tambm, nestas duas
plataformas clientes distintas.

Captulo 6

6. Concluso e Perspectivas de
Desenvolvimento
Nesta dissertao apresentou-se o projecto e a implementao de um sistema de
superviso, monitorizao e controlo remoto via Web de instalaes de domtica
respeitantes com standard aberto KNX/EIB.
Este sistema tinha como objectivos essenciais: o uso de uma plataforma de hardware com
um baixo custo de aquisio, um baixo consumo elctrico (de modo a estar sempre ligada)
e desprovida de software proprietrio (execuo e desenvolvimento), capaz de servir como
base para a estrutura de software a desenvolver. Esta estrutura de software teria de
permitir o acesso aos dispositivos da instalao de domtica, atravs de qualquer
dispositivo com um browser e acesso Internet.
Neste trabalho, foi feito um estudo sobre as diversas tecnologias Web disponveis, capazes
de suportar a estrutura de software e os objectivos j atrs mencionados. Como resultado
do estudo efectuado, foi possvel conceber trs possveis abordagens para a concepo da
arquitectura funcional, recorrendo a diferentes tecnologias. Aps serem discutidas as
consideraes sobre vantagens e desvantagens de cada uma das trs propostas, foi eleita a
soluo mais conveniente para a arquitectura funcional do sistema.
A fase seguinte foi a implementao prtica de um exemplo simples, de modo a poder
validar a arquitectura escolhida. Nesta fase, numa etapa inicial, foi concebido um interface
Web (baseado em HTML, JavaScript e Ajax de modo a poder actuar num dispositivo do
tipo EIS1) e uma aplicao CGI compatvel com esse interface. Esta aplicao teve, nesta
etapa, como plataforma de execuo, um PC (de modo a facilitar o desenvolvimento e o
debug de possveis erros). Esta etapa foi concluda com sucesso, funcionado como o
previsto, isto , acendendo uma lmpada no painel didctico EIB atravs de um interface
Web.
A segunda etapa desta fase, tinha por objectivo o port da aplicao Web de controlo,
desenvolvida com sucesso na primeira etapa, para a execuo no sistema embebido
69

70

CAPTULO 6: CONCLUSO E PERSPECTIVAS DE DESENVOLVIMENTO

seleccionado (ICnova AP7000). Nesta etapa, foi efectuado um estudo sobre o processo de
cross-compiling que permitiu recompilar a aplicao CGI, o cliente KNX/EIB e
respectivas bibliotecas necessrias. Foi concebido uma guia de compilao de toda a
aplicao do servidor, para o sistema embebido, estando como anexo deste documento.
Nesta etapa, foram verificados os primeiros problemas.
Apesar das compilaes de todos os componentes da aplicao do servidor terem sido
efectuadas com sucesso, a execuo de uma biblioteca externa (GNU Pth) da qual toda a
aplicao depende, gera um erro (segfault), que no foi possvel solucionar at ao presente
momento. Com a cooperao do responsvel pela API cliente KNX/EIB e do responsvel
pelo port do Linux para a plataforma AVR32 (CPU da ICnova AP7000), pde-se concluir
que existe um bug (sem soluo no tempo til para este projecto) ao nvel do software do
sistema embebido escolhido para esta aplicao (ICnova AP7000).
De modo a prosseguir com o processo de validao, foi utilizada outra opo no que diz
respeito plataforma de hardware do servidor.
Como a grande maioria do equipamento de gesto de redes baseado em Linux, e, numa
instalao onde exista um acesso contnuo Internet, a probabilidade de existir um router
elevada, surge a hiptese da utilizao deste como plataforma de hardware de suporte
para a estrutura do software do servidor.
Para a validao da arquitectura escolhida com esta nova plataforma, procedeu-se a uma
anlise do hardware envolvido, no interior do router OEM disponvel para o efeito. Aps
o conhecimento do fabricante, do modelo e da arquitectura interna do CPU, procedeu-se
recompilao de todo o software (aplicao CGI, cliente KNX/EIB e respectivas
bibliotecas) recorrendo a um toolchain para esta plataforma especfica.
Ao contrrio do sistema embebido seleccionado para o efeito, no router no houve
nenhum problema na execuo das aplicaes e respectivas bibliotecas. A nica limitao
foi o no suporte passagem de parmetros para o CGI, atravs dos mtodos GET ou
POST. De modo a colmatar esta falha foi utilizado um outro servidor Web, o Boa
Webserver, que oferece uma grande eficcia, boa simplicidade de utilizao e
configurao, e ainda um bom suporte para aplicaes CGI.
Resolvida esta falha, toda a aplicao do servidor desenvolvida ficou operacional, tendo
ficado completa a implementao para validao da arquitectura funcional proposta.
Esta soluo final funcionou de acordo com o que era previsto para o exemplo de
validao do sistema, com a interaco entre cliente e servidor a ser efectuada via Ajax e
agindo correctamente sobre os actuadores do tipo EIS 1 no painel didctico EIB
disponvel para este projecto.
Pde-se concluir que a nova abordagem e soluo final da arquitectura proposta nesta
dissertao apresentou grandes benefcios quando comparada com a abordagem prevista

CAPTULO 6: CONCLUSO E PERSPECTIVAS DE DESENVOLVIMENTO

71

inicialmente. Destaca-se a melhor eficincia energtica (uma vez que no necessrio um


sistema embebido dedicado sempre ligado), a inexistncia do custo da aquisio deste
(uma vez que toda a aplicao executada no router como um servio extra) e a liberdade
oferecida para o controlo local (edifcios ou habitaes) atravs de plataformas mveis
(PDAs, Smartphones, etc), proporcionada pela capacidade de rede sem fios da plataforma
escolhida, o router wireless.
Com a implementao da plataforma base do servidor, tanto ao nvel do hardware como
ao nvel da arquitectura do software, espera-se como perspectiva de desenvolvimento
futuro, que estejam criadas as condies necessrias ao desenvolvimento de uma aplicao
completa e funcional de monitorizao e controlo via Web.

Referncias Bibliogrficas
[1] Alves, Jos, Casas Inteligentes, Centro Atlntico, 2003
[2] http://www.electronica-pt.com/index.php/content/view/67/43/ - Acedido em 11/Junho/2008
[3] http://acasainteligente.blog.com/ - Acedido em 11/Junho/2008
[4] http://www.casadomo.com/ - Acedido em 3/Junho/2008
[5] KNX : The World`s Only Open Standard for Home and Building Control - www.knx.org
[6] KNX Handbook Volume 3: System Specifications Chapter 1: Architecture
[7] KNX HANDBOOK, KNX Specification, Konnex Association, 2004
[8] Palma, Diana, FEUP KNX-Domtica KNX/EIB de Baixo Custo, Maro 2008
[9] Communication Medium - IR EIBA Handbook Series, Release 3.0
[10] Monteiro, Jos, Montagem de um sistema didctico utilizando a tecnologia Instabus/EIB da
Siemens, Dezembro 2004
[11] Santos, Domingos, Sistemas e Planeamento Industrial , Setembro 2007
[12] EIBA Handbook Series, Release 3.0, Volume 1, Part 2, Abril 1999
[13] http://ezinearticles.com/?JavaScript-for-Web-Design---Advantages-andnDisadvantages&id=645013 Acedido em 15/Junho/2008
[14] http://www.expertrating.com/courseware/JavaScriptCourse/JavaScript-Introduction-1.asp
Acedido em 15/Junho/2008
[15] Holzner, Steven, Ajax Bible, John Wiley & Sons, 2007
[16] http://www.adaptivepath.com/ideas/essays/archives/000385.php - Acedido em 16/Junho/2008
[17] www.jquery.com - Acedido em 16/Junho/2008
[18] http://hoohoo.ncsa.uiuc.edu/cgi/intro.html - Acedido em 17/Junho/2008
[19] Gundavaram, Shishir , CGI Programming on the World Wide Web, Maro 1996.
[20] Coelho, Pedro, Programao em Java 2 FCA, 2003
[21] http://doc.ece.uci.edu/~klefstad/s/180a/app.html - Acedido em 20/Junho/2008
[22] David Powers, PHP Solutions: Dynamic Web Design Made Easy, Apress, 2006

[23] www.php.net - Acedido em 21/Junho/2008


[24] http://www.upto11.net/generic_wiki.php?q=embedded_system - Acedido em 21/Junho/2008
[25] Using Linux in Embedded Systems and Smart Devices - www.linuxdevices.com - Acedido
em 23/Junho/2008
[26] www.picotux.com - Acedido em 23/Junho/2008
[27] http://www.scratchbox.org/documentation/general/tutorials/introduction.html
[28] http://www.ic-board.de/product_info.php?info=p75_ICnova-AP7000-Base.html
[29] Federal Standard 1037C - http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm - Acedido em
26/Junho/2008
[30] Siemens N148/21 Operating and mounting instructions, Janeiro 2007
[31] http://sourceforge.net/projects/eibnetmux/ - Acedido em 2/Maio/2008
[32] http://sourceforge.net/projects/bcusdk/ - Acedido em 2/Maio/2008

[33] WEINZIERL ENGINEERING GmbH, Implementation of KNX Standard, Outubro


2006
[34] Carter, Alex EIB and Konnex succeed in bringing true building interoperability in
accordance

with EN50090, Agosto 2004

[35] Flores, Antnio ,A criao de valor no binmio: casa inteligente / consumidor


[36] http://www.acasainteligente.com/sistemas.asp?idSist=5 - Acedido em 26/Junho/2008
[37] http://www.domotica-vivimat.com/index.php - Acedido em 28/Junho/2008
[38] http://webserver.jgdomotica.com/ - Acedido em 28/Junho/2008
[39] http://www.jgdomotica.com - Acedido em 29/Junho/2008
[40] http://cardio.pt/ - Acedido em 29/Junho/2008
[41] http://www.secant.ca/En/index.htm - Acedido em 29/Junho/2008
[42] Boa Webserver - http://www.boa.org/
[43] Accton : Networking Equipments - http://www.accton.com/index.htm

ANEXO 1
Guia de Cross-Compiling do eibd
para a arquitectura AVR32

O AVR32 GNU Toolchain um conjunto de programas standalone usados para criar


aplicaes para os microprocessadores da famlia AVR32 da Atmel. Estas aplicaes
podem correr como aplicaes embebidas ou em cima de um sistema operativo como o
Linux.
Este toolchain distribudo gratuitamente pela Atmel e est disponvel no site da mesma,
tanto para plataformas Linux como para plataformas Windows.

Instalao do AVR32 Toolchain no Ubuntu:


1. Descarregar o toolchain mais recente do site da Atmel para a distribuio de Linux
que vai ser usada (neste caso Ubuntu, mas tambm existem para Fedora ou SUSE).

2. Confirmar se as verses mais recentes das seguintes bibliotecas, usadas pelo


toolchain esto presentes no sistema. Se no estiverem instaladas, devero ser
instaladas (pode-se utilizar o gestor de pacotes da distribuio, neste caso o
Synaptic).

Nome

Verso

libdwarf

20080208

xerces-c

2.8.0

libelf

0.8.9

libboost

1.33.1

3. Descomprimir o toolchain para um directrio e instalar todos os pacotes (apesar de


no serem todos necessrios). Alguns pacotes dependem de outros que devem ser
previamente instalados. Os pacotes podem ser instalados por vrias ordens
diferentes, como por exemplo a seguinte:
- libavrtools
- libavr32sim
- libavr32ocd
- libelfdwarf
- avrfwupgrade
- avr32-uclibc-kernelheaders
- avr32-uclibc-_0.9
- avr32trace
- avr32program
- avr32-binutils_2.17
- avr32-gcc
- avr32-gbd
- avr32gbdproxy
- avr32headers
- avr32parts
- avr32-linux-binutils
- avr32-linux-gcc
- avr32-linux-gdb

4. Descarregar os seguintes arquivos do site do projecto :


pthsem-2.0.7.tar.gz
argp-standalone-1.3.tar.gz
bcusdk_0.0.3.tar.gz

5. Descomprimir o arquivo pthsem-2.0.7.tar.gz e aceder ao novo directrio:


tar -zxf pthsem-2.0.7.tar.gz
cd pthsem-2.0.7

6. Copiar
os
ficheiros
config.guess
e
config.sub
do
directrio
ICnova_Base/package/gnuconfig do CD para a pasta pthsem-2.0.7 e substituir os
existentes se tal for pedido.

7. Compilar e instalar a biblioteca pthsem-2.0.7 para a arquitectura AVR32:


./configure --host=avr32-linux --prefix=/usr/avr32-linux
make
make install

8. Descomprimir o arquivo argp-standalone-1.3.tar.gz e aceder ao novo directrio:


tar -zxf argp-standalone-1.3.tar.gz
cd argp-standalone-1.3

9. Copiar
os
ficheiros
config.guess
e
config.sub
do
directrio
ICnova_Base/package/gnuconfig do CD para a pasta argp-standalone-1.3 e
substituir os existentes se tal for pedido.

10.Compilar e instalar a biblioteca argp-standalone-1.3 para a arquitectura AVR32:


./configure --host=avr32-linux --prefix=/usr/avr32-linux
make
make install

11.Descomprimir o arquivo bcusdk_0.0.3.tar.gz e aceder ao novo directrio:

tar -zxf bcusdk_0.0.3.tar.gz


cd bcusdk_0.0.3

12.Copiar
os
ficheiros
config.guess
e
config.sub
do
directrio
ICnova_Base/package/gnuconfig do CD para a pasta bcusdk_0.0.3 e substituir os
existentes se tal for pedido.

13.Compilar e instalar o EIBD para a arquitectura AVR32:

./configure --host=avr32-linux --prefix=/usr/avr32-linux


--with-pth=/usr/avr32-linux --without-pth-test --enable-onlyeibd
--enable-eibnetiptunnel
make
make install

14.Para criar o ficheiro executvel do EIBD para colocar no sistema embebido, com
todas as bibliotecas contidas nesse mesmo executvel, aceder a
/bcusdk_0.0.3/eibd/server:
rm eibd
make

15.Copiar o ltimo comando executado no make anterior e adicionar static e executar


outra vez. O ficheiro executvel eibd resultante, presente nesse directrio o que
dever ser copiado para plataforma AVR32.

16.Para compilar o CGI com o acesso ao EIBD:


avr32-linux-gcc -o cliente_eibd.cgi cgi.c common.c -leibclient