ANLISE DE PROTOCOLOS DE AUTOMAO PREDIAL/RESIDENCIAL JAIR J. ARAUJO1, CARLOS E.

PEREIRA2 Instituto de Informtica, UFRGS / Centro Federal de Educao Tecnolgica de Pelotas1 Grupo de Controle, Automao e Robtica, Depto de Engenharia Eltrica, UFRGS2 Praa 20 de Setembro 455, 96015-360, Pelotas, RS, Brasil1 E-mails: jonko@inf.ufrgs.br/jonko@cefetrs.tche.br1, cpereira@eletro.ufrgs.br2
Abstract This work presents a state-of-the-art analysis of communication protocols for home and building automation. The strengths and weaknesses of the most used protocols are discussed and directions for research in this area are signaled. Keywords building automation, home automation, protocols. Resumo Este artigo apresenta um estudo avaliando as principais caractersticas de alguns protocolos de comunicao para uso em sistemas de Automao Predial/Residencial. So apresentados os principais conceitos dos protocolos X-10, Lonworks, EIB, BACnet, HomePnP, Jini, UPnP e OSGi, apontando-se alguns de seus pontos fortes e fracos e as perspectivas futuras da rea de Automao Predial/Residencial. Palavras-chave automao predial, automao residencial, protocolos

1 Introduo Os avanos tecnolgicos nas reas da microeletrnica e da Informtica permitem a realizao de sistemas computacionais fisicamente distribudos, capazes de serem monitorados, executados e atualizados remotamente, o que permite distribuir a tarefa de controle entre os prprios dispositivos (sensores, atuadores, equipamentos autnomos, etc.) e tem aumentado a eficincia e a confiabilidade nos modernos sistemas de automao. Em automao predial a tendncia inicial foi realizar automao com as mesmas tecnologias (equipamentos, barramentos, etc) que so utilizados na rea industrial. A observao, entretanto, de que estas aplicaes possuem caractersticas especficas tem levado ao desenvolvimento de tecnologias que visam encontrar as melhores solues para esta rea, o que tem se refletido no grande crescimento das reas de automao predial e residencial no Brasil e no mundo. Dentre as funcionalidades a serem realizadas pelos sistemas de automao predial (SAP) destacam-se o gerenciamento de energia (com o objetivo de monitorar e otimizar o consumo de energia) e do conforto trmico atravs do controle de condicionadores de ar (HVAC - Heating, Ventilation and Air Conditioning), com parmetros selecionados de acordo com a estao do ano, perodo do dia, ocupao, etc, o controle de iluminao (baseado nas atividades realizadas nos diferentes ambientes e levando-se em conta fontes de iluminao natural), o controle de acesso (a salas, elevadores, estacionamento, etc), o controle de segurana em caso de problemas eltricos ou mecnicos, fumaa, incndio e gua (o sistema deve ser capaz de acionar as equipes de emergncia, fechar automaticamente portas contra fogo e acionar iluminao de emergncia), entre outros.

Relativamente automao residencial (AR) devem ser considerados o estilo de vida e preferncias do proprietrio, por isso as solues tendem a ser muito pessoais e dirigidas. Caractersticas relevantes so a facilidade de instalao, de configurao e de manuteno da rede, uma vez que na maioria das vezes os usurios no esto capacitados a executar programaes complexas e no se pode esperar que cada residncia possua um tcnico treinado para operar o sistema. Outra peculiaridade refere-se a importncia do entretenimento, muito maior do que em prdios comerciais. Embora existam na literatura publicaes sobre protocolos para SAP elas geralmente so apresentadas em estudo de caso com foco na validao de alguma metodologia proposta. Este trabalho visa analisar algumas das solues tecnolgicas disponveis para implementao desses sistemas, com foco nos padres abertos, apontando suas principais caractersticas. Na prxima seo sero apresentados alguns protocolos, na seo 3 ser realizada uma avaliao qualitativa dos mesmos de acordo com o critrio especificado no incio da seo 2 e na ltima seo sero apontadas algumas tendncias para a rea. 2 Protocolos Alguns parmetros considerados importantes para diferenciar os protocolos entre si e que devem ser avaliados na escolha de uma determinada soluo so: o estado atual de padro; as caractersticas da rede; processo de configurao oferecido pelo protocolo; o modelo de objetos e o suporte oferecido para garantir a interoperabilidade.

