KNX Fomacao

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
Junho 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 1.2 1.3 1.4
Enquadramento ................................................................................................................... 1 Motivao............................................................................................................................ 2 Objectivos ........................................................................................................................... 3 Estrutura do relatrio........................................................................................................... 4
2.
Domtica
2.1 2.2 2.3
Introduo ........................................................................................................................... 5 Arquitectura ........................................................................................................................ 5 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
3.1
15
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.1 Linux embebido.................................................................................................... 36 3.3.2 Cross-Compiling......................................................................................................... 37
3.3.1 Sistemas Operativos para sistemas embebidos ........................................................... 35
4.
Arquitectura Funcional
4.1
39
Primeira abordagem .......................................................................................................... 39
4.1.1 Primeira alternativa..................................................................................................... 40 4.1.2 Segunda alternativa..................................................................................................... 41 4.1.3 Terceira alternativa ..................................................................................................... 42 4.2 4.3 Segunda abordagem .......................................................................................................... 43 Terceira abordagem........................................................................................................... 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.3.1 KNX @ HOME .......................................................................................................... 44
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
5.1
49
Hardware ........................................................................................................................... 49
5.1.1 Sistema embebido para a plataforma do servidor ....................................................... 49 5.1.2 Sistema de testes ......................................................................................................... 51 5.1.3 Gateway KNX/EIB ..................................................................................................... 54 5.1.4 Topologia do sistema de monitorizao e controlo Web............................................ 55
NDICE 5.2
XIII
Software ............................................................................................................................ 56 5.2.1.1 Aplicao CGI de interface com a rede KNX/EIB .............................................. 56 5.2.1.2 Interface Web exemplo para a validao.............................................................. 58
5.2.1 Primeira fase ............................................................................................................... 56
5.2.2 Segunda fase ............................................................................................................... 61 5.3 Testes e resultados ............................................................................................................ 61
5.3.1 Primeira fase ............................................................................................................... 61 5.3.2 Segunda fase ............................................................................................................... 61
6.
Concluso e Perspectivas de Desenvolvimento
65 71
ANEXO 1
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 [28] ................................................................................................ 49 FIGURA 5.2 PICOTUX [26] ............................................................................................................. 50 FIGURA 5.3 VISTA FRONTAL DO PAINEL EIB................................................................................ 52 FIGURA 5.4 VISTA TRASEIRA DO PAINEL EIB............................................................................... 52 FIGURA 5.5 LEGENDA DA INSTALAO EIB ................................................................................ 53 FIGURA 5.6 GATEWAY IP SIEMENS N148/21 ............................................................................... 54 FIGURA 5.7 TOPOLOGIA DO SISTEMA DE MONITORIZAO E CONTROLO WEB ............................ 55 FIGURA 5.8 ESTRUTURA DE APLICAO DO SERVIDOR ................................................................ 56 FIGURA 5.10 INTERFACE WEB COM DISPOSITIVO DESACTIVADO ................................................. 58 FIGURA 5.11 INTERFACE WEB COM DISPOSITIVO ACTIVADO ....................................................... 59 FIGURA 5.12 INTERFACE WEB COM ERRO NO DISPOSITIVO.......................................................... 59
XVI
LISTA DE FIGURAS
FIGURA 5.13 NOVA TOPOLOGIA DO SISTEMA DE MONITORIZAO E CONTROLO WEB................ 63 FIGURA 5.14 ROUTER LA FONERA UTILIZADO NA NOVA ABORDAGEM ......................................... 64
LISTA DE TABELAS
XVII
Lista de Tabelas
TABELA 3.1 TIPOS DE DADOS EIS ................................................................................................ 25 TABELA 5.1 DISPOSITIVOS PRESENTES POR DIVISO NA SIMULAO .......................................... 51
XVIII
LISTA DE TABELAS
LISTA DE ACRNIMOS
XIX
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 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
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 tipo de 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.
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 CONTROLADOR SENSOR
barramento CONTROLADOR
SENSOR
SENSOR
INTERFACE
barramento
INTERFACE
SENSOR
CONTROLADOR
SENSOR
INTERFACE
ACTUADOR
Figura 2.2 Arquitectura descentralizada
Num sistema de domtica, uma arquitectura distribuda caracteriza-se pelo facto de cada elemento do sistema, seja 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 domstico 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 como 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.
12
CAPTULO 2: DOMTICA
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].
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 so a 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.
14
CAPTULO 2: DOMTICA
De qualquer telefone da casa, sendo guiado por uma voz em portugus atravs de menus de opes. 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.
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
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
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 evitar colises, o CSMA/CD (Carrier Sense Multiple Access with Collision Detection) [5][7][8].
20
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
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
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 mtodo 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 defeito com um conjunto de parmetros de funcionamento [5][7][8].
23
3.1.5.3 Modo A
Existe, ainda, um terceiro mtodo, denominado automatic mode, que foi recentemente especificado na norma KNX. Este mtodo 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
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
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 EIS 1 EIS 2 EIS 3 EIS 4 EIS 5 Funo EIB SWITCHING DIMMING TIME DATE VALUE Dimenso 1bit 4bit 3bytes 3bytes 2bytes Descrio Acendido / Apagado, ON/OFF, TRUE/FALSE Aumenta (+)/ Diminui(-), Valor Dia da semana, hora, minutos e segundos Dia / ms / ano 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%) Mover baixo/cima, Abrir/Fechar Activado / Desactivado Codificao de um nmero em vrgula flutuante Representa os valores de um contador de 16 bits Representa os valores de um contador de 32 bits Cdigo de acesso de segurana Codificao de caracteres ASCII Representa os valores de um contador de 8 bits Transmite uma string at 14 bytes
EIS 6 EIS 7 EIS 8 EIS 9 EIS 10 EIS 11 EIS 12 EIS 13 EIS 14 EIS 15
SCALING CONTROL DRIVE PRIORITY FLOAT VALUE 16BIT COUNTER 32BIT COUNTER ACCESS CHARACTER ASCII 8BIT COUNTER CHARACTER STRING
8bit 1bit 1bit 4bytes 2bytes 4bytes 4bytes 8bit 8bit 14bytes
26
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 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 interactivos 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 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 executam do lado do cliente.
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
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].
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 robusta compatibilidade 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
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
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
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.
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
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].
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
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].
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].
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.

