Padrão de formatação - paginas.fe.up.ptpaginas.fe.up.pt/~ee04228/actas/tese2.pdf · Sistema...
Transcript of Padrão de formatação - paginas.fe.up.ptpaginas.fe.up.pt/~ee04228/actas/tese2.pdf · Sistema...
Faculdade de Engenharia da Universidade do Porto
Sistema modular de comunicação e controlo de dispositivos sensores/atuadores: Um ensaio na
NextToYou - Network Solutions, Lda.
Luis Alberto Cerqueira Sousa
VERSÃO PROVISÓRIA
Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores
Major Automação
Orientador: Prof. Dr. José Ruela
Co-orientador: Engº Rui Moreira
© Luis Alberto Cerqueira Sousa, 26 de Junho 2012
iii
Resumo
O presente documento descreve o trabalho efetuado no âmbito da dissertação de mestrado,
os objetivos do projeto, as opções tomadas, os passos seguidos e as conclusões e ambições futuras
do projeto.
Esta dissertação tinha como objetivo desenvolver um sistema de gestão para uma aplicação
de domótica a integrar num sistema existente desenvolvido pela empresa onde esta dissertação se
desenrolou. O sistema de gestão de domótica a desenvolver teria ser implementado numa Intranet,
ou seja, o sistema deveria operar numa rede domótica KNX já implementada. A rede de domótica
KNX implementada possui um Router, uma fonte de alimentação e um módulo de quatro saídas. O
Router garante a fiabilidade da comunicação entre um sistema externo e a rede KNX, a fonte de
alimentação alimenta toda a rede, o módulo de quatros saídas permite o controlo das saídas
independentemente das cargas elétricas (lâmpada, motor, led, etc.) colocadas para controlo, e
possui quatro sensores que permitem verificar o estado (on/off) das saídas desse módulo.
O sistema de gestão de domótica é constituído por um computador com o sistema operativo
Windows, um módulo de software que foi desenvolvido na dissertação e o programa Calimero. Com
a perspetiva a futuros desenvolvimentos como a ligação remota ao sistema de domótica, o software
devia ser desenvolvido numa linguagem compatível com o Worl Wide Web. As linguagens escolhidas
para esse efeito foram HTML e CSS para a parte visual, Javascript para criar mais interação entre o
sistema e o utilizador e por fim PHP responsável pelo controlo de todo o sistema de gestão de
domótica. O sistema de gestão de domótica controla o programa Calimero, segundo as decisões de
controlo do utilizador e de forma a que rede KNX já existente responda essas decisões.
O software a desenvolvido teve como base uma arquitetura Model View Controller, ou seja,
uma arquitetura de software modular. Esta arquitetura foi adotada para que o sistema possa
facilmente ser adaptado às opções que uma rede KNX oferece, em número, variedade e
funcionalidades dos dispositivos. Esta arquitetura permite também alterar o modelo de negócio, a
apresentação e o controlo do software sem que se tenha de alterar todo o sistema ou alguma das
partes que não seja necessária.
Tudo o que foi desenvolvido na dissertação teve por base o protocolo de domótica KNX.
v
Abstract
This document consists in a master thesis describing the goals, decisions, implementation and
conclusions and future work in order to describe work done along the project.
This dissertation has the goal of developing a demotic management system, integrating the
application in a system built by the enterprise that hosted this project.
The demotic management system had to be implemented on an intranet, in other words, the
system had to operate in an already implemented KNX demotic network. The implemented network
has a Router, a power source and a four port module. The Router guarantee communication
reliability between an external system and the KNX network, the power supply feeds all the
network and the four ports module enables the control of all ports regardless of the electrical
charges ( lamp, motor, led, etc…) used to control and has four sensors that checks the state (
on/off) of each module output.
The demotic system consists of a computer with Windows operating system, a software module
developed in the dissertation and the Calimero application. The system had to be built on a
language compatible with the Worl Wide Web, covering the need of developing a software capable
of establishing a remote connection to the demotic system. Chosen languages were HTML and CSS
for the graphic interface[parte visual], JavaScript with the goal of stimulating interaction
between user and the system and finally PHP responsible of controlling all the demotic
management system. The demotic management system controls the Calimero application,
respecting the user decisions and letting the existing KNX network respond to that decisionsThe
software was developed using a Model View Controller architecture, in other words, a modular
software architecture. This architecture was adopted with the idea of easily integrate system with
the options that KNX network offers in quantity, variety, and device features. Finally this
architecture enables to edit one of the business, presentation or control models separately
avoiding unnecessary work.
All dissertation work was developed under the KNX demotic protocol.
viii
Agradecimentos
Quero expressar o meu sincero agradecimento ao meu orientador, Prof. José Ruela, pelo seu
interesse e acompanhamento, mesmo fora de horas, no desenvolvimento e escrita desta
dissertação.
Quero agradecer ao Luciano Alves pelas inúmeras sugestões e acompanhamento no
desenvolvimento da aplicação e pela revisão e sugestões dadas relativas ao artigo escrito em Inglês.
Quero também agradecer à minha mãe pela educação por tudo aquilo que faz de mim a pessoa
que sou hoje.
Quero ainda deixar um agradecimento à empresa NexttoYou pela compreensão e pelo tempo
disponibilizado para a realização do projeto e desta dissertação.
Agradeço a todos que me apoiaram incondicionalmente neste meu percurso académico.
A todos o meu muito obrigado.
x
Índice
Resumo ............................................................................................ iii
Abstract ............................................................................................. v
Agradecimentos ................................................................................. viii
Índice ............................................................................................... x
Lista de figuras ................................................................................... xii
Abreviaturas e Símbolos ....................................................................... xvi
Capítulo 1 .......................................................................................... 1
Introdução..................................................................................................... 1 1.1 - Problema ............................................................................................ 1 1.2 - Motivação ............................................................................................ 2 1.3 - Estrutura da dissertação .......................................................................... 3 O relatório divide-se em 9 capítulos: .................................................................. 3
Capítulo 2 .......................................................................................... 4 2.1 História .............................................................................................. 4 2.2 Objetivos da Domótica ............................................................................ 4 2.3 Áreas de controlo ................................................................................... 5
2.4 Protocolos de comunicação ......................................................................... 6 2.4.1 X-10 ............................................................................................. 6
Capítulo 3 .......................................................................................... 9
Sistemas KNX ................................................................................................. 9 3.1 História .............................................................................................. 9 Principais características e vantagens .............................................................. 10 Desvantagens ............................................................................................ 11 3.2 Arquitectura e Elementos KNX ................................................................. 11 Modos de configuração ................................................................................. 11 Tipos de implementação .............................................................................. 13 Dispositivos .............................................................................................. 13 Acopladores .............................................................................................. 14 BCU (Bus Coupling Units) .............................................................................. 15 PEI (Physical External Interface) ..................................................................... 16 3.3 Rede KNX e Endereçamento .................................................................... 17 Topologia da Rede KNX ................................................................................ 17 Telegrama KNX .......................................................................................... 20
xi
3.4 Gateway IP / Bus KNX ............................................................................ 25 Troca de Dados e Interfuncionamento .............................................................. 26 3.5 Instalação de Redes KNX ....................................................................... 31 Quadro elétrico ......................................................................................... 31 Tipo de cabo ............................................................................................. 33
Capítulo 4 ......................................................................................... 35
Sistema de gestão de domótica ........................................................................... 35 3.1 Sistema de gestão de domótica ................................................................ 35 4.1 Model ............................................................................................... 37 4.2 View ................................................................................................. 37 4.4 BASE DE DADOS ................................................................................... 38
Capítulo 5 ......................................................................................... 42
Tecnologias adoptadas ..................................................................................... 43 5.3 CSS 44 5.4 Javascript .......................................................................................... 45 5.5 PHP .................................................................................................. 48 5.6 Calimero ............................................................................................ 49 5.7 Wampserver ....................................................................................... 49
Capítulo 6 ......................................................................................... 51
Interface gráfica .......................................................... Erro! Marcador não definido. 6.2 Processamento do controlo ..................................................................... 52
Capítulo 7 ......................................................................................... 54
Teste e avaliação do sistema .............................................................................. 54 7.1 Cenários de teste ................................................................................. 54 7.2 Base dados ......................................................................................... 54 7.3 Configuração da rede IP e configuração KNX ................................................ 62 7.6 Base de dados ..................................................................................... 68
Referências ....................................................................................... 74
xii
Lista de figuras
Figura 1: Exemplo de sistema de implementação do KNX. ............................................... 9
Figura 2: Exemplo de uma Rede KNX. ....................................................................... 10
Figura 3: Modos de configuração do KNX. ................................................................... 13
Figura 4: Estrutura de um dispositivo KNX. ................................................................. 14
Figura 5: Arquitetura de um BCU. ............................................................................ 15
Figura 6: Arquitectura de um TRC.. .......................................................................... 16
Figura 7: Diagrama de pinos do PEI. .......................................................................... 16
Figura 8: Tipos de redes KNX. ................................................................................. 18
Figura 9: Topologia genérica de um sistema KNX. ......................................................... 19
Figura 10: Endereços individuais do protocolo KNX. ...................................................... 20
Figura 11: Endereços de grupo no protocolo KNX. ........................................................ 20
Figura 12: Características de um telegrama KNX. ......................................................... 21
Figura 13: Características do campo de controlo de um telegrama KNX.. ............................ 22
Figura 14: Endereço individual. ............................................................................... 22
Figura 15: Endereços de grupo de dois e três níveis. ..................................................... 23
Figura 16: Características do campo de controlo de um telegrama KNX. ............................. 23
Figura 17: Campo contador. ................................................................................... 23
Figura 18: Campo de dados. ................................................................................... 24
Figura 19: Campo de verificação cruzada. .................................................................. 24
Figura 20: Estrutura de uma mensagem de confirmação. ................................................ 24
Figura 21: Montagens com routers IP/KNX. ................................................................. 26
Figura 22: Exemplo de comunicação entre um interruptor e uma lâmpada. ......................... 27
xiii
Figura 23: Pirâmide de inter-funcionamento. .............................................................. 28
Figura 24: Funções EIB. ......................................................................................... 29
Figura 25: Função EIB2 (dimming). ........................................................................... 29
Figura 26: Função EIB2 (Priority). ............................................................................ 30
Figura 27: Diferentes tipos de calha e cobertura para calha DIN. ...................................... 31
Figura 28: Montagem Rail-mounted. ......................................................................... 32
Figura 29: Dispositivos do tipo montagem embebida. .................................................... 32
Figura 30: Dispositivo do tipo montagem de superfície .................................................. 32
Figura 31: Dispositivo do tipo montagem Device mounted. .............................................. 33
Figura 32: Isolamento de cabos para KNX. .................................................................. 33
Figura 33: Características de um cabo param KNX. ....................................................... 34
Figura 34: Arquitetura global do sistema. ................................................................... 35
Figura 35: Arquitetura de Software do sistema a desenvolvida. ........................................ 36
Figura 36: Esquema da base de dados elaborada para armazenar a informação da rede KNX. ... 40
Figura 37: Modelo final da base de dados. .................................................................... 42
Figura 38: Página de login sem a influência da CSS. ......................................................... 44
Figura 39: Página de login já com a influência da CSS. ...................................................... 45
Figura 40: Organograma das classes de objetos existentes em Javascript................................ 46
Figura 41: Caixa de dialogo alert() do objeto Window. ..................................................... 46
Figura 42: Página antes de clicar no botão Ler e ativar o script. .......................................... 47
Figura 43: Página depois de clicar no botão Ler e ativar o script. ......................................... 47
Figura 44: HTML sem a influência das folhas de estilo e o Javascript. .................................... 51
Figura 45: HTML já com a influência das folhas de estilo mas sem o Javascript. ....................... 52
Figura 46: HTML já com a influência das folhas de estilo e o Javascript. ................................ 52
Figura 47: Pesquisa na base de dados na tabela habitações. ............................................ 55
Figura 48: Pesquisa à base de dados por habitações. ..................................................... 56
Figura 49: Pesquisa de utilizadores efetuada na base de dados. ....................................... 56
Figura 50: Pesquisa de utilizadores do sistema efetuada à base de dados. ........................... 57
Figura 51: Pesquisa de Datapoints efetuada na base de dados. ......................................... 57
Figura 52: Pesquisa de Datapoints efetuada à base de dados pelo sistema. .......................... 58
xiv
Figura 53: Pesquisa por dispositivos na base de dados. .................................................. 58
Figura 54: Pesquisa efetuada a base de dados pelo sistema à procura de todos os dispositivos. ................................................................................................. 59
Figura 55: Pesquisa efetuada a base de dados à procura de todos os endereços de grupo. ....... 59
Figura 56: Pesquisa efetuada a base de dados pelo sistema à procura de todos os endereços de grupo. .................................................................................................... 60
Figura 57: Pesquisa na base de dados por dispositivoaddressgroup. ................................... 61
Figura 58: Pesquisa por dispositivoaddressgroup na base de dados efetuada pelo sistema. ...... 61
Figura 59: Configuração do IP alternativo do computador para funcionar com o Calimero. ...... 62
Figura 60: Página de login. ..................................................................................... 63
Figura 61: Página de acesso interdito. ....................................................................... 64
Figura 62: Página de controlo para utilizadores do tipo util2. .......................................... 64
Figura 63: Página de controlo para utilizadores do tipo util1. .......................................... 65
Figura 64: Página de controlo para utilizadores do tipo admin. ........................................ 65
Figura 65: Página de acesso a base de dados para utilizadores do tipo admin. ...................... 66
Figura 66: Página de edição do utilizador do tipo admin, Luisa. ....................................... 66
Figura 67: Página de controlo para utilizadores do tipo técnico e escolha da habitação a controlar. ................................................................................................... 67
Figura 68: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação1. ................................................................................................. 67
Figura 69: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação2. ................................................................................................. 68
Figura 70: Página da base de dados para editar, adicionar, pesquisar e eliminar habitação. ..... 69
Figura 71: Página da base de dados para editar, adicionar, pesquisar e eliminar utilizadores ... 69
Figura 72: Página da base de dados para editar, adicionar, pesquisar e eliminar dispositivos. .. 70
Figura 73: Página da base de dados para editar, adicionar, pesquisar e eliminar Datapoints. ... 70
Figura 74: Página da base de dados para editar, adicionar, pesquisar e eliminar endereços de grupo. .................................................................................................... 71
Figura 75: Página da base de dados para editar, adicionar, pesquisar e eliminar relações entre um dispositivo e um endereço de grupo (dispositivoaddressgroup). ..................... 71
xvi
Abreviaturas e Símbolos
Lista de abreviaturas (ordenadas por ordem alfabética)
AA - Acoplador de área
AC - Area Coupler
ACK - Acknowledgement (data networks)
AL - Acoplador de linha
AM – application module
A-Mode - Automatic mode
ANACOM - Autoridade Nacional de Comunicações
AP- application program
BAU- Bus Access Unit
BCU - Bus Coupling Unit
BIM- Bus Interface Modules
BUSY- Linha de bus ocupada
CEBus - Consumer Electronics Bus
CENELEC EN - European Committee for Electrotechnical Standardization
CEN EN - European Committee for Standardization
CSMA/CA - Carrier Sense Multiple Access with Collision Avoidance
DIN - Deutsches Institut für Normung
EEPROM - Electrically Erasable Programmable Read Only Memory
EHS - European Home Systems Protocol
EIA - Electronic Industries Association
EIB - European Installation Bus
EIBA - European Installation Bus Association
EIB/KNX - European Installation Bus/konnex
EIS - EIB Interworking Standard
EIS - EIB Interworking Standard
E-Mode - easy mode
xvii
EN - European standards
ETS - Engineering Tool Software
HTTP - Hypertext Transfer Protocol
IP - Internet Protocol
IR - infra-red
ISO - International Organization for Standardization
ITED - Infra-estruturas de Telecomunicações em Edifícios
KNX- konnex
LC – Line Coupler
LAN – Local Area Network
MVC - Model-view-controller
Mysql - Structured Query Language
NACK - negative acknowledgement
PEI - Physical External Interface
PLC- Power Line Carrier
RAM – Random access memory
RF - Radio frequency
ROM – read only memory
RP - Repetidor de Linha
SCADA - supervisory control and data acquisition
SELV - Safety Extra Low Voltage
S-Mode - system mode
TRC- Transceive
X-10 - protocolo de comunicação para domótica (USA)
Capítulo 1
Introdução
1.1 - Problema
O problema proposto pela empresa NextToYou sedeada no INESC Porto será o tema para a
dissertação a desenvolver no 2º semestre de 2011/2012. O projeto proposto para desenvolver
durante a dissertação foi a criação de um sistema de gestão de domótica do tipo modular que
permite o controlo remoto de dispositivos sensores (estado electroválvulas, intrusão, etc.) e
atuadores (ligar, desligar, ativar alarmes, gerar avisos SMS/Email, etc.). O Software desenvolvido
teve como base uma arquitetura de Software modular do tipo Model-view-controller (MVC). Esta
arquitetura de Software visa separar a lógica de negócio da lógica de apresentação, permitindo
assim o desenvolvimento, teste e manutenção isolado de ambos.
O modelo (model) será uma base de dados em Mysql ou Postgres usada para fazer o registo no
domínio dos dados do sistema, que permitirá armazenar, modificar e extrair informação de um
banco de dados mediante as necessidades do sistema. Esta será uma representação detalhada da
informação que a aplicação gera e necessita para o funcionamento de todo o sistema.
A visão (view) tem como objectivo a representação do sistema de uma forma gráfica ao
utilizador, apresentando os dados de saída do sistema assim como os dados a fornecer ao sistema
pelo utilizador. Isso permite a interação entre este e o sistema, oferecendo para um mesmo modelo
diferentes visões mediante as funcionalidades e decisões tomadas pelo utilizador. Inicialmente será
uma página Web e, mais tarde, pretende-se a publicação da mesma como a possibilidade de acesso
ao sistema, através de internet e/ou PDA.
O controlador (controller) é um sistema baseado no protocolo HTTP que fará a gestão da base
de dados. Tais dados irão permitir atuar as saídas e atualizar a visão gráfica apresentada ao
utilizador. O controlador recebe-os e inicia a resposta ao utilizador, invocando as funções do
sistema de domótica adequadas à ordem efetuada e apresentando a visão baseada nas entradas
inseridas. Este também é responsável pela validação e filtragem da entrada de dados.
2 Introdução
2
O sistema de domótica desenvolvido foi baseado no protocolo aberto KNX. Isso deveu-se à
análise dos prós e contras efetuados pela empresa: visto ser o que oferece mais e melhores
vantagens para a empresa, para o produto e para o cliente (mercado).
1.2 - Motivação
A automação de edifícios sempre foi vista como um artigo de luxo capaz de assegurar um maior
conforto, autonomia aos utilizadores e segurança a um edifício. Com o crescente sedentarismo das
pessoas, por motivos profissionais e devido às vantagens oferecidas pela domótica, cada vez mais é
vista aos olhos dos consumidores como algo cada vez mais fundamentável. Hoje em dia, e cada vez
mais, existem equipamentos e dispositivos nas nossas casas que melhoram a nossa qualidade de
vida. Os eletrodomésticos inteligentes e os sistemas de controlo de iluminação são bons exemplos
de equipamentos que aumentam o conforto. Contudo, necessitam da interação humana para
poderem funcionar de acordo com as suas pretensões, tendo de ser atuado de forma independente
para satisfazer as preferências de cada utilizador. Os sistemas ao atuar só sob as ordens dos
utilizadores não permite atingir uma boa solução global em termos de eficiência energética, pois o
utilizador não consegue estar constantemente a controlar os diferentes dispositivos. Com a
necessidade de relacionar fatores como as condições ambientais, o consumo energético, a
segurança e o conforto, os sistemas de domótica vêm de encontro às necessidades dos utilizadores.
A grande motivação desta dissertação está na satisfação das necessidades de mercado, no
apelo comercial e futurista da domótica e visando uma versão comercial mais avançada do produto
já existente. Este trabalho vem dar continuidade a um projeto já existente: um sistema de
domótica. O âmbito da dissertação é a criação de um Software de gestão de domótica com
linguagem Web. Este futuramente poderá permitir a gestão do sistema por acesso remoto através
da Internet.
A NextToYou já possuía uma rede KNX construída é configurada, mas pretendia alargar a
capacidade do controlo domótico incluindo mais dispositivos e criando um sistema de gestão para
a rede existente. Para isso será desenvolvido um Software com base na linguagem Web para
gestão do condomínio com o intuito de futuramente conseguir controlar uma rede KNX com o
maior número de funcionalidades possíveis. O Software desenvolvido teve por base uma
arquitetura modular MVC com a finalidade de ser mais fácil de evoluir e modificar o sistema todo.
Com estes atributos, a empresa pretende criar um sistema capaz de rivalizar e superiorizar-se aos
existentes no mercado, de modo a conseguir tornar-se, quem sabe, líder de mercado. Para atingir
esta meta, será necessário o desenvolvimento de um sistema que apresente uma qualidade igual
ou superior aos sistemas já existentes mas a um preço inferior. A empresa não pretende
desenvolver os seus próprios dispositivos (hardware), mas sim utilizar dispositivos fornecidos por
revendedores que possam comunicar com o sistema a desenvolver. É necessário que seja um
sistema de arquitectura modular e passível de suportar a sua integração numa plataforma de
serviços existente, tendo como fim um sistema robusto e seguro, estando protegido de possíveis
ataques que possam prejudicar o bom funcionamento.
Erro! A origem da referência não foi encontrada. 3
1.3 - Estrutura da dissertação
O relatório divide-se em 9 capítulos:
Capitulo 1: é apresentado o resumo, índice a lista das figuras e a lista de abreviaturas;
Introdução: é explicado o âmbito do projeto, a motivação para a elaboração do projeto, os
objetivos da dissertação e a estrutura do relatório;
Estado da arte da Domótica: é apresentado um estudo aprofundado da domótica e dos seus
protocolos até aos nossos dias, com em especial atenção para o protoclo X-10 e o protocolo
da dissertação o KNX.
Sistemas KNX: é contada a história da criação do protocolo KNX e a sua evolução (Evolução
histórica), explicada e exemplificados alguns tipos de arquiteturas KNX e explicada a
constituição dos dispositivos utilizados num sistema KNX (Arquitetura e Elementos KNX). É
explicado como se elabora uma rede KNX e como os dispositivos interagem e comunicam
entre si (Rede KNX e Endereçamento). São também explicados os princípios e requisitos de
uma instalação de domótica com o protocolo KNX (Instalações KNX);
Sistema de gestão de domótica:
É apresentada a arquitetura de Software (MVC) que foi utilizada para desenvolver o
sistema;
É apresentado e explicado o modelo de base de dados criado e implementado;
E apresentada a Interface gráfica que será apresentada ao utilizador ao utilizar o sistema
desenvolvido;
É feita uma apresentação de Calimero e explicado o processamento do controlo efetuado
através do Calimero.
Teste e avaliação do sistema- são apresentados os testes às principais funcionalidades do
sistema de gestão desenvolvido e é feita uma avaliação do mesmo. Os testes efetuados
pretenderam a avaliação funcional e qualitativa do sistema de gestão de domótica;
Conclusões: é feita uma análise dos objetivos propostos para esta dissertação e
apresentadas as conclusões;
Desenvolvimentos futuros: são apresentados e explicadas as espectativas do sistema de
gestão domótica desenvolvido;
Bibliografia: são enumeradas as fontes de conhecimento nas quais foram baseadas o
relatório.
Capítulo 2
2. Estado da Arte em Domótica
2.1 História
Domótica é a integração de tecnologias e serviços, que permite a gestão de todos os recursos
de edifícios (habitações, escritórios, hospitais entre outros) de uma forma autónoma. A palavra
Domótica (domotique) surgiu na França, por volta dos anos 80, no século XX, durante a construção
dos primeiros edifícios, e da necessidade de controlar e interligar as funções de climatização,
segurança e iluminação. A palavra Domótica é a junção de domus do Latim (lar ou casa) com a
palavra telemática (telecomunicações + informática). Numa perspetiva mais abrangente, domótica
é a utilização de um conjunto de tecnologias e sistemas (eletricidade, eletróncia e tecnologias da
informação), que deverão funcionar de uma forma integrada, permitindo o controlo e uma gestão
automática dos diferentes recursos de um edifício, local ou de forma remota (Internet) oferecendo
uma vasta gama de aplicações. Outro sinónimo para domótica é casa inteligente (smart house),
porém nesta dissertação será utilizado o termo domótica.
2.2 Objetivos da Domótica
A domótica tem como grande objetivo oferecer a automatização de uma vasta gama de
aplicações nas áreas da segurança, conforto, comunicações e gestão de energia rentabilizando o
sistema, simplificando a vida diária das pessoas, satisfazendo as suas necessidades. A domótica
pode substituir o ser humano em diversas atividades rotineiras de forma a propiciar uma otimização
nas condições de vida numa casa. O próprio sistema zela pela satisfação dos clientes, sem que seja
necessária a contínua intervenção do mesmo. A vantagem de um sistema de domótica perante
sistemas de alarme ou outros automatismos é o facto de ele próprio se ir otimizando com base nas
informações recolhidas pelos diversos dispositivos que estão ligados ao sistema. Os sistemas de
domótica deverão ter capacidade de inteligência distribuída e de interação com os diversos
subsistemas de um edifício ou de uma habitação (Ar Condicionado, Luzes, Segurança,
eletrodomésticos, aparelhos de multimédia, etc.) mas de uma forma integrada, numa única central
que gere todos os espaços autónomos e todos os sistemas. Ou seja o sistema deve possuir pequenos
módulos que possam tomar decisões simples e um módulo principal que faça a gestão desses
módulos de uma forma centralizada, pois é esse módulo que possui a informação de todo o sistema.
A automatização de edifícios envolve questões técnicas e funcionais. Sob um ponto de vista
Erro! A origem da referência não foi encontrada. 5
funcional devem-se analisar questões como "que funções realizar" (comandos, medidas a obter,
parâmetros a regular, etc.), "quando realizá-las" (em tempo) e "como se realizam" fisicamente. Sob
o ponto de vista técnico, devesse planear questões como a modularização do sistema, periféricos e
a compatibilidade com elementos de outros fabricantes. O grau de controlo domótico alcançado
pode ser variável, sendo uma função do custo, desejo pessoal dos clientes, estrutura do edifício e
tecnologia usada.
2.3 Áreas de controlo
A Domótica pode ser divida em quatro grandes áreas, a saber: a gestão de energia, a segurança, o
conforto e as comunicações. De seguida serão enumerados os benefícios, as funções e as ações
tomadas pela domótica, nas áreas em que foram divididas:
Gestão de energia: Otimizar a relação conforto / consumo energético;
Ajuste automático de temperatura;
Gestão da iluminação;
Permitir um uso mais racional da água;
Controlo de electro domésticos: ligar/desligar electro domésticos como máquinas de lavar,
secar roupa e sistemas de aquecimento, quando as tarifas de energia elétricas são mais
baixas;
Facilitar o uso de energias renováveis:
Aquecimento de água;
Produção de energia elétrica;
Redução de desperdícios energéticos:
Iluminação: desliga automaticamente as luzes quando não houver pessoas em
determinado ambiente;
Reaproveitamento de águas pouco sujas para utilização sanitária;
Controlo de temperatura: poder controlar aquecedores e ar condicionado de forma
a minimizar o consumo de energia.
Segurança: Vigilância e deteção de intrusão;
Simulação de presença: ligar música e luzes;
Deteção de situações de emergência;
Monitorização de pessoas e bens (sistemas de videovigilância ou circuito fechado de
televisão);
Gerar alarmes técnicos em situações de emergência ou anómalas:
Inundação;
Fuga de gás e água;
Falta de energia;
Fogo e fumo: deteção rápida;
Forno, luzes, esquentador ou fogão está ou estão ligados;
Portas ou janelas abertas;
Alarme médico: monitorização e diagnóstico remoto de sinais vitais;
Enviar a informação dos alarmes técnicos para telefone, telemóvel, PDA, e-mail, sistema
SCADA e página Web;
6 Introdução
6
Corte automático da água e gás em caso de ocorrência de fuga;
Acionar automaticamente os serviços de segurança:
Alerta a moradores (SMS, e-mail, chamada telefónica);
Fazer chamada para bombeiros e/ou polícia.
Conforto: Permitir uma melhor qualidade de vida e maior autonomia;
Facilitar tarefas, automatizar procedimentos (Acionamento automático de tarefas de rotina
como ligar o aquecimento);
Controlar, monitorizar e administrar a casa à distância;
Auxiliar de memória (controlar a toma de medicamentos, etc.);
Apoio a pessoas idosas, doentes ou com deficiências (permitir maior autonomia e
telemedicina);
Entretenimento (Vídeo, áudio e multimédia);
Adequar a iluminação e climatização para as diferentes pessoas;
Ligar luz (por presença, som, hora ou luz ambiente);
Abrir/ fechar persianas (controlo automático por presença de luz ambiente, chuvas e pelo
despertador);
Abertura de portões ou portas por reconhecimento de pessoas ou outros (matrículas, etc.);
Sistema de rega automática;
Comunicações: Proporcionar uma comunicação eficiente com o mundo externo;
Interligar a rede interna de uma casa (domótica, intranet) com a rede externa (por Internet);
Capacidade de controlar algum dispositivo remotamente;
Teletrabalho e Teleformação;
Divulgação das redes domésticas (Home Networks);
Acesso à Internet em banda larga;
Expansão das tecnologias Wireless (IEEE 802.11x, Bluetooth, ZigBee, ...);
Maior largura de banda (rede IP global integrando dados, voz e imagem);
Centralização: ligar/desligar o sistema com um único botão remotamente.
2.4 Protocolos de comunicação
Existe uma grande variedade de protocolos de comunicação para sistemas de domótica.
Todavia, serão enumerados os mais conhecidos com uma breve descrição. Posteriormente, será
feita uma descrição mais exaustiva do protocolo escolhido.
2.4.1 X-10
O X-10 é o protocolo mais antigo usado nas aplicações de domótica. Foi desenvolvido entre
1976 e 1978 com o objetivo de transmitir dados por linhas de baixa tensão (110V nos EUA e 230V na
Europa) a uma velocidade muito baixa (60 bps no EUA e 50 bps na Europa) e com custos muito
baixos. Ao usar as linhas elétricas da habitação, não é necessário instalar nova cablagem para ligar
Erro! A origem da referência não foi encontrada. 7
os dispositivos. O protocolo X-10 é proprietário mas a sua patente já expirou pelo que, atualmente,
qualquer fabricante pode produzir dispositivos X-10 e oferecê-los ao mercado. Graças ao seu
amadurecimento (mais de 30 anos no mercado) e à tecnologia implementada, os produtos X-10 tem
um preço muito competitivo e são líderes no mercado residencial Norte-Americano, podendo as
instalações ser realizadas por eletricistas sem conhecimentos de automação ou informática ou até
pelos próprios utilizadores. O preço e a facilidade de instalação são de facto os principais pontos
fortes desta tecnologia.
Existem três tipos de dispositivos X-10: os que só podem transmitir ordens, conhecidos por
controladores, os que só podem receber ordens conhecido por recetores, e os dispositivos que
podem receber e enviar ordens, que são na prática recetores com capacidade de responder e
confirmar a realização correta de uma ordem (feedback). Os controladores enviam sinais de
comando para os recetores que, por sua vez, fazem atuar o dispositivo elétrico que lhe está ligado.
Os recetores são adaptadores que se instalam entre o dispositivo elétrico que se pretende controlar
e a fonte de corrente elétrica que o alimenta. Os recetores vêm dotados de dois pequenos
comutadores giratórios, um com 16 letras (código da casa) e o outro com 16 números (código do
dispositivo), que permitem identificar um dos 256 endereços possíveis. Numa mesma instalação
pode haver vários recetores configurados com o mesmo endereço, todos realizam a função pré-
designada, desde que um controlador envie um telegrama com o seu endereço de destino. A
pequena gama de endereços existentes nesta tecnologia torna-a inadequada para grandes edifícios,
dado que só permite a existência de 256 dispositivos recetores independentes. Esta é uma
importante limitação relativamente às outras tecnologias existentes. Qualquer ação num sistema X-
10 implica o envio de duas mensagens: mensagem de seleção do dispositivo e mensagem com a
ordem a executar. De forma a minimizar possíveis falhas de comunicação, as mensagens são
enviadas em duplicado. Este protocolo de comunicação torna o envio de comandos para os
dispositivos um processo demasiado moroso, sendo este outro ponto fraco desta tecnologia. Por
outro lado, dado que este protocolo não inclui qualquer controlo sobre a correta receção de
mensagens por parte dos dispositivos recetores, esta tecnologia apresenta um baixo nível de
fiabilidade. Concluindo, a tecnologia X10 é uma tecnologia com bastante sucesso dado o seu baixo
custo e facilidade de instalação. No entanto apresenta bastantes limitações, comparando
nomeadamente com o EIB/KNX. O X-10 é apenas dirigido para pequenos ambientes residenciais
dada a sua incapacidade para suportar muitos dispositivos, e a pouca fiabilidade, robustez e rapidez
do seu protocolo de comunicação.
2.4.2 KNX
KNX - o protocolo KNX foi publicado pela recente Associação KNX em 2002 - é um protocolo de
domótica aberto. Foi desenvolvido por 110 empresas líderes de mercado e assenta num standard
mundial para o controlo de habitações e de edifícios ISO/IEC 14543-3. Aprovado como Norma
Europeia CENELEC EN 50090 e CEN EN 13321-1. Presentemente, existem centenas de fabricantes a
produzir equipamento certificado pela associação Konnex, disponibilizando aos clientes e
instaladores. Com mais variedade e opções para o desenvolvimento de soluções modernas e
competitivas, este protocolo permite ao utilizador o controlo local e remoto das aplicações
existentes na sua instalação. O protocolo KNX é a única norma global para domótica com uma
ferramenta de programação (ETS Engineering Tool Software) e conceção única e independente do
fabricante tem um conjunto vasto de meios de ligação suportados (par entrançado, linha de
potência, RF e IP /Ethernet) e inúmeros modos de configuração suportados.
EIB (European Installation Bus) - Protocolo concebido pela EIBA - European Instalation Bus
Association inicialmente pensado como sistema de gestão de instalações elétricas de edifícios.
8 Introdução
8
LonTalk - Tecnologia LonWorks desenvolvida na Echelon Corporation nos EUA em 1993 como
uma tecnologia de automação distribuída. A maior parte dos sistemas até então desenvolvidos eram
de controlo centralizado. A Echelon desafia essa premissa lançando um conceito inovador que em
1999 é definido como norma (Protocolo LonTalk).
CEBus (Consumer Electronics Bus) - Surgiu em 1984 como standard promovido pela EIA
(Electronic Industries Association).
Batibus – é um protocolo “open-source” dispõe de um sistema de controlo de colisões, baseado
numa hierarquia de prioridades. Nos dispositivos Batibus é possível seleccionar o seu endereço na
rede, à semelhança do Protocolo X-10. Todos os dispositivos escutam todas as mensagens, mas
apenas os invocados as executam.
EHS - o protocolo foi criado em 1992 por uma comissão de grandes empresas europeias de
produção eletrodomésticos. Esta comissão criou este protocolo como um protocolo aberto e com
uma vasta gama de aplicações, permitindo que equipamentos de diferentes fabricantes
comuniquem entre si de forma a que possam partilhar recursos. Hoje em dia já existem produtos
em Hardware e Software standard. As maiores empresas europeias de produção eletrodoméstica já
incluem o protocolo EHS nos seus produtos.
Erro! A origem da referência não foi encontrada. 9
Capítulo 3
Sistemas KNX
3.1 História
O protocolo KNX nasceu do desenvolvimento e da vontade de tornar standard as especificações
de comunicação do antigo protocolo EIB (European Instalation Bus), já anteriormente referido. Este
protocolo resultou da mistura de mais de 15 anos de experiência dos antecessores deste protocolo
( EIB, EHS e BATIBUS) e da união de empresas ligadas ao fabrico de materiais elétricos e eletrónicos
e de eletrodomésticos. KNX é um protocolo que permite ser utilizado em qualquer tipo de sistema:
desde a pequena habitação a grandes condomínios. Este protocolo devido ao seu grande
desenvolvimento permite a monitorização e controlo de sistemas de videovigilância, consumos de
energia, sistemas de iluminação, ar condicionado, contagem, controlo de áudio/vídeo,
aquecimento, ventilação e regularização automática de persianas. Todas estas funções podem ser
controladas, vigiadas e sinalizadas através dum sistema único sem necessidade de centrais de
controlo extra. Todos os componentes do sistema são ligados à rede KNX e as ligações podem ser
feitas por cabo entrançado, infravermelhos, radiofrequência, rede elétrica ou IP/Ethernet. É
através destas ligações que os dispositivos da rede trocam ou fornecem informações. Os dispositivos
ligados através de meios físicos como o par entrançado entre outros, retiram a energia para
funcionar através do barramento e os dispositivos sem ligação física têm fontes de alimentação
adicionais. As figuras seguintes mostram simples sistemas de aplicação do protocolo KNX e a rede
KNX.
Figura 1: Exemplo de sistema de implementação do KNX.
10 Introdução
10
Figura 2: Exemplo de uma Rede KNX.
Uma das grandes vantagens do KNX é possibilitar a construção de um sistema modular, em
qualquer altura do desenvolvimento do sistema ou até depois de implementado haverá a
possibilidade de acrescentar mais dispositivos e funções ao sistema, pois é reconfigurável. Esta
vantagem advém de ser um sistema descentralizado e em que os dispositivos comunicam entre si,
uma vez que podem ser recetores e emissores sem necessidade de hierarquia e/ou supervisão da
rede. Têm apenas de comunicar entre si através de telegramas segundo o formato definido pelo
protocolo. Este tipo de sistema é normalmente controlado por um computador comum, passando
assim a ter uma arquitetura centralizada e podendo ser controlado por outro qualquer sistema com
acesso à Internet. O intuito do desenvolvimento deste protocolo foi aumentar a flexibilidade e as
capacidades dos sistemas com um custo reduzido. Pode-se dizer portanto que os objetivos foram
quase cumpridos. No que toca aos custos e à flexibilidade, não se pode dizer que são dos sistemas
mais baratos e nem dos mais flexíveis. Contudo continua a ter a vantagem de ser um protocolo
aberto, bastante implementado, uma vasta gama de produtos e reconfigurável.
Principais características e vantagens
O protocolo KNX garante que os produtos das mais variadas marcas, quando construídos
segundo as definições do protocolo KNX, conseguem comunicar entre si se estiverem ligados na
mesma rede. Esta característica permite uma enorme flexibilidade para modificação e expansão de
um sistema já existente. A associação KNX exige dos seus representantes e fabricantes um nível
bastante exigente nos desenvolvimentos dos produtos KNX, pois todos os produtos desenvolvidos
pelos membros KNX vão representar a marca KNX. Os produtos KNX têm de cumprir a norma ISO
9001. Os membros da KNX fabricam produtos para todo o tipo de aplicações para o controlo de
edifícios, desde o controlo de iluminação até aos sistemas mais complexos de gestão inteligente de
energia. O protocolo KNX foi desenvolvido para integrar todos os tipos de edifícios: do edifício
antigo ao edifício totalmente construído de raiz sem quaisquer dificuldades de implementação.
Permite também a instalação em edifícios de um piso a edifícios de vários pisos, como hotéis,
shoppings e arranha-céus. Este tipo de implementações é possível devido à grande variedade de
meios físicos de comunicação como par entrançado, a rede elétrica (powerline), infravermelhos,
rádio frequências e IP/Ethernet. Todas estas formas de comunicar permitem ao sistema a facilidade
de se efetuar mudanças, atualizações e expansões sem que se tenha a necessidade de desenhar
novamente o sistema, reconstruir a instalação ou mudanças mais profundas que não as pretendidas.
A associação KNX tem um Software desenvolvido pelos seus membros o ETS (Engineering Tool
Software), que permite a configuração de todos os dispositivos certificados pela KNX
Erro! A origem da referência não foi encontrada. 11
independentemente da sua marca ou fabricante. Este Software possibilita a integração de vários
tipos de produtos numa instalação e possibilita a atualização da base de dados dos diferentes
produtos, descarregando os dados do fabricante do produto com a total garantia de compatibilidade
com o ETS, caso fabricado por um membro KNX. No KNX existem três tipos de configuração: o S-
Mode, o A-Mode e o E-Mode. O A-Mode é o mais simples neste modo de configuração, pois o sistema
configura-se automaticamente. Embora pareça uma vantagem para o sistema, este fica limitado às
configurações automáticas. O E-Mode é efetuado por um controlador de um dispositivo ligado ao
barramento de dados. E o S-Mode é o método de configuração mais poderoso. É realizado através
de um computador com o Software ETS instalado, ligado ao barramento através de um dispositivo
de interface. O modo S destina-se a projetistas e instaladores com certificação KNX e a instalações
de grandes dimensões. As vantagens desta norma face a outras são ter nascido de três normas já
existentes e com bastante experiência no mercado e se basear nas qualidades e vantagens de cada
norma.
Desvantagens
A norma KNX não apresenta grandes desvantagens e podem-se destacar como pontos menos
favoráveis desta tecnologia o preço, uma vez que em relação a outras tecnologias não é muito
convidativo, a instalação e a configuração é mais complexa e o elevado preço do software ETS. As
desvantagens não são muitas mas os preços dos dispositivos e das instalações pesam bastante na
decisão do cliente.
3.2 Arquitectura e Elementos KNX
Modos de configuração
Cada habitação, edifício, condomínio e um outro qualquer sistema KNX tem necessidades e
funcionalidades diferentes. Os sistemas EIB/KNX possuem vários modos de configuração para
satisfazer as diferentes necessidades de configuração dos diferentes dispositivos e utilizadores. Os
diferentes modos de configuração permitem que os fabricantes tenham mais liberdade para inovar e
ao mesmo tempo garantem a inter-funcionalidade entre os diferentes dispositivos. As várias
configurações possíveis de serem executadas poderão e/ou deveram ser alteradas conforme as
necessidades do utilizador, com o auxilio de Software nomeadamente o ETS da KNX. Existem já no
mercado outros Software de configuração de sistemas KNX de outras marcas. A título de exemplo, o
Tebis da Hager. Estas ferramentas acedem às características e configurações possíveis de cada
dispositivo e configuram-no conforme a sua utilidade e funcionalidades pretendidas, garantindo a
inter-funcionalidade no sistema. Os modos de configuração são 3:
O S-mode (System mode);
O A-mode (Automatic mode);
O E-mode (Easy mode) que se divide em duas sub-configuraçoes:
O Controller Mode;
O Push-Button Mode.
De seguida serão explicados de forma sucinta os diferentes modos de configuração dos
dispositivos KNX.
S-mode (System mode), esta forma de configuração do sistema é a mais utilizada e a mais
versátil. Esta está vocacionada para a instalação feita por profissionais, pois necessita da utilização
de Software especializado concebido para esse efeito, como o é caso (ETS). Este modo segue a
mesma filosofia que no EIB e permite que os dispositivos da nova instalação possam ser configurados
12 Introdução
12
conforme a vontade dos clientes e segundo as funcionalidades do dispositivo. Esta configuração terá
de ser efetuada por um computador ligado à rede KNX, tipicamente com o ETS. Para uma
configuração mais completa e abrangente, o ETS usa a informação detalhada de cada dispositivo.
Caso não disponha dessa informação, o configurador poderá importá-la do fabricante. Este Software
permite também atribuir o endereço individual ou de grupo de cada dispositivo (Binding); permite a
parametrização individual de cada dispositivo, de acordo com o datasheet do fabricante
(Parameterisation) e importar e carregar programas dos fabricantes para configurar as mais
diversas funcionalidades de cada dispositivo. Estas configurações são efectuadas através do BCU,
pois é este que faz o controlo de ligação com o módulo de aplicação do dispositivo, cabendo ao
configurador a responsabilidade e decidir a configuração.
E-mode (Easy mode) nesta configuração, os dispositivos como já vêm da fábrica programados
para realizar uma determinada função, não necessitam de um computador com o ETS para a
configuração da rede. Contudo oferece funções mais limitadas. Alguns detalhes podem e devem ser
configurados pelo instalador de acordo com a instalação pretendida. Essas alterações poderão ser
efetuadas através do uso de um controlador ou através de micro interruptores. Neste modo, as
propriedades dos dispositivos ligados na rede podem ser lidas através do barramento, sem haver a
necessidade da base de dados do fabricante com as propriedades do produto. Este modo de
configuração está dividido em outros dois modos, o easy controller mode e o easy push-button
mode.
Easy Controller Mode: neste modo, uma instalação precisa de definir um dispositivo como
controlador, que suportará o processo de configuração. Esta configuração suporta um número de
dispositivos limitado em cada segmento. Um controlador pode suportar uma ou mais configurações.
Contudo está limitado, pois não possui os detalhes das bases de dados dos fabricantes como no ETS,
visto não possuir memória para os guardar. Após a configuração, o controlador deverá continuar
ligado à rede salvo algumas exceções. O controlador pode ser dinamicamente configurado, pode
criar grupos de objetos para determinadas funções, definir endereços físicos e de grupo e
parâmetros de funcionamento. Ao controlador cabe ler as diferentes funcionalidades de cada
dispositivo e mediante as instruções do instalador configurar os diferentes endereços individuais de
cada dispositivo, as ligações a definir entre os mesmos e parâmetros de funcionamento.
Easy Push-button Mode: ao contrário do modo controller não é necessário o uso de
controlador, embora não permita um elevado número de dispositivos num segmento de rede. Cada
dispositivo pertencente à rede deverá possuir a possibilidade de autoconfigurar a sua aplicação,
definir o seu endereço físico e de grupo e definir os parâmetros necessários ao seu funcionamento.
A troca de parâmetros com outros dispositivos também é possível, no entanto a configuração é
essencialmente local. Aquando da configuração, o instalador designa sucessivamente os
dispositivos, cujas funções vão ser interligadas de acordo com as especificações de cada fabricante.
A troca de dados de configuração entre os dispositivos, tipicamente sensores e atuadores, ocorrem
através de um serviço da camada de aplicação. Aos dispositivos emissores, cabem apenas definir o
seu endereço de grupo único e informar depois os dispositivos a controlar o seu endereço.
A-mode (Automatic mode): este modo de configuração é o mais simples, pois é automático.
Contudo é também o mais limitado. Este modo pode ser configurado por um utilizador sem
conhecimentos sobre EIB/KNX e segue uma metodologia Plug&Play, pois os dispositivos possuem a
capacidade de localizar outros dispositivos, definir interoperações e adquirir os seus próprios
endereços físicos. Neste modo de configuração, os dispositivos são direcionados geralmente para
uma única aplicação que contém o seu próprio controlador de aplicação, sendo este também o
configurador Master para a aplicação. A este cabe a configuração dos endereços de grupo. Este
modo será especialmente indicado para ser usado em eletrodomésticos e equipamentos de
entretenimento (consolas, boxes, áudio e vídeo, etc.). A facilidade deste modo reside no facto de
Erro! A origem da referência não foi encontrada. 13
que nem o instalador nem o utilizador final têm de configurar qualquer dispositivo introduzido. A
figura 2 mostra-nos os três modos de configuração fundamentais do KNX.
Figura 3: Modos de configuração do KNX.
Tipos de implementação
Os sistemas de domótica têm dois tipos de implementação fundamentais: o Power Line Carrier
e Barramento/cablagem dedicada. A implementação Power Line Carrier (PLC) é a solução de mais
baixo custo, pois faz uso da rede elétrica do edifício para a transmissão de dados entre os
dispositivos que compõem o sistema. A implementação barramento/cablagem dedicada é uma
solução mais dispendiosa, devido à necessidade de instalação de cablagem extra durante a
construção. Atualmente, devido à regulação do sector das telecomunicações, a ANACOM define que
a instalação de infraestruturas de telecomunicações em edifícios, incluindo a respetiva ligação às
redes públicas (ITED) como obrigatória. Assim sendo, e como essa cablagem inclui cabos para o uso
de sistemas de domótica, este tipo de implementação fica um pouco mais acessível. Além da
comunicação por cabo a comunicação entre dispositivos do sistema, pode ainda ser feita por Rádio
Frequências, Infravermelhos, Bluetooth, Zigbee e fibra ótica.
Dispositivos
Os dispositivos KNX têm uma arquitetura que se divide em três grandes tipos: os componentes
básicos, os componentes de sistema e os orientados para aplicações. Os componentes básicos são
componentes que não entrevem no funcionamento do sistema e não têm parte ativa no sistema.
Exemplos de componentes básicos são: fontes de alimentação, filtros de sinal, etc. Os componentes
de sistema permitem a criação de uma rede são eles acopladores de BUS (BCU – Bus Coupling Unit),
Acopladores de Linha (LC – Line Coupler), Acopladores de Fase, repetidores, etc. Os componentes
orientados para as aplicações são componentes que entrevem diretamente no funcionamento do
sistema, são eles sensores, atuadores, Recetores de IR, painéis de comando essencialmente
atuadores, sensores e controladores. Estes dispositivos são ligados à rede através de um Acoplador
de Bus ou de uma interface similar. Os dispositivos são constituídos por:
Uma unidade de acoplamento ao barramento (BCU);
Um módulo de aplicação (AM);
14 Introdução
14
Um programa de aplicação (AP).
A unidade de acoplamento e o módulo de aplicação podem ser vendidos em conjunto
integrados num só ou ser vendidos em separado. Quando vendidos em separado devem ser
interligados por uma interface física externa (PEI - Physical External Interface). Existem no
mercado interfaces físicas externas de 10 e de 12 pinos, estas interfaces são utilizadas para troca
de mensagens entre os dispositivos e como fonte de alimentação para o módulo de aplicação. A
figura 4 descreve a constituição de um dispositivo:
Figura 4: Estrutura de um dispositivo KNX.
Acopladores
Os acopladores são componentes de sistemas KNX que têm como objetivo ligar diferentes
áreas, linhas e funcionar como repetidores. Os acopladores de bus podem funcionar como
dispositivos independentes ou estarem integrados em outros dispositivos orientados à aplicação
quando funcionam como independentes, os módulos de aplicação usam-nos para se ligarem a rede.
O módulo e o acoplador devem ser do mesmo fabricante para tornar mais fiável o seu
funcionamento. È nos interruptores tácteis onde normalmente se encontra separado o BCU do
módulo da aplicação (AM), o BCU é normalmente embutido nas paredes. Há também dispositivos
orientados à aplicação que tem acopladores. Quando o BCU faz parte do dispositivo, vem
normalmente integrado no dispositivo através de módulo de Interface como Barramento (BIM - Bus
Interface Module) ou através de um Chip set do próprio fabricante, substituindo PEI. Os tipos
acopladores são:
O Acoplador de Área (AA) que é um dispositivo que interliga a linha de área à Linha
Principal;
O Acoplador de Linha (AL) que é um dispositivo que interliga a linha principal a uma linha
secundária;
O Repetidor de Linha (RP) é um dispositivo que permite expandir um segmento de linha
possibilitando inserir mais 64 dispositivos ou poder expandir o cabo de transmissão de dados em
mais 1.000 m.
Erro! A origem da referência não foi encontrada. 15
Quando um acoplador de área ou de linha é utilizado, estamos a construir uma tabela de
filtragem, pois os telegramas só são encaminhados pelo acoplador para os dispositivos, se estiverem
registados na tabela de filtragem. O repetidor tem como função a repetição de um sinal nas redes
par entrançado regenerando os sinais elétricos, permitindo aumentar o comprimento das linhas e
unir segmentos de redes extensas quando necessário. A título de exemplo em grandes edifícios.
BCU (Bus Coupling Units)
Os BCU são disponibilizados para dois tipos de meios são eles o par entrançado (Twisted Pair) e
Linha de Potência (Power Line), ainda não existem para rádio frequências. Só existem soluções RF
integradas, ou seja, cada dispositivo tem a sua própria inteligência devido ao BCU, daí o KNX ser um
sistema descentralizado não necessitando de uma unidade central de processamento. As funções
centrais como a supervisão podem contudo ser implementadas, através de painéis tácteis ou
Software de Supervisão instalados em PC, através de página Web e aplicações Android. Os
dispositivos KNX podem ser divididos em três classes: sensores, atuadores e controladores. Os
sensores são dispositivos que fazem medições, leituras e enviam os dados para o BCU. O BCU
verifica o estado do módulo de aplicação, procurando constantemente no PEI variações de sinal, se
for detetada alguma alteração envia um telegrama para o barramento KNX. O telegrama é a
codificação da informação a ser transmitida, segundo o protocolo KNX. Os atuadores são dispositivos
que recebem telegramas e agem segundo o que lhes foi ordenado. Ao receber o telegrama o BCU
descodifica e envia essa informação ao módulo de aplicação (AM) que agirá mediante a informação
descodificada. Os controladores são dispositivos que ditam o funcionamento dos sensores e
atuadores. Estes recebem as suas funções quando o programa de aplicação adequado for carregado
para o BCU através do ETS. O BCU é constituído por duas partes: um controlador (BCC) e um
transceiver (TRC) adequado ao meio de transmissão que é possível visionar na figura 5.
Figura 5: Arquitetura de um BCU.
O módulo controlador (BCC) possui um microprocessador que faz a comunicação entre a
interface externa (PEI) e um sistema operativo que pode executar um programa de controlo do
dispositivo para a gestão do mesmo. Os diferentes tipos de memória internos do microprocessador
guardam os dados do Software do sistema na memória ROM, valores temporários do sistema e da
aplicação na RAM e o programa de aplicação e endereços na memória flash e ou EEPROM. O BCC
organiza e controla o acesso ao barramento, faz a gestão, codificação e descodificação dos
telegramas, a deteção de problemas na transmissão de dados, o controlo de repetição de
transmissões, fornece sinais de controlo e controla as funções das aplicações. O módulo transceiver
(TRC) tem a função de separar os dados, da alimentação, monitorização da temperatura, regular a
tensão a 5V e 24V, proteção contra polaridade invertida, proteger os dados se tensão baixar dos
18V, desligar o micro se a tensão for inferior a 4,5V.
16 Introdução
16
Figura 6: Arquitectura de um TRC..
PEI (Physical External Interface)
O PEI tem como objetivo a comunicação entre o meio físico BCU e a camada de aplicação e possui
especificações elétricas/mecânicas e de Software que permitem efetuar o acesso ao bus de dados.
O acesso ao meio e transmissão de dados pode ser feito por transmissão série ou paralelo, o
conector de ligação (elétrica/mecânica) deste ao BCU possui duas versões: de 10 pinos e de 12
pinos. Através de uma interface paralela PEI I/O, os valores de input e output podem ser acedidos
pela aplicação interna do BAU (Bus Access Unit). Por seu lado, na comunicação série PEI entre o
BAU e a aplicação, o módulo aplicação é o responsável pela leitura e escrita dos valores de entrada
e saida. Exemplos de comunicação deste tipo: a comunicação de um PC (com software ETS) no
processo de configuração de um dispositivo ou da rede através da rede e um dispositivo que tenha
dados que possam ser lidos e escritos por um outro dispositivo. O diagrama de pinos do PEI (figura
7) permite verificar o que até então foi explicado e perceber o que são os diferentes termos.
Figura 7: Diagrama de pinos do PEI.
Erro! A origem da referência não foi encontrada. 17
As diferentes ligações foram criadas devido à possibilidade de variação das resistências entre
os pinos 5 (Vcc) e 6 (type), com isso possibilitando a criação de 21 tipos, os quais são agrupados em
quatro grandes grupos:
Utilizações especiais;
Reservados para futuras extensões;
Comunicações em Paralelo;
Comunicações em Série.
As configurações do tipo utilizações especiais são:
PEI tipo 0 – é conseguida sem resistência entre os pinos 5 e 6, esta foi concebida para se
utilizar em aplicações onde não existe nenhum adaptador;
PEI tipo 1 – este tipo de configuração é utilizado quando não existe qualquer tipo definido
ou enquanto o tipo de PEI atribuído ainda não foi inicializado;
PEI tipo 20 – este tipo de PEI è destinado ao fabricante para fazer o download de
configurações para a unidade que contém o interface físico (BCU, BIM- Bus Interface Modules,…).
Os PEI reservados para futuras extensões são os tipos guardados para futuras necessidades ou
desenvolvimentos do protocolo KNX, são eles: 3, 5, 7, 9, 11, 13, 15, 18.
Os PEI para comunicações em Paralelo são: 2, 4, 6, 8, 17 e 19.
Os PEI para comunicações em Série são: 10, 12, 14 e 16 cada um suporta diferentes versões do
protocolo de comunicação (síncrona e a assíncrona). A comunicação assíncrona é garantida pelo
tipo 10 e 16. A comunicação síncrona é garantida pelo tipo 12 e 14. O tipo 12 implementa
comunicação síncrona com interface de mensagens, como foi dito anteriormente o tipo 14 suporta
também comunicação síncrona mas este com interface de blocos. O PEI tipo 10 implementa
comunicação assíncrona assim como o PEI do tipo 16. Contudo, este possui o seu protocolo para
interagir com o módulo de aplicação e o BCU. Nos sistemas EIB/KNX não têm de existir por
definição um PEI (Physical External Interface), garantindo assim outras formas e possibilidades de
comunicação entre o módulo de aplicação e o BCU, como por exemplo na utilização de memória
RAM partilhada ou qualquer outro protocolo que não tenha por base a interface PEI. E como já
referido existem dispositivos que têm o BCU e o módulo de aplicação em um dispositivo.
3.3 Rede KNX e Endereçamento
Topologia da Rede KNX
O KNX é definido como uma rede totalmente distribuída, pois não necessita de um controlador
central na instalação visto todos os dispositivos possuírem o seu próprio microprocessador e a
implementação do protocolo de comunicação KNX de acesso ao meio. Quando ligados a um
barramento de comunicação de dados funcionam como recetores e emissores, dispensando assim
um controlador central. Como já referido anteriormente, o KNX suporta diferentes meios físicos de
comunicação: o par entrançado, a rede elétrica (powerline), os infravermelhos e rádio frequências.
O KNX não possui uma topologia física definida para sua implementação. Num sistema KNX pode
existir uma mistura das topologias físicas ou só uma das topologias. As topologias físicas base: em
estrela, em anel, linear e em árvore. Existe ainda a possibilidade de as combinar numa topologia
mista. Estas topologias são constituídas por vários dispositivos e secções definidas pelos diferentes
cabos individuais que podem ser tão longos quanto o permitido pelos requisitos elétricos.
18 Introdução
18
A figura 8 é uma representação das diferentes topologias físicas base, muitas mais podem ser
conseguidas através destas topologias físicas base.
Figura 8: Tipos de redes KNX.
Em cada segmento (ramo) o KNX define um máximo de 64 dispositivos, dois quaisquer
segmentos podem ser ligados por um repetidor ficando com a designação de linhas. Uma linha pode
conter um máximo de quatro segmentos interligados por repetidores, ficando assim com uma
capacidade de até 255 dispositivos. À linha de bus principal é permitido conectar um maximo 15
linhas secundárias utilizando os acopladores de linha. O uso de mais que um segmento só será
aceitável para o aumento de capacidade de instalação do sistema. Quando o edifício a instalar está
separado por pisos e ou dá mais jeito dividir em subsistemas o sistema será dividido por áreas. Uma
área pode possuir até um máximo de 15 linhas e um sistema poderá ter até 15 áreas o que dá um
máximo de 225 linhas por sistema. As diferentes áreas têm de ser ligadas à linha principal através
de um acoplador de área (AA). Cada linha deve ter a sua própria fonte de alimentação, possuir até
6 controladores de linha (i.e. acopladores de linha, acopladores de área e repetidores) em cada
caminho de transmissão. Os repetidores de linhas não podem ser utilizados em linhas de área e
linhas principais. É possível utilizar dispositivos nas linhas de área e principal. Contudo, o número
de dispositivos que podemos utilizar decresce com os acopladores de área usados. Se não se
recorrer a repetidores podemos conseguir a instalação de até 15.153 dispositivos, se forem
utilizados repetidores podemos atingir os 61 233 dispositivos. A figura 9 mostra uma topologia
possível de um sistema KNX e a representação de alguns termos mencionados anteriormente:
Erro! A origem da referência não foi encontrada. 19
Figura 9: Topologia genérica de um sistema KNX.
Endereçamento
Endereçamento Individual
O endereço individual define o endereço de comunicação para um dispositivo e como o próprio
nome indica é único. Todos os dispositivos num sistema KNX possuem um endereço individual, pois é
para este que lhe vão ser enviadas mensagens. Este funciona para o dispositivo como a impressão
digital para um ser humano. Os endereços são baseados na área e linha onde se inserem e no seu
endereço do dispositivo nessa mesma linha. Um endereço individual definido por:
Área:
Numa área o endereço irá de 1 a 15;
O endereço 0 é reservado para o dispositivo na linha de área;
Linha:
Numa linha o endereço irá de 1 a 15 numa determinada área;
O endereço 0 é reservado para os dispositivos na linha principal;
Dispositivo:
Numa linha o dispositivo poderá ter um endereço de 1 a 255;
O endereço 0 é reservado para o acoplador de linha.
Os dispositivos quando saem de fábrica vêm com o endereço 15.15.255. Este endereço terá de
ser modificado pelo ETS ou será modificado quando programado automaticamente no A-Mode. A
figura 10 ilustra a organização dos endereços individuais.
20 Introdução
20
Figura 10: Endereços individuais do protocolo KNX.
Endereçamento de Grupo
O endereçamento de grupo é feito para um determinado conjunto de dispositivos (grupo). Cada
endereço pode ser atribuído a qualquer dispositivo numa qualquer linha. Ao atribuir um endereço
de grupo a vários dispositivos, eles podem ser endereçados ao mesmo tempo através de um único
telegrama. Um dispositivo de grupo atuador pode responder a vários endereços de grupo. Já um
sensor só envia a um endereço de grupo. A figura 11 ilustra uma atribuição de endereços de grupo e
como é constituído:
Figura 11: Endereços de grupo no protocolo KNX.
Telegrama KNX
O telegrama KNX é uma mensagem que pode ser enviada entre dispositivos na rede KNX. Nesta
rede, as mensagens enviadas terão de possuir as características definidas pelo protocolo. Antes de
enviar uma mensagem, o dispositivo emissor deve escutar a rede verificando se está desocupada. Se
estiver desocupada, poderá enviar a mensagem; se estiver ocupada, espera e vai escutando a rede
até ficar desocupada. Quando desocupada, espera que o tempo t1 (t1 =50bits) seja ultrapassado. De
seguida envia o telegrama. O telegrama possui um campo que define a prioridade. Se ao enviar um
telegrama, um dispositivo de maior prioridade transmitir um outro, o de menor deixará de
Erro! A origem da referência não foi encontrada. 21
transmitir. A deteção é feita porque o dispositivo enquanto transmite continua a ouvir a rede para
conseguir detetar colisões com outras transmissões. Quando o dispositivo de mais alta prioridade
parar de transmitir o dispositivo de menor prioridade volta a transmitir o telegrama. Este método
de funcionamento é definido no protocolo CSMA/CA (Carrier Sense Multiple Access with Collision
Avoidance). Após o envio da mensagem, o dispositivo espera um tempo t2 (t2=13bits) para receber
a confirmação de que a mensagem foi recebida com sucesso, senão repete-a um determinado
número de vezes. O telegrama de grupo é enviado ao mesmo tempo para todos os dispositivos a que
se destinam. Os telegramas são enviados de forma assíncrona. Contudo são enviados bits de início
antes do primeiro carácter e no fim um bit de finalização do telegrama para sincronizar os
participantes. Cada carácter enviado é um byte (bits) de informação. O telegrama é enviado a uma
taxa de transmissão de 9600 bits/s, demorando aproximadamente 104μs por bit. O período entre
um carácter e outro é de 13 bits, ou seja, 1,35ms. Cada telegrama pode possuir entre 8 e 23
caracteres de tamanho. O conhecimento da receção de um telegrama é efetuado por apenas um
carácter de reconhecimento. Com todos estes requisitos, um telegrama ocupa a linha por um tempo
de 20 a 40 ms. Os telegramas mais comuns ocupam o bus aproximadamente 20 ms. A figura 13
demonstra visualmente o que foi até então explicado:
Figura 12: Características de um telegrama KNX.
Um telegrama é informação específica de uma rede e para essa rede e fornece os dados e
ordens para o bom funcionamento da mesma. Um telegrama possui um campo que define a
prioridade de uma mensagem que é o campo do controlo; possui o endereço de origem e destino;
um campo contador e de comprimento; um campo de dados e um campo de verificação. O campo
de controlo é um campo de oito bits que define a prioridade dos telegramas entre os vários
dispositivos. Permite a escolha da repetição de um telegrama se não for confirmado pelo dispositivo
que o recebe. Os oito bits começam com D7 e acaba em D0 como podemos verificar pela figura 14:
22 Introdução
22
Figura 13: Características do campo de controlo de um telegrama KNX..
Os bits que sofrem alteração e que podem alterar o funcionamento do sistema são os bits D3 e
D2 e D5. Podemos verificar na figura 14 que para os diferentes tipos de funcionamento existem
diferentes tipos de prioridade. Quando os bits D3D2 estão 0 prioridade é máxima e mínima quando
estão a 1 (prioridade de serviço baixa). A prioridade da transmissão é apenas levada em conta
existirem 2 ou mais dispositivos a transmitirem em simultâneo. Quando o telegrama é enviado e o
emissor não recebe a confirmação, o bit D5 será alterado para 0 e o telegrama será novamente
enviado, garantindo assim que caso o destinatário tenha executado o comando não o volte a
executar. Saberá que é uma repetição de um comando, porque o bit D5 estará a zero. Neste caso é
assegurado que o participante que já tenha executado o respetivo comando não o repita
novamente. Os restantes bits podem ser alterados pelo Software ETS, segundo as necessidades do
utilizador e do sistema.
O campo dos endereços incluiu o endereço de origem e o de destino; o de origem possui 16
bits, o de destino tem mais um bit para definir o tipo de endereçamento. O endereço de origem
pertence ao dispositivo que envia o comando, isto para que o dispositivo de destino saiba quem lhe
envia o comando. O endereço de destino garante que o comando é recebido pelo(s) dispositivo(s) a
que é destinado. Este é normalmente um endereço de grupo, com um número elevado de
participantes que podem ser endereçados simultaneamente. O endereço pode também ser
individual, este é normalmente utilizado no modo de inicialização do sistema, programação e
diagnóstico.
A informação do endereço de destino é transmitida com 17 bits para que o recetor, consiga
partir do bit D7 saber de que tipo de endereço de destino (grupo, individual). Como poderemos
verificar na figura 15. As imagens ilustram os bits que constituem os diferentes endereços e os tipos
de endereçamento.
Figura 14: Endereço individual.
Os quatro bits mais à esquerda definem a área. Os quatro bits seguintes definem uma linha e os
últimos 8bits à direita definem o dispositivo do qual o comando é enviado.
Erro! A origem da referência não foi encontrada. 23
Figura 15: Endereços de grupo de dois e três níveis.
Figura 16: Características do campo de controlo de um telegrama KNX.
Na figura 16 podemos ver que os 4 bits de A3 a A0 definem a área de destino, os 4 bits
seguintes de L3 a L0 a linha, os oito bits de P7 a P0 o endereço do dispositivo de destino e o último
bit o tipo de endereço. No endereçamento de grupo os quatro bits de P3 a P0 indicam o endereço
do grupo principal, os três bits de I2 a I0 o endereço do grupo intermédio, os 8 bits seguintes o
subgrupo e o bit mais a direita a 1 para indicar que é um endereço de grupo de três níveis.
O campo contador e comprimento contêm um campo inicializado com o valor 6, que é o
número de vezes que pode passar por um Router. A cada passagem por um acoplador de linha é
decrementado e retransmite, enquanto o valor for positivo. As tabelas de filtragem são também
tidas sempre em linha de conta. Este campo cede um bit ao endereço de destino; o bit D7 mais a
esquerda que define o tipo de endereço (individual ou de grupo). Os 3 bits seguintes de R2 a R0
representam o contador e os 4 bits mais a direita de L3 a L0 definem o comprimento do campo dos
dados. A figura 17 confirma e representa o que foi dito sobre o campo contador.
Figura 17: Campo contador.
O campo dos dados é constituído normalmente por 2 bytes (16 bits), este na generalidade
apenas utiliza um bit para activação (1) ou desactivação (0) de dispositivos. A informação no campo
dos dados pode ter um comprimento de 1 bit até 13 Bytes (Byte 2 a 15), esta depende do tipo de EIS
(EIB Interworking Standard).
24 Introdução
24
Quando é feito um pedido para "ler" é solicitado ao dispositivo que recebe o telegrama um
aviso do seu estado que pode ser uma confirmação curta ou longa.
Figura 18: Campo de dados.
A ordem (as funções a executar) é definida pelos 4 bits BBBB acima representados: a escrita
(0010), a leitura (0000), a confirmação curta (0001) e a confirmação longa (0001). Os restantes
bytes são parâmetros que podem ser a confirmação, dados ou não serão utilizados dependendo do
tipo de dados a enviar.
O campo de verificação permite verificar se o telegrama chega ao seu destino corretamente. A
verificação do carácter faz a soma dos bits de dados (D7 a D0) e de Pz. Essa soma tem de dar 0,
caso contrário a mensagem está corrompida (confirmação por paridade par). A Verificação de
Telegrama analisa a posição dos bits de todos os caracteres por prioridade, isto é, o bit de
verificação S7 recebe o valor “0” ou “1” para fazer a soma de todos os bits de dados D7 mais os bits
de verificação S7 iguais a 1. A combinação da verificação dos caracteres e do telegrama é chamada
Verificação Cruzada. A figura 19 representa o que foi explicado.
Figura 19: Campo de verificação cruzada.
Quando um receptor recebe um telegrama e foi efectuada a correcta recepção do mesmo,
deve enviar um aviso como confirmação correspondente uma mensagem de reconhecimento. Se o
dispositivo de origem receber um reconhecimento NAK (recepção incorrecta), o dispositivo de
origem envia um novo telegrama que poderá ser repetido até três vezes. Caso receba um
reconhecimento BUSY (linha de bus ocupada), o emissor aguarda um intervalo antes de repetir o
telegrama. Se o emissor não receber a mensagem de reconhecimento, irá terminar a transmissão.
No caso de a mensagem estar correcta o receptor envia um reconhecimento ACK. A figura 20 mostra
a estrutura da mensagem de reconhecimento.
Figura 20: Estrutura de uma mensagem de confirmação.
Erro! A origem da referência não foi encontrada. 25
Esta é a constituição de um telegrama utilizado para comunicar e gerir um sistema de
domótica através do protocolo KNX.
3.4 Gateway IP / Bus KNX
As Gateways têm como função a interligação de um sistema de domótica a outros sistemas e
meios em qualquer nível. Com o crescer do número de edifícios, com aplicações de domótica e a
evolução das tecnologias de comunicação, começa a fazer cada vez mais sentido a utilização deste
tipo de solução, devido às dimensões dos projetos e as tecnologias e funções a implementar no
sistema. Um dos principais motivos para a interligação de sistemas através de Gateways é o
crescente aumento de dispositivos e o volume de telegramas que implica a interação entre os
mesmos. O congestionamento da rede pode acontecer devido ao sistema possuir dispositivos que
enviem constantemente o seu estado ou informações. Numa topologia par entrançado poderá
sobrecarregar facilmente a linha, devido à sua baixa velocidade de transmissão: aproximadamente
9.6 kbit/s. Esta situação poderá ser ultrapassada usando uma rede IP, utilizando acopladores IP nas
linhas principais e de área. A rede Ethernet é pelo menos 1000 vezes mais rápida que a de par
entrançado. As Gateways podem funcionar como acopladores IP/KNX e também para configuração
ou programação remotamente através da rede IP. A interligação em paralelo de várias linhas não
serão mais problema com as Gateways. Esta comunicação tem o nome Tunnelling consiste em criar
um túnel IP, entre um cliente KNXnet/IP e um servidor KNXnet/IP por onde são trocadas tramas
KNX. Em linhas individuais KNX, a comunicação terá de ser assegurada por uma Gateway Router
IP/KNX. A este tipo de comunicação dá-se o nome de Routing esta é utilizado para efetuar o
encaminhamento de tramas pela rede KNX. O princípio de funcionamento de um Router IP/KNX é
muito parecido com o das linhas principais de par entrançado: se precisar de enviar um telegrama
entre linhas, fá-lo através de um endereçamento Multicast sobre a rede Ethernet. Os Router IP/KNX
endereçados com este tipo de endereçamento são capazes de receber e avaliar o telegrama. O
Router ao filtrar os telegramas faz o seu roteamento, ou seja, faz o mesmo que o acoplador de
linha faz quando usa as tabelas de filtragem, resultando assim no encaminhamento ou bloqueio dos
telegramas. Assim como acoplador de linha de par entrançado, o Router pode ser utilizado como
acoplador de linha e de área. Topologias físicas possíveis com Routers IP/KNX:
Caso 1, a linha de área passa a ser uma rede LAN;
Caso 2, todas as linhas principais e também a linha de área são substituídas por uma rede
Ethernet;
Caso 3, é uma mistura do caso 1 e 2. A linha de área em par entrançado, um Router IP/KNX
no topo e por cada linha um Routers IP/KNX em vez de acopladores de linha.
A alta taxa transmissão de bits da rede Ethernet facilita muito o tráfego de telegramas e
minimiza as suas perdas. Contudo, deverá ser feita uma gestão de tráfego, evitar o envio de
telegramas a alta frequência e o envio simultâneo das várias linhas para uma única linha. As
imagens na figura 21 representam alguns dos diferentes tipos de montagem utilizando Routers
IP/KNX:
26 Introdução
26
Figura 21: Montagens com routers IP/KNX.
Troca de Dados e Interfuncionamento
A troca de dados entre os vários dispositivos e o interfuncionamento permite-lhes que
comuniquem entre si, executem comandos e partilhem informação necessária ao funcionamento do
sistema. A título de exemplo, a comunicação entre um sensor (comando de um ar condicionado) e
um atuador (um ar condicionado), é constituída por uma sequência de operações que poderemos
ver na ilustração da figura 22. O exemplo é de um interruptor e uma lâmpada que em tudo se
assemelha ao exemplo dado anteriormente:
Erro! A origem da referência não foi encontrada. 27
Figura 22: Exemplo de comunicação entre um interruptor e uma lâmpada.
Os dispositivos físicos da figura 22 representados possuem um endereço único, a comunicação é
feita por endereçamento individual quando só uma lâmpada ou por endereçamento de grupo
quando se trata de várias. Através do protocolo KNX, um dispositivo poderá comunicar com vários
outros dispositivos que pertençam a um grupo através de um endereçamento de grupo e de um
simples comando. Não existe a necessidade de se enviar um comando para cada dispositivo. A
transmissão de informação baseia-se na troca de dados codificados, que apenas podem fazer o
endereçamento da mensagem para um único grupo por mensagem ou para um único dispositivo. Já
o recetor poderá subscrever vários endereços de grupo, que permitirá que seja controlado por
vários emissores. Uma mensagem enviada para um determinado grupo será recebida e interpretada
pelos vários recetores que o constituem e que subscrevem esse endereço de grupo. O
interfuncionamento está dividido em vários patamares de uma pirâmide que determina os vários
graus de interfuncionamento. Um comando é inicialmente um telegrama a transmitir e depois acaba
como ações executadas por um ou vários atuadores. Este processo é muito semelhante à troca de
correio, representado na figura 22, em que os objetos representam a caixa de correio e a Acão a
tomar a mensagem que está escrita na carta. A figura 23 ilustra e define os vários tipos de
interfuncionamentos e suas funcionalidades:
28 Introdução
28
Figura 23: Pirâmide de inter-funcionamento.
O patamar inicial (Formato Comum) é a base do inter-funcionamento. Garante a troca de
informação com o mesmo tipo de codificação em todas de mensagens trocadas entre os dispositivos.
O segundo patamar (mesma interpretação) garante que os dispositivos receptores iram interpretar a
mensagem da mesma forma e segundo a interpretação desejada e efectuada pelo emissor usando
uma semântica comum. O terceiro patamar (funções comuns) garante que os vários constituintes
partilhem as mesmas funções, garantindo assim que para um mesmo objectivo os diferentes
dispositivos irão utilizar as mesmas funções e regras para chegar às acções desejadas. O patamar de
topo (mesmas funcionalidades) é alcançado a partir da junção dos vários patamares da pirâmide de
inter-funcionamento, reunindo as funções comuns, garantindo a mesma interpretação e num
formato comum a todos os dispositivos. A título de exemplo, se um interruptor pretender desligar
uma lâmpada terá de enviar uma mensagem à lâmpada para a desligar. Esta terá de perceber o que
o interruptor escreveu e conhecer a função desligar. O topo da pirâmide garante que para um
qualquer dispositivo, a função desligar será interpretada da mesma forma. Para garantir o inter-
funcionamento entre os vários dispositivos foram definidas normas, o EIS (EIB Interworking
Standards), através das quais devem ser criadas e programadas as aplicações. Os diferentes tipos de
dispositivos e as diferentes marcas devem garantir entre si a comunicação e interpretação da
mesma forma e as mesmas funções. Com esse intuito, foram criados vários tipos de funções tipo
que estão definidos na norma EIS e se pode ver na figura 24. Estas funções standard são chamadas
EIB functions:
Erro! A origem da referência não foi encontrada. 29
Figura 24: Funções EIB.
O nome das EIB-functions está relacionado com a primeira aplicação para que foram
concebidas. Contudo podem ser usadas noutras aplicações. A título de exemplo, a função Dimming
foi inicialmente concebida para variar a intensidade da iluminação e é também hoje utilizada para
a regulação de aquecimento, assim como em vários outros tipos de utilização. Estas funções base
podem constituir outras funções ligeiramente diferentes ou completamente diferentes, permitindo
assim através destas conceber as mais variadas funções de um sistema de domótica. Serão
apresentadas e explicadas as diferentes funções disponibilizadas pelas normas EIS:
A função EIB EIS 1 (“Switching”) é usada para a comutação de cargas ligadas a um atuador
que permitirá: operações on/off, operações lógicas ativo/desativo, sinalização verdadeiro/falso,
alarme, etc. servindo na sua essência para ativar ou descativar um dispositivo;
A função EIB EIS 2 (“dimming”) consiste na união de três outras funções: a de control
(dimming relativo), a de value (demming absoluto) e a de position (comutação on/off e estado). A
função position permite ligar/desligar o dispositivo. A função control é usada para aumentar ou
diminuir o valor a atuar, permitindo também a comutação on/off do atuador. Por fim, a função
value permite a atribuição de um valor através de um byte igual à função EIS 6. A figura 25
exemplifica de forma clara e concisa o funcionamento da função dimming.
Figura 25: Função EIB2 (dimming).
30 Introdução
30
A função EIB EIS 3 (“Time”) fornece as horas em tempo real a qualquer dispositivo que
forneça e necessite deste tipo de informação, a informação será enviada no formato
horas/minutos/segundos;
A função EIB EIS 4 (“Date”) fornece a data a qualquer dispositivo que forneça e necessite
deste tipo de informação, a informação será enviada no formato dia/mês/ano;
A função EIB EIS 5 (“Value”) é usada para transmitir dados que representam valores físicos
numa variável de 2bytes. O valor é obtido através da formula [ (-1)S * (0.01M) *2E ] onde “S” é o
sinal, “E” é o expoente na base dois com 4 bits e “M” representa a mantissa em complemento para
dois de 11bits, o valor (value) poderá variar de -671.088.64 a +670 760.96;
A função EIB EIS 6 (“Scaling”) serve para enviar valores relativos de oito bits, normalmente
utilizado para valores percentuais.
A função EIB EIS 7 (“Control Drive”) é constituída por duas outras sub-funções: elas as
funções move e step. A função move serve para pôr por exemplo um motor de um estore a
funcionar ou mudar de sentido de rotação. A função step serve para fazer movimentos graduais ou
ordenar a paragem de um dispositivo.
As funções EIB EIS 8 (“Priority”) são constituídas por duas sub-funções: a função
EIS_priority_position e a função EIS_priority_control. A sub-função EIS_priority_position permite a
comutação para o estado on/off supervisionada pela função EIS_priority_control. Se a entrada
control estiver activa a função EIS_priority_control controla a saída, caso contrário a saída é
controlada pela função EIS_priority_position. Como podemos verificar na figura 26.
Figura 26: Função EIB2 (Priority).
A função EIB EIS 9 (“Float value”) é utilizada para enviar valores físicos no formato de
vírgula flutuante IEEE, usando 4 bytes.
A função EIB EIS 10 (“16-bit Counter Value”) é usada para representar um contador de 16
bits.
A função EIB EIS 11 (“32-bit Counter Value”) é usada para representar um contador de 32
bits.
A função EIB EIS 12 (“Acess”) faz o controlo de permissões de acesso às várias aplicações
através de uma variável de 4 bytes.
Erro! A origem da referência não foi encontrada. 31
A função EIB EIS 13 (“EIB-ASCII-Char”) permite o envio de um único caracter.
A função EIB EIS 14 (“8-bit Counter Value”) é usada para representar um contador de 8 bits.
A função EIB EIS 15 (“Character String”) permite o envio de mensagens textuais com
tamanho máximo de 14 bytes.
As funções EIB são a as mesmas que as do protocolo KNX, pois este nasceu com base no
protocolo EIB e das mudanças e melhorias necessárias.
3.5 Instalação de Redes KNX
Quadro elétrico
O quadro elétrico permite alojar os dispositivos elétricos e eletrónicos que não precisam e ou
não devem estar acessíveis ao utilizador. O quadro elétrico poderá ser um qualquer normalizado
pela norma EN50022 35×7,5mm DIN. No quadro a parte de energia deve ser separada da instalação
KNX. Preferindo-se não separar, deverão ser utilizados cabos com a bainha até aos terminais e
garantir que os cabos de energia não contactem com o bus. Os quadros têm de possuir calha DIN
para colocação dos dispositivos. Quando existem dispositivos KNX e elétricos na mesma calha, terá
de se garantir que não existe uma descarga de energia para a calha e esta não pode ser ligada ao
potencial da terra. A régua de dados liga os participantes como fontes de alimentação filtros entre
outros ao bus. A régua autocolante deve ser colocada de acordo com a norma numa calha DIN de 35
mm. O tamanho destas réguas depende dos tamanhos normalizados para cada quadro elétrico e não
devem ser alteradas. Para evitar contactos indesejados, a parte das calhas que não são utilizadas,
deverão ser tapadas com uma cobertura como podemos ver na figura 27, onde podemos ver também
os vários tipos de calha DIN.
Figura 27: Diferentes tipos de calha e cobertura para calha DIN.
Este tipo de montagem tem o nome de Rail-mounted. Esta permite arrumar e organizar os
dispositivos na calha DIN de uma forma muito simples. A figura 28 ilustra um exemplo para melhor
compreensão:
32 Introdução
32
Figura 28: Montagem Rail-mounted.
Na montagem embebida (Flush mounted), a instalação de dispositivos é feita dentro das
paredes, sempre que possível é preferível este tipo de montagem. Este tipo de montagem é feita
em caixas embebidas nas paredes, os dispositivos são fixados a estas através de parafusos. As caixas
devem ter 50 mm de profundidade para se poder trabalhar com os cabos e o dispositivo caber.
Neste tipo de montagem é possível combinar dispositivos de energia e dispositivos do tipo embebido
KNX, como podemos ver na figura 29.
Figura 29: Dispositivos do tipo montagem embebida.
Na montagem de superfície (Surface mounted,) os dispositivos são colocados à superfície,
ficando totalmente visíveis para o utilizador como mostra a figura 30.
Figura 30: Dispositivo do tipo montagem de superfície
Na montagem Device mounted os dispositivos são incorporados em outros equipamentos como
aquecedores, ar condicionado, lâmpadas e em alguns eletrodomésticos. Aos olhos do utilizador não
Erro! A origem da referência não foi encontrada. 33
é visível sua presença. Como poderemos confirmar na figura 31, não é visível que a banheira tem
qualquer tipo de controlo contudo existe: possui electro-válvulas e vários sensores que não são
visíveis, mas que podem ser controlados em benefício do utilizador.
Figura 31: Dispositivo do tipo montagem Device mounted.
Tipo de cabo
Antes de especificar o tipo de cabos a utilizar nas instalações, convém dar uma breve
explicação sobre as tensões admissíveis nos cabos de bus KNX. A tensão SELV (Safety Extra Low
Voltage) é uma das mais importantes a ter em conta. Esta tensão é gerada por um transformador de
segurança. O seu valor normal de funcionamento é de 29 VDC e não pode ser ligada ao potencial da
terra. Os limites máximos de tensão para corrente contínua e alternada são nomeadamente:
120VDC e 50VAC. Os cabos utilizados nos sistemas KNX devem possuir isolamento de segurança das
outras redes, isolamento à terra e sem isolamento para o utilizador. A figura 32 representa os
termos e ideias referenciados:
Figura 32: Isolamento de cabos para KNX.
No capítulo 9 do Handbook KNX estão todos os tipos de cabos que podem ser utilizados numa
instalação. A título de exemplo, os cabos com o logótipo KNX e os outros que cumprem as
características e que lá estão definidos, como exemplo: o YCYM 2x2x0.8 e o JY(St)Y 2x2x0.8. Só os
cabos verdes KNX garantem: o máximo comprimento da linha, o máximo espaço entre dispositivos e
o máximo de dispositivos. Este cabo tem como características 72Ω e uma capacidade de 0.12μF por
cada 1000m. A figura 33 especifica as características necessárias de um cabo KNX.
34 Introdução
34
Figura 33: Características de um cabo param KNX.
Os requisitos de uma instalação KNX são normalmente os mesmos que param uma instalação
de 230/400V. Quando possível deve-se garantir uma distância mínima de 4mm entre os condutores
do bus KNX e os de energia.
Erro! A origem da referência não foi encontrada. 35
Capítulo 4
Sistema de gestão de domótica
3.1 Sistema de gestão de domótica
No âmbito da dissertação foi proposto o desenvolvimento de um sistema de gestão de domótica
que deveria interagir com uma rede KNX já implementada. O novo sistema acrescenta
funcionalidades ao sistema já existente, devendo ser baseado numa arquitetura de software
modular. O sistema desenvolvido é constituído por um computador e um quadro que representa a
rede KNX, sendo ligados entre si por um cabo Ethernet. Para melhor compreender o sistema a figura
34 representa de forma simplificada e concisa a constituição do sistema.
Figura 34: Arquitetura global do sistema.
Toda esta arquitetura de hardware já se encontrava elaborada, faltando apenas o software
para controlar e gerir todo este sistema. Com este projeto a empresa pretendia dar os primeiros
passos na área da domótica; após este desenvolvimento pretende-se que o sistema evolua e que
inclua novas funcionalidades. A arquitetura de hardware é constituída por uma Gate Box que
permite a ligação do sistema à Internet e futuramente o acesso remoto e um Switch que permite a
ligação do sistema desenvolvido até então à Gate Box. O switch identifica cada porta (sistema de
gestão de domótica) e envia os dados somente para a porta destino, evitando assim que outros
36 Introdução
36
sistemas de gestão de domótica recebam dados que não lhe são destinados. A caixa verde
representa um sistema idêntico ao desenvolvido e a possibilidade de ligar vários sistemas idênticos
ao switch. O sistema desenvolvido nesta dissertação é constituído por um computador que possuí o
software que controla a rede KNX. O computador é ligado ao quadro ou rede KNX por um cabo
Ethernet como já foi referido e está representado na figura 34. O quadro ou rede KNX é constituído
por um Router (ABB KNX IP router IPR/S 2.1), uma fonte de alimentação representada na figura por
VCC e um módulo de controlo de quatro saídas (TXA 204A). O router tem a função de fazer a
interface entre o computador e o resto da rede KNX e o encaminhamento dos telegramas KNX
recebidos para os dispositivos a que se destinam através do bus de dados representado pelos fios
preto e vermelho e legenda “KNX”. O bus de dados serve para transmitir os telegramas e alimentar
os módulos da rede KNX. O módulo de controlo de quatro saídas independentes é constituído por
quatro relés que permitem fazer a interface do bus KNX com cargas elétricas comandadas por
comandos ligar/desligar. Permitem comandar a iluminação, o aquecimento ou qualquer outra carga
pelo apertar de um botão (contacto livre de potencial). Este módulo possui quatro botões de
pressão com um indicador de estado (led verde se ligado) para comandar as saídas independentes. A
fonte de alimentação é alimentada a 230 V alternados, produz uma tensão de 29 V contínuos
(definido pelo protocolo), uma corrente máxima de 350 mA e pode alimentar até um máximo de 16
dispositivos KNX. As habitações 1 e 2 representam habitações que poderiam ser adicionadas à rede
KNX. Devido às limitações apresentadas pela rede relativamente ao número de saídas que se podem
controlar e à necessidade de definir vários perfis de utilização, definiu-se que as mesmas saídas
iriam ser comuns às duas habitações. Isto para que fosse possível mediante cada perfil de utilizador
e sua habitação, o utilizador só pudesse controlar determinadas saídas ou conjunto, mediante as
permissões que tivesse. Contudo isto será mais percetível aquando da apresentação de resultados
nos testes e avaliação do sistema.
Voltando ao objetivo fundamental desta dissertação salienta-se a especificação e
desenvolvimento de uma arquitetura modular que permitisse futuras alterações e desenvolvimentos
do sistema global. Após a análise das várias arquiteturas de software foi escolhida a arquitetura
Model-View-Controller (MVC) representada pela figura 35.
Figura 35: Arquitetura de Software do sistema a desenvolvida.
A arquitetura MVC é uma arquitetura de Software que se divide em três camadas: Model
(modelo), View (visão) e Control (controlo). Esta foi escolhida por ser uma arquitetura modular que
permitiria aumentar o número de aplicações e o número de dispositivos a controlar. A arquitetura
MVC por ser modular permitia a separar a lógica de negócio da lógica do controlador, desta forma
facilitando a organização e separação dos diferentes módulos. A separação dos dados a apresentar
ao utilizador dos dados da aplicação permitia uma melhor organização da informação.as vantagens
que levaram à escolha desta arquitetura são as seguintes:
Separação das diferentes camadas de desenvolvimento dotando o sistema da capacidade de
se tornar modular;
Separação da lógica de apresentação do negócio da lógica de aplicação;
Erro! A origem da referência não foi encontrada. 37
Facilidade e possibilidade de reaproveitamento do código em desenvolvimentos futuros ou
possíveis alterações;
Reutilização do código do desenvolvido para as diferentes partes a desenvolver;
Facilidade de manutenção do sistema;
Facilita a criação de documentação e manutenção de cada parte constituinte arquitetura;
Desenvolvimento de múltiplas aplicações e integração de equipas multidisciplinares no
desenvolvimento da arquitetura;
Separação do design da visão, da programação do controlo;
Teste e manutenção isolada das diferentes camadas de desenvolvimento;
Facilidade da implementação de segurança no sistema;
Facilidade da organização do sistema a desenvolver pois possibilita a programação por
diferentes especialistas em cada área e a interação entre os mesmos devido à sua modularidade.
Antes de chegar ao sistema de gestão de domótica a implementar foi necessário uma análise
dos requisitos do sistema, definir objetivos de usabilidade, realizar estudos de campo, analisar a
concorrência, definir perfis de utilizador para os diferentes utilizadores do sistema, realizar análise
de tarefas, definir cenários de utilização, definir o que é responsabilidade do sistema e o que é
responsabilidade do utilizador e por a fim definição e combinação das diferentes tecnologias para
as diferentes camadas de forma a serem compatíveis e de terem bom desempenho.
4.1 Model
A camada model (modelo) representa as informações do sistema de gestão de domótica,
fornece funções para operar os dados, isto é, representa as funcionalidades da aplicação. A camada
model é responsável por notificar a interface (View) quando os dados são alterados se assim for
definido no modelo de negócio. A forma como os dados são armazenados, manipulados e como é
feito o seu acesso não depende da arquitetura mas sim do modelo de negócio. A camada Model teve
como finalidade as características atrás mencionadas, definir e gerir o domínio da informação e
notificar os utilizadores sobre mudanças nos dados, manipular e representar a informação detalhada
fornecida pelo utilizador à aplicação. Devido à necessidade de armazenar a informação foi
necessário criar uma base de dados para guardar a informação do sistema. No model foram criadas
as regras do negócio representadas sob a forma de tabelas, campos, estruturas, relações entre
tabelas etc. A base de dados criada para a camada model será explicada de forma mais
aprofundada após a explicação da arquitetura de software.
4.2 View
A camada View (visão) ou interface teve como objetivo apresentar o modelo de negócio ao
utilizador com a apresentação dos dados. Diferentes visões podem ser apresentadas para um mesmo
modelo de negócio se existirem diferentes propósitos como a limitação por tipo de utilizador. A
camada View teve a finalidade de definir de que forma a informação é apresentada ao utilizador. A
camada View teve ainda como função base a apresentação das perguntas e respostas ao utilizador
mediante os dados pretendidos pelo controlador e pelo utilizador. Assim sendo esta camada foi
fundamentalmente utilizada para entrada e saída de dados e dar um aspeto gráfico mais agradável
à apresentação dos dados. Antes de ser definida à camada View do sistema foi necessário:
Definir objetivos de usabilidade do sistema;
Analisar a concorrência (outros sistemas de gestão de domótica) para retirar o melhor que
cada sistema de gestão de domótica possui e implementar um se possível ainda melhor;
Analisar e definir as diferentes visões para cada perfil de utilizador;
Definir os diferentes cenários de utilização;
38 Introdução
38
Definir a informação a apresentar e como deveria ser apresentada ao utilizador;
Definir a tecnologia e linguagem gráfica a usar.
Depois das necessidades acima mencionadas existiram duas perguntas que impuseram:
A quem se destina esta camada?
Foi fundamental saber quem era o público-alvo, o número de utilizadores, as tecnologias já
existentes e o que os utilizadores esperavam e achavam necessário ser apresentado. Foi definido o
design com base nestes aspetos e com a preocupação de criar uma navegabilidade e uma estrutura
da camada View que promovesse a usabilidade do sistema.
O que apresentar na elaboração da camada View?
Saber o conteúdo a apresentar foi dos tópicos mais importantes e uma das razões da camada
View; daí adveio também a preocupação da forma como apresentar a informação visto esta
influenciar a funcionalidade da camada.
Após uma análise dos prós e contras das várias tecnologias e não esquecendo a necessidade de
compatibilidade dentro de todo o sistema foi escolhida a apresentação gráfica do explorador de
Internet com base na linguagem HTML e no tratamento gráfico pela linguagem de estilo CSS.
Estas tecnologias e linguagens foram escolhidas por serem de acesso livre e gratuito, existir
imensa documentação, variados exemplos onde se basear para a elaboração da apresentação
gráfica e por fim porque o produto final conseguido com estas escolhas ser de elevada qualidade
gráfica e de fácil obtenção.
4.3 Controller
A camada Controller (controlador) tem como função fazer toda a gestão da arquitetura de
software, receber e tratar as interações com a visão, apresentar e implementar o modelo de
negócio sempre que solicitado e dar as respostas ao modelo através da visão. As funções base da
camada Controller e necessidades do sistema são:
Controlar as regras do negócio;
Processar e responder a eventos;
Poder invocar alterações no Modelo.
Ao Controller cabe a responsabilidade de toda a gestão e controlo do que ocorre no sistema e a
decisão de tudo o que é apresentado ao utilizador. Ao Controller é exigido que ao receber a
entrada de dados, inicie a resposta ao utilizador invocando objetos do modelo e por fim apesente
uma visão baseada na entrada. Ele também terá a responsabilidade da validação e filtragem da
entrada de dados. Como neste caso prático é usado uma aplicação web em HTML como na camada
View, o controlador teria de receber a entrada dos dados pelo método GET ou POST. Após um
estímulo do utilizador a camada Controller tinha de decidir como processar os dados, invocando
objetos do sistema para tratar a lógica de negócio, e por fim invocar uma visão para apresentar a
saída. Depois da análise efetuada às necessidades do sistema, da camada Controller e à
necessidade de compatibilidade com as tecnologias até então escolhidas e a vasta abrangência de
funções o PHP foi a linguagem escolhida. O porquê desta escolha será detalhado mais a frente.
4.4 BASE DE DADOS
A criação de uma base de dados surgiu da necessidade de suportar o modelo de negócio
permitindo armazenar e gerir a informação de toda a rede KNX. Posteriormente ocorreu a
necessidade de criar um modelo de base de dados que servisse de suporte para toda a informação
de qualquer rede KNX. É na base de dados que são guardadas todas as informações uteis ao
funcionamento do sistema e onde são registadas todas as informações úteis da rede (habitações,
Erro! A origem da referência não foi encontrada. 39
utilizadores, dispositivos, Datapoints, endereços de grupo, a relação entre cada uma das entidades
e todas as atividades da rede KNX). Tudo isto será explicado mais à frente neste capítulo.
A base de dados construída é uma base de dados relacional que foi criada devido à necessidade
de ter conjuntos de relações (tabelas) que guardassem as informações e as separassem segundo as
necessidades da rede KNX e segundo restrições de integridade. A cada relação (tabela) criada
segundo as necessidades da rede KNX foi necessário atribuir um nome, definir os diferentes
atributos (tuplos) e um conjunto de restrições internas para o seu preenchimento. A necessidade de
organização da informação levou à criação de atributos nessas tabelas criadas que só admitem
valores elementares e nunca conjunto de valores. Para uma melhor identificação, todas as tabelas
construídas possuem uma chave de relação que identifica os seus tuplos de uma forma única
possuem; ainda um conjunto mínimo de atributos para que sejam distintas, uma chave primária e
em alguns casos chaves alternativas. As chaves alternativas são chaves estrangeiras que permitem a
utilização de um atributo ou um conjunto de atributos que referenciam um atributo ou um conjunto
de atributos de outra tabela permitindo relacionar as diferentes tabelas entre si. Estas chaves
estrangeiras permitiram o cruzamento dos dados, a relação das diferentes tabelas como um só
sistema de informação e tornaram mais simples de obtenção da informação desejada.
As restrições do modelo relacional criado para suportar a informação da rede KNX são comuns
às mais variadas bases de dados e foram criadas em resposta às seguintes necessidades:
Integridade das entidades:
Os valores da uma chave primária não podem ser nulos;
Os valores dos atributos devem ser todos do mesmo tipo;
Unicidade das chaves;
Não podem existir 2 tuplos diferentes com valores iguais na chave;
Integridade referencial:
Um tuplo de uma relação que se refira a uma outra relação tem de se referir a um tuplo
existente nessa relação referenciada;
Alguns atributos não podem possuir valores nulos mesmo não sendo chaves candidatas
colocando na criação do atributo Not Null, isto porque são atributos fundamentais à identificação e
ao funcionamento da rede KNX;
Chaves candidatas são atributos que têm de ser únicos (UK- Unique Key) estes definem o
objeto exemplo: contribuinte de um utilizador.
A necessidade de identificar de forma única as diferentes tabelas criadas levou à criação de
chaves de identidade, isto porque era necessário como já referido criar relações entre as diferentes
tabelas. As relações tipo que surgiram foram de um campo para muitos campos (cardinalidade 1:N)
e de muitos para muitos (cardinalidade N:M). A título de exemplo estas relações tipo surgiram da
necessidade de relacionar uma habitação com N dispositivos e da necessidade de relacionar N
dispositivos com M endereços de grupo e vice-versa.
A criação de relações foi fundamental para um bom funcionamento e organização da base de
dados uma vez que permitiu o cruzamento de informação. Estas aceleraram e facilitaram a
realização de pesquisas e consultas que incluíam mais de uma tabela. Para criar uma relação como
já referido foi preciso associar o campo chave primária duma tabela com os seus correspondentes
numa outra tabela. A figura 36 retrata o modelo da base de dados concebido para o sistema
desenvolvido na dissertação.
40 Introdução
40
Figura 36: Esquema da base de dados elaborada para armazenar a informação da rede KNX.
A figura 36 serve para suportar o que será explicado de forma a se perceber como e o porquê
de cada tabela.
O que representa cada tabela:
Habitação é a representação da casa como um todo, caso seja uma só moradia, ou uma
fração, caso existam várias moradias.
Utilizador é a representação das diferentes pessoas que irão utilizar o sistema com as
diferentes permissões.
Dispositivo é a representação dos diferentes elementos que constituem a rede.
Datapoint é a representação de cada funcionalidade possível de se implementar nos
diferentes dipositivos.
Addressgroup é a representação de um endereço de grupo de um ou vários dispositivos
numa rede KNX.
Dispositivoaddressgroup representa a relação de N:M entre o dispositivo e o addressgroup,
isto para se saber quantos dispositivos possui um Addressgroup e a quantos Addressgroup pertence
um dispositivo.
Será agora explicado porquê da rede ter sido dividida desta forma.Como a rede KNX que existia
já possuía determinadas características e tinha como perspetivas futuras acrescentar mais
funcionalidades por conseguinte mais dispositivos. Com base em todas essas necessidades foi criada
uma base de dados que possibilitasse a gestão de N habitações, com M dispositivos e com X
utilizadores. A necessidade de guardar a informação da rede e a necessidade de organizar essa
informação, levou à criação de uma tabela para dividir a rede nas N habitações possíveis. Como
para cada habitação havia muita e variada informação, foi necessário repartir a informação por
mais duas outras tabelas, utilizador e dispositivo (aparelho KNX). Daí surgiu a necessidade de criar
relações entre estas e a tabela habitação, as relações criadas foram uma habitação para M
dispositivos e uma habitação para X utilizadores daí as relações terem a cardinalidade 1:N. Depois
desta divisão verificou-se que ainda não era o suficiente visto que a informação necessária ao
funcionamento e gestão de um dispositivo era imensa. Foi efetuada uma análise e verificado que o
dispositivo comum segundo o protocolo KNX precisava de um a N Datapoints (define uma
funcionalidade) para funcionar e devia pertencer a pelo menos um endereço de grupo (o seu para
ser identificado no comando a executar) ou poderia pertencer a N endereços (definindo um
cenário). Com base na possibilidade e necessidade de criar cenários foi criada uma relação de M
Erro! A origem da referência não foi encontrada. 41
dispositivos para Y grupos e vice-versa, daí adveio a necessidade de criar a tabela de relação
dispositivoaddressgroup para que fosse possível este tipo de relação e assim a tecnologia obrigava.
Após uma profunda análise e estudo do protocolo KNX descobriu-se que a cada addressGroup só
poderia estar associado um Datapoint e a cada Datapoint uma só funcionalidade daí a necessidade
anteriormente definida de existir uma relação de M dispositivos para Y grupos e vice-versa. Devido
à existência de duas habitações e a possibilidade de existirem N habitações surgiu a necessidade de
identificar no endereço de grupo (addressGroup) a habitação que pertence.
Agora será demonstrado como a informação foi organizada e distribuída assim como a
informação necessária à correta gestão da rede KNX:
Habitação:
Id (identificação da habitação);
O IP da Gateway da rede (ipGatewayKNX- ip do Router IPR/S 2.1) para comunicação com a
mesma;
O IP do computador (ipGateway) para comunicação com a rede;
Porto do computador para comunicação com a rede;
Utilizador:
Identificação enquanto utilizador;
Identificação pessoal do utilizador;
Username e password para autenticação;
Dispositivos:
Identificação do dispositivo;
Habitação pertencente;
Endereço individual (área, linha, nº do dispositivo) único na rede;
Estado atual do dispositivo e valor atual para saber do seu funcionamento;
Datapoint:
Identificação do Datapoint;
Prioridade face a outras funções;
Codificação ou seja uma string que identifica o comando na rede KNX;
Valor máximo e mínimo para saber a gama de valores que o dispositivo poderá receber num
comando;
Unidades quando aplicavél;
AddressGroup:
Identificação do endereço de grupo;
Identificação da habitação a que pertence;
Endereço físico atribuído pelo programa de gestão da rede KNX (ETS);
Identificação do Datapoint a que está associado;
O número de dispositivos que constituem o grupo;
Dispositivo_AddressGroup:
Identificação da relação entre o dispositivo e o endereço a que pode pertencer;
Identificação do dispositivo;
Identificação do endereço de grupo;
42 Introdução
42
Após vários testes de funcionalidade e sucessivas alterações o modelo de base de dados final é
o abaixo demonstrado pela figura 37:
O tipo de dados de cada tuplo corresponde à informação que este terá de armazenar não
podendo guardar de qualquer outro tipo. Este modelo pode ser aplicado a qualquer rede KNX com o
mais variado número de dispositivos e utilizadores e habitações.
Figura 37: Modelo final da base de dados.
Erro! A origem da referência não foi encontrada. 43
Tecnologias adoptadas
4.5.1 MySQL
O MySQL é um sistema de gestão de base de dados (SGBD), que utiliza a linguagem SQL
(Structured Query Language - Linguagem de Consulta Estruturada) como interface. O SGBD é
responsável pela gestão da base de dados; o principal objetivo é gerir o acesso, a manipulação e a
organização dos dados. A inclusão de um SGBD no sistema surgiu devido à necessidade de
armazenar, agilizar e garantir a continuidade e segurança dos dados necessários e adquiridos. Após
uma análise aprofundada foi escolhido um SGBD em MySQL; no início a escolha recaiu em 2
linguagens o PostgreSQL e o MySQL pois as linguagens ofereciam:
Manipulação, definição, controlo, transação e consulta de dados;
Elevada Portabilidade (suportadas por praticamente qualquer plataforma atual);
Elevada compatibilidade (módulos de interface para diversas linguagens de programação,
como Delphi, Java, C/C++, Python, Perl, PHP e Ruby e drivers ODBC, JDBC e .NET);
Excelente desempenho e estabilidade;
Pouco exigente quanto a recursos de hardware necessários do sistema na sua manipulação;
Facilidade de uso e elevado número de documentação livre;
Serem de utilização livre.
A escolha foi o MySQL pois havia mais documentação onde apoiar o seu estudo e
desenvolvimento, preenchia todos os requisitos e necessidades inerentes ao sistema, era uma
linguagem nova para mim e por fim era uma linguagem de uso livre, que também era um dos
requisitos. Era necessário que fosse compatível com o Windows, pois era o sistema operativo do
computador; verificou-se ser possível e que ainda podia operar com outros sistemas operativos (
Linux, Mac OS X, etc.). Devido à possibilidade de o sistema operar com um elevado número de
habitações, utilizadores e dispositivos, revelou-se a necessidade de um SGBD de elevado
desempenho, robustez, multitarefa e multiutilizador. Prova da resposta a estas necessidades era a
própria Wikipedia utilizar MySQL na gestão da sua base de dados, demostrando assim que é possível
utilizá-la em sistemas de produção de alta exigência e em aplicações sofisticadas com múltiplos
utilizadores a aceder e modificar os dados ao mesmo tempo. Depois de todas estas vantagens,
funcionalidades e prova das suas capacidades não restou dúvidas na escolha do MySQL para o
sistema SGBD.
4.5.2 HTML
O HTML é uma linguagem de marcação de hipertexto (Hyper Text Markup Language), ou seja,
uma linguagem usada para criar páginas Web. Esta linguagem foi desenvolvida para transmitir a
informação que é colocada nos documentos partilhados na web pelo protocolo http (Hyper Text
Transfer Protocol). A escolha do HTML deveu-se à necessidade de apresentar dados ao utilizador
através de camada View, formatar texto e imagens, atribuição de cores, definir padrões, fundos,
definir papel de parede, tabelas, links e frames. O facto de ser uma linguagem de fácil
compreensão mesmo para quem nunca teve contato com qualquer outro tipo de linguagem de
programação, adicionado às necessidades atrás mencionadas e às funcionalidades e vantagens
ajudou na escolha do HTML. O HTML possui ainda a vantagem de poder ser criado e editado por um
simples editor de texto, como por exemplo o Notepad. Caso seja desejado um melhor será
aconselhado o Notepad++ que também é de uso livre e é mais vocacionado para este estilo de
programação em questão. O HTML no sistema elaborado sofreu grande influência das folhas de
44 Introdução
44
estilo (CSSs) na sua apresentação, essa influência será de seguida justificada e apresentadas as
vantagens dessa influência.
4.5.3 CSS
Cascading Style Sheets (folha de estilo) é uma linguagem de estilo utilizada para definir a
apresentação de documentos escritos numa linguagem de marcação, como HTML ou XML. A
principal vantagem na sua utilização é permitir separar a formatação do conteúdo a apresentar na
camada View. Em vez de colocar a formatação do documento HTML dentro deste, o programador
apenas precisa criar um link (ligação) em cada página criada para a folha de estilos. A necessidade
de criar muitas páginas e a possibilidade de usar a mesma CSS economizando código nas páginas
HTML e por conseguinte redução do tamanho dos ficheiros. A facilidade de quando se quiser alterar
a aparência das diferentes páginas dependentes da CSS. A necessidade de acompanhar as
tendências do mercado e por conseguinte a necessidade de alterar o conteúdo a apresentar. Os 16
milhões de cores para utilizar nos textos e fundos e imagens. A possibilidade de definir vários
padrões para utilizar sempre que necessário formatar:
Fontes tipo para formatação de texto;
Formatação das margens;
Formatação de tabelas;
Fundos;
Bordas;
Distância entre objetos;
Definir posição de objetos.
Depois de demonstradas as vantagens e verificadas as necessidades do sistema ficou clara a
necessidade e as vantagens da utilização de CSS na elaboração da camada View. Assim sendo a
imagem seguinte demonstra de uma forma visual o que até agora foi enumerado como vantagens.
Serão mostradas duas imagens com a mesma página web, uma sem a influência das formatações da
CSS e depois da influência da CSS para demonstrar e exemplificar o que foi dito e o impacto no
produto final.
Figura 38: Página de login sem a influência da CSS.
Como podemos verificar a página está sem vida, não capta a atenção do utilizador, não motiva
a sua utilização e não permite identificar o objetivo de cada elemento. A imagem seguinte já é uma
Erro! A origem da referência não foi encontrada. 45
imagem com a influência da CSS; tem muito mais vida, está mais organizada, consegue-se perceber
o que é cada elemento, é mais atrativa a sua utilização e mais funcional.
Figura 39: Página de login já com a influência da CSS.
Em jeito de conclusão além de tornar a página bem mais agradável, funcional, atrativa etc. a
CSS permitiu uma redução muito grande do código em cada página e facilitou o tratamento dos
erros e as alterações feitas ao longo do desenvolvimento.
4.5.4 Javascript
O Javascript é uma linguagem de programação web normalmente utilizada para auxiliar o
desenvolvimento de páginas web. Esta linguagem foi desenvolvida pela NETSCAPE, para tornar as
aplicações nas páginas HTML mais interativas. Após a sua criação recebeu uma importante
colaboração da Sun Microsystems, empresa que já se havia dedicado ao desenvolvimento de
aplicações para a Internet, com uma das linguagens mais poderosas, o Java contudo diferente do
Javascript. Após esta colaboração, podemos dizer que o Javascript é uma linguagem compatível
com a linguagem Java, daí a semelhança do nome “Javascript”. As características e vantagens que
levaram à utilização da linguagem Javascript foram:
Ser uma extensão da linguagem HTML;
Ser uma linguagem de programação orientada a objetos;
Variedade de objetos que já existem criados;
Possibilidade de poder mudar as propriedades mesmo depois do objeto ser carregado
aquando a página;
Possibilidade de criação de scripts tanto do lado cliente como do lado servidor;
Fazer o tratamento de:
Eventos (clicar em objeto, selecionar algum objeto, pressionar tecla);
Formulários (preenchimento e analise dos dados inseridos);
Maior interação com o utilizador do que HTML;
Facilidade de edição num editor ASCII como por exemplo, o Bloco de Notas do Windows.
Possibilidade de reutilizar o código se desenvolvido num ficheiro à parte.
46 Introdução
46
As imagens seguintes demonstram um organograma de parte dos objetos que a linguagem
possui e um exemplo de um objeto muito utilizado nas páginas web.
Figura 40: Organograma das classes de objetos existentes em Javascript.
Conforme apresentado neste organograma, pode-se verificar que existem vários objetos e
alguns são melhorias dos seus antecessores. A figura apresenta uma função comum no
desenvolvimento web que permite alertar o utilizador para um qualquer erro.
Figura 41: Caixa de dialogo alert() do objeto Window.
Erro! A origem da referência não foi encontrada. 47
As duas figuras seguintes apresentam uma das funcionalidades criadas na página de controlo, a
primeira figura antes de clicar sobre objeto submit (Ler) e segunda depois de clicar.
Figura 42: Página antes de clicar no botão Ler e ativar o script.
Figura 43: Página depois de clicar no botão Ler e ativar o script.
48 Introdução
48
Como se pode constatar mesmo depois da página carregada o script alterou a página e pediu a
informação à base de dados sobre o dispositivo em questão, sem a necessidade de carregar uma
nova página. Para concluir é de referir que o Javascript facilitou o desenvolvimento do projeto e o
tratamento de dados; contudo, devido à falta de tempo não foi muito utilizado. O Javascript
revelou-se uma ferramenta poderosa, fácil de implementar e muito útil.
5.5.5 PHP
O PHP ( Hypertext Preprocessor originalmente Personal Home Page) é uma linguagem de
programação web livre utilizada para gerar conteúdo dinâmico. O PHP foi escolhido porque
acrescentava valor às páginas web e devido à capacidade de dotar o sistema de funcionalidades
avançadas. Uma das vantagens de usar PHP é que é simples para um iniciante, contudo oferece
muitos recursos ao programador profissional. Era necessária uma linguagem que permitisse a gestão
e a execução de comandos que executassem programas externos; de todas as linguagens analisadas
e livres a que melhor se enquadrava era o PHP. Pode-se dizer que a única limitação para o uso do
PHP é a imaginação. O PHP é uma linguagem muito rica; contudo pode ser editada num qualquer
editor de texto, embora seja aconselhado o Notepad++ ou o Netbeans que é ainda melhor, e
correspondem à exigência de serem software livre. Uma desvantagem que no fundo não se tornou
uma desvantagem devido ao sistema a desenvolver foi que o PHP apenas executava no Netbeans ou
num servidor; contudo, tal não se tornou uma desvantagem visto o sistema necessitar dum servidor
para publicar as páginas web do sistema. Ao contrário do que ocorre com o HTML e as CSS, no
PHP não faz diferença o navegador que é usado, mas sim o servidor onde a página é hospedada. Isto
porque PHP é uma tecnologia processada do lado do servidor, o que se torna uma segurança para o
mesmo, pois o cliente apenas vê o código como HTML e não tem como saber que é PHP. O PHP
possui a particularidade de poder conjugar HTML e código de controlo PHP e ainda exige menos
comandos que o HTML. O PHP para ser diferenciado do HTML apenas precisa ser delimitado pelas
tags “<?php” no início e no fim terminar com “?>”.
O que distingue essencialmente o PHP do Javascript é que o PHP é executado do lado do
servidor, gerando código HTML que é então enviado ao cliente. O cliente recebe apenas os
resultados da execução do script, mas não sabe como é o código fonte o que oferece segurança ao
sistema desenvolvido nesta linguagem.
O PHP é uma linguagem muito rica. Com ela pode-se fazer tudo o que se precisar como por
exemplo interagir com outros programas de outras linguagens como era necessário ao sistema de
gestão de domótica desenvolvido. O PHP é uma linguagem de script, com ele pode fazer tudo o que
faria com outro programa CGI (Common Gateway Interface) como:
Receber e tratar dados de formulários;
Gerar páginas com conteúdo dinâmico;
Enviar e receber Cookies;
Correr outros programas;
Trabalhar com base de dados;
Escrever aplicações de desktop, se bem que não é a sua melhor funcionalidade.
O PHP tem a sua maior utilização na construção de scripts:
Do lado do servidor (server-side) e este é o principal campo de atuação do PHP;
Execução de comandos na linha de comandos, que é um script que funciona sem um
servidor web ou browser; apenas necessita de um interpretador. Este tipo de uso é ideal para
agendar tarefas, rotinas de processamento de texto.
Erro! A origem da referência não foi encontrada. 49
Com a necessidade de criar conexões, manipular dados, pesquisar e eliminar dados na base de
dados o PHP foi um ótimo aliado devido às suas funcionalidades e à facilidade de as utilizar. Com o
desenrolar de sistema desenvolvido foi necessário limitar as funcionalidades até então
desenvolvidas por tipo de utilizador e mais uma vez e devido às variáveis de sessão e
funcionalidades do PHP foi simples de resolver.
Com muito por dizer em termos de funcionalidades e vantagens, pode se mesmo dizer que o
PHP poderia ser quase a única linguagem para o desenvolvimento da dissertação e não só da parte
de controlo pois revelou se uma ferramenta poderosa.
4.5.6 Calimero
O Calimero é um pacote de software livre constituído por um conjunto de APIs JAVA,
desenvolvidas por estudantes da Vienna University of Technology e da University Of Applied
Sciences in Deggendorf, que foi apresentado na conferência científica de KNX. Com as bibliotecas
criadas por este grupo de estudantes podem-se construir aplicações KNX, que permitem a
comunicação, controlo, acesso local e remoto de redes KNX. O acesso efetuado pelo Calimero ou
qualquer outra aplicação desenvolvida com base nestas bibliotecas permite o estabelecimento de
um túnel de comunicação sobre uma rede IP com um Gateway KNX, processo denominado
KNXnet/IP Tunnelling. A versão mais atual do software suporta ainda o modo KNXnet/IP Routing, a
gestão da rede de dispositivos, registo de erros e mensagens de Debug, possui um buffer para as
mensagens de rede KNX e uma função que permite registo de todos os eventos ocorridos no
Barramento KNX numa base de dados. As APIs do Calimero permitem a criação de aplicações KNX
sem conhecer a fundo o protocolo de comunicação do KNX. O Calimero permite a ligação a uma
rede KNX permitindo passar comandos de escrita e de leitura sobre os dispositivos KNX, podendo
atuar como um gestor de eventos na rede KNX. A função do Calimero no sistema desenvolvido é
apenas fazer a interface entre o sistema e a rede KNX. Ao Calimero cabe apenas executar os
comandos de escrita e leitura enviados pelo sistema para a rede KNX e transformar os dados
recebidos pelo sistema em telegramas KNX percetíveis à rede KNX. Após receber o telegrama, a
rede KNX, mais propriamente a Gateway KNX, fará a interface entre a rede IP e a sub-rede KNX/EIB
- TP1. Após o telegrama chegar à rede KNX, será encaminhado para o dispositivo certo e convertido
num comando. Estas são as funções base do Calimero no sistema desenvolvido na dissertação.
4.5.7 Wampserver
O Wampserver ou WAMP5 é um pacote de software livre que foi desenvolvido pela PHP Team.
WAMP5 significa Windows, Apache, MySQL, PHP5. Este pacote é constituído por um conjunto de
programas que instala automaticamente o Apache, o PHP, o MySQL, o PHPmyadmin e
SQLitemanager. A escolha deste programa deveu-se essencialmente ao facto de ser executável em
Windows, possuir o servidor Apache que foi um dos maiores servidores web em 2010 com mais de 66
milhões dos sites mais, possuir uma base de dados MySQL, disponibilizar as ferramentas necessárias
para o uso de scripts PHP e interpretar CSS, HTML e Javascript. Com auxílio deste programa pode-se
criar um sistema de gestão de domótica, sem ter que publicar na Internet qualquer página,
permitindo ainda navegar entre páginas como se se estivesse na Internet como era pretendido. O
Wampserver permitiu o acesso às páginas web escritas em PHP, HTML e Javascript e tornou o
sistema mais dinâmico e rápido. Permitiu ainda alojar o sistema e através deste o acesso à base de
dados MySQL. O Wampserver como já referido anteriormente interpreta a tecnologia livre PHP5
permitindo o uso dos seus objetos e scripts. Como já antes foram abordadas e referidas as suas
funcionalidades tem se a acrescentar que o Wampserver possui uma interface para o utilizador
adicionar, editar, pesquisar e eliminar utilizadores, base de dados, tabelas e tudo o que uma base
de dados necessite.
Erro! A origem da referência não foi encontrada. 51
4.6.1 Interface gráfica
A interface gráfica como já referido na arquitetura MVC é a parte visual apresentada ao
utilizador. A interface desenvolvida baseou-se fundamentalmente em três linguagens: HTML, CSS e
Javascript.
O HTML é a principal linguagem e a mais utilizada na parte visual de todo o projeto; a ela
coube a apresentação dos conteúdos comuns como imagens, textos, tabelas, hiperligações e
estrutura das várias páginas.
As CSSs e a sua programação foram a tecnologia secundária desta interface, permitindo a
definição de uma estrutura, uma formatação do texto e uma apresentação comum às várias
páginas, tornando o sistema modular e de fácil alteração quer na estrutura ou na parte gráfica.
O Javascript foi a tecnologia menos utilizada por falta de tempo para aprofundar o projeto. O
tratamento de formulários, criação de animações e a promoção de uma maior interatividade entre
o controlo e o utilizador podiam ser promovidos por esta tecnologia visto serem funções muito
comuns nesta linguagem. A sua utilização limitou-se ao tratamento de formulários e algumas
animações. As figuras seguintes irão demonstrar a dependência das três linguagens para o projeto
desenvolvido e o acrescento de qualidade a cada linguagem adicionada.
Figura 44: HTML sem a influência das folhas de estilo e o Javascript.
52 Introdução
52
Figura 45: HTML já com a influência das folhas de estilo mas sem o Javascript.
Figura 46: HTML já com a influência das folhas de estilo e o Javascript.
Como se pode observar ao passar o rato pelo menu a imagem troca de posição com as letras e ao
retirar volta a trocar, isto graças ao Javascript pois na imagem acima o rato está lá e nada
aconteceu pois o Javascript estava desativado.
4.6.2 Processamento do controlo
O processamento do controlo do sistema desenvolvido dividiu-se em duas partes o controlo com
o PHP e o controlo com Calimero. O PHP tem o seu controlo dividido em duas grandes partes: o
controlo da base de dados e o controlo e gestão da parte da domótica. A gestão da base de dados
envolve todo o processamento, tratamento, edição, pesquisa e eliminação de dados. Para a gestão
de um sistema de domótica é necessária a informação fundamental ao funcionamento de toda a
rede.
Erro! A origem da referência não foi encontrada. 53
A base de dados como já referido tem de ter a informação necessária ao funcionamento da
rede KNX e a possibilidade de relacionar as diferentes componentes da mesma. Em cada rede KNX
pode existir uma ou mais habitações, pois pode ser uma rede de uma habitação pessoal ou a rede
de um condomínio com muitas habitações. Dentro de cada habitação podem existir imensos
dispositivos (sensores, atuadores e aplicações), cada um terá de ser identificado e possuir a
informação necessária ao seu funcionamento na base de dados da rede. Todos os dispositivos
possuem um endereço individual e único na rede, contudo devem pertencer a um grupo ou a vários
grupos dentro dessa rede. Isto é útil para definir cenários e ou facilitar o funcionamento da rede
evitando enviar comandos individuais, enviando para vários de uma só vez. Os dispositivos podem
ainda possuir vários Datapoints consoante as suas funções e necessidades da rede.
Os Datapoints são aplicações para os mais diferentes tipos de dispositivos, o tipo de um
Datapoint define o tipo de aplicação para o qual foi definido. Os Datapoints são normalizados para
garantir a compatibilidade de dispositivos similares de diferentes fabricantes. Esta normalização
inclui exigências relativas ao formato dos dados e da estrutura dos Objetos de Grupo, bem como das
funções dos sensores e dos atuadores estas normas são definidas pela Organização KNX. À
combinação de vários tipos de Datapoints normalizados é dominado por bloco funcional de um
dispositivo ou grupo de dispositivos. Os Datapoints podem ser atribuídos a um só dispositivo ou a
vários dispositivos, contudo é de ressalvar que um endereço de grupo não pode possuir mais que um
Datapoint.
Os AddressGroup ou endereços de grupo são utilizados para definir um endereço de um
dispositivo ou comum a vários dispositivos da rede e possibilitar o comando de vários dispositivos ao
mesmo tempo e com isso por vezes e se for de interesse definir cenários de funcionamento. Devido
a necessidade de relacionar os diferentes endereços de grupo com os diferentes dispositivos foi
criada uma tabela com o nome de dispositivoaddressgroup, esta necessidade surge por pelo facto de
um grupo possuir muitos dispositivos e ainda porque um dispositivo poder pertencer a vários grupo.
A parte de controlo da rede KNX é efetuada pelas funções de escrita e leitura criadas no
âmbito deste projeto. Para isto ser possível foi necessário combinar as funções criadas com dois
ficheiros Batch (comandos )e o programa Calimero anteriormente explicado. Aos ficheiros PHP cabe
a tomada de decisões mediante as ações do utilizador, depois das decisões tomadas o programa PHP
executa o comando de escrita ou de leitura. No comando de escrita e de leitura o programa em PHP
aatravés das suas funções (exec, escapeshellarg, etc.) executa o ficheiro Batch e passa-lhe como
argumentos os dados necessários para a execução dos comandos. Após a execução do ficheiro
Batch, ele irá passar como argumentos os argumentos anteriormente transmitidos a este. Os
argumentos serão passados ao Calimero e é feito o pedido que este execute o comando pretendido.
O controlo por parte do Calimero é especificamente a execução da função ProcComm que ao
receber os argumentos executa os comandos recebidos para os dispositivos definidos nos
argumentos passados pelo ficheiro Batch. O que esta função faz basicamente é converter os
dados passados como argumento em dados interpretados pela rede KNX ou seja telegramas KNX
interpretados pela rede e por um ou vários dispositivos a que se dirige o comando. Os argumentos
passados são:
Endereço IP do computador;
Endereço IP da gateway da rede KNX;
Comando a executar (write ou read);
Porto de comunicação;
Codificação do Datapoint;
Estado futuro;
Endereço de grupo.
É assim que é feito e executado o controlo do sistema desenvolvido nesta dissertação,
concebido com a interação entre o PHP, os Batch files e o Calimero.
54 Introdução
54
Capítulo 5
Teste e avaliação do sistema
5.1 Cenários de teste
O cenário de teste teve o intuito de testar e verificar a compatibilidade entre o sistema e o
protocolo KNX e o seu desempenho. Os cenários de testes criados foram divididos em dois grandes
grupos:
1. Base de dados:
Teste de habitação;
Teste de utilizadores;
Teste de endereço de grupos;
Teste de dispositivos;
Teste de Datapoint;
Teste de relação entre endereços de grupo e Datapoints;
2. Controlo:
Teste de 2 habitações numa mesma rede;
Teste para utilizadores com diferentes perfis;
Como só havia um quadro (rede KNX) foram mapeadas duas habitações no mesmo quadro.
Devido ao limitado número de saídas e à necessidade de definir diferentes tipos de perfis de
utilizador foi necessário utilizar as mesmas saídas físicas para as duas habitações pois o módulo
possuía apenas quatro saídas. Mesmo mapeando os mesmos endereços físicos, os dispositivos
dispõem de endereços virtuais e na base de dados independentes. Caso fosse acrescentado mais um
módulo apenas seria necessário mudar os endereços físicos na base de dados e o sistema continuaria
a funcionar mas já com saídas diferentes e independentes. Como o intuito era testar o software e a
base de dados não fazia diferença mapear endereços físicos iguais pois o que poderia acontecer era
mandar ligar ou desligar duas vezes o mesmo dispositivo isto sem qualquer consequência física
(curto-circuito) e nem na base de dados. Todos os testes efetuados tiveram em linha de conta o
facto de os dispositivos além de serem os mesmos fisicamente, mapeavam endereços diferentes na
base de dados. Todas as atividades e testes foram registados na base dados como seria expectável
numa habitação em uso. Serão apresentados os dados referentes às duas habitações criadas e o
cruzamento dos dados para provar a viabilidade do sistema.
5.2 Base dados
Para efetuar os testes da base dados teriam de se criar cenários que representassem situações
gerais e que provassem que o sistema de gestão de base de dados funcionaria mesmo em casos
extremos. Não foi necessário um teste tão exaustivo; contudo, foi criado um cenário de teste que
garantisse que a base dados era compatível com qualquer rede. O cenário foi criar na base de
dados:
Duas habitações para garantir que o sistema tanto podia possuir uma como N habitações;
Cinco utilizadores para que fosse garantido que se pudesse no limite ter N utilizadores e
para garantir os 5 perfis diferentes com as cinco permissões diferentes;
Erro! A origem da referência não foi encontrada. 55
Dois Datapoints para garantir que o sistema podia possuir no limite N Datapoints.
Oito dispositivos, quatro da primeira habitação e quatro da segunda habitação, isto para
garantir que o sistema funcionaria no limite com N dispositivos, salvaguardava a utilização das
quatro saídas e as diferentes permissões dos diferentes utilizadores;
Doze endereços de grupo, oito dos quais endereços dos oito dispositivos, dois endereços de
grupo de dois grupos de dois dispositivos nas diferentes habitações e por fim dois grupos de todos os
dispositivos de cada habitação;
Vinte relações entre dispositivos e endereços de grupo (dispositivoaddressgroup):
Oito devido aos endereços de grupo individuais;
Quatro dos dois endereços de grupo de dois dispositivos;
Oito dos dois endereços de grupo de quatro dispositivos;
Os testes efetuados serão demonstrados por imagens que são print screens da base dados e das
diferentes visões criadas pela camada View do projeto desenvolvido.
Habitação:
Figura 47: Pesquisa na base de dados na tabela habitações.
Como se pode verificar na figura da base de dados, esta possui a mesma informação que é
recebida pelo sistema quando é feita uma pesquisa pelas habitações existentes, o que demonstra a
coerência dos sistemas e com os dados anteriormente mencionados.
56 Introdução
56
Figura 48: Pesquisa à base de dados por habitações.
Utilizadores:
Os utilizadores são as pessoas que irão usar o sistema; a cada tipo de utilizador está associado
um tipo de perfil, uma identificação pessoal e da base de dados como poderemos verificar nas
imagens seguintes.
Figura 49: Pesquisa de utilizadores efetuada na base de dados.
Como podemos verificar existem diferentes tipos de utilizadores, todos os endereços de e-
mail, username, telemóvel, idUtilizador e contribuinte são únicos pois é exigido pelo sistema e pela
base de dados.
Erro! A origem da referência não foi encontrada. 57
Figura 50: Pesquisa de utilizadores do sistema efetuada à base de dados.
Como se pode verificar os dados nas duas tabelas da base de dados e sistema são os mesmos,
confirmando-se assim a coerência no sistema.
Datapoints:
Os Datapoints são importantes ao sistema pois são eles que possuem a informação necessária
para implementar as funções que os mesmos representam. Como se pode verificar pela figura 51 só
existem dois Datapoints (funções), embora para o sistema a implementar e devido às suas
limitações só é necessário o primeiro Datapoint.
Figura 51: Pesquisa de Datapoints efetuada na base de dados.
A figura 52 representa uma pesquisa na base de dados por Datapoints e confirma a coerência
entre o sistema e a base de dados.
58 Introdução
58
Figura 52: Pesquisa de Datapoints efetuada à base de dados pelo sistema.
Dispositivos:
Os dispositivos representados na figura 53 pertencem à mesma rede KNX mas a habitações
diferentes. Como podemos verificar pelo idhabitacao os primeiros 4 dispositivos pertencem à
primeira habitação e os últimos quatro à segunda habitação.
Figura 53: Pesquisa por dispositivos na base de dados.
Como se pode verificar todos os dispositivos possuem um endereço individual único constituído
pelas componentes área, linha e número do dispositivo como exigido pelo protocolo KNX. A
componente estadoActual representa o estado atual do dispositivo na base de dados; contudo, tal
não implica que fisicamente o dispositivo esteja no mesmo estado. A cada escrita ou leitura
efetuada pelo sistema o estado será atualizado pelo mesmo e será garantido que o seu estado é
aquele que foi executado pelo sistema. A figura 54 confirma a coerência dos dados e da pesquisa
obtida nos dois sistemas.
Erro! A origem da referência não foi encontrada. 59
Figura 54: Pesquisa efetuada a base de dados pelo sistema à procura de todos os dispositivos.
Pode se constatar-se que os dados são coerentes, assim garantido-se o compromisso de
coerência dos dois sistemas.
Addressgroup:
O addressgroup como já referido anteriormente é um endereço de grupo que pode estar
associado a varios dispositivos de uma rede KNX. O sistema implementado possui para cada
habitação quatro grupos de um elemento, um de dois elementos e por fim um com todos os
elementos. Como podemos verificar na figura 55 existem 6 grupos para cada habitação, num total
de doze habitações.
Figura 55: Pesquisa efetuada a base de dados à procura de todos os endereços de grupo.
60 Introdução
60
O campo idHabitacao identifica a que habitação pertence cada endereço de grupo, o código o
endereço físico na rede KNX e como podemos constatar são seis e representam os mesmos
endereços físicos para as duas habitações como já foi referido. Como o único módulo que a rede
KNX possuía era um módulo para controlo de quatros dipositivos a única função possível era on/off,
daí o Datapoint ser sempre o mesmo em todos os dispositivos. Por fim, como se pode verificar, a
coluna nDispositivos apresenta os grupos anteriormente referidos, que totalizam 12 endereços de
grupo.
Figura 56: Pesquisa efetuada a base de dados pelo sistema à procura de todos os endereços de grupo.
Dispositivoaddressgroup:
A dispositivoaddressgroup é o nome dado à relação entre um endereço de grupo e um
dispositivo. Esta tabela foi criada devido à necessidade de representação das relações entre os
diferentes dispositivos e os endereços de grupo e também devido à sua cardinalidade N:M. Ou seja,
para um dispositivo pode pertencer a N grupos e um endereço de grupo possuir M dispositivos; daí a
necessidade da criação desta tabela. Como cada habitação possui quatro grupos individuais, um de
dois e um de quatro, isto totaliza dez relações por habitação e vinte no total como se pode verificar
na figura 57.
Erro! A origem da referência não foi encontrada. 61
Figura 57: Pesquisa na base de dados por dispositivoaddressgroup.
Figura 58: Pesquisa por dispositivoaddressgroup na base de dados efetuada pelo sistema.
Como se pode verificar mais uma vez os dados são coincidentes e representam as
funcionalidades e necessidades do sistema implementado. Toda a base de dados é coerente com o
sistema desenvolvido e com as necessidades de configuração e das suas atividades e assim sendo
62 Introdução
62
pode se concluir-se que o sistema está bem implementado a nível de base de dados. Pode-se ainda
concluir que a base de dados poderia suportar um sistema bem maior e muito mais abrangente,
correspondendo às espectativas.
5.3 Configuração da rede IP e configuração KNX
Para o sistema desenvolvido funcionar em conjunto com o Calimero e por conseguinte comunicar com a
rede KNX foi necessário realizar algumas configurações. As configurações devem ser efetuadas em:
Propriedades de Ligação de Área Local no campo Protocolo de IP versão IPV4, isto no computador que
comunica com a rede e no programa Calimero. O computador que comunicar com o sistema tem de possuir
um IP alternativo para conseguir executar a aplicação Calimero. As configurações são:
IP address: 192.168.0.20;
Netmask: 255.255.255.0;
A figura 59 demonstra as configurações efetuadas e onde as fazer.
Figura 59: Configuração do IP alternativo do computador para funcionar com o Calimero.
Ordem dos passos a seguir:
1. Propriedades de ligação de Área Local;
2. Selecionar o Protocolo IP versão 4;
3. Clicar em propriedades;
4. Clicar na aba configuração alternativa;
5. Inserir o endereço IP: 192.168.0.20;
6. Inserir a Netmask: 255.255.255.0;
7. Por fim confirmar os dados e sair.
Assim fica configurado o computador onde o sistema for instalado.
Para comunicar com a rede KNX o Calimero ou as suas funções devem ser executadas com o
endereço IP 192.168.0.222 e com o porto 3671 para que o módulo da rede KNX (Módulo ABB IPRS/S
2.1) consiga receber as tramas KNX e enviá-las para o dispositivo a que se destinam.
Erro! A origem da referência não foi encontrada. 63
5.4 Avaliação funcional
Serão demonstradas e avaliadas as funcionalidades do sistema, tais como a gestão de
utilizadores, demonstrações de controlo individual e de grupo dos dispositivos. Como anteriormente
referido existem diferentes tipos de utilizadores, pelo que serão apresentadas de forma gradual as
funcionalidades que cada grupo de utilizadores usufrui, para que seja mais fácil a sua apresentação
e compreensão. Os perfis existentes dividem-se em cinco tipos são eles o técnico, o administrador,
o utilizador de nível um, o utilizador de nível dois e o utilizador de nível três. A cada perfil estão
associadas diferentes tipos de permissões como:
Técnico este perfil tem todo o tipo de permissões possíveis no sistema.
Administrador este perfil tem todo o tipo de permissões de controlo na sua habitação
contudo não é permitida a execução de todos os comandos na base de dados.
Utilizador 1 – este perfil apenas pode comandar as lâmpadas individualmente e a edição dos
seus dados enquanto utilizador.
Utilizador 2 – este perfil apenas pode comandar as lâmpada 1 e 2 individualmente e a
edição dos seus dados enquanto utilizador.
Utilizador 3 – este perfil apenas pode comandar o sistema físico, não tem acesso a qualquer
função do sistema desenvolvido.
De seguida serão demonstradas as funcionalidades do sistema de gestão de domótica para os
diferentes perfis de utilizador.
A figura 60 é a página que aparece caso o utilizador tente aceder a uma página que implique
que se tenha efetuado o login.
Figura 60: Página de login.
Utilizadores do tipo util3:
Este tipo de utilizador não tem acesso a nenhuma página criada. Este perfil foi criado para
teste e para definição de vários tipos de perfis para as mais variadas funções possíveis do sistema,
podendo vir a ganhar permissões em desenvolvimentos futuros. Como este perfil não possui
qualquer tipo de permissão mesmo após ter feito login, quando tentar aceder a qualquer
funcionalidade do sistema a página que aprece é a da figura 61.
64 Introdução
64
Figura 61: Página de acesso interdito.
Utilizadores do tipo util2:
Utilizador do tipo 2 (util2) é um perfil de utilizador que já possui permissão para o controlo das lâmpadas
1 e 2 de forma individual, pertencentes à sua habitação. A figura 62 demonstra a página de acesso.
Figura 62: Página de controlo para utilizadores do tipo util2.
Utilizadores do tipo util1:
Utilizador do tipo 1 (util1) é um perfil de utilizador que já possui permissão para o controlo de
todas as lâmpadas de forma individual, pertencentes à sua habitação. A figura 63 demonstra a sua
página de acesso.
Erro! A origem da referência não foi encontrada. 65
Figura 63: Página de controlo para utilizadores do tipo util1.
Utilizadores do tipo admin:
Utilizador do tipo administrador (admin) é um perfil de utilizador que já possui permissão para
o controlo de todas as lâmpadas de forma individual ou o grupo 1_2 ou grupo 1_2_3_4 que
pertencentes à habitação onde foi inserido o seu perfil. A figura 64 demonstra a sua página de
acesso.
Figura 64: Página de controlo para utilizadores do tipo admin.
O utilizador pode ainda aceder à base de dados e editar o seu perfil de utilizador e dos
utilizadores da sua rede como podemos verificar nas imagens 64:
66 Introdução
66
Figura 65: Página de acesso a base de dados para utilizadores do tipo admin.
Após aceder à página basta clicar no ícone de editar e será reencaminhado para a página de
edição do seu perfil para editar os seus dados com podemos ver na figura 66.
Figura 66: Página de edição do utilizador do tipo admin, Luisa.
Utilizadores do tipo técnico:
O utilizador do tipo técnico tem permissão para controlar todos os dispositivos de todas as
casas pertencentes à rede KNX, assim como a possibilidade de gerir toda a base de dados (editar,
pesquisar, eliminar e adicionar) da mesma rede. A apresentação deste perfil limita se à
apresentação básica das páginas principais, inicialmente a parte de controlo e por fim a base de
dados. A figura 67 é a imagem de controlo apresentada ao utilizador do tipo técnico, que lhe
permite escolher a casa a controlar, como se pode ver.
5.5 Controlo
Erro! A origem da referência não foi encontrada. 67
Figura 67: Página de controlo para utilizadores do tipo técnico e escolha da habitação a controlar.
Como se pode verificar na imagem da planta da habitação acima, a habitação ainda não está
identificada e é dada a possibilidade do utilizador escolher a habitação a controlar. A figura 68
representa a escolha da habitação 1.
Figura 68: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação1.
Como se pode verificar na planta da casa já aparece a identificação neste caso habitação 1: agora
será apresentada a imagem quando a escolha é a habitação 2.
68 Introdução
68
Figura 69: Página de controlo para utilizadores do tipo técnico depois de escolher a habitação2.
Os comandos que serão de seguida apresentados representam os comandos enviados pelo
controlador para o Calimero comunicar com a rede KNX e executar os pedidos do utilizador:
Lâmpada 1 – on ( 192.168.0.20 3671 1.001 0.0.1 on 192.168.0.222), off ( 192.168.0.20 3671
1.001 0.0.1 off 192.168.0.222);
Lâmpada 2 - on ( 192.168.0.20 3671 1.001 0.0.2 on 192.168.0.222), off ( 192.168.0.20 3671
1.001 0.0.2 off 192.168.0.222);
Lâmpada 3 - on ( 192.168.0.20 3671 1.001 0.0.3 on 192.168.0.222), off ( 192.168.0.20 3671
1.001 0.0.3 off 192.168.0.222);
Lâmpada 4 - on ( 192.168.0.20 3671 1.001 0.0.4 on 192.168.0.222), off ( 192.168.0.20 3671
1.001 0.0.4 off 192.168.0.222);
Lâmpada 1_2 - on ( 192.168.0.20 3671 1.001 0.0.5 on 192.168.0.222), off ( 192.168.0.20
3671 1.001 0.0.5 off 192.168.0.222);
Lâmpada 1_2_3_4 - on ( 192.168.0.20 3671 1.001 0.0.6 on 192.168.0.222), off (
192.168.0.20 3671 1.001 0.0.6 off 192.168.0.222);
Os comandos representados acima são os mesmos para a habitação 1 e 2 pois como já referido
os dispositivos possuem os mesmos endereços físicos. Em cada lâmpada são apresentados os dois
comandos possíveis (on e off).
5.6 Base de dados
As figuras seguintes apresentam as diferentes possibilidades que o utilizador do tipo técnico poderá
usufruir para configurar a base de dados: contudo, apenas serão apresentadas as principais páginas
de cada opção.
Erro! A origem da referência não foi encontrada. 69
Habitação:
Figura 70: Página da base de dados para editar, adicionar, pesquisar e eliminar habitação.
Utilizador:
Figura 71: Página da base de dados para editar, adicionar, pesquisar e eliminar utilizadores
Dispositivo:
70 Introdução
70
Figura 72: Página da base de dados para editar, adicionar, pesquisar e eliminar dispositivos.
Datapoint:
Figura 73: Página da base de dados para editar, adicionar, pesquisar e eliminar Datapoints.
AddressGroup:
Erro! A origem da referência não foi encontrada. 71
Figura 74: Página da base de dados para editar, adicionar, pesquisar e eliminar endereços de grupo.
DispositivoAddressGroup:
Figura 75: Página da base de dados para editar, adicionar, pesquisar e eliminar relações entre um
dispositivo e um endereço de grupo (dispositivoaddressgroup).
72 Introdução
72
Capítulo 6
Conclusões
6.1 Conclusões
O objetivo desta dissertação era desenvolver um sistema a integrar na linha de produtos da
empresa NextToYou e, deste ponto de vista, constituiria uma evolução desses produtos (melhoria do
ponto de vista de funcionalidades oferecidas). A evolução que foi proposta foi a criação de um
sistema de gestão de domótica para a rede KNX já existente.
Os objetivos que foram propostos para esta dissertação foram completamente cumpridos com
sucesso e ainda garantindo a fiabilidade do sistema de gestão de domótica.
Foi criado um modelo de base dados que ao longo do processo de criação foi sofrendo várias
alterações, mediante os testes efetuados, conforme se iam descobrindo as falhas de conceção do
modelo relativamente ao protocolo KNX e às exigências da rede a implementar. Pode se dizer que o
processo exigiu um estudo aprofundado das exigências e necessidades do protocolo KNX, os tipos de
endereçamento e como o fazer, como atribuir funcionalidades aos dispositivos e de que forma se
tinham de processar. O modelo implementado teria de garantir que poderia ser implementado
numa qualquer rede KNX independentemente do seu tamanho e complexidade. Concluído este
processo e efetuados os testes necessários pode-se concluir que o modelo criado pode suportar uma
qualquer rede que siga o protocolo KNX.
A escolha da base de dados MySQL correspondeu às necessidades porque permitia a utilização
do modelo relacional concebido para o modelo de base de dados e demonstrou elevada
consistência, elevado desempenho, confiabilidade, para além de muito simples de utilizar.
A arquitetura Model-View-Controller revelou-se uma ótima escolha pois o trabalho foi
desenvolvido de forma modular. Isto permitiu que nunca tivesse de se parar o desenvolvimento do
sistema por qualquer problema, isto porque se ocorresse um qualquer problema nos diferentes
módulos podia sempre desenvolver um dos outros módulos sem o problema de compatibilidades e
ou erros pois os módulos eram independentes. Isto permitiu ganhar tempo e desenvolver uma
solução que pudesse ser alterada e evoluir em qualquer altura devido à sua modularidade. Esta
característica também ajudou na fase em que foi necessário detetar e corrigir erros pois como eram
módulos independentes era mais fácil de chegar ao erro e o poder corrigir. Esta modularidade
permitiu que facilmente se pudessem fazer alterações na camada View, para que esta se fosse
adequando e ficando com melhor apresentação e promovesse a usabilidade e captasse o interesse
do cliente. Esta arquitetura também permitiu que o projeto ficasse em aberto para qualquer
evolução em qualquer camada que o constitui, o que faz desta arquitetura de software uma boa
base para um projeto de software igual ou idêntico.
O sistema de gestão da base de dados foi plenamente conseguido ele permitia que o utilizador
sem formação alguma em base de dados conseguisse preencher a informação que o sistema de
gestão precisasse e ainda editar, pesquisar e eliminar qualquer dado da base dados sempre que não
violasse as restrições (do tipo de atributos, chaves estrangeiras, campos not nul, etc.) impostas
aquando da criação da base de dados. Basicamente pode-se se fazer quase tudo o que se faz na
base de dados do projeto só que de uma forma mais simples e intuitiva, o utilizador apenas está
limitado pelo facto de não poder mudar o modelo da base de dados e seus atributos.
A navegabilidade do sistema construído é simples e muito intuitiva tanto na gestão da base de
dados como na parte de controlo. Foi conseguido o objetivo de construir um sistema que
Erro! A origem da referência não foi encontrada. 73
promovesse a usabilidade, que fosse simples de utilizar, fosse útil e por fim eficaz ou seja com
poucos cliques executar uma determinada funcionalidade.
A criação do sistema de gestão da rede KNX foi conseguido na sua plenitude visto que no final
da dissertação, o sistema conseguia atuar sobre os quatro atuadores que a rede possuía e ler dos
quatro sensores que existiam na rede. Como foi desenvolvido segundo a arquitetura de software
modular e visto que as funcionalidades de escrever nos atuadores e ler dos sensores estão
implementadas e que a comunicação com a rede KNX se resume às funcionalidades de escrita e
leitura. Visto isto pode-se concluir que seria simples adicionar mais e diferentes módulos e
conseguir o completo controlo desse sistema pois teria pouco de novo a acrescentar visto já se
conseguir ler e escrever nos dispositivos existentes.
Porque o sistema possui funcionalidades que em caso de uso indevido poderia comprometer o
normal funcionamento do sistema foram criadas restrições de uso a certas funcionalidades a alguns
utilizadores. Para que a segurança do sistema e dos seus dados (dados da rede KNX e dos
utilizadores) não fosse comprometida, foram criados vários perfis de utilizador para diferentes tipos
de utilização e criadas restrições de acesso a determinadas funções e páginas segundo esses
diferentes tipos de perfis.
6.2 Desenvolvimentos futuros
O sistema de gestão de domótica desenvolvido foi um pequeno passo contudo importante para
o que se pode fazer no campo da gestão de domótica. Tendo como ponto de partida o que foi até
então feito e estudado poder-se-á chegar a um sistema mais complexo e bem mais completo. Os
próximos passos seriam adicionar mais dispositivos ao sistema mas com diferentes funcionalidades
para tornar o sistema mais abrangente e dotando-o da capacidade de ter um exemplo de software
para cada tipo de módulo existente na domótica KNX. Seria também de apostar na criação de mais
funcionalidades em Javascript para tratamento de formulários e promover a interatividade entre o
sistema e utilizador.
Com o âmbito de comercializar o produto seria necessário implementar mais segurança no
sistema (defesa contra intrusão e controlo indevido) e posteriormente criar um sistema para o
utilizador poder fazer o acesso remoto do sistema através da Internet.
O programa ETS4 concebido pela KNX para configurar uma rede KNX após a configuração da
rede cria um documento XML. Seria interessante e muito útil criar um módulo software que
convertesse esse ficheiro em dados que seriam úteis ao sistema e se possível que apenas através
deste ficheiro fosse possível criar a base de dados fundamental à rede e com a informação
necessária ao funcionamento de todo o sistema de gestão de domótica KNX. Este passo seria um
parsing de XML para a linguagem MySQL . Depois de todas estas melhorias o produto já podia ser
comercializado pois já ofereceria as funcionalidades que os sistemas de gestão de domótica
oferecem atualmente.
Referências
[1] Ciberdúvidas da Língua Portuguesa. Disponível em http://www.ciberduvidas.com/
/glossario.php. Acesso em 20/Maio/2008.
[2] Luís Grave Rodrigues, “Regras de escrita e gramática”. Disponível em
http://rprecision.blogspot.com/2008/02/regras-de-escrita-e-de-gramtica.html. Acesso
em 20/Maio/2008.
[3] “Regras para a Apresentação de Dissertações de Cursos de Mestrado da FEUP”, Faculdade
de Engenharia da universidade do Porto, Junho de 1995. [4] The EIB Association: The EIBA Handbook Series – Release 3.0, Brussels, 1998
[5] X-10, “Wireless solutions for 230 volts countries”. Disponível em
http://www.x10europe.com. Acesso em Junho /2011.
[6] The Konnex Association: KNX, The World’s First Open Standard For Home and Building
[7] Control – System Architecture, Brussels, July 2004.
[8]
[9] Wolfgang Kastner and Bernd Thallner: “A GPL Linux Device Driver for the EIB”, Technische
Universität Wien Institut für Rechnergestützte Automation, Treitlstraße 1, A-1040 Wien
[10] S. Avelar, “Protocolo EIB KNX”, Instituto Superior de Engenharia do Porto, Dezembro,
2007
[11] IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements Specifications.
[12] Pedro Miguel de Miranda Fernandes, “Aplicações Domóticas para Cidadãos com Paralisia
Cerebral”, Tecnologia Domótica, Universidade de Aveiro, 2001.
http://portal.ua.pt/thesaurus/default1.asp?OP2=0&Serie=0&Obra=28&H1=1&H2=0 Acesso em Junho
/2011 .
[13] João Pedro Santos Silva, “Aplicação de Interface Com Sistema Domótico EIB”, Instituto
Superior Técnico
[14] Diana Sobreiro da Costa Palma, “FEUP KNX, Domótica KNX/EIB de Baixo Custo”, Faculdade
de Engenharia da Universidade do Porto
[15] Institute of Automation, Automation Systems Group - Calimero - EIBnet/IP Tunnelling
[16] (and more) for Java; Acedido pela última vez em 2009-06-28;
[17] URL:https://www.auto.tuwien.ac.at/a-lab/calimero.html;
[18] Boris Malinowsky, Georg Neugschwandtner, Wolfgang Kastner, “Calimero: Next
[19] Generation”, Novembro 2008;
[20] www.knx.org/pt. Acesso em Junho /2012.
[21] www.enei.net/ Acesso em Junho /2012.
[22] http://www.maujor.com Acesso em Junho /2012.
[23] http://www.w3schools.com Acesso em Junho /2012.
[24] http://www.domus.areadeservico.com/ Acesso em Junho /2012.
[25] http://www.logichome.pt/ Acesso em Junho /2012.
[26] http://www.ihome.pt/ Acesso em Junho /2012.
[27] http://pt.wikipedia.org Acesso em Junho /2012.
[28] http://www stackoverflow.com Acesso em Junho /2012.