A seguir, na descrio de cada protocolo, procurar-se- analisar os mesmos com nfase nestes parmetros. 2.1 X10 O sistema X-10 PLC (Power Line Carrier) [1] foi desenvolvido na dcada de 70 e transmite dados modulados sobre a rede eltrica existente sendo que uma informao binria transmitida sempre que o sinal senoidal de tenso eltrica passa pelo zero. O esquema de endereamento permite enderear 256 pontos diferentes, os quais podem ser ajustados atravs de um seletor nos dispositivos receptores . A transmisso em broadcast e todo o comando repetido duas vezes, assim um comando completo ocupa 47 ciclos em 60Hz o que corresponde a um tempo de aproximadamente 0,8s. A rede eltrica pode ocasionar alguns comportamentos errticos dos componentes, seja por problemas de rudo, falta de energia ou descargas eletromagnticas. 2.2 LONWorks O padro LonWorks [2] uma tecnologia proposta pela empresa Echelon em 1990 e abrange toda a infra-estrutura de hardware e software para a operao da rede local denominada LON (Local Operating Network). um sistema aberto e de controle distribudo, com o funcionamento baseado no protocolo de comunicao LonTalk (padro ANSI 709.1). Uma associao de usurios estabelece padres e certifica dispositivos de controle interoperveis. O controle distribudo nos dispositivos, sendo possvel construir rede com diferentes topologias e meios fsicos, com distncias mximas e nmero de nodos variveis de acordos com caractersticas do meio utilizado. O protocolo LonTalk implementa as sete camadas do modelo OSI tendo sido projetado para aplicaes que envolvem funes de sensoriamento, monitoramento, controle e identificao. um protocolo baseado em pacotes e com comunicao peer-to-peer que implementa o algoritmo CSMA p-persistente preditivo com um esquema de prioridades que garante o acesso preferencial ao meio para pacotes com prioridade alta. Um programa de aplicao consiste em um ou mais objetos LonWorks. Cada objeto baseado na definio de um perfil funcional, o qual define uma camada de interface, incluindo as variveis de rede, propriedades de configurao e os relacionamentos requeridos pelo dispositivo para executar as suas funes de controle. Um bloco funcional desempenha uma tarefa recebendo dados de entrada de configurao ou de operao, processando-os e gerando dados de operacionais de sada, podendo receber entradas da rede, do hardware anexado ao dispositivo ou de outros blocos funcionais e pode enviar os resultados

rede, para hardware anexado ao dispositivo ou para outros blocos funcionais. Existem perfis funcionais padronizados para as reas de HVAC, gerenciamento de energia, iluminao, acesso, intruso e monitorao, controle de motores, sensores, refrigerao, deteco de incndio, transporte de cargas, entre outros. A interoperabilidade de dispositivos de diferentes fabricantes na rede garantida por um conjunto padro de variveis de rede (Standard Network Variable Types SNVTs) estando atualmente padronizadas 166 variveis [3]. A localizao fsica de uma varivel de rede transparente para o programa de aplicao sendo as conexes lgicas estabelecidas durante processo de configurao. 2.3 EIB EIB (European Installation Bus) um sistema aberto, cuja padronizao abrange dispositivos, gerenciamento de rede, interfaces para criao de ferramentas e esquemas de certificao de produtos. A tecnologia administrada por uma associao chamada EIBA, a qual publica o padro do EIB, realiza certificaes e fornece a ferramenta de desenvolvimento denominada ETS (EIB Tool Software) que usada para configurar a instalao, realizar manuteno e fazer diagnsticos. Os dispositivos, que podem compor uma arquitetura distribuda ou centralizada, so divididos em linhas e reas a fim de reduzir o trfego na rede, podendo totalizar 61455 dispositivos [4]. Uma unidade de acesso ao barramento padronizada denominada BCU (Bus Coupling Unit), permite que dispositivos fornecidos por diferentes fabricantes, operem no barramento o qual pode utilizar diferentes meios tais como par tranado, fiao eltrica existente (powerline), rdio freqncia, etc. Um conjunto padro de objetos definido a partir dos quais as aplicaes so construdas. Para cada um desses objetos est definido um conjunto de propriedades, algumas obrigatrias e outras opcionais. Objetos padres tambm foram definidos para indicao tipos de dados das propriedades, IDs e tipos de objetos. Para permitir a interoperabilidade entre dispositivos de diferentes fabricantes, esto padronizados os valores e a interpretao de dados includos na comunicao entre objetos, os quais sero usados pelos objetos de comunicao. Estas funes padronizadas, so denominadas EIS (EIB Interworking Standards for Group-Communication-Objects) [5]. De uma maneira geral so definidas a descrio e a finalidade de cada funo, a faixa de valores admissveis e a definio da funo. 2.4 BACNet BACnet (Building Automation and Control Network) um protocolo aberto de comunicao de dados,