Servlet JAVA API Calimero
SERVIDOR
Apache Tomcat
CLIENTE
WWW

KNX / EIB Device KNX / EIB Device KNX / EIB Device
Applet JAVA
HTML Javascript AJAX
Browser
IP
IP / EIB Gateway
KNX/EIBTP1
Figura 4.1 Arquitectura proposta na 1 alternativa da 1 abordagem
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
Browser
IP
IP / EIB Gateway
KNX/EIBTP1
42
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

IP / EIB Gateway
Apache Tomcat
WWW
JDBC
SQL
Servlet JAVA
Aces a executar + Histrico das aces Dispositivos + Info instalao Utlizadores
API Calimero
IP
HTML Javascript AJAX Browser
KNX/EIBTP1
CLIENTE
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.

KNX / EIB Device
SERVIDOR CLIENTE
WWW
Browser
IP
IP / EIB Gateway
KNX/EIBTP1
KNX / EIB Device
KNX / EIB Device
Figura 4.4 Arquitectura proposta na 2 abordagem
44
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.
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
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.
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
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: VALIDAO
49
Capitulo 5
5. Validao
Neste captulo, ser descrita uma implementao prtica de um exemplo simples, de modo a poder validar a soluo da arquitectura funcional proposta no captulo anterior. Este exemplo ter como objectivo o comando de um dispositivo KNX/EIB do tipo EIS1 via Web.
5.1 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 duas opes disponveis no mercado que cumprem estes objectivos: D) ICnova AP7000 Base
Hardware
CPU RAM Flash Ethernet Interfaces Atmel AVR32 @ 140MHz 64 MB 8 MB 10/100Mbit USB-UART via CP2102 UART, I2C Conversor DC/DC integrado 5-10V Figura 5.1 ICnova AP7000 [28]
Alimentao
50
CAPITULO 5: VALIDAO
Software
S.O. Shell Aplicaes uClinux 2.6.24 Busybox 1.0 Servidor Web, Telnet, SSH deamon
Custo
95
E) picotux
Hardware
32-bit ARM 7 Netsilicon NS7520 @ 55mhz 8 MB 2 MB 10/100Mbit Srie TTL, at 230.400 bps 250mA @ 3,3V
CPU RAM Memria Flash Ethernet Interfaces Alimentao
Software
Figura 5.2 picotux [26] S.O. Shell Sistema de ficheiros Aplicaes uClinux 2.4.27 Busybox 1.0 CRAMFS, JFFS2, NFS Servidor Web, Telnet
Custo
142
CAPITULO 5: VALIDAO
51
F) Escolha da plataforma de hardware para o servidor Depois de apresentadas as duas solues para a plataforma do servidor era necessrio escolher uma. A plataforma picotux (figura 5.2) apresenta-se como excelente 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). Podemos, ento, concluir, que a plataforma mais adequada 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 com uma instalao de domtica EIB da Siemens, construdo 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.1 Dispositivos presentes por diviso na simulao
Auditrios
2 2 2 1 1 1 1 Lmpadas incandescentes regulveis (Halogneo) Lmpadas fluorescentes compactas regulveis Lmpadas fluorescentes compactas fixas Simulador de estores elctricos Receptor de infravermelhos Dispositivo de comando qudruplo Sensor de presso comum aos dois auditrios 1 1 1
Rgie
Lmpada incandescente fixa Touch Panel Vision Dispositivo de comando qudruplo
52
CAPITULO 5: VALIDAO
Figura 5.3 Vista frontal do painel EIB
Figura 5.4 Vista traseira do painel EIB
CAPITULO 5: VALIDAO
53
Legenda:
1 2 3 4 5 6 7
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
8 9
Figura 5.5 Legenda da instalao EIB
54
CAPITULO 5: VALIDAO
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.6)
Figura 5.6 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.6). 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.6) [29][30].
CAPITULO 5: VALIDAO
55
5.1.4 Topologia do sistema de monitorizao e controlo Web

