UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA PROGRAMA DE PS-GRADUAO EM COMPUTAO

JAIR JONKO ARAUJO

Framework Orientado a Objetos para o Desenvolvimento de Aplicaes de Automao Predial e Residencial

Dissertao submetida avaliao, como requisito parcial para a obteno do grau de Mestre em Cincia da Computao

Prof. Dr. Carlos Eduardo Pereira Orientador

Porto Alegre, abril de 2005.

CIP CATALOGAO NA PUBLICAO Araujo, Jair Jonko Framework Orientado a Objetos para o Desenvolvimento de Aplicaes de Automao Predial e Residencial / Jair Jonko Araujo. Porto Alegre: PPGC da UFRGS, 2005. 115f.:il. Dissertao (mestrado) Universidade Federal do Rio Grande do Sul, Programa de Ps-Graduao em Computao, Porto Alegre, RS-BR, 2005. Orientador: Carlos Eduardo Pereira. 1. Automao predial. 2. Automao residencial. 3. Orientao a Objetos. 4. Framework.. I. Pereira, Carlos Eduardo. II. Ttulo.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. Jos Carlos Ferraz Hennemann Vice-Reitor: Prof. Pedro Cezar Dutra Fonseca Pr-Reitora de Ps-Graduao: Profa. Valquria Linck Bassani Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux Coordenador do PPGC: Prof.. Flavio Rech Wagner Bibliotecria-Chefe do Instituto de Informtica: Beatriz Haro

 minha esposa Valdriane e minha filha Aline pela aceitao das minhas ausncias e por darem um sentido especial a cada etapa de minha vida.

AGRADECIMENTOS
Em cada etapa de nossa vida somos auxiliados por muitas mos visveis e invisveis a quem temos muito a agradecer quando conseguimos conclu-la. Ao nomear algumas pessoas que contriburam conosco para materializar algo importante, corremos o risco de sermos injustos. Entretanto algumas foram fundamentais nesse caminho que merecem o destaque de um agradecimento especial. Agradeo: em primeiro lugar minha esposa Valdriane pela compreenso das minhas ausncias e pelo estimulo durante a realizao deste trabalho e minha filha Aline, hoje com quatro anos, que foi o grande farol que me iluminou em cada dificuldade me estimulando a super-las; ao professor Carlos Eduardo, meu orientador, no s pela oportunidade de trabalho, pela orientao firme e tranqila, pelas incontveis discusses e revises ao longo deste trabalho, mas tambm pelo exemplo de dedicao e tica com o trabalho de pesquisa, na certeza de que este um dos caminhos importante e possvel para gerar desenvolvimento ao pas; ao colega Leandro Buss Becker, companheiro de longa data e com quem tive oportunidade de dividir, alm da sala de estudos no DELET/UFRGS, as minhas infindveis dvidas e questionamentos. Agradeo tambm sua contribuio na reviso das verses iniciais do texto da dissertao; ao Instituto de Informtica e ao Departamento de Engenharia Eltrica da UFRGS, personificados pelos seus professores e funcionrios, pela lio de como pesquisar e promover cincia com dedicao e tica. E finalmente, deixo um agradecimento a tantos, no citados nominalmente, mas sem cuja colaborao este trabalho no teria sido realizado, especialmente a meus colegas de trabalho no CEFET-Pelotas que criaram meios para que sempre houvesse tempo para realizar as atividades relacionadas com este trabalho.

SUMRIO
LISTA DE ABREVIATURAS OU SIGLAS ...................................................................7 LISTA DE FIGURAS........................................................................................................9 LISTA DE TABELAS.....................................................................................................11 RESUMO..........................................................................................................................12 ABSTRACT .....................................................................................................................13 1 INTRODUO ............................................................................................................14 1.1 Contextualizao do Trabalho .................................................................................14 1.2 Objetivos do Trabalho ..............................................................................................17 1.3 Organizao do Texto ...............................................................................................18 2 ANLISE DO ESTADO DA ARTE EM AUTOMAO PREDIAL ....................19 2.1 Arquiteturas em Sistemas de Automao Predial. .................................................19 2.2 Protocolos de Comunicao......................................................................................20 2.2.1 X10 ...........................................................................................................................21 2.2.2 LONWorks ...............................................................................................................21 2.2.3 EIB............................................................................................................................23 2.2.4 BACNet ....................................................................................................................24 2.2.5 HomePnP ..................................................................................................................25 2.2.6 UPnP.........................................................................................................................26 2.2.7 KNX .........................................................................................................................27 2.2.8 Comparao entre os Protocolos ..............................................................................29 2.3 Frameworks ...............................................................................................................31 2.3.1 OSGI.........................................................................................................................31 2.3.2 Niagara Framework e Baja .......................................................................................32 2.3.3 O Projeto EMBASSI ................................................................................................34 2.3.4 Consideraes Finais sobre Frameworks .................................................................36 2.4 Metodologias de Projeto Baseada em Vises ..........................................................36 2.4.1 O Conceito de Viso.................................................................................................36 2.4.2 O modelo de Referncia para Processamento Distribudo Aberto ...........................37 2.4.3 Alguns Trabalhos que Utilizam o Conceito de Vises e o RM-ODP ......................39 3 PROPOSTA DE FRAMEWORK .................................................................................40 3.1 Introduo ..................................................................................................................40 3.2 Construo do Framework ........................................................................................41

3.2.1 Definio das Funcionalidades.................................................................................41 3.2.2 Definio do Meta-modelo.......................................................................................45 3.2.3 Definio dos Dispositivos Lgicos e de suas Interaes ........................................50 3.2.4 Mapeamento Tecnolgico ........................................................................................52 3.3 Consideraes Finais .................................................................................................54 4 CICLO DE DESENVOLVIMENTO USANDO O FRAMEWORK .........................57 4.1 A Metodologia de Projeto Definida no Framework ................................................57 4.2 Roteiro de Projeto Utilizando o Framework ...........................................................58 4.3 Exemplos de Modelagem Utilizando o Framework ................................................62 5 VALIDAO DO MODELO .....................................................................................65 5.1 Sistema de Automao Predial/Residencial da Empresa Homesystems ..............65 5.1.1 Dispositivos Disponveis ..........................................................................................67 5.1.2 Outros Conceitos Usados pela Arquitetura ..............................................................67 5.1.3 Mapeamento do Framework.....................................................................................69 5.2 Exemplos de Mapeamento dos Dispositivos Lgicos..............................................73 5.3 Estudo de Caso: Automao de Escritrio..............................................................74 5.4 Mapeamentos Diferentes para o Subsistema de HVAC.........................................87 5.5 Consideraes Finais .................................................................................................89 6 CONCLUSES E TRABALHOS FUTUROS...........................................................90 REFERNCIAS ..............................................................................................................92 ANEXO A DETALHAMENTO DO MODELO...........................................................96 A.1 - Diagramas UML .....................................................................................................96 A.2 - Descrio de Atributos e Mtodos ......................................................................102 ANEXO B ARQUITETURA HOMESYSTEMS........................................................105 B.1 - Descrio dos Mdulos.........................................................................................105 B.2 - Mapeamento do Modelo para a Arquitetura Homesystems.............................108 ANEXO C ESTUDO DE CASO...................................................................................112 C.1 - Definio das Funcionalidades Conforme Subsistema .....................................112 C.2 - Definio dos Dispositivos Lgicos .....................................................................113 C.3 - Definio dos Cenrios.........................................................................................114

LISTA DE ABREVIATURAS OU SIGLAS

ANSI API ASHRAE AV BACnet BCU BIBBs CAL CD CEBus CIC CORBA CSMA DCOM DHCP DSL DVD EEPROM EIA EIB EIBA EIS EHS ETS FMS GENA HomePnP HTTP HVAC IEC IEEE American National Standards Institute; Application Programming Interface; American Society of Heating, Refrigerating and Air-Conditioning Engineers; udio e Vdeo; Building Automation and Control Network; Bus Coupling Unit; BACnet Interoperability Building Blocks; Common Application Language; Compact Disk; Consumer Electronics Bus; CEBus Industry Council; Common Object Request Broker Architecture; Carrier Sense Multiple Access; Distributed Component Object Model; Dynamic Host Configuration Protocol; Digital Subscriber Line; Digital Video Disk; Electrically Erasable Programmable Read-Only Memory; Electronic Industries Association; European Installation Bus; European Installation Bus Association; EIB Interworking Standards for Group-Communication-Objects; European Home Systems; EIB Tool Software; Facility Management Systems; General Event Notification ArchitectureI; Home Plug & Play; Hypertext Transfer Protocol; Heating, Ventilation and Air Conditioning; International Electrotechnical Commission; Institute of Electrical and Electronics Engineers;

IP ISO ITU LAN LON OMG OPC OSGi OSI PC PEI PLC RAM RM-ODP ROM RTOS SAP SCPTs SNVTs SOAP SSDP TCP UCPTs UDP UML UNVTS UPnP URL VCR XML XSL

Internet Protocol; International Standard Organization; International Telecomunication Union; Local Area Network; Local Operating Network; Object Managment Group; OLC (Object Linking and Embedding) for Process Control; Open Services Gateway Initiative; Open System Interconnection; Personal Computer; Physical External Interface; Power Line Carrier; Random Access Memory; Reference Modelo-Open Distributed Process; Read-Only Memory; Real-Time Operating System; Sistema de Automao Predial; Standard Configuration Property Types; Standard Network Variable Types; Simple Object Access Protocol; Simple Service Discovery Protocol; Transmission Control Protocol; User-defined Configuration Property Types; User Datagram Protocol; Unified Modeling Language; User-Defined Network Variable Types; Universal Plug & Play; Uniform Resource Locator; Video Cassette Recorder; Extensible Markup Language; eXtensible Stylesheet Language;

LISTA DE FIGURAS
Figura 1.1: Diagrama conceitual bsico de um sistema de controle .............................. 15 Figura 1.2 : Viso parcial de funes de um sistema de automao predial .................. 16 Figura 2.1 : Esquema de transmisso de mensagem no protocolo X10 ......................... 21 Figura 2.2 : Perfil funcional de um sensor e de um controlador de luminosidade ......... 22 Figura 2.3 : Arquitetura do padro KNX (KNX, 2003). ................................................ 28 Figura 2.4 : Estrutura do modelo de objetos(KNX, 2003). ............................................ 28 Figura 2.5 : Localizao de um service gateway (OSGi, 2001). .................................... 31 Figura 2.6 : Arquitetura Niagara (TRIDIUM, 2002-a)................................................... 33 Figura 2.7 : Arquitetura EMBASSI (EMBASSI, 2004)................................................. 35 Figura 3.1 : Etapas de projeto......................................................................................... 41 Figura 3.2 : Estruturao funcional de um subsistema................................................... 42 Figura 3.3 : Definio dos Subsistemas.......................................................................... 43 Figura 3.4 : Funcionalidades do subsistema de HVAC.................................................. 44 Figura 3.5 : Representao utilizando Dispositivos Lgicos ......................................... 46 Figura 3.6 : Viso inicial do modelo .............................................................................. 46 Figura 3.7 : Especializao da classe SimpleDevice....................................................... 47 Figura 3.8 : Modelagem dos Cenrios............................................................................ 49 Figura 3.9 : Exemplos de utilizao da sintaxe .............................................................. 49 Figura 3.10 : Dispositivos lgicos do subsistema HVAC .............................................. 50 Figura 3.11 : Especializao da classe Channel. ............................................................ 52 Figura 3.12 : Fluxo de informao no subsistema HVAC. ............................................ 52 Figura 3.13 : Mapeamento Tecnolgico......................................................................... 53 Figura 3.14 : Representao do framework .................................................................... 54 Figura 3.15 : Usando XSL para converso de formatos................................................. 54 Figura 3.16 : Viso Geral do Projeto.............................................................................. 55 Figura 4.1 : Definio das funcionalidades .................................................................... 57 Figura 4.2 : Projeto lgico seleo das funcionalidades do modelo............................ 58 Figura 4.3 : Projeto Lgico Seleo dos dispositivos lgico....................................... 58 Figura 4.4 : Mapeamento Tecnolgico........................................................................... 59 Figura 4.5 : Construo das prioridades baseadas na ocorrncia dos eventos ............... 62 Figura 4.6 : Sensor conectado diretamente ao atuador................................................... 62 Figura 4.7 : Modelagem de um interruptor comandando uma lmpada......................... 63 Figura 4.8 : Representao de um processo de controle em malha fechada .................. 63 Figura 4.9 : Modelagem de um controle de temperatura................................................ 63 Figura 4.10 : Representao de sistema que permite diferentes cenrios. ..................... 64 Figura 4.11 : Modelagem de um controle de temperatura com diferentes cenrios....... 64 Figura 4.12- Modelagem de um controle de luminosidade com diferentes cenrios. .... 64 Figura 5.1 : Arquitetura fsica......................................................................................... 66 Figura 5.2 : Ferramenta de Configurao....................................................................... 66

Figura 5.3 : Mapeamento dos Atributos da Classe PhysicalDevice ............................... 70 Figura 5.4 : Mapeamento dos Atributos dos Dispositivos Lgicos................................ 71 Figura 5.5 : Mapeamento dos Cenrios .......................................................................... 72 Figura 5.6 : Implementao de um sensor conectado diretamente no atuador............... 73 Figura 5.7 : Implementao do controle de variveis contnuas .................................... 74 Figura 5.8 : Implementao de diferentes cenrios ........................................................ 74 Figura 5.9 : Planta baixa de escritrio ............................................................................ 75 Figura 5.10 : Funcionalidades especificadas .................................................................. 76 Figura 5.11 : Detalhamento das funcionalidades............................................................ 78 Figura 5.12 : Modelagem lgica..................................................................................... 81 Figura 5.13 : Variveis ................................................................................................... 84 Figura 5.14 : Dispositivos mapeados.............................................................................. 85 Figura 5.15 : Vista parcial dos eventos programados..................................................... 86 Figura 5.16 : Mapeamento dos Cenrios ........................................................................ 87 Figura 5.17 : Implementao do subsistema HVAC usando apenas dispositivos disponveis pela arquitetura Homesystems. ........................................................... 88 Figura 5.18 : Implementao do subsistema HVAC usando AC Carrier....................... 89

LISTA DE TABELAS
Tabela 2.1 : Objetos EIB Padronizados.......................................................................... 23 Tabela 2.2 : Objetos BACnet padronizados ................................................................... 24 Tabela 2.3 : Classificao de dispositivos por diferentes padres ................................. 30 Tabela 2.4 : Objetos comuns entre alguns protocolos .................................................... 30 Tabela 3.1 - Equivalncia dos objetos propostos no modelo ......................................... 56 Tabela 5.1 : Detalhamento dos comportamentos............................................................ 76 Tabela 5.2 : Definio dos Dispositivos Lgicos ........................................................... 80 Tabela 5.3 : Implementao dos dispositivos lgicos .................................................... 83

RESUMO
O crescente aumento pela exigncia de funcionalidades na implementao dos atuais sistemas de automao predial, vem provocando um aumento da complexidade de projeto e de gerenciamento desses sistemas. O grande desafio que se apresenta atualmente como, a partir de dispositivos isolados e subsistemas, conseguir sistemas totalmente integrados, os quais permitam economia no investimento inicial, na operao e na manuteno dos sistemas de automao, garantindo um aumento no desempenho geral da edificao Acredita-se que uma etapa importante para avaliar a real necessidade da integrao seja projetar o sistema de automao sem foco em uma tecnologia especfica, o que no ocorre atualmente, uma vez que, pela carncia de ferramentas de apoio ao projeto, as etapas de especificao e projeto geralmente j esto focadas em uma tecnologia disponvel para implementao. Este trabalho busca preencher a lacuna deixada pela carncia dessas ferramentas, tendo por finalidade a especificao de um framework orientado a objetos para o desenvolvimento de aplicaes de automao predial e residencial que permita modelar estes sistemas de forma independente da tecnologia que ele ir utilizar, possibilitando o mapeamento posterior para a mais adequada ou disponvel. Serviram como base para o framework proposto a anlise de vrios padres abertos disponveis para implementao de sistemas de automao predial e a especificao ISO/IEC10746, o modelo de referncia para processamento distribudo aberto, usado como suporte a metodologia de projeto proposta. O trabalho tambm discute o mapeamento dos conceitos definidos para uma arquitetura alvo, apresentado um estudo de caso para validao da metodologia proposta.

Palavras-chave: automao predial, automao residencial, orientao a objetos, framework.

Object-Oriented Framework for The Design of Home and Building Automation Applications.

ABSTRACT
The increasing demand on the funcionalities in the implantation of the new automating building systems has caused an increase in the complexity of the project as well as in the management of these systems. The greatest challenge nowadays is how to obtain systems entirely integrated from isolated devices and subsystems, which allow savings in the initial investments as well as in the operations and maintenance of the automation systems in order to guarantee an increase in the general performance of the building. It is believed that an important stage to assess the actual need of this integration is to project an automating system without a specific technological focus, which does not occur nowadays. Due to the lack of supporting tools for the project, the stages of specification and project are generally focused on the available technology for implementation. This work aims to fill in this gap by specifying an object-oriented framework for the development of applications in the building automation, enabling the modelling of the systems regardless of the technology it will use, leaving this mapping for the last stage of the project Several open protocols available for implementation of building automation systems and the specification ISO/IEC10746, Reference Model of Open Distributed Processing, were a foundation for the proposed framework. The latter was used as the support to proposed methodology. This work also discusses the mapping of the defined concepts to target architecture and it presents a case study in order to validate the proposed methodology.

Keywords: Building automation, home automation, object-oriented framework

14

1 INTRODUO

1.1 Contextualizao do Trabalho

Com o crescente aumento da competio global, a produtividade e a eficincia tornam-se imperativos em todos os negcios. Os pases mais ricos e desenvolvidos so aqueles que conseguem produzir bens de elevado valor agregado com maior produtividade para atender suas prprias necessidades e ao mercado externo. A automao constitui papel fundamental nesse processo e assim observa-se, desde o surgimento dos microprocessadores a partir de 1970 e com o desenvolvimento da Informtica, um enorme avano na oferta de dispositivos automatizados e a crescente importncia de sistemas computacionais nas mais variadas aplicaes de automao. Isto ocorre porque os avanos tecnolgicos na rea da microeletrnica tornam disponveis a custos bastante acessveis, processadores de suficiente desempenho, tamanho reduzido, baixo consumo, etc. Adicionalmente, no campo da Informtica, evolues nas reas de sistemas distribudos, linguagens de programao, sistemas operacionais, entre outras permitem a realizao de sistemas computacionais fisicamente distribudos, capazes de serem monitorados, executados, e at mesmo atualizados remotamente. A automao est relacionada a equipamentos que controlam processos ou plantas. Segundo (MIYAGI, 1996) controle a aplicao de uma ao pr-planejada para que aquilo que se considera como objeto de controle atinja certo objetivo. Uma instalao predial, em analogia com os sistemas de automao industrial, basicamente um processo que se deseja controlar. Genericamente os sistemas de controle so classificados em dois tipos: os sistemas de variveis contnuas onde o objetivo igualar o valor de uma varivel fsica, denominada varivel de controle, a um valor de referncia e os sistemas de eventos discretos nos quais a execuo de operaes ocorre conforme procedimentos prestabelecidos. No primeiro caso o dispositivo de realizao do controle denominado regulador ou controlador e responsvel por executar um algoritmo de controle para ajustar o sinal recebido do processo a um valor de referncia, enquanto no segundo caso tem-se um processador de comando que avalia o estado atual do processo e determina a prxima tarefa a ser executada. Na Figura 1.1, pode-se observar os principais elementos envolvidos em um processo de controle.

15

Figura 1.1: Diagrama conceitual bsico de um sistema de controle Pode-se dizer que atualmente existem trs grandes reas para utilizao da automao: a automao industrial, a automao predial e a automao residencial. Num primeiro momento o foco de ateno de fabricantes de dispositivos e prestadores de servio foi a rea industrial. Consolidada a automao industrial ele voltou-se s construes comerciais (hotis, hospitais, prdios de escritrios, prdio pblicos, lojas de departamento, supermercados, entre outros), dando origem automao comercial e automao predial. Nessas reas a automao alm de provocar mudanas na metodologia de trabalho permitiu tambm o controle das variveis relacionadas ao ambiente de trabalho (iluminao, aquecimento e ventilao, segurana patrimonial, controle de acesso, gerenciamento energtico, etc) dando origem ao conceito de prdios inteligentes. Outra observao que inicialmente a automao predial e residencial foi realizada com as mesmas tecnologias (equipamentos, barramentos, etc) que eram utilizados na rea industrial. A observao, entretanto, que cada uma destas reas possuem caractersticas especficas tem levado ao desenvolvimento de tecnologias que tentam se adequar a necessidades prprias de cada uma delas. Embora nos primrdios da automao predial o conceito de inteligncia estivesse associado apenas disponibilidade de equipamentos modernos, hoje consenso que um prdio inteligente deve oferecer mais do que solues tecnolgicas: deve aproveitar ao mximo os recursos naturais e a tecnologia de novos materiais para atingir seus objetivos. Becker define: Prdios inteligentes podem ser definidos como naqueles onde a integrao dos sistemas e as novas tecnologias so usadas para maximizar a produtividade de seus ocupantes, permitindo gerenciamento eficiente de recursos e minimizao de custos. (BECKER,1995) Ou seja, o conceito de prdio inteligente no se restringe apenas ao uso de dispositivos eletromecnicos, sensores, atuadores e sistemas computacionais para automao de tarefas e controle de processos. Todavia, no presente trabalho focar-se- nos conceitos e tcnicas que permitam o desenvolvimento de sistemas computacionais usados em automao predial e residencial Em relao automao predial o que se observa que os sistemas necessitam executar um nmero cada vez maior de funes, entre as quais pode-se citar: o controle do sistema de iluminao ambiente, mantendo os nveis especificados conforme a aplicao; o controle de acesso a ambientes e equipamentos permitidos apenas aos usurios autorizados;

16

o controle de parmetros relativos a aquecimento, ventilao e condicionamento de ar; o controle das condies ambientais que causem ameaa segurana de pessoas e instalaes, relativamente a controle de gases perigosos e fogo; o gerenciamento de energia com objetivo de maximizar a produtividade com minimizao do consumo de energia; o controle dos sistemas de movimentao de pessoas e objetos, tais como elevadores e escadas rolantes. J na automao residencial os aspectos importantes a serem considerados so o estilo de vida e preferncias de quem vai residir ou reside no local, por isso as solues tendem a ser muito pessoais e dirigidas. A automao residencial tem que se valer de interfaces amigveis porque, na maioria das vezes, os usurios so totalmente leigos em computao, sendo avessos a programaes complexas. Alm disso no realista considerar-se que cada residncia possua um tcnico treinado para operar o sistema de automao, algo que pode ser vivel no caso de automao de um prdio comercial. Outra peculiaridade refere-se importncia do entretenimento, muito maior em sistemas de automao residencial do que em prdios comerciais. Logicamente existem caractersticas comuns s reas de automao predial e residencial das quais pode-se destacar: adequada relao custo/benefcio, confiabilidade, interatividade, atualizao tecnolgica (upgrades) simples, entre outras. Muitas destas caractersticas so tambm desejveis em sistemas de automao industrial. Neste trabalho no se far distino entre automao predial e residencial, o termo automao predial ser usado indistintamente. A Figura 1.2 mostra uma viso parcial de um sistema de automao predial e exemplifica algumas funes de controle que podem fazer parte um projeto.

Figura 1.2 : Viso parcial de funes de um sistema de automao predial Como ocorre em sistemas de automao industrial, em sistemas de automao predial, cada vez mais os dispositivos (sensores, atuadores, equipamentos autnomos) so dotados de inteligncia e existe uma clara tendncia descentralizao do controle entre os dispositivos, conectados atravs de uma arquitetura de rede adequada. Isto permite que a troca de informaes seja realizada

17

diretamente entre eles para a execuo das tarefas programadas, 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 ainda persistem e diferentes solues esto sendo propostas, em geral por diferentes grupos de fabricantes de dispositivos, para tentar resolv-los. Em trabalhos anteriores - vide (ARAUJO, 2002), (ARAUJO, 2003) e (ARAUJO, 2004), concluiu-se que os padres mais recentes esto se concentrando em definir especificaes para as ltimas camadas do modelo OSI, em especial a camada de aplicao (TANENBAUM, 1997), a fim de que a integrao entre diferentes equipamentos seja realizada de maneira mais rpida e simples. Muitos destes protocolos utilizam o paradigma da orientao a objetos para sua especificao e padronizam vrios perfis de objetos para reas especificas da automao predial citadas acima. Ao mesmo tempo, vrios trabalhos tm discutido estratgias para implementao de middlewares para soluo do problema da interoperabilidade, tal como pode ser observado em (WILS, 2002), (CHO, 2002), (KU, 2002) e (MOON, 2002). Uma outra linha de pesquisa investiga a utilizao de inteligncia artificial em sistemas de automao predial a fim de facilitar-se a operao pelos usurios. Nesta linha de pode-se citar o projeto EMBASSI (EMBASSI, 2004) que busca o desenvolvimento de novos paradigmas e arquiteturas para aumentar a interao intuitiva com diferentes sistemas, entre eles os de automao predial, fornecendo assistncia inteligente, interao multmodo e interfaces de usurio antropomrficas dentro de um framework, o qual forma uma camada acima da arquitetura fsica e lineariza a interao com o usurio, independente da tecnologia que esteja sendo empregada para implementao. Ao nvel de projeto observa-se, entretanto, a carncia de ferramentas que permitam ao projetista modelar o sistema baseado nas funcionalidades necessrias, de forma independente da tecnologia que ele ir utilizar, possibilitando o mapeamento posterior para a tecnologia mais adequada ou disponvel. Atualmente o projeto da instalao deve ser realizado utilizando a ferramenta disponvel para o protocolo, utilizando os conceitos que ela disponibiliza, de acordo com as suas caractersticas e com os conceitos implementados por esse protocolo especificamente.

1.2 Objetivos do Trabalho

O crescente aumento pela exigncia de funcionalidades na implementao dos atuais sistemas de automao predial, vem provocando 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. O grande desafio que se apresenta atualmente como a partir de dispositivos e subsistemas isolados conseguir-se sistemas totalmente integrados, os quais permitam economia no investimento e maior facilidade na operao e na manuteno dos sistemas de automao, permitindo assim um aumento no desempenho geral da edificao (REIS, 2002). Acredita-se que uma etapa importante para avaliar a real necessidade da integrao seja projetar o sistema de automao sem foco em uma tecnologia especfica,

18

o que no ocorre atualmente. Esta constatao decorrente da carncia de ferramentas de apoio ao projeto, uma vez que as etapas de especificao e implementao geralmente j esto focadas em uma tecnologia pr-definida. Este trabalho busca preencher a lacuna deixada pela carncia dessas ferramentas, tendo por finalidade a especificao de um framework orientado a objetos para o desenvolvimento de aplicaes de automao predial, permitindo modelar estes sistemas de forma independente da tecnologia que ele ir utilizar, possibilitando o mapeamento posterior para a mais adequada ou disponvel, conforme ser abordado nos prximos captulos.

1.3 Organizao do Texto

O texto desta dissertao est organizado como segue: o prximo captulo apresenta o estado da arte em sistemas de automao predial, onde so apresentados as arquiteturas usuais nesses sistemas, os principais padres abertos disponveis, alguns frameworks, uma breve descrio do modelo de referncia para processamento distribudo aberto e uma avaliao de alguns trabalhos relacionados com os conceitos de viso e com este modelo de referncia. O captulo 3 define todas as etapas de projeto do arcabouo proposto. O captulo 4 apresenta a metodologia para o projeto de sistemas de automao predial, a qual suportada por este framework. O Captulo 5 apresenta a validao do modelo apresentado nos dois captulos anteriores: os conceitos apresentados so mapeados para uma arquitetura alvo e apresentado um estudo de caso com o objetivo de validar a metodologia proposta. Finalmente o ltimo captulo apresenta as concluses obtidas e aponta para os trabalhos futuros. No captulo de anexos pode ser encontrada a descrio detalhada sobre o modelo, com a descrio de todas as classes e dos subsistemas especificados, o detalhamento da arquitetura alvo e do mapeamento tecnolgico para esta arquitetura e o detalhamento de parte do estudo de caso no apresentado no corpo do texto.

19

2 ANLISE DO ESTADO DA ARTE EM AUTOMAO PREDIAL

Conforme j abordado no Captulo 1, as primeiras solues de automao em sistemas prediais implementavam as mesmas tecnologias utilizadas em automao industrial. Entretanto, a observao de que estes sistemas apresentam diferentes requisitos, levou ao desenvolvimento de solues especficas para esta rea nos ltimos anos. Este captulo tem por objetivo fornecer uma breve descrio do estado da arte em sistemas de automao predial. Inicialmente sero apresentadas as arquiteturas usais em sistemas de automao predial e posteriormente sero abordadas algumas propostas de protocolos de comunicao disponveis para implementao desses sistemas e seus modelos. Na seqncia sero analisados alguns frameworks e no final do captulo includa uma breve descrio do modelo de referncia para sistemas distribudos abertos, o qual serviu de base para o modelo de objetos e a metodologia de projeto proposta neste trabalho.

2.1 Arquiteturas em Sistemas de Automao Predial.

Quanto arquitetura fsica dos componentes de um sistema de automao predial, pode-se ter trs solues distintas. Na soluo mais simples um dispositivo central de controle executa todos os algoritmos de controle, sendo responsvel pelo gerenciamento total do sistema. As caractersticas desse tipo de sistema esto amplamente discutidas na literatura de redes de computadores e sistemas operacionais (TANENBAUM, 2003). As evolues de setores como microeletrnica e da informtica deram origem ao segundo tipo de arquitetura no qual a implementao do sistema de automao predial est distribuda entre dispositivos autnomos (sensores, atuadores, interfaces com usurio, etc) que so conectados atravs de uma arquitetura de rede adequada e distribuem entre si a tarefa de controle, com a troca de informaes diretamente entre eles para a execuo das tarefas programadas, sem a necessidade de uma unidade de controle centralizada. Uma discusso das caractersticas dessa arquitetura pode ser encontrada na mesma referncia citada anteriormente. O terceiro tipo de soluo uma soluo intermediria entre os sistemas centralizados e os totalmente distribudos. Nesta soluo existem dispositivos autnomos que funcionam com um conjunto de funcionalidades que independem de uma unidade central, porm determinadas funcionalidades s so possveis pelo gerenciamento da unidade de controle central.