desenvolvido por iniciativa da ASHRAE (American Society of Heating, Refrigerating and AirConditioning Engineers) e adotado pela ANSI desde 1995, aps aproximadamente nove anos de estudos para definio do padro. O protocolo implementa algumas camadas do modelo OSI, sendo que para as camadas fsicas e de enlace foram adotados alguns padres de LAN j estabelecidos no mercado, o que permite bastante flexibilidade na escolha do meio mais adequado, conforme a melhor relao custo x benefcio. O modelo definido para o BACnet est fundamentado em trs aspectos [6]: objetos para representar o sistema de informao e a base de dados com propriedades padronizadas, servios que permitem a um objeto acessar informaes de outro objeto e regras de interoperabilidade que fornecem mecanismos para que sistemas com componentes de diferentes fornecedores operem corretamente em conjunto. Foram definidos e padronizados dezoito tipos de objetos e 123 propriedades definidas conforme o objeto que ser implementado e o tipo de dispositivo no qual o objeto reside. Um servio meio pelo qual um dispositivo adquire informaes de um outro, comanda-o para realizar alguma tarefa ou anuncia para um ou mais dispositivos que algum evento ocorreu. O programa de aplicao responsvel pelo recebimento e pelo processamento das requisies de servio. Foram definidos 32 servios classificados nas categorias alarm and event, file access, object access, remote device management e virtual terminal services. Para garantir interoperabilidade a idia dividir o problema da interoperabilidade em conjuntos comuns de funes e definir requisies para cada um desses conjuntos. Foram definidas cinco reas de interoperabilidade para classificar os BIBBs (BACnet Interoperability Building Blocks) e em cada uma h uma srie de servios que sero executados [7]. Um servidor deve ser capaz de receber uma requisio de servio, executar e retornar o resultado ao cliente, o qual deve ser capaz de iniciar uma requisio de servio e processar a resposta quando ela chega. 2.5 HomePnP HomePnP [8] busca estabelecer um padro dentro do nvel de aplicao, definindo o contedo das mensagens de controle que so trocadas entre dispositivos e controladores, descrevendo como diferentes produtos podem cooperar entre si. Ele baseado na CAL (Common Application Language) [9] e no nvel de aplicao do protocolo CEBus (Consumer Electronics Bus) sendo um padro EIA desde 1995. O protocolo HomePnP padroniza a estrutura das mensagens e os cdigos de controle usados nas mensagens. Alguns conceitos chaves do modelo de objetos do protocolo so: uma linguagem de aplicao comum independente do protocolo de transporte, os contexto e dispositivos e os objetos ouvintes, status e