Na figura 5.7 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.7 Topologia do sistema de monitorizao e controlo Web
56
CAPITULO 5: VALIDAO
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/EIBTP1
Figura 5.8 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.9, 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
CAPITULO 5: VALIDAO
57
da aplicao CGI so recolhidos os dados por um dos dois mtodos disponveis: GET ou 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.
C ham ada do C G 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
N o D a d o s c o e re n te s ?
M ensagem de e rro (A J A X )
S im S em sucesso
A b r e c o n e x o v ia IP c o m o g a te w a y IP /K N X
C om sucesso S em sucesso
M ensagem de e rro (A J A X )
E n v ia tr a m a K N X /E IB e n c a p s u la d a n u m a tr a m a IP
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 itiv o n o b r o w s e r (A J A X )
Figura 5.9 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 mais profundo e exaustivo do standard KNX/EIB, optou-se pelo uso de um cliente j desenvolvido.
58
CAPITULO 5: VALIDAO
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. Este interface, ilustrado na figura 5.10, 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.11 ilustra a mudana no estado do dispositivo no caso de uma actuao efectuada com sucesso, e a figura 5.12 ilustra um caso de erro no processo de mudana de estado ou uma falha no dispositivo.
Figura 5.10 Interface Web com dispositivo desactivado
CAPITULO 5: VALIDAO
59
Figura 5.11 Interface Web com dispositivo activado
Figura 5.12 Interface Web com erro no dispositivo
60
CAPITULO 5: VALIDAO
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); }) })
CAPITULO 5: VALIDAO
61
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 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 primeira fase para o sistema embebido escolhido na seco 5.1.1. Aps o estudo efectuado sobre o mtodo e as ferramentas de cross-compiling, foi elaborado um guia de cross-compiling, que se encontra como anexo deste relatrio. Este guia tem todos os passos necessrios para a compilao de toda a aplicao do servidor num 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.
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 de uma pgina Web, foi possvel actuar num dispositivo do tipo EIS1, o actuador ON/OFF (Siemens N561) de uma lmpada do painel EIB.
5.3.2 Segunda fase

