Configuração de Sistemas Domóticos João Pereira Nunes Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. Jose Carlos Martins Delgado Orientador: Prof. Renato Jorge Caleira Nunes Vogal: Prof. Nuno Filipe Valentim Roma Setembro 2009 i Configuração de Sistemas Domóticos João Pereira Nunes ii Resumo As casas inteligentes fazem parte do presente e é preciso tornar a domótica um serviço simples e agradável de se utilizar. Actualmente a concepção, instalação e configuração de um sistema domótico é uma tarefa complexa e, normalmente, exige o uso de ferramentas dedicadas de custo elevado, concebidas para serem usadas por pessoal técnico e não pelos utilizadores comuns. É também relevante permitir que os utilizadores possam modificar as configurações de um sistema já operacional de modo a satisfazer novas necessidades ou preferências, o que as soluções actualmente disponíveis tipicamente não oferecem. Neste âmbito, no presente trabalho é apresentada a especificação de um programa para desenho e configuração de sistemas domóticos que visa simplificar o respectivo processo de configuração, instalação e reconfiguração. Este programa baseia-se no modelo DomoBus e oferece uma solução genérica, independente das particularidades das soluções comerciais disponíveis actualmente, permitindo a integração de componentes de diferentes tecnologias. O programa desenvolvido permite ainda, de forma dinâmica, modificar ou definir novos comportamentos para o sistema. Palavras-chave: Domótica, automação residencial, DomoBus, configuração de sistemas domóticos, DomoConfig iii Abstract Smart houses are the present and it is necessary to make their usage as simple and user-friendly as possible. Currently, the design, installation and configuration of a home automation system is a complex task and, normally, require expensive dedicated tools, built to be used by skilled professionals and not by common users. It is also relevant to allow users to be able to change operational system configurations to meet their new needs and preferences which, typically, are not offered by current available solutions. In this context, the present work describes – the design and implementation of a tool that simplifies the configuration process, installation and reconfiguration of home automation systems. This tool is based on DomoBus model and offers a generic solution, independent of the particularities of current commercial products, allowing the integration of components from different technologies. The proposed tool also allows, dynamically, the modification and definition of new behaviors for the system. Key-words: Home automation, House automation systems, DomoBus, configuration of home automation systems, DomoConfig iv Índice Lista de Tabelas ............................................................................................................................................. vii Lista de Figuras ............................................................................................................................................. viii Lista de Abreviaturas ....................................................................................................................................... x 1. 2. 3. 4. Introdução................................................................................................................................................. 1 1.1. Motivação ........................................................................................................................................ 1 1.2. Objectivos do trabalho ................................................................................................................... 2 1.3. Estructura da tese .......................................................................................................................... 3 Tecnologias domóticas ........................................................................................................................... 4 2.1. X10.................................................................................................................................................... 4 2.2. EIB/KNX ........................................................................................................................................... 6 2.3. LonWorks ......................................................................................................................................... 8 2.4. DomoBus ....................................................................................................................................... 11 2.4.1. Comando e monitorização ................................................................................................. 11 2.4.2. Gestão e Supervisão ........................................................................................................... 14 Ferramentas de Configuração de sistemas ...................................................................................... 18 3.1. ETS ................................................................................................................................................. 18 3.2. LonMaker ....................................................................................................................................... 21 Arquitectura da solução ........................................................................................................................ 24 4.1. 5. 6. Descrição da solução (DomoConfig) ......................................................................................... 24 4.1.1. Descrição dos módulos domóticos ................................................................................... 26 4.1.2. Descrição genérica dos dispositivos domóticos.............................................................. 28 4.1.3. Descrição da habitação ...................................................................................................... 29 4.1.4. Descrição do comportamento do sistema ........................................................................ 30 4.1.5. Configuração dos dispositivos instalados ........................................................................ 33 4.1.6. Configuração dos dispositivos ........................................................................................... 35 4.1.7. Configuração das Gateways .............................................................................................. 37 4.2. Linguagem e ambiente de desenvolvimento ............................................................................ 38 4.3. Implementação da ferramenta DomoConfig ............................................................................ 39 4.3.1. Interface do instalador e utilizador comum ...................................................................... 39 4.3.2. Interface para fabricante ..................................................................................................... 45 4.3.3. Camada de negócio da aplicação DomoConfig .............................................................. 48 4.3.4. Persistência de dados ......................................................................................................... 51 4.3.5. Organização do código ....................................................................................................... 52 Avaliação do trabalho ........................................................................................................................... 54 5.1. Casos de uso ................................................................................................................................ 54 5.2. Resultados dos testes.................................................................................................................. 54 5.2.1. Utilização da ferramenta para a criação de uma configuração .................................... 54 5.2.2. Utilização da ferramenta para a criação de um módulo domótico ............................... 56 5.3. Avaliação dos resultados ............................................................................................................ 57 5.4. Comparação de custos ................................................................................................................ 58 Conclusões............................................................................................................................................. 59 v 6.1. 7. Trabalho futuro .................................................................................................................................. 60 Referencias ............................................................................................................................................ 61 vi Lista de Tabelas Tabela 1. Resultados da tarefa Criar níveis de acesso e utilizadores .............................................. 55 Tabela 2. Resultados da tarefa Criar uma habitação com 1 piso e 2 divisões ................................. 55 Tabela 3. Resultados da tarefa Instalar os dispositivos adquiridos e coloca-los nas divisões ......... 55 Tabela 4. Resultados da tarefa Criar cenários de comportamento .................................................. 55 Tabela 5. Resultados da tarefa Guardar a configuração .................................................................. 56 Tabela 6. Resultados da tarefa Criar os tipos de dados ................................................................... 56 Tabela 7. Resultados da tarefa Criar classes para os dispositivos .................................................. 56 Tabela 8. Resultados da tarefa Criar tipos de configuração ............................................................. 57 Tabela 9. Resultados da tarefa Criar tipos de dispositivos ............................................................... 57 Tabela 10. Resultados da tarefa Criar módulos e exporta-los .......................................................... 57 Tabela 11. Comparativo de preços das ferramentas de configuração ............................................. 58 vii Lista de Figuras Figura 1. Mensagem transmitida com o código do dispositivo ........................................................... 4 Figura 2. Mensagem transmitida com o código da função ................................................................. 4 Figura 3. Tabelas de códigos da habitação, dispositivos e funções ................................................... 5 Figura 4. Arquitectura de rede do DomoBus ..................................................................................... 12 Figura 5. Arquitectura dos módulos de controlo ............................................................................... 12 Figura 6. Endereço de um dispositivo domótico na rede DomoBus ................................................. 13 Figura 7. Modelo simples de Dispositivos Genéricos ....................................................................... 14 Figura 8. Endereços na rede DomoBus ............................................................................................ 15 Figura 9. Formatos das mensagens entre aplicações e a rede DomoBus ....................................... 16 Figura 10. Estrutura do campo data de uma mensagem DomoBus ................................................. 16 Figura 11. Formato das mensagens pré-definidas ........................................................................... 16 Figura 12. Formato da mensagem do Forward ................................................................................. 17 Figura 13. ETS 3.0d Interface de utilizador ....................................................................................... 18 Figura 14. Pesquisa de dispositivos no ETS ..................................................................................... 19 Figura 15. Lista de dispositivos instalados ........................................................................................ 19 Figura 16. Configuração de parâmetros ........................................................................................... 20 Figura 17. Dispositivos nas várias linhas .......................................................................................... 20 Figura 18. Dispositivos por divisão.................................................................................................... 20 Figura 19. Arquitectura da aplicação DomoConfig ........................................................................... 25 Figura 20. Modelo da descrição dos módulos .................................................................................. 27 Figura 21. Modelo de uma habitação ................................................................................................ 29 Figura 22. Modelo de um cenário...................................................................................................... 31 Figura 23. Modelo de uma macro ..................................................................................................... 33 Figura 24. Modelo de um dispositivo ................................................................................................ 34 Figura 25. Detalhe das configurações do dispositivo (retirado da descrição dos módulos domóticos) ............................................................................................................................................................... 36 Figura 26. Modelo de configuração de uma gateway ....................................................................... 37 Figura 27. Janela principal do DomoConfig ...................................................................................... 39 Figura 28. Configuração de um dispositivo e seus serviços ............................................................. 40 Figura 29. Edição de um cenário ...................................................................................................... 41 Figura 30. Lista de expressões de uma condição ............................................................................. 41 Figura 31. Utilizadores do sistema .................................................................................................... 42 Figura 32. Níveis de Acesso ............................................................................................................. 43 Figura 33. Gestão de plug-ins ........................................................................................................... 43 Figura 34. Configuração de uma gateway ........................................................................................ 44 Figura 35. Menu da aplicação DomoConfig ...................................................................................... 45 Figura 36. Janela principal do DomoConfig em modo fabricante ..................................................... 46 Figura 37. Gestão dos tipos de configurações .................................................................................. 47 viii Figura 38. Gestão dos tipos de dispositivos genéricos ..................................................................... 47 Figura 39. Gestão de módulos .......................................................................................................... 48 Figura 40. Modelo da classe global .................................................................................................. 49 Figura 41. Diagrama de classes das habitações .............................................................................. 49 Figura 42. Diagrama da interface dos plug-ins ................................................................................. 50 Figura 43. Projecto ―DomoConfig‖..................................................................................................... 52 Figura 44. Projecto ―TiposComuns‖ .................................................................................................. 53 Figura 45. Projecto de um plug-in X10 .............................................................................................. 53 ix Lista de Abreviaturas DC DomoConfig EIB European Installation Bus EHS European Home Systems protocol ETS Engineering Tool Software LNS Local Network operating System PC Personal Computer PDA Personal Digital Assistant SBC Single Board Computer WPF Windows Presentation Foundation XML eXtensible Markup Language x 1. Introdução 1.1. Motivação A domótica é uma tecnologia que permite a gestão dos diferentes recursos presentes numa habitação. O termo ―Domótica‖ resulta da junção da palavra ―Domus‖ (casa) com ―robótica‖ (controlo automatizado de algo). É esta automação que permite simplificar a vida diária das pessoas satisfazendo as suas necessidades de conforto, de segurança e de comunicação. Quando a domótica se começou a divulgar, nos anos 80, as principais áreas de intervenção eram o controlo da iluminação, das condições climáticas e da segurança, procurando-se interligar estas três vertentes. Os sistemas domóticos oferecem inúmeras vantagens e têm vindo a aumentar de popularidade. Para isso tem também contribuído a utilização de novas tecnologias tais como a internet e o uso de dispositivos portáteis como os smartphones e PDAs. De entre as vantagens oferecidas pela domótica destaca-se o aumento do nível de conforto e de segurança, a automação de tarefas e a poupança de energia. Relativamente à poupança de energia, existem vários aspectos interessantes, nomeadamente implementar políticas de programação horária podendo apenas ligar certos equipamentos quando a energia é mais económica (nas horas de vazio), permitir desligar as luzes e o ar condicionado quando as divisões estão vazias e ainda controlar os gastos de água. Numa casa domótica, existe também a possibilidade de um melhor aproveitamento das energias renováveis produzidas em casa tais como energia solar ou eólica. No entanto, a evolução da domótica tem tido um percurso difícil. É frequente os produtos serem proprietários, não sendo possível interligar directamente produtos de fabricantes diferentes. Neste sentido, foram feitos esforços para se normalizar as tecnologias para que produtos de diferentes fabricantes possam comunicar entre si, conseguindo reduzir custos para o comprador final e aumentar a diversidade de escolha. Surgiram assim várias normas como o EIB/KNX (R. Nunes s.d.), (KNX Association 2008), (Kell e Colebrook 2004), (Harry Crijns 2004), (EIB Interworking Standards 1999) e (Weinzierl 2004), CEBus (CEBus 2009) e LonWorks (Douglas Lighting controls 2003) e (Echelon Corporation 2009). Contudo, a existência de várias normas fizeram com que o mercado se dividisse e se confundisse enquanto novas tecnologias e produtos continuavam a aparecer. Após este período, e numa tentativa de oferecer produtos a baixo custo, voltaram a divulgar-se tecnologias proprietárias utilizando produtos simples e com funcionalidades mais restritas. Embora este movimento tenha inconvenientes óbvios, acabou por, de certo modo, contribuir para a divulgação da domótica. Actualmente a norma mais divulgada a nível europeu é o KNX, o qual resultou de uma junção do EIB, EHS (European Home Systems Protocol 2008) e BatiBus (BatiBUS 2009) que é gerido pela Konnex Association (KNX Association 2008). Nesta tecnologia, a configuração dos sistemas é feita através da ferramenta ETS (KNX Association 2009), a qual permite configurar qualquer produto KNX 1 e definir diversas parametrizações, bem como descrever a estrutura da casa e identificar onde se encontram localizados os dispositivos e o meio físico de comunicação: par-entrançado ou linha de distribuição de energia. Geralmente as tecnologias domóticas não oferecem ferramentas de configuração mas, quando oferecem, estas são produtos fechados ou específicos para uma tecnologia, e vocacionados para pessoal técnico. No caso do EIB/KNX, por exemplo, a ferramenta de configuração – ETS – é muito específica, de utilização bastante complexa e cara. Devido a estes problemas, propõe-se neste trabalho a criação de uma ferramenta de configuração de sistemas domóticos que procura ser o mais genérica possível para poder funcionar com qualquer tipo de tecnologia domótica, desde que esta não seja um sistema privado e fechado e que ofereça suporte à interacção com o exterior. Ao tornar uma ferramenta genérica é importante a facilidade com que se realiza a configuração do sistema domótico a implementar e a facilidade de utilização da ferramenta. Ao oferecer uma utilização simples evitam-se erros e incorrecções no processo de configuração, aumentando assim a produtividade da ferramenta e favorecendo uma maior divulgação da domótica. A ferramenta proposta permitirá não só a criação das configurações dos sistemas domóticos e a edição de casas já existentes, mas também será possível alterar certos comportamentos da casa de modo a ajustar a casa às novas necessidades dos seus utilizadores. A ferramenta irá abranger vários tipos de configuração do sistema domótico desde níveis muito específicos e focados no hardware, por exemplo, características físicas dos dispositivos e respectivos parâmetros, assim como níveis mais altos e focados no utilizador como, por exemplo, a localização dos dispositivos numa divisão ou o nome comum dos dispositivos (para facilitar a sua identificação pelos utilizadores). Outro aspecto será a possibilidade de definir o comportamento dos dispositivos e de como estes interagem entre si. 1.2. Objectivos do trabalho O objectivo deste trabalho é conceber uma aplicação para o PC suficientemente genérica e flexível, utilizando o modelo DomoBus (P. R. Nunes 2005), (NUNES Agosto 2004), (P. R. Nunes 2006), (R. J. Nunes Maio 2006), (R. J. Nunes Julho 2003), (R. J. Nunes Fevereiro 2005), (R. J. Nunes Outubro 2004) e (P. R. Nunes 2009), para criar a configuração e parametrização de sistemas domóticos ou para editar configurações já existentes, de modo a que esta se torne numa ferramenta flexível e independente da tecnologia, e que não seja privada, mas sim de algum modo, compatível com o sistema DomoBus. A ferramenta proposta permitirá descrever e modificar habitações individuais ou mesmo condomínios residenciais. Neste caso, será útil a possibilidade de aproveitar definições já realizadas ao nível da casa ou dos dispositivos comuns às várias casas. A descrição do sistema domótico irá conter a constituição completa da habitação ou habitações por pisos e divisões, podemos assumir o exterior da habitação, um piso com várias divisões, a descrição dos dispositivos em localização específica na habitação e também das suas parametrizações e configurações. 2 Outra vertente da ferramenta será a de definir ou modificar o modo como os vários dispositivos existentes no sistema interagem entre si. Isto irá permitir definir os comportamentos dos dispositivos. Por exemplo, quando se carrega num dado interruptor, qual ou quais são as lâmpadas que deverão acender. Além destes comportamentos, também será possível a criação e edição de macros personalizadas. Por exemplo, ao entrar em casa desencadear uma série de acções através de um simples comando no sistema. Uma das vantagens desta ferramenta será a de permitir que, em qualquer altura, um utilizador modifique facilmente parâmetros de configuração de certos dispositivos, para que o sistema se adeqúe às suas novas necessidades ou preferências. Outra vantagem refere-se ao facto de ser possível adicionar facilmente novos dispositivos à habitação, introduzindo a informação sobre o dispositivo que se pretende adicionar a ferramenta passa automaticamente a conhece-lo e a permitir adicioná-lo a uma divisão, bem como a permitir configurar o dispositivo. Para atingir os objectivos será seguido o modelo DomoBus no desenvolvimento da ferramenta mencionada. A especificação XML utilizada no DomoBus será utilizada para a criação de todas as definições da habitação e do comportamento bem como as configurações dos vários módulos e dispositivos. Além disso o modelo DomoBus por ser genérico permite a utilização de diversas tecnologias domóticas, não ficando o utilizador ―preso‖ a uma tecnologia específica. 1.3. Estrutura da tese O documento está dividido em sete capítulos. No capítulo 2 são apresentadas as tecnologias domóticas estudadas neste trabalho e de seguida, no capítulo 3, as suas ferramentas de configuração. Apresenta-se no capítulo 4 uma solução para os problemas identificados e, no capítulo 5, descrevem-se os testes realizados para avaliar a aplicação desenvolvida. Por fim no capítulo 6 são apresentadas as conclusões e possível trabalho futuro, a que se segue a bibliografia. 3 2. Tecnologias domóticas Neste capítulo são estudadas várias tecnologias domóticas para se analisar e conhecer as suas características e identificar se oferecem mecanismos de interoperação e como podem ser interligadas entre si. 2.1. X10 O X10 (POWERHOUSE 2003) e (X10 2009) é uma norma de facto de comunicação entre dispositivos domóticos que utiliza a rede eléctrica comum. Este sistema foi criado em 1974 na Escócia pela empresa ―Pico Electronics, Ltd‖ que agora faz parte da X10 Ltd. O primeiro produto X10 foi vendido ao público em 1978 e a partir dessa data o X10 tem vindo a fazer parte de muitas habitações domóticas. É o sistema domótico com maior número de módulos vendidos. A comunicação no X10 é efectuada através da rede eléctrica de 110/220 Volts com uma velocidade de comunicação de 50 bit/s na Europa. Embora baixo, este ritmo é aceitável para um sistema de automação habitacional com poucos comandos. Na comunicação não existe detecção de colisões, podendo acontecer colisões e com comportamento inesperado nos dispositivos. Cada dispositivo em X10 tem o seu identificador constituído pelo par letra–dígito que é composto por letras de ―A‖ a ―P‖ e dígitos de 1 a 16, assim é possível ter no sistema até 256 dispositivos (16 códigos de casa x 16 códigos de dispositivo). Para a transmissão de comandos para um dispositivo é utilizado o seu endereço seguido do comando. Por exemplo para ligar uma lâmpada com o endereço ―A1‖ são enviadas duas mensagens, uma que ―selecciona o código A1‖ e de seguida outra que explicita o comando ―ligar‖. Os formatos das mensagens são os seguintes: Figura 1. Mensagem transmitida com o código do dispositivo Figura 2. Mensagem transmitida com o código da função O envio de um comando para um dispositivo é composto pelo envio das duas mensagens acima. Em que na primeira foi seleccionado o dispositivo. O ―Start Code‖ é sempre o mesmo para todas as mensagens que é 1110. O ―House code‖ é o código da habitação composto por 4 bits. O ―Number 4 Code‖ é o código do dispositivo que se pretende enviar um comando. A mensagem é sempre enviada duas vezes para efeitos de redundância. Dos 22bits os últimos 11bits são a repetição dos primeiros 11bits. Na segunda mensagem é enviado o comando. A mensagem é semelhante à anterior mas em vez de ser enviado o número do dispositivo é enviado o código da função. O envio de um bit pressupõe sempre o envio do seu complemento (excepto no campo Start Code). A seguinte imagem mostra os códigos das habitações bem como os códigos dos dispositivos e funções: Figura 3. Tabelas de códigos da habitação, dispositivos e funções Do lado esquerdo estão os códigos da casa compostos por 4 bits, e do lado direito os códigos do dispositivo e das funções compostos por 5 bits, em que o ultimo bit indica se é dispositivo (bit a 0) ou função (bit a 1). Devido à utilização da rede eléctrica para a comunicação no X10 o ruído introduzido por certos equipamentos faz com que a comunicação seja pouco fiável. Para resolver esse problema é necessário a utilização de filtros junto desses equipamentos para não afectar o sinal. Outro problema que existe é o sinal passar para fora da habitação. Para ultrapassar este problema é necessária a introdução de filtros na ligação com o exterior. Nos sistemas trifásicos é necessária a utilização de um repetidor para permitir a comunicação entre as fases. Devido a todos estes problemas, o x10 torna-se um sistema pouco fiável. Actualmente o sistema X10 suporta a comunicação via radiofrequência, em que os módulos já não utilizam a rede eléctrica mas comunicam entre si via ondas de rádio. O X10 tem um número reduzido de comandos para os actuadores, só sendo possível a realização de operações de ligar, desligar, subir e descer intensidade luminosa e colocar todas as lâmpadas desligadas ou ligadas. Os sensores geram, essencialmente, comandos de ligar ou desligar dispositivos (por exemplo, se a temperatura atinge um certo valor, é enviada uma indicação para desligar o aquecimento). O controlo dos módulos em X10 é bastante simples e pode ser efectuado 5 por programas para o PC. Existem disponíveis na internet uma grande variedade de programas, alguns gratuitos, com a possibilidade de controlar e monitorizar qualquer dispositivo instalado na habitação. Bastando indicar o endereço do dispositivo no software e indicar o seu tipo. A instalação de dispositivos na habitação é bastante simples, não necessitando de técnicos. Um utilizador comum consegue instalar um sistema X10 na sua habitação com toda a facilidade. Uma vantagem das instalações em X10 é não ser preciso um barramento separado para a comunicação, como acontece em outras tecnologias, reduzindo desta forma custos de cablagem adicional. Esta vantagem possibilita a instalação de um sistema domótico X10 com a mesma simplicidade após ou na altura da construção da habitação. Basta ligar os dispositivos à tomada eléctrica e estão quase prontos para funcionar. Para se configurar o comportamento do sistema é preciso em cada sensor, indicar o endereço do actuador e o tipo de comando (ligar, desligar, etc). A configuração do endereço dos dispositivos é feita no dispositivo através de dois comutadores, em conjunto criam o identificador do dispositivo composto pelo par letra-dígito. Apesar de simples é um processo que pode ser demorado para habitações com vários dispositivos. A prática recomenda ainda tomar nota de todos os endereços dos dispositivos para futura referência. 2.2. EIB/KNX O EIB foi desenvolvido por um conjunto de empresas líderes no mercado europeu de material eléctrico com o objectivo de criar um sistema alternativo aos sistemas produzidos nos mercados Japonês e Estados Unidos da América onde estas tecnologias estavam bastante mais desenvolvidas e maduras. O objectivo principal foi o criar uma norma europeia que permitisse a comunicação entre os vários dispositivos de uma instalação. A arquitectura do EIB é descentralizada e ela define uma relação elemento a elemento entre os dispositivos, permitindo um processamento distribuído entre os sensores e actuadores. A EIBA é uma associação sediada em Bruxelas criada em 1990 e cujo objectivo é divulgar o sistema de instalação EIB. Esta associação actua nas seguintes áreas: Estabelecer directrizes técnicas para o sistema e produtos EIB, bem como os procedimentos de ensaio e certificação de qualidade. Divulgar o conhecimento e experiencia de empresas que trabalham com EIB, bem como novos produtos e inovações. Atribuição da marca registada EIB aos produtos e aos fabricantes associados. Colaborar com outros organismos europeus e internacionais nas fases de normalização e adaptação do EIB às normas internacionais. Participar na iniciativa de conversão da KONNEX, juntamente com o BCI (Batibus) e a EHSA (EHS). 6 A KONNEX (KNX) criada em 14 de Abril de 1999 tinha o objectivo de obter um standard Europeu para a automação de edifícios, além deste objectivo pretendiam melhorar a prestação de serviços dos vários meios físicos, introduzir novos modos de funcionamento com a filosofia Plug&Play aos vários dispositivos numa casa, juntar empresas fornecedoras de serviços como as de telecomunicação e as de electricidade para um controlo da casa à distância. A KONNEX fez uma junção dos sistemas EIB, Batibus e EHS para criar uma única norma europeia que seja capaz de oferecer qualidade e que consiga competir com outros sistemas como o LonWorks ou CEBus. Actualmente a norma é compatível com EIB e foi baseada na comunicação deste e contempla os modos de configuração do Batibus e EHS. Esta norma junta o melhor das três tecnologias. Os modos de configuração do KNX são os seguintes: S-mode ou System-mode é a configuração proveniente do EIB, os dispositivos são instalados e configurados por profissionais através da ferramenta ETS. Este modo é o mais utilizado no KNX sendo o mais flexível permitindo maiores níveis de funcionalidade e de adaptação às particularidades de cada habitação. E-mode ou Easy mode é a configuração fácil do sistema, os dispositivos vêm pré-programados de fábrica para realizar uma certa função, estes dispositivos tem que ser configurados no local da instalação utilizando um controlador ou através de micro-interruptores presentes nos dispositivos, com alguma semelhança face ao que é feito na tecnologia X10. A-mode ou Automatic mode é o modo Plug&Play do KNX este modo visa a simplicidade de instalação por parte de um utilizador comum e não necessita de qualquer configuração. Este modo foi pensado para a instalação de electrodomésticos e equipamentos de entretenimento (videojogos e multimédia). Em relação aos meios físicos o KNX suporta par entrançado TP1 que provem do EIB e suporta par entrançado TP2 que provem do Batibus. Suporta ainda corrente eléctrica PL110 proveniente do EIB e PL132 proveniente do EHS. Suporta Ethernet via KNXnet/IP, apenas para ligação de dispositivos KNX. Suporta Radiofrequência proveniente do EIB.RF e ainda infra-vermelhos proveniente do EIB.IR, esta ultima limitada a 12 metros. Com o KNX a configuração dos sistemas domóticos não se tornaram tão simples como parecia, a configuração s-mode continua a ser a base de toda a configuração existente e alguns dispositivos suportam a configuração e-mode, pois nem todos suportam outra configuração que a s-mode. Em comparação com o X10 o KNX é mais robusto e implementa um protocolo real de comunicação, com retransmissões, etc. mas o KNX não é imune a problemas de comunicação sobre a rede eléctrica, podendo ocorrer falhas. Tal como no X10 o ruído eléctrico era um problema no KNX também continua a ser. A implementação de um sistema KNX deverá ser feita por um técnico especializado, sendo necessário recorrer à ferramenta ETS. Aumentando os custos finais de instalação. Outro problema com esta tecnologia é o facto das novas configurações não serem simples. Por exemplo, se um utilizador quiser alterar uma preferência ou definição num dispositivo ou no sistema terá que carregar toda a configuração e o respectivo código dos dispositivos em questão para os mesmos. Na prática é 7 necessário que alguns dispositivos domóticos parem de funcionar durante o tempo que a configuração demorar a ser instalada. Desta forma verifica-se que o KNX é pouco flexível a mudanças. A introdução de um novo dispositivo no sistema também origina o mesmo problema, toda a configuração terá que ser carregada para o novo dispositivo e os que com ele interactuam. 2.3. LonWorks O LonWorks é uma tecnologia desenvolvida pela Echelon. A tecnologia é bastante utilizada não só para habitações mas também em instalações industriais, estando mais divulgada nos EUA. O LonWorks baseia-se numa rede de dispositivos chamada ―LON‖ que significa Local Operating Network, esta rede está desenhada para transferir pequenas quantidades de informação (comandos). Os dispositivos também conhecidos como nós, normalmente são constituídos por um chip o ―neuron‖, um transceiver, uma fonte de energia e o respectivo hardware de entradas e saídas. Os dispositivos são capazes de comunicar utilizando o protocolo normalizado ANSI/ CEA-709.1 (EN14908). A implementação do protocolo pela Echelon é chamada de ―LonTalk‖. Os dispositivos em LonWorks são categorizados consoante a sua função primária. Dispositivos que efectuam medidas são considerados sensores. Dispositivos que tenham entradas e saídas são considerados controladores. Dispositivos que controlam o hardware em resposta às variáveis de controlo são chamados actuadores. Existem ainda outros tipos de dispositivos para controlo da rede. A funcionalidade do dispositivo está implementada como uma aplicação no dispositivo, que está guardada e é executada pelo processador neuron. Os detalhes da aplicação e definições estão guardados num ficheiro do tipo XIF, ou External Interface File. Este ficheiro é fornecido pelo fabricante e contém toda a informação relevante sobre o dispositivo, como as variáveis e as propriedades que ele implementa. Um ficheiro completo irá incluir também valores de fábrica para todos os parâmetros do dispositivo. O objectivo deste ficheiro é disponibilizar toda a informação necessária a uma base de dados ou ferramenta de configuração sem ter o dispositivo fisicamente. Desta maneira é possível desenhar e criar uma rede completa e configurá-la através de um PC sem estar ligado à rede de destino. Este método, é conhecido como ―Engineered System‖, permite que a integração seja quase toda elaborada no escritório. A configuração de um sistema LonWorks exige que a instalação seja efectuada por instaladores certificados. A base de dados criada no escritório é depois enviada para a localização onde os dispositivos realmente estão na rede física. Todo o endereçamento, ligação de variáveis a dispositivos e configuração criados no escritório são automaticamente carregados nos dispositivos. As variáveis de rede são a base da comunicação entre os dispositivos LonWorks. Uma variável de rede é definida como saída num dispositivo, para que esse dispositivo possa exportar um valor de um certo tipo e como entrada noutro dispositivo para que esse possa importar variáveis de rede desse tipo. Um dispositivo pode implementar até 62 variáveis de rede. As variáveis de rede podem ser tipos de dados básicos, como inteiros ―unsigned‖ ou ―signed‖, ou podem corresponder a dados mais complexos. As variáveis de rede normalizadas são chamadas de SNVTs do inglês Standard Network Variable Type e são utilizadas para transferir dados predefinidos, como tempo, peso, velocidade ou posições. Existem centenas de SNVTs. Tipicamente, as ligações são efectuadas entre variáveis de 8 rede do mesmo tipo. Por exemplo, uma variável de rede de saída SNVT_switch de um dispositivo de um botão de pressão irá ser ligada a uma variável de rede de entrada SNVT_switch de um controlador de uma lâmpada. Para além dos SNVTs também existem os SCTP do inglês Standard Configuration Property Type, que são conjuntos de propriedades, normalizadas de um tipo de objecto, que é atribuído no momento da instalação e permanece estático no dispositivo que o contem. Os SCTPs são definidos e normalizados pela organização LonMark e são feitos para ser utilizados onde for aplicável. Normalmente os SCTPs incluem localização de dispositivos, etiquetas, frequências de comunicação para saídas, etc., os SCTPs são atribuídos por um browser LonWorks que vem com o LonMaker (ECHELON Corporation 2003) e (Echelon Corporation 2006) (aplicação de configuração) ou através de um Plug-in. Um objecto pode ter mais de um SCTP. Um objecto é um conjunto de variáveis de rede e de entradas, em conjunto com propriedades para realizar uma certa função. Um objecto é uma entidade de software, gravada no chip do dispositivo e um dispositivo pode conter vários objectos. Cada objecto LonWorks tem um número associado para identificação. Um browser LonWorks é um dispositivo genérico que permite um utilizador ver e modificar as variáveis e as propriedades de um dispositivo. O browser normalmente vem incluído com a ferramenta de configuração LonMaker para o Windows, que é a ferramenta mais comum para a manipulação de redes LonWorks. Este browser mostra as variáveis e propriedades numa lista, e inclui monitorização de saídas, formatação dos dados e capacidade de criar relatórios. A LonMark é a organização que define as normas e procedimentos para os dispositivos utilizados na rede LonWorks. A organização LonMark define as Standard Network Variable Types (SNVTs), os Standard Configuration Property Types (SCPTs), os Functional Profiles (FPs), e formatos de ficheiros específicos para suportar funções, tais como auto-documentação, suporte multilingue, e especificações de recursos do dispositivo. Ao ir de encontro a estas normas é garantida a interoperabilidade, que é, a possibilidade de dispositivos de diferentes fabricantes poderem funcionar em conjunto na mesma rede. O Functional Profile (FP) é um modelo de aplicação industrial normalizado de funções específicas de um dispositivo. O modelo descreve os tipos de variáveis de rede necessárias para implementar uma dada função, os SCPTs, ou propriedades necessárias para optimizar a função, e uma descrição geral em como e quando as SNVTs e SCPTs devem ser aplicadas a eventos. Um perfil funcional típico poderá ser um actuador de uma lâmpada, que recebe comandos de activação via SNVT_switch, e transmite o estado via SNVT_switch. Uma colecção de perfis funcionais interligados (ligados pela relação de variáveis de rede de entrada e saída) formam a base para uma rede funcional. Perfis funcionais permitem a desenhadores e integradores partilhar uma descrição normalizada do propósito e capacidades de um dado dispositivo. Os perfis funcionais não especificam o número exacto de requisitos de hardware, nem especificam a totalidade da funcionalidade de um dispositivo. Contudo, eles especificam um conjunto mínimo de funcionalidades que deverá ser programada. Eles também indicam as variáveis de rede apropriadas e propriedades de configuração necessárias para a comunicação da funcionalidade e características dos FPs. Os fabricantes são livres de adicionar funcionalidade à funcionalidade básica dos FPs definidos. Esta liberdade permite funcionalidades adicionais de serem implementadas nos dispositivos de modo a 9 oferecer maior flexibilidade e vantagens competitivas, enquanto continuam em conformidade com as especificações base requeridas pelo perfil. Cada dispositivo na rede é composto por propriedades que um utilizador pode ajustar para modificar o comportamento do dispositivo. A alteração dessas propriedades é chamada de configuração. Por exemplo, configurar o valor da intensidade luminosa por defeito de uma lâmpada faz parte da configuração das acções normais do dispositivo. Os fabricantes podem definir as suas próprias propriedades, conhecidas como UCPTs do inglês User defined Configuration Property Types. As propriedades da configuração são escritas no dispositivo quando este é colocado na rede pelo instalador, e as definições são também guardadas na base de dados de rede. As definições guardadas podem ser reutilizadas no caso de uma substituição do dispositivo, se o original se avariar. O dispositivo substituto irá assumir todas as características operacionais do dispositivo original. Certas configurações para dispositivos específicos podem ser demasiado complexas, nestes casos o fabricante disponibiliza um Plug-in (uma mini aplicação) com uma interface simples para a configuração desse dispositivo. Nem todas as ferramentas LonWorks suportam Plug-ins, e nem todos os dispositivos têm plug-ins escritos para eles. Um dispositivo poderá operar normalmente sem a utilização de nenhum Plug-in. O objectivo do plug-in é de auxiliar o utilizador na configuração do dispositivo. A comunicação entre os dispositivos é efectuada utilizando o LonTalk, o protocolo de comunicação entre os vários neurons. Ele inclui a especificação dos tipos de mensagem, se as mensagens são de troca de SNVTs, mensagens comando e controlo vindas de ferramentas ou mensagens definidas pelo utilizador. Voltando ao hardware, o neuron foi o nome dado ao chip fabricado pela Toshiba. Este chip tem o protocolo LonTalk embebido num dos três processadores que o constituem e tem memória para as aplicações específicas do dispositivo. Estas aplicações são rotinas criadas pelo fabricante para dar funcionalidades particulares ao dispositivo. Geralmente todos os dispositivos ―LON‖ incluem um neuron. Estas aplicações são programadas em ―Neuron C‖ uma variante do ANSI C, que adiciona três funcionalidades à linguagem: 1. A geração de eventos utilizando os comandos ―when‖ e ―events‖, tornando o neuron C uma linguagem orientada a eventos. 2. Adiciona tipos de dados, tipos de objectos de E/S e objectos temporizadores, para simplificar e normalizar o controlo dos dispositivos. 3. Mecanismos de parsing de mensagens de rede. Esta linguagem permite que a programação use um modelo de eventos, em que as aplicações são activadas através dos eventos que ocorrem algures num dispositivo da rede. A rede em si também é controlada por eventos. O que significa que as redes LonWorks tem menos tráfego que redes normais. Pois escusam de estar sempre a verificar se existem alterações, as alterações são enviadas para o dispositivo em questão. 10 A comunicação de rede pode ser efectuada por diversos tipos de meios físicos que podem ser fibra óptica, radiofrequência, rede eléctrica e par entrançado. Cada tipo de canal de comunicação tem as suas características e distâncias máximas, número de dispositivos máximo e largura de banda. O tipo mais comum é o par entrançado que opera a 78Kbits/s. Para a rede eléctrica a velocidade são 5.4Kbits/s. A maior parte dos dispositivos apenas podem estar num canal a não ser que seja utilizado um router. Um router é um dispositivo especial ―LON‖ que permite a comunicação entre diversos canais diferentes numa rede ―LON‖. Um router comum tem dois neurons em cada ligação aos canais. Permitindo assim ao router passar os dados de um canal para o outro. Os routers podem também filtrar e bloquear dados de cada um dos lados, baixando o tráfego. Os routers também isolam electricamente os dois canais, uma falha num dos canais não afecta o funcionamento do outro canal. O LonWorks é uma tecnologia bastante complexa e difícil de obter documentação, não existindo ainda muitos instaladores certificados. Esta tecnologia para ser instalada têm que recorrer sempre a um instalador certificado, e não é virada para o utilizador comum alterar ou adicionar módulos à rede de comunicações. Cada dispositivo requer um neuron chip fazendo com que o custo total dos dispositivos seja um pouco mais caro em relação a ter um neuron chip por vários dispositivos. O modelo de programação dos dispositivos é inteligente e eficaz, mas requer que seja aprendida uma nova linguagem criada pela echelon o ―neuron C‖. 2.4. DomoBus O sistema DomoBus consiste numa abordagem à domótica que intervém a dois níveis: Comando e monitorização domótica com interface directa com o meio físico através de sensores e actuadores adequados. Gestão e supervisão domóticas usando uma abordagem flexível e que oferece suporte à interoperação com outras tecnologias domóticas. 2.4.1.Comando e monitorização O nível de comando e monitorização é constituído pelos dispositivos físicos (sensores e actuadores) e pelos respectivos módulos de controlo. A figura seguinte ilustra a arquitectura do DomoBus: 11 Figura 4. Arquitectura de rede do DomoBus A rede DomoBus está organizada em segmentos que interligam módulos de controlo (CM). Cada um destes módulos corre um conjunto de aplicações domóticas que estão associadas a diversos dispositivos domóticos (sensores e actuadores). Como se observa na Figura 4 existem três tipos fundamentais de componentes do sistema DomoBus: CM – Control Modules, SM – Supervision Modules e R – Router modules que se descrevem em seguida CM módulo de controlo que é responsável pela inteligência dos dispositivos físicos tais como lâmpadas ou tomadas eléctricas, estes módulos podem controlar mais que um dispositivo sendo mais económico que controlar apenas um (como é comum em outras soluções) porque optimiza a utilização dos recursos existentes e a fonte de energia de um só módulo. Nestes módulos são enviadas e recebidas mensagens quando são premidos botões, quando são dadas ordens para ligar algum dispositivo ou qualquer outra acção. Figura 5. Arquitectura dos módulos de controlo A Figura 5 mostra a arquitectura interna de um módulo de controlo. A placa electrónica dos módulos é constituída por um micro-controlador de 8bits com memória interna para código e dados e ainda um temporizador para a gestão de tempo. Os protótipos existentes utilizam o AT90S8515 da ATMEL (Atmel Corporation 2009) . 12 Para a comunicação é utilizado um receptor/emissor EIA-485 devido às seguintes características: oferece boa imunidade ao ruído eléctrico, suporta comunicação em longas distâncias (a necessária dentro de uma habitação) e são bastante baratos. Na comunicação é utilizada uma politica do tipo CSMA/CD que oferece uma baixa latência em condições de tráfego normal. A ponte entre o micro-controlador e os dispositivos físicos é feita através de interface incluída nas placas. Nesta interface está o hardware necessário para ligar os interruptores e vários tipos de sensores (temperatura, humidade, etc.) e a electrónica de potência que permite comandar lâmpadas, motores, etc. As placas têm um modelo de software em que existem tarefas com um dado objectivo e que são executadas ciclicamente. O objectivo é comandar um dado actuador ou receber informação de um sensor e tratá-la correctamente. Cada tarefa quando é executada corre uma rotina de código e executa as acções necessárias, passando em seguida para a próxima tarefa. As tarefas podem também comunicar entre si utilizando variáveis globais ou utilizando um sistema de mensagens. Existem tarefas que oferecem serviços nucleares ao funcionamento de um CM como a tarefa de rede que efectua a gestão da rede e a tarefa de tempo que efectua a gestão do tempo real. A tarefa de rede é responsável pela comunicação robusta entre os vários módulos utilizando o protocolo do DomoBus. As tarefas podem ser parametrizadas permitindo definir certos comportamentos como, por exemplo, o valor máximo e mínimo de determinado valor do dispositivo, o intervalo de tempo entre envios periódicos de informação, endereços dos destinatários, etc. Estes parâmetros ficam guardados na memória não volátil do módulo permitindo que o sistema funcione de forma mais autónoma e descentralizada. A parametrização das tarefas é feita a partir do nível de gestão através de configurações criadas para cada dispositivo. SM é o módulo de supervisão. Este é um módulo opcional, no sentido que não necessita de existir um por cada segmento de rede, embora deva existir pelo menos um por sistema para supervisionar os CM. Ele será explicado na secção seguinte sobre o nível de supervisão. R - Router module, um módulo utilizado para interligar segmentos da rede. A rede DomoBus pode ser decomposta em vários segmentos para simplificar a expansão. Neste caso a comunicação entre os segmentos é realizada através de uma rede backbone entre os router modules. Esta abordagem permite uma optimização do tráfego global, devido ao facto da comunicação dentro de um segmento não influenciar a de outro segmento. Apenas as mensagens destinadas a nós noutros segmentos atravessam os elementos R e o segmento backbone. Figura 6. Endereço de um dispositivo domótico na rede DomoBus 13 Na rede Domobus o endereçamento dos dispositivos físicos é feito utilizando endereços de 16 bits tal como mostra a Figura 6, em que os 12 bits mais significativos identificam a Aplicação de Controlo e os últimos 4 bits identificam o dispositivo gerido por essa aplicação. A identificação da aplicação de controlo pode ser interpretada como possuindo uma estrutura hierárquica em que os 4 bits mais significativos identificam um segmento de rede (permitindo um máximo de 16 segmentos), os 5 bits seguintes identificam um nó localizado nesse segmento (com um máximo de 32 nós por segmento) e os 3 bits menos significativos identificam uma tarefa dentro de um nó (podem existir até 8 tarefas). Cada tarefa controla até 16 dispositivos (identificados por 4 bits). 2.4.2.Gestão e Supervisão No nível de gestão são definidas a habitação, a localização de dispositivos e a configuração dos dispositivos seguindo uma abordagem genérica independente da tecnologia utilizada. Este nível está especificado em XML e pode ser alterado por utilizadores comuns utilizando a ferramenta de configuração do DomoBus designada DomoConfig. Neste nível é seguido um modelo abstracto onde é possível representar qualquer dispositivo. Um dispositivo é caracterizado por um conjunto de propriedades tendo cada propriedade um valor. Cada propriedade tem um tipo de dados associado que pode ser um enumerado, um número escalar ou um vector. Tal como é ilustrado na Figura 7. Figura 7. Modelo simples de Dispositivos Genéricos Este modelo de propriedades é usado directamente pelo DomoBus no nível de comando e monitorização. A criação destes tipos de dados, dos dispositivos genéricos e dos módulos (equipamentos que incluem múltiplos dispositivos) está destinada aos fabricantes de hardware em que eles apenas criam os dispositivos genéricos e os agregam numa descrição XML. O instalador, com a descrição XML do módulo, adiciona os dispositivos à habitação. O comportamento do sistema, as macros e a estrutura da habitação são também definidos no nível da Gestão pelo instalador ou por um utilizador comum, sendo essa informação também guardada em XML. Uma habitação é considerada uma entidade que possui um ou mais pisos em que cada piso 14 possui uma ou mais divisões e cada divisão pode conter vários dispositivos domóticos. É neste nível que a simplicidade de utilização será explorada ao máximo. Para a supervisão da habitação são utilizadas diversas aplicações que interagem entre si para supervisionar todo o sistema. Estas aplicações inteligentes podem correr em PCs ou em SBCs (Single Board Computers) que são designados de módulos de supervisão (SM) – ver Figura 4. Os módulos SM, recebem informação vinda dos CMs e processam-na de acordo com as regras programadas e comportamentos desejados, e enviam os comandos necessários para os CMs. Um sistema pode utilizar vários SMs conforme as necessidades. Um sistema pequeno pode ter apenas um SM, enquanto num sistema mais complexo podem ser utilizados vários SMs, por exemplo um por segmento de rede, tal como ilustra a Figura 4. Deste modo eventos gerados pelos CMs ligados a um segmento de rede podem ser recebidos e processados directamente pelo SM correspondente. Isto permite uma supervisão distribuída, oferecendo vantagens em relação a tempos de resposta e disponibilidade (sem existência de pontos únicos de falha). De realçar que cada SM pode controlar qualquer CM no sistema e que os SMs podem interactuar entre si para partilhar informação e coordenar acções. Para este fim os SMs podem utilizar diferentes tipos de ligação (Ethernet ou Wireless LAN) com uma largura de banda maior e suporte a serviços de multimédia. A interacção com outros sistemas também se torna mais fácil permitindo a realização de soluções integradas. A interligação com diferentes tecnologias domóticas é efectuada através de aplicações Gateway específicas que, tipicamente, correm num PC. Uma Gateway traduz a lógica de funcionamento do DomoBus nas operações específicas suportadas por uma dada tecnologia. As gateways tratam da conversão dos endereços e dos comandos das diferentes tecnologias. Cada gateway possui uma tabela de conversão de endereços para a tecnologia de destino e uma tabela com a informação de como serão convertidas as mensagens recebidas numa tecnologia para o sistema Domobus. É ainda possível dispor de algum tipo de inteligência que faça com que certas funcionalidades presentes no DomoBus tais como avisos periódicos do valor de um sensor sejam possíveis mesmo em tecnologias que não o suportem. O endereçamento na rede Domobus ao nível da supervisão é feito utilizando 32 bits em que os 16 bits mais significativos servem para identificar aplicações de gestão, supervisão e gateways, e os 16 bits menos significativos são usados para identificar dispositivos concretos de uma dada tecnologia. Como se pode ver na Figura 8. Figura 8. Endereços na rede DomoBus As mensagens trocadas na rede Domobus têm o formato ilustrado na Figura 9 em que o primeiro campo indica o tipo de mensagem, depois vêm os endereços de origem e destino, um número de sequência, o tamanho dos dados e finalmente os dados. Estes dados podem incluir informação em 15 formato específico trocado entre as aplicações do nível de gestão ou mensagens de controlo que explicitam uma propriedade de um dispositivo, a operação a realizar e um valor. Figura 9. Formatos das mensagens entre aplicações e a rede DomoBus O formato do campo de dados das mensagens usadas na interacção com dispositivos domóticos está ilustrado na Figura 10. Existe um campo de controlo (CTR) que contém informação sobre a prioridade (P), se é uma retransmissão (R), se é uma resposta a uma mensagem anterior (ANS) e o tipo de mensagem (opCode), estando já definido os seguintes tipos: GET, SET, REPORT e FORWARD. Figura 10. Estrutura do campo data de uma mensagem DomoBus Para o caso dos tipos de mensagens predefinidas o formato do campo de payload é o indicado na Figura 11 e inclui a identificação do dispositivo, a propriedade e o valor que se quer ler ou definir ou reportar. Numa mensagem podem ser enviados múltiplos pares propriedade-valor. Figura 11. Formato das mensagens pré-definidas 16 Para mensagens do tipo FORWARD o campo Device é substituído pelo campo DeviceAddress que corresponde a um endereço completo de 16 bits (ver Figura 12). Este endereço completo identifica o dispositivo a que se referem as propriedades e que será diferente de quem está a enviar a mensagem. Com as mensagens FORWARD é possível ter um dispositivo A a enviar mensagens para um dispositivo B mas que se refere a propriedades de um dispositivo C. Este endereço C é o que irá no campo DeviceAddress. Figura 12. Formato da mensagem do Forward O DomoBus é uma solução inovadora pela simplicidade e flexibilidade introduzida pelo seu modelo abstracto de dispositivo domótico, permitindo que possa funcionar como plataforma de interoperação entre diferentes tecnologias e permitindo que o utilizador possa alterar interactivamente o comportamento do sistema e adaptá-lo às suas necessidades e preferências. Ao nível da monitorização e controlo, o DomoBus mostra-se também muito flexível e económico pois os seus módulos incluem, tipicamente, um elevado número de dispositivos, o que permite rentabilizar os recursos de alimentação, processamento e comunicação. A solução proposta oferece uma elevada capacidade de configuração, usando uma ferramenta gratuita, sendo de realçar que os módulos podem ser reconfigurados em qualquer momento, sem necessidade de os desligar e sem afectar o funcionamento de outros módulos. 17 3. Ferramentas de Configuração de sistemas Após um estudo de tecnologias domóticas foi efectuado um estudo sobre as suas ferramentas de configuração. 3.1. ETS O ETS é uma aplicação desenvolvida pela KONNEX Association que significa Engineering Tool Software e tem como objectivo principal o desenho e configuração de sistemas domóticos baseados em EIB/KNX. Com a ferramenta também é possível a gestão da rede EIB/KNX. O modo de configuração s-mode do KNX é realizado através desta ferramenta. O ETS utiliza uma base de dados com a descrição de todas as informações necessárias sobre os dispositivos para a sua correcta configuração. Esta base de dados é criada pelos fabricantes de cada dispositivo utilizando uma ferramenta própria, ―manufacturer tool‖, e normalmente vem junto com o dispositivo. Esta base de dados não é aberta e só pode ser lida pela ferramenta ETS. A configuração do sistema pode ser feita em modo offline e posteriormente enviada para os dispositivos. A versão actual da ferramenta ETS é a 3.0f mas a versão apresentada é a 3.0d Professional. Existem três versões da ferramenta: a ETS Tester virada para quem pretende testar e aprender a utilizar a aplicação e é gratuita, a versão ETS Starter já é mais virada para o utilizador comum e serve apenas para a criação de pequenas habitações, mas com o inconveniente de que a base de dados tem que ser criada propositadamente para esta versão e finalmente a versão profissional sem quaisquer limites de dispositivos para a configuração em s-mode. A Figura 13 ilustra a interface da aplicação: Figura 13. ETS 3.0d Interface de utilizador Esta é a interface principal da ferramenta ETS, onde é possível abrir e criar novos projectos. Projectos estes que irão conter toda a configuração e desenho da instalação EIB/KNX. 18 Os catálogos dos fabricantes de dispositivos podem ser consultados via menu de View e efectuar pesquisas nos mesmos, para depois serem introduzidos na configuração. O ETS permite verificar se tudo se encontra correcto bem como testar todo o sistema através do menu Diagnostics. O ETS pode ser configurado para aceder ao barramento do sistema via USB, RS232 e TCP/IP através do menu Extras. É ainda possível através desse menu gerir as licenças do software e efectuar outras configurações e a manutenção das bases de dados. Esta aplicação necessita de importar as bases de dados de produtos para ser possível utilizar e testar dispositivos. Após este processo, que é bastante demorado, torna-se possível pesquisar dispositivos como ilustra a Figura 14. Figura 14. Pesquisa de dispositivos no ETS Nesta janela é possível pesquisar por fabricante, família e tipo de produto, tipo de meio físico entre outras opções. Depois de feita a escolha carrega-se no botão Find e aparece uma lista com todos os dispositivos filtrados pelas opções escolhidas anteriormente. Com esta lista de dispositivos é possível escolher os que se pretende adicionar ao projecto carregando no botão insert. Após terem sido inseridos alguns dispositivos tem-se este ecrã com a lista de dispositivos instalados como ilustra a Figura 15: Figura 15. Lista de dispositivos instalados Quem estiver a criar ou editar o projecto tem que ter a devida atenção para não introduzir dispositivos inexistentes ou diferentes dos reais no projecto. Depois de encontrados e inseridos os dispositivos de acordo com a escolha é possível configurá-los individualmente parâmetro a parâmetro como ilustra a Figura 16. 19 Figura 16. Configuração de parâmetros Figura 17. Dispositivos nas várias linhas Esta instalação de exemplo (Figura 17) tem dois meios físicos referidos como linhas e alguns dispositivos. Na criação do projecto, é com alguma facilidade que os dispositivos são adicionados às linhas e os endereços EIB/KNX são gerados automaticamente pelo ETS (também podem ser atribuídos manualmente pelo utilizador). Cada linha suporta dispositivos de diferentes fabricantes bastando para isso seleccionar na pesquisa os vários fabricantes. Durante a configuração é possível separar os dispositivos por divisão da habitação apenas para melhor percepção do sistema, não tendo o dispositivo qualquer informação sobre a divisão onde o mesmo se encontra - ver exemplo na Figura 18. Figura 18. Dispositivos por divisão 20 É ainda possível seleccionar uma vista por endereços de grupo, para os configurar. Os endereços de grupo são a base do comportamento do sistema. Um sensor envia uma mensagem para um endereço de grupo e os actuadores que estiverem presentes nesse grupo irão actuar. Dentro de um grupo só podem estar dispositivos do mesmo tipo ou de tipos compatíveis. Após a configuração do sistema selecciona-se a opção de Download e o ETS inicia a configuração dos dispositivos físicos, carregando tanto o código que depois será executado no dispositivo como a configuração para o dispositivo. Os dispositivos físicos inicialmente não vêm com o código, o ETS cria o código específico com a configuração lá dentro e só assim é possível colocá-los a funcionar. Para o diagnóstico o ETS permite a instalação de ferramentas de terceiros que acedem ao barramento para a leitura e interpretação das mensagens. Este software exige por parte de quem o utiliza algum conhecimento sobre o funcionamento do EIB/KNX nomeadamente na parte de endereços, endereços de grupos, catálogos com descrições de dispositivos e para configurações mais pormenorizadas, sobre as opções do dispositivo. Para a configuração dos dispositivos este software só permite dois tipos de meio físico: o par-entrançado e a rede eléctrica ou então, se for outro tipo, terá que ser utilizado o tipo ―qualquer‖. Se um utilizador quiser alterar um parâmetro de um certo dispositivo é preciso fazer o download de toda a configuração junto com o código para o dispositivo o que é uma desvantagem deste sistema. A instalação de catálogos de dispositivos e a inserção de dispositivos ao projecto é um processo demasiado lento para a utilização eficaz do ETS. O ETS é uma ferramenta paga e foi desenvolvida para trabalhar só com redes KNX, sendo pois específica desta tecnologia. Para um utilizador comum o custo de 900€ da ferramenta é bastante significativo. 3.2. LonMaker O LonMaker é a aplicação comercializada pela Echelon para o desenho e configuração de redes domóticas baseadas na tecnologia LonWorks. Esta ferramenta de configuração utiliza como componente principal do desenho o Microsoft Visio. Existem actualmente duas versões da ferramenta, a versão Standard Turbo Edition e a versão Professional Turbo Edition. A grande diferença entre as duas é a versão do Visio incluída em que a versão standart tem menos funcionalidade. A versão actual da ferramenta é a 3.13. O LonMaker é uma ferramenta paga com um preço a rondar os 900$ (perto de 650€). Na ferramenta existe o conceito de créditos, os créditos servem para ser possível a configuração dos dispositivos, quer isto dizer que um dispositivo para ser configurado consome um crédito. Ambas as versões trazem um certo número de créditos, mas após a utilização dos mesmos estes podem ser comprados por 5$ (3,6€) cada um, para ser possível configurar mais dispositivos. Os créditos só são efectivamente consumidos na altura do envio da configuração para a rede. Sempre que se configura um dispositivo já configurado anteriormente e que tenha sido gasto um crédito, essa nova configuração já não consome mais créditos. Sendo este o modelo de negócio envolvido na ferramenta. A próxima versão da ferramenta, que irá ser lançada em 2010, já não envolve este modelo de créditos tornando o processo de configuração mais económico. 21 A ferramenta LonMaker baseia-se no LNS (―Local Network operating System‖) que é um software baseado em serviços com uma de base de dados desenvolvido pela Echelon, para ser utilizado por fabricantes de ferramentas para os ajudar a criar aplicações para PC. O LNS não é um produto completamente operacional, mas sim uma ferramenta para a criação sistemas de HMI (Human Machine Interface) ou GUI (Graphical User Interface), como o LonMaker. Existe um servidor LNS que oferece os mecanismos de instalação, criação da rede, manutenção, controlo e monitorização (local e remota) através de serviços e uma base de dados de recuperação e arquivo, é também possível o trabalho conjunto utilizando vários computadores com o LonMaker instalado. O que possibilita integradores, instaladores e pessoal da manutenção de trabalhar numa rede LonWorks ao mesmo tempo. O Lonmaker pode ser utilizado para gerir todas as fases do ciclo de vida de uma rede LonWorks, desde a fase do desenho inicial e envio da configuração para a rede até à fase de operação. O LonMaker proporciona as seguintes funcionalidades: Desenho da rede: É possível desenhar a rede fora do local da instalação (sem estar ligado à rede) e/ou no local da instalação, e modificá-la em qualquer altura. É possível também o carregamento do desenho de uma rede existente através do processo network recovery. É Nesta fase que se adicionam os dispositivos ao desenho e se os configuram. O comportamento do sistema é realizado também nesta fase recorrendo às interacções das variáveis de rede, em que um sensor poderá exportar uma variável e um actuador lê uma variável e dá uma resposta em hardware (actua) a essa variável. Instalação da rede: É possível instalar uma rede que foi desenhada fora do local da instalação no local da instalação. As definições dos dispositivos podem ser rapidamente associadas aos dispositivos físicos para reduzir o tempo de envio da configuração para a rede. O LonMaker Browser permite um acesso completo às variáveis de rede e propriedades da configuração. Documentação da rede: É possível criar desenhos LonMaker durante os processos de desenho e instalação da rede. Estes desenhos são uma representação lógica precisa da rede física instalada. O desenho é entretanto um componente essencial para relatórios. Manutenção da rede: É possível adicionar, testar, remover, modificar ou substituir dispositivos, routers, canais, subsistemas e ligações para a manutenção da rede. Para a configuração de uma rede LonWorks é necessário um servidor LNS que irá incluir a base de dados da configuração. Na base de dados estão guardadas todas as configurações e informações sobre dispositivos, sempre que é mudada alguma configuração num dispositivo o LonMaker utiliza um serviço para a actualização dessa base de dados. Uma vantagem desta base de dados é a possibilidade de se poder substituir um dispositivo avariado e enviar a configuração guardada na base de dados para o novo dispositivo. Deste modo o dispositivo novo fica a funcionar como se fosse o que avariou. A maior desvantagem da utilização desta ferramenta é o seu sistema de créditos e a necessidade de um técnico certificado para a instalação de novos dispositivos, pois sempre que é colocado um novo dispositivo na habitação é necessário chamar o técnico e pagar um valor proporcional ao número de 22 dispositivos instalados. Esta ferramenta não é a única para a configuração de redes LonWorks existem outras alternativas não da empresa Echelon mas podem ainda ser mais caras que o LonMaker como o caso da NL220. Existe ainda outra da Cirson mas com menos qualidade que é o Network Integrator e o Visual Integrator. O sistema de créditos mantém-se nestas ferramentas, em que os créditos são comprados directamente à Echelon. Nas várias ferramentas apenas é possível a edição de redes LonWorks, são por isso específicas a uma tecnologia. 23 4. Arquitectura da solução Na implementação da solução será seguido o modelo DomoBus devido às suas características genéricas. Neste modelo os dispositivos são representados por colecções de propriedades, existindo operações normalizadas (get, set, notify¸ etc.) para lhes aceder. Utilizando estas operações é definido o comportamento do sistema, tornando-se possível criar uma ferramenta suficientemente genérica e flexível. O modelo DomoBus não está associado a nenhuma tecnologia específica. A opção por outras tecnologias domóticas foi descartada devido às suas limitações ou por serem soluções fechadas. No caso do X10, por exemplo, a comunicação é demasiado básica e muito pouco robusta. A tecnologia KNX foi rejeitada pois obriga ao uso de bases de dados de produtos que são proprietárias e ao uso da ferramenta ETS que não é de utilização livre. A tecnologia LonWorks possui um modelo de créditos pagos e a interligação com outras tecnologias não está prevista. Em ambas as tecnologias, as ferramentas utilizadas são complexas, pagas e específicas para o pessoal técnico. 4.1. Descrição da solução (DomoConfig) Para ultrapassar os problemas identificados anteriormente optou-se pelo uso do modelo DomoBus. Neste modelo a representação da habitação é genérica e os dispositivos são objectos genéricos caracterizados por um conjunto de propriedades. No processo de configuração e especificação do comportamento da habitação será possível abstrair a tecnologia utilizada. No DomoBus é utilizado o formato XML para guardar a especificação da habitação e suas configurações. Na abordagem DomoBus um sistema domótico é composto por módulos domóticos, cada um constituído por um ou mais dispositivos domóticos. Assume-se que os módulos domóticos são comprados e vêm acompanhados de um ficheiro XML com a sua descrição. Esse ficheiro XML será importado pela aplicação, ficando a conhecer os dispositivos presentes nele e as suas características, permitindo depois efectuar a configuração de todo o sistema. No fim é possível guardar essa configuração e alterá-la mais tarde. O processo completo será detalhado de seguida. A Figura 19 ilustra a arquitectura da aplicação que irá permitir efectuar a configuração de sistemas domóticos - DomoConfig. 24 DomoConfig XML XML Descrição dos XML Descrição dos módulos Descrição dos módulos domóticos módulos domóticos domóticos GUI Lógica aplicacional KNX X10 … XML Configuração da Gateway XMLUtil XML Final Descrição genérica dos dispositivos domóticos Descrição da habitação Descrição do Comportamento do sistema Configuração dos dispositivos instalados Figura 19. Arquitectura da aplicação DomoConfig A aplicação DomoConfig está representada na zona central da figura e inclui o componente ―GUI”, o componente ―Lógica aplicacional‖ e o componente ―XMLUTIL”. O componente ―GUI” implementa a interface gráfica com o utilizador, permitindo-lhe interagir com a aplicação. Este componente disponibiliza todas as opções relativas à edição das características da habitação e configuração do comportamento dos dispositivos domóticos. Disponibiliza também funcionalidades de criação e alteração de módulos domóticos e dos respectivos dispositivos, o que em princípio se destina a utilizadores mais especializados (fabricantes e instaladores). No componente ―Lógica aplicacional‖ está a lógica da aplicação, as estruturas de dados e é onde o GUI assenta. Este componente tem como função gerir todos os aspectos funcionais da aplicação, que são acedidos pelo utilizador através do GUI. Este componente suporta a instalação de plug-ins associados a tecnologias específicas. Através desses plug-ins será possível aceder aos gateways de cada tecnologia e efectuar a sua configuração e dos respectivos dispositivos. O componente ―XMLUtil‖ é a parte que se encarrega de guardar as estruturas de dados do componente ―Lógica aplicacional‖ em ficheiros XML e de carregá-las dos ficheiros XML quando for pedido. Em torno da aplicação, ver a Figura 19, estão representados os ficheiros XML de entrada e saída. A aplicação irá permitir a criação, leitura e edição das descrições dos módulos domóticos, a edição dos tipos de dispositivos, a edição da descrição de habitações, a edição do comportamento desejado para o sistema e a configuração de gateways. 25 Os ficheiros XML com a descrição dos módulos domóticos podem ser utilizados para iniciar a configuração de uma habitação. A descrição dos módulos contém a descrição genérica dos dispositivos nele incluídos com indicação dos seus tipos e das respectivas propriedades bem como os tipos de dados associados. Com esta informação torna-se possível à aplicação saber as propriedades e os parâmetros dos dispositivos e permite a sua instalação e configuração na habitação. O ficheiro ―XML Final‖ contém toda a configuração do sistema e da habitação e é constituído por quatro partes: ―Descrição genérica dos dispositivos‖, ―Descrição da habitação‖, ―Configuração dos dispositivos instalados‖ e ―Descrição do comportamento do sistema‖. Estas partes serão utilizadas para guardar a configuração realizada na ferramenta e posteriormente podem ser editados no DomoConfig ou lidas por uma ferramenta de comando e supervisão do sistema. As quatro partes encontram-se juntas num só ficheiro XML divididas em secções. A secção com a descrição genérica dos dispositivos domóticos contém tudo o que é reutilizável e genérico. A secção com a descrição da habitação contém a descrição da estrutura da habitação organizada em pisos e divisões. A secção com a configuração dos dispositivos instalados contém os dispositivos instalados, a sua localização e as configurações de notificações que os dispositivos deverão gerar. A secção com a descrição do comportamento do sistema contém a definição dos cenários do sistema e das macros. Estas secções serão detalhadas em pormenor adiante. Se for necessária comunicação com tecnologias domóticas distintas do DomoBus terá de ser utilizada uma gateway. Esta gateway é configurada na aplicação e tem um ficheiro XML dedicado. A configuração da gateway é feita utilizando um plug-in que é instalado na aplicação e depois utilizado para fazer as configurações do modo específico exigido pela tecnologia. 4.1.1.Descrição dos módulos domóticos Na lógica DomoBus um módulo domótico corresponde a um conjunto de dispositivos domóticos que podem ser de vários tipos. Eventualmente, como caso extremo, um módulo pode corresponder a apenas um único dispositivo domótico. Cada módulo, normalmente, vem acompanhado de um ficheiro XML com a sua descrição. Esse ficheiro contém informação sobre os dispositivos contidos no módulo, bem como todos os tipos de dados e configurações que lhe estão associadas. A aplicação, quando importa um módulo, copia todos os tipos de dispositivos, tipos de dados, configurações e dispositivos disponíveis para a sua configuração geral da habitação. A descrição dos módulos é criada, tipicamente, pelo respectivo fabricante, sendo essa operação suportada pela aplicação DomoConfig que permite criar novos tipos genéricos ou recorrer a tipos já definidos noutros módulos e gerar um ficheiro XML autónomo. Apresenta-se em seguida o modelo UML da informação contida na descrição de um módulo. 26 Figura 20. Modelo da descrição dos módulos Cada módulo contém uma lista dos dispositivos que o constituem, podendo ser de diferentes tipos (por exemplo, sensores, lâmpadas, interruptores). Cada um destes dispositivos presentes no módulo faz referência a um tipo de dispositivo genérico descrito no módulo. Um tipo de dispositivo tem uma lista de propriedades que o dispositivo implementa e uma classe. Esta classe serve para separar os tipos de dispositivos por categorias dentro do módulo. As propriedades dos tipos de dispositivo têm um tipo de dados, informação das permissões de leitura e escrita e um tipo de configuração associada. Este tipo de configuração é constituído por vários itens e cada um deles indica os valores máximos e mínimos que são possíveis para certas notificações ou o número máximo de condições para a propriedade. Os tipos de dados das propriedades indicam os dados que uma propriedade suporta e podem ser enumerados, valores escalares ou vectores. Estes dados por vezes precisam de ser convertidos para serem lidos ou visualizados correctamente pelas aplicações, caso em que pode ser incluído um conversor por tipo de dados. Apresenta-se adiante um exemplo de XML onde se ilustra a definição de um módulo (―Modulo de estore‖) que inclui um dispositivo de estore (―estore 1‖). Esse dispositivo do tipo ―Estores‖ contém uma propriedade (―Aberto-Fechado‖) que é do tipo enumerado (―Subir-Descer-Parar‖). Esta propriedade tem uma configuração associada (―Config estado‖) e pode ser configurada com envios periódicos, envios de estado estável e duas condições personalizadas. 27 <ModuleDescriptionList> <ModuleDescription Version="1" Model="v1" Manufacturer="IST" ID="1" Description="Modulo de estore"> <ConversionFormulaList /> <ConversionObjectList /> <ScalarValueTypeList /> <EnumValueTypeList> <EnumValueType ID="4" Name="Subir-Descer-Parar"> <Enumerated Name="Subir" Value="0" /> <Enumerated Name="Descer" Value="1" /> <Enumerated Name="Parar" Value="2" /> </EnumValueType> </EnumValueTypeList> <ArrayValueTypeList /> <DeviceClassList> <DeviceClass ID="3" Name="Segurança" /> </DeviceClassList> <ConfigurationTypeList> <ConfigurationType ID="3" Name="Config estado"> <NotifyRate MaxValue="60" MinValue="1" Units="segundos" /> <StateChange MaxValue="30" MinValue="1" Units="segundos" /> <Condition MaxValue="2" /> </ConfigurationType> </ConfigurationTypeList> <DeviceTypeList> <DeviceType ID="6" Name="Estores" RefDeviceClass="3" Description="Tipo Estore"> <PropertyTypeList> <PropertyType ID="1" Name="Aberto-Fechado" AccessMode="RW" ValueType="ENUM" RefValueType="4" RefConfigType="3" /> </PropertyTypeList> </DeviceType> </DeviceTypeList> <ModuleDevice ID="1" LocalAddress="10" RefDeviceType="6" Description="Estore 1" /> </ModuleDescription> </ModuleDescriptionList> 4.1.2.Descrição genérica dos dispositivos domóticos Os tipos de dados genéricos normalmente vêm incluídos no ficheiro com a descrição do módulo e depois de instalados permanecem na descrição completa do sistema. Estes tipos genéricos são constituídos pelos tipos de dispositivos com as suas propriedades, tipos de dados (escalares, vectores e enumerados), os conversores que podem ser conversores directos ou conversores recorrendo a um DLL, tipos de configuração com os seus itens e as classes dos dispositivos. Os conversores que recorrem a um DLL para efectuar a conversão são chamados de conversores objecto. Estes conversores tipicamente são mais elaborados que os directos, em que apenas se efectua um cálculo simples. Nestes conversores o método a executar presente no DLL irá receber os dados a converter, efectua as operações e devolve os resultados. No DLL poderá ser elaborado um conversor bastante complexo que em XML seria impossível. 28 Os tipos de dados genéricos são uma solução simples para a reutilização de dados que normalmente teriam de ser repetidos várias vezes quando se têm vários dispositivos físicos do mesmo tipo. 4.1.3.Descrição da habitação A descrição da habitação contém a descrição de uma ou mais habitações e inclui informação sobre os seus pisos e as suas divisões. A especificação da habitação é feita em duas fases. Na primeira é criada a estrutura da habitação. De seguida são adicionados à habitação os dispositivos físicos que existem nos módulos previamente instalados indicando em que divisões se encontram. Na seguinte figura apresenta-se o modelo da estrutura de uma habitação: Figura 21. Modelo de uma habitação Este modelo permite de uma forma simples e eficaz, representar qualquer habitação. Notar ainda que a entidade Division não tem que representar necessariamente uma divisão física da habitação. Pode referir-se a um espaço lógico que tenha interesse identificar. Por exemplo o quintal pode ter várias divisões como jardim e garagem. Na descrição da habitação está também incluída a informação dos utilizadores, níveis de acesso e lista de serviços presentes nas habitações. No exemplo seguinte apresenta-se uma habitação (―Vivenda Silva‖) com dois pisos e três divisões no Rés-do-chão. Inclui também um exemplo da lista de acessos, de utilizadores e de serviços. 29 <HouseList> <House ID="1" Name="Vivenda Silva" Address="xxxxx" Phone="xxxx"> <FloorList> <Floor ID="1" Name="Cave" HeightOrder="-1"> <DivisionList> <Division ID="1" Name="Cave" AccessLevel="1" /> </DivisionList> </Floor> <Floor ID="2" Name="R/C" HeightOrder="0"> <DivisionList> <Division ID="2" Name="Cozinha" AccessLevel="3" /> <Division ID="3" Name="Sala" AccessLevel="2" /> <Division ID="4" Name="Hall" AccessLevel="2" /> </DivisionList> </Floor> </FloorList> </House> </HouseList> <AccessLevelList> <AccessLevel Level="0" Name="Free Access" /> <AccessLevel Level="1" Name="Guest" /> <AccessLevel Level="2" Name="Common User - Child" /> <AccessLevel Level="3" Name="Common User - Parent" /> <AccessLevel Level="10" Name="Administrator" /> </AccessLevelList> <UserList> <User ID="1" Name="abcd" Password="efgh" AccessLevel="2" /> <User ID="2" Name="ijkl" Password="mnop" AccessLevel="10" /> </UserList> <ServiceList> <Service ID="1" Name="Aquecimento" /> <Service ID="2" Name="Iluminação" /> <Service ID="3" Name="Alarme" /> <Service ID="4" Name="Tomadas" /> <Service ID="5" Name="Irrigação" /> </ServiceList> 4.1.4.Descrição do comportamento do sistema A descrição do comportamento do sistema contém informação sobre condições e listas de acções a realizar quando essas condições se verificam. Uma condição e respectiva lista de acções é designada de cenário. Um cenário corresponde a uma cláusula do seguinte tipo: IF condição THEN lista-acções O termo condição pode ser uma expressão complexa e pode envolver um instante de tempo e valores de propriedades de dispositivos domóticos. O tempo é considerado uma propriedade de um dispositivo relógio. A lista-acções é a sequência de acções a realizar, em que cada uma consiste na atribuição de um valor a uma propriedade específica de um dispositivo. Esta forma de especificar o comportamento de uma habitação está presente no modelo DomoBus e é bastante simples e eficaz. É fácil de entender por um utilizador comum e simplifica o processo de manter o comportamento desejado. Para além da lista de acções os cenários contemplam uma lista de acções de 30 desactivação. Esta lista contém acções que são executadas quando uma condição de activação deixa de se verificar. Para ilustrar os benefícios desta capacidade analisemos um cenário relativo à rega de um jardim e consideremos a seguinte condição (é usada uma notação em que se identifica um dispositivo e a respectiva propriedade - Dispositivo.propriedade): Relógio.hora >= 10:30 AND Relógio.hora <= 11:00 AND SensorHumidadeSolo.humidade < 25% Quando esta condição é verdadeira, uma lista de acções como a que se indica em seguida seria executada: ElectroválvulaRelva.estado_aberta_fechada = aberta ElectroválvulaCanteiro.estado_aberta_fechada = aberta Como pode ser observado, se nada mais for efectuado, uma vez abertas as electroválvulas estas manteriam o seu estado indefinidamente. A lista de acções de desactivação permite ultrapassar este problema, possibilitando, por exemplo, especificar as seguintes acções: ElectroválvulaRelva.estado_aberta_fechada = fechada ElectroválvulaCanteiro.estado_aberta_fechada = fechada. Deverá existir também mecanismos de segurança que ofereçam uma salvaguarda para que em situações de falha não ocorram problemas nem comportamentos indesejados. Neste exemplo os actuadores das electroválvulas teriam um mecanismo de protecção que assegurariam o corte de energia caso houvesse uma falha na comunicação identificada por não existir comunicação durante um certo período de tempo. O uso de acções de desactivação é opcional e em algumas situações é útil que as acções continuem até indicação do contrário. Figura 22. Modelo de um cenário Na Figura 22 apresenta-se o modelo de um cenário, resumindo-se os conceitos apresentados. Um cenário pode ter uma ou mais acções de activação e qualquer número de acções de desactivação (zero ou mais). A activação de um cenário é controlada pela condição. A condição é definida por um 31 ou mais operadores lógicos. Os operadores são efectuados através da operação de disjunção ―OR‖ e da conjunção ―AND‖. Por sua vez, cada um desses operadores lógicos pode conter uma ou mais expressões (condições envolvendo o teste de uma propriedade de um dispositivo), cada operador lógico pode conter outro operador lógico criando assim várias possibilidades para as condições. O seguinte exemplo XML refere-se a um cenário (―ligar lâmpada quarto‖) com uma acção (―acender a luz‖) e uma desactivação (―apagar a luz‖). Com uma condição ―AND‖ que verifica se está escuro e outra se detecta presença. Estão incluídas também verificações encadeadas apenas para ilustração, não sendo precisas para este exemplo. <ScenarioList> <Scenario ID="1" Name="ligar lampada quarto"> <ActionList> <Action ID="1" Name="aceder a luz" RefDevice="1" RefProperty="1" Value="1" /> </ActionList> <DesactivationList> <Action ID="1" Name="apagar a luz" RefDevice="1" RefProperty="1" Value="0" /> </DesactivationList> <Condition> <Logic Type="AND"> <ConditionExpression RefDevice="1" RefProperty="2" Operator="LT" Value="20" Description="Se está escuro" /> <ConditionExpression RefDevice="2" RefProperty="1" Operator="EQ" Value="1" Description="Se detector de presença activo" /> <Logic Type="AND"> <ConditionExpression RefDevice="1" RefProperty="1" Operator="LT" Value="20" Description="Se está escuro1" /> <ConditionExpression RefDevice="2" RefProperty="1" Operator="EQ" Value="1" Description="Se detector de presença activo1" /> </Logic> <Logic Type="OR"> <ConditionExpression RefDevice="1" RefProperty="1" Operator="LT" Value="20" Description="Se está escuro2" /> <ConditionExpression RefDevice="2" RefProperty="1" Operator="EQ" Value="1" Description="Se detector de presença activo2" /> </Logic> </Logic> </Condition> </Scenario> </ScenarioList> Para além dos cenários é ainda possível ter macros personalizadas em que o funcionamento é parecido com o dos cenários mas não têm a condição e só têm acções de activação. Estas macros servem para um botão ou uma aplicação de controlo poder desencadear uma lista de acções rapidamente no sistema. Um exemplo de uma macro pode ter o nome como ―Ver TV‖, ―Regar o Jardim‖ e pode ser activado pelo simples premir de um interruptor. 32 Figura 23. Modelo de uma macro Uma macro é constituída apenas por uma lista de acções. As macros são úteis para se poder desencadear um conjunto de acções rapidamente. Por exemplo, alterar a luminosidade e a temperatura de um quarto para as preferidas de um utilizador, apenas carregando num botão. Exemplo XML de uma macro de (―Ver TV‖) com três acções: <MacroList> <Macro ID="1" Name="Ver TV"> <ActionList> <Action ID="1" Name="Fecha Estore" RefDevice="1" RefProperty="1" Value="0" /> <Action ID="2" Name="Candeeiro 50%" RefDevice="2" RefProperty="2" Value="50" /> <Action ID="3" Name="LampTecto 40%" RefDevice="3" RefProperty="2" Value="40" /> </ActionList> </Macro> </MacroList> 4.1.5.Configuração dos dispositivos instalados Para instalar dispositivos nas habitações é necessário incluir primeiro os respectivos módulos. Após a instalação do módulo é possível escolher que dispositivos pretendemos instalar e em que divisão. Os dispositivos instalados podem ser depois organizados em serviços como, por exemplo, iluminação, rega, climatização, etc. Os dispositivos têm um nível de acesso e podem ser bloqueados por utilizadores (dispositivos bloqueados só podem ser acedidos pelo próprio ou por quem tenha um nível de privilégio superior). Apresenta-se de seguida o modelo de um dispositivo: 33 Figura 24. Modelo de um dispositivo O dispositivo faz sempre referência à divisão em que está localizado. Os dispositivos têm uma lista de serviços aos quais pertencem (podem pertencer a mais que um serviço). Um dispositivo tem associados dois níveis de acesso (um de leitura e outro de escrita). Os níveis de acesso permitem controlar quem pode monitorizar o dispositivo e quem pode comandá-lo (nível de acesso idêntico ou superior ao definido). Os utilizadores podem bloquear o acesso ao dispositivo para o controlo e monitorização. Se um utilizador tiver um privilégio superior ao do dispositivo ele pode bloquear o acesso à monitorização ou à actuação. Um dispositivo instalado faz sempre referência a um tipo de dispositivo existente que define as suas características de base. O dispositivo depois de instalado é configurado e as suas configurações servem para parametrizar várias das suas funcionalidades e condições de notificação de valores das suas propriedades. Estas propriedades estão associadas ao tipo de dispositivo que este dispositivo implementa. Um dispositivo quando é instalado recebe sempre um endereço DomoBus único que o irá identificar no sistema. As configurações dos dispositivos serão detalhadas na próxima subsecção. Segue-se um exemplo XML relativo a um dispositivo com o endereço ―1010‖ que pertence a dois serviços da habitação. Este dispositivo tem duas das suas propriedades configuradas. A propriedade com a referência ―1‖ tem quatro configurações. Uma para o envio de notificações periódicas do seu valor, outra para o envio de notificações dependendo das alterações ao seu estado e duas condições. A segunda propriedade com a referência ―2‖ tem cinco configurações que definem: o seu limite máximo, o seu limite mínimo, a sua variação de valores, o envio de notificações periódicas do seu valor e o envio do seu estado dependendo da estabilidade do mesmo. 34 <DeviceList> <Device ID="1" RefDeviceType="1" Name="Candeeiro-Mesa" Address="00001010" SupervisiorAddress="#10" RefHouse="1" RefDivision="2" MonAccessLevel="3" ControlAccessLevel="10" UserBlockedMon="-" UserBlockedControl="2"> <DeviceServiceList> <DeviceService RefService="2" /> <DeviceService RefService="4" /> </DeviceServiceList> <ConfigurationList> <NotifyRateConfig RefProperty="1" Value="1" /> <StateChangeConfig RefProperty="1" Value="0" /> <ConditionConfig RefProperty="1" Operator="EQ" Value="10" /> <ConditionConfig RefProperty="1" Operator="NE" Value="10" /> <MaxLimitConfig RefProperty="2" Value="60" /> <MinLimitConfig RefProperty="2" Value="1" /> <VariationConfig RefProperty="2" Value="2" /> <NotifyRateConfig RefProperty="2" Value="1" /> <StateChangeConfig RefProperty="2" Value="0" /> </ConfigurationList> </Device> </DeviceList> 4.1.6.Configuração dos dispositivos No DomoBus cada dispositivo pode suportar vários tipos de configurações de base que estão associadas ao seu tipo genérico de dispositivo - ver Figura 25. Essas configurações definem genericamente, as condições em que são geradas notificações quando ocorrem mudanças de valor nas propriedades de um dispositivo. Existem seis tipos distintos de configurações, podendo estar várias associadas a cada propriedade. Uma propriedade pode, por exemplo, suportar um envio periódico do seu valor. Para o configurar é necessária a informação sobre o valor máximo e mínimo de tempo que é possível definir para esse envio periódico. Após ter a informação dos valores máximos e mínimos para esta configuração o utilizador pode escolher um valor dentro desse intervalo para essa notificação. Além desta configuração existem várias outras que serão detalhadas de seguida. No caso de o sistema estar a utilizar outras tecnologias domóticas quem está responsável por introduzir este conceito de notificações e condições é a gateway associada à tecnologia. 35 Figura 25. Detalhe das configurações do dispositivo (retirado da descrição dos módulos domóticos) A configuração dos dispositivos é opcional e irá conter os itens que estiverem definidos nos tipos de configuração de cada propriedade dos tipos de dispositivos genéricos. Estes tipos de configuração têm valores máximos e mínimos para cada item da configuração que a propriedade suporta. Ao configurar o dispositivo apenas se pode definir um valor dentro desse intervalo máximo e mínimo, valor que será guardado de forma persistente no dispositivo. Existe ainda uma configuração para o número máximo de condições suportadas pelo dispositivo para cada propriedade. Indica-se em seguida os vários tipos de configurações que o modelo DomoBus suporta: 1. Configurar limite inferior. Quando uma propriedade de um sensor está com um valor abaixo do limite inferior é enviada uma mensagem. 2. Configurar limite superior. Quando uma propriedade de um sensor está com um valor acima do limite superior é enviada uma mensagem. 3. Configurar envios periódicos. Com os envios periódicos é possível ter um sensor a enviar o seu valor para outro dispositivo a intervalos regulares cujo valor é configurável. 4. Variações. É possível configurar os dispositivos como por exemplo um sensor de temperatura, para que quando o seu valor variar mais do que um ∆v, avisar um supervisor. Por exemplo se o valor ∆v for 0,5 e se o sensor de temperatura está a 10º ele só irá enviar uma mensagem caso a temperatura esteja a 9,5º ou a 10,5º e só tornará a enviar uma mensagem caso a temperatura volte a variar de novo ∆v. 5. Mudança de estado dos actuadores. Sempre que um actuador muda de estado é possível ter dois tipos de envio da mensagem. No primeiro tipo sempre que o actuador muda de estado é enviada uma mensagem. Para o segundo tipo apenas se envia uma mensagem se o valor estiver estável há pelo menos um tempo ∆t. (∆t = 0 implica envio imediato assim que o estado muda). 6. Condições. Uma propriedade além das configurações acima pode suportar uma ou mais condições. Os limites inferior e superior descritos acima são um caso específico de uma condição. Para as condições é definido um operador lógico (>, >=, <, <=, ==, !=) e um valor de comparação. 36 Se a condição se verificar o dispositivo notifica o seu supervisor. Na ferramenta indica-se o operador de entre uma lista e o valor a usar na comparação. 4.1.7.Configuração das Gateways As gateways são uma parte importante do DomoBus ao permitirem a comunicação com dispositivos de outras tecnologias. Nas gateways serão efectuadas as conversões de endereços e de comandos de uma tecnologia para outra. Estas gateways terão de ser configuradas para definir como irão proceder às conversões mencionadas. Para isso é utilizado um Plug-in que irá dizer como se traduz os endereços e os comandos. Este Plug-in tem ainda a função de adicionar novos tipos de dados ao sistema. Estes tipos de dados estão preparados para trabalhar com a tecnologia específica a que o Plug-in se destina. Para se configurar uma gateway é sempre necessária a utilização de um Plug-in. Figura 26. Modelo de configuração de uma gateway As gateways possuem duas configurações fundamentais que correspondem à conversão de endereços e ao mapeamento de propriedades DomoBus em comandos da tecnologia. Para os endereços existem ainda duas vertentes a considerar que são as conversões de endereços físicos (conversões directas) e de endereços virtuais. Na conversão de endereços físicos, a um endereço DomoBus corresponde um endereço da tecnologia e vice-versa. Nos endereços virtuais, é criado um endereço DomoBus virtual ao qual está associada uma lista de endereços físicos DomoBus. Cada um desses endereços físicos tem a sua representação na conversão directa. Para mapear as propriedades dos dispositivos é necessário recorrer aos tipos de dados que são instalados pelo plug-in. As propriedades, ao utilizarem os tipos de dados do plug-in passam a poder ser mapeadas para as da tecnologia de destino. Para efectuar o mapeamento o plug-in identifica o tipo de dados presente na propriedade e efectua o mapeamento para comandos que a gateway irá 37 reconhecer. A gateway depois tratará das conversões dos comandos de DomoBus para os da tecnologia específica e vice-versa. Depois de configurada a gateway utilizando o respectivo Plug-in é possível guardar o ficheiro XML com a configuração completa da gateway. O exemplo XML que se segue ilustra a configuração de uma gateway para KNX. Neste exemplo é mostrado o mapeamento de endereços directo (DomoBus ―1000‖ para KNX ―1.1.1‖), o mapeamento de um endereço virtual (DomoBus ―1010‖ para KNX ―1.2.2‖) que contém dois endereços no grupo (―1100‖ e ―1101‖) e um mapeamento de duas propriedades de um dispositivo para os comandos que a gateway irá identificar. </DomoBusGatewayList> <DomoBusGateway Name="gateway knx" Technology="KNX" Version="1.0"> <GatewayAddressConfiguration> <AddressMap> <GatewayAddress DBValue="1000" MapValue="1.1.1" /> <GatewayAddress DBValue="1001" MapValue="1.1.2" /> </AddressMap> <virtualAddressMap> <virtualAddress DBValue="1010" MapValue="1.2.2"> <InAddress DBValue="1100" /> <InAddress DBValue="1101" /> </virtualAddress> </virtualAddressMap> </GatewayAddressConfiguration> <GatewayPropertyMap> <GatewayProperty RefDevice="1" RefProperty="1" Command="KNXonoff"/> <GatewayProperty RefDevice="1" RefProperty="2" Command="KNXDIMM"/> </GatewayPropertyMap> </DomoBusGateway> </DomoBusGatewayList> 4.2. Linguagem e ambiente de desenvolvimento Para o desenvolvimento deste trabalho foi escolhida a linguagem de programação C#. O desenvolvimento foi efectuado utilizando o Visual Studio 2008 SP1 (Microsoft 2009) e foi usada a .Net Framework versão 3.5 SP1 com suporte a linq (Microsoft Corporation 2009) e WPF (Microsoft 2009). O ambiente de desenvolvimento escolhido permite uma grande simplicidade e facilidade para criar interfaces com o utilizador e para trabalhar com ficheiros XML. A utilização desta tecnologia não impossibilita a utilização da ferramenta futuramente em ambientes Unix. É possível a utilização da tecnologia Mono (Novell 2008) (ainda não disponível para as versões utilizadas) para fazer a execução de .Net em Linux, MacOS e outros sistemas operativos. A linguagem C# utiliza uma máquina virtual mas ao contrário do que acontece na linguagem Java ela é compilada em tempo de execução e torna-se bastante mais rápida em relação ao Java que é interpretado. Com esta linguagem a gestão de memória já não é da responsabilidade do programador e a criação de plug-ins que irá ser importante é bastante simplificada. 38 4.3. Implementação da ferramenta DomoConfig A ferramenta DomoConfig é composta por três componentes principais como já foi visto atrás na Figura 19. Na interface gráfica estão disponibilizadas todas as opções ao utilizador com dois grandes focos: um vocacionado para o instalador e para o utilizador da habitação e outro mais virado para o fabricante de dispositivos. Na implementação da interface gráfica foi utilizada a tecnologia WPF da plataforma .Net devido à sua enorme flexibilidade na criação de interfaces ricas e agradáveis. A camada intermédia de negócio e a componente de persistência de dados em XML serão explicadas após detalhar a interface. 4.3.1.Interface do instalador e utilizador comum Quando o utilizador executa a aplicação é mostrado um ecrã com a estrutura da habitação e os dispositivos instalados como ilustra a Figura 27. Figura 27. Janela principal do DomoConfig O instalador ou utilizador pode nesta altura editar a configuração da habitação ou se preferir criar uma nova. As seguintes operações estão disponíveis para o utilizador: criar uma nova habitação, alterar o nome de uma habitação e remover a habitação. Dentro da habitação existem as seguintes operações: criar um piso, editar o nome do piso e remover o piso. Para os pisos existem as seguintes operações: criar uma divisão, editar o nome da divisão e remover a divisão. Para trabalhar com os dispositivos inserem-se os módulos adquiridos utilizando a opção de carregar módulo. Após este passo o utilizador pode inserir os dispositivos dos módulos que adquiriu. Também é possível remover dispositivos já instalados. Os dispositivos são inseridos nas várias divisões da habitação escolhidas pelo utilizador e após a inserção torna-se possível configurá-los. 39 Esta configuração incide sobre as suas propriedades como ilustra a Figura 28, onde são definidos os valores dentro do intervalo permitido para os quais o dispositivo deve efectuar uma notificação. Os dispositivos podem ainda ser organizados por serviços, permitindo agregar dispositivos semelhantes. Figura 28. Configuração de um dispositivo e seus serviços Concluída a definição da habitação e a inserção dos dispositivos o passo seguinte é a edição dos cenários. No DomoBus a utilização de cenários permite definir o comportamento geral de uma habitação. Um cenário em DomoBus é constituído por uma lista de acções e uma lista de desactivações. As acções são realizadas quando as condições do cenário se verificarem, a lista de desactivações é realizada no caso contrário. Uma condição é composta por uma expressão lógica com qualquer número de termos combinados usando os operadores AND e OR. Cada um dos termos envolve um teste sobre o valor de uma propriedade de um dispositivo. Apresenta-se em seguida um exemplo muito simples em que se pretende que a actuação de um interruptor acenda uma lâmpada – ver Figura 29. Começa-se por criar um cenário indicando uma condição ―ligar lâmpada quarto‖ com uma expressão AND. Dentro desta expressão AND está uma lista de expressões para a propriedade de um interruptor. 40 Figura 29. Edição de um cenário No cenário existe a acção de activação de acender a luz e a acção de desactivação que é apagar a luz. A condição tem apenas uma expressão lógica AND com apenas um teste (expressão de comparação) a uma propriedade de um interruptor – ver Figura 30. Figura 30. Lista de expressões de uma condição 41 Quando a condição for verificada (se o interruptor está ligado) é enviada uma ordem para a lâmpada acender. Esta ordem consiste em modificar o valor de uma propriedade (On-Off) da lâmpada para ela se ligar. Quando a condição deixar de se verificar (desligar o interruptor) a lâmpada é desligada. Neste caso é enviada uma ordem para ser modificado o valor da propriedade da lâmpada. Um cenário pode ser bastante complexo fazendo uso de várias expressões lógicas e diversas expressões de comparação entre várias propriedades de diversos dispositivos. Para além dos cenários o utilizador tem ainda a possibilidade de configurar macros, as quais são úteis para desencadear múltiplas acções. A aplicação permite também definir quais os utilizadores existentes – ver Figura 32 – e definir os seus níveis de acesso - ver Figura 31. Estes níveis de acesso são necessários para verificar quem pode aceder aos diversos dispositivos, sendo distinguido o acesso em termos de monitorização (conhecer o seu estado) e em termos de actuação (alterar o seu estado). Figura 31. Utilizadores do sistema 42 Figura 32. Níveis de Acesso Quando é necessário utilizar outra tecnologia domótica na habitação o DomoConfig permite configurar as gateways para a tecnologia específica. A configuração de uma gateway é um processo avançado e exige alguns conhecimentos por parte de quem as está a configurar. Para efectuar a configuração de uma gateway é necessária a instalação de um plug-in para essa tecnologia. Figura 33. Gestão de plug-ins Os plug-ins são ficheiros DLL que adicionam a funcionalidade de configurar uma gateway para uma tecnologia específica. Os plug-ins incluem os tipos de dados específicos para trabalharem com essa tecnologia que se baseiam nos tipos de base do DomoBus: enumerados, escalares e vectores. É necessário instalar estes tipos de dados para se poder efectuar a conversão dos comandos da tecnologia específica para a lógica DomoBus. Para cada dispositivo que se pretenda utilizar numa 43 tecnologia específica é necessário alterar os tipos de dados das propriedades dos tipos de dispositivos para os tipos de dados do plug-in. Com estes tipos de dados pré configurados para uma tecnologia específica é possível enviar os comandos certos para essa tecnologia. Depois de efectuada a definição dos tipos de dados a gateway pode começar a ser configurada, o que se inicia pela escolha dos dispositivos da habitação que se deseja aceder na outra tecnologia. Figura 34. Configuração de uma gateway Na Figura 34 ilustra-se uma gateway para X10 e apresenta-se um dispositivo (um candeeiro) nessa tecnologia que se pretende que seja controlado utilizando a lógica DomoBus recorrendo a duas propriedades. De notar que os tipos de dados das propriedades (X10On-Off e X10Dimming) são um tipo de dados instalado pelo plug-in da tecnologia X10. Estes tipos de dados incluem a informação do comando na tecnologia X10. Depois de escolhidos os dispositivos e as propriedades a mapear é necessário premir os botões de ―gerar mapeamentos‖ e ―gerar comandos‖, sendo gerado um endereço X10 para o dispositivo e comandos compatíveis com as propriedades. O endereço gerado é único e sequencial, podendo ser modificado em qualquer altura. Em alternativa à geração automática, os endereços podem ser todos explicitados manualmente. O comando gerado será um código que a gateway reconhece. A gateway utiliza o endereço DomoBus do dispositivo, o tipo de dados da 44 propriedade e o comando para depois enviar a mensagem correcta para a tecnologia específica. Esta mensagem é gerada com base no mapeamento de endereço do dispositivo, juntamente com a informação incluída no tipo de dados da propriedade e do comando mapeado. Após a geração dos endereços e dos comandos a configuração de uma gateway está pronta para ser exportada para um ficheiro XML que posteriormente pode ser modificado. Este ficheiro será carregado pela gateway que fica então configurada e pronta a funcionar. Dentro da configuração da gateway está a informação sobre o nome, tecnologia e versão da configuração bem como todos os mapeamentos criados: uma lista de endereços DomoBus com o respectivo endereço da tecnologia específica, uma lista de endereços DomoBus virtuais com o seu endereço correspondente na tecnologia específica e a lista de dispositivos do grupo associado a esse endereço virtual, e uma lista de propriedades mapeadas e respectivos comandos associados. Concluída a configuração da habitação por parte do instalador ou utilizador comum, é necessário guardar os dados da habitação configurada. Para se guardar os dados escolhe-se no menu da Figura 35 a opção ―Guardar como‖ e é criado um ficheiro XML com toda a informação da configuração efectuada. Figura 35. Menu da aplicação DomoConfig Neste menu é possível abrir um ficheiro de configuração anteriormente criado, edita-lo na aplicação e tornar a guardá-lo. Neste menu existe ainda a opção de criar uma nova configuração, alterar o tema da aplicação, consultar a janela acerca e sair. 4.3.2.Interface para fabricante Quando se está no modo de fabricante a aplicação oferece outras opções para permitir a gestão dos módulos e a gestão de todos os tipos de dados genéricos, como ilustra a Figura 36. 45 Figura 36. Janela principal do DomoConfig em modo fabricante Para a criação dos módulos o fabricante dispõe aqui de tudo o que precisa. Inicialmente começase por criar os tipos de dados genéricos e se for necessário criam-se conversores para os tipos de dados. Após ter criado os tipos de dados genéricos o fabricante avança para a definição de configurações e para a criação dos tipos de dispositivos genéricos. Ou, se for o caso, pode reutilizar outros criados anteriormente. 46 Figura 37. Gestão dos tipos de configurações Na criação dos tipos de configurações das propriedades, ver Figura 37, o fabricante tem de indicar as configurações que a propriedade suporta e para cada uma os limites permitidos dos valores máximos e mínimos. Por exemplo, o limite máximo nesta configuração só pode variar entre 1 e 100 graus. O que significa que quando se aplicar este tipo de configuração a uma propriedade e se for configurar a tal propriedade de um dispositivo, só é possível escolher valores entre 1 e 100 para a definição do limite máximo. Para as condições apenas se indica o número máximo de condições suportadas pela propriedade. De notar que um tipo de configuração não necessita conter todas as seis configurações possíveis. Figura 38. Gestão dos tipos de dispositivos genéricos Na criação dos dispositivos genéricos, ver Figura 38, o fabricante tem de criar as propriedades desse dispositivo, dar-lhes um nome, escolher o tipo de acesso (leitura, escrita ou ambos), escolher um tipo de dados existente e associar-lhes um tipo de configuração previamente criado. Pode ainda 47 escolher uma classe e uma descrição para o dispositivo. Na Figura 38 apresenta-se o exemplo de uma lâmpada regulada que pertence à classe de iluminação e tem duas propriedades: uma (On-Off) que guarda o estado ligado ou desligado e outra (Intensidade) que guarda a intensidade luminosa em percentagem. Concluída a fase de criação dos dispositivos genéricos, o fabricante cria um módulo e adiciona os dispositivos que o módulo implementa, como ilustra a Figura 39. Figura 39. Gestão de módulos No exemplo ilustrado na Figura 39 existe um módulo de uma estação meteorológica com dois dispositivos: um sensor de temperatura e um de humidade. Na criação dos módulos é necessário introduzir o endereço local dos dispositivos que será utilizado pela aplicação para a geração de endereços DomoBus quando este dispositivo for instalado numa habitação. Por fim, o fabricante pode exportar a descrição do módulo criado para um ficheiro XML e entregá-lo juntamente com o módulo físico. 4.3.3.Camada de negócio da aplicação DomoConfig A camada intermédia da aplicação é onde estão as estruturas de dados necessárias ao funcionamento da aplicação e toda a lógica de funcionamento. Esta componente está dividida em duas partes: uma DLL com todas as estruturas de dados, que são partilhadas com os plug-ins, e outra com a lógica aplicacional. As estruturas de dados guardam toda a informação que é carregada do XML ou, no caso de uma nova configuração elas estão vazias. Existe uma classe que será a classe agregadora de todas as estruturas de dados. Nesta classe estão as listas de objectos para várias entidades que existem na aplicação. Além das listas esta classe também tem a informação dos ficheiros XML. A Figura 40 mostra o esquema da classe. 48 Figura 40. Modelo da classe global As entidades ilustradas na Figura 40, que no código são classes, podem conter listas de outras entidades como é o caso da estrutura de dados que guarda a informação das habitações. As entidades podem referenciar outras entidades como no caso dos dispositivos, em que eles referenciam a sua divisão. Cada uma destas listas possui métodos de inserção, remoção e pesquisa para facilitar a utilização das mesmas. Notar que certas entidades, como a entidade Habitação, incluem também métodos próprios que permitem, por exemplo, a edição das propriedades da habitação. A entidade habitação tem uma lista de entidades piso e a entidade piso tem uma lista de entidades divisão como ilustra a Figura 41. Figura 41. Diagrama de classes das habitações Existem também estruturas para os demais tipos de dados presentes no XML, que foi explicado na subsecção 4.1. Todas têm a sua lista de entidades, pelo que os ficheiros XML ficam todos disponíveis na memória num formato simples de trabalhar. As entidades que guardam endereços DomoBus e a janela de inserção de dispositivos para gerarem ou alterarem os endereços DomoBus recorrem a um gestor de endereços. Ao ser inserido um dispositivo na habitação a aplicação, utilizando o gestor de endereços, atribui um endereço DomoBus que pode ser alterado pelo utilizador. Para a configuração ser correcta nenhum dos endereços pode ser repetido. O gestor de endereços tem como função gerar sempre um endereço único para cada novo dispositivo e de verificar se um endereço quando é alterado não se está a repetir. Assim é possível garantir a unicidade de endereços dentro da aplicação. 49 A classe global juntamente com as estruturas de dados e o gestor de endereços estão no projecto ―TiposComuns‖ que são compiladas como uma biblioteca dinâmica DLL. Esta DLL é partilhada com a aplicação e com os plug-ins. Os plug-ins têm de seguir uma interface específica. Esta interface contém propriedades obrigatórias como o nome da tecnologia, criador e data. Além das propriedades têm que ser implementados quatro métodos. Se uma tecnologia não suportar o endereçamento de grupo um dos métodos pode ser deixado em branco enviando uma mensagem a avisar o utilizador da limitação. A figura seguinte ilustra a interface a implementar. Figura 42. Diagrama da interface dos plug-ins Nesta interface as propriedades são listas de caracteres (strings) e devem de ser preenchidas com a informação necessária. O método ―InstalarTipos‖ é um método que será chamado quando o utilizador carregar o plug-in e premir o botão de instalar tipos de dados da janela ilustrada na Figura 33. Neste método devem ser adicionados ao sistema os tipos de dados escalares, vectores e enumerados necessários à tecnologia. Se for necessário também devem ser adicionados os conversores. Os outros três métodos são chamados a partir da janela de configuração das gateways da Figura 34. Estes métodos são executados quando o utilizador premir um dos botões de ―gerar‖, seja o gerar mapeamentos tanto directos como virtuais, seja o gerar comandos. Na geração dos endereços o método do plug-in recebe uma lista de endereços de dispositivos e associa a cada um, um endereço da tecnologia específica. O mesmo acontece para os endereços virtuais. O método recebe uma lista de endereços virtuais e atribui endereços de grupo específicos da tecnologia. Para a geração de comandos são recebidas as propriedades e, após a análise do seu tipo de dados, o plugin atribui-lhes um comando que a gateway entende. Os tipos de dados utilizados pelas propriedades têm de ser os mesmos que foram instalados pelo plug-in ou podem ser os que vêm previamente configurados pelo fabricante desde que o fabricante utilize tipos de dados do plug-in. A criação de um plug-in implica recorrer a um projecto à parte que tem de ser compilado como uma biblioteca dinâmica (DLL). A interface a implementar está incluída na biblioteca DLL ―TiposComuns‖ 50 do DomoConfig. No projecto terá que ser feita uma referência à biblioteca DLL ―TiposComuns‖ para ser possível implementar a interface e trabalhar com as estruturas de dados. A aplicação tem a missão de controlar todas estas estruturas e de lidar com os plug-ins enviando a informação para a interface gráfica. Na altura de adicionar novos dados a aplicação terá de criar novas classes e adicioná-las, juntamente com as existentes, na lista correcta. Lista essa que está presente na classe global. A aplicação tem de verificar se certas operações são possíveis como a remoção de certas entidades. Por exemplo, se um dispositivo está instalado numa divisão é impossível remover essa divisão da habitação ou a configuração tornar-se-ia incorrecta. O envio de mensagens de erro para o utilizador é gerado através de excepções detectadas pela camada aplicacional que provém normalmente das estruturas de dados e ocorre tipicamente quando são introduzidos valores errados ou quando se tenta carregar um XML que não seja o correcto ou um DLL que não é um plug-in válido. Esta parte da aplicação pertence ao projecto de ―DomoConfig‖ e está directamente ligada à interface gráfica (GUI). 4.3.4.Persistência de dados A persistência de dados na aplicação é feita utilizando ficheiros XML que serão tratados na ferramenta utilizando um módulo de software específico chamado XMLUtil. Neste módulo é realizada a verificação e o carregamento dos ficheiros XML para as estruturas de dados internas utilizadas pela aplicação. As importações de módulos e das configurações das gateways também passam por esta camada, pois ambas têm estruturas de dados internas como as demais configurações. A gravação dos dados das configurações é o processo inverso em que são convertidas todas as estruturas de dados para XML. O mesmo se verifica nas exportações de módulos e configurações de gateways. Para este módulo de software é vastamente utilizada a tecnologia linq da plataforma .Net de modo a facilitar o tratamento de XML e tornando-o um processo extremamente rápido. Na tecnologia linq um ficheiro XML é tratado como se fosse uma base de dados normal, onde se pode utilizar a linguagem linq (semelhante ao SQL), para efectuar consultas e alterações à base de dados (XML). Este módulo encontra-se dentro do projecto da aplicação ―DomoConfig‖ e pode ser facilmente substituído por outro módulo que guarde os dados numa Base de dados ou outro suporte. O módulo é uma classe que inclui métodos para carregar e guardar cada um dos tipos de dados do XML descrito na secção 4.1. Cada um destes dados terá um método próprio para o carregamento do XML e um para a escrita da informação para XML. Quando é necessário carregar um ficheiro previamente guardado, são chamados por uma certa ordem os vários métodos de carregamento e eles efectuarão a leitura do XML, conversão para classes e adição às listas da classe global. No fim e se não existir nenhum problema no XML, a aplicação está pronta a editar a configuração carregada. Para guardar a configuração são chamados os métodos de criação do XML pela mesma ordem de leitura. Após a geração do documento final ele é guardado num ficheiro especificado pelo utilizador. 51 4.3.5.Organização do código O código da aplicação está organizado numa solução com 2 grandes projectos: ―DomoConfig‖ e ―TiposComuns‖. Estes dois projectos são a base da aplicação. Existe ainda um projecto secundário para a criação de um programa de instalação da ferramenta. Para gerar os p lug-ins são usados projectos específicos como explicado mais adiante. No projecto DomoConfig estão incluídas todas as janelas da aplicação, uma pasta com imagens e ícones da aplicação e o módulo ―XMLUtil‖ como ilustra a Figura 43. Este projecto gera o executável da aplicação. Figura 43. Projecto ―DomoConfig‖ Neste projecto foram utilizadas duas bibliotecas externas para utilização na interface de modo a torná-la mais agradável e prática. Uma biblioteca foi o WPF Ribbon preview 1 para criar interfaces com ―ribbons‖ semelhantes às do Microsoft Office 2007 e do Windows 7. Outra biblioteca incluída foi o WPF Tookit2 para a criação de ―Datagrids‖ facilitando a edição e apresentação de dados na aplicação Ambas as bibliotecas estarão incluídas na próxima versão do Visual Studio 2010. No projecto TiposComuns, que gera uma biblioteca DLL, estão incluídas todas as classes de dados numa pasta Dados, as excepções numa pasta Excepções, a classe global (explicada anteriormente) e uma interface de um plug-in. Tanto o projecto DomoConfig como um Plug-in têm que fazer referência a este projecto. Na pasta de Dados deste projecto encontram-se oito ficheiros com classes. Cada um destes ficheiros está organizado por categorias: ―ClassesCenarios‖, ―ClassesDispositivos‖, ―ClassesGateway‖, ―ClassesGerais‖, ―ClassesHabitacao‖, ―ClassesPlugins‖, ―ClassesTiposDados‖, ―ClassesUtilizadores‖. Cada uma destas classes gere a informação que o próprio nome da classe sugere. A Figura 44 ilustra a organização do projecto ―TiposComuns‖. 1 2 http://wpf.codeplex.com/ http://wpf.codeplex.com/ 52 Figura 44. Projecto ―TiposComuns‖ Um projecto de um plug-in apenas tem uma classe que implementa a interface ―IPlugin‖ do projecto ―TiposComuns‖ como ilustra a Figura 45. Figura 45. Projecto de um plug-in X10 53 5. Avaliação do trabalho Para avaliar o trabalho foram realizados testes de usabilidade de modo a verificar a correcta execução das tarefas. São apresentados dois casos de uso e algumas tarefas para os utilizadores fazerem. Com base nestas tarefas são calculados: o número de erros, o número de passos e o tempo necessário que um utilizador precisa para elaborar cada uma delas. Com os resultados dos testes é possível concluir se a ferramenta se comporta como era de esperar e se tem uma utilização simples. Adicionalmente foi elaborada uma tabela comparativa de custos de diferentes ferramentas de modo a verificar a mais económica. 5.1. Casos de uso Caso de uso para um utilizador comum ou instalador quando deseja configurar uma nova habitação e definir alguns cenários: 1. Utilizador cria níveis de acesso e utilizadores da habitação 2. Utilizador cria a sua habitação 3. Utilizador instala os módulos que adquiriu 4. Utilizador adiciona dispositivos nas devidas divisões 5. Utilizador cria os cenários que definem o comportamento desejado para a habitação 6. Utilizador guarda a configuração Caso de uso para um fabricante que deseja criar um módulo: 1. Utilizador cria alguns tipos de dados 2. Utilizador cria classes para os dispositivos 3. Utilizador cria tipos de configurações 4. Utilizador cria tipos de dispositivos 5. Utilizador cria módulos e adiciona os dispositivos 6. Utilizador exporta os módulos 5.2. Resultados dos testes Antes da realização dos testes foi feita uma breve explicação sobre o modelo DomoBus aos utilizadores, também foi explicado algumas noções sobre ETS. 5.2.1. Utilização da ferramenta para a criação de uma configuração Teste de usabilidade: Criar a configuração de uma habitação com um piso e duas divisões. Incluir um módulo adquirido que possui 2 lâmpadas e 2 interruptores. Incluir uma lâmpada e um interruptor em cada divisão, Criar o comportamento para fazer a ligação desses interruptores com as lâmpadas. 54 Tabela 1. Resultados da tarefa Criar níveis de acesso e utilizadores Subtarefa Atributo Medida Valor actual Óptimo (Utilizador Avançado em DC) Criar níveis de acesso e utilizadores Facilidade em criar utilizadores e níveis de acesso na 1ª utilização Tempo total dispendido 20seg (criar um utilizador no Windows) 10seg Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Observado (utilizador experiência em ETS) sem Utilizador 1 17seg Utilizador 2 18seg Utilizador 3 22seg Média 19seg com 13seg 12seg 15seg 13seg sem Não existe esta funcionalidade Tabela 2. Resultados da tarefa Criar uma habitação com 1 piso e 2 divisões Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Criar uma habitação com 1 piso e 2 divisões Facilidade em criar uma habitação na 1ªutilização Tempo total dispendido e número de erros 16seg/0erros Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Observado (utilizador experiência em ETS) sem Utilizador 1 1:46min/1erro Utilizador 2 1:59min/0erros Utilizador 3 1:11min/0erro Média 1:39min/0erros com 32seg/0erros 36seg/0erros 25seg/0erros 31seg/0erros sem 2:00min/1erro 1:40min/0erros 1:41min/1erros 1:47min/1erro Tabela 3. Resultados da tarefa Instalar os dispositivos adquiridos e coloca-los nas divisões Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Instalar os dispositivos adquiridos e coloca-los nas divisões Facilidade em instalar e adicionar dispositivos na 1ª utilização Tempo total dispendido e total de clicks 11seg/ 9clicks Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Observado (utilizador experiência em ETS) Utilizador 1 55seg/ 12clicks 16seg/9clicks Utilizador 2 48seg/ 10clicks 19seg/9clicks Utilizador 3 43seg/9clicks Média 49seg/10clicks 18seg/9clicks 18seg/9clicks 1:51min/ 19clicks 2:25min/ 23clicks 1:43seg/ 16clicks 2:00min/ 19clicks sem com sem Tabela 4. Resultados da tarefa Criar cenários de comportamento Subtarefa Atributo Medida Óptimo (Utilizador Avançado Criar cenários de comportamento Facilidade em criar cenários de comportamento na 1ª utilização Tempo total dispendido / nº erros 27seg/0erros 55 em DC) Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Observado (utilizador experiência em ETS) sem com sem Utilizador 1 3:24min/ 1erro 1:30min/ 1erro 2:51min/ 2erros Utilizador 2 4:22min/2erros Utilizador 3 2:27min/1erro Média 3:24min/1erro 1:56min/0erros 1:01min/0erros 1:29min/0erros 3:43min/1erro 2:22min/2erros 2:59min/2erros Tabela 5. Resultados da tarefa Guardar a configuração Subtarefa Atributo Medida Valor actual Óptimo (Utilizador Avançado em DC) Guardar a configuração Facilidade em guardar a configuração na 1ª utilização Número de passos 2 Passos (guardar um ficheiro no bloco de notas) 1 Passo Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Observado (utilizador experiência em ETS) sem Utilizador 1 2Passos Utilizador 2 1Passo Utilizador 3 1Passo Média 1Passo com 1 Passo 1Passo 1Passo 1Passo sem 0 Passos, a ferramenta guarda automaticamente ao sair 5.2.2. Utilização da ferramenta para a criação de um módulo domótico Teste de usabilidade: Criar um módulo domótico com 2 dispositivos, um dispositivo que seja um sensor de temperatura e um que seja um interruptor de uma lâmpada. Tabela 6. Resultados da tarefa Criar os tipos de dados Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) sem com Criar os tipos de dados Facilidade na criação dos tipos de dados necessários na 1ª utilização Tempo / nº erros 20seg/0erros Utilizador 1 1:06min/ 0erros 31seg/0erros Utilizador 2 1:50min/1erro Utilizador 3 2:05/0erro Média 1:40min/0erros 45seg/0erros 37seg/0erros 38seg/0erros Tabela 7. Resultados da tarefa Criar classes para os dispositivos Subtarefa Atributo Medida Criar classes para dispositivos Facilidade na criação das classes de dispositivos na 1ª utilização Número de erros 56 Óptimo (Utilizador Avançado em DC) Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) 0 Erros sem Utilizador 1 Utilizador 2 Utilizador 3 0 Erros com 0 Erros Média Tabela 8. Resultados da tarefa Criar tipos de configuração Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Criar tipos de configuração Facilidade na criação de tipos de configuração na 1ª utilização Tempo / nº erros 50seg/0erros Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) Utilizador 1 3:16min/2err os 1:25min/1err os sem com Utilizador 2 5:04min/2erros Utilizador 3 3:34min/1erro Média 3:58min/2erros 1:55min/0erros 1:38min/0erro s 1:29min/0erros Tabela 9. Resultados da tarefa Criar tipos de dispositivos Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) sem com Criar tipos de dispositivos Facilidade na criação dos tipos de dispositivos genéricos na 1ª utilização Tempo / nº erros 25seg/0erros Utilizador 1 1:13min/ 0erros 43seg/0erros Utilizador 2 58seg/0erros Utilizador 3 1:41seg/1erro Média 1:17min/0erros 39seg/0erros 50seg/0erros 44seg/0erros Tabela 10. Resultados da tarefa Criar módulos e exporta-los Subtarefa Atributo Medida Óptimo (Utilizador Avançado em DC) Criar módulos e exporta-los Facilidade na criação e exportação dos módulos na 1ª utilização Tempo 19seg Resultados Observado (utilizador experiência em DC) Observado (utilizador experiência em DC) sem Utilizador 1 59seg Utilizador 2 51seg Utilizador 3 1:25min Média 1:05min com 35seg 30seg 36seg 34seg 5.3. Avaliação dos resultados 57 Com a análise destes resultados é possível verificar que, quando o utilizador já possui alguma experiência, o número de erros ou passos é baixo e muito próximo do que se poderá considerar um valor óptimo. No caso de um utilizador inexperiente o número de erros está na maior parte das vezes dentro de um valor normal. Em relação ao tempo dispendido na execução das tarefas, no caso de um utilizador com pouca experiência, esse tempo é mais alto e melhor na maior parte das vezes que na ferramenta ETS. Já um utilizador com experiência consegue ter tempos melhores e perto dos tempos óptimos. O único ponto onde se notou algum desvio maior dos tempos pretendidos foi na criação de cenários de comportamento devido a ser uma tarefa mais exigente. A interface foi desenvolvida tendo em consideração as opiniões e sugestões de vários utilizadores, o que contribuiu para criar uma interface mais simples e fácil de utilizar como mostram os resultados. 5.4. Comparação de custos Outro problema existente nas ferramentas actuais é o seu elevado custo. Na seguinte tabela é feito um comparativo aos preços das ferramentas estudadas. Tabela 11. Comparativo de preços das ferramentas de configuração Ferramenta Preço ETS (KNX) 900€ - 950€ LonMaker (LonWorks) 900$ (+-638€) Notas Sistema de créditos: 5$ cada pack, próxima versão já não tem o sistema de créditos. DomoConfig (DomoBus) 0€ Verificando a tabela de comparação de preços das ferramentas, é possível verificar que na próxima versão da ferramenta LonMaker o sistema de créditos irá terminar, reduzindo os custos na configuração de sistemas LonWorks, mas ainda assim a ferramenta é paga e com um valor elevado para um utilizador comum. A ferramenta DomoConfig torna-se a mais económica do teste, pois permite configurar mais que uma tecnologia e gratuitamente. Para uma correcta utilização da ferramenta ETS é necessária formação com um custo de cerca de 2000€, embora a pessoa que foi formada passe a ser um instalador KNX credenciado. O que é pouco prático para um utilizador comum que só queira alterar um parâmetro na sua habitação. A ferramenta DomoConfig será gratuita e disponibilizada para todos sem qualquer restrição, além disso toda a sua documentação e especificação será igualmente gratuita e disponibilizada. Em relação aos plug-ins, o sistema está feito de maneira a que sejam gratuitos e utilizados sem restrições. 58 6. Conclusões Este documento teve como objectivo apresentar uma proposta para uma ferramenta de configuração de instalações domóticas suficientemente genérica para lidar com qualquer tecnologia, baseando-se no modelo DomoBus. A domótica tem uma crescente divulgação e existem várias tecnologias com diversas formas de configurar os sistemas. O problema da configuração é que o utilizador final não conseguia ou era bastante complexo alterar as configurações de um sistema. E uma pequena alteração poderia envolver contactar pessoal técnico e implicar custos elevados. Outro problema estava no custo das ferramentas de configuração que é elevado para o utilizador final. Para ultrapassar estes problemas foram estudadas diversas tecnologias domóticas e suas ferramentas de configuração em que foram identificados alguns problemas e limitações nas mesmas. Verificou-se então que a tecnologia DomoBus era a mais indicada para este trabalho, devido ao seu modelo genérico, a possibilidade de interligar-se com outras tecnologias e a facilidade de configuração da habitação sem ser necessário colocar o sistema parcialmente desligado para efectuar pequenas configurações. Avaliadas as diversas tecnologias e escolhendo o DomoBus como a mais adequada, foi proposta e desenvolvida uma ferramenta de configuração de sistemas domóticos que visa aproveitar todas as vantagens do DomoBus face às outras tecnologias, e que é fácil de usar por utilizadores não peritos em domótica. Pretendeu-se também reduzir drasticamente o custo associado a este tipo de ferramentas e permitir a interligação com outras tecnologias domóticas. O recurso ao modelo DomoBus permite que seja criada uma configuração genérica para qualquer tecnologia, sendo a informação relevante guardada em XML. A especificação do XML existente no DomoBus teve de ser reformulada e actualizada para obedecer aos novos requisitos e permitir as novas funcionalidades. A ferramenta desenvolvida permite ultrapassar a generalidade dos problemas identificados nas ferramentas de outras tecnologias e oferece ainda suporte para permitir a modificação interactiva do comportamento do sistema, o que não é oferecido nas outras tecnologias analisadas. É possível a utilização da ferramenta para outras tecnologias, desde que o sistema seja devidamente configurado utilizando os plug-ins e as gateways adequadas. Para além do desenvolvimento da aplicação foi ainda desenvolvido um plug-in para a tecnologia X10 para verificar a compatibilidade da aplicação com essa tecnologia. Esse plug-in poderá ser usado, no futuro, como base para o desenvolvimento de plug-ins para outras tecnologias. Concluído o desenvolvimento foram feitos testes com utilizadores para verificar se a utilização da ferramenta era fácil e correcta. Com estes testes foi verificado que a ferramenta tinha uma utilização simples e que os utilizadores realizam correctamente as acções solicitadas. Com a ferramenta desenvolvida no presente trabalho espera-se ter dado um contributo para tornar a domótica um serviço mais simples e agradável de utilizar por qualquer utilizador, e mais útil e fácil de adaptar às necessidades de cada pessoa. 59 6.1. Trabalho futuro A ferramenta foi desenvolvida com base nas opiniões de utilizadores sendo que a sua interface está bastante simples de perceber logo numa primeira utilização. No entanto detectou-se um problema na definição de comportamentos pois os utilizadores demoravam mais tempo que o esperado e por vezes cometiam erros. Devido a este problema, e como trabalho futuro, poderá ser criada uma nova forma de definir comportamentos, em que se pudesse dispor de um modo simples e outro avançado (que corresponde ao que existe actualmente). No modo simples poder-se-ia criar comportamento juntando dois ou mais dispositivos e a aplicação automaticamente percebia as propriedades semelhantes e criava o comportamento, acções, desactivações e as expressões necessárias. Funcionando apenas para dispositivos simples tais como lâmpadas e interruptores ou outros pré-definidos. Nas ferramentas ETS e LonMaker após a criação da configuração da habitação existe uma funcionalidade que permite o envio da mesma para a rede e colocar todo o sistema operacional. Numa próxima versão deveria ser implementada esta funcionalidade para que a ferramenta ficasse mais completa, embora esta funcionalidade não tenha sido um requisito para este trabalho. 60 7. Referencias Atmel Corporation. AVR 8-Bit RISC processor. 2009. http://www.atmel.com/products/AVR/ (acedido em 2009). BatiBUS. 2009. http://www.cwct.co.uk/ibcwindow/ibc/fieldbus/batibus.html (acedido em Janeiro de 2009). CEBus. 2009. http://en.wikipedia.org/wiki/CEBus (acedido em Janeiro de 2009). Douglas Lighting controls. Definitions of LonWorks Terms. 2003. Echelon Corporation. 2009. http://www.echelon.com/ (acedido em Agosto de 2009). ECHELON Corporation. LonMaker User’s Guide. USA, 2003. Echelon Corporation. LonMaker® User’s Guide Turbo Edition. United States of America, 2006. EIB Interworking Standards. EIBA Handbook Series, Volume 3 System Specifications, Part 7: Interworking. Release 3.0. Vol. 3. 1999. European Home Systems Protocol. 2008. http://en.wikipedia.org/wiki/European_Home_Systems_Protocol (acedido em Dezembro de 2008). Harry Crijns, Konnex Association. System-architecture. Brussels-Diegem, 2004. Kell, Alan, e Peter Colebrook. Open Systems for Homes and Buildings:Comparing LonWorks and KNX. United Kingdom: i&i limited, 2004. KNX Association. 2008. http://www.knx.org/ (acedido em Dezembro de 2008). —. ETS. 2009. http://www.knx.org/knx-tools/ets/description/ (acedido em Agosto de 2009). Microsoft Corporation. LINQ. 2009. http://msdn.microsoft.com/en-us/netframework/aa904594.aspx (acedido em 2009). Microsoft. Visual Studio 2008 SP1. 2009. http://msdn.microsoft.com/en-us/vstudio/default.aspx (acedido em 2009). —. WPF. 2009. http://msdn.microsoft.com/en-us/library/ms754130.aspx (acedido em 2009). Novell. Mono. 2008. http://www.mono-project.com/Main_Page (acedido em Dezembro de 2008). Nunes, Prof. Renato. Comunicação no sistema DomoBus Application Programming Interface. Lisboa, 2005. —. DomoBus. 2009. http://www.domobus.net/ (acedido em 2009). —. Especificação XML de um Sistema DomoBus. Lisboa, 2006. Nunes, Renato. ―EIB (BUS de Instalação Europeu) ETS2.‖ IST - Disciplina de Mestrado Ambientes Inteligentes. Alameda. NUNES, Renato J. ―A Communication Infrastructure for Home Automation.‖ International Conference on Computer, Communications and Control Technologies. Austin, USA, Agosto 2004. 5661. Nunes, Renato Jorge Caleira. ―Decentralized Supervision for Home Automation.‖ MELECON 2006 The 13th IEEE Mediterranean Electrotechnical Conference. Benalmádena, Espanha, Maio 2006. —. ―DomoBus - A New Approach to Home Automation.‖ 8CLEEE - 8th International Congress on Electrical Engineering, Portugal, July 2003. Lisboa, Julho 2003. 2.19-2.24. 61 —. ―Implementing Tiny Embedded Systems with Networking Capabilities.‖ Implementing Tiny Embedded Systems with Networking Capabilities", . Algarve, Portugal, Fevereiro 2005. —. ―Modelo de Especificação e Programação de um Sistema Domótico.‖ IADIS Conferência IberoAmericana WWW/Internet 2004. Madrid, Espanha, Outubro 2004. 377-384. POWERHOUSE. X10 Technical Note. USA, 2003. Weinzierl, Dr.-Ing. Thomas. Development kit for EIB/KNX devices based on the TP-UART chip. Alemanha: WEINZIERL ENGINEERING GMBH, 2004. X10. About X10. 2009. http://www.x10.com/about.htm (acedido em 2008). 62