de requisio. Tambm est especificado um processo de configurao automtico. Objeto o termo CAL usado para definir uma funo de controle simples dentro de um contexto, sendo implementado por um conjunto de variveis, chamando variveis de instncia (IVs). A especificao define um conjunto de 22 objetos, a partir dos quais os dispositivos e subsistemas so construdos. Um contexto um grupo de objetos representando uma funo comum de um dispositivo sendo que vrios contextos podem representar um dispositivo que um mecanismo que expem e controla variveis de estado atravs da rede usando o protocolo CAL. Ele um continer para um conjunto de contextos CAL que coletivamente recebe mensagens endereadas para o mesmo endereo da camada de transporte. Um dispositivo pode ser implementado em hardware ou em software em um PC. Esto especificados os seguintes grupos de contextos: General, Audio/Vdeo, Lighting, Communication, HVAC, Security, Utility/Energy Management, Convenience, Computer/Home Office e Appliance. Cada grupo contm um certo nmero de contextos chamado Classes de Contexto. No grupo Lighting h seis classes (Light Sensor, Light, Light Scene, Light Sensor Status, Lighting Scene Request e Lighting Scene Status), no grupo Environmental h oito e assim por diante. Cada classe de contexto composta pelos objetos de acordo com suas caractersticas. A classe Light por exemplo composta pelos objetos Light Level Control, Light Level Setting, Feature Select entre outros. Tambm esto especificados um conjunto de mtodos que podem executar em vrios objetos. 2.6 Jini Jini [10] uma tecnologia desenvolvida pela Sun Microsystems, lanada em 1999, que proporciona um mecanismo para que diversos dispositivos conectados em rede possam colaborar para e execuo de tarefas e compartilhar recursos sem a necessidade de que o usurio final tenha que configurar a rede. A arquitetura Jini totalmente distribuda e todos os dispositivos podem oferecer servios e comunicarem-se entre si. Ela pode ser utilizada em estaes de trabalho, PCs, pequenos dispositivos (PDAs, filmadoras, reprodutores mp3) ou em eletrodomsticos que estejam conectados em uma rede. Tambm possvel a conexo de dispositivos que no rodem a mquina virtual Java atravs do uso da arquitetura surrogate [11]. Um sistema Jini consiste basicamente de trs partes: um conjunto de componentes que fornece a infraestrutura para compartilhamento de servios em um sistema distribudo; um modelo de programao que suporta o desenvolvimento de servios distribudos confiveis;

servios que podem fazer parte de um sistema Jini compartilhado e que oferecem funcionalidades a outros membros do sistema. Os servios podem ser adicionados ou retirados de um sistema em qualquer momento, de acordo com a necessidade, a demanda ou as mudanas de configurao dos usurios do sistema. Do ponto de vista do servio cliente, no h distino entre servios que so implementados por objetos em diferentes mquinas, os que esto no espao de endereamento local e os que so implementados em hardware: um repositrio de servios mapeia interfaces que indicam a funcionalidade fornecida por um servio, para um conjunto de objetos que implementam este servio. Os objetos podem ser descarregados e executados em qualquer dispositivo que suporte JVM, sendo compostos, basicamente, por uma interface Java. As interfaces definem as operaes que podem requisitadas de um servio. Como muitos dispositivos no so capazes de procurar e registrar servios, de descarregar e executar classes escritas em Java e de exportar classes para disponibilizar servios a outros objetos da rede por falta de capacidade de processamento ou memria ou por no rodarem JVM, eles no podem participar diretamente da rede. A arquitetura Jini surrogate indicada para esse caso, definindo mecanismos para que esses componentes possam participar da rede Jini. Basicamente ela define um conjunto de mecanismos para que um proxy, o qual executa em uma mquina com capaz de participar da rede Jini, represente um dispositivo e executa aes a favor dele. Este proxy pode ser descarregado do prprio dispositivo ou de outro lugar especificado. A ativao e desativao do surrogate controlado por um conjunto de APIs denominado surrogates APIs. 2.7 UPnP Universal Plug&Play (UPnP) [12], semelhante ao Jini, uma arquitetura de software aberta e distribuda que permite as aplicaes dos dispositivos conectados em rede trocarem informaes e dados sem necessidade de configurar a rede, os dispositivos e o sistema operacional. Sua arquitetura est baseada em protocolos padres tais como TCP, UDP, IP entre outros e foi projetado para ser independente de fabricante, sistema operacional, linguagem de programao de cada dispositivo e do meio fsico para implementar a rede. A descrio dos servios e dispositivo mantida pelo UPnP Forum, e seu desenvolvimento est direcionado s redes domsticas, s redes de pequeno porte em pequenos negcios e pequenos prdios comerciais. Os elementos bsicos do UPnP so os dispositivos, os servios, e os controladores, cujas informaes so estruturadas utilizando XML (Extensible Markup Language). Um dispositivo um continer de servios e de dispositivos aninhados. Diferentes categorias de dis-