A segunda fase tinha como objectivo o port da aplicao de servidor desenvolvida na primeira fase para o sistema embebido ICnova AP7000. Nesta fase, foram encontrados os primeiros problemas.
62
CAPITULO 5: VALIDAO
A aplicao CGI de teste, o cliente KNX/EIB de interface com o gateway IP e todas as bibliotecas necessrias por estas, foram compiladas com sucesso de acordo com o guia apresentado como anexo deste relatrio. A execuo do cliente KNX/EIB no sistema embebido gera um erro (segmentation fault), que faz com que este termine, sem efectuar qualquer aco. 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 CPU 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 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 proposta uma variao da topologia do sistema de monitorizao e controlo Web apresentado na seco 5.1.4. A nova topologia apresentada na figura 5.13.
CAPITULO 5: VALIDAO
63
Figura 5.13 Nova topologia do sistema de monitorizao e controlo Web
A diferena nesta nova proposta encontra-se ao nvel da plataforma onde executada a aplicao do servidor. 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 modem/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. De modo a poder validar esta nova soluo, foi recomeada a segunda fase da implementao, agora tendo como destino a nova plataforma (figura 5.14)
64
CAPITULO 5: VALIDAO
Figura 5.14 Router La Fonera utilizado na nova abordagem
Aps o estudo do hardware (nomeadamente o processador e a sua arquitectura interna) presente no router La Fonera, um CPU Atheros AR531X (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. At ao presente momento, esta limitao ainda no foi ultrapassada, uma vez que preciso recompilar o cdigo do servidor Web de modo a ter o total suporte para aplicaes CGI. Apesar de ser possvel a actuao dos dispositivos na rede KNX/EIB com sucesso, atravs do terminal de comandos do router, espera-se que at discusso desta dissertao, o problema da passagem de parmetros s aplicaes CGI esteja resolvido.
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.
66
CAPTULO 6: CONCLUSO E PERSPECTIVAS DE DESENVOLVIMENTO
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 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, surgiu uma nova 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 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. Contudo, atravs do terminal de comandos e de uma ligao ao router por telnet, foi possvel actuar nos dispositivos do barramento EIB do painel de simulao. Pde-se concluir que a nova abordagem apresentou grandes benefcios quando comparada com a abordagem prevista inicialmente, sendo estes: a melhor eficincia energtica, uma vez que no necessrio um sistema embebido dedicado sempre ligado, e a inexistncia do custo da aquisio deste, uma vez que toda a aplicao executada no router como um servio extra.
CAPTULO 6: CONCLUSO E PERSPECTIVAS DE DESENVOLVIMENTO
67
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 Internet.
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
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 (podese utilizar o gestor de pacotes da distribuio, neste caso o Synaptic).
Nome
libdwarf xerces-c libelf libboost
Verso
20080208 2.8.0 0.8.9 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

KNX Fomacao

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

KNX Fomacao

Transféré par

Droits d'auteur :

Formats disponibles

Faculdade de Engenharia da Universidade do Porto

Interface homem-mquina para domtica baseado em tecnologias Web

Orientador: Prof. Dr. Mrio de Sousa

Joo Ferreira, 2008

Ao meu Av, Famlia e Amigos

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

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

3.3.1 Sistemas Operativos para sistemas embebidos ........................................................... 35

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

4.3.1 KNX @ HOME .......................................................................................................... 44

5.2.1 Primeira fase ............................................................................................................... 56

5.2.2 Segunda fase ............................................................................................................... 61 5.3 Testes e resultados ............................................................................................................ 61

5.3.1 Primeira fase ............................................................................................................... 61 5.3.2 Segunda fase ............................................................................................................... 61

Concluso e Perspectivas de Desenvolvimento

1.4 Estrutura do relatrio

Figura 2.1 Arquitectura centralizada

SENSOR CONTROLADOR SENSOR

Figura 2.2 Arquitectura descentralizada

Figura 2.3 Arquitectura distribuda

2.3.2 A eficincia energtica

2.4 Sistemas comerciais

Figura 2.4 Arquitectura do sistema VIVIMAT [37]

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

Figura 2.6 Consola tctil do sistema CARDIO [40]

3.1 O standard KNX/EIB

3.1.2 Principais caractersticas

3.1.3 Topologia da rede

Figura 3.1 Topologia de uma rede KNX/EIB

3.1.4 Meios de transmisso

3.1.4.1 Par entranado

3.1.4.2 Rede elctrica

3.1.5 Modos de configurao

3.1.6 Modo de endereamento de dispositivos

Figura 3.2 Topologia dos endereos fsicos

Figura 3.3 Nveis dos endereos de grupo

3.1.7 Comunicao entre dispositivos

Tabela 3.1 Tipos de dados EIS

3.2 Tecnologias Web

Figura 3.4 Interaco assncrona das aplicaes Ajax [16]

Figura 3.5 Interaco sncrona das aplicaes Web tradicionais [16]

Figura 3.6 Diagrama de sequncia CGI simples

Figura 3.7 Sequncia de um programa JAVA simples

3.3 Sistemas Embebidos

3.3.1 Sistemas Operativos para sistemas embebidos

3.3.1.1 Linux embebido

Figura 3.8 Picotux [26]

4.1 Primeira abordagem

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.1.1 Primeira alternativa

HTML Javascript AJAX

Figura 4.1 Arquitectura proposta na 1 alternativa da 1 abordagem

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.1.2 Segunda alternativa

HTML Javascript AJAX

Figura 4.2 Arquitectura proposta na 2 alternativa da 1 abordagem

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.1.3 Terceira alternativa

HTML Javascript AJAX Browser

CAPTULO 4: ARQUITECTURA FUNCIONAL

4.2 Segunda abordagem

KNX / EIB Device

KNX / EIB Device

Figura 4.4 Arquitectura proposta na 2 abordagem