20

Um sistema de Automao Predial pode ser subdividido em diversas partes de acordo com a funcionalidade que se deseja controlar. Cada uma dessas partes, posteriormente denominada subsistema no mbito deste trabalho, responsvel pelo controle de um conjunto de funcionalidades afins, das quais pode-se destacar: aquecimento, ventilao e ar condicionado: permite o controle da temperatura, da ventilao e da umidade ambiental com parmetros selecionados de acordo com a estao do ano, perodo do dia, ocupao, dia da semana (domingo, feriado), etc., a fim de aumentar o conforto e a produtividade das pessoas usurias do prdio e minimizar o consumo de energia; iluminao: possibilita o controle de iluminao de acordo com os parmetros tais como horrio, ocupao do ambiente, entre outros, garantindo nveis de iluminao adequados nos ambientes internos e externos; o controle de acesso: permite o acesso apenas a usurios autorizados s instalaes internas (salas, elevadores, estacionamento, etc) e aos equipamentos; segurana: mantm as condies de segurana das instalaes em caso de problemas eltricos ou mecnicos, fumaa e outros gases, incndio, vazamentos de gua, entre outros, devendo ser capaz de acionar as equipes de emergncia, fechar automaticamente portas contra fogo, acionar sistemas de emergncia, etc. gerenciamento de energia: permite o monitoramento e o gerenciamento do consumo de energia e de outros recursos tais como gs, gua fria e quente, fornecimento e consumo de energia eltrica (controle da demanda, a programao horria de cargas, a superviso de geradores de emergncia e de sistemas de alimentao permanentes,etc.) entre outros; movimentao: tem como objetivo o gerenciamento dos recursos de transporte tais como elevadores e escadas rolantes, com algoritmos selecionados conforme horrio, dia da semana, fluxo de pessoas, etc.; entretenimento: possibilita o controle de HomeTeather (DVD, CD, TV, VCR), som ambiente, vdeo e udio sob demanda, internet rpida, jogos em rede, etc.

2.2 Protocolos de Comunicao

Para implementar estas tarefas de controle um sistema de automao predial pode utilizar uma soluo proprietria ou solues abertas. No primeiro caso um determinado fabricante oferece uma soluo, a qual pode ser para um subsistema especfico ou para um sistema de automao completo que envolva todos os subsistemas sendo que apenas dispositivos fornecidos por este fabricante podem operar corretamente no sistema. A interoperabilidade com subsistemas de outros fabricantes uma questo que depende de negociaes comerciais e da existncia de gateways que permitam a converso de protocolos para permitir a comunicao. A outra possibilidade utilizar solues abertas. Neste caso equipamentos fornecidos por diferentes fabricantes podem interoperar desde que tenham sido fabricados segundo um mesmo padro. Numa analise da situao atual de mercado, o que se observa so fabricantes trabalhando em conjunto na especificao de padres que so administrados por associaes encarregadas da manuteno e da atualizao do padro e pela certificao de produtos. Novamente a comunicao entre dispositivos de diferentes padres exige a utilizao de gateways.

21

Um padro define uma arquitetura para interligao dos dispositivos e o protocolo que ser implementado para permitir a comunicao entre eles. Alguns dos padres abertos mais utilizados sero discutidos a seguir, sendo que uma anlise mais detalhada dos mesmos pode ser encontrada em (ARAUJO, 2002), (ARAUJO, 2003) e (ARAUJO, 2004). 2.2.1 X10 O sistema X-10 PLC (Power Line Carrier) (X10,2003) um dos mais antigos protocolos de comunicao para sistemas de automao residencial, tendo sido originalmente desenvolvido nos anos 70 e tendo os primeiros produtos disponveis a partir de 1979. Atualmente uma grande gama de produtos X-10 encontra-se disponvel (vide referncia anterior). O protocolo X-10 transmite dados modulados sobre a rede eltrica sendo que uma informao binria transmitida sempre que o sinal senoidal de tenso eltrica passa pelo zero. E em funo disto podem ser utilizados em qualquer residncia utilizando-se a infra-estrutura da rede eltrica j existente. Na Figura 2.1 pode-se observar o formato do frame para transmisso de mensagens entre um transmissor e um receptor. Um endereo de dispositivo composto por um cdigo de ambiente (house code) mais um cdigo de unidade (key/number code), permitindo enderear 256 pontos diferentes. Uma mensagem bsica em X-10 usa 13 bits. Os primeiros 4 bits so um cdigo de entrada (start code), os 4 seguintes um cdigo de ambiente (house code), os prximos 4 so um cdigo de funo (function code) ou de unidade (key ou number code) e o ltimo bit indica se os 4 anteriores devem ser interpretados como funo ou como unidade.
Cdigo transmitido quando o nmero do receptor selecionado

Start Code

House Code

Number Code

Start Code

House Code

Number Code

Start House Function Start House Function Code Code Code Code Code Code Figura 2.1 : Esquema de transmisso de mensagem no protocolo X10 As funes disponveis so basicamente para ligar, desligar e realizar configuraes bsicas em dispositivos de automao predial. Para acionar um equipamento X-10 so necessrios dois conjuntos de 13 bits, um para transmitir o endereo e outro para transmitir o comando em si. A transmisso em broadcast e todo o comando repetido duas vezes, assim um comando completo ocupa necessita aproximadamente 0,8s. A rede eltrica pode ocasionar alguns comportamentos errticos dos componentes tais como falta de energia ou descargas eletromagnticas. Pode-se utilizar o X-10 em diversas aplicaes, tais como acionamento remoto de lmpadas, eletrodomsticos e portas. No entanto, como sua confiabilidade limitada, no se recomenda seu uso em aplicaes criticas, ligadas segurana domstica, j que os dispositivos no implementam sistemas de monitoramento para avaliar o status de um equipamento. 2.2.2 LONWorks O padro LonWorks (ECHELON, 1999-a) uma tecnologia proposta pela empresa Echelon em 1990 e abrange toda a infra-estrutura necessria (hardware e

Cdigo transmitido quando a funo selecionada

22

software) para a operao da rede local denominada LON (Local Operating Network). um sistema aberto e de controle distribudo, com o funcionamento baseado num protocolo de comunicao denominado LonTalk. Em outubro de 1999, LonTalk tornouse o padro ANSI 709.1. Uma associao de usurios denominada LonMark Interoperability Association estabelece padres e certifica dispositivos de controle interoperveis. O controle da rede distribudo nos dispositivos os quais so denominados ns. Cada n tem seu prprio programa aplicativo, de acordo com a sua funo no processo, e capaz de comunicar-se com os outros ns usando o protocolo de comunicao. possvel construir uma rede com at 32385 dispositivos, os quais podem ser configurados em vrias topologias usando-se diversos meios fsicos. um protocolo dividido em camadas que implementa todas as camadas mo modelo OSI, baseado em pacotes, com comunicao peer-to-peer e utiliza o algoritmo CSMA p-persistente preditivo para acesso ao meio fsico. Um esquema de prioridades garante o acesso preferencial ao meio para pacotes com prioridade alta. Diversos esquemas de endereamento so possveis: os pacotes podem ser endereados, a partir do n de origem, para um n especfico (physical adress ou device adress), para um grupos de ns(group adress) ou para todos os dispositivos(broadcat adress). Todo o pacote transmitido contm o endereo do dispositivo de origem (source adress) e do dispositivo de destino (destination adress), que pode ser qualquer um dos citados acima. Um programa de aplicao consiste em um ou mais objetos LonWorks. Cada objeto baseado na definio de um perfil funcional (functional profile) vide Figura 2.2, 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 (ECHELON, 2002-a).

Figura 2.2 : Perfil funcional de um sensor e de um controlador de luminosidade Os perfis padronizam as funes de um objeto, fornecendo uma descrio comum do comportamento funcional do objeto especificado. Existem perfis 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.

23

A interoperabilidade de dispositivos de diferentes fabricantes na rede garantida por um conjunto padro de variveis de rede (Standard Network Variable Types SNVTs). So 166 variveis padronizadas atualmente (ECHELON, 2002-b), sendo ainda possvel que fabricantes definam variveis de rede no padronizada (UserDefined Network Variable Types UNVTs), que s sero acessveis a dispositivos que as conheam previamente. O programa da aplicao no precisa saber de onde vem uma varivel de rede ou para que dispositivo ela ir. Outras camadas do hardware/software so configuradas, durante o projeto da rede, para saber o endereo lgico dos dispositivos que esperam aquela varivel. Esse processo de configurao denominado ligao (binding) e cria conexes lgicas entre os ns da rede. 2.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) a qual usada para preparar e configurar a instalao, fazer manuteno e diagnsticos. O sistema , geralmente, implementado de maneira descentralizada e diferentes meios fsicos so disponveis para construo do barramento (par tranado, fiao eltrica existente (powerline), rdio freqncia, etc.). Com o objetivo de reduzir o trfego na rede, os dispositivos so divididos em linhas e a rede pode ter at 61455 dispositivos (EIB, 1999-a). Uma unidade de acesso ao barramento padronizada (BCU Bus Coupling Unit) permite que os dispositivos sejam fornecidos por diferentes fabricantes. Um conjunto padro de objetos definido a partir dos quais as aplicaes so construdas (EIB, 1999-c), conforme pode ser na observado na Tabela 2.1. Para cada um desses objetos est definido um conjunto de propriedades, algumas das quais so obrigatrias e outras opcionais. Objetos padres tambm foram definidos para indicao tipos de dados das propriedades, IDs e tipos de objetos (object-types). Tabela 2.1 : Objetos EIB Padronizados
Objeto Device Object Addresstable Object Associationtable Object Applicationprogram Object Interfaceprogram Object EIB-Object Associationtable Object Router Filtertable Object Poling Master EIB Object File Object Analog Input/Output/ValueObject Binary Input/Output/ValueObject Finalidade informaes sobre o dispositivo inclui o endereo fsico e o endereo de grupo do dispositivo. Fornece operaes de gerenciamento para downloading conecta Groupobjects em endereos de grupo contm informaes globais sobre o programa de aplicao do usurio especifica um tipo especial de programa de aplicao que gerencia a PEI definio dos objetos escravos de um dispositivo inclui informaes sobre a Filtertable para um roteador Descreve um mestre para um grupo de polling especfico descreve arquivo de dados em um dispositivo define um objeto cujas propriedades representam as caractersticas visveis de um dispositivo fsico ou hardware de entrada/sada analgico define um objeto cujas propriedades representam as caractersticas visveis de um dispositivo fsico ou hardware de entrada/sada que pode ter apenas dois distintos estados

24

Objeto Counter Object Loop Object

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 GroupCommunication-Objects) (EIB, 1999-b). 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.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 Air-Conditioning Engineers) e adotado pela ANSI. O grupo de trabalho que elaborou o protocolo levou aproximadamente nove anos para definir o padro. A padronizao pela ASHRAE e pela ANSI ocorreu em 1995. As funcionalidades das camadas de apresentao, sesso e transporte do modelo OSI so implementadas na camada de aplicao ou so eliminadas. Para meio fsico foram adotados alguns padres de LAN j estabelecidos no mercado. O modelo definido para o BACnet est fundamentado nos seguintes aspectos (SWAN, 2003): 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; regras de interoperabilidade que fornecem mecanismos para que sistemas com componentes de diferentes fornecedores operem corretamente em conjunto, usando requisies padro de servio. Os objetos podem representar uma caracterstica fsica ou um grupo de caractersticas que realizam uma determinada funo. Podem representar tambm conceitos abstratos como um programa, horrios e dados histricos. Cada objeto possui um conjunto de propriedades que permite o seu controle. A Tabela 2.2 permite a visualizao dos objetos BACnet padronizados. Tabela 2.2 : Objetos BACnet padronizados
OBJETO Analog Input EXEMPLO DE USO Entrada de um sensor OBJETO Event Enrollment EXEMPLO DE USO Descreve um evento que pode ser uma condio de erro ou um alarme que outro dispositivo de saber. Ele pode chamar um dispositivo ou usando um objeto Notification Class chamar mltiplos dispositivos. Permite acesso para ler e escrever arquivos de dados suportados pelo dispositivo. Fornece acesso para mltiplas propriedades de mltiplos objetos em uma operao simples de leitura. Fornece acesso padronizado para um "control loop". Representa o estado de um processo de mltiplos estado. Representa o estado desejado de um processo de mltiplos estado. Contm a lista de dispositivos que devem ser informados por um objeto Event Enrollment sobre uma mensagem de alarme.

Finalidade usado para dispositivos de hardware contadores permite representar loops de controle

Analog Output Analog Value Binary Input Binary Output Binary Value Calendar

Sada de um controlador

File

Setpoint ou outro parmetro de um Group controle analgico Entrada de um dispositivo tipo ON/OFF Sada rel Loop

Multi-state Input Parmetro de controle binrio (digital) Multi-state Output Define uma lista de datas para Notification agendamento. Class

25

OBJETO Command

Device

EXEMPLO DE USO OBJETO Escreve mltiplos valores para mltiplos Program objetos em mltiplos dispositivos para atender um propsito especifico (como um modo de emergncia). Propriedades que informam que objetos e Schedule servios o dispositivo suporta e outras informaes especficas do dispositivo como fornecedor, reviso de firmware, etc.

EXEMPLO DE USO Permite que um programa possa ser iniciado, parado, carregado e descarregado e informa a situao atual do programa. Define um agendamento semanal de operaes. Pode usar o objeto Calendar para tratar as excees.

Foram definidos e padronizados dezoito tipos de objetos e 123 propriedades, algumas das quais so obrigatrias e outras opcionais, dependendo do objeto. As propriedades presentes em cada objeto iro depender do tipo de dispositivo no qual o objeto reside e das prprias caractersticas do objeto que est sendo implementado. Os dispositivos comunicam-se atravs de servios. Cada requisio de servio (service request) enviada e cada confirmao de servio (service acknowledgment) recebido torna-se um pacote de mensagem que transferido atravs da rede, entre os dispositivos. Cada dispositivo implementa os servios adequados a sua funo e a sua complexidade. O servio ReadProperty, por exemplo, deve estar disponvel em todos os dispositivos. Cada programa de aplicao, que o software que desempenha a operao do dispositivo, recebe as requisies de servio e as processa. BACnet define 32 servios e os classifica em cinco categorias, que so: alarm and event, file access, object access, remote device management, virtual terminal services. Para garantir interoperabilidade a idia dividir o problema da interoperabilidade em conjuntos comuns de funes e definir requisies BACnet para cada um desses conjuntos. Foram definidas cinco reas reas de interoperabilidade para classificar os BIBBs (BACnet Interoperability Building Blocks) . Em cada rea h uma srie de servios que sero executados pelos BIBBs (BUSHBY, 1999): so quatorze para data sharing, oito para alarms and events, dois para scheduling, quatro para trending e vinte e sete para network management. Um BIBB pode ser implementado por um ou mais servios e na execuo cada servio h sempre duas entidades envolvidas: um cliente (dispositivo que pergunta) e um servidor (dispositivo que responde). O servidor deve ser capaz de receber uma requisio de servio, execut-la e retornar o resultado e um cliente deve ser capaz de iniciar uma requisio de servio e processar a resposta quando ela chegar. 2.2.5 HomePnP HomePnP (CIC, 1998), 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. O protocolo fornece todos os detalhes necessrios para construir uma mensagem para efetuar uma operao especfica em um dispositivo ou subsistema. O padro baseado na CAL (Common Application Language) e no nvel de aplicao do protocolo CEBus (Consumer Electronics Bus). Este protocolo um padro EIA (Electronic Industries Association) desde 95, EIA 600, aps onze anos de trabalho do Comit CEBus que contou com o envolvimento de mais de 400 empresas de diferentes reas. A fim de permitir seu uso por diferentes fornecedores de dispositivos, independente do protocolo de comunicao utilizado, a CAL (CIC, 1996), acabou sendo publicada em 1997 como um padro separado do EIA 600, sob a denominao de EIA 721.

26