positivos podem ser associadas com diferentes servios e dispositivos embutidos. Como um dispositivo pode conter outros dispositivos, dispositivos lgicos e servios, o seu conjunto de servios e as suas propriedades devem ser padronizados para garantir interoperabilidade entre os diferentes fornecedores. Um controlador um componente lgico capaz de descobrir e controlar outros dispositivos. Aps a descoberta ele deve ser capaz de recuperar a descrio do dispositivo e obter a lista de servios, recuperar a descrio de um determinado servio, invocar aes para o controlador do servio e assinar o servidor de evento. Aps o dispositivo obter um endereo IP vlido, utilizando DHCP, ele pode, usando o protocolo SSDP, publicar os seus servios ou procurar por dispositivos de interesse na rede obtendo a descrio detalhada de cada servio. A descrio de um servio define as aes e seus argumentos, as variveis de estado com seus tipos, faixa de valores e eventos caractersticos. O controle de um servio realizado usando o protocolo SOAP Os servios publicam atualizaes quando suas variveis so modificadas e um controlador pode se inscrever para receber estas informaes. Estas atualizaes so enviadas atravs de mensagens de eventos, que so formatadas usando o protocolo GENA. Alm disso, se um dispositivo pode conter uma URL para apresentao a qual pode ser carregada em um browser e permitir ao usurio o controle e/ou a visualizao do estado do dispositivo. A UPnP Device Architecture [13] define o modelo genrico para criao de dispositivos e para descrio de servios para qualquer dispositivo e tipo de servio. Grupos de trabalho organizados em comits trabalham para padronizar os diferentes dispositivos e servios, criando os modelos adequados para represent-los e os submetendo para padronizao. Existem comits formados para as reas de A/V, eletrodomstico, Automao Residencial e Segurana, Imagem e Gateways Internet, entretanto at o momento existem muito poucos dispositivos padronizados. 2.8 OSGI OSGi (Open Services Gateway Initiative) [14] uma associao fundada em 1999 com a misso de criar especificaes abertas para a entrega de mltiplos servios sobre redes geograficamente distribudas (WANs) para redes locais e dispositivos. O componente principal do esforo de especificao OSGi est concentrado em services gateway, que so servidores para conectar a rede externa com clientes internos, atuando como uma plataforma para instalao e execuo de software que trabalha em cooperao com dispositivos de uma rede domstica, tais como sensores, interruptores, de DVDs, aparelhos de som, etc. Este software permite que provedores de servios externos interajam com os dispositivos dessa rede, provendo para seus proprietrios ser-

vios tais como filme e msica sob demanda, controle e monitoramento do sistema de segurana, gerenciamento dinmico de energia, etc. A especificao OSGi padroniza APIs para um ambiente de execuo de uma plataforma gateway. As APIs endeream servios, gerenciam ciclo de vida, controlam a dependncia entre os servios, gerenciam dados, controlam acessos a dispositivos e a recursos e garantem segurana. Um framework forma o ncleo da especificao desta plataforma e fornece um ambiente de execuo para servios descarregados eletronicamente, os quais so denominados pacotes. Qualquer dispositivo padro OSGi pode descarregar, instalar e remover estes pacotes, sob o controle do framework, que gerencia a instalao e a atualizao desses pacotes bem como a dependncia entre os pacotes e os servios, alm de fornecer mecanismos de gerenciamento de eventos para que os pacotes possam receber eventos de objetos de servios que tenham sido registrados, modificados ou desinstalados. 3 Comparao entre os protocolos A tabela 1 apresenta uma comparao entre alguns dos protocolos analisados em relao limitao de endereamento da rede, a meios fsicos disponveis e ao comportamento quanto expanso, destacando a necessidade ou no de configurao dos dispositivos e da utilizao de ferramentas especficas para isto, caracterstica importante quando se trata de aplicao em sistemas residenciais. Uma das primeiras limitaes que se observa nos protocolos pesquisados o suporte a fluxo contnuo de dados entre dispositivos, caractersticos de aplicaes de udio e vdeo: LonWorks EIB e BACnet so desenvolvidos para dispositivos de controle e no suportam a distribuio de udio ou vdeo analgico ou dados digitais, alm disso os meio padronizados no suportam taxas de transmisso tpicas destas aplicaes. HomePnP, embora especifique classes de contexto para udio/Vdeo, at o momento ainda no
n . max. de dispositivos 256 32385 Rede eltrica
0

especificou os padres e os microprocessadores disponveis no mercado no oferecem este suporte. Por se tratar de produtos relativamente baratos e de fcil aplicao, o protocolo X-10 pode ser utilizado em diversas aplicaes, tais como acionamento remoto de lmpadas, eletrodomsticos e portas. Como sua confiabilidade limitada, seu uso no recomendado em aplicaes crticas, ligadas segurana domstica, sendo uma boa alternativa nos casos de residncias j construdas, onde se deseje evitar transtornos com reformas, uma vez que o meio fsico padro a rede eltrica existente. A arquitetura Jini apresenta-se como uma soluo promissora por ser independente de plataforma, o que permite que os dispositivos no estejam limitados a uma marca especfica de software, processador, driver ou protocolo de rede. Algumas crticas so realizadas ao fato de apenas a Sun e algumas poucas empresas autorizadas por ela, poderem desenvolver a Mquina Virtual Java. Outra crtica que Jini uma arquitetura pesada em funo dos recursos de memria que exige e que prejudica a sua utilizao em dispositivos de baixo custo (algo que o conceito de surrogates tenta minimizar). Alm disso, a comunicao necessria ao gerenciamento de uma rede Jini, ao mesmo tempo em que aumenta a flexibilidade, tende a sobrecarregar a rede, degradando o desempenho. A Microsoft est investindo fortemente no protocolo UPnP, que um concorrente direto do Jini. Embora a especificao utilize protocolos j de utilizao consagrados principalmente pela Internet e independentes de sistema operacional, apenas a Microsoft fornece suporte a esta tecnologia atualmente e existem muito poucos dispositivos disponveis. A plataforma OSGI concebida para permitir a conexo de dispositivos de diferentes padres num gateway, garantindo o fornecimento de servios para esses dispositivos. O foco do desenvolvimento, entretanto, para conexo de sistemas externos com sistemas internos, buscando criar uma infraestrutura de suporte a provedores de servios para aplicaes de monitorao, udio e vdeo sob demanda, entre outros.

Tabela 1 Comparao entre protocolos considerando caractersticas de rede e de configurao Protocolo X10 LonWorks Meio Fsico Configurao/expanso Instalar o dispositivo e ajustar endereo diretamente no mesmo

Par tranado, cabo coaxial, RF, Power Instalar o dispositivo e configurar utilizando Link, infravermelho, fibra tica, rede ferramenta de configurao eltrica. Par tranado, rdio freqncia, ISO/IEC Instalar o dispositivo e configurar utilizando 61455 EIB 802-2, rede eltrica ferramenta de configurao Ethernet, ARCNET, point-to-point, Sem limitaes* LonTalk, TCP/IP (UDP), master- (sem informao) BACNet slave/token-passing, Sem limitao* EIA-600, IEEE 1394, TCP/IP,EIB, etc. Plug and Play HomePnP Sem limitao* Redes TCP/IP Plug and Play Jini Sem limitao* Redes TCP/IP Plug and Play UPnP * Quanto ao endereamento (no considera problemas na rede tais como congestionamento, jitter, etc.)