O protocolo HomePnP padroniza a estrutura das mensagens e os cdigos de controle usados nas mensagens. O protocolo de aplicao fornece todos os detalhes necessrios para construir a mensagem para efetuar uma operao especfica num dispositivo ou subsistema, independente do protocolo usado na camada de transporte. Para garantir que os produtos interoperem entre si, eles devem ser projetados usando o padro CAL e utilizando os contextos, objetos e variveis de instncia contidos na especificao HomePnP. Um objeto CAL define uma funo de controle simples dentro de um contexto e implementado por um conjunto de variveis, chamando variveis de instncia (IVs - Instance Variables). A especificao define um conjunto de 22 objetos, a partir dos quais os dispositivos e sistemas so construdos. Um contexto um grupo de objetos que representa uma funo comum. Um dispositivo pode implementar vrios contextos podendo ser um hardware com finalidades especficas ou um software em um PC, por exemplo Esto especificados vrios grupos de contexto (General, Audio/Video, 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 (Environmental Zone, Environmental Sensor, Environmental Sensor Status, etc) 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 est especificado um conjunto de mtodos que podem executar em vrios objetos, tais como: setOn, setOff, setValue, getValue, setArray, getArray, etc. 2.2.6 UPnP Universal Plug&Play (UPnP) (Microsoft, 2000-a), uma arquitetura de software aberta e distribuda que permite s aplicaes dos dispositivos conectados em rede trocarem informaes e dados de forma transparente para o usurio final, sem necessidade de configurar a rede, os dispositivos e o sistema operacional. A descrio dos servios e dispositivos (Device and Service Descriptions) mantida pelo Universal Plug and Play Forum, uma associao composta, atualmente, por 539 membros das reas de dispositivos eletrnicos, computao, automao residencial, impresso, fotografia, redes de computadores, computao mvel, etc e o seu desenvolvimento est direcionado s redes domsticas e s redes de pequeno porte (proximity networks) em pequenas empresas e pequenos prdios comerciais. Uma das principais caractersticas do UPnP que ele foi construdo usando toda uma infraestrutura de protocolos j padronizados e amplamente utilizado pelo mercado para prover as suas diferentes caractersticas, tais como TCP, UDP, IP, SOAP, GENA, entre outros. No nvel mais alto as mensagens contm apenas informaes especficas do fabricante sobre o seu dispositivo, as quais so complementadas por informaes definidas pelo UPnP Forum. Os elementos bsicos do UPnP so os dispositivos (devices), os servios (services) e os controladores (control points), cujas informaes so estruturadas utilizando XML (Extensible Markup Language).

27

Um dispositivo (lgico) um continer de servios e de dispositivos aninhados. Um dispositivo raiz (fsico), o qual possui um endereo IP na rede, pode conter outros dispositivos (lgicos) e servios. Por este motivo o conjunto de servios que um determinado dispositivo deve prover e as suas propriedades devem ser padronizadas, para garantir interoperabilidade entre diferentes fabricantes de dispositivos. Um controlador um componente lgico capaz de descobrir e controlar 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. A descrio de um servio define as aes e seus argumentos, as variveis de estado com seus tipos, faixa de valores e eventos caractersticos. Um servio pode ter zero ou mais aes, as quais podem ter argumentos de entrada e de sada. 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, as quais contm o nome e o estado atual de uma ou mais variveis de estado. Estas mensagens tambm so formatadas usando GENA (General Event Notification Architecture). Quando um dispositivo tem uma URL para apresentao, o controlador pode recuperar a pgina, carreg-la em um browser e, dependendo da capacidade da pgina, permitir ao usurio o controle e/ou a visualizao do estado do dispositivo, conforme capacidades especifica ou da pgina e do dispositivo A UPnP Device Architecture (Microsoft, 2000-b) 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 ainda existem poucos dispositivos padronizados disponveis comercialmente. 2.2.7 KNX O padro KNX (KNX, 2003) um padro europeu que comeou a ser especificado em 2000 e tem como objetivo a convergncia dos padres BatiBUS (BatiBUS, 2004), European Instalation Bus (EIB) e European Home Systems (EHS, 2004). Ele administrado pela Konnex Association e tem como premissa o controle distribudo entre os dispositivos que compem a rede. Os principais conceitos do padro - vide Figura 2.3, so: um modelo para construo de aplicaes distribudas para permitir a distribuio das tarefas entre diferentes dispositivos; esquemas de configurao e gerenciamentos que permite construir conexes lgicas entre as partes de uma aplicao distribuda que executa em diferentes ns; um sistema de comunicao que suporta a configurao, o gerenciamento e o funcionamento da rede, o qual suportado pela camada denominada Common Kernel; modelos para construo de dispositivos fsicos, organizado em perfis, os quais padronizam a estrutura bsica dos mesmos.

28

Uma das caractersticas que o diferencia de todos os demais padres existentes que ele utiliza trs diferentes mecanismos de configurao: System-mode (S-mode): neste modo, herdado do padro EIB, a configurao da rede e a instalao de novos dispositivos utiliza software de configurao, o ETS (EIB Tool Software), permitindo a configurao plena de todos os dispositivos da rede. Easy-mode (E-mode): herdado do padro Batibus, neste modo no necessrio ferramenta de configurao, cada componente possui alguns parmetros prdefinidos porm possvel reconfigurar alguns parmetros, principalmente setups e conexes lgicas.

Figura 2.3 : Arquitetura do padro KNX (KNX, 2003). Automatic-mode (A-mode): herdado do padro EHS, permite que ao conectar o dispositivo na rede ele se auto configure (plug and play) seguindo um modelo de aplicao pr-definido. O conceito principal de uma aplicao KNX o de data-point. Eles representam as variveis do sistema, podendo ser uma entrada, uma sada, um parmetro, o dado de um diagnstico, etc. A fim de garantir a interoperabilidade est especificado um conjunto padro denominado Standardized Data-point Types os quais podem ser agrupados formando blocos funcionais (FB functional blocks). Estes blocos funcionais esto relacionados com os campos de aplicao, embora alguns sejam de uso geral, tais como data e tempo. A Figura 2.4 ilustra estes conceitos.

Figura 2.4 : Estrutura do modelo de objetos(KNX, 2003).

29

desejvel que todo o processo de comunicao esteja baseado no acesso a data-points e no a dispositivos, o que garante o acoplamento fraco (independncia de aspectos de implementao), desejvel em sistemas distribudos. Uma aplicao basicamente corresponde a um conjunto de envio e recebimento de data-points. Todos os dispositivos que mapearam um determinado data-point na sua tabela de endereos recebero uma atualizao seu valor, sempre que uma mensagem deste tipo for colocada na rede. Quanto topologia e endereamento o padro segue o modelo proposto pelo protocolo EIB e prev a utilizao de trs diferentes meios fsicos: o par tranado (TP), a rede eltrica (PL) e radio freqncia (RF). Uma camada, denominada Common Kernel, representa o controle da sobre as diferentes camadas da rede. Na conexo lgica entre data-points podem ser usados trs esquemas: o primeiro denominado free binding: no h definio a priori de quais datapoints devem ser conectados entre si, sendo permitido qualquer configurao das funcionalidades dos dispositivos; o segundo denominado structured binding: o modelo da aplicao estabelece um modelo preciso para conexo de um conjunto de data-points, os quais correspondem a determinados blocos funcionais ou canais. Controller (CTRL), push-button (PB) e A-Modes seguem este conceito; o terceiro denominado tagged binding. A conexo lgica tambm prdefinida no modelo da aplicao, porm o valor de endereo nunca alterado, uma vez que parte deste valor implica diretamente no data-point alvo no dispositivo parceiro na comunicao. O modelo LTE (Logical Tag Extended mode) usa este princpio. 2.2.8 Comparao entre os Protocolos Uma das primeiras limitaes que se observa nos protocolos apresentados o suporte a fluxo contnuo de dados entre dispositivos, caractersticos de udio e vdeo: LonWorks, EIB, KNX e BACnet so desenvolvidos para dispositivos de controle e no suportam a distribuio de udio ou vdeo analgico ou dados digitais, alm disso as taxas de transmisso disponveis atualmente no suportam estas aplicaes. HomePnP embora especifique Classes de Contexto para udio/Vdeo at o momento ainda no especificou os padres e os microprocessadores disponveis no mercado no oferecem este suporte. O protocolo KNX um padro recente em fase final de especificao e como padro de convergncia busca inserir os pontos fortes de cada um dos padres em que se baseia, embora seja fortemente baseado no padro EIB, adotando seus principais conceitos. Seu grande diferencial a possibilidade dos dispositivos oferecerem diferentes modos de configurao que vo desde plug and play, passando por algumas configuraes bsicas no prprio dispositivo e chegando na configurao plena de todas as funcionalidade utilizando ferramenta de configurao. Uma caracterstica comum entre diferentes protocolos a classificao das aplicaes na tentativa de padronizar uma estrutura comum a ser utilizada nos dispositivos, a fim de garantir a interoperabilidade entre produtos de diferentes fornecedores. Assim tm-se os perfis nos protocolos LonWorks e EIB, os contextos no HomePnP e os grupos no protocolo UPnP, entre outros. A Tabela 2.3 apresenta, em ordem alfabtica, a classificao adotada pelos protocolos LonWorks, HomePnP e UPnP, onde pode ser observado que existe um conjunto de classes comuns.

30

Tabela 2.3 : Classificao de dispositivos por diferentes padres

Perfis Funcionais LONMark Access/Intrusion/Monitoring Energy Management Fire & Smoke Device HVAC Industrial Input/Output Lighting Perfis Funcionais LONMark Motor Control Refrigeration Sensor Vertical/Conveyor Transportation Contextos HomePnP Appliance Audio/video Communications Computer/Home Office Convenience HVAC Lighting Contextos HomePnP Security Utility Grupos UPnP Appliance Audio/video Home Automation Security Image Internet Gateways Grupos UPnP

&

A padronizao de objetos muito bem estruturada nos protocolos BACNet, EIB e HomePnP. A Tabela 2.4 apresenta os objetos comuns entre estes protocolos Tabela 2.4 : Objetos comuns entre alguns protocolos
EIB-Type_Id (dec) EIB Object types 0 - Device Objec 1 - Addresstable Object 2 - Associationtable Object 3 Application program Object 4 - Interface Program 5 - EIB-Object-Associationtable-Object 6 - Router Filtertable 10 - Pollingmaster 11 - File 100 - Analogue-Input 101 - Analogue-Output 102 - Analogue-Value 103 - Binary-Input 104 - Binary-Output 105 - Binary-Value 106 - Counter 107 - Loop 108 - Multistate-Input 109 - Multistate-Output BACnet ID(dec) BACnet Object types 8 - Device Object HomePnP ID(hex) HomePnP Object types 01 - Node Control 02 - Context Control

16 - Program Object

10 -File 0 - Analogue-Input 1 - Analogue-Output 2 - Analogue-Value 3 - Binary-Input 4 - Binary-Output 5 - Binary-Value 12 - Loop 13 - Multistate-Input 14 - Multistate-Output 6 - Calendar 7 - Command 9 - Event Enrollment 11 - Group 15 - Notification Class 17 - Schedule

16 - Data Memory 08 - Analog Sensor 07 - Analog Control 06 - Binary Sensor 05 - Binary Switch 1C - Counter/Timer 0A - Matrix Switch 10 - Multi-position Sensor 09 - Multi-position Switch

15 - List Memory 03 - Data Ch. RCVR 04 - Data Ch. Trans 0F - Metter 10 - Display 11 - Medium Transport 13 - Dialer 14 - Keypad

31

EIB-Type_Id (dec) EIB Object types

BACnet ID(dec) BACnet Object types

HomePnP ID(hex) HomePnP Object types 17 - Motor 19 - Synth/Tuner 1A - Tone Generator 1D - Clock

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.

2.3 Frameworks
2.3.1 OSGI OSGi (Open Services Gateway Initiative) (OSGi, 2001) 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. Ela composta por mais de 60 membros, incluindo provedores de servio de Internet, operadores de rede, fabricantes de equipamentos, desenvolvedores de softwares, entre outros. Ela est focada na camada de aplicao e aberta para qualquer protocolo, camada de transporte ou dispositivo. O componente principal do esforo OSGi foi concentrado na especificao de gateways de servios (services gateway), que so servidores inseridos em uma rede para conectar a rede externa com clientes internos, atuando como uma plataforma para instalao e execuo de software que trabalha em cooperao com dispositivos em uma rede domstica. Esse software permite que provedores de servios externos interajam com os dispositivos dessa rede, provendo servios para seus proprietrios. A Figura 2.5 mostra a localizao do servio num sistema instalado.

Figura 2.5 : Localizao de um service gateway (OSGi, 2001). A idia principal interconectar as redes de dispositivos localizados dentro de residncias (tais como sensores, interruptores, alm de DVDs, aparelhos de som, entre outros) a servios externos, sendo que fisicamente proposto um gateway entre uma rede externa do tipo conexo de TV a cabo ou DSL e do lado interno redes com os protocolos similares aos analisados no captulo anterior, permitindo que provedores possam fornecer servios tais como filmes e msicas sob demanda que possam ser

32

distribudos a diversos dispositivos em um prdio, controle e monitoramento do sistema de segurana, gerenciamento dinmico de energia pela empresa fornecedora, etc. As especificaes OSGi padronizam interfaces de programao que podem ser utilizadas para construir aplicaes tipo gateway. Gateways de servio abertos devem suportar estas APIs para estarem de acordo com as a especificaes. Atravs do uso dessas APIs possvel enderear servios, gerenciar ciclo de vida, controlar a dependncia entre os servios, gerenciar dados, controlar acessos a dispositivos e a recursos e garantir segurana. A especificao divide essas APIs em cinco grupos e define uma estrutura de execuo de software projetada para acomodar pacotes de software modulares. Um framework forma o ncleo da especificao da plataforma de servio OSGI e fornece um ambiente que suporta o desenvolvimento servios extensveis que podem ser descarregado via rede que so denominados pacotes (bundles). Um pacote uma entidade colocada disposio para aplicaes baseadas em Java. Este framework fornece um modelo de programao para desenvolvedores de pacotes Java, simplificando o desenvolvimento dos pacotes. Este framework capaz, entre outras tarefas, de gerenciar a dependncia entre os pacotes e os servios. Qualquer dispositivo padro OSGi pode buscar e instalar pacotes OSGi e remov-los quando no forem mais necessrios. Estes pacotes so construdos a partir de um conjunto de servios cooperantes disponveis em um servio de registro (service registry) compartilhado. Um servio definido por sua interface (service interface) e pelo objeto que a implementa (service object). As dependncias de uso dos servios pelos pacotes so gerenciadas pelo framework, que mapeia os servios para seus objetos de servio subordinados e fornece mecanismos que habilitam um pacote instalado a requisitar os servios que necessite. Ele fornece tambm um mecanismo de gerenciamento de eventos para que os pacotes possam receber eventos de objetos de servios que so registrados, modificados ou desinstalados. A plataforma oferece ainda um conjunto de servios para garantia de segurana das aplicaes, controle de dispositivo (para localizao, instalao e configurao automtica de drivers), gerenciamento de usurios e servidor HTTP. 2.3.2 Niagara Framework e Baja O Niagara Framework (TRIDIUM, 2004-a) e (TRIDIUM, 2004-b) uma infraestrutura de software, desenvolvido pela empresa Tridium, que permite que desenvolvedores construam solues baseadas em web para acesso, automao e controle de dispositivos inteligentes em tempo real, atravs da Internet. uma estrutura aberta, baseada em Java, com capacidade de integrar em um ambiente de desenvolvimento diversos sistemas e dispositivos independentes de fabricante, de padro de comunicao ou software (tais como BACNet, LonWorks, Modbus, DeviceNet, entre outros). Ele construdo a partir de padres para Internet (Java, TCP/IP, HTTP e XML), sua proposta tornar possvel o controle de dispositivos de qualquer lugar atravs de um web browser. Sua principal caracterstica que os dispositivos so convertidos em objetos de software para a construo das aplicaes e o Framework1 integra os dispositivos, comunicando-se com eles atravs da sua rede e de seu protocolo nativos, permitindo a
1

Framework nesse contexto refere-se ao Niagara FrameworkTM

33

leitura de dados, o envio de comandos e a utilizao de ferramentas de programao para configurao e programao, sem a necessidade de instalar um gateway fsico entre os diferentes sistemas. Na Figura 2.6 pode-se observar a arquitetura do sistema. Mltiplas camadas de aplicao, compostas de uma combinao de aplicaes gerais, solues verticais e aplicaes especficas podem operar em paralelo. Exemplos de aplicaes horizontais so acesso a web, segurana, armazenagem de dados histricos e alarmes. Como exemplos de aplicaes verticalizadas tem-se automao predial, FMS (Facility Management Systems), gerenciamento de manuteno, monitorao remota e diagnsticos, etc.

Figura 2.6 : Arquitetura Niagara (TRIDIUM, 2002-a). O ambiente pode operar com as diversas plataformas de hardware (estaes de trabalho Sun, servidores NT, computadores pessoais (PCs) e controladores) e de sistemas operacionais (Wind River's VxWorks RTOS, Microsoft Windows NT ou UNIX) que suportem a mquina virtual Java, escolhidos de acordo com as necessidades especficas da aplicao. Apesar desta portabilidade a empresa comercializa controladores denominados JACE (Java Application Control Engine) como dispositivo principal de interconexo entre diferentes sistemas de um prdio. Uma caracterstica importante do ambiente o servio de integrao de dispositivos que permite a conexo entre os dispositivos fsicos e o modelo de objetos,. Isto possibilita que o ambiente comunique-se com o dispositivo usando o seu prprio protocolo e a sua prpria rede.. Os objetos de software usam esses servios para ler dados de campo dos dispositivos, enviar-lhes comandos e fornecer suporte para reconfigurao e reprogramao dos mesmos. Exemplos de alguns sistemas heterogneos que podem ser integrados usando esses servios so: BACNet, LonWorks, Modbus, DeviceNet, OPC, Fieldbus Fundation, Profibus, etc. J os servios de integrao de empresa permitem a ligao do ambiente com as aplicaes de gerenciamento. Atravs de tecnologias baseadas em padres abertos, tais como DCOM, CORBA e XML, essas aplicaes podem acessar diretamente os dados coletados dos dispositivos ou calculados pelo ambiente, usando os recursos implementados por esses servios. A partir do desenvolvimento do Niagara, a empresa Tridium Inc passou a liderar junto com a Sun Microsystems um grupo formado por empresas fornecedoras de sistemas de automao tais como, Siemens, Echelon e Johnson Controls, entre outras,

34

com a tarefa de criar uma plataforma aberta, padro Java, para o mercado de automao predial, a qual foi denominada Baja (Building Automation Java Architecture), totalmente baseada nas caractersticas Niagara. Baja (TRIDIUM, 2004-c) define um ambiente de aplicao de automao predial com especificaes que descrevem um conjunto de APIs Java e esquemas XML para aplicaes de sistemas de controle interoperveis. Ela define uma arquitetura Java padro para controladores programveis, uma arquitetura que permite interoperabilidade entre diferentes fornecedores de software e dispositivos heterogneos, um modelo que permite a usurios construir aplicaes de controle e a capacidade de programar uma aplicao quando ela est em execuo. O principal objetivo que os desenvolvedores venham a ter um framework aberto para desenvolver aplicaes de software que permita alm do funcionamento perfeito de sistemas e dispositivos heterogneos de diferentes fornecedores, a compatibilidade da aplicao com a Internet. 2.3.3 O Projeto EMBASSI EMBASSI (EMBASSI, 2004) um projeto financiado pelo Ministrio da Educao e Pesquisa Alemo integrado por universidades e empresas com o objetivo de desenvolver novos paradigmas e arquiteturas para interao intuitiva com dispositivos eletrnicos presentes em ambientes tais como automveis, residncias, terminais pblicos, etc. O objetivo principal pesquisar novos mtodos para interao homemmquina, especialmente no que se refere sistemas distribudos. As duas principais mudanas de paradigmas que esto envolvidas neste projeto so a transio da interao com dispositivo orientada a funo para interao com o sistema orientada a objetivo e a transio das estruturas de dilogo unimodal, com vocabulrio fornecido pelo sistema, para interao multimodal, com um vocabulrio de interao ilimitado fornecido pelo usurio, ou seja, desenvolver tcnicas de projeto de sistemas cujo foco esteja no usurio. Assim o projeto busca desenvolver uma arquitetura que fornea assistncia inteligente, interao multmodo e interfaces antropomrficas dentro de um framework padro. Para isto foi especificada uma camada capaz de estender um padro de hardware existente, desenvolvido dentro do conceito de orientado a funo, para o de centrado no usurio, com a interao baseada no objetivo a ser atingido e utilizando tcnicas de Inteligncia Artificial para aquisio de conhecimento sobre estes sistemas. Esta camada tem por finalidade linearizar a interao com os sistemas fsicos, interagindo com o usurio atravs de comandos naturais ou intuitivos e evitando que ele tenha que aprender em termos de funcionalidade dos dispositivos. A arquitetura - vide Figura 2.7, pode ser dividida em trs grandes nveis: interao multimodal: responsvel pelo estabelecimento dos objetivos a partir da interao com o usurio; assistncia: responsvel pelo estabelecimento e acompanhamento dos planos traados com objetivo de atingir a meta estabelecida no nvel anterior; efeito: responsvel por controlar os dispositivos fsicos que interagem sobre o ambiente. Cada nvel consiste de um nmero de processos (componentes) que podem ser adicionados ou removidos dinamicamente e que cooperam coletivamente para implementar a funo do nvel, o que permite, por exemplo, selecionar componentes para construir sistemas especficos.

35

O componente de gerenciamento de contexto responsvel pelo gerenciamento da viso do sistema sobre o mundo (informaes sobre o usurio, recursos e ambiente) e pelo controle dos componentes do framework. Diversas funes intermedirias foram definidas neste caminho. Primeiro, a interao com dispositivos fsicos de entrada (componentes I - Input) transformada em eventos de interao atmicos (lexical level), os quais so os menores blocos a partir dos quais as interaes compostas podem ser construdas.

Figura 2.7 : Arquitetura EMBASSI (EMBASSI, 2004). A seguir eles so enviados a componentes F (Filters) responsveis por agregar estes eventos em sentenas amodais. Estas sentenas so recebidas por componentes D (Dialogue Manager) os quais so responsveis por transform-las em objetivos e tambm pelo relacionamento entre as diferentes sentenas recebidas. O processo reverso ocorre quando uma sada para o usurio for produzida. Na prxima etapa ocorre o mapeamento do objetivo em alterao no ambiente. O primeiro componente desta fase, o componente A (Assistant) estabelece estratgias, denominadas planos, que visam alcanar-se o objetivo recebido. No existe uma maneira pr-definida para estabelecer um plano, cada componente pode usar uma estratgia diferente. Os planos resultantes so enviados aos componentes X (eXecution Control) que sero responsveis por garantir a seqncia correta dos passos do plano, pela execuo paralela de mltiplos planos e pelo gerenciamento da execuo de recurso necessrios para o plano. Finalmente as requisies individuais so enviadas para dispositivos abstratos, os componentes G, que controlam os dispositivos fsicos, os quais mudam o estado do ambiente e provocam o efeito requerido pelo usurio. Considerando a dinamicidade do sistema, novos componentes e novos objetivos podem ser inseridos a qualquer momento e novos comandos devem poder ser inseridos dinamicamente na meta linguagem que representa os objetivos. O componente Generator responsvel por interpretar as definies da metalinguagem para

36

especificao das funes e objetivos e pela atualizao de componentes A e D afetados pela linguagem. Diferentes tcnicas, protocolos e linguagens so utilizados na representao e construo dos componentes. Detalhes podem ser encontrados em (EMBASSI, 2004). 2.3.4 Consideraes Finais sobre Frameworks A plataforma OSGI concebida para permitir a conexo de dispositivos de diferentes padres num gateway residencial, com o objetivo de permitir que diferentes provedores forneam servios aos usurios que executem nesses dispositivos. O foco do desenvolvimento para conexo de sistemas externos com sistemas internos, buscando criar uma infraestrutura de suporte a provedores de servios para aplicaes tais como monitorao, udio e vdeo sob demanda, entre outros. O grupo de empresas associadas, fortemente vinculado rea de Telecomunicaes, deixa evidente este objetivo. A partir do material disponvel para estudo, pode-se concluir que o Niagara conceitualmente comporta-se como um midleware baseado em Java. Diferentes protocolos so mapeados para uma estrutura comum, sobre a qual podem ser realizados processamentos e os resultados so convertidos novamente na estrutura padro da tecnologia. Parte desta estrutura deve corresponder ao padro BAJA, porm durante a escrita deste trabalho ainda no estava disponvel a sua especificao. O projeto EMBASSI por sua vez busca atacar o problema de Interface Homem Mquina, onde mquina num sentido mais amplo representa o sistema como um todo. Neste projeto o sistema no mais visto como um conjunto de funcionalidades que devem ser manuseadas pelo usurio para atingir o seu objetivo. A proposta passar para o framework a definio das funcionalidades e dispositivos que sero ativados para atingir uma meta estabelecida pelo usurio, poupando-o da tarefa de realizar o controle do sistema. Este framework deve incorporar sistemas de IA a fim de superar a limitao de recursos da maioria dos dispositivos e sistemas disponveis atualmente. Outra questo sob o foco do projeto e o estudo de interfaces naturais de interao com o usurio.

2.4 Metodologias de Projeto Baseada em Vises

A crescente complexidade dos atuais sistemas de automao predial impe a necessidade de subdividi-los a fim de conseguir-se capturar corretamente os seus requisitos e implement-los de forma eficiente. Ao mesmo tempo, a existncia de diversos protocolos e de diferentes frameworks e midlewares, aponta para a necessidade de desenvolvimento de sistemas abertos que permitam a interoperabilidade entre diferentes equipamentos e sistemas, independente da tecnologia de comunicao que eles implementam. Esta seo tem por objetivo tratar dessas duas questes no que se refere ao desenvolvimento de Sistemas de Automao Predial e analisar alguns trabalhos que se enquadram nesses conceitos. 2.4.1 O Conceito de Viso Uma abordagem usual no desenvolvimento de software, cujo objetivo simplificar a anlise e o desenvolvimento de sistemas complexos, dividi-lo em camadas. Partindo-se da especificao de requisitos inicial, cada camada subseqente representa perspectiva menos abstrata do sistema.

37

Esta multiplicidade de perspectivas no projeto de software suportada pelo conceito de ponto de vista ou viso (viewpoint) (SOMMERVILLE, 1997). Um ponto de vista o encapsulamento de informaes parciais sobre as requisies de um sistema e a integrao de diferentes vises compe a especificao final do mesmo. Dentre as vantagens dessa abordagem, destacam-se: pontos de vista podem ser utilizados para colecionar e classificar os diferentes tipos de informaes necessrias para a especificao, tais como informao sobre o domnio da aplicao, sobre ambiente e sobre desenvolvimento do sistema; pontos de vista podem ser utilizados para encapsular modelos diferentes do sistema onde cada um fornece uma parte da especificao. Este conceito utilizado, por exemplo, em (DOUGLASS, 2003), na abordagem de padres de projeto para sistemas de tempo real. Douglass propem cinco vises para a diviso da arquitetura fsica de um sistema de tempo real: subsistemas, distribuio, concorrncia, tolerncia falhas e mapeamento fsico. Outros exemplos de vises j bastante usuais no desenvolvimento de sistemas de informao so os de segurana, de marketing, de base de dados e de rede, entre tantos possveis. 2.4.2 O modelo de Referncia para Processamento Distribudo Aberto O RM-ODP (Reference Model for Open Distributed Processing) vide (ISO/IEC, 1995), o resultado de um trabalho conjunto da ISO/ITU para estabelecer um framework de desenvolvimento de sistemas distribudos heterogneos de grande escala em ambiente multiplataforma, baseado no conceito de vises. Ele define cinco vises para representao de um sistema distribudo aberto: a viso de empresa, a viso de informao, a viso de computao, a viso de engenharia e a viso de tecnologia. Viso de empresa: O objetivo principal desta viso especificar os objetivos e as restries do sistema de interesse. Para isto ele representado por um ou mais objetos dentro de uma comunidade de objetos que representam a empresa e pelas funes (roles) nas quais estes objetos esto envolvidos. Estas funes representam, por exemplo, usurios, proprietrios, fontes de informao processadas pelo sistema, etc. Algumas definies importantes desta viso so: Polticas: conjunto de regras associadas com um determinado propsito. Polticas registram regras na qual aes de um objeto so permitidas ou proibidas e tambm que aes os objetos so obrigado executar; Obrigao: a prescrio de que um determinado comportamento requerido. Uma obrigao executada pela ocorrncia do comportamento prescrito; Permisso: a prescrio de que um determinado comportamento permitido que ocorra; Proibio: a prescrio de que um determinado comportamento no deve ocorrer. A idia principal desta viso a de um contrato, ligando os objetos realizadores de diferentes funes e expressando suas obrigaes mtuas. Viso de informao: Esta viso contm os conceitos para permitir a especificao da semntica da informao manipulada e armazenada em um sistema de processamento distribudo

38

aberto. A especificao da informao consiste de um conjunto de esquemas os quais esto relacionados com os dados que necessitam ser armazenados e processados. Viso de Computao: O sistema descrito como um conjunto de objetos que interagem atravs de suas interfaces. A interao entre os objetos definida como assncrona e classificada em: Sinal: interao atmica elementar; Operao: similar a procedimentos (procedures) que so invocadas atravs de interfaces. classificada em interrogao quando h retorno de resposta e anncio quando no espera resposta; Fluxo: seqncia contnua de dados entre interfaces. Tambm est definido que a interao entre interfaces somente possvel se for estabelecida uma conexo (binding) explcita entre elas (Operaes permitem binding implcito) e que um objeto pode estar envolvido simultaneamente em diversas conexes. Viso de Engenharia Relacionada aos mecanismos de suporte de distribuio do sistema. Define a estrutura computacional que suporta a estrutura definida na viso anterior, promovendo os diversos nveis necessrios para suporte distribuio, ou seja, como a distribuio alcanada e quais recursos necessrios para isto, definindo regras para estruturar canais de comunicao entre os objetos e estruturar os sistemas visando o gerenciamento de recursos. Cada objeto computacional deve corresponder a pelo menos um objeto de engenharia, podendo corresponder a mais de um em caso de replicao. Estes objetos podem ser agrupados em clusters, cpsulas e ns. Objetos so agrupados em clusters a fim de reduzir o custo de interao e o custo de manipulao entre eles. As cpsulas geralmente correspondem menor unidade de Sistema Operacional (ex . todos os objetos da cpsula correspondem a um nico processo). Os objetos de engenharia so conectados atravs de canais. Viso de Tecnologia Esta viso est associada aos detalhes dos componentes construtivos do sistema (escolha da tecnologia de hardware e software para composio do sistema). O modelo tambm define as seguintes funes: Funo de gerenciamento do n: realiza tarefas de gerenciamento de threads, escalonamento, etc; Funo de gerenciamento da cpsula/cluster: responsvel pela criao, desativao, reativao e recuperao desses objetos; Funo de replicao: responsvel pela replicao de objetos e pela consistncia das rplicas; Funo de transao: define as aes de interesse, verifica as consistncias, estabelece as dependncias e verifica a recuperao de falhas; Funo de segurana: responsvel pelos servios de segurana, controle de acesso, fiscalizao aplicados a objetos e interaes entre eles. Finalmente define que num sistema distribudo deve existir transparncia quanto a acesso, persistncia, localizao, relocao, migrao e falha.

39

2.4.3 Alguns Trabalhos que Utilizam o Conceito de Vises e o RM-ODP Alguns trabalhos que utilizam os conceitos de vises e o RM-ODP em diferentes contextos podem ser encontrados em (GOEDICKE, 1999), (KAND, 1998), (BASTIDAS, 2003) e (BASTIDAS, 2004). Goedicke, em (GOEDICKE, 1999), prope uma ferramenta que suporte o desenvolvimento de software orientado a vises com o objetivo de verificar a consistncia dentro de cada viso e entre as vises durante o processo de especificao. Para isto cada viso dividida em slots que representam diferentes perspectivas da mesma. Os slots definem os esquemas e a notaes para representar a viso, sua rea de domnio, a prpria especificao da viso de acordo com a notao definida, as aes que ela executa (workplans). Dois slots so responsveis por verificar a consistncia dentro as diferentes vises e dentro de uma determinada viso. O foco desse trabalho e fornecer uma metodologia que detecte inconsistncias, usando um mecanismo formal de transformaes grficas a partir da manipulao dos esquemas definidos nos slots. Kand (KAND, 1998) apresenta uma proposta para modelar as vises do RM-ODP usando UML, apontando os diagramas que podem ser usados para modelar cada viso. A proposta desenvolvida a partir em um estudo de caso, a implementao de um sistema de telecomunicaes e a especificao (viso de empresa) realizada com o foco numa soluo para este sistema. O ponto de partida a definio dos domnios da aplicao e a modelagem baseada nesses domnios. A viso de computao expande os diagramas de classe UML definidos na viso de informao com foco na definio das interfaces entre as classes. Diagramas de seqncia e de interao UML complementam esta viso com o objetivo de representar a interaes entre os objetos do sistema. Na viso de engenharia so usados os diagramas de componentes e os deployments e para representar o mapeamento tecnolgico ele prope o uso texto plano. Batisdas (2003; 2004) aborda a utilizao do RM-ODP para a especificao de sistemas abertos, UML para represent-los e redes de Petri para assegurar a coerncia formal entre as diferentes fases de especificao, usadas para modelar a dinmica do sistema. Embora os trabalhos enfatizem a aplicao de uma metodologia para modelar sistemas de automao predial, os estudos de casos so realizados usando-se apenas um subsistema de controle de incndios, no fazendo consideraes sobre a generalizao para outros subsistemas. Em Bastidas (2004) no existe a preocupao de relacionar os diagramas UML com vises especificas do RM-ODP. A definio e construo dos diagramas de classe , genericamente, tratada como um atividade relacionada com os pontos de vista de informao e computao, sendo o comportamento dos objetos especificados atravs de redes de Petri. O trabalho no aborda a representao das interaes entre os objetos e em ambos os trabalhos a anlise pra na viso computacional: a representao da implementao ainda no est resolvida.

40

3 PROPOSTA DE FRAMEWORK
Neste captulo definida a proposta de framework orientado a objetos para o desenvolvimento de projetos de sistemas de automao predial, tema da presente dissertao de mestrado. Para especificao deste framework ser utilizado a Unified Modeling Language (UML) (OMG, 2003). Embora existam outras opes para representao, tais como blocos funcionais (CHRISTENSEN, 2004), escolheu-se a UML por ser esta um padro j consolidado (durante a escrita deste texto encontra-se na verso 1.5) e largamente utilizado, ter ampla bibliografia disponvel e tambm pela experincia do grupo de pesquisa no qual este trabalho foi desenvolvido.

3.1 Introduo
Segundo (GAMMA, 2000) um framework um conjunto de classes cooperantes que constroem um projeto reutilizvel para uma especfica classe de software que possui as seguintes caractersticas: dita a arquitetura da aplicao; define a diviso em classes e objetos e define as responsabilidades chaves das classes e objetos: como elas colaboram, os fluxos de controle, etc. Ele reduz as decises de projeto, pois as aplicaes passam a ter estruturas similares, permitindo construir solues mais rapidamente. O projetista aposta que a arquitetura especificada funcionar para todas as aplicaes do domnio, sendo exatamente esta arquitetura a principal contribuio de um framework. Neste trabalho objetiva-se, a partir da descrio funcional de um sistema de automao predial, selecionar dentre os objetos especificados no framework proposto, aqueles que melhor representem as funcionalidades requeridas por uma dada aplicao e conect-los de forma a atender a especificao funcional da mesma. Esta etapa denominada projeto lgico e independente da tecnologia que ser utilizada para implementao do sistema, uma vez que o mapeamento tecnolgico somente ir ocorrer na etapa final do projeto, aps a concluso do projeto lgico. Os objetos utilizados no projeto lgico so denominados, no mbito deste trabalho, dispositivos lgicos. O mapeamento tecnolgico corresponde a agrupar os dispositivos lgicos especificados no projeto lgico de maneira conveniente, conforme funcionalidades oferecidas pelos dispositivos fsicos disponveis. A Figura 3.1 representa, de forma simplificada, as etapas principais de projeto propostas.

41

Figura 3.1 : Etapas de projeto A metodologia de projeto proposta neste trabalho baseada no conceito de vises, porm usa para definio das vises do RM-ODP, descrito no captulo anterior, por ser um padro estabelecido por um rgo de padronizao internacional. Ao longo desse captulo o sistema de automao predial ser dividido em camadas de acordo com os conceitos definidos no modelo de referncia.

3.2 Construo do Framework

O ponto de partida para realizao do framework proposto neste trabalho foi a anlise do modelo de objetos dos diversos padres abertos disponveis para implementao de sistemas de automao predial descritos no captulo anterior. Esta anlise buscou identificar conceitos comuns entre diferentes padres, a fim de identificar um conjunto mnimo de objetos que pudessem ser mapeados para as diferentes tecnologias disponveis. Esta anlise foi importante na definio da hierarquia de classes do modelo, a qual dever permitir representar as informaes de um sistema de automao predial, etapa correspondente viso de informao no RM-ODP e que ser detalhada posteriormente neste captulo. Ao mesmo tempo fez-se tambm uma anlise bottom-up dos sistemas de automao predial, buscando identificar requisitos e comportamentos tpicos desses sistemas. O restante do captulo define uma proposta de framework, construdo a partir dessas duas abordagens, seguindo as definio do RM-ODP. 3.2.1 Definio das Funcionalidades Tendo como referncia o RM-ODP, a primeira viso (camada) do projeto de um sistema tem por finalidade especificar os objetivos e as restries do sistema de interesse. Um sistema de automao predial tem por objetivo controlar as diferentes funcionalidades do ambiente sobre controle. Algumas funcionalidades tpicas de uma instalao predial so: Manter a temperatura, a umidade e qualidade do ar em valores prdeterminados. Estas funcionalidades podem ser refinadas posteriormente de acordo com as condies ambientais em aquecer, esfriar, ventilar, exaurir, desumidificar, umidificar, etc; Manter a luminosidade em valores pr-estabelecidos, o que pode resultar em aumentar e diminuir a luminosidade conforme as condies ambientes

42

Controlar acesso que pode ser refinado em identificar e autenticar o usurio, autorizar ou negar o acesso, etc; Identificar acessos no autorizados que poder ser refinado em detectar e comunicar intruso; Controlar Fogo que pode ser refinado em detectar, comunicar e controlar fogo: controlar portas corta fogo, controlar sprinkler, controlar dumpers, etc; Controlar interao entre ambientes que pode ser refinado em abrir e fechar cortinas, janelas, brises, portas, portes, etc. As funcionalidades do mesmo tipo so usualmente agrupadas formando subsistemas. Na definio de cada subsistema faz-se necessrio identificar quais so as variveis que o compem e quais estaro relacionadas com cada funcionalidade do subsistema. A estratgia que ser utilizada no controle importante na definio das variveis de interesse do controle e tambm para a definio do tipo de dados que ser utilizado para represent-las. A Figura 3.2 ilustra a estruturao funcional de um subsistema Y para controle de um determinado ambiente X.

Figura 3.2 : Estruturao funcional de um subsistema. Suponha-se que a definio dos requisitos especificasse a necessidade de manter a temperatura em um valor predeterminado e que a anlise das condies locais identificasse a necessidade de resfriar o ambiente, pois a temperatura externa sempre superior a temperatura determinada para o mesmo. E que, adicionalmente, tivesse sido definido como estratgia de controle que se o ambiente estivesse desocupado ou abaixo de uma determinada temperatura o sistema de resfriamento devesse ser desligado. A partir desses requisitos identifica-se, neste exemplo, as seguintes funcionalidades: resfriar (representada pela funcionalidade A), controlar a temperatura interna (representada pela funcionalidade 1), controlar a temperatura externa (representada pela funcionalidade 2) e controlar a ocupao do ambiente (representada pela funcionalidade 3), estas ltimas definidas em funo das variveis de interesse temperatura interna, temperatura externa e ocupao, necessrias para implementar a estratgia de controle definida. Numa anlise inicial identifica-se que as diferentes variveis envolvidas no processo podem ser classificadas em trs grupos distintos: variveis de processos: temperatura, umidade, luminosidade, ocupao, rudo, qualidade do ar, consumo de energia (eletricidade, gs, gua quente/fria), presena de gases (fumaa, CO2, etc), indicao de vazamentos (gua, gs, etc), identificao de defeitos em equipamentos, faltas (gua, gs, eletricidade, etc), entre outras; variveis temporais: data, horrio, intervalos, temporizaes (retardos - delays/ temporizaes - timers), etc; variveis relativas a interfaces com usurios: identificadores, mensagens de autenticao, notificaes e configuraes, comandos, entre outras.

43

Estas variveis possuem atributos especficos conforme o seu tipo (resoluo, faixa de valores, etc) e diferentes funcionalidade podem estar associadas a uma varivel, de acordo com a estratgia de controle a ser implementada para o ambiente. Assim, por exemplo, a deteco de que um ambiente passou do estado desocupado para ocupado, atravs da mudana do valor de uma varivel que esteja associada ocupao do ambiente, pode dar incio a diferentes aes no que se refere ao controle de luminosidade, temperatura e controle de acesso/intruso no ambiente. Cada subsistema corresponde a um domnio com funes de controle especficas e desejvel que eles interajam entre si a fim de atingir plenamente seus objetivos. A Figura 3.3 apresenta os subsistemas que foram definidos no escopo deste trabalho e especifica as interaes que ocorrem entre eles.

Figura 3.3 : Definio dos Subsistemas As principais funcionalidades de cada um desses subsistemas so: Supervisrio (supervisory): responsvel pelos mecanismos de interao com os usurios (login, autenticao, notificaes, etc.) e pela armazenagem e recuperao de dados (configuraes, eventos, alarmes); Controle de Iluminao (lighting): deve permitir o controle de iluminao no ambiente em diferentes condies de uso; Controle de HVAC (HVAC): deve permitir o controle da temperatura, da umidade e da ventilao do ambiente, conforme condies pr-estabelecidas; Controle de Acessos (Acess): responsvel pela identificao e autenticao do usurio, permitindo ou no o acesso a reas restritas; Controle de Intruses (intrusion): responsvel pela identificao de acesso no autorizado a ambientes e equipamentos; Controle de Venezianas (Blind): responsvel pela da manipulao de cortinas, persianas, brises, portes, etc. Controle de Incndio (Fire): responsvel por manter o controle a condies ambientais que causem ameaa a segurana de pessoas e instalaes, relativamente a controle de gases perigosos e, especialmente, fogo. Outros domnios tpicos que no foram modelados neste trabalho so o de Entretenimento, o Gerenciamento de Energia, o de Controle de Servios e o de Movimentao. Este procedimento foi adotado tendo em vista que durante a realizao dos estudos preliminares para definio do framework constatar-se que eles podem ser refinados usando-se os mesmos conceitos adotados para os demais subsistemas.

44

Para cada subsistema foi determinado um conjunto de funcionalidades tpicas. A Figura 3.4 apresenta o diagrama UML de caso de uso que representa as funcionalidades do subsistema HVAC. Para os demais subsistemas os diagramas de caso de uso podero ser encontrados no Anexo A.
Heater Cooler Fan Exhauster Drier Sprinkler

Heat

Cool uses

Fan uses uses

Exhaust uses

Dehumid uses uses

Humid

ControlSensors HVACSensors

uses

ControlHVAC

uses

uses

ControlExtSensors ExternalSensors

uses

ControlScene

Figura 3.4 : Funcionalidades do subsistema de HVAC Nesta figura pode-se observar que para este subsistema foram definidas funcionalidades de aquecer (Heat), resfriar (Cool), ventilar(Fan/Exhaust) e aumentar e diminuir a umidade (Humid/Dehumid). Algumas variveis, tais como temperatura e umidade, esto relacionadas diretamente com a funo de controle (ControlHVAC) e esto sendo representadas pelo ator HVACSensors enquanto outras, tais como as associadas data, horrio ou ocupao do ambiente, definem condies funcionamento (ControlScene) para o subsistema e esto sendo representadas pelo ator ExternalSensors. As setas na Figura 3.3 indicam a interao entre os subsistemas. A seguir sero descritas as principais finalidades destas interaes: Controle de Acessos x Controle de Iluminao: possibilita que o subsistema de controle de iluminao responda a eventos do controle de acessos, possibilitando o nvel de iluminao adequado apenas nos ambientes cujo acesso foi autorizado. Permite ainda a personalizao dos parmetros de iluminao, conforme identificao do usurio; Controle de Acessos x Controle de HVAC: possibilita que o subsistema de controle de HVAC responda a eventos do controle de acessos, possibilitando o nvel de temperatura e umidade adequado apenas aos ambientes cujo acesso foi autorizado. Permite ainda a personalizao desses parmetros, conforme identificao do usurio; Controle de Acessos x Controle de Intruso: possibilita que o subsistema de controle de intruso seja desativado em reas cujo acesso tenha sido autorizado pelo controle de acessos; Controle de Iluminao x Controle de Venezianas: esta interao possibilita que estes subsistemas cooperem a fim de ajustar o nvel de iluminao externa ao nvel especificado para o ambiente; Controle de HVAC x Controle de Venezianas: esta interao possibilita que estes subsistemas cooperem a fim de ajustar os nveis de temperatura e de umidade levando em conta parmetros externos ao ambiente sob controle;

45

Controle de Intruso x Controle de Iluminao: permite que o subsistema de controle de iluminao responda a eventos do subsistema de controle de intruses, garantindo nvel adequado de iluminao de acordo com a especificao, em ambientes cuja intruso tenha sido detectado; Controle de Intruses x Controle de Venezianas: esta interao possibilita que estes subsistemas cooperem a fim de detectar intruses e realizar isolamentos do ambiente controlado do ambiente externo, conforme a especificao de requisitos do projeto; Controle de Intruses x Controle de Acessos: esta interao possibilita realizar isolamentos do ambiente controlado do ambiente externo, em caso de deteco de intruso; Controle de Incndios x Controle de Acessos: esta interao possibilita realizar isolamentos do ambiente controlado, bem como liberar sadas de emergncia; Controle de Incndios x Controle de Intruso: esta interao permite liberar acessos das zonas onde tenha sido detectado incndio, conforme especificao; Controle de Incndios x Controle de HVAC: esta interao possibilita o controle da refrigerao e da ventilao, em caso de deteco de fogo, conforme especificao da instalao; Controle de Incndios x Controle de Iluminao: esta interao possibilita realizar o controle da iluminao de emergncia, da iluminao de acessos e das indicaes de sadas, entre outros, em caso de deteco de fogo. A especificao dos requisitos de um sistema do sistema de automao predial, com as definies das condies de funcionamento e a parametrizao das suas variveis, realizada na fase de especificao da instalao. A partir dessa caracterizao pode-se definir quais subsistemas do framework sero utilizados, selecionar quais funcionalidades de cada subsistema so necessrias para atender a especificao e definir as parametrizaes e as estratgias de controle de cada funcionalidade. Por exemplo uma funcionalidade especificada como manter a temperatura 0 em 22 C, ser refinada de maneiras diferentes, conforme a temperatura ambiente tpica do local onde o sistema ser implantado. Se a temperatura ambiente for sempre acima da especificada dever ser modelada como a funcionalidade resfriar, caso contrrio aquecer e ainda se ela variar acima e abaixo desse valor tero que ser modeladas as duas funcionalidades. A definio de outras funcionalidades que sero necessrias para atender esta funcionalidade ir depender das estratgias de controle ou condies de funcionamento especificadas. Assim, por exemplo, nesse refinamento pode-se ainda acrescentar funcionalidades tais como verificar a ocupao do ambiente, o dia da semana ou o horrio para atender s especificaes de controle. 3.2.2 Definio do Meta-modelo Definidos os subsistemas, suas funcionalidades e a interao entre eles, fazse necessrio definir os conceitos e as estruturas que sero usadas para manipular e armazenar as informaes do sistema de automao predial. Esta camada do framework, focada no significado da informao, corresponde viso de informao no RM-ODP. O conceito principal adotado no framework para representar as informaes o de dispositivo lgico (LogicalDevice). Um dispositivo lgico corresponde a um componente que representa uma funcionalidade lgica, possuindo atributos tpicos dessa funcionalidade, independente de como ele ser implementado posteriormente.

46

Todo o sistema pode ser representado como um conjunto de dispositivos lgicos conectados logicamente entre si a fim de permitir a interao entre eles. A Figura 3.5 ilustra dispositivos lgicos conectados entre si a fim de modelar um controle de temperatura e um controle de luminosidade. As conexes dependem da estratgia de controle que ser implementada para o ambiente. Eles esto sendo representados por figuras geomtricas diferentes apenas para efeito visual

Figura 3.5 : Representao utilizando Dispositivos Lgicos A raiz do modelo, conforme pode ser observado na Figura 3.6, so as classes LogicalDevice, Subsystem e SimpleDevice. Elas implementam o padro de projeto Composite (Gamma, 2000), o qual permite compor objetos em estruturas de hierrquicas. Dessa forma, um dispositivo lgico (LogicalDevice) pode ser especializado como subsistema (Subsystem), recursivamente, at que a uma folha da rvore seja especializada como um SimpleDevice.

Figura 3.6 : Viso inicial do modelo A seleo dos atributos e mtodos teve como base a definio dos atributos e mtodos dos protocolos estudados. Uma descrio detalhada dos mtodos e atributos que foram definidos para cada classe encontra-se nas tabelas do Anexo A. Os tipos bsicos (decimal, list, string, boolean, etc.) utilizados na especificao dos atributos das classes utiliza a definio de tipos definidos para XML (W3C, 2001) por ser independente de linguagem de programao. Um SimpleDevice pode ser composto por um ou mais canais, os quais permitem representar as conexes lgicas citadas anteriormente. Esta classe especializada a fim de permitir a representao das diferentes funcionalidades de um sistema de automao predial. A hierarquia de classes foi construda a partir

47

identificao dos objetos comuns entre os diferentes protocolos estudados e da anlise das variveis citadas anteriormente neste captulo. Conforme pode ser observado na Figura 3.7, a classe SimpleDevice foi especializada nas classes ProcessInterface, Controller, UserInterface, ComunicationInterface e Persistent, cada uma com objetivo de permitir a representao de um conjunto de funcionalidades tpicas da aplicao.

Figura 3.7 : Especializao da classe SimpleDevice. A classe ProcessInterface representa as variveis do processo fsico. Em conformidade com a Figura 1.1, ela foi especializada nas classes Sensor, responsvel pela representao das variveis controladas do processo e Actuator, que permite representar as variveis de atuao do processo. A classe Sensor foi especializada em BinarySensor, AnalogSensor e MultistateSensor e a classe Actuator em BinaryActuator, AnalogActuator e MultistateActuator. A classe Binary (Sensor ou Actuator) tem por finalidade permitir a representao de variveis que possuam apenas dois estados possveis, a classe Analog (Sensor ou Actuator) permite a representao de variveis que possuam um conjunto finito de valores, dados um determinado intervalo e uma resoluo e a classe Multistate (Sensor ou Actuator) possibilita representar o estado atual de uma varivel de mltiplos estados. A classe Controller destina-se a representar as funes de controle de processos, podendo ser especializada em classes que representam diferentes estratgias de controle. A classe Persistent objetiva modelar dados persistentes no sistema. Estes dados podem ser informaes para autenticao de usurios (login e senhas, entre outros), musicas, vdeos, etc, os quais poderiam estar armazenados em um arquivo em mdia, memria ou qualquer meio que garanta a persistncia da informao.

48

A classe UserInterface tem por finalidade permitir modelar a interao com os usurios do sistema. Teclados, displays e monitores so especializaes tpicas dessa classe. A fronteira entre as classes ProcessInterface e UserInterface no bem definida, pois se pode considerar, por exemplo, o interruptor de um sistema de iluminao como sendo uma interface com o usurio ou com o processo. No modelo proposto procura-se reservar o conceito de interface com o usurio para representar entradas/sadas de dados de mais alto nvel, embora na etapa de mapeamento tecnolgico, possa-se optar por implementar esta interface por um dispositivo menos complexo, tpico da classe ProcessInterface. Finalmente a ltima classe, CommunicationInterface, tem por objetivo representar componentes do subsistema de comunicao. Esta classe acabou sendo pouco explorada no desenvolvimento do trabalho pois toda a infraestrutura de comunicao tratada como uma camada, um middleware, o que permite considerar toda a conexo de comunicao entre dispositivos lgicos como sendo ponto a ponto. Esta simplificao foi adotada uma vez que a questo do projeto de redes que um problema bastante complexo e est fora do escopo deste trabalho. Outra caracterstica que necessita ser representada o comportamento discreto sistema, ou seja, especificar as aes que devem ser executadas quando da ocorrncia de determinados eventos. Para esta representao foi adotado o conceito de cenrio, que definido pela UML (OMG, 2003) como sendo uma seqncia especfica de aes que ilustra um comportamento. Este conceito tambm utilizado por algumas tecnologias analisadas, principalmente associado execuo de diferentes aes pelos subsistemas de iluminao. Petriu (PETRIU, 2003) define cenrio como uma seqncia de passos que pode incluir caminhos alternativos, caminhos paralelos, laos e refinamentos de um passo por um subcenrio. Na sua viso, os cenrios podem ser modelados ou por diagramas de interao ou por diagramas de atividade e apresenta as vantagens e as desvantagens de cada diagrama. Neste trabalho faz-se ampla utilizao deste conceito para representar o comportamento discreto em todos os subsistemas: um cenrio define os procedimentos que devam ser executados conforme a ocorrncia de determinadas pr-condies, Conforme pode ser observado na Figura 3.8 foram definidas as classes Scene, Precondition e Procedure. A classe Precondition permite representar as prcondies e est associada classe LogicalDevice pois estas podem corresponder ao estado de um subsistema (Subsystem) ou de qualquer especializao da classe SimpleDevice. Alm disso, associadas a ela tambm esto as classes Calendar e Clock, as quais permitem representar pr-condies dependentes do tempo, relativas a calendrio e a passagem do tempo. A classe Procedure est associada com SimpleDevice e indica estado desejado do dispositivo ao qual est associada. Um cenrio, representado pela classe Scene, associa pr-condies (Precondition) a procedimentos (Procedure). Para representar o comportamento expresso pelos cenrios foram adotadas regras de produo que consistem basicamente em um conjunto de condies no estilo SE <pr-condio> ENTO <ao>, com a possibilidade de incluso de conectivos lgicos relacionando os atributos. Podem ser usados operadores lgicos (E, OU e NEGAO), operadores relacionais (maior, maior igual, menor, menor igual, igual e diferente), operadores

49

aritmticos (soma , subtrao diviso, multiplicao) e funes temporais ([durao x unidades de tempo] e Esperar [x unidades de tempo]).

Figura 3.8 : Modelagem dos Cenrios As funes temporais permitem representar temporizaes na construo dos procedimentos. A primeira, utilizada aps a especificao de uma ao, representa o tempo de durao da mesma e a segunda corresponde a uma ao, representando um tempo de espera antes ou depois de uma outra ao. Os parnteses devem ser usados para determinar a prioridade da avaliao das sentenas e o ponto e vrgula utilizado nos procedimentos como separador de uma cadeia de aes. A Figura 3.9 exemplifica a utilizao da sintaxe para representao de comportamentos num sistema.

Figura 3.9 : Exemplos de utilizao da sintaxe As regras de produo so um mecanismo utilizado para a construo de sistemas especialistas em inteligncia artificial e a sintaxe definida mostrou-se suficiente na realizao dos estudos de caso realizados ao longo deste trabalho. Uma questo importante a resoluo de conflitos entre cenrios. Um caso tpico o conflito entre comandos automticos e manuais, quando o sistema define pela execuo de um procedimento e o usurio outro, em conflito com o primeiro. Para o tratamento deste problema foi adotado o conceito de prioridades definido pelo protocolo BACnet para priorizao de mensagens (Erro! A origem da referncia no foi encontrada., 2003).

50

Foram definidos 5 nveis de prioridades, conforme a finalidade do cenrio, as quais podem ter at 10 subnveis de prioridade (de 0 a 9). A composio do nvel mais o subnvel dar origem a um nmero inteiro. Quanto maior o valor do nmero, maior a prioridade do cenrio. Os nveis definidos foram nvel 1: conforto (Iluminao, HVAC, cortinas, supervisrio, etc.); nvel 2: gerenciamento de Energia; nvel 3: controle de Acesso; nvel 4: controle de Intruses; nvel 5: controle de Incndios. Esta estratgia resolve o problema de resoluo de conflitos entre os subsistemas. Dentro de um mesmo subsistema o projetista define, em tempo de projeto, nveis de prioridades diferentes sempre que houver conflito de aes. A viso conjunta do diagrama de classes pode ser encontrada no Anexo A. 3.2.3 Definio dos Dispositivos Lgicos e de suas Interaes No RM-ODP, aps a definio dos objetivos e das restries (viso de empresa) e da especificao do significado da informao (viso de informao), na prxima viso o sistema deve ser descrito como um conjunto de objetos que interagem atravs de suas interfaces. Esta camada denominada viso de computao. Para atender esta definio, esta etapa de projeto do framework especifica os diferentes tipos de objetos que compem cada um dos subsistemas e como estes objetos interagem. Estes objetos que so denominados como objetos computacionais pelo modelo de referncia so denominados, no mbito deste trabalho dispositivos lgicos, uma vez que tem por objetivo representar logicamente as funcionalidades que devero ser implementadas pelo sistema A Figura 3.10 apresenta os dispositivos lgicos que foram definidos para o subsistema HVAC. Estes dispositivos foram definidos em funo das funcionalidades desse subsistema que se deseja representar e correspondem a instncias das classes definidas na etapa anterior. A fim de tornar os diagramas menores e mais fceis de serem compreendidos foi utilizado o conceito de stereotypes da UML para representar a classe de origem.
AnalogSensor

TempSensor

BinarySensor

OcupSensor

BinarySensor

Switch

AnalogSensor

HumSensor

MultistateSensor

SceneSelector

Sensor
+Read():

Scene
-Scene: list -priority: int +insertScene(scene) +removeScene(scene) +execute()

1..* 1 0..* 1 HVACSubsystem 1..* Actuator

+onValue(parameter:d +Off() +On()

HVACController 1 1..*
-mode: string +setMode(mode:string) +getMode(): string

Controller
-setpoint: decimal +deactivateControl() +runControll() +setSetpoint(setpoint:decimal) +getSetpoint(): decimal

Bin/AnalogActuator

HeatActuator

Bin/AnalogActuator

CoolActuator

Bin/AnalogActuator

HumidActuator

Bin/AnalogActuator

FanActuator

Bin/AnalogActuator

Bin/AnalogActuator

DehumidActuator

ExhaustActuator

Figura 3.10 : Dispositivos lgicos do subsistema HVAC

51

Como pode ser observado, o subsistema HVAC composto por dispositivos lgicos instanciados das classes Actuator e Sensor, o quais representam variveis de atuao e de entrada do processo e das classes Scene e Controller, que permitem representar o comportamento do subsistema, sendo que a primeira permite representar a estratgia para o comportamento em relao aos eventos discretos e a segunda em relao ao controle das variveis contnuas. As cardinalidade adotadas nas composies permitem a representao de sistemas com as mais diferentes complexidades. Para representar variveis de entrada foram instanciados os seguintes dispositivos lgicos: TempSensor: do tipo AnalogSensor com o objetivo de representar a temperatura; OcupSensor: do tipo BinSensor que permite representar se um determinado ambiente est ocupado ou no; Switch: do tipo BinarySensor que permite representar qualquer outra funcionalidade que s tenha dois estados; HumSensor: do tipo AnalogSensor que permite representar a varivel de entrada umidade; SceneSelector: do tipo MultistateSensor o qual permite a seleo de um cenrio especfico de um conjunto de cenrios relativos a HVAC. Para representar variveis de atuao os seguintes dispositivos lgicos foram instanciados: HeatActuator: o qual representa uma fonte de calor e pode ser do tipo BinaryActuator ou do tipo AnalogActuator, conforme a fonte apresente apenas dois estados (ligado/desligado) ou permita seleo de um valor intermedirio entre dois limites pr-estabelecidos (representado por 0 e 100%); CoolActuator: o qual representa uma fonte de frio e pode ser do tipo BinaryActuator ou do tipo AnalogActuator; HumidActuator: o qual representa uma fonte de umidade e tambm pode ser do tipo BinaryActuator ou do tipo AnalogActuator; DehumidActuator: o qual representa uma fonte capaz de retirar a umidade do ambiente. Pode ser do tipo BinaryActuator ou do tipo AnalogActuator; FanActuator: o qual representa uma fonte de ventilao e pode ser do tipo BinaryActuator ou do tipo AnalogActuator; ExhaustActuator: o qual representa uma fonte de ventilao e pode ser do tipo BinaryActuator ou do tipo AnalogActuator. O tipo do controlador (Controller) no foi especificado no modelo, embora possa se observar a especializao do controlador para atender ao controle das funcionalidades desse subsistema (HVACController) Nesta etapa tambm devem ser definidos o tipo e o sentido da conexo, relativamente ao sentido do fluxo de informao entre os objetos computacionais. Especializaes da classe Channel, permite representar os diferentes tipos de conexes previstas na definio do RM-ODP, conforme pode ser observado na Figura 3.11. Para modelar o fluxo de informao entre os dispositivos especificados para cada subsistema foi adotada uma representao similar aos diagramas de colaborao UML com o foco apenas no sentido da informao.

52

Figura 3.11 : Especializao da classe Channel. Esta simplificao foi necessria porque os diagramas UML que tem por objetivo representar a interao entre objetos (diagramas de colaborao e de seqncia) so focados na soluo do problema, no sendo genricos o suficiente para esta representao. Na Figura 3.12 pode ser observado o diagrama resultante da modelagem do subsistema HVAC.
Bin/AnalogActuator

HeatActuator

AnalogSensor

bin/levelOut humInput HVACController

-mode: string +setMode(mode:string) +getMode(): string

Bin/AnalogActuator

CoolActuator

HumSensor

bin/levelOut bin/levelOut bin/levelOut bin/levelOut bin/levelOut

Bin/AnalogActuator

HumidActuator

AnalogSensor

TempSensor

tempInput

Bin/AnalogActuator

DehumidActuator

BinarySensor

OcupSensor

setpoint ocupInput
Scene

Bin/AnalogActuator

FanActuator

BinarySensor

Switch

switchInput sceneInput

HVACScene

Bin/AnalogActuator

ExhaustActuator

MultistateSensor

SceneSelector

Figura 3.12 : Fluxo de informao no subsistema HVAC. O tipo da informao est relacionado com o atributo especificado na Classe Pai do dispositivo lgico. Assim, para a classe Analog(Sensor ou Actuator) a varivel que representa o valor atual (PresentValue) do tipo decimal (W3C, 2001), para a classe Binary(Sensor ou Actuator) do tipo boolean, para a classe Controller a varivel setpoint do tipo decimal e assim sucessivamente para qualquer objeto lgico que tenha sido especificado em qualquer subsistema. O mesmo critrio foi usado para especificao de todos os subsistemas. Os diagramas correspondentes de cada um dos subsistemas especificados no modelo podem ser encontrados no Anexo A. 3.2.4 Mapeamento Tecnolgico Na prxima viso do RM-ODP, os objetos computacionais definidos do nvel anterior so mapeados para objetos de engenharia e includo todo o suporte a transparncia em relao distribuio fsica esta viso, denominada viso de engenharia, que dar suporte especificao fsica da prxima viso. Como as tecnologias para as quais se estar realizando mapeamento tecnolgico, na ltima etapa de modelagem, j implementam os conceitos necessrios distribuio fsica, conforme j foi abordado no captulo 2, esta viso torna-se desnecessria no framework.

53

Assim, a quarta e ltima etapa de projeto do framework corresponde viso de tecnologia no RM-ODP que tem por finalidade a definio da tecnologia de hardware e software para composio do sistema e localizao de cada componente de hardware, a nvel fsico e em nvel de rede. Cada dispositivo lgico definido na etapa anterior ser mapeado para dispositivos fsicos de uma determinada tecnologia selecionada. Um dispositivo fsico pode ser composto por um ou mais dispositivos lgicos, dependendo das funcionalidades suportadas pelo hardware escolhido. Conforme pode ser observado na Figura 3.13 cada dispositivo recebe uma localizao fsica (em determinado ambiente da instalao) e uma localizao na rede correspondendo a um ponto (n) da rede em uma soluo distribuda.
1..* Zone
-name: string

1..*

Subnet
-groupAdress: list

Building

Room
-AbsLocalization: vetor -RelLocalization: string -temperature: decimal -humidity: decimal -luminosity: decimal

Network 1..*

peer
-AbsLocalization: string -RelLocalization: string

1 1..*

PhysicalDevice
-vendorName: string -deviceName: string -model: string -systemStatus: string -objectList: list -description: string

LogicalDevice 1..* 1..* 1..*

-adress: int -name: string -type: string -description: string -adressGroup: list +getAdress(): int

Figura 3.13 : Mapeamento Tecnolgico A fim de possibilitar este mapeamento, dispositivos fsicos de diferentes fabricantes devem ter suas funcionalidades mapeadas, conforme proposto no framework, compondo uma biblioteca de dispositivos. A partir dessa biblioteca ser possvel selecionar que componente oferece a funcionalidade que foi modelada. As conexes entre os dispositivos lgicos correspondero a uma conexo local, quando os objetos estiverem dentro do mesmo n, ou a uma conexo externa quando for realizada entre diferentes dispositivos fsicos. As conexes locais so providas por mecanismos de comunicao adotados pela tecnologia para a qual se est fazendo o mapeamento e as conexes externas sero dependentes da infraestrutura de rede suportada por ela. O resultado ser o modelo fsico de um sistema. funo das ferramentas de configurao importar esta especificao e fazer configuraes automticas de um dado sistema. Acredita-se que uma boa estratgia seja descrever o sistema no formato XML Extensible Markup Language (W3C, 2000), o qual um padro foi proposto pelo W3C para ser uma linguagem para troca de dados entre aplicaes e tem rapidamente se tornado um padro de mercado para representao de dados (AMARAL, 2002). Uma vantagem da utilizao de XML que possvel validar um arquivo, pela verificao da sua correo gramatical (analisando a estrutura do documento) antes

54

mesmo da sua utilizao por uma ferramenta especfica, o que importante para prevenir erros de formao de um arquivo fonte. Isto possvel porque o consrcio tambm define uma linguagem para descrever a estrutura do documento, recomendando atualmente o uso de XML Schema (W3C, 2001) para esta finalidade A Figura 3.14 representa uma proposta para o processo de representao (armazenagem) dos dados modelados no framework para um determinado sistema. Os dispositivos e as conexes lgicas seriam armazenados em formato XML. Posteriormente, a partir desse(s) arquivo(s) poderia ser realizado o mapeamento automtico para diferentes tecnologias disponveis para implementao.

Figura 3.14 : Representao do framework Esta tarefa de mapeamento consiste na definio de filtros para converso do(s) arquivo(s) gerado(s) pelo framework no formato do(s) arquivo(s) de configurao da tecnologia alvo. O uso de arquivos no formato XML deve facilitar esta tarefa pela existncia de padres (geralmente suportados por diferentes ferramentas) para manuseio de arquivos XML. Para converso de formato do(s) arquivo(s) padro gerado a partir do framework para o formato suportado pelo(s) arquivo(s) de uma determinada tecnologia alvo, por exemplo, pode citar-se o padro XSL (eXtensible Stylesheet Language) cujo processo est representado na Figura 3.15.

Figura 3.15 : Usando XSL para converso de formatos. O anexo C apresenta uma proposta de estrutura de arquivo XML para representao dos dispositivos lgicos e conexes.

3.3 Consideraes Finais

A Figura 3.16 apresenta uma viso geral das diversas etapas do projeto de um sistema de automao predial que foram abordadas, situando-as no nvel correspondente conforme o RM-ODP.

55

projeto define requisitos Anlise/Especificao (viso de em presa) so decompostos Com portamentos define define Usurios vlidos define Interfaces com Usurio define restries Estratgias de controle so decompostos Funcionalidades

define quais

define tipo

define quais define tipo

define quais

define

Variveis de entrada mapeia para Sensor

m apeia para m apeia para

define Variveis de sada mapeia para Actuator Persistent Locais de Armazenagem

Projeto Lgico (Viso de informao + viso de computao)

mapeia para

Controller Scene

mapeia para

UserInterface mapeia para m apeia para m apeia para mapeia para mapeia para mapeia para Funcionalidades Implementao (Viso de Tecnologia) implementa Dispositivo Fsico oferece biblioteca

possui

localizao fsica

Figura 3.16 : Viso Geral do Projeto Em Gomaa (GOMAA, 2000) pode-se encontrar uma categorizao de classes de aplicao. O autor apresenta as seguintes classes como representativas para as aplicaes: interfaces: classes que interagem com objetos do ambiente externo tais como dispositivos, usurios e sistemas ou subsistemas externos; classe de armazenamento (entity): classes que armazenam informaes de objetos persistentes; controle: classes que fornecem a coordenao para um conjunto de objetos; lgica: classe que contm os detalhes da lgica da aplicao. Embora o modelo proposto no tenha sido elaborado a partir dessa classificao, como ficou claro no texto apresentado ao longo desse captulo, pode-se observar que as classes propostas se assemelham muito as da categorizao apresentada pelo autor. Como foi citado um dos pontos de partida para definio das classes do framework foi a anlise dos padres. A Tabela 3.1 apresenta os objetos comuns entre os protocolos EIB, BACnet e HomePnP e os objetos propostos no framework.

56

Tabela 3.1 : Equivalncia dos objetos propostos no modelo

EIB-Type_Id (dec) EIB Object types BACnet ID(dec) BACnet Object types HomePnP ID(hex) HomePnP Object types 01 - Node Control Modelo (proposto) PhysicalObject

0 - Device Objec 8 - Device Object 1 - Addresstable Object 2 - Associationtable Object 3 Application program Object 4 - Interface Program 5 - EIB-ObjectAssociationtableObject 6 - Router Filtertable 10 - Pollingmaster 11 - File 100 - Analogue-Input 101 - Analogue-Output 102 - Analogue-Value 103 - Binary-Input 104 - Binary-Output 105 - Binary-Value 106 - Counter 107 - Loop 108 - Multistate-Input 16 - Program Object

02 - Context Control

Scene

1C - Counter/Timer 0A - Matrix Switch 10 - Multi-position Sensor 109 - Multistate-Output 14 - Multistate-Output 09 - Multi-position Switch 6 - Calendar 7 - Command 9 - Event Enrollment 11 - Group 15 - Notification Class 17 - Schedule 15 - List Memory 03 - Data Ch. RCVR 04 - Data Ch. Trans 0F - Metter 10 - Display 11 - Medium Transport 13 - Dialer 14 - Keypad 17 - Motor 19 - Synth/Tuner 1A - Tone Generator 1D - Clock 12 - Loop 13 - Multistate-Input

10 -File 0 - Analogue-Input 1 - Analogue-Output 2 - Analogue-Value 3 - Binary-Input 4 - Binary-Output 5 - Binary-Value

16 - Data Memory 08 - Analog Sensor 07 - Analog Control 06 - Binary Sensor 05 - Binary Switch

Persistent AnalogSensor AnalogActuator Scene BinarySensor BinaryActuator Scene Controller Controller MultistateSensor MultistateActuator Calendar

Scene Persistent Sensor UserInterface Channel UserInterface Actuator Clock

57

4 CICLO DE DESENVOLVIMENTO FRAMEWORK

USANDO

Este captulo tem por objetivo mostrar como o framework proposto utilizado a fim de garantir a consistncia durante as diversas fases de projeto de sistema de automao predial

4.1 A Metodologia de Projeto Definida no Framework

A metodologia de projeto proposta no framework basicamente divide o projeto de um sistema de automao predial em trs etapas. A primeira corresponde ao nvel de anlise onde a partir das caractersticas desejadas do ambiente so definidos as funcionalidades e os comportamentos desejados do sistema. Esta etapa deve concentrar-se no qu o sistema deve realizar. A Figura 4.1 representa esta etapa, onde est sendo utilizado um use case UML para representar as funcionalidades desejadas. Estas informaes devem ser complementadas atravs da descrio das polticas (estratgias de controle) que devem ser asseguradas para cada funcionalidade.

Definir Funcionalidades (ambiente)

Figura 4.1 : Definio das funcionalidades A partir desse ponto, o restante do projeto realizado com o suporte do framework proposto. As funcionalidades e o comportamento desejados so mapeados para as funcionalidades dos subsistemas disponveis no framework especificado. Conforme pode ser observado na Figura 4.2, esta etapa corresponde a expandir o use case inicial. Entretanto esta expanso j realizada com foco nas funcionalidades que foram modeladas em cada subsistema.

58

Definir Funcionalidades (modelo)

MODELO (funes)

Figura 4.2 : Projeto lgico seleo das funcionalidades do modelo Depois de definidas as funcionalidades a prxima etapa corresponde ao projeto lgico: so selecionados os dispositivos lgicos necessrios para representar as funcionalidades que foram definidas. importante ressaltar que nesta etapa so tomadas as decises de projeto, uma vez que a seleo de um determinado dispositivo lgico que ser utilizado para implementao de uma determinada funcionalidade deve levar em conta aspectos relacionados a estratgia de controle que ser utilizada no sistema. A Figura 4.3 representa esta camada do projeto.

Selecionar Dispositivos Lgicos

MODELO (dispositivos Lgicos)

Figura 4.3 : Projeto Lgico Seleo dos dispositivos lgico Na terceira etapa os dispositivos lgicos so mapeados (deployed) para componentes fsicos que suportem as funcionalidades especificadas e as conexes lgicas entre dispositivos sero mapeadas para as conexes fsicas disponveis para uma dada tecnologia. A fim de permitir este mapeamento, dispositivos de diferentes tecnologias e/ou fornecedores devero ter suas funcionalidades mapeadas conforme as funcionalidades propostas para os subsistemas do modelo, formando uma biblioteca de dispositivos fsicos, a qual relaciona dispositivos com funcionalidades do modelo. Esta camada pode ser visualizada na Figura 4.4, dividida em duas partes (seleo e localizao dos dispositivos) para melhor representao dos passos envolvidos.

4.2 Roteiro de Projeto Utilizando o Framework

Na realizao de estudos de casos para validao do framework proposto, observou-se que diversas atividades devem ser executadas em cada uma das etapas citadas no item anterior. Por este motivo optou-se pelo detalhamento das mesmas, resultando no roteiro de projeto que ser apresentado a seguir.

59

Selecionar Dispositivos fsicos

Biblioteca de Dispositivos Fsicos

Localizao (fsica + rede)

Figura 4.4 : Mapeamento Tecnolgico Este roteiro identifica atividades relevantes que devem ser executadas em cada etapa de projeto e tem como objetivo principal fornecer uma transio suave entre as diferentes camadas que compem o framework proposto. Ele mantm a estrutura de camadas especificada, inserindo atividades dentro de cada camada a fim de facilitar a especificao do sistema. As etapas desse roteiro foram definidas subjetivamente e resultaram da observao da repetio de tarefas medida que se executavam estudos de caso para a validao do framework, ao longo de suas diversas etapas de especificao. A seguir sero especificadas as principais atividades que devem ser executadas no projeto de um sistema de automao predial, no mbito do framework especificado no trabalho. 1. Definir as funcionalidades do ambiente que devem ser controladas A caracterizao do ambiente define as funcionalidades que devero ser atendidas pelo mesmo as quais so selecionadas de acordo com especificao do(s) proprietrio(s) e/ou projetista(s) e de acordo com normas e legislao vigentes conforme o tipo de ambiente. A partir da anlise das caractersticas do ambiente externo pode-se definir quais as caractersticas especificadas para o ambiente definem funcionalidades que devem ser implementadas no sistema de automao predial por no serem atendidas pelo ambiente externo. Para representao das funcionalidades que devem ser atendidas podem ser construdos diagramas use case UML, os quais devem ser complementados por

60

informaes relativas s estratgias (polticas) de controle especificadas para o ambiente. 2. Definir os agentes externos que iro interagir com o sistema e definir as polticas de gerenciamento Os agentes externos podem ser definidos como usurios do sistema, os quais podem ser classificados em diversos nveis de acesso conforme as polticas de gerenciamento definidas, relativamente configuraes, notificaes, permisses de acesso, interfaces de interao com sistema, etc. 3. Dividir o ambiente em sub-regies ou zonas de acordo com as funcionalidades que devem ser controladas Um ambiente pode ser subdividido para possibilitar o ajuste da funo de controle as caractersticas especficas de uma parte do ambiente ou para facilitar a manuteno e a instalao. HomePnp define estas sub-regies como zonas e as define como uma parte fsica ou lgica de uma regio de controle (CIC, 1998). Na diviso do ambiente em zonas deve-se levar em conta parmetros relativos a fatores tais como conforto (controle de luminosidade, de temperatura, de umidade, de qualidade do ar, etc.), segurana (controle de acesso, de intruso, de incndio e controle ambiental: vazamentos, inundaes, faltas, falha de equipamentos,etc), gerenciamento de energia, etc. Um subsistema especfico pode ter uma ou mais zonas, de acordo com a caracterstica de controle que se deseje implementar e no necessariamente existe relao entre a diviso de zonas entre os diferentes subsistemas. 4. Selecionar funcionalidades e subsistemas que comporo o modelo A partir da anlise das funcionalidades e das polticas definidas no item 1, so definidos os subsistemas necessrios para atender a especificao e so refinadas aquelas funcionalidades de acordo com as funcionalidades definidas nos subsistemas especificados no framework. 5. Definir as polticas de operao dos subsistemas A partir das estratgias de controle que foram especificadas no item 1 definir as polticas de operao, criando cenrios de operao com enfoque nas aes que devem ocorrer e que no podem ocorrer em cada sub-regio (zona) para cada subsistema. Nesta etapa pode ser interessante definir os estados de ocupao do ambiente ou modos de operao do sistema os quais posteriormente daro origem a cenrios especficos nos diferentes subsistemas. Esta caracterstica to relevante na definio dos sistemas de automao predial que alguns protocolos a tratam explicitamente. HomePnP, por exemplo, define um contexto denominado House mode (CIC, 1998) com os seguintes estados: Ocupado (normal, baixa atividade, dormindo) Desocupado (at 1h, at 4h, at 8h, at 24h, at 48h, frias) e Incerto. Por sua vez UPnP define um template denominado house status (UPnP, 2003) para o qual define as seguintes variveis : occupancyState(Ocupado, Desocupado e Indeterminado), activityLevel (regular, alta atividade e dormindo) e DormancyLevel (frias, regular e animais na casa).

61

6. Selecionar os dispositivos lgicos e suas conexes Nesta etapa sero selecionados os dispositivos lgicos e suas conexes que permitem representar as funcionalidades especificadas no item 4 de forma a atender as polticas de operao definidas no item 5. Definies de projeto so estabelecidas ao definir-se as classes de origem do dispositivo lgico que vai ser utilizado para representar uma determinada funcionalidade e as conexes entre os diferentes dispositivos lgicos que representam cada subsistema. 7. Especificar os cenrios Construir os cenrios de operao com enfoque nas funcionalidades dos dispositivos lgicos especificados, definindo as pr-condies e procedimentos que correspondem a cada poltica de operao definida no item 5. Como atravs dos cenrios que implementada a interao entre diferentes subsistemas esta etapa fundamental para localizar a necessidade de interao entre os subsistemas. Uma questo importante a definio e representao das prioridades na soluo dos conflitos. No meta-modelo apresentado no captulo 3 foram definidos nveis de prioridade para cada cenrio. Entretanto, a anlise de diversas tecnologias mostrou que na maioria dos casos o hardware disponvel para execuo dos cenrios no trabalha orientado a prioridade. Uma alternativa fazer a construo das prcondies com a incluso explcita de prioridades baseada nos eventos que ocorrem nos dispositivos lgicos. Aps avaliar os cenrios e verificar as colises, definindo as prioridades, conforme citado no item 3.2.2, deve-se: Estabelecer as prioridades das pr-condies, conforme a prioridade que foi definida para os cenrios; Estabelecer para cada pr-condio as de maior prioridade que provocam coliso, ou seja, que esto associadas a procedimentos contraditrios e no devem ser vlidos no momento da avaliao de uma pr-condio de menor prioridade; Avaliar a ocorrncia dessas pr-condies antes da de menor prioridade, redefinindo a cadeia de eventos que deve ser verificada para cada pr-condio de menor prioridade, incluindo os eventos das pr-condies de maior prioridade. As avaliaes das condies lgicas devem ser realizadas usando-se as leis da lgica booleana. A Figura 4.5, um extrato do estudo de caso do captulo seguinte e ilustra estas etapas. Primeiro, a partir da definio de prioridades dos cenrios foi estabelecido a prioridade das pr-condies. A seguir foi avaliado, levando-se em conta os procedimentos que deviam ser executados, que pr-condies de maior prioridade levavam a procedimentos contraditrios. Finalmente foi reconstruda a cadeia de eventos as ser avaliada em cada pr-condio a fim de eliminar o conflito. Ness exemplo no aparece a pr-condio PreA5 como pr-condio prioritria para a PreA1 porque na definio dos cenrios elas no levam a procedimentos contraditrios. Esta soluo ser explorada posteriormente no estudo de caso.

62

Figura 4.5 : Construo das prioridades baseadas na ocorrncia dos eventos 8. Realizar mapeamento tecnolgico Selecionar dispositivos fsicos que implementem as funcionalidades dos dispositivos lgicos modelados no item anterior, definindo sua localizao fsica (deployment) e o endereamento na rede e mapear as conexes lgicas para conexes fsicas.

4.3 Exemplos de Modelagem Utilizando o Framework

De forma simplificada um padro de projeto descreve uma soluo que foi utilizada para resolver um problema especfico a qual se repete em outras aplicaes (GAMMA, 2000). De uma maneira geral, em qualquer rea de aplicao eles podem ser identificados e documentados, logo tambm em sistemas de automao predial possvel identificar determinados padres que se repetem em diferentes contextos. O objetivo principal desta seo apresentar algumas solues que se repetem no domnio sob estudo e mostrar como elas so definidas no mbito do framework proposto, fornecendo alguns exemplos genricos de modelagem usando a estrutura proposta. Estas solues foram observadas a partir de anlises de solues em sistemas de automao predial ao longo do trabalho Sero apresentados trs padres utilizando os dispositivos lgicos especificados, os quais permitem representar sistemas com complexidade crescente e que so utilizados independentes das funcionalidades e dos subsistemas que esto sendo implementados. Para cada um deles ser apresentada uma descrio genrica da sua ocorrncia, para cuja representao sero utilizadas as classes de origem dos dispositivos lgicos modelados e ser apresentado um exemplo. Um primeiro padro que se identifica componentes da classe Sensor esto conectados diretamente a componentes da classe Actuator, o qual recebe o parmetro relativo a varivel de entrada e executa a operao sobre a varivel de sada representada, conforme pode ser observado na Figura 4.6.
Sensor input Actuador

Figura 4.6 : Sensor conectado diretamente ao atuador

63

Um exemplo de aplicao desse padro para representar um interruptor ligado diretamente a uma lmpada, a qual deve ligar ou desligar conforme o sinal recebido do mesmo. A figura Figura 4.7 ilustra esta aplicao.
BinarySensor

Switch

s witchInput

BinaryActuator

LightRelay

Figura 4.7 : Modelagem de um interruptor comandando uma lmpada. O segundo padro tem o objetivo de representar sistemas de controle de variveis contnuas, no qual se deseja que uma varivel de sada mantenha um valor de referncia previamente estabelecido. Um objeto da classe Controller executa o algoritmo que objetiva manter a varivel de sada, representada por um objeto da classe Actuator, no valor previamente estabelecido geralmente pelo usurio, representado por um objeto da classe UserInterface. Um objeto da classe Sensor destina-se a representar a varivel de entrada que est associado ao processo sob controle. A Figura 4.8 ilustra este modelo.
Sensor input Controller Setpoint/Command Setpoint/Comand UserInterface output Actuator

Figura 4.8 : Representao de um processo de controle em malha fechada Um exemplo de aplicao desse padro ilustrado na Figura 4.9 a qual representa um controle de temperatura tpico de um Ar Condicionado com as opes quente e frio. As funcionalidades aquecer, resfriar e ventilar esto sendo modeladas por trs objetos da classe Actuator. O algoritmo de controle est sendo representado por um objeto da classe Controller e um objeto da classe Sensor est representando a temperatura ambiente. Um objeto da classe UserInterface permite representar a interface com o usurio o qual determina o valor de referncia (setpoint) e selecionar comandos tais como ligar ou desligar, entre outras possibilidades.
IntTempSensor
AnalogSensor AnalogSensor

tempInput tempInput

HVACController setpoint/command
UserInterface

binOut binOut binOut

BinaryActuator

HeatActuator CoolActuator FanActuator

BinaryActuator

ExtTempSensor Interface

BinaryActuator

Figura 4.9 : Modelagem de um controle de temperatura Sistemas mais elaborados devem oferecer uma flexibilidade de operao maior, permitindo a construo de diferentes cenrios de operao. Estes sistemas podem ser representados com o terceiro padro de projeto definido. Aos objetos j citados nos dois modelos anteriores acrescentado um objeto cenrio, da classe Scene, o qual permite representar diferentes condies para as variveis de sada, atravs da determinao de parmetros de referncia (setpoints) ou comandos (commands) para os controladores ou pela manipulao direta das variveis de sada, conforme parmetros ou eventos que ocorrem no ambiente, representados por objetos da classe Sensor, conforme pode ser observado na Figura 4.10.

64

Sensor

input

Controller setpoint/command

output

Actuator

Sensors

inputs(events)

Scene UserParameters UserInterface

command

Actuator

Figura 4.10 : Representao de sistema que permite diferentes cenrios. A Figura 4.11 acrescenta ao controle da temperatura da Figura 4.9 a possibilidade da representao de diferentes cenrios, conforme a ocupao do ambiente, representado por um objeto da classe Sensor e de acordo com uma agenda previamente determinada, representado por um objeto da classe Callendar.
BinaryActuator

CoolActuator HeatActuator FanActuator Interface

AnalogSensor

binOut tempInput HVACController binOut binOut

TempSensor OcupSensor Agenda

BinaryActuator BinaryActuator

BinarySensor

setpoint/command ocupInput
Scene

Callendar

events

HVACScene

userParameters

UserInterface

Figura 4.11 : Modelagem de um controle de temperatura com diferentes cenrios. J a Figura 4.12 representa um sistema de controle de iluminao com dois atuadores das classes BinaryActuator e AnalogActuator cujos atributos so estabelecidos conforme o cenrio, determinado pelos valores dos atributos dos diferentes objetos do tipo Sensor, que representam as variveis de interesse.
AnalogSensor

LightSensor Switch

BinarySensor BinarySensor

lightInput switchInput ocupInput sceneSelect

BinaryActuator

LigtnScene User parameters

UserInterface

Scene

binOut levelOut

LightRelay Dimmer

AnalogActuator

OcupSensor

MultistateSensor

SceneSelector

Interface

Figura 4.12- Modelagem de um controle de luminosidade com diferentes cenrios.

65

5 VALIDAO DO MODELO
Ao longo da definio do modelo foram realizados diversos estudos de caso, a fim de validar os conceitos e funcionalidades que estavam sendo definidas. Neste captulo apresentado o mapeamento dos objetos especificados para uma arquitetura alvo e tambm um estudo de caso com o objetivo de validar a metodologia como um todo.

5.1 Sistema de Homesystems

Automao

Predial/Residencial

da

Empresa

A arquitetura alvo principal do estudo de caso apresentado uma plataforma proprietria da empresa Homesystems, cuja matriz localiza-se em Porto Alegre e desenvolve tecnologia em sistemas de automao predial (HOMESYSTEMS, 2005) e com a qual o Grupo de Controle Automao e Robtica (GCAR) da UFRGS possui uma parceria. A arquitetura se enquadra no terceiro tipo abordado no captulo 2: diferentes mdulos so conectados em rede e possuem um conjunto de funcionalidades que independem de uma unidade central, podendo funcionar em regime stand-alone. Entretanto determinadas funcionalidades s so possveis pelo gerenciamento da unidade de controle central, denominada systembox. A plataforma de rede utiliza um protocolo proprietrio rodando sobre a camada fsica 485 e permite diferentes configuraes na montagem dos dispositivos atravs da utilizao de um hub especfico, denominado

Starhub. A Figura 5.1 ilustra uma configurao tpica.

66

Figura 5.1 : Arquitetura fsica Durante a realizao deste trabalho, as interfaces de alto nvel com usurio eram o aparelho telefnico e navegadores internet. Estas funcionalidades so suportadas pela unidade central, a qual faz o gerenciamento seguro das chamadas telefnicas e executa um servidor apache para automatizar a disponibilizao de informaes do sistema para um usurio atravs de um browser padro. Uma ferramenta de configurao e manuteno, denominada commander, permite a configurao e a manuteno do sistema. Na Figura 5.2 pode ser visualizada a janela principal da ferramenta. No lado direito da podem ser observados os diversos mdulos disponveis pela arquitetura, no lado esquerdo as funcionalidades oferecidas pela ferramenta e na rea central tm-se a rea de trabalho, onde configurada a rede, pela seleo e endereamento dos dispositivos.

Figura 5.2 : Ferramenta de Configurao

67

Um conjunto de arquivos de configurao manuseado pela ferramenta de configurao durante a etapa de configurao do sistema e posteriormente so enviados unidade central que os utiliza durante a execuo do programa de controle. 5.1.1 Dispositivos Disponveis A arquitetura Homesystems oferece um conjunto de dispositivos que podem ser utilizados para a automao de sistemas de iluminao, de ar condicionado e aquecimento, controle de portes e cortinas, etc. A seguir so listados alguns mdulos disponveis e suas finalidades: Painel de comandos: at 9 teclas e 9 leds que podem ser configurados para entradas/indicao de comandos e cenrios; Sensor Externo: 2 entradas analgicas, podendo ser usado para indicao de nvel de luminosidade, temperatura, etc. A varivel pode assumir valores inteiros entre 0 e 255; Rels de 8 e de 15 canais: 8 ou 15 sadas digitais que podem ser utilizados para acionar cargas do tipo ligado/desligado; Rels de 12 e de 16 canais: 12 ou 16 sadas digitais, com possibilidade de ligao no prprio mdulo de teclados de 9 teclas e definio de at 8 cenrios que permitem configurar como ativado ou desativado cada um dos canais de sada para cada um dos cenrios; Dimmer 4 canais: 4 sadas analgicas que podem ser configuradas entre 0 e 100%, com o objetivo de acionar cargas que possam receber tenso varivel; QuickLight: 9 sadas analgicas, com possibilidade de ligao no prprio mdulo de teclados de 9 teclas e definio de at 8 cenrios que permitem configurar valores entre 0% e 100% cada um dos canais de sada para cada um dos cenrios; Entradas digitais de 8 canais: 8 entradas digitais com possibilidade de configurao NA/NF (Normalmente Aberto/Normalmente Fechado). Podem ser utilizadas para indicar o estado de qualquer grandeza que possa ser representado pelos estados ligado/desligado; Entradas digitais de 16 canais: 16 entradas digitais com possibilidade de configurao NA/NF (Normalmente Aberto/Normalmente Fechado) e 2 entradas analgicas; Termostato: utilizado para o controle de atuadores de subsistemas de HVAC e como interface de usurio com este tipo de subsistema. Atravs dele podem ser definidos setpoints de refrigerao e aquecimento e realizado o acionamento dos atuadores do Ar condicionado, atravs de ligao eltrica entre eles. Acionador de Porto: este mdulo usado para controle de portes, possuindo entradas para sensores tpicos dessa aplicao e sada para ligao dos motores de acionamento; Combo: mdulo leitor de cartes para identificao de usurios. O arquivo hsconfig.ini possui a configurao dos parmetros de cada mdulo. 5.1.2 Outros Conceitos Usados pela Arquitetura Variveis: O sistema permite a utilizao de variveis. Na manipulao de variveis esto disponveis as opes atribuir valor, incrementar valor, decrementar valor, atribuir

68

E/S e atribuir varivel. A configurao de variveis armazenada no arquivo variable.ini. Temporizaes: Diversos mdulos permitem definir temporizaes para o comando ligar e na execuo de qualquer procedimento pode-se implementar um comando especfico definido como esperar. Algumas tarefas de controle possuem temporizaes especficas e podem ser configuradas diretamente no prprio mdulo, como exemplo pode-se citar o acionador de porto que possui alguns tempos definidos diretamente na configurao do mdulo. Agrupamentos: A arquitetura permite definir grupos. Um grupo comporta-se como uma entrada ou sada digital e sobre ele podem ser executados comandos e verificados estados tpicos de uma sada digital. Alarmes e avisos: Podem ser definidos diferentes alarmes os quais podem ser enviados a telefones previamente cadastrados. Para cada alarme podem ser especificadas algumas temporizaes (atraso na ativao, tempo de ciclo ligado, tempo de ciclo desligado, tempo de acionamento), podem ser definidas sadas que sero acionadas por este alarme e podem ser definidas mensagens para os eventos de invaso, ativao e desativao do alarme. Uma simplificao do alarme o aviso. Um aviso pode estar vinculado a qualquer canal de qualquer dispositivo do sistema. As opes de notificao so atravs de mensagem (vinculada ao canal na configurao) ou atravs de sinal sonoro (bip) e ser emitido para uma lista de telefones configurados previamente. Os arquivo alarm.ini possui toda a configurao de alarme e avisos que programada atravs da ferramenta de configurao. Os arquivos alarm.ini e voicemsgs.ini possuem a configurao dos alarmes, de telefonia e de mensagens de voz utilizadas. Calendrio e Relgio Atravs de um calendrio podem ser definidos os dias teis, os feriados e os finais de semana e um relgio interno permite configurar eventos temporais. Desta forma possveis definir eventos baseados em data, horrio (com a possibilidade de definir os dias da semana para os quais est sendo configurado o horrio, podendo ser includos ou excludos os feriados) e intervalo de horrio o qual permite definir de um horrio inicial e um horrio final. O arquivo holidays.ini possui a configurao do calendrio. Scripts A ferramenta de configurao oferece um recurso denominado scripts. Atravs dele possvel definir eventos e associar procedimentos que sero executados na ocorrncia da condio verdadeira ou falsa de um determinado evento. Um evento pode estar associado a uma entrada ou sada (digital ou analgica), a um horrio ou intervalo de horrio, a uma data ou a uma varivel. Diversas condies podem ser previstas para um evento, associadas atravs dos operadores lgicos E e OU. Um procedimento estabelece aes que devem ser executadas no sistema. Uma ao pode corresponder ao acionamento de uma sada, execuo de um outro procedimento, vinculao de uma sada, atribuio de uma varivel, determinao

69

de um tempo de espera, ao toque de uma mensagem ou telefone e execuo de um alarme ou de um aviso. Os arquivos events.ini e procedure.ini possuem toda a configurao de eventos e procedimentos programados atravs da ferramenta de configurao. Telefonia Como a interface principal com o sistema atravs do telefone a ferramenta permite configurar a topologia das conexes telefnicas no systembox (ligado diretamente, atravs de central interna, ramal de atendimento, tipos de toques, temporizaes, etc). Tambm permite definir senhas para acesso externo e interno e nveis de acesso. Na etapa final de configurao da telefonia podem ser montados menus em nvel com nmeros que estaro associados com procedimentos para comando via telefone. O arquivo telephony.ini e phonebook.ini possuem toda a configurao de telefonia programada atravs da ferramenta de configurao. 5.1.3 Mapeamento do Framework No mapeamento do framework deve-se considerar a funcionalidade oferecida por um determinado mdulo e a sua configurao. Primeiramente, um dispositivo lgico dever estar mapeado em um mdulo que oferea a funcionalidade requerida. A seguir est relacionado para que mdulos devem ser mapeados as classes do framework: AnalogSensor: sensor de temperatura e luminosidade (2 canais), entradas digitais 16 canais (2 canais analgicos); AnalogActuator: dimmer de 4 canais e dimmer de 9 canais; BinarySensor: entradas digitais onboard, entradas digitais de 8 e 16 canais e painel de comando; BinaryActuator: sadas digitais onboard, rels de 8, 12, 15 e 16 canais e dimmer de 9 canais (cada canal pode ser configurado opcionalmente para ter um comportamento digital); MultistateSensor / Multistate Actuator: no implementado diretamente. Implementaes dessa funcionalidade usam entradas/sadas analgicas com definio dos valores tais como: 0=ligado, 1=desligado, 2=parado, etc; Controller: todos os mdulos executam funo de controle especfico, de acordo com a finalidade do mdulo; UserInterface: as interfaces padro telefone e internet so funcionalidades oferecidas pelo systembox com configuraes especficas. Determinados mdulos fornecem interfaces especficas (termostato: display, teclado, leds sinalizadores, teclados: leds sinalizadores, combo: carto e acionador de porto: infravermelho, etc.); Persistent: alguns mdulos possuem configurao especfica de parmetros. O mdulo Combo armazena nmero de cartes, o mdulo de comando de portes armazena cdigos de RF. Os atributos e funcionalidades iro corresponder s configuraes e operao desses mdulos. As variveis utilizadas nos scripts correspondem a um meio de armazenamento em RAM, gerenciadas atravs do sistema operacional do Systembox; Scene: implementado atravs de eventos (preconditions) e procedimentos (procedures) no Systembox.

70

Resolvida a questo do mapeamento fsico, a segunda questo refere-se configurao correta dos diferentes arquivos de configurao para que eles reflitam o modelo de um sistema que foi modelado usando o framework proposto. A seguir, no restante desse item procura-se demonstrar como deve ser feito este mapeamento. Uma descrio mais detalhada pode ser encontrada no Anexo B, onde est descrito o mapeamento de cada atributo do modelo para atributos dos arquivos de configurao, bem como uma descrio de como so utilizados os mtodos do modelo. No arquivo hsconf.ini devem ser configurados os mdulos que faro parte da rede que corresponde ao mapeamento dos dispositivos fsicos (da classe PhysicalDevice) que foram definidos no framework. A Figura 5.3 resume a representao desse mapeamento. No lado esquerdo tem-se a especificao da classe e no lado direito uma parte do arquivo de configurao do dispositivo fsico. A parte central mostra a equivalncias entre os atributos. Como pode ser observado, alguns atributos no possuem equivalncia nos arquivos de configurao e alguns atributos dos mesmos no possuem equivalncia no modelo. No primeiro caso tm-se atributos que no interferem na funcionalidade oferecida pela arquitetura, enquanto no segundo tm-se atributos que so utilizados por aspectos visuais da ferramenta de configurao ou em alguma configurao especfica oferecida pela arquitetura que no esto previstas no framework.

Figura 5.3 : Mapeamento dos Atributos da Classe PhysicalDevice A seguir destacam-se os atributos que pertencem a estes casos que foram observados na figura anterior: os atributos vendorName e objectList so indicados por default no mapeamento pois, conforme pode ser observado no item anterior, a definio dos objetos que compem cada mdulo uma caracterstica fixada na escolha do mdulo e o fabricante no indica nenhuma referncia nos arquivos de configurao do mdulo; o atributo description no implementado pela arquitetura Homesystems; o atributo pooltime utilizado para indicar o tempo de intervalo entre as leituras sucessivas do mdulo (escravo) pelo systembox (mestre), caracterstica de configurao do modelo de comunicao mestre-escravo; os atributos hw e icon e so utilizados para implementao de aspectos visuais na ferramenta de configurao. Aps a especificao dos dispositivos fsicos dever ser feito o mapeamento de cada dispositivo lgico. Esta configurao realizada no mesmo arquivo e o mapeamento dos atributos pode ser observado na Figura 5.4.

71

No lado esquerdo tem-se a especificao das classes do modelo que so mapeadas no arquivo de configurao, parcialmente representado no lado direito da figura. A parte central mostra a equivalncias entre os atributos. Aqui tambm se observa que alguns atributos do framework so default na arquitetura Homesystems, alguns no so implementados e alguns atributos da arquitetura no so mapeados no framework. O detalhamento dos dois primeiros casos pode ser encontrado no anexo B. Relativamente ao terceiro caso tm-se os atributos: [unit_x] utilizado como separador; icon e form que so utilizados para configurao de aspectos visuais no commander; disab que indica que a unidade est desabilitada pois o arquivo de configurao sempre contm todas as unidades de todos os mdulos configurados; logged que indica que o systembox deve manter um arquivo com histrico para aquela unidade;

Figura 5.4 : Mapeamento dos Atributos dos Dispositivos Lgicos voice indica a mensagem de voz que est vinculada unidade, se houver, e gender se esta mensagem ser com voz masculina ou feminina. Por sua vez, o mapeamento dos cenrios pode ser observado na Figura 5.5. No lado esquerdo tm-se as classes de origem do modelo e a direita extratos parciais dos arquivos de configurao.

72

Figura 5.5 : Mapeamento dos Cenrios Para facilitar a identificao de equivalncia entre o modelo e os arquivos de configurao junto a estas classes encontra-se a representao dos procedimentos, precondies e cenrios de acordo com a sintaxe definida no item 3.2.2 e foram utilizados setas e retngulos delimitadores, indicando onde os conceitos esto sendo implementados nos arquivos de configurao. Os nmeros aps o sinal de igual esto relacionados com a sintaxe adotada pelo fabricante para representar os procedimentos e eventos. Por exemplo na primeira e na segunda linha aps o delimitar PROC_4 (action_2 = 1 70 0 1 0 1) o primeiro campo indica que o comando o acionamento de uma sada, o segundo indica a unit que ser acionada e os demais campos esto relacionados com os parmetros desse comando. A ltima linha (name = ProcA4(Desligar L1 e Ligar L2)) indica o nome do procedimento. Uma sintaxe similar utilizada na definio dos eventos. O arquivo procedures.ini contm a implementao dos procedimentos (classe Procedure) e o arquivo events.ini contm a implementao dos cenrios (classe Scene). Na parte superior de um evento, delimitado pelo marcador [EVENT_x] tem-se a descrio das pr-condies (classe Precondition) que deve ser avaliadas e na parte inferiro indicado o procedimento que deve ser executado quando o resultado da avaliao for verdadeiro (proc) ou quando for falso (proc_false), as quais correspondes s condies SE e SENO definidas nos cenrios do framework. Dois outros atributos aparecem neste arquivo so every indica se o procedimento deve ser executado sempre ou uma nica vez e enable que indica se o procedimento est habilitado ou no.

73

Por indisponibilidade da especificao da sintaxe usada nestes arquivos de configurao e limitao de tempo para fazer-se engenharia reversa usando a ferramenta de configurao, no se fez o mapeamento da sintaxe adotada com arquivo de configurao. Durante a realizao dos estudos de caso, os procedimentos, as precondies e os cenrios foram construdos usando-se os recursos de alto nvel oferecido pela ferramenta, muito semelhante sintaxe especificada no framework, conforme pode ser observado posteriormente neste captulo.

5.2 Exemplos de Mapeamento dos Dispositivos Lgicos

O primeiro padro estabelecido no captulo anterior foi de sensor conectado diretamente ao atuador. Na arquitetura em anlise isto possvel de ser implementado apenas quando se utiliza um mdulo de sada que possui teclado acoplado diretamente (Rels de 12 e 16 canais e o Dimmer de 9 canais). Como estes mdulos foram projetados para funcionar independentemente do mestre da rede, se o componente da classe Sensor for uma entrada do teclado, aps configurao local, a funo de controle ser executada no prprio mdulo. A implementao do exemplo, modelado usando o framework, representado na Figura 4.7 pode ser observada na Figura 5.6. Os mdulos disponveis pela arquitetura esto representados por retngulos identificados, a linha cheia que conecta os mdulos representa uma conexo de rede e a linha com a seta, entre os objetos do framework, indica uma conexo lgica entre estes objetos.
Teclado
BinarySensor

Rel/Dimmer
BinaryActuator

Switch

LightRelay

Figura 5.6 : Implementao de um sensor conectado diretamente no atuador O segundo padro especificado tem por objetivo representar sistemas de controle de variveis contnuas, no qual se deseja que uma varivel de sada mantenha um valor de referncia previamente estabelecido. Os mdulos que se enquadram neste padro so o termostato para aquecimento, o termostato para refrigerao e o termostato (com ambas funcionalidades), os quais possuem sensor de temperatura interna, uma interface com o usurio local e executam uma funo de controle local para manter o setpoint estabelecido. A implementao do exemplo da Figura 4.9 est representado na Figura 5.7. Como o termostato possui ligao eltrica com o aparelho de Ar Condicionado (AC), o qual implementa os atuadores (da classe Actuator), no termostato esto modeladas apenas as interfaces (da classe CommunicationInterface) com estes dispositivos lgicos.

74

Figura 5.7 : Implementao do controle de variveis contnuas O terceiro padro destina-se a representao de sistemas com diferentes cenrios. Duas alternativas de implementao de cenrios so possveis: uma local mais limitada e outra remota, que pode estar associada com qualquer funcionalidade do sistema. Na primeira, quando forem utilizados rel de 12 ou 16 canais e dimmer de 9 canais possvel compor at 8 cenrios com combinao de valores para as sadas (0 e 100% para rels e qualquer valor intermedirio para dimmer). Estes cenrios ficam armazenados no prprio mdulo e podem ser executados a partir do teclado local. Na segunda opo, o systembox ser responsvel pela execuo do cenrio estabelecido atravs dos scripts. Qualquer funcionalidade do sistema (entrada, sada, relgio, calendrio, etc.) pode gerar eventos e qualquer combinao de procedimentos pode estar associada a um evento. As interfaces disponveis (telefonia e internet) tambm podem ser usadas para emitir comandos. O exemplo ilustrado na Figura 4.11 pose ser implementado conforme representado na Figura 5.8.

Figura 5.8 : Implementao de diferentes cenrios

5.3 Estudo de Caso: Automao de Escritrio

O estudo de caso proposto, embora de dimenses reduzidas se comparado com um projeto de automao real, permite utilizar amplamente os conceitos discutidos nas sees anteriores, uma vez que para sua implementao devero ser utilizados diversos subsistemas especificados no modelo. A anlise de aplicaes reais mostrou que um projeto de grande porte difere, de uma maneira geral, apenas pelo aumento dos componentes que integram cada subsistema, o que muitas vezes provoca a diviso em subsistemas menores para facilitar o gerenciamento. A Figura 5.9 representa a planta baixa de um escritrio, onde L1 e L2 so luminrias fluorescentes com acionamento independente, L3 representa luminrias incandescente externas (com possibilidade de dimerizao), AC1 um ar condicionado de janela e cort1 representa uma cortina motorizada.

75

Figura 5.9 : Planta baixa de escritrio A partir dessa descrio geral do ambiente foram definidos diversos requisitos para o prdio com objetivo de permitir a modelagem de diversos subsistemas propostos. Foram especificados os seguintes requisitos: As lmpadas devero permanecer ligadas apenas se a sala estiver ocupada de acordo com luminosidade do ambiente. Um sistema de acionamento manual deve permitir o acionamento da iluminao durante um determinado intervalo independente do sistema automtico de controle. Objetivo: controle de iluminao por ocupao e por luminosidade, controle manual/automtico com prioridades diferentes. A iluminao externa dever ser acionada apenas noite e a partir da meia noite dever ser reduzida para 50%. Objetivo: controle de iluminao por luminosidade e por horrio. Temperatura ambiente controlada em 220C. A partir das 18h o sistema de controle de temperatura dever estar acionado apenas se a sala estiver ocupada. O sistema poder ligar (conforme temperatura ambiente) nos dias teis a partir das 7h mesmo que o ambiente esteja desocupado. Objetivos: controle de temperatura por horrio, calendrio e ocupao. A cortina da janela 1 dever estar aberta durante o dia, sempre que o controle de intruso esteja desativado. Quando a temperatura externa for maior do que X0C ela dever ser fechada e a iluminao interna ajustada. Um sistema de acionamento manual deve permitir o acionamento da cortina durante um determinado intervalo independente do sistema automtico de controle. Objetivos: controle da cortina por luminosidade, temperatura e ocupao do ambiente, controle manual/automtico com prioridades diferentes. Interao entre os dois subsistemas Diariamente s 18h o sistema de irrigao dever ser acionado por um tempo X. Objetivo: utilizao de um subsistema com controle de acionamento por horrio e tempo de durao. Quando o sistema de controle de intruso for ativado, a iluminao interna dever ser desacionada, o sistema de controle de temperatura desativado, exceto dias teis no intervalo de almoo (12 s 14h) e a cortina dever ser fechada. Objetivo: estabelecer cenrios diferentes para controle de intruso. Em caso de deteco de intruso o alarme dever ser acionado, a cortina dever abrir e, se for noite, a iluminao dever ser acionada. Objetivo: explorar a interao entre diferentes subsistemas Sistema de deteco de fumaa dever acionar alarme de incndio em caso de deteco de fumaa (dois nveis: maior quando sala ocupada e menor quando

76

sala desocupada). Objetivo: explorar cenrios diferentes de ativao para o sistema de controle de incndio. A seguir sero apresentadas as etapas de projeto, conforme definidas no captulo anterior.

1. Definio das funcionalidades e comportamentos A Figura 5.10 apresenta um diagrama use case UML com as funcionalidades que devero ser implementadas pelo sistema, o qual foi construdo a partir da descrio da especificao do ambiente.
Sistema de Automao
Controlar Luminosidade Interna SensLum

AtuadorLumInt

Controlar Luminosidade Externa

AtuadorLumExt

SensTemp

Controlar Temperatura Controlar Cortinas

AtuadorTemp

AtuadorCortina

SensIntruso

Detectar e Comunicar Intruso Detectar e Comunicar Fogo Controlar Irrigao

AtuadorInt

SensFogo

AtuadorFogo

AtuadorIrrig

Figura 5.10 : Funcionalidades especificadas Esse diagrama complementado com informaes de comportamento que esto descritos na Tabela 5.1, as quais posteriormente permitiro o detalhamento de cada subsistema que ser implementado. Tabela 5.1 : Detalhamento dos comportamentos
Funcionalidade Controlar temperatura (aquecer ou resfriar) Comportamento Manter em 220C; Aps 18h acionar apenas se houver ocupao; Habilitar dias teis a partir das 7h Desligar ao habilitar controle de Intruso, exceo dias teis no horrio de almoo (12h s 14h); Regular conforme luminosidade externa; Desligar se ambiente estiver desocupado; Ligar em caso de intruso, se noite; Permitir comando manual. Acionar (100%) quando noite; s 24h reduzir para 50%; Acionar (100%) em caso de intruso, se noite; Permitir comando manual com prioridade sobre o automtico por um tempo pr-determinado.

Controlar luminosidade interna

Controlar luminosidade externa

77

Funcionalidade Controlar Cortina (abrir e fechar)

Detectar e comunicar Intruso Detectar e comunicar Fogo Controlar Irrigao

2. Definir os agentes externos que iro interagir com o sistema e definir as polticas de gerenciamento Foram definidos os seguintes usurios e para eles foram definidas as seguintes polticas: Administrador: responsvel pela habilitao de usurios, pela configurao de parmetros dos os subsistemas e pela criao/alterao de cenrios; Usurio: usurio habilitado a desabilitar o sistema de intruso, controlar a temperatura da sala de atendimento e selecionar cenrios previamente estabelecidos. 3. Dividir o ambiente em sub-regies ou zonas de acordo com as funcionalidades que devem ser controladas Considerando que existe um ambiente nico no se fez necessrio dividir o ambiente em sub-regies de controle, necessidade tpica de sistemas maiores com controle mais complexo. 4. Selecionar funcionalidades e subsistemas que comporo o modelo Os seguintes sistemas sero utilizados para modelar esta aplicao: Controle de Iluminao (lighting) para modelar as funcionalidades controlar luminosidade interna e controlar luminosidade externa; Controle de HVAC (HVAC) para modelar a funcionalidade controlar temperatura Controle de Intruses (intrusion) para modelar a funcionalidade detectar e comunicar intruso; Controle de Acessos (Acess) utilizada para permitir o habilitao/desabilitao do sistema de intruses apenas usurios habilitados; Controle de Venezianas (Blind) para modelar a funcionalidade controlar cortina; Controle de Incndio (Fire) para permitir a modelagem da funcionalidade detectar e comunicar fogo; A funcionalidade controlar irrigao foi modelada de maneira independente de qualquer dos subsistemas especificados no framework com o objetivo de demonstrar possibilidade de expandir os subsistemas definidos, usando-se os mesmos conceitos que suportam os subsistemas definidos na proposta. Na Figura 5.11 pode ser observado o detalhamento da funcionalidade controlar temperatura, usando as funcionalidades que foram modeladas para o subsistema de controle de HVAC no framework, conforme Figura 3.4

Comportamento Aberta durante o dia quando controle de intruso estiver desabilitado; Fechar quando temperatura externa for maior do que 260C; Fechar ao habilitar controle de Intruso; Abrir quando intruso detectada; Permitir comando manual com prioridade sobre o automtico por um tempo pr-determinado. Emitir alarme local em caso de intruso; Abrir cortina e quando noite acionar iluminao. Emitir alarme local em caso de deteco de fogo; Ajustar o nvel de deteco a ocupao do ambiente. Acionar diariamente as 18h; Manter acionado por 5mim.

78

AtuadorAquec

AtuadorResf

AtuadorVent

Aquecer use

Resfriar use Controlar Temperatura use use

Ventilar SensTempInt Controlar Temp. Int. Controlar Temp. Ext Controlar Presena Controlar Estado Intruso SensTempExt

use

InterfUs

Controlar Cenario HVAC use Controlar Calendrio use

use use use

SensOcup

Controlar Horario

SensIntruso

Calendrio

Relgio

Figura 5.11 : Detalhamento das funcionalidades Pode-se observar nesta figura que as funcionalidades ControlExtSensors e ControlSensors definidas na Figura 3.4 foram expandidas a fim de permitir a modelagem da funcionalidades que garantiro o comportamento desejado desse subsistema. Outra caracterstica que pode ser observada que a modelagem da funcionalidade ControlHVAC, representada nesse diagrama pela funcionalidade Controlar Temperatura, utiliza apenas as funcionalidades que permitem implementar o controle de temperatura que foi especificado para o ambiente (aquecer, resfriar e ventilar). No anexo C podem ser encontrados os diagramas que representam as funcionalidades a serem implementadas pelos demais subsistemas. 5. Definir as polticas de operao de cada subsistema A partir da anlise do comportamento desejado, foram modelados diferentes trs estados de ocupao para o ambiente: ocupado para quando o sistema de intruso estiver desativado; desocupado para quando ele estiver ativado; alarme para quando o sistema de intruso for acionado. A seguir ser detalhado o comportamento desejado, com foco para cada subsistema: Subsistema de controle de iluminao: o Se luminosidade interna maior do que Y lumens: L1 e L2 desligadas; o Se luminosidade interna entre X e Y lumens: L1 desligada e L2 Ligada; o Se luminosidade interna menor do que X lumens: L1 e L2 ligadas; o Se noite: ligar L3 com 100%; o Se noite, aps as 24h: ligar L3 com 50%; o Quando estado de ocupao = desocupado ou quando e o controle presena indicar que o ambiente est desocupado: L1 e L2 desligados; o Quando estado de ocupao = alarme, se noite: L1, L2 e L3 ligados; o L1, L2 e L3 podem ser acionadas manualmente. O comando manual tem prioridade durante um tempo de 15min sobre os demais comandos, exceto se controle de intruso for ativado.

79

Subsistema de controle de temperatura: o Manter a temperatura em 220C (parmetro altervel pelo usurio); o A partir das 18h quando a sala estiver desocupada o subsistema dever apenas ventilar; o Quando controle de intruso estiver ativado dever ser desligado; o Nos dias teis, mesmo com o controle de intruso ativado no dever desligar no horrio de almoo (intervalo das 12h s 14h); o Nos dias teis a partir das 7h o controle de temperatura dever estar ligado.Se at s 9h no houver ocupao no ambiente, ele deve ser desligado. Subsistema de controle de cortinas: o A cortina dever estar aberta durante o dia quando a sala quando o sistema de intruso estiver desativado; o Se a temperatura externa for maior do que 260C a cortina dever ser fechada; o Quando o ambiente estiver desocupado ela dever ser fechada; o A cortina dever abrir quando a sala estiver em alarme; o Permitir comando manual. Os comandos manuais tm prioridade durante um tempo de 15min sobre os demais comandos, exceto se controle de intruso for ativado; Subsistema de controle de acesso: o O usurio dever ser identificado aps abrir a porta para desacionar o sistema de controle de intruso, sempre que ele for o primeiro a entrar na sala. O procedimento semelhante realizado na sada da sala, quando ele for o ltimo a deixar o ambiente. Subsistema de controle de intruses: o Se o sistema de controle de acesso autenticar o usurio, o sistema de controle de intruso muda para estado habilitado aps um tempo X se ele estiver no estado ocupado ou para o estado desabilitado imediatamente se ele estiver no estado desocupado ou no estado de alarme. o Aps entrar na sala, se o sistema de intruso estiver habilitado, o usurio possui um tempo Y para desabilitar o sistema, caso contrrio o sistema de intruso passa para o estado de alarme; o Se o sistema de intruso entrar no estado de alarme dever emitir um sinal sonoro; Subsistema de controle de Incndio: o Ajustar o nvel de deteco conforme a ocupao do ambiente (considerando se o sistema de controle de intruso est habilitado ou desabilitado); o Emitir um sinal sonoro em caso de deteco de fogo. Subsistema de controle de irrigao: o Ligar diariamente s 18h e manter ligado por 15min. 6. Selecionar os dispositivos lgicos e suas conexes A partir das funcionalidades especificadas na no item 4 foram selecionados os dispositivos lgicos necessrios para representar cada funcionalidade. A tabela Tabela 5.2 mostra o equivalncias entre as funcionalidades especificadas e o dispositivo lgico usado para modelagem. Ao definir-se o dispositivo lgico que ser usado para representar cada funcionalidade deve-se analisar o comportamento desejado para o subsistema e

80

determinar a classe de origem do mesmo. Por exemplo, deve-se determinar se um dispositivo lgico necessrio para modelar uma varivel de controlada, derivado da classe Sensor, ser um AnalogSensor, um BinarySensor ou um MultistateSensor.. Tabela 5.2 : Definio dos Dispositivos Lgicos
Controlar Luminosidade Externa Controlar Luminosidade Interna Controlar Presena Indicar Status do Ambiente (desocupado/ocupado/alarme) Operao Manual L1 Operao Manual L2 Operao Manual L3 Controlar Horrio Controlar Calendrio (dias teis) Controlar Temperatura Interna Controlar Temperatura Externa Indicar cortina aberta Indicar cortina Fechada Operao Manual Cortina (open/ close) Detectar Intruso Detectar Fogo Identificao do Usurio (no acesso) Setpoint do HVAC Controlar Temperatura Controlar L1, L2 e L3 Controlar Cortina atendimento Indicar alarme de incndio Indicar alarme de intruso Controlar Temperatura Controlar Cortina Temporizadores Iluminao HVAC + Cortina Incndio Intruso Irrigao Cadastro de Usurios (autenticar Usurio) Funes associadas a variveis de entrada ExtLightSensor (analogSensor) IntLightSensor (analogSensor) OcupSensor (binarySensor) StatusSensor, StatusActuator (multistateSensor/Actuator) ManualL1 (binarySensor) ManualL2 (binarySensor) ManualL3 (binarySensor) Clock Callendar IntTempSensor (analogSensor) ExtTempSensor (analogSensor) BupSensor (binarySensor) BdownSensor (binarySensor) ManualL3 (multistateSensor) OcupSensor (binarySensor) SmokeSensor (analogSensor) IntInterface (UserInterface) HVACInterface (UserInterface) HeatActuator, CoolActuator, FanActuator (binaryActuator) LightRelay1 e LightRelay2 (binaryActuator) LightDimmer (analogActuator) BlindRelay (binaryActuator) FireAlarmRelay (binaryActuator) IntAlarmRelay (binaryActuator) HVACController (HVACController) BlindController (BlindController) Implementados nos cenrios LigthScene HVACScene FireScene IntrusionScene IrrigationScene UserInfo

Na Figura 5.12 pode ser observado o modelo de uma parte do sistema correspondente aos subsistemas de HVAC e de cortina, onde alm dos dispositivos lgicos que modelam as funcionalidades especificadas pode ser observado tambm as conexes necessrias entre os dispositivos, as quais representam a interface necessria entre os dispositivos lgicos.

Base de Dados

Cenrios

Controladores

Funes associadas a variveis

Dispositivos Lgicos

Interfaces

81

Temp Int. Temp Ext. Relgio Calendrio Estado Intruso Presena Manual Cortina Cortina Fechada Cortina Aberta

IntTempSensor ExtTempSensor
Clock AnalogSensor

AnalogSensor

tempInput

HVACController

Controller

binOut binOut stateOut

BinaryActuator

CoolAcuator

Resfriador

BinaryActuator

HeatActuator

Aquecedor

Clock

setpoint/command tempInput actualTimer dataTo stateInput ocupInput switchInput bUpInput command

Scene

MultistateActuator

FanActuator

Ventilador

Callendar

Callendar

MultistateSensor

StatusSensor OcupSensor

HVACScene

userParameters

HVACInterface

UserInterface

InterfaceHVAC

BinarySensor MultistateSensor

manualBlind BUpSensor

BinarySensor

bUpnput bDownInput

BlindController

Controller

binOut

BinaryActuator

BlindRelay

Cortina

BDownSensor

BinarySensor

Figura 5.12 : Modelagem lgica Para facilitar a compreenso do diagrama, ao lado de cada dispositivo lgico foram adicionados comentrios relativos funcionalidade que est sendo modelada. O anexo C contm o modelo completo do estudo de caso. 7. Especificar os cenrios (com foco nos dispositivos selecionados) A partir das polticas, definidas no item 5 desta subseo, sero especificados os cenrios para os diferentes subsistemas com foco nas funcionalidades oferecidas pelos dispositivos selecionados no item anterior. No captulo anterior foi discutido o problema da implementao de prioridades em gerenciadores de cenrios no orientados a prioridade. As pr-condies apresentadas a seguir j implementam a soluo discutida. No Anexo C pode ser observado o detalhamento das etapas anteriores que originaram esta soluo. A seguir podem ser observadas as pr-condies, os procedimentos e os cenrios para os cenrios de iluminao e HVAC, modelados pelos dispositivos lgicos LightScene e de HVACScene. Todas as polticas especificadas no item 5 devem ser atendidas, no que se refere s pr-condies e procedimentos. LightScene Pr-condies
Nome PreA1 PreA2 PreA3 PreA4 PreA5 PreA6 PreA7 PreA8 Eventos a serem avaliados StatusSensor = Ocupado & OcupSensor = on & IntLightSensor x StatusSensor = Ocupado & OcupSensor = on & manualL1 = off & IntLightSensor > x & IntLightSensor y StatusSensor = Ocupado & OcupSensor = on & manualL1 = off & manualL2 = off & IntLightSensor > y StatusSensor = Desocupado OU OcupSensor = off StatusSensor = Ocupado & OcupSensor = on & manualL1 = on StatusSensor = Ocupado & OcupSensor = on & manualL2 = on ExtLightSensor < Z & (actualTime > 8h & actualTime =< 24h) Status <> Alarme & manualL3 = off & ExtLightSensor < Z & (actualTime > 0h & actualTime =< 8h)

82

PreA9 PreA10 PreA11

StatusSensor <> Alarme & manualL3 = off & ExtLightSensor > Z StatusSensor <> Alarme & manualL3 = on StatusSensor = Alarme & IntLightSensor < y

Procedimentos
Nome ProcA1 (Ligar L1 manual) ProcA2 (Ligar L2 manual) ProcA3 (Ligar L1 e L2) ProcA4 (Desligar L1 e Ligar L2) ProcA5 (Desligar L1 e L2) ProcA6 (Ligar L3 100%) ProcA7 (Ligar L3 Manual) ProcA8 (Ligar L3 com 50%) ProcA9 (Desligar L3) ProcA10 (L1, L2 e L3 ligados) Dispositivos lgicos a serem acionados LigthRelay1 = on [durao 15min] LigthRelay2 = on [durao 15min] LigthRelay1 = on; LigthRelay 2 = on LigthRelay1 = off; LigthRelay 2 = on LigthRelay1 = off; LigthRelay 2 = off LightDimmer = on LightDimmer = on [durao 15min] LightDimmer = onValue (50) LightDimmer = off LigthRelay1 = on; LigthRelay 2 = on; LightDimmer = on

Cenrios
Nome CenA1 (Luminosidade menor do que X) CenA2 (Luminosidade entre X e Y) CenA3 (Luminosidade maior do que Y) CenA4 (Iluminao: sala desocupada) CenA5 (Acionamento manual de L1) CenA6 (Acionamento manual de L2) CenA7 (L3: noite antes 24h) CenA8 (L3: noite aps 24h) CenA9 (L3: durante o dia) CenA10 (Acionamento manual de L3) CenA11 (Alarme acionado durante a noite) Prior 10 10 10 12 11 11 10 10 10 11 40 Descrio do Cenrio SE PreA1 ENTO ProcA3 SE PreA2 ENTO ProcA4 SE PreA3 ENTO ProcA5 SE PreA4 ENTO ProcA5 SE PreA5 ENTO ProcA1 SE PreA6 ENTO ProcA2 SE PreA7 ENTO ProcA6 SE PreA8 ENTO ProcA8 SE PreA9 ENTO ProcA9 SE PreA10 ENTO ProcA7 SE PreA11 ENTO ProcA10

HVACScene Pr-condies
Nome PreB1 PreB2 PreB3 PreB4 PreB5 PreB6 PreB7 PreB8 PreB9 PreB10 PreB11 PreB12 Eventos a serem avaliados ((actualTime < 18h & actualTime > 07h) OU OcupSensor = on) & ExtTempSensor > HVACController.setpoint actualTime > 18h & actualTime < 07h & OcupSensor = off actualTime > 07h & atualTime < 09h & StatusOfDay = dia til actualTime > 12h & atualTime < 14h & StatusOfDay = dia til (((actualTime < 07h & atualTime > 09h) OU (actualTime < 12h & atualTime > 14h) OU StatusOfDay <> dia til) & StatusSensor = Desocupado StatusSensor = Ocupado manualBlind = off & ExtTempSensor < 260C & StatusSensor = Ocupado & ExtLgihtSensor > Z manualBlind = off & ExtTempSensor >= 260C StatusSensor = Desocupado StatusSensor = Alarme StatusSensor = Ocupado & manualBlind = Open StatusSensor = Ocupado & manualBlind = Close

Procedimentos
Nome Dispositivos lgicos a serem acionados

83

ProcB1 (Selecionar modo=refrigerao) ProcB2 (Selecionar modo=aquecimento) ProcB3 (Selecionar modo=ventilao) ProcB4 (Executar controle) ProcB5 (Desativar controle) ProcB6 (Abrir cortina) ProcB7 (Fechar cortina) ProcB8 (Abrir cortina manual) ProcB9 (Fechar cortina manual)

HVACController.setmode = cool HVACController.setmode = hot HVACController.setmode = fan HVACController.runControl HVACController.deactivateControll BlindController.up BlindController.down BlindController.up; manualBlind = open[durao 15min] BlindController.down; manualBlind = close[durao 15min]

Cenrios
Nome CenB1 (HVAC: setar modo = Refrigerao ou Aquecimento) CenB2 (HVAC: noite, sala desocupada) CenB3 (HVAC: dia til entre 7 e 9h) CenB4 (HVAC: intruso ativado entre 12 e 14h) Nome CenB5 (HVAC: intruso = ativado) CenB6 (HVAC: intruso = desativado) CenB7 (Cortina durante o dia) CenB8 (Cortina temperatura externa maior 26 graus) CenB9 (Cortina: Intruso = ativado) CenB10 (Cortina: Intruso = alarme) CenB11 (Cortina: abrir manual) CenB12 (Cortina: fechar manual) Prior Descrio do Cenrio 10 SE PreB1 ENTO ProcB1 SENAO ProcB2 11 SE PreB2 ENTO ProcB3 11 SE PreB3 ENTO ProcB4 11 SE PreB4 ENTO ProcB4 Prior Descrio do Cenrio 10 SE PreB5 ENTO ProcB5 10 SE PreB6 ENTO ProcB4 10 SE PreB7 ENTO ProcB6 11 SE PreB8 ENTO ProcB7 13 SE PreB9 ENTO ProcB7 40 SE PreB10 ENTO ProcB6 12 SE PreB11 ENTO ProcB8 12 SE PreB12 ENTO ProcB9

A mesma metodologia utilizada para a construo dos demais cenrios. O conjunto completo dos cenrios pode ser encontrado no Anexo C. 8. Realizar mapeamento tecnolgico Nesta etapa os dispositivos lgicos selecionados sero mapeados para dispositivos fsicos/unidades oferecidas pela arquitetura. A Tabela 5.3 mostra onde esto mapeados os dispositivos lgicos na arquitetura alvo. Tabela 5.3 : Implementao dos dispositivos lgicos
Dispositivo lgico HomeSystems IntLightSensor (var) IntLightSensor Systembox scripts ExtLightSensor (61) ExtLightSensor OcupSensor (62) MovSensor (var) OcupSensor StatusSensor, (var)StatusSensor StatusActuator Systembox scripts ManualL1 (108) Switch1 (var) ManualL1 ManualL2 (109)Switch2 (var) ManualL2 ManualL3 (110)Switch3 (var) ManualL3 Clock Relgio Interno (Systembox scripts) Callendar Calendrio Interno (Systembox scripts) IntTempSensor (06) termostato ExtTempSensor (60) ExtTempSensor BUpSensor (63) BUpSensor BDownSensor (64) BDownSensor ManualBlind SmokeSensor Dispositivo lgico IntInterface HVACInterface HeatActuator CoolActuator FanActuator LightRelay1 LightRelay2 LightDimmer BlindRelay FireAlarmRelay IntAlarmRelay IntAlarmRelay HVACController BlindController Temporizadores (111) Switch4 (var) ManualBlind (134)SmokeSensor HomeSystems Switch5 (54) CoolSp (55) HeatSp (53) HeatActuator (52) CoolActuator (56) FanActuator (70) LightRelay1 (71) LightRelay2 (17) LightDimmer (72) BlindRelay (75) FireAlarmRelay (74) IntAlarmRelay (76) IrrigRelay (006) Termostato + Systembox - scripts Systembox - scripts Systembox - scripts

84

LigthScene HVACScene FireScene IntrusionScene

Nesta tabela pode-se observar que os dispositivos lgicos so mapeados de trs formas distintas: atravs de uma unidade de um dispositivo fsico (quando aparece um nmero entre parentes que representa o endereo do canal onde est implementado o dispositivo lgico); atravs uma varivel interna (quando aparece a expresso var entre parnteses); atravs da programao de scripts na unidade central (systembox). A Figura 5.13 mostra a tela onde podem ser observadas as variveis que esto sendo utilizadas.

Systembox - scripts Systembox - scripts Systembox - scripts Systembox - scripts

WaterScene UserInfo

Systembox - scripts Systembox scripts (var)userSearch

Figura 5.13 : Variveis As variveis permitem representar funcionalidades que podem ser manuseadas de forma independente dos dispositivos fsicos. Elas permitem representar o estado de um subsistema tais como StatusSensor, userSearch, manualL1, manualL2, manualL3, manualBlind, ocupSensor e tambm funcionalidades que podem ser obtidas indiretamente, sem a necessidade de um dispositivo fsico. Para ilustrar uma aplicao deste segundo caso, o dispositivo lgico ExtTempSensor foi modelado atravs da varivel IntLightSensor que obtida por operaes matemticas a partir do valor de ExtLightSensor, BUpSensor e BDownSensor. A Figura 5.14 mostra a rvore de dispositivos da configurao que implementa o estudo de caso. Nela podem ser encontrados os dispositivos fsicos onde so implementados os dispositivos lgicos citados anteriormente.

85

Figura 5.14 : Dispositivos mapeados Embora o estado de um subsistema possa estar associado ao estado de um determinado dispositivo, interessante implement-lo usando variveis a fim de permitir que o ele possa ser alterado tambm por outras condies alm do dispositivo com a qual est associada. Um exemplo tpico em que isto deve ser levado em conta a deteco de acionamentos manuais, uma vez que em muitos casos deve-se resolver problemas de conflito e no apenas o estado do dispositivo fsico suficiente para determinar o estado do subsistema em questo, o estado atual do e o estado de outros dispositivos podem ser necessrios para definir o estado futuro do sistema. Alm das variveis definidas na tabela de mapeamento, as variveis modoHVAC e runControl so utilizadas para permitir a implementao de parte do controle do Ar Condicionado que no implementado pelo controlador do termostato e sim por scripts do systembox. A Figura 5.15 mostra uma vista da tela de scripts do commander: na coluna da esquerda esto as precondies e na coluna da direita os procedimentos que esto associados a cada precondio. Esta associao corresponde implementao de um cenrio do modelo.

86

Figura 5.15 : Vista parcial dos eventos programados Como a ferramenta no permite especificar nomes para os cenrios, a fim de permitir a observao da equivalncia entre o modelo e a implementao, os nomes das precondies da implementao correspondem a uma combinao do nome adotado para a precondio com o nome adotado para o cenrio no modelo. O nome adotado para o procedimento corresponde exatamente ao nome adotado para o procedimento no modelo. Nesta figura podem ser observados dois destaques. Os cenrios destacados em A, so necessrios para atualizar o valor das variveis que representam estados (manualL1, manualL2, manualL3, manualBlind) de acordo com eventos gerados por um dispositivo fsico disponvel em hardware (por exemplo uma tecla de um painel de comando) e para permitir a atualizao da varivel IntLightSensor que obtida indiretamente pela operao sobre outras funcionalidades disponveis. Estes cenrios no faziam parte do modelo e foram necessrios tendo em vista que a funcionalidade foi mapeada em variveis, as quais devem ser atualizadas conforme as condies do ambiente. O segundo destaque, os cenrios destacados em B, mostra a implementao manual (atravs dos scripts) de uma parte do controle que no executado pelo hardware de controle do HVAC, o termostato. Isto necessrio porque a implementao do termostato s permite a fazer o lao de controle local, lendo a temperatura interna e atuando sobre o atuador que esteja ativado no momento (refrigerao, aquecimento ou ventilao) a fim de manter o setpoint especificado. Assim como no modelo, a atividade de controle previa a leitura da temperatura externa (ExtTempSensor) e a seleo automtica do modo de funcionamento, esta etapa do controle teve que ser especificada atravs de cenrios no systembox. A Figura 5.16 visa ilustrar todo o processo de configurao de um cenrio do modelo atravs da programao de um evento na ferramenta. A montagem

87

composta de trs partes: sobreposta janela de configurao de eventos (janela 1) est a de configurao de procedimentos (janela 2), ambas disponveis pela ferramenta de configurao e ao centro tem-se a especificao de um cenrio com as pr-condies e os procedimentos especificados no mbito do framework e extrados do estudo de caso (janela 3). Janela 1

Janela 2

Modelo

Janela 3

Figura 5.16 : Mapeamento dos Cenrios Os delimitares e as setas indicam as correspondncias entre as diversas partes representadas no modelo e onde elas esto sendo implementadas pela ferramenta de configurao. Pode-se observar a estreita relao entre o modelo e a implementao

5.4 Mapeamentos Diferentes para o Subsistema de HVAC

Esta seo tem por objetivo demonstrar diferentes modelagens possveis a partir da descrio lgica de um subsistema. Os mapeamentos descritos so possveis implementaes para o subsistema de HVAC modelado na Figura 5.12. Na Figura 5.17 pode-se observar o mapeamento usando-se os dispositivos disponveis pela arquitetura Homesystems. O termostato implementa o sensor de temperatura interna, o controlador e a interface com o usurio, conforme descrito no item 5.2. Ele possui ligao eltrica com o aparelho de Ar Condicionado, o qual implementa os dispositivos lgicos que representam os atuadores. O systembox implementa o controlador de cenrios, o relgio e o calendrio. O mdulo de entradas implementa os sensores de temperatura externa e de presena. Por simplificao, neste ltimo caso est se omitindo o hardware especifico desses sensores, conectados nas portas do mdulo de entrada.

88

Figura 5.17 : Implementao do subsistema HVAC usando apenas dispositivos disponveis pela arquitetura Homesystems. A Figura 5.18 apresenta um mapeamento diferente para o mesmo projeto lgico citado anteriormente. Esta implementao utiliza o Ar Condicionado de janela com controle eletrnico da empresa Springer-Carrier (SPRINGER, 2005), o qual alvo de projeto de pesquisa no DELET/UFRGS com objetivo de possibilitar a operao em rede destes aparelhos. Nessa soluo o aparelho de ar condicionado implementa alm dos atuadores, o controlador e os sensores de temperatura interna e externa. A interface com o usurio implementada no controle remoto do aparelho. O controlador de cenrios, o relgio e o calendrio continuam sendo implementados no systembox e sensor de presena tambm continua sendo implementado pelo mdulo de entradas. Um gateway implementa as interfaces entre os dois protocolos.

89

Figura 5.18 : Implementao do subsistema HVAC usando AC Carrier.

5.5 Consideraes Finais

O mapeamento apresentado discute diferentes possibilidades de mapeamento do mesmo projeto lgico para diferentes arquiteturas alvo. Alguns recursos disponveis no foram explorados tais como as configuraes especficas de alarme e de telefonia, os quais implicariam um outro mapeamento. Embora o mapeamento tenha sido realizado manualmente com a utilizao da ferramenta de configurao, isto , no foram editados diretamente os arquivos de configurao, acredita-se que o mapeamento automtico seja uma tarefa factvel, principalmente se forem utilizados os recursos disponveis pela tecnologia XML, conforme discutido no captulo anterior e considerando-se, obviamente, que se conhea a estrutura de armazenamento disponvel pela tecnologia alvo.

90

6 CONCLUSES E TRABALHOS FUTUROS

Este trabalho teve por objetivo principal propor um framework orientado a objetos para projeto de Sistemas de Automao Predial independente da tecnologia adotada durante a sua implementao. A fim de que os objetos especificados pelo framework sejam representativos desse domnio de aplicao e possam representar satisfatoriamente a informao dos sistemas de automao predial, foram analisados vrios padres abertos e selecionados objetos comuns entre os mesmos. A metodologia de projeto definida adota a diviso do projeto em camadas, seguindo-se as vises propostas pelo RM-ODP (Modelo de Referncia para Processamento Distribudo Aberto) da ISO. A ltima parte do trabalho teve por objetivo a validao do trabalho. Para isto uma tecnologia de mercado analisada, os conceitos propostos so mapeados para dispositivos disponveis nesta arquitetura e um estudo de caso teve por objetivo validar o processo de anlise e projeto de um sistema de automao predial suportado pelo framework. Em relao ao framework proposto, o trabalho apresenta as seguintes contribuies: a identificao de um conjunto de funcionalidades tpicas dos sistemas de automao predial, as quais foram agrupadas formando subsistemas; a definio de um conjunto de dispositivos lgicos que permitem representar estas funcionalidades independentes do dispositivo fsico que ser usado para implementao do sistema e a modelagem das relaes entre os dispositivos lgicos as quais permitem verificar o tipo de informao que deve ser trocada entre os diferentes dispositivos lgicos que compem cada um dos subsistemas modelados; a utilizao do conceito de cenrios como elemento fundamental para representar o comportamento dos subsistemas e a especificao dos cenrios de funcionamento baseada nas polticas de operao de cada subsistema. Como o comportamento do sistema est concentrado nos cenrios possvel acrescentar e remover comportamentos sem alterar a representao do sistema como um todo. Tambm deve ser possvel alterar a forma de representao desse comportamento sem alterar a representao e a relao entre os dispositivos lgicos modelados, ou seja, alteraes no comportamento alteraro apenas esta classe sem alterar a representao do sistema. A utilizao das camadas conceituais (vises) do RM-ODP mostrou-se uma alternativa interessante, por se tratar de um padro criado pela ISO e fornecer todo o suporte conceitual para fazer-se a transio desde as camadas de alto nvel, quando se tem apenas a especificao relativa ao domnio do problema, at a implementao fsica (de um sistema de automao predial)

91

Como um modelo bastante genrico procurou-se identificar os conceitos relevantes para o domnio dos sistemas de automao predial, ao especificar cada camada do framework. Neste sentido, o roteiro de projeto apresentado neste trabalho, tem por objetivo oferecer uma transio suave entre as diferentes camadas, com foco nos conceitos relevantes desta rea de aplicao. O roteiro busca facilitar o uso do framework proposto, uma necessidade que surgiu durante a realizao de estudos de caso ao longo do trabalho. Ele mantm as estrutura de camadas especificadas, inserindo atividades dentro de cada camada a fim de facilitar a especificao do sistema. Relativamente etapa de validao do modelo, uma questo bastante significativa que o tipo de tecnologia empregada na arquitetura alvo escolhida no havia sido avaliada na definio dos objetos componentes do modelo, uma vez que foram analisados apenas modelos de objetos de padres abertos. Mesmo assim todas as funcionalidades propostas no modelo puderam ser mapeadas para dispositivos disponveis pela arquitetura, o que aponta para a generalidade do modelo proposto. Durante a elaborao do estudo de caso a maior dificuldade encontrada foi a de configurar o sistema exatamente como havia sido modelado, o que mais uma vez demonstra o quanto crtica a passagem do projeto para a implementao, principalmente quando no se utilizam ambientes integrados. Outra questo marcante ao longo da realizao do estudo de caso foi a necessidade de reiniciar cada nova implementao praticamente do incio, sem a possibilidade de reaproveitamento de estruturas e fazer-se novamente todo o processo de configuraes de endereos para cada mdulo e para cada unidade, de criao de cada procedimento e de cada script, mesmo em se tratando de estruturas de alto nvel bastante similares a um outro caso j implementado. O mapeamento automtico, com a seleo de dispositivos fsicos na ltima etapa do projeto, reduziria os dois problemas citados nos pargrafos anteriores, permitindo que o sistema implementado seja fiel ao que foi modelado na etapa de projeto e reduzindo o retrabalho, pelo aproveitamento de padres de alto nvel. Como trabalho futuro, destaca-se a implementao de uma ferramenta computacional para suporte ao framework proposto. Numa primeira fase, a ferramenta dever permitir a representao do projeto lgico em arquivo formato XML. Na etapa seguinte devero ser implementados filtros que permitam converter as definies do modelo lgico em um formato que possa ser importado por cada ferramenta de configurao especfica de uma determinada tecnologia, a qual foi definida para implementao de determinado(s) dispositivo(s) lgico(s). Outra questo interessante modelar e experimentar outras formas de modelar o comportamento inteligente no sistema seja pela alterao da sintaxe ou pela utilizao de outras tcnicas de representao de comportamento, o que permitiria explorar o recurso oferecido no framework de definir o comportamento de forma independente da representao dos dispositivos que compem o sistema.

92

REFERNCIAS

AMARAL, J.; PIETROBOM, C. A. M. Using XML to Improve Frameworks Reuse. In: SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, SBES, 16., 2002, Gramado. Anais Porto Alegre: Instituto de Informtica, 2002. p. 254-267. ARAUJO, J. J. Anlise do Estado da Arte dos Modelos de Objetos utilizados em Sistemas de Automao Predial. 2003 Trabalho Individual (Mestrado em Cincia da Computao) Instituto de Informtica, UFRGS, Porto Alegre. ARAUJO, J. J. Protocolos de Comunicao para Sistemas de Automao Predial. 2002. 55f. Trabalho Individual (Mestrado em Cincia da Computao) Instituto de Informtica, UFRGS, Porto Alegre. ARAUJO, J. J.; PEREIRA, C. E. Anlise de protocolos de Automao Predial/Residencial. In: CONGRESSO BRASILEIRO DE AUTOMTICA, CBA, 15., 2004, Gramado. Anais ... [Rio de Janeiro]: SBA, 2004. 1 CD-ROM. ARAUJO, J. J.; PEREIRA, C. E. Object-Oriented Framework for the Design Of Home/Building Automation Systems. In: IFAC WORLD CONGRESS, 16., 2005, Prague, Czech Republic. Proceedings [S.l.:s.n.], 2005. BASTIDAS, G.; VILLANI, E.; JUNQUEIRA, F. et al. Open Distributed Supervisory System Design using Petri nets. In: IEEE INTERNATIONAL SYMPOSIUM ON INDUSTRIAL ELECTRONICS, 2003, Rio de Janeiro. Proceedings... [S.l.:s.n.], 2003. BASTIDAS, G.; MYAIGI, P. Metologia para Modelagem de Sistemas Abertos e Distrubudos para Automao Predial. In: CONGRESSO BRASILEIRO DE AUTOMTICA, CBA, 15., 2004, Gramado. Anais ... [Rio de Janeiro]: SBA, 2004. 1 CD-ROM. BATIBUS. Batibus in the first Line. Disponvel em:<http://www.batibus.com/anglais/ pre/index.htm>. Acesso em: 12 set. 2004. BECKER, R. What is an Intelligent Building? In: INTELLIGENT BUILDINGS CONGRESS, 1995, Tel-Aviv. Proceedings... [S.l.:s.n.], 1995. p.229-240. BUSHBY, S. T.; NEWMAN, H. M.; APPLEBAUM, M. A. GSA Guide to Specifying Interoperable Building Automation and Control Systems Using ANSI/ASHRAE Standard 135-1995, BACnet. [S.l.]: National Institute of Standards and Technology, 1999. 80p. Disponvel em: <fire.nist.gov/bfrlpubs/build99/ PDF/b99051.pdf>. Acesso em: 05 mar. 2003 CHO, S. Y. Framework for the Composition and Interoperation of the Home Appliances Based on Heterogeneous Middleware in Residential Networks. IEEE Transactions on Consumer Electronics, [S.l.], v.48, n.3, p. 484 489, Aug. 2002.

93

CHRISTENSEN, J. H. Basic Concepts of IEC 61499. Disponvel <http://www.holobloc.com/papers/1499_conc.zip > Acesso em: 14 jan. 2004.

em:

CIC. Common Application Language (CAL) Specification. [S.l.], 1996. 80p. Disponvel em: <http://www.cebus.org/Files/eia600.zip>. Acesso em: Acesso em: 14 jan. 2003. CIC. HomePnPTM Specification: version 1.0. [S.l.], 369p. Disponvel em: <http://www.cebus.org/Files/hpnp10.zip>. Acesso em: 14 jan. 2003. DOUGLASS, B. P. Real-Time Design Patterns: Robust Scalable Architeture for RealTime Systems. Boston: Addison-Wesley, 2003. 484p. ECHELON CORPORATION. Introduction to the LONWORKS System: version 1.0. [S.l.], 1999. Disponvel em: <http://www.echelon.com/Support/ documentation/Manuals/IntroLonWorks.pdf>. Acesso em: 11 abr. 2002. ECHELON CORPORATION. LonMark Application-Layer Interoperability Guidelines: Version 3.3. [S.l.], 2002. 135p. Disponvel em: <http://www.lonmark.org/press/ download/LYR732.pdf>. Acesso em: 05 nov. 2002. ECHELON CORPORATION. LONMARK SNVT Master List: verso 11. [S.l.], 2002. 143p. Disponvel em: <http://www.echelon.com/support/documentation/ Manuals/SNVT.pdf>. Acesso em: 17 mar. 2003. EHS. European Home Systems Specification. <http://www.ehsa.com>. Acesso em: 12 set. 2004. Disponvel em:

EIBA. Interworking. [S.l.], 1999. 42p. Disponvel em: <http://www.eiba.ru/dnld.htm>. Acesso em: 03 nov. 2002. EIBA. Introduction to the System. [S.l.], 1999. 36p. Disponvel em: <http://www.georg-luber = on linehome.de/data/introduc.pdf>. Acesso em: 03 nov. 2002. EIBA. User Layer. [S.l.], 1999. 20p. Disponvel em: <http://www.eiba.ru/dnld.htm>. Acesso em: 03 nov. 2002. EMBASSI. The EMBASSI-project. Disponvel em: <http://www.embassi.de/ewas/ project_frame.html >. Acesso em: 15 mar. 2004. ENDERS, B.; HEVERHAGEN, T. Consistency during the Design of Function Block Adapters using Integration by the Viewpoint Framework.. In: WORLD CONFERENCE ON INTEGRATED DESIGN & PROCESS TECHNOLOGY, 6., 2002. Proceedings... [S.l.:s.n.], 2002. GAMMA, E.; HELM, R.; JOHNSON, R. et al. Padres de projeto: solues reutilizveis de software orientado a objetos. Porto Alegre: Bookman, 2000. 364 p. GOEDICKE, M.; MEYER, T.; TAENTZER, G. ViewPoint-Oriented Software Development by Distributed Graph Transformation: Towards a Basis for Living with Inconsistencies. In: IEEE INTERNATIONAL SYMPOSIUM ON REQUIREMENTS ENGINEERING, 4., 1999. Proceedings... [S.l.:s.n.], 2002. p.9299. GOMAA, H. Designing Concurrent, Distributed, and Real-Time Aplication with UML. Boston: Addison-Wesley, 2000. 785p. HOMESYSTEMS. Homepage da Empresa. <http://www.homesystems.com.br> Acesso em: 15 dez. 2004. Disponvel em:

94

SNOONIAN, D. Smart Buildings. IEEE Spectrum, [S.l.], v.4, n.8, p.18-23, Aug. 2003. ISO/IEC. ISO/IEC 10746: Open Distributed Processing - Reference Model. [S.l.], 1995. KAND, M.; MAZAHER, S.; PRNJAT, O. et al. Applying UML to Design an Interdomain Service Management Application. In: WORKSHOP ON THE UNIFIED MODELING LANGUAGE, 1., 1998. [S.l.]: Proceedings... [S.l.:S.n.], 1998. p. 201214. KNX. KNX System-Architecture. [S.l.]: Konnex Association. 2003. 32p Disponvel em: <www.konnex.org>. Acesso em: 20 jul. 2004. KU, T.-Y.; PARK, D.-H.; MOON, K.-D. A Java-Based Home Network Middleware Architecture Supporting IEEE 1394 and TCI/IP. IEEE Transactions on Consumer Electronics, [S.l.], v.48, n.3, p. 496-504, Aug. 2002. MICROSOFT CORPORATION. Understanding Universal Plug and Play: White Paper. Redmond, 2000. 45p. Disponvel em: <http://www.upnp.org/download/ UPNP_UnderstandingUPNP.doc>. Acesso em: 12 fev. 2003. MICROSOFT CORPORATION. Universal Plug and Play Device Architecture: verso 1.0. Redmond, 2000. Disponvel em: <http://www.upnp.org/download/ UPnPDA10_20000613.htm>. Acesso em: 12 fev. 2003. MIYAGI, P. E. Controle Programvel. Rio de Janeiro: Ed. E. Blcher, 1996. 194p. MOON, K.-D.; LEE, Y.-H.; SON, Y.-S. et al. Universal Home Network Middleware Guaranteeing Seamless Interoperability among the Heterogeneous Home Network Middleware. IEEE Transactions on Consumer Electronics, [S.l.], v.49, n.3, p. 546553, Aug. 2003. OMG. OMG Unified Modeling Language Specification: verso 1.5. [S.l.], 2003. 736p. Disponvel em: <http://www.omg.org/uml> Acesso em: 14 jan. 2004. OSGi. OSGi Service Platform. Release 2. [S.l.], 2001. 288p. Disponvel em: <http://www.osgi.org/resources/docs/spr2book.pdf>. Acesso em: 03 abr.2003. PETRIU, D.C.; WOODSIDE, C.M. Performance Analyses with UML. In: UML for Real: Design of Embedded Real-Time Systems. Boston: Kluwer Academic Publishers, 2003. p.220-239 REIS, L. A.; REIS, L. A. Integrao de Sistemas Uma Tendncia Irreversvel nos Edifcios Inteligentes. In: CONGRESSO BRASILEIRO DE AUTOMAO E PRDIOS INTELIGENTES, 1., 2002, Curitiba. Anais ... [S.l.], 2002. p127-135. SOMMERVILLE, I.; SAWYER, P. Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering. [S.l.]: Computing Department, Lancaster University, 1997. 34p. Disponvel em: <http://www.comp.lancs.ac.uk/computing/ research/cseg /97_rep.html > Acesso em: 03 jun. 2003. SPRINGER. Homepage da Empresa. Disponvel em: <http://www.springer.com.br> Acesso em: 10 fev. 2005. SWAN, B. The Language of BACnet-Objects, Properties and Services. [S.l.]: Alerton Technologies. 13p. Disponvel em: <http://www.gopolar.com/BACnet/ learning/langbac.html>. Acesso em: 05 mar. 2003.

95

TANENBAUM, A. S. Redes de Computadores. 4.ed. Rio de Janeiro: Campus, 1997. 923p. TANENBAUM, A. S. Sistemas Operacionais Modernos. 2.ed. So Paulo: Pearson Education do Brasil, 2003. 635p. TRIDIUM. Baja: A Java TM - based Architecture Standard for the Building Automation Industry. Richmond, VA, 2000. 10p. Disponvel em: <http://www.tridium.com/products/Baja_White_Paper.pdf >. Acesso em: 08 jun. 2002. TRIDIUM. Niagara FrameworkTM. Richmond, VA: Tridium Inc. Disponvel em: <http://www.tridium.com/products/niagara.asp>. Acesso em: 08 jun. 2004. TRIDIUM. Press Kit. Richmond, VA: Tridium Inc. Disponvel <http://www.tridium.com/company/press_kit.pdf>. Acesso em: 08 jun. 2002. UPnP. HouseStatus:1 Service Template. [S.l.], 2003. http://www.upnp.org/download/> Acesso em: 21 jun. 2004. Disponvel em: em: <

W3C. Extensible Markup Language (XML) 1.0 (Second Edition). [S.l.], 2000. 59p. Disponvel em:<http://www.w3.org/TR/2000/REC-xml-20001006.pdf> Acesso em: 9 jun. 2003. W3C. XML Schema Part 0: Primer. [S.l.], 2001. <http://www.w3.org/TR/xmlschema-0/> Acesso em: 14 jan. 2003. Disponvel em:

W3C. XML Schema Part 2: Datatypes. [S.l.], 2001. 137p. Disponvel em: <http://www.w3.org/TR/xmlschema-2/> Acesso em: 14 jan. 2003. WILS, A.; MATTTHIJS, F.; HOLVOET, T. et al. Device Discovery via Residential Gateways. IEEE Transactions on Consumer Electronics, [S.l.], v.48, n.3, p. 478-483, Aug. 2002. X10. X10 Powerline Carrier (PLC) Technology. Disponvel <http://www.x10.com/ support/technology1.htm>. Acesso em: 04 abr. 2002. em:

96

ANEXO A DETALHAMENTO DO MODELO

A.1 - Diagramas UML

Callendar
-dayOfWeek -partOfDay -statusOfDay -year

1..*

LogicalDevice
-adress: int -name: string -type: string -description: string +getAdress(): int

clock
-actualTime

Scene 1
-Scene: list -priority: int +insertScene(scene) +removeScene(scene) +execute()

1 ProcessInterface
-unit: string

Sensor
+Read(): value

Actuator
+onPerc(Per:decimal) +Off() +On()

1..* Precondition
-PreCondition: list +insertPrecondition(description:string) +removePrecondition(description:string)

1..* Procedure
-Procedure: list +insertProcedure(description:string) +removeProcedure(description:string)

Controller
-setpoint: decimal +activate() +deactivate() +runControll() +setSetpoint(setpoint:decimal) +getSetpoint(): decimal

1..* actuate

SubSystem 1..* 1..* Channel

-qoSParameters: list +setQoSParameter() +start() +stop() +pause()

SimpleDevice
-listChannels: list +addChannel(Ident:int): boolean +removeChannel(Ident:int): boolean

UserInterface
-new parameter: boolean -parameter: string +activate() +deactivate() +getParameter(): string +dysplayParameter(parameter:string)

Persistent
-Size -CurrentPosition +Read(): data +Write(data) +search(data): int +remove(data): boolean

SignalChannel

MessageChannel

FlowChannel
-coding: string -flow QoSPar : array +addFlow (TypeFlow ) +removeFlow (TypeFlow ) +changeQoSFlow ()

CommunicationInterface
-rate -codif ication

DataFlow

AudioFlow

VideoFlow

MultimediaFlow

Figura A.1: Viso geral do modelo (viso de informao)

97

IncreaseLighting

DecreaseLighting

uses ControlSensors LightSensors uses ControlExtSensors ExternalSensors uses

uses ControlLight

uses

LightActuator uses ControlScene

Figura A.4: Funcionalidades do subsistema de controle iluminao

MultistateSensor

SceneSelector

BinarySensor

OcupSensor

BinarySensor

Switch

AnalogSensor

LightSensor

Sensor
+Read():

Scene
-Scene: list -priority: int +insertScene(scene) +removeScene(scene)

0..* 1

1..* 1 LightingSubsystem 1 1..* Actuator

+onValue( +Off()

LightController 1 1..*
+on() +off() +increase() +decrease()

Controller
-setpoint: decimal +deactivateControl() +runControll() +setSetpoint(setpoint:decimal) +getSetpoint(): decimal

BinaryActuator

LigthRelay

AnalogActuator

Dimmer

Figura A.3: Diagrama de Classe do subsistema de controle de Iluminao.

LightController
AnalogSensor

LightSensor

lightInput

+on() +off() +increase() +decrease()

levelOut
BinarySensor BinarySensor AnalogActuator

Switch

switchInput ocupInput

LightRelay

setpoint/command lightInput

Dimmer

BinarySensor

OcupSensor

switchInput ocupInput

binOut

levelOut

MultistateSensor

SceneSelector

sceneSelect

LightScene

Scene

Figura A.4: Diagrama de contexto do subsistema de controle de iluminao

98

Authenticate uses IdentifyUser User uses

Authorize AcessActuators

uses

ControlAcess uses uses NotifyUser User

ControlExtSensors ExternalSensorsst

uses

ControlScene

Figura A.5: Funcionalidades do subsistema de controle de acessos

Scene
-Scene: list -priority: int +insertScene(scene)

1..* Actuator
+onPerc(Per:decimal) +Off() +On()

NotInterface UserInterface IdentInterface

1 1..*

AccessSubsystem 1

1 1..*

1..* 1..*
BinaryActuator

PolicyInfo

UserInfo

AcessRelay

Persistent
-Size -CurrentPosition +Read(): data +Write(data)

Figura A.6: Diagrama de Classe do subsistema de controle de acessos.

BinaryActuator

AcessRelay

binOut
UserInterface

Persistent

NotInterface

userNot userId

AccessScene

Scene

dataTo dataTo

PolicyInfo UserInfo

Persistent

UserInterface

IdentInterface

Figura A.7: Diagrama de contexto do subsistema controle de acessos

99

DetecIntrusion uses ControlSensors IntrusionSensors ControlScene uses ControlExtSensors ExternalSensors IntrusionActuators uses uses CommuncateIntrusion

Figura A.8: Funcionalidades do subsistema de intruses

BinarySensor

OcupSensor

WindowSwitch

BinarySensor

BinarySensor

Switch

Controller

Sensor
+Read(): value AnalogActuator BinaryActuator

1..* timer
-time: real -timeout: boolean +getTimeout(): boolean

IntrusionAnalogOut 1 1 1..* Actuator

+onPerc(P +Off()

0..* 1..*

IntrusionSubsystem 1

IntrusionRelay

IntrusionMultistateOut 1..* Scene

-Scene: list -priority: int

MultistateActuator

1..* ExternalInterface

UserInterface

+insertScene(scene)

Figura A.9: Diagrama de Classe do subsistema de controle de intruses.

timer

activate timeout WindowSwitch

BinarySensor BinarySensor AnalogActuator

winInput ocupInput switchInput

Scene
-Scene: list -priority: int +insertScene(scene)

levelOut binOut stateOut

IntrusionAnalogOut
BinaryActuator

OcupSensor Switch

IntrusionRelay

BinarySensor

commands Alarm

IntrusionMultistateOut

MultistateActuator

ExternalInterface

Figura A.10: Diagrama de contexto do subsistema de controle de intruses

100

Open

Close

uses ControlSensors PositionSensors uses

uses

uses

ControlBind

ControlExtSensors ExternalSensors

uses

ControlScene

Figura A.11: Funcionalidades do subsistema de controle persianas.

AnalogSensor

BLevelSensor

BinarySensor

Switch

BinarySensor

BUpSensor

BDownSensor

BinarySensor

Sensor
+Read(): value

1..* Scene
-Scene: list -priority: int +insertScene(scene) +removeScene(scene)

1 0..* 1 BlindSubsystem 1 1..* Actuator

+onPerc(Per:decimal) +Off() +On()

BlindController 11..*
+dow n() +up() +move(level:decimal)

Controller

AnalogActuator

BlindAnalogOut

BinaryActuator

BlindRelay

Figura A.12: Diagrama de Classe do subsistema de controle de persianas.

BinarySensor

BUpSensor

BDownSensor
BinarySensor

BinarySensor

bUpInput bDownInput switchInput bLevelInput

BlindController
+dow n() +up() +move(level:decimal)

BinaryActuator

binOut levelOut

BlindRelay

Switch

AnalogActuator

BlindAnalogOut

AnalogSensor

BLevelSensor

setpoint/command Scene
-Scene: list -priority: int +insertScene(scene) +removeScene(scene)

Figura A.13: Diagrama de contexto do subsistema de controle de persianas.

101

CommunicateFire User FireSensors DetectFire uses ControlSensors uses ControlSprinkler uses ControlFire uses ControlDoors uses ControlDumpers uses

DoorActuators

DumpersActuator

Figura A.14: Funcionalidades do subsistema de controle de incndios

AnalogSensor

SmokeSensor

BinarySensor

FDoorSensor

AnalogSensor

TempSensor

BinarySensor

DampSensor

Sensor
+Read(): value

1..* 1..* 1 1..* 1..*

1..* 1 ExternalInterface 1..* 1 FireSubsystem 1..* UserInterface 1

FireController SprinkController Controller DampController FireDoorController

Actuator
+onPerc(P +Off()

BinaryActuator

DampActuator

FireDoorActuator

BinaryActuator

BinaryActuator

PumpActuator

AnalogActuator

BinaryActuator

FireAnalogOut

AlarmRelay

BinaryActuator

SprinkActuator

MultistateActuator

FireMultistateOut

Figura A.15: Diagrama de Classe do subsistema de controle de incndios.

ExternalInterface alarm commands
AnalogSensor

AnalogActuator

FireAnalogOut FireRelay

SmokeSensor

smokeInput tempInput

Scene
-Scene: list -priority: int +insertScene(scene)

levelOut binOut stateSelect

BinaryActuator

AnalogSensor

TempSensor

MultistateActuator

FireMultis tateOut

command

command

command

SprinkController

DampController dampInput

FireDoorController FDoorInput binOut

BinarySensor

binOut binOut
BinaryActuator

binOut
BinarySensor

PumpActuator

DampSensor

FDoorSensor

BinaryActuator

BinaryActuator

SprinkActuator

DampActuator

FireDoorActuator

BinaryActuator

Figura A.16: Diagrama de contexto do subsistema de controle de incndios

102

A.2 - Descrio de Atributos e Mtodos Tabela A.1: Descrio do Dispositivo Fsico

Atributos absLocalization relLocalization groupAdress vendorName deviceName model description systemStatus objectList Mtodos PhysicalDevice Modela o dispositivo fsico Finalidade / Tipo Endereo absoluto do dispositivo na rede. Tipo: int. Endereo relativo do dispositivo na rede. Tipo: string Lista de grupos ao qual o dispositivo pertence. Tipo: list. Identificao do fornecedor (nome, referncia, etc.). Tipo: string Identificao do nome do dispositivo. Tipo: string. Identificao da referncia do dispositivo. Tipo: string. Descrio do dispositivo. Tipo: string. Representar o estado do dispositivo. Estados possveis: ON/OFF online/offline. Tipo: string. Lista dos dispositivos lgicos. Tipo: list. Descrio

Tabela A.2: Descrio dos Dispositivos Lgicos

Mtodos e atributos herdados Mtodos e atributos herdados das classes anteriores Atributos Finalidade / Tipo adress Representa o endereo lgico. Tipo: int adressGroup Representa o grupo lgico do dispositivo Tipo: list. name Identificao do nome lgico do dispositivo. Tipo: string. description Descrio do dispositivo. Tipo: string. type Tipo: string. listChannels Representa a lista de conexes lgicas.Tipo: list Mtodos Descrio addChannel (Ident:int): boolean Mtodo para gerenciamento de conexes lgicas removeChannel (Ident:int): Mtodo para gerenciamento de conexes lgicas boolean AnalogSensor Objeto cujas propriedades representam as caractersticas visveis de um dispositivo fsico entrada analgico Atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: decimal defaulValue Representa o valor default. Tipo: decimal resolution Representa o incremento de variao do valor atual. Tipo: decimal maxPresValue Representa o valor mximo permitido para o valor atual. Tipo: decimal highLimit Representa um valor prximo de valor mximo.Tipo: decimal minPresValue Representa o valor mnimo permitido para o valor atual Tipo: decimal lowLimit Representa um valor prximo de valor mnimo.Tipo: decimal Mtodos Descrio Read(): presentValue Devolve o valor do atributo presentValue AnalogActuator Objeto cujas propriedades representam as caractersticas visveis de um dispositivo de sada analgico atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: decimal defaulValue Representa o valor default. Tipo: decimal resolution Representa o incremento de variao do valor atual. Tipo: decimal maxPresValue Representa o valor mximo permitido para o valor atual. Tipo: decimal

103

highLimit minPresValue lowLimit Mtodos onValue(parameter:data) on() off()

Representa um valor prximo de valor mximo.Tipo: decimal Representa o valor mnimo permitido para o valor atual Tipo: decimal Representa um valor prximo de valor mnimo.Tipo: decimal Descrio Altera o valor do atributo presentValue para o valor estabelecido entre 0 e 100% Altera o valor do atributo presentValue para 100% Altera o valor do atributo presentValue para 0

BinarySensor Objeto cujas propriedades representam as caractersticas visveis de um dispositivo de entrada que pode ter apenas dois estados Atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: boolean defaulValue Representa o valor default. Tipo: boolean persistence Representa o comportamento quando na alterao do valor atual. Estados possveis: momentary/persistent. Tipo: boolean polarity Indica a polaridade na posio de inicial. Estados possveis: NA / NF .Tipo: boolean Mtodos Descrio Read(): presentValue Devolve o valor do atributo presentValue BinaryActuator Objeto cujas propriedades representam as caractersticas visveis de um dispositivo de sada que pode ter apenas dois distintos estados Atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: boolean defaulValue Representa o valor default. Tipo: boolean persistence Representa o comportamento quando na alterao do valor atual. Estados possveis: momentary/persistent. Tipo: boolean polarity Indica a polaridade na posio de inicial. Estados possveis: NA / NF .Tipo: boolean Mtodos Descrio onValue(parameter:data) Atribui 0 ou 1 para o atributo presentValue on() Altera o valor do atributo presentValue para 1 off() Altera o valor do atributo presentValue para 0 MultistateSensor Objeto cujas propriedades representam as caractersticas visveis de um dispositivo de entrada que pode ter mltiplos estados Atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: byte defaulValue Representa o valor default. Tipo: byte numberPositions Nmero de estados possveis.Tipo: byte persistence Representa o comportamento quando na alterao do valor atual. Estados possveis: momentary/persistent. Tipo: boolean Mtodos Descrio Read(): presentValue Devolve o valor do atributo presentValue MultistateActuator Objeto cujas propriedades representam as caractersticas visveis de um dispositivo de sada que pode ter mltiplos estados Atributos Finalidade / Tipo unit Unidade fsica que est sendo representada. Tipo: string presentValue Representa o valor atual. Tipo: byte

104

defaulValue numberPositions persistence Mtodos onValue(parameter:data) on() off()

Representa o valor default. Tipo: byte Nmero de estados possveis.Tipo: byte Representa o comportamento quando na alterao do valor atual. Estados possveis: momentary/persistent. Tipo: boolean Descrio Altera o valor do atributo presentValue para o valor estabelecido entre 1 e numberPositions Incrementa 1 posio em numberPositions Altera o valor do atributo presentValue para 0 Controller Permite representar dispositivos de controle Finalidade / Tipo Representa o valor de referncia. Tipo: decimal Descrio Ativa o controlador Desativa o controlador Executa a funo de controle UserInterface Permite representar interfaces com o usurio Finalidade / Tipo Representa o dado que est sendo manipulado pela interface. Tipo: data Indica a disponibilidade de um novo parmetro. Tipo: boolean Descrio Ativa a interface Desativa a Interface

setpoint

atributos

Mtodos activate() deactivate() runControll()

Atributos parameter newParameter: boolean Mtodos activate() deactivate()

Persistent Permite representar dados persistentes armazenados em algum tipo de mdia atributos Finalidade / Tipo size Representa o tamanho da informao. Tipo: int currentPosition A posio atual no local de representao da informao. Tipo: int Mtodos Descrio read(): data Permite a leitura de um contedo com um determinado formato write(data) Permite a escrita de um contedo com um determinado formato search(data): int Permite a localizao de um contedo com um determinado formato remove(data): boolean Permite a remoo de um contedo com um determinado formato CommunicationInterface Modelando-se a rede como um subsistema, permite representar os dispositivos de rede atributos Finalidade / Tipo rate Representa o taxa de transmisso do dispositivo. Tipo: string codification Representa o padro de codificao da informao Tipo: string

105

ANEXO B ARQUITETURA HOMESYSTEMS

B.1 - Descrio dos Mdulos Configurao Geral do dispositivo Configurao obrigatria em todos os mdulos. Nome do dispositivo (cadeia de caracteres); Endereo (inteiro entre 0 e 128); default: 100; Pool Time (0, 10s, 15s, 12s, 30s, 1min, 2min, 3min, 4min, 5min) default: 0; Desabilitado (verdadeiro/falso) default: verdadeiro; Parmetros para canais de sada Configuraes obrigatrias em todos os canais de sada Nome (cadeia de caracteres); Memorizvel (verdadeiro/falso) default: falso; Desabilitado (verdadeiro/falso) default: verdadeiro; Log (verdadeiro/falso) default: falso; Vincular mensagem de voz (verdadeiro/falso) default: falso; Gnero (masculino/feminino) default: masculino; Identificador da mensagem (cadeia de caracteres). Parmetros para canais de entrada Configuraes obrigatrias em todos os canais de entrada Nome (cadeia de caracteres); Desabilitado (verdadeiro/falso) default: verdadeiro; Log (verdadeiro/falso) default: falso; Vincular mensagem de voz (verdadeiro/falso) default: falso; Gnero (masculino/feminino) default: masculino; Identificador da mensagem (cadeia de caracteres). Painel de comandos 09 teclas e 09 leds com os parmetros especificados em item c; Na verificao do estado de uma tecla so possveis os seguintes valores: ligou, desligou, ligado, desligado e mudou de estado; Cada led pode receber um dos seguintes comandos: ligar, desligar, piscar lento e piscar rpido; Na verificao do estado de um led so possveis os seguintes valores: ligado, desligado, piscando lento e piscando rpido; Sensor Externo 2 entradas (analgicas) com os parmetros especificados em item c;

106

Uma entrada analgica pode assumir um valor entre 0 e 256 (0-100%). Comparaes podem ser feitas usando o operador igual, diferente, maior, menor, maior ou igual e menor ou igual. Rels de 8 e de 15 canais (para cada canal): 8 e 15 sadas (digitais) com os parmetros especificados em item b; Cada sada pode receber um dos seguintes comandos: ligar, desligar e toggle. Na verificao do estado de uma sada so possveis os seguintes valores: ligou, desligou, ligado, desligado e mudou de estado; Rels de 12 e de 16 canais (para cada canal): 12 ou 16 sadas (digitais) com os parmetros especificados em item b; 09 teclas e 09 leds configurados conforme especificado para o painel de comandos; Cada sada pode ser configurada conforme especificado para o rel de 8 canais 08 cenrios permitem configurar como ativado (0%) e desativado (100%) cada um dos canais para cada um dos cenrios. Dimmer 4 canais 4 sadas (analgicas) com os parmetros especificados em item b; Cada sada pode receber ser configurao entre 0 e 100%. QuickLight 09 sadas (analgicas) com os parmetros especificados em item b; 09 teclas e 09 leds configurados conforme especificado para o painel de comandos; Cada sada pode assumir um valor entre 0 e 100%. Cada sada pode ser habilitada para funcionar como digital. Parmetro: Habilitar rel para canais de 1 at 9 (verdadeiro/falso) Fade (s) (inteiro entre 0 e 255). Observao: este parmetro corresponde ao tempo de rampa; Cena inicial: nome da cena; 08 cenrios permitem configurar valores entre 0% e 100% cada um dos canais cada um dos cenrios. Entradas digitais de 8 canais 8 entradas (digitais) com os parmetros especificados em item c; Parmetro: Habilitar NF (verdadeiro/falso) default: falso; Na verificao do estado de uma entrada so possveis os seguintes valores: ligou, desligou, ligado, desligado e mudou de estado; Entradas digitais de 16 canais Parmetro: Habilitar NF (verdadeiro/falso) default: falso; 16 entradas digitais com os parmetros especificados em item c; Os estados das entradas so configurados conforme especificado para entradas digitais de 8 canais. 2 entradas (analgicas) configuradas conforme especificado para o sensor externo; 16 teclas e 16 led configurados conforme especificado para o painel de comandos. Termostato Configurao geral do dispositivo: - Temperatura de aquecimento: temperatura inferior e temperatura inferior (tipo inteiro) - Temperatura de refrigerao: temperatura inferior e temperatura inferior (tipo inteiro)

107

- KeyLock (verdadeiro/falso) default: falso. Permite o bloqueio do teclado, no permitindo alterao manual no mesmo. - 8 canais de sada configurados conforme item b e com a seguinte especificao: COOL (sada digital, NA): permite habilitar comando remoto da refrigerao; HEAT (sada digital, NA) permite habilitar comando remoto do aquecimento; SP COOL (sada analgica): determina qual a temperatura que deve ser atingida quando se ligar COOL. SP HEAT (sada analgica): determina qual a temperatura que deve ser atingida quando se ligar COOL. FAN SPEED (sada analgica): Permite habilitar comando remoto da ventilao. Opes: 0 (automtico), 1 (velocidade 1) e 2 (velocidade 2). Modo Display (sada analgica): habilita a exibio da temperatura externa Temperatura Externa (sada analgica): ??? Temperatura Interna (sada analgica): ??? Um dispositivo denominado Termostato para aquecimento apenas as sadas HEAT e SP HEAT. Acionador de Porto (Dual) Configurao geral do dispositivo: tempo para fechar G1 default: 0; tempo aps IVA SENSE default: 0; tempo para fechar G2 default: 0; modo IVA (verdadeiro/falso) default: falso; modo noturno (motor, luz, luz+system, system e desligado) default: motor; Parmetros do G1 (idem para G2): tempo do porto aberto default: 0; tentativas para fechar default: 0; tempo de luz ligada default: 0; modo IVA (verdadeiro/falso) default: falso; modo rel (motor, luz, luz+system, system e desligado) default: motor; IVA Sensor (NA, NF, desligado) default: desligado; tempo aps IVA SENSE default: 0; Chave/Sensor (chave/sensor) default: sensor; 16 canais configurados conforme no item 2 ou 3 e com a seguinte especificao: Rel Abre/Fecha/Para G1: sada analgica. Opes: abrir, fechar, parar, toggle Sada Rel Aux G1: sada digital NA Rel Abre/Fecha/Para G2: sada analgica. Opes: abrir, fechar, parar, toggle Sada Rel Aux G1: sada digital NA Noite: sada digital NA Sensor (superior) G1: sada digital NA Sensor (inferior) G1: sada digital NA Sensor IVA G1: sada digital NA Sensor auxiliar G1: sada digital NA Sensor (superior) G2: sada digital NA Sensor (inferior) G2: sada digital NA Sensor IVA G2: sada digital NA Sensor auxiliar G2: sada digital NA 3 sadas digitais Analgicas, cdigo RF

108

Combo: 4 entradas digitais, configuradas conforme entradas digitais de 8 canais 5 sadas digitais, configuradas conforme rel de 8 canais 2 Leds 1 Leitor de carto

B.2 - Mapeamento do Modelo para a Arquitetura Homesystems Tabela A.3: Mapeamento para o Dispositivo Fsico
ATRIBUTOS MODELO absLocalization relLocalization groupAdress vendorName deviceName model description systemStatus objectList PhysicalDevice ATRIBUTO HOMESYSTEMS (arquivo hsconfig.ini) Endereo (addr) No implementado no nvel fsico (tratado pelo systembox) No implementado default HomeSystems Nome do Dispositivo (name) Conforme o dispositivo (model) No implementado Desabilitado/Habilitado (disab) Os dispositivos oferecem uma lista fixa de funcionalidades, denominado porta na arquitetura. Posteriormente cada unidade de programao (que corresponde a um dispositivo lgico no modelo) ir referenciar o dispositivo fsico onde ela est localizada. Tempo de pooling (Pooltime) Padro para o parmetro model Sadas digitais onboard = 2 Rel 12 canais = 4 Rel 16 canais = 19 Dimmer 9 canais = 7 Termostato = 10 Sensor Temperatura e luminosidade = 12 Entradas digitais 16 canais = 21 grupo = 22

Entradas digitais onboard = 1 Rel 8 canais = 3 Rel 15 canais = 5 Dimmer 4 canais = 6 Acionador de Porto dual = 20 Termostato aquecimento = 11 Entradas digitais 8 canais = 13 Painel de comando = 14

Tabela A.4: Mapeamento dos Dispositivos Lgicos

Atributos e mtodos herdados Atributo HomeSystems (arquivo hsconfig.ini) adress Endereamento automtico ao inserir o mdulo (dev + port) adressGroup O objeto grupo que possui as referncias para o endereo do dispositivo name Nome (name) description Inserido automaticamente conforme mdulo (descr ) type Permite identificar apenas se analgico ou digital (kind 0: analgico e 1: digital) listChannels No implementado AnalogSensor Implementado nos seguinte mdulos: sensor de temperatura e luminosidade, Entradas digitais 16 canais (2 canais) atributos Atributo HomeSystems (arquivo hsconfig.ini) unit No implementado presentValue Valor entre 0 e 255 que pode ser monitorado atravs de operadores relacionais nos scripts, gerando eventos. atributos

109

defaulValue resolution maxPresValue highLimit minPresValue lowLimit Mtodos Read(): presentValue

No implementado Default inteiro = 1 Dependente de programao: pode ser monitorado comparando-se com variveis. Dependente de programao: pode ser monitorado comparando-se com variveis. Dependente de programao: pode ser monitorado comparando-se com variveis. Dependente de programao: pode ser monitorado comparando-se com variveis. Implementao HomeSystems O valor atual do sensor pode ser monitorado em operadores relacionais

atravs dos scripts atravs dos scripts atravs dos scripts atravs dos scripts eventos atravs de

AnalogActuator Implementado nos seguinte mdulos: dimmer de 4 canais e dimmer de 9 canais atributos Atributo HomeSystems (arquivo hsconfig.ini) unit No implementado presentValue Valor entre 0 e 255. pode ser monitorado atravs de operadores relacionais em eventos nos scripts. defaulValue O valor default zero resolution Default inteiro = 1 maxPresValue Dependente de programao: pode ser monitorado atravs dos scripts comparando-se com variveis. highLimit Dependente de programao: pode ser monitorado atravs dos scripts comparando-se com variveis. minPresValue Dependente de programao: pode ser monitorado atravs dos scripts comparando-se com variveis. lowLimit Dependente de programao: pode ser monitorado atravs dos scripts comparando-se com variveis. Mtodos Implementao HomeSystems onValue(parameter:data) Na execuo de um procedimento corresponde a opo ligar com percentual regulvel on() Na execuo de um procedimento corresponde a opo ligar off() Na execuo de um procedimento corresponde a opo desligar BinarySensor Implementado nos seguinte mdulos: entradas digitais onboard, entradas digitais de 8 e 16 canais e painel de comando Atributos Atributo HomeSystems (arquivo hsconfig.ini) unit No implementado presentValue Os estados ligou, ligado, desligou, desligado e mudou de estado que podem ser monitorado atravs em eventos nos scripts. defaulValue O valor default desligado persistence O estado da entrada persistente. Um evento mudou de estado pode ser monitorado em eventos. Para o caso de falta de energia o estado pode ser memorizado (mem) polarity Nonc (0: Normalmente Aberto 1: Normalmente Fechado) Mtodos Implementao HomeSystems Read(): presentValue O valor atual do sensor pode ser monitorado em eventos atravs dos testes ligou, ligado, desligou, desligado e mudou de estado BinaryActuator Implementado nos seguinte mdulos: sadas digitais onboard, rels de 8, 12, 15 e 16 canais e dimmer de 9 canais (opcionalmente) Atributos Atributo HomeSystems (arquivo hsconfig.ini) unit No implementado

110

presentValue defaulValue persistence polarity Mtodos onValue(parameter:data) on() off()

Os estados ligou, ligado, desligou, desligado e mudou de estado que podem ser monitorado atravs em eventos nos scripts. O valor default desligado Conforme descrito para BinarySensor. A opo memorizvel (atributo mem) utilizada para restabelecer o estado anterior a falta de energia. Para os mdulos de entrada digital a configurao NA/NF realizada diretamente no dispositivo. Implementao HomeSystems no implementado Na execuo de um procedimento corresponde a opo ligar Na execuo de um procedimento corresponde a opo desligar

MultistateSensor / Multistate Actuator No implementado diretamente: implementaes dessa funcionalidade usam entradas / sadas analgicas com definio dos valores tais como: 0=ligado, 1=desligado, 2=parado, etc. Controller Todos os mdulos executam funo de controle especfico, de acordo com a finalidade do mdulo. Descrio Geral da Funo de Controle Todas as unidades ficam realizando pooling nas entradas/sadas e atualizando o mapa de memria com o estado atual de cada posio. Atualizaes locais no mdulo so executadas conforme programao resultante do projeto do mdulo. A cada pooling da unidade central o estado do mdulo informado ao systembox, o qual pode enviar comandos especficos para determinados mdulos. Como se pode observar o controle feito em duas camadas: uma etapa no prprio mdulo quando se tratar de atualizaes locais, conforme programao residente no mdulo e que independe de comunicao, e outra etapa, gerenciada pelo mestre rede (dependente de comunicao), resultante da execuo do programa construdo a partir dos scripts. Parmetros locais so definidos a partir da configurao do mdulo e os parmetros remotos so gerenciados pelo systembox e programados a partir dos scripts. Dois mdulos de controle com funes especficas so o Termostato e o Acionador de porto Descrio geral de mtodos para os mdulo de controle Mtodos Implementao HomeSystems activate() Configurar o mdulo como Habilitado (configurar o parmetro disab = 0) deactivate() Configurar o mdulo como Desabilitado (configurar o parmetro disab = 1) runControll() Mdulo habilitado automaticamente executa seu procedimento de controle e responde a requisies do mestre (systembox) getMode scritps setMode scrips Termostato atributos Atributo HomeSystems (arquivo hsconfig.ini) mode No implementado unit Default: 0C. O mdulo possui configurao direta que impede a determinao de setpoints fora da faixa especificada (corresponderia aos atributos do modelo maxPresValue, highLimit, minPresValue, lowLimit) setpoint Ajustado diretamente pelo usurio, via teclado, ou atravs de scripts, usando as sadas analgicas SP COOL, SP HEAT e Fan Speed. UserInterface As interfaces padro telefone e internet so funcionalidades oferecidas pelo systembox com configuraes especficas. Se considerar o painel de comando como interface sua configurao j foi abordada em BinarySensor. Se considerar o Termostato como interface, sua configurao j foi abordada em Controller Persistent

111

Alguns mdulos possuem configurao especfica de parmetros. O mdulo Combo armazena nmero de cartes, o mdulo de comando de portes armazena cdigos de RF. Os atributos e funcionalidades iro corresponder as configuraes e operao desses mdulos. As variveis utilizadas nos scripts correspondem a um meio de armazenamento em RAM, gerenciadas atravs do sistema operacional do Systembox. Operaes sobre variveis Mtodos Implementao HomeSystems read(): data O valor atual de uma varivel pode ser monitorado em eventos atravs de operadores relacionais em eventos nos scripts. write(data) Para uma varivel pode-se atribur um valor, atribuir uma varivel, atribuir uma E/S, incrementar e decrementar um valor em procedimentos nos scripts. search(data): int No implementado remove(data): boolean Uma varivel pode ser excluda atravs da ferramenta de configurao. Qualquer dado de uma varivel pode ser reescrito. CommunicationInterface No implementado

112

ANEXO C ESTUDO DE CASO

C.1 - Definio das Funcionalidades Conforme Subsistema

Atuadores Aquec Controlar Tem peratura us e Controlar Cenario HVAC us e Controlar Calendrio us e us e us e us e Controlar Es tado Intrus o Controlar Horario Relgio L1Atuator L2Atuator L3Atuator Sens Intrus us e Controlar Tem p. Int. Controlar Tem p. Ext Sens Tem pExt Controlar Pres ena Sens Ocup Sens Tem pInt

InterfUs

Calendario

Controlar L1 us e

Controlar L2 us e

Contolar L3 DiaSens or Controlar Turno Dia us e us e Controlar Horario Controlar Es tado Intrus o Controlar Op.Manual

us e us e

Controlar Cenario Ilum . us e us e

Relogio

us e

Controlar Lum . Int.

Controlar Pres ena

ManSens or

Sens Intrus Lum Sens or Controlar Cortina us e Controlar Cenario Cortina us e IntSens us e Controlar Intrus o us a Controlar Aces s o us e us e Autenticar Us urio us e Detectar Intrus o Com unicar Intrus o Sens Ocup Sens Intrus Controlar Es tado Intrus o us e us e Controlar Tem p Ext. us e Controlar Op.Manual

CortAtuador

Controlar Turno Dia

DiaSens or

ManSens or ExtTem pSe

Relogio Identificar Us urio InterfUs Controlar Horario Us Lis ta us es Controlar Irrigao

Detectar Fogo us e Controlar Fogo us e us e Com unicar Fogo

Fum Sens or Controlar Pres ena

Sens Ocup IrrigAtuador InterfUs

Figura A.17: Estudo de caso: especificao das funcionalidades

113

C.2 - Definio dos Dispositivos Lgicos

Lum.Interna Presena Estado Intrus o Manual L1 Manual L2 Manual L3
AnalogSensor

Relgio
Clock

IntLightSensor
BinarySensor

Clock

OcupSensor

MultistateSensor

lightInput ocupInput stateInput switchInput switchInput switchInput lightInput

StatusSensor manualL1 manualL2 manualL3

actualTime binOut binOut lightLevelOut

BinaryActuator

LigthRelay1 LigthRelay2

L1 L2

BinarySensor BinarySensor BinarySensor

LigthScene

Scene

BinaryActuator

AnalogActuator

LightDimmer

L3

Lum.Externa

ExtLightSensor
AnalogSensor

AnalogSensor

Temp Int. Temp Ext. Relgio Calendrio Estado Intruso Presena Manual Cortina Cortina Fechada Cortina Aberta Fumaa Estado Intruso Presena Login Usuario Relgio

IntTempSensor ExtTempSensor
Clock AnalogSensor

tempInput

HVACController

Controller

binOut binOut stateOut

BinaryActuator

CoolAcuator

Resfriador

BinaryActuator

HeatActuator

Aquecedor

Clock

setpoint/command tempInput actualTimer dataTo stateInput ocupInput switchInput bUpInput command

Scene

MultistateActuator

FanActuator

Ventilador

Callendar

Callendar

MultistateSensor

StatusSensor OcupSensor

HVACScene

userParameters

HVACInterface

UserInterface

InterfaceHVAC

BinarySensor MultistateSensor

manualBlind BUpSensor

BinarySensor

bUpnput bDownInput

BlindController

Controller

binOut

BinaryActuator

BlindRelay

Cortina

BDownSensor
AnalogSensor

BinarySensor

SmokeSens or StatusSensor OcupSensor IntInterface

Clock

s mokeInput stateInput

FireScene

Scene

binOut

BinaryActuator

AlarmRelay1

Alarme Fogo

MultistateSensor

BinaryActuator

s tateInput
BinarySensor UserInterface

AlarmRelay2

Alarme Intruso Estado Intruso Cadastro Usurios Irrigador

OcupInput UserId

IntrusionScene

Scene

binOut stateOut DataTo

MultistateActuator

StatusActuator
Persistent

UserInfo

Clock

actualTime

IrrigationScene

Scene

binOut

BinaryActuator

IrrigRelay

Figura A.18: Estudo de caso: projeto lgico

114

C.3 - Definio dos Cenrios LightScene Pr Condies: com definio de prioridades conforme cenrios
Nome PreA1 PreA2 PreA3 PreA4 PreA5 PreA6 PreA7 PreA8 PreA9 PreA10 PreA11 Prior 10 10 10 12 11 11 10 10 10 11 40

Eventos a serem avaliados IntLightSensor x IntLightSensor > x & IntLightSensor y IntLightSensor > y StatusSensor = Desocupado OU OcupSensor = off ManualL1 = on ManualL2 = on ExtLightSensorSensor < Z & (actualTime > 17h & actualTime < 24h) ExtLightSensor < Z & (actualTime > 0h & actualTime < 8h) ExtLightSensor > Z ManualL3 = on StatusSensor = Alarme & IntLightSensor < y

Pr-cond. prioritaria Eventos a serem avaliados ~PreA11 & ~PreA4 IntLightSensor x ~PreA11 & ~PreA4 & IntLightSensor > x & IntLightSensor y ~PreA5 PreA3 ~PreA11 & ~PreA4 & IntLightSensor > y ~PreA5 & ~PreA6 PreA4 ~PreA11 StatusSensor = Desocupado OU OcupSensor = off PreA5 ~PreA11 & ~PreA4 switch1 = on PreA6 ~PreA11 & ~PreA4 switch2 = on PreA7 * ExtLightSensorSensor < Z & (actualTime > 17h & actualTime < 24h) PreA8 ~PreA11 & ~PreA10 ExtLightSensor < Z & (actualTime > 0h & actualTime < 8h) PreA9 ~PreA11 & ~PreA10 ExtLightSensor > Z PreA10 ~PreA11 Switch3 = on PreA11 * StatusSensor = Alarme & IntLightSensor < y * No ocorre coliso

Nome PreA1 PreA2

Pr Condies: com definio das pr-condies prioritrias

HVACScene Pr Condies: com definio de prioridades conforme cenrios

Nome PreB1 PreB2 Prior 10 11 11 11 10 10 10 11 13 40 12 12

PreB3 PreB4 PreB5 PreB6 PreB7 PreB8 PreB9 PreB10 PreB11 PreB12

Eventos a serem avaliados ExtTempSensor > HVACController.setpoint actualTime > 18h & actualTime < 07h & OcupSensor = off & StatusSensor = Ocupado actualTime > 07h & atualTime < 09h & StatusOfDay = dia til actualTime > 12h & atualTime < 14h & StatusOfDay = dia til StatusSensor = Desocupado StatusSensor = Ocupado ExtLgihtSensor > Z ExtTempSensor > 260C StatusSensor = Desocupado StatusSensor = Alarme manualBlind = open manualBlind = close

115

Nome PreB1 PreB2 PreB3 PreB4 PreB5

Pr Condies: com definio das pr-condies prioritrias

Prior ~PreB2 *

* * ~PreB3 & ~PreB4 PreB6 * PreB7 ~PreB8& ~PreB9 & ~Pre B10 & ~Pre B12 PreB8 ~PreB9 & ~Pre B10 ~PreB11 PreB9 * PreB10 * PreB11 ~PreB9 PreB12 ~PreB10 * No ocorre coliso

Eventos a serem avaliados ExtTempSensor > HVACController.setpoint actualTime > 18h & actualTime < 07h & OcupSensor = off StatusSensor = Ocupado actualTime > 07h & atualTime < 09h & StatusOfDay = dia til actualTime > 12h & atualTime < 14h & StatusOfDay = dia til StatusSensor = Desocupado StatusSensor = Ocupado ExtLgihtSensor > Z

&

ExtTempSensor > 260C StatusSensor = Desocupado StatusSensor = Alarme manualBlind = open manualBlind = close

IntrusionScene
Nome PreC1 PreC2 PreC3 PreC4 Nome ProcC1 ProcC2 ProcC3 ProcC4 Nome CenC1 CenC2 CenC3 CenC4 Eventos a serem avaliados UserInfo.Search (userId)> 0 & StatusSensor = Ocupado UserInfo.Search > 0 & StatusSensor = Desocupado StatusSensor = Desocupado & OcupSensor = on StatusSensor = Alarme

Pr-condies

Procedimentos
Dispositivos lgicos a serem acionados Esperar [X]; StatusSensor = Desocupado StatusSensor = Ocupado Esperar [Y]; StatusSensor = Alarme; IntrAlarmeRelay = on IntrAlarmeRelay = on

Cenrios
Prior 40 40 40 40 Se Se Se Se Descrio do Cenrio PreC1 ENTO ProcC1 (Desativar: usurio reconhecido) PreC2 ENTO ProcC2 (Ativar: usurio reconhecido) PreC3 ENTO ProcC3 (Intruso detectada) PreC4 ENTO ProcC4 (Alarme Acionado)

FireScene Pr-condies
Nome PreD1 Eventos a serem avaliados (StatusSensor = Ocupado & SmokeSensor > Y) OU (StatusSensor = Desocupado & SmokeSensor > X)

Procedimentos
Nome Dispositivos lgicos a serem acionados

116

ProcD1 Nome CenD1

FireAlarmeRelay = on

Cenrios
Prior 50 Descrio do Cenrio Se PreD1 ENTO ProcD1 (Aciona Alarme de Incndio)

IrrigationScene
Nome PreE1 Nome ProcE1 Nome CenE1

Pr-condies
actualTime = 18h

Eventos a serem avaliados

Procedimentos
Dispositivos lgicos a serem acionados IrrigRelay = on [durante 5min]

Cenrios
Prior 10 Descrio do Cenrio Se PreE1 ENTO ProcE1 [durante 5mim] (Acionar Irrigao)

ANEXO D