O uso de conceitos de orientao a objetos nos protocolos mais recentes, bem como a padronizao de classes de dispositivos mostra a preocupao de fornecer mecanismos que favoream a interoperabilidade entre dispositivos fornecidos por diferentes fabricantes. Dentro de cada padro este objetivo tem sido conseguido atravs da certificao de produtos pelas associaes que administram cada protocolo, porm a interoperabilidade entre produtos de diferentes tecnologias ainda no foi atingida. Quanto disponibilidade e custos pode-se apenas fazer apenas uma avaliao subjetiva. Pode-se dizer que existe boa disponibilidade para os padres X10 quando se trata de dispositivos para automao residencial a um custo relativamente baixo, existe boa disponibilidade de dispositivos LonWorks e EIB para automao residencial e comercial com custos relativamente moderado e moderado a alto, respectivamente, existe disponibilidade de equipamentos BACnet para a rea de automao comercial com custo alto e existe muito pouca disponibilidade de equipamentos para os demais protocolos. Finalmente, o que se observa que no existe claramente um protocolo superior aos outros: os protocolos mais recentes tentam preencher as lacunas deixadas por limitaes dos protocolos mais antigos, visando atingir uma faixa de mercado que eles no atendem bem. 4 Concluses e trabalhos futuros Conforme apresentado neste artigo, apesar de existirem vrias opes de protocolos, nenhuma delas ainda satisfaz completamente os requisitos de desempenho, custo e facilidade de instalao, configurao e ampliao. Percebe-se aqui uma clara oportunidade para desenvolvimento de solues que preencham a lacuna existente. As solues atuais tm comum a proposta de distribuir a tarefa de controle entre os dispositivos e conect-los atravs de uma arquitetura de rede adequada, permitindo a troca de informaes diretamente entre eles, para a execuo das tarefas programadas, sem a necessidade de unidades de controle centralizadas, o que vem aumentando a eficincia e a confiabilidade dos sistemas instalados. Em contrapartida h um aumento da complexidade de projeto e de gerenciamento desses sistemas: os desafios da comunicao e da integrao, ponto chave para interoperabilidade entre os dispositivos e subsistemas, ainda permanecem sem soluo. Nesse contexto est sendo desenvolvida no PPGC/UFRGS uma ferramenta para suporte ao projeto de aplicaes na rea de automao predial/residencial para permitir modelar um sistema de automao residencial/predial de forma independente da tecnologia que ele ir utilizar, possibilitando o mapeamento posterior para a mais adequada ou disponvel.

Referncias Bibliograficas [1]X10 Powerline Carrier (PLC) Technology. Disponvel em: <http://www.x10.com/ support/technology1.htm>. [2]ECHELON CORPORATION. Introduction to the LONWORKS System: version 1.0. 1999. Disponvel em: < http://www.echelon.com/ support/documentation >. [3]ECHELON CORPORATION. LONMARK SNVT Master List: verso 11. 2002. 143p. Disponvel em: < http://www.echelon.com/ support/documentation >. [4]EIBA. Introduction to the System. European Installation Bus Association. 1999. 36p Disponvel em: <http://www.georgluber.onlinehome.de/data/introduc.pdf>. [5] EIBA. Interworking. European Installation Bus Association. 1999. 42p Disponvel em: <http://www.eiba.ru/dnld.htm>. [6]SWAN, Bill. The Language of BACnetObjects, Properties and Services. Alerton Technologies, Inc.13p. Disponvel em: <http://www.gopolar.com/BACnet/articles.html> [7]BUSHBY, Steven T. NEWMAN, H. Michael. APPLEBAUM, Martin A. GSA Guide to Specifying Interoperable Building Automation and Control Systems Using ANSI/ASHRAE Standard 135-1995. 1999. NIST. 80p. Disponvel em: <fire.nist.gov/ bfrlpubs/build99/PDF/b99051.pdf>. [8]CIC. HomePnPTM Specification: version 1.0. CEBus Industry Council. 1998. 369p. Disponvel em: <http://www.cebus.org/Files/ hpnp10.zip>. [9]CIC. Common Application Language (CAL) Specification. CEBus Industry Council. 1996. 80p. Disponvel em: <http://www.cebus.org/ Files/eia600.zip>. [10]SUN Microsystems. JiniTM Architecture Specification. Palo Alto, 2001. 26p.Disponvel em: <http://wwws.sun.com/software/jini/specs/ jini1_2.pdf>. [11]SUN Microsystems. JiniTM Technology Surrogate Architecture Specification. Palo Alto, 2003. 34p. Disponvel em: <http://www.jini.org/standards/sa.pdf>. [12]MICROSOFT. Understanding Universal Plug and Play: White Paper. Microsoft Corporation 2000, Redmond. 45p. Disponvel em: <http://www.upnp.org/resources/ documents.asp>. [13]MICROSOFT. Universal Plug and Play Device Architecture: verso 1.0. 2000, Redmond. Disponvel em: <http://www.upnp. org/resources/documents.asp>. [14]OSGi. OSGi Service Platform. Release 2. Open Services Gateway Initiative. 2001. 288p. Disponvel em: <http://www.osgi.org/ resources/spec_download.asp>