FEUP KNX Domtica KNX/EIB de Baixo Custo

2007 / 2008

Departamento de Engenharia Electrotcnica e de Computadores

Mestrado Integrado em Engenharia Electrotcnica e de Computadores
Faculdade de Engenharia da Universidade do Porto

Diana Sobreiro da Costa Palma ee05241

http://www.feupknx.pt.vu

Faculdade de Engenharia da Universidade do Porto

FEUP KNX Domtica KNX/EIB de Baixo Custo

Diana Sobreiro da Costa Palma

Dissertao submetida para a satisfao parcial dos requisitos de grau de mestre em Engenharia Electrotcnica e de Computadores

Dissertao realizada sob a orientao do Professor Doutor Mrio de Sousa, do Departamento de Engenharia Electrotcnica e de Computadores da Faculdade de Engenharia da Universidade do Porto

Porto, Maro 2008

Resumo
A implantao de um sistema de automao numa casa ou num edifcio, permite aumentar o conforto, segurana e obter uma melhor gesto de gastos de energia. Por exemplo, uma luz s liga se for necessrio e no ocorre o problema de esquecimento de luzes ligadas. Hoje em dia, os sistemas utilizados para automatizar um edifcio tm uma hierarquia distribuda, ao contrrio dos sistemas de controlo industriais cuja lgica de controlo se encontra centralizada nos autmatos programveis. Um sistema de automao de um edifcio assenta numa rede de comunicao de dados sobre a qual tambm possvel realizar tarefas de gesto da mesma rede. Para interligar todos os dispositivos de uma casa necessrio utilizar uma rede com alguma complexidade. Um dos protocolos de rede mais utilizados em sistemas de automao de casas ou edifcios o European Installation Bus (EIB/KNX). Utiliza o meio fsico proprietrio Twisted Pair (TP), mas este protocolo permite a utilizao do mesmo sob RS-232, USB, RF e Ethernet. Com o aumento do uso do protocolo de rede TCP/IP sob Ethernet em edifcios, grande a vantagem de utilizar o backbone da rede TCP/IP para ligar a rede KNX/EIB e assim aproveitar a cablagem j existente. Com esta soluo, poder controlar uma casa remotamente utilizando a Internet, deixa de ser uma utopia. O objectivo deste trabalho tornar o projecto Domoitech realizado em KNX/EIB, compatvel com redes KNX/EIB sob TCP/IP Ethernet. Sero estudadas possveis arquitecturas e ser criado um servidor que efectua a interface entre uma rede TCP/IP Ethernet e a rede KNX/EIB implementada no Domoitech. A norma KNX/EIB, inclui uma parte que especifica como este servidor deve ser criado. Essa parte tem o nome de KNXnet/IP e um protocolo que permite o envio de tramas KNX/EIB sob o TCP/IP. O servidor KNXnet/IP a ser criado, tem a vantagem de ser multi-plataforma e a aplicao do mesmo em sistemas embebidos de baixo custo, torna a soluo muito econmica. Sero efectuados testes e validao do servidor KNXnet/IP depois da implementao do mesmo.

FEUP KNX 2008

ii

Abstract
The deployment of a system of automation in a house or a building can increase the comfort, safety and better management of spending power. For example, a light turn on only if necessary and is not the problem of forgetfulness of lights on. Today, the systems used to automate a building have a hierarchy distributed, as opposed to industrial control systems whose logic of control is centralized in a programmable logic controller (PLC). A system automation of a building based on a data communication network, on which it is also possible to perform management tasks on the same network. To connect all devices of a house is necessary to use a network with some complexity. One of the Network Protocols used in most systems automation of houses or buildings, is the European Installation Bus (KNX/EIB). Uses the media owner Twisted Pair (TP), but the network protocol allows the use of even under RS232, USB, Ethernet and RF. With the increase in the use of the protocol TCP/IP on Ethernet in buildings, it is a great advantage of using the backbone of the TCP/IP network to connect the network KNX/EIB and thus takes up the existing wiring. With this solution, able to manage a home remotely using the Internet, ceases to be a dream. The objective of this work is to make the project Domoitech held in KNX/EIB, compatible with networks KNX/EIB under TCP/IP Ethernet. Will be studied possible architectures and will be set up a server that performs the interface between a TCP/IP Ethernet network and KNX/EIB implemented in Domoitech. The standard KNX/EIB includes a section that specifies how this server must be created. This piece is named KNXnet/IP and is a protocol that allows the transmission of frames KNX/EIB under the TCP/IP. The server KNXnet/IP to be created, has the advantage of being multiplatform and the application of it in embedded systems at low cost, makes the solution very economic. After the implementation of the server KNXnet / IP, tests and validation will be carried out.

FEUP KNX 2008

iii

Prefcio
Os sistemas de automao de edifcios, mais conhecidos por sistemas Domticos, tm um custo elevado. At o sistema mais simples que utiliza um protocolo de rede elementar como o X-10, tem um custo que no acessvel a todos os bolsos. Por exemplo, um simples interruptor de parede que funciona em X-10, tem um custo superior a 40. Quando comparado com o KNX/EIB, o X-10 o protocolo pobre para Domtica e se um simples interruptor X-10 caro, um interruptor KNX/EIB exageradamente caro (custo superior a 70). A motivao para a realizao desta dissertao surgiu na ideia de dar seguimento ao projecto Domoitech que consistiu em criar um sistema Domtico de baixo custo e compatvel com outros equipamentos que existam no mercado. O protocolo de Domtica utilizado no Domoitech foi o KNX/EIB Ao longo da realizao deste trabalho, o contacto com o mercado foi mantido sempre, para uma constante actualizao sobre as novidades e acompanhar o crescimento e necessidades dos sistemas domticos no mercado nacional.

Em primeiro lugar gostaria de agradecer minha famlia, especialmente aos meus pais, por terem estado sempre presentes e me terem apoiado ao longo deste percurso escolar. Ao orientador, professor Mrio de Sousa agradeo a sua disponibilidade e orientao ao longo desta dissertao. Aos meus amigos e colegas que me apoiaram neste percurso universitrio e que partilharam comigo as vivncias mais importantes e estiveram sempre ao meu lado.

FEUP KNX 2008

iv

ndice
1 Introduo ...........................................................................................................13 1.1 1.2 1.3 2 Protocolos de Domtica ..............................................................................14 Domoitech ....................................................................................................16 Objectivos ....................................................................................................18

Protocolo KNX/EIB ............................................................................................19 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.4.1 2.4.4.2 2.5 KNX/EIB Handbook.....................................................................................22 Arquitectura .................................................................................................24 Modos de configurao........................................................................26 Topologia .............................................................................................28 Formato da trama KNX/EIB................................................................30 Meio Fsico ..................................................................................................31 Par entranado ....................................................................................31 Rede elctrica.......................................................................................33 Rdio Frequncia e Infravermelhos ....................................................34 Ethernet................................................................................................35 Comunicao ...............................................................................................36 Camada de Ligao Lgica .................................................................36 Camada de Rede ..................................................................................37 Camada de Transporte ........................................................................38 Camada de Aplicao ..........................................................................38 Servios ............................................................................................39 EIS....................................................................................................42

Interfaces Standard de Comunicao ..........................................................45

FEUP KNX 2008

2.5.1 2.5.1.1 2.5.2 2.5.2.1 2.5.2.2 2.6 3

Physical External Interface..................................................................45 Protocolo FT 1.2..............................................................................48 External Message Interface .................................................................51 Mensagens cEMI na camada de ligao lgica ..............................52 Mensagens cEMI de gesto e configurao ....................................56

ETS...............................................................................................................59

KNXnet/IP ...........................................................................................................63 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Arquitectura .................................................................................................64 Mdulos do KNXnet/IP ................................................................................66 Ncleo ..........................................................................................................69 Gesto de dispositivos..................................................................................71 Tunnelling ....................................................................................................72 Routing.........................................................................................................74 Resumo dos servios do KNXnet/IP.............................................................75 Formato das tramas KNXnet/IP ..................................................................78

Anlise da arquitectura.......................................................................................79 4.1 4.1.1 4.2 4.2.1 4.3 Arquitectura Domoitech com KNXnet/IP ....................................................80 Projecto de Hardware..........................................................................80 Arquitectura Hbrida ...................................................................................85 Projecto de Hardware..........................................................................86 Comparao de arquitecturas .....................................................................87

Implementao do Servidor KNXnet/IP.............................................................91 5.1 5.2 5.2.1 Arquitectura do Software.............................................................................91 Validao e Resultados................................................................................95 Testes aos servios do Ncleo..............................................................97

FEUP KNX 2008

vi

5.2.2 5.2.3 6

Testes aos servios do Tunneling.......................................................100 Testes aos servios da Gesto de Dispositivos ..................................102

Concluso ..........................................................................................................103 6.1 Desenvolvimentos futuros ..........................................................................104

Referncias ................................................................................................................106 Apndice 1 .................................................................................................................107

FEUP KNX 2008

vii

ndice de Figuras
Ilustrao 1 - Diagrama de blocos da estrutura de hardware Domoitech.............................................16 Ilustrao 2 Modelo do Sistema KNX .................................................................................................22 Ilustrao 3 - Modelo KNX/EIB .............................................................................................................24 Ilustrao 4 - Estrutura de uma rede KNX/EIB .....................................................................................29 Ilustrao 5 - Formato Trama EIB.........................................................................................................30 Ilustrao 6 - Sinal balanceado entre dispositivos KNX/EIB.................................................................31 Ilustrao 7 - Protocolo CSMA/CA ........................................................................................................32 Ilustrao 8 - Codificao sinal pela rede elctrica ..............................................................................34 Ilustrao 9 Servios da camada de ligao lgica ............................................................................36 Ilustrao 10 Interface com a camada de rede entre os dispositivos KNX/EIB ..................................37 Ilustrao 11 Interface com a camada de transporte entre os dispositivos KNX/EIB.........................38 Ilustrao 12 Cdigos dos servios KNX/EIB modo multicast............................................................40 Ilustrao 13 Exemplo Trama GroupValue_Read ..............................................................................40 Ilustrao 14 - Exemplo Trama GroupValue_Res .................................................................................41 Ilustrao 15 Exemplo Trama GroupValue_Write..............................................................................41 Ilustrao 16 EIS Switching ................................................................................................................42 Ilustrao 17 EIS Drive Control - Move .............................................................................................43 Ilustrao 18 EIS Drive Control Step...............................................................................................43 Ilustrao 19 Mquina de estados do Drive Control ..........................................................................44 Ilustrao 20 - Diagrama de pinos de um conector PEI ........................................................................46 Ilustrao 21 - Caractere de controlo de uma trama FT 1.2 de uma estao primria........................49 Ilustrao 22 - Caractere de controlo de uma trama FT 1.2 de uma estao secundria .....................50 Ilustrao 23 - Exemplo de transmisso de dados por FT 1.2 ..............................................................51 Ilustrao 24 - Fluxo de mensagens entre cliente e servidor cEMI .......................................................52 Ilustrao 25 - Estrutura bsica de uma mensagem cEMI do tipo L_DATA ........................................53 Ilustrao 26 - Control Field 1 do L_DATA..........................................................................................54 Ilustrao 27 - Control Field 2 do L_DATA..........................................................................................54

FEUP KNX 2008

viii

Ilustrao 28 - Estrutura bsica de mensagem cEMI de gesto e configurao ...................................56 Ilustrao 29 - Interface ETS 3.0d Profissional ....................................................................................60 Ilustrao 30 - Interface de pesquisa e insero de dispositivos KNX/EIB ..........................................61 Ilustrao 31 - Interface configurao de uma instalao KNX/EIB.....................................................61 Ilustrao 32 - Modelo em camadas do protocolo KNX e KNXnet/IP ..................................................63 Ilustrao 33 - Exemplo de uma configurao KNXnet/IP possvel .....................................................65 Ilustrao 34 - Exemplo de arquitectura com servidor KNXnet/IP implementando tunnelling ............67 Ilustrao 35 - Exemplo de arquitectura com servidor servidor KNXnet/IP implementando routing ...68 Ilustrao 36 - Esquema de um servidor KNXnet/IP e a funo do ncleo ...........................................70 Ilustrao 37 - Endpoints de um servidor KNXnet/IP ............................................................................71 Ilustrao 38 - Formato das tramas KNXnet/IP ....................................................................................78 Ilustrao 39 - Arquitectura Domoitech com KNXnet/IP.......................................................................80 Ilustrao 40 - Esquema do hardware evidenciando as ligaes do PIC18F6520 e da XPORT AR .....82 Ilustrao 41 - Diagrama de blocos da estrutura de hardware .............................................................84 Ilustrao 43 - Diagrama de blocos da estrutura de hardware .............................................................86 Ilustrao 44 - Grfico comparativo entre as arquitecturas..................................................................89 Ilustrao 45 - Arquitectura de software................................................................................................92 Ilustrao 46 - Diagrama UML da estrutura de ficheiros do software..................................................94 Ilustrao 47 - Esquema da instalao da plataforma de testes ............................................................96 Ilustrao 48 - Teste Search Request .....................................................................................................97 Ilustrao 49 - Teste Search Response...................................................................................................98 Ilustrao 50 - Teste Description Response ...........................................................................................98 Ilustrao 51- Teste Connect Response..................................................................................................99 Ilustrao 52 - TesteConnection State Response...................................................................................99 Ilustrao 53 - Teste Disconnect Response ..........................................................................................100 Ilustrao 54 - Teste Tunneling Request ..............................................................................................100 Ilustrao 55 - Teste Tunneling Acknowledge......................................................................................101 Ilustrao 56 - Envio de trama KNX/EIB para o Domoitech ...............................................................101 Ilustrao 57 - Teste Device Configuration Request............................................................................102

FEUP KNX 2008

ix

Ilustrao 58 - Teste Device Configuration Acknowledge ...................................................................102

FEUP KNX 2008

ndice de Tabelas
Tabela 1 Protocolos de Rede utilizados na Domtica.........................................................................15 Tabela 2 - Valores de resistncia para seleco do tipo de PEI ............................................................47 Tabela 3 - Custo placa principal Domoitech com KNXnet/IP................................................................87 Tabela 4 - Cdigos das mensagens cEMI.............................................................................................107 Tabela 5 - Propriedades do device object ............................................................................................109

FEUP KNX 2008

xi

Notao e Glossrio
Esta seco apresenta os conceitos (glossrio de termos) ordenados alfabeticamente e acrnimos utilizados no corpo do texto do relatrio.

AVAC Bits/s cEMI Dispositivo KNX/EIB E/S EIS ETS EIBA EIB IP KNX/EIB OSI PDA PLC PL PEI RF TP Trama

- Aquecimento, Ventilao e Ar Condicionado - Bits por segundo - Common External Message Interface - Elemento fsico que comunica em KNX/EIB e que est ligado a uma rede KNX/EIB. um objecto concreto que o cliente compra como por exemplo, um interruptor KNX/EIB. - Entradas/Sadas - EIB Interworking Standards - EIB Tool Software - European Installation Bus Association - European Installation Bus - Internet Protocol - Protocolo da associao Konnex - Open Systems Interconnection - Personnel Digital Assistente, uma agenda electrnica com sistema operativo e realiza funes idnticas a um computador - Autmato Programvel - Power Line - Physical External Interface - Rdio Frequncia - Twisted Pair - Sequencia de octetos sempre com a notao little-endian

FEUP KNX 2008

xii

1 Introduo
A Domtica uma tecnologia recente que permite a gesto de todos os recursos habitacionais. O termo Domtica resulta da juno da palavra Domus (casa) com Telemtica (electrnica + informtica). So estes dois ltimos elementos que, quando utilizados em conjunto, rentabilizam o sistema, simplificando a vida diria das pessoas satisfazendo as suas necessidades de comunicao, de conforto e segurana. Quando a Domtica surgiu (com o primeiros edifcios, nos anos 80) pretendia-se controlar a iluminao, condies climticas, a segurana e a interligao entre os 3 elementos. Nos nossos dias, a ideia base a mesma, a diferena o contexto para o qual o sistema est pensado: j no um contexto militar ou industrial mas domstico. Apesar de ainda ser pouco conhecida e divulgada, pelo conforto e comodidade que pode proporcionar, a Domtica promete ter muitos adeptos. A Domtica alia as vantagens da electrnica informtica, de forma a obter uma utilizao e uma gesto dos diversos equipamentos de uma casa. Torna a vida mais confortvel, mais segura e at mais divertida! Permite que as tarefas mais rotineiras e aborrecidas sejam executadas. A Domtica torna-se ainda mais interessante se a aplicarmos para melhorar o nvel de vida de uma pessoa incapacitada. Poder optar por um manuseamento mais ou menos automtico. Nos sistemas passivos o elemento reage s quando lhe transmitida uma ordem, dada directamente pelo utilizador (interruptor). Nos sistemas mais avanados, com mais inteligncia, no s interpreta parmetros, como reage s circunstncias (informao que transmitida pelos sensores), por exemplo detectar que uma janela est aberta e avisa o utilizador, ou que a temperatura est a diminuir e ligar o aquecimento. O controlo remoto de casas de habitao deixa de ser uma utopia. A Domtica permite o acesso s funes vitais da casa, como aquecimento, electrodomsticos, alarme, fechaduras das portas, quer seja atravs de um comando remoto, da Internet ou do telemvel. [1]

FEUP KNX 2008

13

1.1 Protocolos de Domtica

grande a variedade de protocolos normalizados direccionados para a Domtica. necessrio diferenciar quais os que so proprietrios, os de alianas ou grupos de trabalho e ainda quais so livres e abertos. No mercado, os sistemas mais usuais utilizam o protocolo X-10 por ser mais econmico, mas a grande desvantagem a sua fraca robustez e ser muito rudimentar. Sistemas que utilizem este protocolo so facilmente encontrados que por utilizarem a rede elctrica como meio de comunicao, no necessitam de instaladores experientes, nem da instalao de mais cablagem porque a instalao elctrica existente aproveitada. aconselhado o uso deste tipo de sistema no caso de se necessitar um controlo simples. O protocolo mais fivel e mais utilizado em sistemas domsticos existentes no mercado, o KNX/EIB. Este protocolo oferece muita robustez e flexibilidade contudo, os produtos so de elevado custo. Para ter uma noo, um interruptor de presso quadruplo da Siemens, custa aproximadamente 70,91. [2] O protocolo KNX/EIB tem sido desenvolvido dentro do contexto da Unio Europeia, com o fim de fazer frente aos produtos domticos j existentes na Amrica e Japo. O protocolo KNX/EIB permite a utilizao de vrios meios fsicos, mas o mais utilizado o par entranado onde todos os dispositivos esto ligados a um Bus. Mas com esta soluo de par entranado (TP), era necessria uma fonte de alimentao para o barramento que normalmente tem um custo elevado, na ordem dos 160. [2] O KNX/EIB um protocolo aberto e por esta razo, existem no mercado alguns fabricantes que tm os seus produtos a utilizarem KNX/EIB. Existem outros protocolos de domtica mas no so muito usuais e raramente encontrados no mercado. A tabela seguinte apresenta uma breve descrio de alguns Protocolos standards utilizados na Domtica, distinguindo quais pertencem a organizaes e quais so proprietrios. [3]

FEUP KNX 2008

14

Protocolos de Rede - Alianas e Grupos de Trabalhos Standard BatiBUS Meio Fsico Par Entranado Todos Descrio
Sensores de unio e actuadores para construir sistemas que controlem HVAC (Ar Condicionado), sistemas de segurana e acesso. Em convergncia com EIB e EHS para KNX. O Standard CEBus (EIA-600) um protocolo criado pela Associao de Industrias Electrnicas (EIA) para ser possvel a interligao e comunicao entre dispositivos electrnicos da casa. Sensores e actuadores para construir sistemas que controlem HVAC (Ar Condicionado), sistemas de segurana e acesso. Em convergncia com EHS e BatiBus para KNX. Uma colaborao entre industrias e governos Europeus sobre Domtica. Entre alguma das suas misses a EHSA tem o objectivo de ser um standard na Europa de um BUS comum (EHS). Em convergncia com EIB e BatiBus para KNX. A misso do grupo de trabalho HomeRF tornar possvel uma vasta gama de produtos electrnicos de consumo que operem entre si, estabelecendo uma especificao aberta para comunicaes digitais de RF (sem licena), para PC,s e produtos electrnicos de consumo em qualquer sitio e arredores da casa. A associao LonMark tem a misso de integrar facilmente dispositivos baseados em redes LonWorks, fazendo uso de ferramentas e componentes standards. Pensa-se que este pode ser um dos standards que ir ser bastante utilizados no mundo da domtica. uma verso melhorada do HomeRF e destinada a ambientes industriais.

CEBus (Consumer Electronics Bus) EIB (European Installation Bus) EHS (European Home System)

Par Entranado Todos

HomeRF (Home Radio Frequency Working Group)

RF

LonMark Interoperability Association ZIGBEE

Todos

RF

Protocolos de Rede - Proprietrios Lonworks Echelon Corp. Todos

Redes de controlo comerciais e para a casa. Uma rede LonWorks grupo de dispositivos trabalhando juntos para sensorizar, monitorizar, comunicar, e de algumas maneiras controlar. muito parecido com uma LAN de PC,s. O protocolo mais utilizado na domtica, utiliza a rede elctrica e facilita o controlo de dispositivos domticos sem instalao de qualquer fio em casa, por utilizar a instalao de rede elctrica j existente.

X-10

Corrente elctrica/RF

Tabela 1 Protocolos de Rede utilizados na Domtica

FEUP KNX 2008

15

1.2 Domoitech
O projecto Domoitech realizado no ano lectivo de 2006/2007, consistiu em criar uma configurao e equipamento para domtica que fosse compatvel com solues que facilmente se encontrem no mercado. Outro requisito muito importante era que o custo deveria ser o mnimo possvel. A soluo apresentada foi baseada numa arquitectura descentralizada, composta por dispositivos com os sensores e actuadores que estaro ligados ao barramento da rede de domtica. Cada um desses dispositivos, permite ligar vrias entradas e sadas. composto por uma placa principal, onde feito o processamento do protocolo de domtica e a esta placa possvel conectar at 7 placas secundrias que contm as interfaces as sensores e actuadores (p.ex: rels, optoacopladores, ). A figura seguinte ilustra a arquitectura de hardware da placa principal, e dos dois tipos de placas secundrias possveis:

Ilustrao 1 - Diagrama de blocos da estrutura de hardware Domoitech

FEUP KNX 2008

16

Analisando a figura 1, comeando pelo topo, encontramos o diagrama de blocos da estrutura para placa principal que contm; um receptor de infravermelhos, reguladores de tenso, uma interface para o programador da placa, entradas/sadas RJ11 para ligar as placas secundrias, um microcontrolador PIC18F452 [11] e uma XPORT [10]. O microcontrolador a unidade de processamento que contm o protocolo de domtica e efectua leituras/escritas de dados das placas secundrias e da XPORT. Este ltimo componente referido, efectua uma converso bidireccional entre o protocolo RS232 e TCP/IP sob Ethernet. a soluo integrada mais compacta para permitir uma interface web a qualquer componente com uma interface srie. Posteriormente ser explicado que o barramento fsico utilizado para a rede de domtica foi o TCP/IP sob Ethernet. As placas secundrias podem ser de dois tipos; utilizando rels ou triacs para os actuadores. Cada placa secundria contm duas interfaces para entradas e duas para as sadas e os respectivos isolamentos pticos e galvnicos. Com a arquitectura descentralizada do Domoitech, possvel ter um computador central que poder funcionar como servidor web, permitindo assim o acesso pelo exterior de forma a controlar remotamente os equipamentos, e realizar algumas tarefas de gesto da rede. Depois de ter sido efectuado um estudo aprofundado de protocolos de domtica existentes e os mais comuns no mercado, foi escolhido desenvolver o projecto utilizando o protocolo EIB. Apesar do projecto Domoitech ter sido desenvolvido com o protocolo EIB, no totalmente compatvel com outros dispositivos KNX/EIB devido ao meio fsico que utiliza no estar em conformidade com a norma. No mercado usual encontrar a sigla KNX/EIB indicativa do nome do protocolo porque desde 14 de Abril de 1999, o EIB evoluiu para KNX que resultou da convergncia entre EIB, EHS e o BatiBUS. O KNX veio acrescentar ao EIB outras funcionalidades tais como: permite a utilizao de mais meios fsicos e o controlo de mais sistemas, como o exemplo de sistemas HVAC. utilizada a sigla KNX/EIB em vez de utilizar s KNX, porque o KNX totalmente compatvel com EIB, visto a sua base ser EIB onde apenas foram acrescentados mais meios fsicos que os protocolos EHS e o BatiBUS suportavam. No projecto Domoitech, foi utilizado como meio fsico o Ethernet e o protocolo de rede TCP/IP sob Ethernet. O KNX tambm suporta esse meio fsico e tem uma

FEUP KNX 2008

17

norma denominada por KNXnet/IP para a utilizao desse mesmo meio em redes IP. Como na altura o protocolo utilizado era o EIB, o Domoitech no utilizou a norma KNXnet/IP e utilizou o Ethernet TCP/IP para simular um barramento Twisted-Pair do EIB. Contudo isto torna uma incompatibilidade com outros equipamentos KNX/EIB porque o acesso ao meio fsico no respeita a norma. Apesar de o Domoitech codificar/descodificar tramas KNX/EIB, falta-lhe saber as regras para envio/recepo dessas mesmas tramas sob o protocolo de rede TCP/IP. Outra lacuna do Domoitech a falta de alguns servios inerentes ao KNX/EIB. Esses servios sero importantes para poder configurar os dispositivos KNX/EIB.

1.3 Objectivos
O objectivo deste trabalho encontrar a melhor soluo para tornar o projecto Domoitech compatvel com equipamento KNX/EIB que se encontra no mercado e encontrar tambm uma arquitectura de baixo custo melhorando o Domoitech mas aproveitando a estrutura do mesmo.

FEUP KNX 2008

18

2 Protocolo KNX/EIB
O EIB um protocolo de comunicao desenvolvido por um conjunto de empresas lderes no Mercado Europeu do material elctrico com o objectivo declarado de criar um sistema que constitua uma barreira s importaes de produtos e sistemas semelhantes que so produzidos nos mercados Japons e dos Estados Unidos da Amrica onde estas tecnologias possuem um grau de maturidade superior ao produzido na Europa. O objectivo era criar uma norma Europeia que permitisse a comunicao entre todos os dispositivos de uma instalao, esteja ela numa casa ou num edifcio de escritrios. O EIB possui uma arquitectura descentralizada. Ele define uma relao elemento a elemento entre os dispositivos, o que permite distribuir a inteligncia entre os sensores e actuadores instalados. A EIBA uma associao actualmente com 114 membros, empresas lideres no mercado do material elctrico, que se iniciou em 1990, com 15 membros apenas, para implantar o uso do sistema de instalao inteligente EIB. A EIBA tem sede em Bruxelas e os seus membros cobrem cerca de 90% do negcio do material elctrico na Europa. As principais reas de actuao desta associao so:

Estabelece as directrizes tcnicas para o sistema e produtos EIB, assim como estabelecer os procedimentos de ensaio e certificao de qualidade e mandar realizar esses mesmos ensaios.

Divulga o conhecimento e experincias das empresas que trabalham com o EIB, assim como dos novos produtos e/ou inovaes.

nica entidade a poder atribuir a marca registada EIB aos produtos e aos fabricantes seus associados.

Colabora activamente com outros organismos europeus e internacionais em todas as fases de normalizao e adaptao do EIB s normas internacionais.

Participa na iniciativa de "convergncia" KONNEX, juntamente com o BCI (Batibus) e a EHSA (EHS). [5]

FEUP KNX 2008

19

O KONNEX, conhecido pelas siglas KNX foi criado em 14 de Abril de 1999 com o objectivo de obter um nico standard Europeu para a automao das casas e edifcios. Os objectivos desta iniciativa, com o nome de "Convergncia", so:

Criar um nico standard para a domtica e automao de edifcios que cubra todas as necessidades e requisitos das instalaes profissionais e residenciais no mbito europeu;

Melhorar as prestaes dos diversos meios fsicos de comunicao sobretudo na tecnologia de radiofrequncia, fundamental para a efectiva consolidao da domtica;

Introduzir novos modos de funcionamento que permitam aplicar uma filosofia Plug&Play a muitos dispositivos tpicos de uma casa;

Envolver

as

empresas

fornecedoras

de

servios

como

as

de

telecomunicaes e de electricidade, com o objectivo de desenvolver a telegesto nas casas; Resumindo, partindo dos sistemas EIB, EHS e Batibus, trata-se de criar um nico standard europeu que seja capaz de competir em qualidade, prestaes e preos, com outros sistemas norte-americanos como o Lonworks ou CEBus. Actualmente a associao KONNEX est a terminar as especificaes do novo standard (verso 1.1) o qual ser compatvel com os produtos EIB instalados. Pode afirmar-se que o novo standard ter o melhor do EIB, do EHS e do Batibus e que aumentar consideravelmente a oferta de produtos para o mercado residencial. A verso 1.1 contempla trs modos de funcionamento: 1. S-mode (System mode): a configurao do modo sistema usa a mesma filosofia que o EIB, isto , os diversos dispositivos ou modos da nova instalao, so instalados e configurados por profissionais com ajuda de um software (ETS) especialmente concebido para este propsito. Este o modo mais utilizado. 2. E-mode (Easy mode): na configurao do modo simples os dispositivos so programados em fbrica para realizar uma funo concreta. Mesmo assim devem ser configurados alguns detalhes no local da instalao mediante o uso de um controlador (como uma porta residencial) ou mediante micro-

FEUP KNX 2008

20

interruptores alojados nos dispositivos (semelhante ao X-10 ou outros dispositivos proprietrios que h no mercado). 3. A-mode (Automatic mode): na configurao do modo automtico, com uma filosofia Plug&Play, nem o instalador nem o utilizador final tm de configurar o dispositivo. Este modo ser especialmente indicado para ser usado em electrodomsticos e equipamentos de entretenimento (consolas, set-top boxes, udio e vdeo).

Respeitante ao meio fsico o novo standard poder funcionar sobre:

Par de condutores (TP1): que aproveita a norma EIB equivalente. Par de condutores (TP0): que aproveita a norma Batibus equivalente. Corrente elctrica (PL100): que aproveita a norma EIB equivalente. Corrente elctrica (PL132): que aproveita a norma EHS equivalente. Ethernet: utiliza a norma KNXnet/IP. Radiofrequncia: que aproveita a norma EIB.RF Existe tambm o EIB.IR que transmite o sinal por infravermelho, at uma distncia mxima de aproximadamente 12 metros. Ideal para o uso com comandos distncia em salas ou sales onde se pretende controlar os dispositivos KNX/EIB instalados e o nmero destes ou as distncias a cobrir esto dentro do limite indicado. [5] A imagem seguinte ilustra que o sistema de base do KNX o EIB e que para

todos os modos de configurao, existe um software criado pela KONNEX para configurar os dispositivos KNX/EIB denominado por ETS (Engineering Tool Software).

FEUP KNX 2008

21

Ilustrao 2 Modelo do Sistema KNX

A imagem ilustra tambm os vrios meios fsicos possveis de utilizar e o significado dos trs pontos () indica que possvel a utilizao de outros meios fsicos, mas apenas o TP, PL, RF, IR e Ethernet que esto definidos na norma.

2.1 KNX/EIB Handbook

Para desenvolver um produto KNX/EIB, necessrio adquirir o KNX/EIB Handbook, que contm a norma ou o Standard EN 50090 que define o KNX/EIB. Existe tambm a possibilidade de no caso de ser-se membro da associao, adquirir o KNX/EIB Handbook gratuitamente. [7] O KNX/EIB Handbook encontra-se ainda na verso 1.1 desde 2004. A norma est estruturada em 10 volumes. Como a norma KNX/EIB encontra-se ainda em construo, existem alguns documentos anexados que ainda no esto terminados e aprovados. Encontram-se igualmente anexados 49 notas de aplicao. Os volumes 1 e 2 no contm nenhum documento e foram criados para a incluso de documentos numa futura verso da norma. O volume 3 o principal porque contm as especificaes do sistema. Tem oito partes divididas por: arquitectura, meio fsico, comunicao, ambiente de

FEUP KNX 2008

22

aplicao, gesto, interfaces standard, inter funcionamento e a ltima parte contm a norma KNXnet/IP. O volume 4 contm os requisitos de hardware e testes ao hardware. aqui que so definidos os requisitos elctricos para cada meio fsico e como efectuar testes aos mesmos. O volume 5 contm o manual de certificao do produto desenvolvido em KNX. O volume 6 contm um conjunto de perfis que especificam o comportamento dos dispositivos KNX, a fim de garantir o inter-funcionamento entre eles. O volume 7 contm alguns exemplos de aplicao e descreve

pormenorizadamente como se desenvolve essas aplicaes. Por exemplo, descreve como o KNX utilizado em sistemas de ventilao e ar condicionado. O volume 8 contm especificao de testes a efectuar ao sistema todo e verificar se est em conformidade. Este volume essencial e importante realizar antes da certificao. O volume 9 descreve os componentes do sistema e dispositivos bsicos como por exemplo, o BCU e BIM. O BCU (Bus coupling units), um dispositivo que inclui o circuito de interface ao meio fsico Twisted-Pair do tipo TP1. composto por um microprocessador que implementa quase todas as camadas KNX/EIB exceptuando as de nvel de aplicao. O colaborador apenas precisa de desenvolver a aplicao num microcontrolador parte e utilizar o BCU como interface ao barramento TP1. O BIM (Bus Interface Modules), basicamente um BCU mas com portas adicionais de entradas e sadas. O volume 10 contm especificaes de domnios de aplicao. A integrao do KNX em outros domnios de aplicao um dos grandes objectivos do KNX. Para alm destes volumes, notas de aplicao e documentos ainda em progresso, contm tambm 26 suplementos que dizem respeito ao volume 3.

FEUP KNX 2008

23

2.2 Arquitectura
Este sub captulo resume os principais elementos de um sistema KNX/EIB e alguns conceitos. O KNX/EIB define a tecnologia de controlo de edifcios como uma forma especializada de automao de processos dedicados s necessidades de uma habitao. A sua arquitectura descentralizada e distribuda, da que se utiliza o termo de Rede KNX/EIB. O KNX/EIB bastante completo e contm imensos mecanismos e ingredientes que possibilitam os fabricantes de escolherem a sua prpria configurao adequada para o mercado pretendido. A figura seguinte ilustra como possvel optar-se por 3 mtodos de configurao e escolher igualmente o meio fsico a utilizar.

Ilustrao 3 - Modelo KNX/EIB

FEUP KNX 2008

24

Os componentes essenciais e que todos os fabricantes tm de desenvolver so os seguintes: - Runtime Interworking, um componente essencial porque contm os Datapoints. Os Datapoints representam as variveis do processo e controlo (inputs, outputs,). A definio desses Datapoints est contida em tabelas denominadas por Group Objects e Interface Objects Properties em que esta ltima contm as propriedades dos Datapoints. necessrio tambm criar Standardized Datapoint Types para definir os tipos das variveis, como por exemplo: a varivel de sada lmpada do tipo 1 Bit em que tem apenas dois estados (ligado/desligado). - Network Management: necessrio criar esquemas de configurao e gesto para gerir todos os recursos da rede. Existem duas formas de configurar uma instalao KNX/EIB: uma ao nvel da rede e a outra a configurao individual dos ns ou dispositivos KNX/EIB. A configurao pode ser feita localmente nos dispositivos, como por exemplo: carregando num boto, ou ligar o dispositivo directamente a um computador que com um software configura o mesmo, etc. O outro tipo de configurao pode ser feita atravs de uma rede de gesto que utiliza o barramento de comunicaes KNX para enviar tramas de configurao para todos os dispositivos. Esta a configurao mais comum em que utiliza o software ETS (que ser abordado posteriormente) para enviar tramas pela rede e configurar todos os dispositivos KNX/EIB. - Communication System: contm a pilha KNX/EIB desde o meio fsico at camada de Aplicao. caracterizado pelo KNX Common Kernel. Ao nvel mais baixo, o de meio fsico, o fabricante pode optar por utilizar um destes meios fsicos: TP0, TP1, PL110, PL132,RF, IR e Ethernet. Das camadas do modelo OSI - 7, apenas a de sesso e de apresentao que esto vazias, porque as restantes so utilizadas pelo KNX/EIB. Comeando pelo nvel mais baixo do modelo de camadas OSI: Camada Meio Fsico: permite a utilizao de vrios meios fsicos, sendo mais utilizado o de TP1. O TP0 foi adoptado do protocolo BatiBus e o TP1 foi adoptado do protocolo EIB, da que a sua utilizao seja mais comum. Estes dois meios fsicos, utilizam um cabo com dois fios entranados, onde passa a alimentao e dados, com transferncias assncronas half-duplex e taxas de

FEUP KNX 2008

25

transferncia de 2400bit/s para TP0 e 9600bit/s para o TP1. Em ambos os meios, implementado o mecanismo de evitar colises CSMA/CD. Os restantes meios raramente so utilizados, mas a norma KNX/EIB permite a utilizao dos mesmos e especifica os mesmos. O KNX acrescentou um novo meio, o de Ethernet com o intuito de permitir a sua utilizao com o protocolo TCP/IP. O intuito da utilizao do protocolo TCP/IP permitir utilizar as redes Ethernet (IEEE 802.2), Bluetooth (IEEE 802.15), Wifi (IEEE 802.11) e FireWire (IEEE 1394). Camada Ligao de Dados: encontra-se acima de cada meio fsico e permite o acesso entre o meio fsico e a ligao lgica. Camada de Rede: feito um acknowledged das tramas e contm tambm um contador das tramas por cada router que passam (hop count). Esta camada tem interesse em utilizao de ns que tenham routers. Camada de Transporte: permite quatro tipos de comunicao, um-paramuitos (multicast), um-para-todos (broadcast), um-para-um sem conexo e umpara-um orientado conexo. Camada de Aplicao: tem uma variedade enorme de servios que permitem realizar todo o tipo de aces ou configuraes nos dispositivos KNX/EIB. Estes servios dependem dos tipos de comunicao da camada de transporte, porque por exemplo, para uns servios necessrio uma ligao de um-para-todos e para outros servios necessrio uma ligao de um-para-um orientado conexo.

2.2.1 Modos de configurao

Uma das opes que o fabricante tem, adoptar por um modo de configurao do sistema KNX/EIB adequado ao mercado destino. A opo de utilizao de vrios modos de configurao, possvel graas ao software ETS que utilizando a funo de leitura de auto-descrio que os dispositivos KNX/EIB tm, consegue saber qual o modo de configurao que utilizam e adequa os procedimentos de configurao. Os trs modos de configurao so: System, Easy e A-mode.

FEUP KNX 2008

26

O System mode o mais verstil e mais usual encontrar porque tem uma implementao simples. A complexidade de configurao deixa de estar no dispositivo KNX/EIB passando para um software de configurao como o ETS. Este tipo de configurao, requere que o ETS tenha uma base de dados dos dispositivos KNX/EIB de cada fabricante com respectivas funcionalidades. Os fabricantes dos seus produtos so responsveis por criarem os templates dos seus dispositivos e por os actualizarem. Normalmente, na compra de um dispositivo KNX/EIB, o fabricante fornece ao cliente o template do mesmo para inserir no ETS e assim poder configurar o dispositivo. O Easy mode como podemos ver na imagem (Fig xx Modelo KNX/EIB), representa um conjunto de vrios modos: - Controller Mode: este modo s suporta um nmero limitado de dispositivos num segmento do meio fsico. Necessita de um controlador instalado nesse segmento fsico que o responsvel por fazer a configurao dos dispositivos. Esse controlador normalmente s suporta uma ou poucas aplicaes como por exemplo: iluminao. Este controlador faz a leitura das funcionalidades de cada dispositivo e realiza a configuraes de cada um. A sua funcionalidade pode-se assemelhar ao ETS mas com funes de configurao muito limitadas. - Push-button Mode: este modo, tal como o anterior, s funciona para um nmero limitado de dispositivos num segmento fsico. Ao contrrio do anterior modo, no necessita de um controlador especializado, porque cada dispositivo KNX/EIB contm um boto de configurao. Os dispositivos tm capacidade de serem configurados dinamicamente. Com isto a complexidade na configurao passa a estar no lado dos dispositivos e quando necessrio alterar algum parmetro, ter de ser feito localmente no dispositivo. - Logical Tag Mode: neste modo no necessrio uma ferramenta de configurao. Os dispositivos KNX/EIB e as suas funcionalidades, so activados atravs de, por exemplo; dip-switches para atribuir os valores a funes de configurao. - Logical Tag Extended Mode: este modo igual ao anterior em que a configurao feita localmente atravs de interruptores, mas este especfico para aplicaes AVAC porque estas necessitam de tramas estendidas. (ver captulo 2.2.3).

FEUP KNX 2008

27

O A- mode ao contrrio de todos os modos anteriores que so dedicados a instalaes que normalmente so fixas (no sofrem alteraes regularmente), este modo destinado a utilizadores inexperientes. Inclui mecanismos de auto configurao permitindo assim a fcil mobilidade de uma aplicao para outra.

2.2.2 Topologia
O KNX/EIB uma rede distribuda que pode ter at 65536 dispositivos com endereos individuais de 16 bit. Em KNX/EIB existem dois tipos de endereos: de grupo ou individual. Normalmente a denotao dos endereos feita com dois pontos e nmeros decimais, ou seja na forma X . X . X, em que dois primeiros nmeros decimais fazem 8 bits e o ltimo nmero decimal tem o tamanho de 8 bits. O endereo de grupo no necessita de ser nico pelo que um dispositivo pode ter mais do que um endereo de grupo. O endereo individual nico em cada dispositivo KNX/EIB e na denotao, o primeiro nmero decimal corresponde ao endereo da rea, que so os 4 bits MSB do octeto 0 e o segundo nmero decimal da denotao, corresponde ao endereo da linha e so os 4 bits LSB do octeto 0. O octeto 1 o que tem o endereo do dispositivo e corresponde ao terceiro nmero decimal na denotao dos endereos com dois pontos. Em cada sub-rede possvel ter at 256 dispositivos. A imagem 4 ilustra um exemplo de uma rede KNX/EIB com o backbone onde so ligadas vrias reas que contm as diversas sub-redes.

FEUP KNX 2008

28

Ilustrao 4 - Estrutura de uma rede KNX/EIB

Cada rea tem uma linha principal onde vo ser ligadas as vrias sub-redes que se denominam por linhas. Tendo em conta que os oito primeiros bits do endereo KNX/EIB so reservados para identificao da rea e linha, restam 8 bits para enderear dispositivos, o que perfaz as 256 combinaes de endereos diferentes nessa linha. Em cada rea possvel ter at 15 linhas porque o endereamento das linhas feito com 4 bits e o endereo 0 reservado para o acoplador entre a linha principal e o backbone. Ligados ao backbone possvel termos no mximo 15 reas porque o endereamento das reas feito com 4 bits e o endereo 0 reservado para definir os dispositivos KNX/EIB que se ligam directamente ao backbone.

FEUP KNX 2008

29

2.2.3 Formato da trama KNX/EIB

A trama KNX/EIB, no tem qualquer prembulo que diga respeito ao meio fsico porque esta independente do meio fsico. Esta trama composta por vrios cabealhos de quatro camadas do modelo OSI do protocolo que foram referidas anteriormente. Uma trama KNX/EIB tem o seguinte formato:

Ilustrao 5 - Formato Trama EIB

Na parte inferior da trama encontra-se uma barra de cores que facilita a visualizao dos prembulos das vrias camadas. A barra azul, desde o octecto 0 at ao octeto 4, mais 5 bits do octeto 5 e ltimo octecto, diz respeito camada de ligao lgica. Neste cabealho, esto indicados os endereos de destino e origem, um caractere inicial de controlo e no final um octecto de controlo com um NOT XOR de todos os octetos anteriores do 0 at este octecto controlo excluindo o prprio. A este octeto terminal, chamamos de check octet e serve para deteco de erros na trama. O caractere de controlo determina a prioridade da trama e distingue se a trama normal ou se estendida. O uso de tramas estendidas muito raro pelo que a norma refere que este tipo de tramas ficou reservado para utilizaes futuras e no definem este tipo de tramas. neste cabealho que indicado o nmero de octetos que a trama tem, desde o octeto 7 at o penltimo octecto, visto que o check octet no entra na contagem. Assim para se saber o tamanho exacto da trama KNX/EIB soma-se a este valor, 8 octetos que sero sempre fixos. A barra amarela, os 3 bits do octeto 5 pertencem camada de rede e indicam se os endereos que vm so do tipo endereos de grupo ou individuais. A barra verde, o octeto 6 contm o cabealho da trama de transporte.

FEUP KNX 2008

30

Na barra a vermelho, os octetos a partir do 7 excepto o ltimo, pertencem camada de aplicao. O tamanho mximo de uma trama KNX/EIB de 23 octectos.

2.3 Meio Fsico

Um dos grandes trunfos do KNX/EIB a possibilidade de utilizao do mesmo sob vrios tipos de meios fsicos. Apesar de a norma especificar cinco meios fsicos, o KNX/EIB refere que possvel utilizar outros que o fabricante pretenda. Contudo, softwares de configurao como o ETS que ser explicado posteriormente, apenas funcionam para os meios fsicos descritos na norma. Se o fabricante pretender utilizar outro meio fsico, dever solicitar a sua certificao junto da Konnex, para a introduo do mesmo no software ETS. Os cinco meios fsicos sero explicados resumidamente nos prximos sub-sub-captulos.

2.3.1 Par entranado

Existem dois tipos de rede para este meio fsico: TP0 e TP1. O primeiro foi herdado do protocolo BatiBus e funciona com uma taxa de transferncia de 2400 bit/s enquanto que o TP1 foi herdado do EIB e funciona com uma taxa de transferncia de 9600 bits/s. Os dados so transmitidos simetricamente atravs de par entranado e a transmisso de sinais feita por meio da diferena de tenso entre os dois condutores do cabo como representado na figura seguinte:

Ilustrao 6 - Sinal balanceado entre dispositivos KNX/EIB

FEUP KNX 2008

31

Uma trama KNX/EIB enviada para o meio fsico TP, no modo de caracteres srie. Cada octeto da trama enviado para o barramento TP utilizando o modo srie que consistem em enviar um bit de incio do caractere, seguido dos oito bits do octeto, um bit de paridade para controlo de erros e no final um bit de identificao do fim do caractere srie. O sinal transmitido no barramento em corrente alternada com uma componente em corrente contnua. A tenso da componente corrente contnua, pode tomar os valores de 21 a 32 Vdc. O tempo de durao da transmisso de um bit de 104 s. O sinal lgico 1 pode ser visto como estado inactivo da linha, o que significa que transmitir um 1 o mesmo que no transmitir nada, assim sendo, para enviar um 1 necessrio enviar um 0 que normalmente o bit de incio do caractere. O sinal lgico 0 feito quando a linha fica a ON durante 35 s, e nos restantes 105 s (at o final de transmisso do bit), a linha fica no estado OFF. O acesso ao barramento baseado no protocolo CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance), que funciona do seguinte modo: - Um dispositivo que pretenda transmitir uma mensagem pode comear a faz-lo imediatamente se encontrar o barramento inactivo (desocupado), caso contrrio, ter de aguardar at este ficar livre. - Os dispositivos escutam o barramento, enquanto transmitem, com o objectivo de detectarem qualquer coliso, que ocorrer se dois dispositivos transmitirem simultaneamente uma mensagem. Quando um dispositivo tenta impor o estado lgico "1" e detecta o estado lgico "0" (sinal de corrente na linha), pra de transmitir para permitir que o dispositivo com a mensagem prioritria o continue a fazer, como ilustra a figura seguinte;

Ilustrao 7 - Protocolo CSMA/CA FEUP KNX 2008

32

- O dispositivo com a mensagem de prioridade mais baixa, continua a escutar o barramento para quando a mensagem prioritria terminar, poder ento transmitir os seus dados. Desta forma, se vrios dispositivos tentarem transmitir

simultaneamente, o protocolo CSMA/CA assegura que a rede s ser ocupada por um destes dispositivos.

2.3.2 Rede elctrica

Este meio fsico utiliza a rede elctrica como meio para comunicao. O protocolo X-10 tambm direccionado para a domtica, conhecido pela utilizao deste meio fsico e muito adoptado porque permite a utilizao da instalao elctrica j existente. Contudo este meio fsico tem muitas interferncias e as taxas de transmisso so baixas. O KNX/EIB tem duas especificaes para este meio fsico: o PL110 e o PL132. O PL110 tem uma taxa de transferncia de 1200 bits/s e foi herdado do EIB pelo que dispositivos EIB PL110 podem comunicar com dispositivos KNX/EIB PL110. O PL132 tem uma taxa de transferncia de 2400 bits/s e foi herdado do EHS que ainda o utiliza, no entanto, dispositivos KNX/EIB PL132 no podem comunicar com dispositivos EHS PL132 porque o protocolo de domtica diferente. A rede elctrica funciona com sinais de corrente alternada de 230 Vac a uma frequncia de 50 Hz. Para enviar sinais digitais pela rede varia-se a frequncia, a modulao do tipo Spread frequency Shift Keying (SFSK) onde a frequncia para o valor lgico 1 115,2 kHz e para o valor lgico 0 de 105,6 kHz. A durao de um bit de 833,33 s. A figura 8 ilustra a codificao dos bits com valor lgico 1 e 0 num sinal de 1,8 Vp e cuja frequncia varia mediante o tipo de valor lgico.

FEUP KNX 2008

33

Ilustrao 8 - Codificao sinal pela rede elctrica

Estes sinais so sobrepostos ao sinal principal de 230 Vac / 50 Hz. A amplitude mxima do sinal transmitido no pode ultrapassar os 116 dBV.

2.3.3 Rdio Frequncia e Infravermelhos

O KNX/EIB permite a utilizao do ar como meio fsico de comunicao. Na norma esto definidos dois tipos de redes que utilizam o ar como meio de transmisso dos dados: a rdio frequncia e os infravermelhos. A rdio frequncia transmite as tramas em sinais de rdio na banda de frequncia de 868 MHz. So chamados dispositivos de curto alcance com um mximo de 25 mW de potncia emitida e uma taxa de transmisso de 16,384 kBits/s. Para a utilizao da rdio frequncia em KNX/EIB, podem ser utilizados componentes de baixo custo que permitam comunicao bidireccional ou unidireccional. A modulao dos sinais em rdio frequncia do tipo Frequency-shift keying (FSK) ou modulao por comutao da frequncia. Como estes meios so abertos necessrio proteger a informao codificando-a. A codificao que a rdio frequncia utiliza a codificao de Manchester. Devido propriedade de este meio fsico ser aberto, necessrio alterar o domnio dos endereos KNX/EIB, para endereos maiores. Por exemplo, no caso de existirem duas redes KNX/EIB vizinhas, podem ocorrer interferncias tais como: ao enviar um pedido de ligar a lmpada no endereo 1/1/2 na rede KNX/EIB de uma

FEUP KNX 2008

34

casa, alm de ligar esta, poder ligar tambm outro dispositivo com o mesmo endereo na rede KNX/EIB da casa vizinha. Estes endereos maiores, so uma combinao de endereos KNX/EIB e o nmero de srie de cada emissor/receptor de rdio frequncia. Com esta soluo garantido que o endereo nico. A especificao da utilizao dos infravermelhos como meio de

comunicao, est definida na norma EIB e que a norma KNX/EIB manteve sem efectuar nenhuma alterao. Este meio de comunicao normalmente utilizado nos comandos de infravermelhos que permitem controlar dispositivos KNX/EIB. Por exemplo, possvel ter um comando de infravermelhos que envie tramas KNX/EIB sob infravermelhos, para uma gateway que contm um receptor de infravermelhos e que passa as tramas para a rede KNX/EIB que poder utilizar por exemplo o meio fsico TP1. A transmisso de dados por infravermelhos assncrona e pode ser unidireccional ou bidireccional mas em half-duplex. A frequncia do sinal que emitido pelo emissor de infravermelhos de 447,5 kHz e o tipo de modulao em amplitude. A taxa de transmisso de aproximadamente 7000 bits/s e a comunicao pode ser bidireccional ou unidireccional como no caso dos comandos de infravermelhos. Os endereos KNX/EIB ao contrrio da rdio frequncia, no so estendidos, so os endereos KNX/EIB normais.

2.3.4 Ethernet
Este meio fsico ao contrrio dos anteriores, no tem nenhum documento na norma que o especifique. Apenas tem uma referncia de que o meio fsico Ethernet utilizado sub o protocolo de rede IP (Internet Protocol). O KNX/EIB, referencia uma norma, herdada do EIB, a EIB.net, que permite a utilizao do KNX/EIB sob redes TCP/IP. A norma denominada por KNXnet/IP est definida na parte 3/8 do KNX Handbook. Est estruturada em cinco captulos, sendo que o primeiro uma introduo e uma viso geral do que a norma e como est estruturada e os quatro restantes captulos so a descrio dos mdulos do KNXnet/IP que sero explicados no captulo 3 desta dissertao. A utilizao deste meio fsico utilizada em paralelo com outro meio fsico como por exemplo o KNX/EIB TP1. A norma KNXnet/IP define um servidor que funciona como uma gateway e que interliga a rede KNX/EIB a uma rede IP.

FEUP KNX 2008

35

2.4 Comunicao
Como foi referido no sub captulo de Arquitectura, o sistema de comunicao do KNX/EIB constitudo por uma pilha protocolar estruturada num conjunto de camadas semelhante ao modelo de 7 camadas OSI. No caso do protocolo KNX/EIB, apenas so implementadas cinco camadas: Fsica, Ligao lgica, Rede, Transporte e por ltimo, a de Aplicao. A camada fsica como foi dito anteriormente, independente das camadas superiores porque o KNX/EIB tem um mecanismo que o permitiu ser independente do meio fsico. Esse mecanismo ser explicado posteriormente. As restantes camadas sero explicadas neste sub captulo.

2.4.1 Camada de Ligao Lgica

A camada de ligao lgica, efectua a interface entre o nvel fsico e a camada de rede. Esta camada costuma vir associada ao meio fsico e aqui que feito o mecanismo que permite que todas as camadas superiores a esta, sejam independentes do meio fsico. Os servios existentes esto representados na figura seguinte:

Ilustrao 9 Servios da camada de ligao lgica

A trama que tratada neste nvel, denomina-se por LPDU e encapsula os dados que vo para as camadas superiores. Numa trama LPDU, o cabealho que tratado neste nvel da ligao lgica, examina o formato da trama, endereo de destino e decide se essa trama lhe destinada. Esta camada, detecta erros de

FEUP KNX 2008

36

transmisso e efectua repeties de tramas. Os servios desta camada sero explicados em pormenor no sub-sub-captulo 2.5.2. Neste nvel feito uma verificao da consistncia dos dados recebidos atravs do teste que feito utilizando o ltimo octeto da trama, o check octet, que realiza um NOT XOR aos restantes octetos da trama.

2.4.2 Camada de Rede

A camada de rede, efectua a interligao entre a camada de ligao lgica e a camada de transporte. Esta camada, recebe tramas enviadas pela camada de ligao lgica, utilizando o servio L_Data e disponibiliza os servios; N_Data, N_GroupData e N_Broadcast para a camada de rede como ilustra a figura seguinte:

Ilustrao 10 Interface com a camada de rede entre os dispositivos KNX/EIB

A trama que circula no nvel de rede, denominada por NPDU e corresponde a uma trama que tem encapsulado os dados que sero enviados s camadas superiores. Em relao ao nvel de ligao lgica, esta trama a resultante de uma trama LPDU sem o cabealho do nvel de ligao lgica que contm: o endereo destino, origem, a informao do comprimento e o octecto de controlo de erros. O cabealho da trama NPDU constitudo por apenas 3 bits situados no octeto 5 e cuja funcionalidade de indicar se os endereos KNX/EIB de destino so do tipo endereos de grupo, individuais ou de broadcast. Se o endereo de destino do tipo individual, a trama enviada para a camada de transporte utilizando os servios do N_Data. Se o endereo de destino KNX/EIB de grupo, a trama enviada utilizando os servios N_GroupData. Quando o endereo KNX/EIB de destino 0 e o tipo de endereo broadcast, a camada de rede envia a trama para a camada de transporte, utilizando os servios de N_Broadcast.

FEUP KNX 2008

37

2.4.3 Camada de Transporte

A camada de transporte realiza a interface entre a camada de rede e a camada superior de aplicao. Implementa os vrios modos de comunicao: o modo multicast, broadcast, um-para-um sem conexo e um-para-todos orientada conexo. Cada modo de comunicao especifica um ponto de acesso que contm vrios servios. Tal como os outros servios, estes contm trs primitivas, o request (req), confirm (con) e o indication (ind). A figura seguinte ilustra os diferentes pontos de acesso dos modos de comunicao e os servios que contm:

Ilustrao 11 Interface com a camada de transporte entre os dispositivos KNX/EIB

A trama da camada de transporte, denominada por TPDU e corresponde trama NPDU mas reduzida, pois no tem o cabealho de controlo de rede. Esta trama contm os dados da camada de aplicao e o cabealho da camada de transporte. Este cabealho composto por um campo de controlo de com o tamanho de 5 bits situados no octeto 5 da trama KNX/EIB. Este campo indica o cdigo do servio da camada de transporte.

2.4.4 Camada de Aplicao

A camada de aplicao corresponde ltima camada superior do modelo OSI. Os servios que esta camada tem, so respectivos aos quatro modos de comunicaes da camada de transporte: o modo multicast, broadcast, um-para-um sem conexo e um-para-todos orientada conexo. Como foi referido anteriormente, uma trama KNX/EIB pode ter at um mximo de 23 octetos. A aplicao utiliza dois bits do octeto 6 e o octeto 7 para identificar o servio. Os restantes octetos so para dados com um limite de 14

FEUP KNX 2008

38

octetos. A trama de aplicao denominada por APDU e vai encapsulada na trama de transporte. Os servios desta camada sero explicados a seguir assim como os objectos de comunicao do EIB, denominados por EIS.

2.4.4.1 Servios
Como foi explicado anteriormente, os servios da camada de aplicao esto organizados em quatro modos de comunicao. Os servios do modo de comunicao broadcast, servem para configurar a rede KNX/EIB. Os servios do modo um-para-um orientado conexo servem para aceder memria do microcontrolador que implementa o protocolo. Quanto ao modo um-para-um sem conexo, serve para alterar ou ler as propriedades dos objectos KNX/EIB como por exemplo; os device objects cujo conceito ser explicado num sub captulo posterior. O modo de comunicao mais utilizado o de multicast que envia tramas de escrita para alterar os valores das sadas do dispositivo KNX/EIB ou trama de leitura para saber qual o estado das entradas. O Domoitech s utiliza os servios deste modo, por isso apenas sero explicados em pormenor os trs tipos de servios: GroupValue_Read, GroupValue_Write e GroupValue_Response. Estes servios alteram ou lem estados de sadas/entradas de um ou mais dispositivos KNX/EIB que pertenam ao endereo de grupo destino da trama recebida. O modo de comunicaes multicast s funciona com endereos de grupo e no com endereos individuais. Os endereos KNX/EIB individuais so utilizados para realizar gesto e configurao dos dispositivos KNX/EIB, porque a actuao/leitura das sadas/entradas, feita atravs de endereos KNX/EIB de grupo. O cdigo do servio que transportado no cabealho da trama da camada de aplicao, pode ter at 10 bits e em alguns dos casos s so necessrios 4 bits. Nos servios do multicast, s sero necessrios 4 bits para os identificar. Assim sendo, os dados podero preenchidos a partir do bit 6 do octeto 7 e os restantes bits tomam o valor 0.

FEUP KNX 2008

39

Os cdigos para os servios so os seguintes:

Ilustrao 12 Cdigos dos servios KNX/EIB modo multicast

de notar que para estes servios o cabealho da trama de rede ter de indicar que pelo menos o endereo de destino um endereo de grupo. Por esta razo, o cdigo do servio s validado em conjunto com o cabealho de rede.

Servio GroupValue_Read
Este servio serve para enviar tramas com pedidos de leitura de estados de variveis ou E/S. O cdigo deste servio tem o valor decimal 0 quando retirados os bits 8, 7, 2 e 1 do octeto 6 e o octeto 7. Para realizar essa validao do cdigo, tem de ser aplicada uma mscara de bits com o valor hexadecimal 0xC3FF aos octetos 6 e 7. O receptor da trama requerente deste servio, dever enviar uma resposta com os estados pedidos, utilizando o servio GroupValue_Res. Um exemplo de uma trama KNX/EIB com este servio a efectuar um pedido de GroupValue_Read para o endereo de grupo 0/0/23 o seguinte:

Ilustrao 13 Exemplo Trama GroupValue_Read

FEUP KNX 2008

40

Servio GroupValue_Res
Este servio serve para enviar tramas de resposta aos pedidos de leitura de estados de variveis ou E/S. O cdigo deste servio tem o valor decimal 1 quando retirados os bits 8, 7, 2 e 1 do octeto 6 e os bits 8 e 7 do octeto 7. Para realizar essa validao do cdigo, aplica-se uma mscara de bits com o valor hexadecimal 0xC3C0 aos octetos 6 e 7. Os estados das variveis vo guardados nos dados, ou seja, so colocados a partir do octeto 7. Se um dos estados um valor binrio ento possvel colocar no octeto 7 porque sobram 6 bits para dados. Um exemplo de uma trama de resposta anterior da ilustrao 13, em que s existe um dispositivo binrio com estado 0 e com o endereo de grupo 0/0/23, o seguinte:

Ilustrao 14 - Exemplo Trama GroupValue_Res

Servio GroupValue_Write
Este servio serve para enviar tramas de escrita em que mudam o estado das varveis ou E/S que estejam no endereo de grupo destino. O valor do estado vai no octeto 7 para o caso de ser binrio ou vai no octeto seguinte para o caso de ser um valor decimal de 8 bits. O cdigo deste servio tem o valor decimal 2. A figura seguinte ilustra o exemplo de uma trama KNX/EIB com este servio que envia um pedido para o endereo de grupo 0/0/23, para modificar um estado que tomar o valor binrio 1.

Ilustrao 15 Exemplo Trama GroupValue_Write

FEUP KNX 2008

41

2.4.4.2 EIS
Os objectos de comunicao do EIB, so os chamados EIS (EIB Interworking Standards), que na norma KNX/EIB no tm essa denominao, mas tm a denominao de Datapoint Types. Esta nova denominao faz mais sentido visto que os EIS so tipos de dados. O Domoitech reconhece apenas dois tipos de EIS: SWITCHING e DRIVE CONTROL. No KNX/EIB estes dois tipos de EIS resumem-se a apenas um Datapoint Type, o boolean. Como o Domoitech foi realizado com os EIS, sero explicados os dois EIS que ele implementa.

EIS 1 - Switching
Este objecto, implementa uma funo com 1bit, logo possvel ter dois estados para actuar numa carga do tipo ON/OFF ligada ao actuador. utilizada esta funo para as lmpadas. No entanto as sadas das lmpadas podem ser utilizadas para qualquer carga do mesmo tipo, como por exemplo: televises, portas elctricas, etc. O EIS 1, tem o valor de 1 bit e o cdigo dele 10 e que pode ter os seguintes estados: (on / off), (enable / disable), (alarm / no alarm) e (true / false).

Ilustrao 16 EIS Switching

FEUP KNX 2008

42

EIS 7 Drive Control

Este objecto consiste em duas subfunes denominadas por move e step. Com a subfuno move possvel colocar o drive em movimento para um sentido ou para o outro. O tempo de movimento escolhido pelo utilizador e facilmente configurvel. Com a subfuno step possvel realizar movimentos graduais em ambos os sentidos. Este tempo de movimento gradual tambm facilmente configurvel. Este objecto utilizado para controlar por exemplo, os estores. A sada do actuador tambm binria, mas neste caso existem duas subfunes: uma coloca a sada num determinado estado a um determinado tempo e a outra subfuno, tambm com os dois estados, mas o tempo bastante inferior em relao ao outro. A subfuno Move utilizada para fechar ou abrir totalmente o estore e pode ter dois estados possveis: mover para baixo ou mover para cima. A imagem seguinte ilustra os dois estados possveis:

Ilustrao 17 EIS Drive Control - Move

A subfuno Step utilizada para fechar ou abrir gradualmente o estore e pode ter dois estados possveis: mover para baixo ou mover para cima. A imagem seguinte ilustra os dois estados possveis:

Ilustrao 18 EIS Drive Control Step

FEUP KNX 2008

43

Para este EIS ser necessrio uma mquina de estado mais complexa em que so necessrios quatro estados possveis: em movimento, parado, gradualmente para cima e gradualmente para baixo. A imagem seguinte ilustra a mquina de estados:

Ilustrao 19 Mquina de estados do Drive Control

FEUP KNX 2008

44

2.5 Interfaces Standard de Comunicao

O KNX/EIB especifica dois tipos de interfaces standards: um para acesso ao meio fsico e outro para acesso camada de ligao lgica. O primeiro standard denominado de Physical External Interface (PEI), estabelece regras de comunicao entre a unidade que contm o interface fsico (BCU, BIM,) e as restantes camadas do protocolo KNX/EIB. O segundo standard, denominado por External Message Interface (EMI) e define as regras de comunicao entre a camada de ligao lgica e a camada de rede. Este standard permitiu que o KNX/EIB fosse independente do meio fsico.

2.5.1 Physical External Interface

O PEI contm especificaes elctricas/mecnica e de software que permitem efectuar o acesso ao meio fsico. Esse acesso pode ser feito atravs de uma transmisso de dados em paralelo ou srie. Existem duas verses para a especificao elctrica/mecnica: a verso de interface de hardware com 10 pinos e a verso de 12 pinos. Devido existncia de resistncias que podem tomar diferentes valores, entre os pinos 5 e 6 em ambas as verses de hardware, permitiu criar 21 tipos de ligaes PEI. Os 21 PEI podem ser agrupados em quatro categorias diferentes: - Utilizaes especiais: PEI tipo 0 para utilizar em aplicaes onde no existe nenhum adaptador, por exemplo, sem a resistncia entre os pinos 5 e 6; PEI tipo 1 este PEI reservado para utilizar quando no existe outro tipo de PEI ou enquanto o outro tipo de PEI no se inicializar; PEI tipo 20 serve para o fabricante efectuar o download de configuraes para a unidade que contm o interface fsico (BCU, BIM,);

- Reservados para futuras extenses: PEI tipos 3, 5, 7, 9, 11, 13, 15, 18;

- Comunicaes em Paralelo: PEI tipo 2, 4, 6, 8, 17 e 19;

- Comunicaes em Srie: PEI tipo 10, 12, 14 e 16.

FEUP KNX 2008

45

Os tipos de PEI mais utilizados so os de comunicao srie. Dentro desses tipos, os PEI tipo 14 e 12 servem para comunicaes srie sncronas e os restantes para comunicaes assncronas excepo do PEI tipo 10 que permite comunicao sncrona ou assncrona. Este ltimo PEI o mais comum devido sua versatilidade apesar de que em quase 100% dos casos utilizado no modo assncrono. Como foi referido anteriormente, nas especificaes elctricas/mecnicas existem dois tipos de interface sendo que o mais utilizado o de 10 pinos. A figura seguinte ilustra os sinais de cada pino numa configurao de interface de 10 pinos:

Ilustrao 20 - Diagrama de pinos de um conector PEI

O pino 5 tem uma tenso de +5 Vdc com uma corrente mxima de 10mA e o pino 8 tem uma tenso de +24 Vdc com uma corrente mxima de 2mA. Os pinos 2, 3, 4, 7 e 9, so de Entradas/Sadas dos dados, que numa comunicao srie correspondem directamente aos sinais: SCLK, RxD/RDI, TxD/TDO, CTS e RTS. O pino 6 para seleco do tipo de PEI, atravs da colocao de uma resistncia entre o pino 6 e pino 5 e que mediante o valor dessa resistncia, seleccionado o PEI. A tabela seguinte contm os valores possveis dessa resistncia e que tipo de PEI definem e ainda uma breve descrio da funo de cada tipo de PEI.

FEUP KNX 2008

46

PEI Tipo 0 1 2 3 4 5 6 7 8 9 10

Descrio do tipo de PEI

Resistncia (k) + tolerncia

Sem adaptador Utilizado quando a aplicao est parada 4 entradas, +1 sada (LED) - Paralelo Reservado 2 entradas / 2 sadas, +1 sada (LED) - Paralelo Reservado 3 entradas / 1 sada, +1 sada (LED) - Paralelo Reservado Reservado Reservado Protocolo de comunicaes srie sncrono ou assncrono tendo como protocolo por defeito p FT 1.2 no modo assncrono. o mais utilizado. Reservado Comunicao srie sncrona Reservado Comunicao srie sncrona com protocolo data block Reservado Comunicao srie sncrona Entradas/Sadas programveis Reservado 4 sadas, +1 sada (LED) - Paralelo Download de configuraes para o BCU/BIM

Sem resistncia 910 5% 430 5% 255 1% 187 1% 140 1% 107 1% 84.5 1% 66.5 1% 54.9 1% 45.3 1%

11 12 13 14 15 16 17 18 19 20

37.4 1% 30.1 1% 24.3 1% 19.1 1% 14.7 1% 11.0 1% 7.50 1% 4.53 1% 2.00 1% 0

Tabela 2 - Valores de resistncia para seleco do tipo de PEI

Tendo em conta que o tipo de PEI mais utilizado o tipo 10 no modo de comunicao assncrono, apenas este ser apresentado explicando o

funcionamento do protocolo que utilizado por defeito, o FT1.2.

FEUP KNX 2008

47

2.5.1.1 Protocolo FT 1.2

Este protocolo baseado na norma internacional: IEC 870-5-1. utilizada uma transmisso de dados balanceada: isto quer dizer que cada estao pode ser simultaneamente uma estao primria (inicia uma transmisso) e uma estao secundria (recebe a mensagem). Qualquer estao pode iniciar uma transmisso porque tm iguais direitos de acesso ao meio, portanto a relao do tipo Mestre/Mestre. So utilizados trs fios: um para recepo de dados (RxD), um para transmisso de dados (TxD) e outro a massa com sinal de 0 V. A transmisso de dados feita com 8 bits de dados e 1 stop bit com paridade par. A taxa de transmisso pode ter um dos seguintes valores: 1200, 2400, 4800, 9600 e 19200, mas por defeito o valor utilizado 19200. O FT1.2 tem trs tipos de tramas: de comprimento fixo, de comprimento varivel e de um s caractere. As tramas de comprimento fixo contm: um caractere inicial cujo valor sempre 10 em hexadecimal e serve para identificar o incio da trama, um caractere de controlo, um caractere de checksum e caractere que identifica o final da trama e que tem sempre o valor 16 em hexadecimal. As tramas de comprimento varivel so as mais utilizadas porque s nestas tramas que possvel enviar dados de utilizador ( tramas KNX/EIB). Estas tramas so iniciadas pelo caractere de incio com o valor 68 em hexadecimal, depois tm dois caracteres que contm o tamanho dos dados de utilizador, um segundo caractere de incio de trama com o valor 68 em hexadecimal, o caractere de controlo procedido pelos dados de utilizador, e no final da trama, um caractere de checksum e para finalizar, o valor 16 em hexadecimal. Outra trama tambm muito utilizada para realizar o acknowledge, a trama de um s caractere. O valor do caractere de E5 em hexadecimal e enviado para dar conhecimento de uma trama bem recebida. Cada caractere das tramas enviado pela linha ( o nvel binrio da linha 1), utilizando um bit de incio com o valor binrio 0, seguido dos 8 bits de codificao do caractere, um bit de paridade e termina com um bit de fim de trama que tem o valor binrio de 1. Em todas a tramas existe o caractere de checksum, que realiza a soma aritmtica em mdulo de 256 para os casos de ocorrer overflow, sobre todos os

FEUP KNX 2008

48

octetos dos dados de utilizador. No caso das tramas de comprimento fixo, este caractere igual ao caractere de controlo. O caractere de controlo contm informao que caracteriza a direco da mensagem, o tipo de servio e suporta mecanismos de controlo de forma a eliminar duplicao de mensagens. Este caractere diferente para tramas enviadas pela estao primria e tramas enviadas pela estao secundria. A imagem seguinte ilustra o caractere de controlo de uma trama enviada pela estao primria:

Ilustrao 21 - Caractere de controlo de uma trama FT 1.2 de uma estao primria

O bit 7 do caractere indica a direco da transmisso da trama: 1 para o sentido de envio por parte do BAU/BIM para o outro dispositivo externo e 0 para o sentido contrrio onde a trama parte do dispositivo externo para o BAU/BIM. O bit 6 indica que a trama parte da estao primria e toma o valor de 1. O bit 5 serve para implementar o mecanismo de evitar repeties de tramas, funcionando como um contador binrio de tramas. Alterna entre 0 e 1 sucessivamente para tramas de Envio/Confirmao. Quando a estao primria envia a primeira trama, coloca o bit contador com o valor 0 e se no receber nenhuma confirmao, volta a enviar uma nova trama com o mesmo bit contador. S quando receber uma confirmao que comuta o estado do bit. O bit 4 encontra-se sempre activado (valor 1) quando a comunicao feita atravs do servio SEND_UDAT. Este servio serve para enviar dados de utilizador, logo o tipo de trama utilizado de comprimento varivel. Os restantes 4 bits indicam o cdigo de funo e as funes possveis so: SEND_RESET que efectua o reset do dispositivo remoto, SEND_UDAT que serve para enviar tramas com dados de utilizador (tramas KNX) e REQ_STATUS que pede uma informao sobre o estado do dispositivo remoto.

FEUP KNX 2008

49

O caractere de controlo de uma trama enviada pela estao secundria um pouco diferente e a imagem seguinte ilustra as diferenas:

Ilustrao 22 - Caractere de controlo de uma trama FT 1.2 de uma estao secundria

Os bits 7 e 6 tm a mesma funo que no caractere de controlo da trama enviada por uma estao primria, sendo que o bit 6 agora toma o valor 0. O bit 5 reservado e o valor dele sempre 0. O bit 4 serve para indicar estao primria que a prxima mensagem que enviar poder causar um overflow. Os restantes 4 bits tal como no caso anterior, servem para indicar o cdigo da funo, mas neste caso as funes possveis so: CONFIRM_ACK que envia tramas de acknowledge positivo, CONFIRM_NACK que envia tramas de acknowledge negativo e RESPOND_STATUS que envia tramas de resposta ao REQ_STATUS.

permitida a transmisso simultnea de dados, visto existirem duas linhas. Contudo, uma estao primria s aceita uma nova mensagem quando a anterior foi entregue com ou sem sucesso. Os erros s so detectados pela estao que recebe a mensagem pois se a estao secundria recebe uma trama corrompida, no envia nenhuma resposta e a estao primria s soube que a trama no foi entregue devido ao tempo de espera de resposta ter terminado. No entanto, a estao primria pode receber a resposta com erros e neste caso volta a retransmitir a trama. A figura 23 ilustra um exemplo de uma transmisso de dados de utilizador com sucesso e outro com distrbios.

FEUP KNX 2008

50

Estao A
SEND_UDAT

Estao B

ACK SEND_UDAT ACK

Transmisso bem sucedida

SEND_UDAT ACK Time-Out SEND_UDAT ACK

Ilustrao 23 - Exemplo de transmisso de dados por FT 1.2

2.5.2 External Message Interface

O EIB criou o conceito da External Message Interface (EMI) que permitiu o EIB ser independente do meio fsico. A EMI serve para troca de tramas entre a camada de ligao lgica e a camada de rede. Contudo, como o EIB definiu a existncia de dois tipos de EMI, a EMI1 e EMI2, o KNX/EIB corrigiu essa diversidade que podia levar a incompatibilidades entre equipamentos de diferentes fabricantes. O KNX/EIB introduziu a Common External Message Interface criando assim uma nica especificao para a EMI com a nova denominao de cEMI, garantindo a compatibilidade total entre produtos de fabricantes diferentes. Uma mensagem cEMI uma estrutura genrica que independente do meio fsico e que pode conter informao adicional como o timestamp ou outro. A figura 24 ilustra em que camadas feita o fluxo de mensagens cEMI.

FEUP KNX 2008

51

Ilustrao 24 - Fluxo de mensagens entre cliente e servidor cEMI

A figura mostra os dois tipos de mensagens cEMI que existem: mensagens de troca de dados na camada de ligao lgica e mensagens de gesto e configurao do dispositivo KNX/EIB.

2.5.2.1 Mensagens cEMI na camada de ligao lgica

Uma mensagem cEMI da camada de ligao lgica, tem uma estrutura bsica constituda por: um octeto inicial que contm o cdigo da mensagem, procedido de um octeto que indica o tamanho do campo que contm informao adicional, os octetos seguintes so a informao adicional (se existir) e a informao que diz respeito ao servio referido no cdigo da mensagem. Esses servios so os diferentes tipos de mensagens cEMI. O apndice 1 contm a tabela com os cdigos de mensagem de todo o tipo de mensagens cEMI. As mensagens cEMI na camada de ligao lgica podem ser de trs tipos de servios: L_DATA, L_POOL_DATA e L_RAW.

FEUP KNX 2008

52

2.5.2.1.1 Servio L_DATA

As mensagens do tipo L_DATA so obrigatrias e utilizadas para enviar os dados (Tramas KNX/EIB). A imagem seguinte ilustra a estrutura bsica de uma mensagem do tipo L_DATA:

Ilustrao 25 - Estrutura bsica de uma mensagem cEMI do tipo L_DATA

At ao octeto Control field 1, o cabealho de uma estrutura cEMI bsica. Todos os restantes octetos so respectivos de cada servio. No servio L_DATA, o Ctrl1 e Ctrl2 so campos de controlo e cada um tem o seu significado: Como podemos observar na figura seguinte, o bit 7 do Ctrl1 representa o tipo de trama KNX/EIB, se estendida (FT=0) ou normal (FT=1). O bit 5 indica se a trama pode ser ou no repetida, r=0 para repetio ou r=1 para no repetio. O bit 4 s aplicvel se o meio fsico for aberto como o caso de redes sem fios. Para o caso de ser system broadcast, SB=0 e para o caso de ser apenas broadcast, SB=1. Os bits 2 e 3 indicam a prioridade da mensagem: 00 para prioridade igual do sistema, 10 para urgente, 01 para normal e 11 para prioridade baixa. O bit 1 indica se necessrio um acknowledge para indicar que a trama L_DATA foi bem entregue. Se for necessrio um acknowledge, a=1 seno toma o valor de 0. O bit 0 utilizado pela funo L_DATA.con e serve para confirmar se houve erros ou no. No caso se ocorrer erros, este bit toma o valor de 1.

FEUP KNX 2008

53

Ilustrao 26 - Control Field 1 do L_DATA

A imagem seguinte ilustra a constituio do Control Field 2:

Ilustrao 27 - Control Field 2 do L_DATA

O bit 7 indica o tipo de endereo KNX/EIB a quem a mensagem se destina. O valor deste bit 0 para o caso do endereo ser individual e 1 para endereo de grupo. Os bits 4, 5 e 6 contm o valor do hop count que decrementado cada vez que passa por um router. Os restantes quatro bits tm a mesma funo que o octeto 7 do Ctrl1, indicam se a mensagem normal ou estendida. Toma o valor de 0000 para mensagem normal e 1xxx para mensagem estendida. Voltando a analisar a imagem 25, depois dos octetos de controlo, seguem-se dois octetos que indicam o endereo KNX/EIB de origem e outros dois que indicam o endereo KNX/EIB de destino. O octeto L contm o nmero de octetos da trama NPDU. Este tamanho igual ao j referido no captulo onde foi explicado o formato de uma trama KNX/EIB. Os restantes octetos, so o que resta de uma trama KNX/EIB deste o octeto que contm o TPCI at ao check octet.

FEUP KNX 2008

54

Existem 3 tipos de mensagens do servio L_DATA: L_DATA.req, L_DATA.con e L_DATA.ind. O L_DATA.req serve para enviar tramas KNX/EIB para o meio fsico. Se o servidor cEMI enviou correctamente a trama KNX/EIB para o meio fsico, envia uma mensagem L_DATA.con para o cliente cEMI a indicar se a trama foi entregue com erro (C=0) ou com sucesso (C=1). A mensagem L_DATA.ind utilizada quando recebido pelo meio fsico uma trama KNX/EIB e o servidor cEMI, passa-a ao cliente cEMI.

2.5.2.1.2 Servio L_POOL_DATA

Este tipo de servio aplicvel apenas quando se utiliza o meio fsico TwistedPair. Este servio opcional. Tal como no servio L_DATA, uma mensagem L_POOL_DATA tem praticamente a mesma estrutura, exceptuando que a partir do endereo KNX/EIB de destino, em vez de conter a NPDU, tem um octeto que define o nmero de slots e para o caso de mensagens L_POOL_DATA.con ainda acrescenta no final um conjunto de octetos que contm os dados. O nmero de slots indica o tamanho dos dados que a mensagem transporta. Ao contrrio do L_DATA, este servio apenas tem as mensagens: L_POOL_DATA.req e L_POOL_DATA.con.

2.5.2.1.3 Servio L_RAW

Este tipo de servio tal como o anterior opcional e a sua utilizao para casos especiais, tais como: teste e diagnstico. Nunca deve ser utilizado quando a rede est a funcionar normalmente, s deve ser utilizado quando a rede se encontra no modo offline. A estrutura de uma mensagem L_RAW mais simples que as anteriores visto s ter o octeto do cdigo da mensagem, a informao adicional e os dados que contm a raw frame.

FEUP KNX 2008

55

Este servio tem as mensagens: L_RAW.req, L_RAW.con, L_RAW.ind e L_BUSMON.ind. excepo da L_BUSMON.ind todas as outras mensagens tm a mesma funo que as do servio L_DATA. O L_BUSMON.ind serve para transportar os acknowledges vindos do meio fsico que a mensagem L_RAW.ind no pode transportar por motivos de diferenciao de tipos de raw frames.

2.5.2.2 Mensagens cEMI de gesto e configurao

A gesto e configurao so feitas localmente no dispositivo KNX/EIB e utilizam-se os seguintes servios: M_PropRead, M_PropWrite, M_PropInfo e M_Reset. O servios de gesto local so confirmados como por exemplo, o M_PropRead.req assim como o M_PropWrite.req, devem ser confirmados se entregues com ou sem sucesso, atravs dos servios M_PropRead.con e M_PropWrite.con respectivamente. Mensagens geradas pelo servidor cEMI, como por exemplo: notificaes de eventos, utilizam o M_PropInfo.ind que um servio que no necessita de confirmao. A figura seguinte, ilustra a estrutura bsica de uma mensagem cEMI de gesto e configurao:

Ilustrao 28 - Estrutura bsica de mensagem cEMI de gesto e configurao

O primeiro octeto contm o cdigo da mensagem. Os cdigos de mensagens encontram-se numa tabela do prefcio 1. Os dois octetos seguintes, indicam o tipo de Interface Object. Existem 14 tipos, sendo que o que mais utilizado o Interface Object tipo 0 que toma o nome de Device Object. Os restantes Interface Objects so utilizados para outras aplicaes que no a de gesto e configurao. O octeto que tem o nome de Object Instance, pode tomar valores de 1 at n e indicam quantas instncias existem do objecto.

FEUP KNX 2008

56

O octeto denominado por PID contm o identificador da propriedade do objecto. No prefcio 1 encontra-se uma tabela com os PID e a respectiva propriedade do Device Object a que se refere. Os dois octetos seguintes, definem o NoE e o SIx, onde o primeiro formado pelos 4 bits iniciais e os restantes 12 so o SIx. O NoE indica o nmero de elementos do array de uma propriedade, se esta tiver uma estrutura de arrays. No caso de a propriedade no for do tipo array, o NoE toma o valor de 1. O SIx o apontador para a posio do primeiro elemento desse array e o primeiro elemento do array encontra-se na posio 1. Os octetos seguintes, contm os dados.

2.5.2.2.1 Servio M_PropWrite

Este servio serve para alterar valores da propriedades de Device Objects. Existem dois tipos de mensagens: M_PropWrite.req e M_PropWrite.con. O M_PropWrite.req enviado pelo cliente cEMI para modificar um valor de uma propriedade do objecto que o servidor cEMI conhece. A estrutura desta mensagem igual estrutura genrica apresentada anteriormente e no campo dos dados, vai o valor ou valores que sero para escrever na propriedade indicada atravs do octeto PID. Como resposta mensagem anterior, o servidor cEMI de gesto, deve confirmar a operao de escrita atravs da mensagem M_PropWrite.con. Quando a resposta positiva (escrita com sucesso), a mensagem no dever contar dados, sendo a sua estrutura igual da mensagem recebida, com os mesmos valores, alterando apenas o cdigo da mensagem e removendo o campo de dados. Quando ocorre algum erro de escrita ou quando o objecto ou propriedade no existe no servidor cEMI, gerido uma mensagem de erro e a resposta ao cliente cEMI deve ser enviada utilizando na mesma a mensagem M_PropWrite.con. Ao contrrio da situao anterior, o campo de dados enviado e nesse campo vai o cdigo do erro da operao. O valor do NoE tambm alterado para o valor fixo de 0 reforando a ideia de que no campo de dados apenas vai o cdigo do erro.

FEUP KNX 2008

57

2.5.2.2.2 Servio M_PropRead

Este servio serve para o cliente cEMI efectuar leituras de propriedades de Device Objects contidos no servidor cEMI. Tal como no servio anterior, existem dois tipos de mensagens:

M_PropRead.req e M_PropRead.con. A mensagem M_PropRead.req enviada pelo cliente cEMI para ler o valor de uma propriedade do objecto contido no servidor cEMI. A estrutura desta mensagem igual estrutura genrica de mensagens de gesto e configurao, exceptuando que o campo de dados no utilizado. Em resposta mensagem anterior, o servidor cEMI envia uma mensagem do tipo M_PropRead.con com a reposta positiva ou negativa. No caso do servidor no encontrar nenhum erro na leitura, envia a resposta positiva em que a mensagem igual recebida anteriormente (M_PropRead.req), mudando apenas o cdigo da mensagem e acrescentado o campo de dados que contm o valor ou valores lidos da propriedade. No caso do servidor cEMI encontrar um erro na leitura como por exemplo, a propriedade ou objecto no existem, ele envia uma mensagem do tipo M_PropRead.con, mas no campo de dados em vez de ir o valor da leitura, vai o cdigo do erro. Para reforar que no campo de dados vai um cdigo de erro, o NoE toma o valor 0.

2.5.2.2.3 Outros servios de gesto e configurao cEMI

Como foi referido no incio, existem mais dois servios utilizados pelo cliente e servidor cEMI. Um deles o M_PropInfo e o outro o M_Reset. O M_PropInfo utiliza apenas uma mensagem do tipo M_PropInfo.ind que deve ser aplicada pelo servidor cEMI para enviar uma notificao de evento para o cliente cEMI. Pode utilizar esta mensagem por exemplo: para avisar o cliente cEMI de que o valor de uma propriedade foi alterado. A estrutura desta mensagem igual estrutura genrica que se encontra na imagem 28. O servio M_Reset tem dois tipos de mensagens: M_Reset.req e M_Reset.ind.

FEUP KNX 2008

58

A mensagem M_Reset.req deve ser utilizada para reiniciar o servidor cEMI por indicao do cliente cEMI. Esta operao normalmente feita quando o cliente cEMI inicializa. Esta mensagem constituda apenas por um octeto que indica o cdigo da mensagem.

Como resposta mensagem anterior, o servidor cEMI deve enviar a mensagem M_Reset.ind ao cliente, avisando-o de que a reinicializao foi feita com sucesso. Tal como a mensagem anterior, esta tambm formada por um s octeto que contm o cdigo da mensagem.

2.6 ETS
O ETS como j foi referido anteriormente, o software criado e fornecido pela organizao KONNEX. Tal como o nome indica: Engineering Tool Software, uma ferramenta para engenharia de sistemas KNX/EIB. O ETS tem vrias utilizaes, sendo que a mais utilizada a de desenho e configurao de uma instalao ou projecto KNX/EIB. Com esta ferramenta tambm possvel, fazer a gesto da rede KNX/EIB. Como j foi referido num sub captulo anterior, um dos modos de configurao: o S-Mode, utiliza um computador com o software ETS para configurar a rede KNX/EIB. Este software contm uma base de dados de todos os produtos e que deve ser fornecida por cada fabricante. Essa base dada contm todas as informaes sobre cada dispositivo KNX/EIB o que permite saber que funes ou aplicaes tem. A pessoa que pretende configurar a instalao KNX/EIB, pode desenhar e configurar toda a rede no modo offline e posteriormente carregar toda a configurao para os dispositivos KNX/EIB. Quando ligado ao barramento KNX/EIB, o ETS comporta-se como um Mestre de Configurao. At data, o ETS vai na verso 3.0d e apresenta duas configuraes: uma para iniciados e outra para profissionais. A verso apresentada a 3.0d para profissionais. Esta a verso mais utilizada pelos instaladores por permitir funes mais avanadas.

FEUP KNX 2008

59

A figura seguinte ilustra a interface inicial na abertura do programa:

Ilustrao 29 - Interface ETS 3.0d Profissional

No menu File, aparecem as funes de abrir ou criar um novo projecto que contm o desenho e configurao da instalao KNX/EIB. No menu View, para alm de ser possvel configurar as barras e janelas que devem aparecer na interface, possvel seleccionar as bases de dados dos fabricantes e efectuar uma pesquisa de produtos nas bases de dados. No menu Diagnostics aparecem as funes que permitem verificar se a configurao est bem feita e permite efectuar testes aos dispositivos KNX/EIB. No menu Extras, surgem as opes de configurar o tipo de ligao entre o ETS e o barramento KNX/EIB, sendo que possvel utilizar o USB, RS232 e o TCP/IP Ethernet. Tem outras funes tais como: manuteno da base de dados, configurar os botes a aparecerem na barras, verificar as licenas, e a funo de colocar o ETS online com a rede KNX/EIB. O software ETS torna-se intil na falta das bases de dados dos fabricantes. Para poder ter acesso a uma base de dados, foi necessrio efectuar o contacto com uma empresa instaladora de sistemas KNX/EIB como o exemplo da empresa Casa das Lampas, revendedora de artigos KNX/EIB da Albrecht Jung que forneceram a base de dados dos artigos deste fabricante. Depois da criao de um novo projecto e da base de dados do fabricante se encontrar inserida no ETS, possvel iniciar a configurao de uma instalao. A figura 30 ilustra a interface obtida quando se pretende procurar e inserir um dispositivo KNX/EIB.

FEUP KNX 2008

60

Ilustrao 30 - Interface de pesquisa e insero de dispositivos KNX/EIB

Nesta janela possvel escolher o fabricante, o tipo de meio fsico que a rede utiliza, a famlia de produtos e o tipo de produto. Depois de escolhidas as categorias pretendidas, efectua-se uma pesquisa seleccionando o boto Find e surge uma lista com todos os dispositivos KNX/EIB que tenham as caractersticas seleccionadas. Depois de seleccionado o dispositivo, insere-se o mesmo no projecto carregando no boto Insert. A figura seguinte ilustra um exemplo de configurao de uma instalao KNX/EIB:

Ilustrao 31 - Interface configurao de uma instalao KNX/EIB

FEUP KNX 2008

61

A instalao do exemplo s contm uma rea e duas linhas. Na criao do projecto, insere-se ou remove-se reas e linhas com muita facilidade e os endereos KNX/EIB so atribudos automaticamente. Em cada linha, inserem-se os dispositivos KNX/EIB da forma que foi explicada anteriormente. Os endereos dos dispositivos so tambm atribudos automaticamente. possvel inserir dispositivos de fabricantes diferentes. Depois de configurada a instalao, basta seleccionar a opo de download e o ETS configura automaticamente cada dispositivo KNX/EIB que esteja na instalao. O instalador apenas tem de ter ateno seleco dos dispositivos KNX/EIB no projecto para no existir a situao de escolher o dispositivo diferente ao que se encontra na instalao fsica. A simplicidade deste software, permite a qualquer pessoa ser capaz de configurar uma rede KNX/EIB sem grandes conhecimentos.

FEUP KNX 2008

62

3 KNXnet/IP
A utilizao das redes de telecomunicaes e das Tecnologias de Informao e Comunicao, tem vindo a aumentar e o custo desse tipo de redes tem diminudo. Actualmente usual existir numa habitao comum uma rede IP onde possvel estar ligado Internet ou at mesmo criar uma PAN (Personal Area Network). O custo de uma rede IP muito reduzido e por essa razo o protocolo Konnex (KNX) permite a sua utilizao como meio fsico. Para poder utilizar KNX sobre uma rede IP foi criado o protocolo KNXnet/IP. O KNXnet/IP uma continuao do EIB.net e esta nova actualizao est definida na norma EN 13321-2. Para uma melhor compreenso, o KNXnet/IP situa-se na camada Fsica do modelo em camadas do KNX e define a integrao do protocolo KNX sobre o protocolo de rede Internet Protocol (IP).

Application Transport Network

Transport ( UDP,TCP)

KNXnet/IP
Services of KNXnet/IP

Data Link Physical

Network (IP)

Physical

Ilustrao 32 - Modelo em camadas do protocolo KNX e KNXnet/IP

FEUP KNX 2008

63

Na figura 32 compreensvel em que camada do protocolo KNX se situa o KNXnet/IP. Os servios do KNXnet/IP so vrios e sero descritos posteriormente. As restantes camadas do KNXnet/IP: transporte, rede e fsica, so as mesmas que o protocolo TCP/IP utiliza. A especificao do KNXnet/IP apenas descreve em pormenor a camada dos servios e indica que se pode utilizar o transporte UDP ou o TCP e a rede a IP. Existem inmeras vantagens em utilizar KNX sobre IP: - permite configuraes remotas da rede KNX; - como a rede IP de velocidades elevadas em comparao com a velocidade num backbone de uma rede KNX (TP1, TP0,), no provoca atrasos nas comunicaes; - permite a superviso e controlo dos dispositivos remotamente.

3.1 Arquitectura
A figura seguinte ilustra um cenrio tpico de um sistema KNXnet/IP onde um dispositivo KNXnet/IP cliente que executa um software de configurao como por exemplo o ETS, acede via uma rede IP aos mltiplos dispositivos KNX instalados em sub redes KNX. Neste exemplo, as sub redes so em Twisted-Pair tipo 1 (KNXTP1), mas podero ter outro meio fsico que a norma KNX permita. O cliente KNXnet/IP pode aceder a um ou todos os servidores KNXnet/IP ao mesmo tempo. No caso dos servidores implementarem tambm o routing, possvel que os servidores possam comunicar entre si. Mais frente ser explicado o que o routing.

FEUP KNX 2008

64

Ilustrao 33 - Exemplo de uma configurao KNXnet/IP possvel

Um sistema KNXnet/IP ter de conter no mnimo os seguintes elementos: - uma sub rede KNX ( KNX-TP1, KNX-TP0, KNX-RF,KNX-PL110,KNXPL132); - um dispositivo que faa interface entre uma rede KNX e uma rede IP que denominado por servidor KNXnet/IP - e adicionalmente poder ser utilizado software para funes remotas num computador ligado rede IP.

FEUP KNX 2008

65

3.2 Mdulos do KNXnet/IP

O KNXnet/IP est organizado por mdulos, o que permite o criador de produtos KNXnet/IP implementar apenas o que lhe interessa diminuindo a complexidade e consequentemente o custo. Os mdulos so os seguintes: - Ncleo; - Gesto de dispositivos; - Tunnelling; - Routing. O mdulo obrigatrio, o ncleo do protocolo que contm as especificaes das tramas KNXnet/IP, os servios bsicos de funcionamento e contm um captulo descritivo do protocolo de rede IP. O mdulo da gesto de dispositivos apenas define servios para efectuar configuraes e gesto de servidores KNXnet/IP. O mdulo de tunnelling consiste em criar um tnel IP, entre um cliente KNXnet/IP e um servidor KNXnet/IP (uma conexo de um-para-um) por onde so trocadas tramas KNX. essencial para poder utilizar o software ETS e configurar os dispositivos KNX que esto ligados a servidores KNXnet/IP. O mdulo de routing utilizado para efectuar o encaminhamento de tramas pela rede. Este mdulo essencial no caso de se pretender que os servidores KNXnet/IP possam trocar mensagens directamente entre si. Essas tramas podem ter origem do prprio servidor, bem como na rede KNX TP1 ligada a esse servidor. Por exemplo, na figura 2, o dispositivo KNX 1.1.2 para comunicar com dispositivos KNX de outras sub-redes (como o exemplo do 3.1.2), necessrio que os servidores de interface rede IP, implementem o routing. Em suma, se for pretendido um servidor KNXnet/IP que possa interligar uma ou mais sub redes a um cliente KNXnet/IP, apenas necessrio implementar o ncleo, gesto de dispositivos e o tunnelling. Um exemplo desta arquitectura a imagem 34.

FEUP KNX 2008

66

Cliente KNXnet/IP (ETS,Falcon)

IP Network
Servidor KNXnet/IP Com tunnelling
KNX Devices

1.1.2 1.1.3 1.1.4

Ilustrao 34 - Exemplo de arquitectura com servidor KNXnet/IP implementando tunnelling

Com esta arquitectura, o software ETS pode configurar um dispositivo KNX como por exemplo: configurar o 1.1.2 utilizando o servidor KNXnet/IP para efectuar a interface entre a rede IP e a rede KNX. de salientar que este tipo de servidor KNXnet/IP no pode comunicar com os outros servidores KNXnet/IP, apenas pode comunicar com clientes KNXnet/IP. Esta soluo utilizada quando se pretende conectar o backbone de uma rede KNX em TP1 a um cliente KNXnet/IP que poder ser um computador que gere e monitoriza a rede KNX. Comea a ser usual encontrar servidores KNXnet/IP destes para poder controlar e monitorizar os dispositivos da casa remotamente utilizando a Internet. Adicionando o mdulo de routing a um servidor KNXnet/IP permite que este possa comunicar com outros servidores KNXnet/IP espalhados pela rede IP. A figura 35 ilustra um exemplo de uma arquitectura com este tipo de servidores.

FEUP KNX 2008

67

Cliente KNXnet/IP (ETS,Falcon)

IP Network
Servidor KNXnet/IP Com routing 1.1.2 2.1.2 2.1.3 2.1.4 3.1.2 3.1.3 3.1.4 Servidor KNXnet/IP Com routing

1.1.3

Ilustrao 35 - Exemplo de arquitectura com servidor servidor KNXnet/IP implementando routing

Com esta soluo possvel por exemplo: o dispositivo KNX 3.1.2 comunicar com os dispositivos KNX 1.1.2 e 2.1.2. Desta forma, possvel interligar uma ou mais sub redes KNX atravs de uma rede IP e assim o backbone da rede KNX passa a ser a rede IP. Estes servidores tambm podem comunicar com os clientes. Este tipo de soluo no to usual visto que aumenta significativamente o custo do projecto KNX. Uma possvel utilizao era em edifcios de grandes dimenses e complexidade onde se pretendia interligar todos os dispositivos do edifcio atravs de uma rede IP. Analisando estas arquitecturas, a soluo ideal por ser a mais completa era de criar um servidor KNXnet/IP que implementasse o ncleo, gesto de dispositivos, o tunnelling e o routing. Por motivos de complexidade e de prazos curtos, decidiu-se implementar apenas o ncleo, gesto de dispositivos e o tunnelling.

FEUP KNX 2008

68

3.3 Ncleo
A especificao do ncleo, contm uma descrio dos servios bsicos de funcionamento do KNXnet/IP assim como as tramas KNXnet/IP, e os conceitos bsicos. Este mdulo obrigatrio implementar num dispositivo KNXnet/IP porque contm a camada bsica do protocolo KNXnet/IP. responsvel pelos servios de discovery e self-description de um servidor. Especialmente para as redes que suportam hot-plug e onde provavelmente a atribuio do seu endereo em runtime (ex: DHCP), importante que haja uma procura dos dispositivos nas sub redes. Por esta razo, foi criado o servio discovery e depois o self-description para saber informaes mais pormenorizadas do dispositivo. O ncleo introduz alguns conceitos como o endpoint, o service container e o HPAI. O endpoint uma abstraco de uma entrada/sada de mensagens KNXnet/IP e KNX. Existem os endpoint: de discovery, controlo e dados. Cada servidor de KNXnet/IP tem de ter obrigatoriamente um endpoint de discovery e poder ter vrios endpoints de dados e controlo. Os endpoints de dados que existem so: o endpoint configurao de dispositivos e o endpoint de encaminhamento de dados que sero explicados posteriormente. O conjunto dos dois endpoints de dados e um endpoint de controlo, denomina-se por service container. de referenciar que para cada ligao a uma sub rede KNX necessrio um service container para cada ligao pois estes no podem ser partilhados. Um Host Protocol Address Information (HPAI), est associado a um endpoint e contm um endereo IP, porta de comunicao IP e o protocolo de transporte (TCP, UDP). Cada endpoint tem de ter um HPAI para fornecer aos dispositivos KNXnet/IP o seu endereamento. Por exemplo: para o endpoint de dados possvel utilizar o protocolo UDP com a porta IP 5001 e com o endereo IP 192.168.105.28. Desta forma, todas as mensagens enviadas pela rede IP como destino o endereo IP 192.168.105.28 e a porta UDP nmero 5001, sero direccionadas para o endpoint de dados.

FEUP KNX 2008

69

Um canal de comunicao uma conexo realizada entre o endpoint de dados do cliente KNXnet/IP e o endpoint de dados do servidor KNXnet/IP. Para estabelecer e manter um canal de comunicao, um servidor deve suportar pelo menos um endpoint de controlo e um endpoint de dados. A figura seguinte ilustra a estrutura bsica de um servidor KNXnet/IP e a funo do ncleo.

Ilustrao 36 - Esquema de um servidor KNXnet/IP e a funo do ncleo

Para o discovery de um servidor KNXnet/IP, o cliente envia um SEARCH_REQUEST para o discovery endpoint dos servidores KNXnet/IP, com o endereo IP de configurao de sistema que existe por defeito em todos os dispositivos KNXnet/IP. Esse endereo de multicast com o IP 224.0.23.12, a porta IP utilizada por defeito a 3671 e o protocolo de transporte utilizado o UDP. Nesta mensagem o cliente envia o HPAI do seu endpoint de controlo para poder receber as respostas ao pedido. Cada servidor KNXnet/IP ter de responder imediatamente com um SEARCH_RESPONSE, para o endpoint de controlo do cliente contendo o protocolo suportado, potencialidades, informao do estado e opcionalmente o nome desse servidor. Nesta mensagem o servidor deve incluir o HPAI do seu endpoint de controlo para comunicaes futuras. A figura 36 contm um exemplo deste servio onde se pode ver as trocas das mensagens. Para estabelecer uma conexo, o cliente envia um CONNECT_REQUEST para o endpoint de controlo servidor KNXnet/IP. Esta mensagem inclui o HPAI do

FEUP KNX 2008

70

endpoint de dados que o cliente deseja utilizar para criar o tnel. O servidor dever responder dentro do tempo de timeout com um CONNECT_RESPONSE contendo o HPAI do endpoint de dados para esta conexo. A figura 36 contm um exemplo de um estabelecimento de conexo.

3.4 Gesto de dispositivos

O mdulo de gesto de dispositivos responsvel pela configurao e gesto do dispositivo KNXnet/IP. Isto poder ser feito via rede IP ou KNX. Para a configurao dos dispositivos necessrio estabelecer uma ligao ponto-a-ponto. Para isso, utiliza-se o endpoint de controlo para estabelecer a ligao (como foi referido na descrio do ncleo) e para o canal de comunicao utiliza-se o endpoint de dados de configurao de dispositivos. Um exemplo de utilizao deste mdulo a troca de informao de configuraes com o software ETS. A figura seguinte ilustra os endpoints que o servidor KNXnet/IP pode ter, evidenciando os endpoints de dados. O endpoint de dados de routing ser explicado posteriormente.

Ilustrao 37 - Endpoints de um servidor KNXnet/IP

FEUP KNX 2008

71

O procedimento para a troca de informao deste mdulo o seguinte: o cliente envia uma trama com o servio DEVICE_CONFIGURATION_REQUEST para o HPAI do endpoint de dados do servidor. Nessa mensagem vai o HPAI do endpoint de dados do cliente. O servidor processa o pedido e responde com um DEVICE_CONFIGURATION_ACKNOWLEDGEMENT num prazo de 10 segundos. A mensagem enviada para o HPAI do endpoint de dados do cliente contendo o HPAI do endpoint de dados do servidor. A configurao e gesto utilizam Interface Objects do KNX para alterar os valores de variveis de dispositivos KNXnet/IP e dispositivos KNX. Cada service container tem possuir os seus prprios Interface Objects e no caso de haver mais do que um service container, cada um deles tem de ter os seus prprios Interface Objects e endereos IP distintos. Este mdulo de gesto de dispositivos altera valores dos vrios Interface Objects. A esses valores, utiliza-se o termo de Property Identifiers (PID). Exemplos de PID: a propriedade que contm o endereo MAC do dispositivo KNXnet/IP, o endereo IP, endereo de multicast, quantas mensagens foram enviadas com sucesso para uma rede KNX ou rede IP, etc.

3.5 Tunnelling
O tunnelling descreve uma ligao de dados ponto-a-ponto numa rede IP e serve para configurar ou para trocar informaes sobre os dispositivos de uma rede KNX. Um cliente KNXnet/IP que implementa o tunnelling, envia uma mensagem cEMI atravs do tnel para um servidor que implemente o tunnelling e este passar a mensagem cEMI rede KNX. de notar que o KNXnet/IP no prev atrasos nas entregas das tramas causadas pelo trfego na rede IP e consequentemente o tempo de transferncia ter de ser inferior ao tempo de timeout do protocolo KNX para transferncia de tramas. O tunnelling utiliza o endpoint de controlo para estabelecer um canal de comunicao como foi descrito no sub captulo do ncleo e o endpoint de dados para a comunicao.

FEUP KNX 2008

72

Existem trs servios diferentes para o tunnelling: - Tunnelling na camada de data link do KNX: Cada dispositivo KNXnet/IP tem de suportar este modo obrigatoriamente. Depois de estabelecida uma conexo com o CONNECT_REQUEST, o servidor KNXnet/IP atribui um endereo de KNX individual para ele prprio e passa-o ao cliente na trama de CONNECT_RESPONSE. Este endereo pode ser configurado e armazenado na propriedade

PID_ADDITIONAL_ADDRESSES. Depois de criado o tnel, o servidor KNXnet/IP envia todas as mensagens KNX ou IP que receber, com destino algum dos seus endereos de grupo, num TUNNELLING_REQUEST para o cliente. Envia tambm mensagens KNX ou IP que receba para o seu prprio endereo. Por exemplo: quando o servidor KNXnet/IP recebe uma mensagem pela rede KNX onde o endereo de destino um endereo de grupo KNX a que ele pertena, este envia a mesma mensagem para a rede IP. Se o servidor KNXnet/IP receber uma mensagem pela rede IP com o endereo IP de destino igual ao dele, retira da mensagem IP a mensagem KNX e envia-a para a rede KNX. Para mais do que uma conexo tunnelling, so necessrios endereos KNX individuais adicionais que tambm sero armazenados na propriedade

PID_ADDITIONAL_ADDRESSES. O servidor gera igualmente tramas IACK para estes endereos adicionais. Se o cliente KNXnet/IP envia uma trama cEMI com o endereo KNX de origem em 0 decimal, o servidor substitui o endereo pelo seu endereo individual e passa a mensagem para a rede KNX. Se o endereo de origem na trama cEMI diferente de 0 decimal, o servidor envia a trama sem a modificar. - Tunnelling sobre um cEMI puro: A implementao deste servio opcional. Neste modo, o servidor passa qualquer mensagem KNX recebida directamente para o cliente conectado. Alm disso, no gera mensagens de IACK. - Tunnelling sobre KNX busmonitor: A implementao opcional. Activando o modo KNX busmonitor poder desactivar outro servio KNXnet/IP para uma sub rede KNX. Este modo no deve ser suportado por um dispositivo que implemente o routing. Para este projecto, apenas ser implementado o servio de tunnelling na camada de data link do KNX.

FEUP KNX 2008

73

3.6 Routing
O routing utilizado para encaminhar mensagens entre dispositivos de redes KNX sobre a rede IP de alta velocidade. Um router KNXnet/IP envia uma mensagem UDP/IP multicast para que outros routers KNXnet/IP na mesma rede a possam receber. Os routers podem substituir as tradicionais linhas KNX e os acopladores de backbone. necessrio ter cuidado quando se atribui o endereo KNX individual a routers para garantir um encaminhamento correcto das tramas KNX e o software ETS foi equipado com mecanismos de garantir as atribuies de endereos correctamente. Um router KNXnet/IP no necessita de estabelecer um canal de comunicao porque o envio das mensagens para a rede IP utiliza endereos multicast. Este mdulo utiliza somente o endpoint de dados de routing. Por defeito, todos os routers KNXnet/IP so configurados com o endereo multicast de setup de sistema referido no sub captulo do mdulo ncleo. O endereo multicast o IP 224.0.23.12 e a porta IP a 3671, registada para este propsito, na Internet Authority for Number Assignment (IANA). [16] de salientar que se existirem duas instalaes KNX diferentes utilizam o mesmo backbone da rede IP, tero de utilizar diferentes endereos de multicast para os seus routers KNXnet/IP. possvel tambm controlar por quantos routers as mensagens podem passar utilizando o TTL (Time To Live) com o valor desejado. Podem ocorrer situaes de overflow no router porque devido velocidade de transmisso de dados numa rede IP ser superior de uma rede KNX, o router no consegue enviar para a rede KNX as tramas todas medida que vo chegando pela rede IP. Nesta situao, os routers KNXnet/IP devem enviar uma mensagem de ROUTING_LOST_MESSAGEM para a rede IP evitando continuar a receber mais tramas sem ter entregue as outras j recebidas.

FEUP KNX 2008

74

3.7 Resumo dos servios do KNXnet/IP

Cada mdulo contm um conjunto de servios e estes sero resumidos nesta seco.

Servios do ncleo:

Search request: Serve para efectuar uma pesquisa de dispositivos KNXnet/IP na rede. enviado por um cliente KNXnet/IP via multicast para os endpoints de discovery de todos os servidores KNXnet/IP escuta. O cliente KNXnet/IP tem de incluir na mensagem de pedido o HPAI do seu endpoint de controlo. Search response: Serve para responder a uma pedido de search request. O servidor KNXnet/IP responde para o endereo unicast que recebeu do cliente KNXnet/IP. Este endereo unicast foi fornecido atravs do HPAI do endpoint de controlo do cliente KNXnet/IP. Nesta mensagem de resposta, o servidor KNXnet/IP inclui o HPAI do seu endpoint de controlo assim como uma descrio do hardware e dos servios que suporta. Description request: utilizado para pedir uma descrio das capacidades e servios suportados por um servidor KNXnet/IP. Este servio utilizado pelo cliente KNXnet/IP que envia o pedido para o endpoint de controlo do servidor KNXnet/IP. A mensagem deve incluir o HPAI do endpoint de controlo do cliente KNXnet/IP. Description response: Serve para o servidor KNXnet/IP responder a um pedido de description request. A resposta enviada para o endereo unicast contido no HPAI do endpoint de controlo do cliente KNXnet/IP. Esta resposta contm vrios Description Information Blocks (DIBs). O DIB fornece informao sobre o meio fsico da rede KNX, o estado do dispositivo, o endereo fsico e unicast, o nmero do projecto de instalao, o nmero de srie, o endereo de multicast de routing, endereo MAC e o nome do servidor KNXnet/IP. Connect request: Serve para enviar um pedido de estabelecimento de um canal de comunicao. enviado pelo cliente KNXnet/IP para o endpoint de controlo do servidor KNXnet/IP. Esta mensagem inclui o HPAI do endpoint de controlo e o

FEUP KNX 2008

75

HPAI do endpoint de dados do cliente KNXnet/IP. Alm disso, contm Connection Request Information (CRI) adicionais, que indica o tipo ligao que se pretende (Tunneling, gesto de dispositivos,). Connect response: Este servio enviado pelo servidor KNXnet/IP como resposta a um pedido de ligao. A mensagem enviada para o endpoint de controlo do cliente KNXnet/IP. Se o endpoint de dados estiver disponvel o servidor KNXnet/IP responde com uma mensagem contendo o identificador do canal de comunicao, informao do estado, o HPAI do seu endpoint de dados e um Connection Response Data Block (CRD). O CRD igual a um CRI. Connection-state request: enviado pelo cliente KNXnet/IP para o endpoint de controlo do servidor KNXnet/IP. Contm o identificador do canal de comunicao e o HPAI do endpoint de controlo. Serve para saber o estado da ligao. Connection-state response: O servidor KNXnet/IP responde ao pedido anterior com o identificador do canal de comunicao assim como o cdigo de estado: sem erro, identificador no encontrado, ligao de dados com erro e ligao KNX com erros. A mensagem enviada para o endpoint de controlo do cliente KNXnet/IP. Disconnect request: Este servio enviado pelo dispositivo KNXnet/IP, normalmente pelo cliente KNXnet/IP, e serve para terminar uma ligao. Esta mensagem enviada para o endpoint de controlo do dispositivo que ir receber a mensagem. A mensagem inclui o HPAI do endpoint de controlo de quem envia a mensagem. Disconnect response: Este servio enviado pelo dispositivo KNXnet/IP, normalmente pelo servidor KNXnet/IP, e serve para confirmar um pedido de disconnect request enviando a mensagem para o endpoint de controlo de quem efectuou o disconnect request.

FEUP KNX 2008

76

Servios da gesto de dispositivos:

Device configuration request: O cliente KNXnet/IP, efectua um pedido de leitura/escrita de um valor de varivel de um dispositivo KNXnet/IP. A mensagem enviada para o endpoint de dados do servidor KNXnet/IP, que este reservou para dados de gesto de dispositivos. Device configuration acknowledge: Este servio a resposta ao pedido anterior. enviado por um dispositivo KNXnet/IP para confirmar a recepo do pedido. Esta mensagem enviada para o endpoint de dados do destinatrio.

Servios do tunnelling:

Tunnelling request: Utilizado para enviar e receber uma mensagem KNX entre um cliente KNXnet/IP e um servidor KNXnet/IP. A mensagem enviada para o endpoint de dados do destinatrio. Tunnelling acknowledge: Este servio a resposta ao pedido anterior. enviado por um dispositivo KNXnet/IP para confirmar a recepo tunnelling request. A mensagem enviada para o endpoint de dados do destinatrio.

Servios do routing:

Routing indication: Utilizado para enviar mensagens KNX sobre uma rede IP. Este servio no necessita de confirmao. A mensagem enviada para o endpoint de dados de encaminhamento do(s) destinatrio(s). Routing lost message: Utilizado para indicao de uma mensagem de encaminhamento KNXnet/IP perdida. Este servio no necessita de confirmao. A mensagem enviada para o endpoint de dados de encaminhamento do(s) destinatrio(s).

FEUP KNX 2008

77

3.8 Formato das tramas KNXnet/IP

Todas as tramas KNXnet/IP contm um cabealho que comum onde o primeiro octeto tem o valor fixo de 6 em decimal e representa o tamanho do cabealho. O segundo octeto representa a verso do protocolo KNXnet/IP que neste momento a verso 1.0. Os seguintes dois octetos descrevem o tipo de servio e os ltimos dois octetos do cabealho so o tamanho do mesmo, mais o tamanho da mensagem. A figura seguinte ilustra o formato das tramas KNXnet/IP e os servios que o protocolo KNXnet/IP fornece.

Ilustrao 38 - Formato das tramas KNXnet/IP

Esta figura tem tambm uma tabela com a estrutura do HPAI,CRI,CRD e DIB que so necessrios em alguns servios para alguns mdulos.

FEUP KNX 2008

78

4 Anlise da arquitectura
No mercado, os dispositivos KNX/EIB possuem na sua maioria uma interface para redes KNX/EIB twisted pair. No entanto, os dispositivos KNX mais recentes permitem a utilizao das redes TCP/IP, recorrendo a um router KNXnet/IP que para alm de conter o protocolo KNXnet/IP, efectua a interface entre o meio fsico TP e a Ethernet. Visto estes routers serem extremamente caros apenas so utilizados quando pretendido ligar redes KNX/EIB mais distantes ou ento quando necessrio poder controlar a rede KNX/EIB atravs da Internet. A utilizao destes routers tem vindo a aumentar e o futuro do KNX/EIB a utilizao crescente das redes TCP/IP como meio fsico. Os dispositivos KNX/EIB poderiam conter eles prprios a interface para rede TCP/IP, mas ficariam ainda mais caros, porque exigiriam mais poder de processamento para conter o protocolo KNXnet/IP e era necessrio acrescentar a interface Ethernet. Tendo em conta isto, o estudo da soluo foi feito para a utilizao redes KNX/EIB sob o meio fsico Ethernet, recorrendo ao protocolo de rede TCP/IP devido sua grande utilizao. Um dos principais requisitos deste trabalho desenvolver um sistema eficiente sem que isso se traduza num elevado preo do produto final. Dado que o preo final do produto em grande parte influenciado pelo custo dos componentes usados na parte do hardware, essencial no momento de desenvolvimento ter em conta a utilizao de componentes standards e de fcil obteno no mercado uma vez que estes se podem adquirir a preos mais competitivos. S assim possvel competir com o produto no mercado, podendo assegurar qualidade e preos baixos. A escolha da arquitectura igualmente importante de forma a escolher a melhor configurao que necessita de menos recursos de hardware e menos dispendiosos. Foram analisadas duas arquitecturas possveis que sero descritas nos sub captulos seguintes.

FEUP KNX 2008

79

4.1 Arquitectura KNXnet/IP

Domoitech

com

Nesta arquitectura, aproveita-se a estrutura de hardware do projecto final de curso Domoitech, efectuando algumas alteraes mnimas. acrescentado ao software do Domoitech, a pilha do KNXnet/IP. O esquema da arquitectura o seguinte:

Ilustrao 39 - Arquitectura Domoitech com KNXnet/IP

Esta arquitectura aproveita o projecto de hardware do Domoitech, fazendo apenas uns melhoramentos no hardware e acrescentar a pilha KNXnet/IP ao software. Com esta arquitectura possvel comunicar com outros dispositivos KNXnet/IP existentes no mercado.

4.1.1 Projecto de Hardware

O projecto de hardware, requer uma anlise dos requisitos do software para que a escolha dos componentes seja optimizada. Aproveita-se a arquitectura de hardware desenvolvido no projecto final de curso Domoitech e alteram-se apenas dois componentes essenciais. Como os requisitos do protocolo KNXnet/IP exigem alguns recursos que a XPORT [10] no possu, necessrio adquirir outra verso superior da XPORT com a denominao de XPORT AR [10]. Esta nova XPORT vem com mais duas portas sries tendo um total de trs

FEUP KNX 2008

80

portas sries: uma para configurao da XPORT atravs de RS232 e duas para utilizar como canais de comunicao para a rede IP. Para poder utilizar os dois canais de comunicao da XPORT AR, necessrio um microcontrolador com duas portas srie. Analisando os microcontroladores PIC [11] com os recursos computacionais necessrios, contendo duas portas sries e o preo, o escolhido foi o PIC18F6520 [11]. As grandes diferenas entre este PIC e o utilizado no projecto Domoitech so: - No nvel fsico o PIC18F6520 mais pequeno porque tem o encapsulamento TQFP; - a memria de programa igual mas a memria de dados maior no PIC18F6520 sendo de 2048 bytes contra os 768 bytes do PIC18F4520 [11] de SRAM e 1024 bytes contra 256 bytes de EEPROM; - o PIC18F6520 tem duas portas srie e o PIC18F4520 tem apenas uma porta srie; - o PIC18F6520 tem 52 entradas/sadas e o PIC18F4520 tem 25 entradas/sadas. Apesar do microcontrolador PIC18F6520 ter dimenses inferiores ao

PIC18F4520, no vai diminuir o tamanho da placa que o alberga porque a XPORT AR maior que a XPORT normal. Outra vantagem de utilizar o PIC18F6520 que ir compensar a diferena de tamanho da XPORT AR para a XPORT de forma a no aumentar o tamanho da PCB.

Mantendo a arquitectura do projecto Domoitech, apenas se efectua alteraes na interface entre o microcontrolador PIC18F6520 e a rede IP. A figura seguinte ilustra o esquema genrico da ligao do microcontrolador rede IP utilizando a XPORT AR.

FEUP KNX 2008

81

Ilustrao 40 - Esquema do hardware evidenciando as ligaes do PIC18F6520 e da XPORT AR

A figura anterior evidencia as ligaes do microcontrolador PIC18F6520 e da XPORT AR. Interpretando a figura: o PIC faz a interface entre uma sub rede KNX e a XPORT AR. de salientar que a sub rede KNX virtual e o PIC liga directamente aos dispositivos sensores/actuadores. O PIC no realiza a pilha TCP/IP por isso apenas codifica a trama KNXnet/IP at camada de servios do KNXnet/IP. Quem acrescenta trama KNXnet/IP o cabealho de transporte e as restantes camadas inferiores do TCP/IP, a XPORT AR. O microcontrolador PIC passa e recebe tramas de e para a XPORT AR atravs de uma das portas srie utilizando o protocolo RS 232. A porta srie nmero 1 da XPORT AR configurada no Connect Mode mas sem endereo IP, com o porto 3671, e UDP. Como no tem um endereo IP configurado, recebe tramas de qualquer dispositivo. Esta porta srie tem a funcionalidade de receber tramas broadcast para o porto 3671 sobre o protocolo

FEUP KNX 2008

COM 1

COM 2

82

UDP. Recebe e envia tramas de e para o discovery endpoint. de referir que os endpoints so criados e geridos pelo microcontrolador PIC. A XPORT apenas direcciona as mensagens para os endpoints existentes no microcontrolador. A porta srie nmero 2 da XPORT AR configurada no Accept Mode para utilizar ligaes TCP. No necessrio configurar nenhum endereo IP remoto visto que a XPORT AR funciona como servidor a aguardar pedidos de ligaes. Apenas necessrio escolher a porta TCP/IP pelo qual ir receber todos os pedidos de ligao, bem como a criao e manuteno de uma ligao TCP. A porta IP escolhida foi a 50001 por se de fcil memorizao e porque est excluda da lista de portas registadas na Internet Authority for Number Assignment (IANA). [16] Esta porta srie recebe e envia mensagens de e para o endpoint de controlo e os endpoints de dados. Surgiu a necessidade de utilizar estas duas portas sries porque eram necessrios dois tipos de endereos IP: de unicast e multicast. Como a XPORT AR no suporta multicast (nem outro dispositivo da mesma empresa), utilizou-se a porta srie 1 para o endereo de broadcast. A porta srie 2 ficou reservada para receber tramas em unicast. Como s discovery endpoint utiliza o endereo multicast, s ele ficou atribudo porta srie 1. Os restantes endpoints utilizam endereos unicast por isso podem utilizar a mesma porta srie 2.

A figura seguinte ilustra a arquitectura de hardware que praticamente igual do projecto Domoitech, diferenciando apenas a ligao da XPORT AR ao mircocontrolador que feita atravs de duas portas srie.

FEUP KNX 2008

83

Regulador 5V Fonte DC 8V-10V Comando IR Receptor IR Regulador 3.3V

PIC18F6520
RS232

Software Programao

Programador PIC

RS232

RS232

XPORT AR

ETHERNET 10/100 Mbits/s

Input/Output RJ11 PC

Input/Output RJ11

Input/Output RJ11

Isolamento ptico

Isolamento Galvnico

Isolamento ptico

Isolamento Galvnico

TRIAC`s

Input

Output

Input

Output

Sensor

Actuador

Sensor

Actuador

Ilustrao 41 - Diagrama de blocos da estrutura de hardware

Nesta arquitectura existe uma placa principal, que contm todo o processamento necessrio e os vrios mdulos de interface com os sistemas exteriores. Existem ainda dois tipos de placas secundrias, diferenciando-se pelas suas sadas, em que uma tem interface de sada utilizando rels e a outra tem interface de sada utilizando TRIACs. A programao do microcontrolador feita on-board, recorrendo a um circuito de interface entre o microcontrolador e a porta srie do PC. Aconselha-se a utilizao de uma fonte DC com uma tenso entre 8V e 10V. Pode-se utilizar uma fonte DC de 12V, mas existir mais energia dissipada nos reguladores de tenso e logo o consumo maior. O microcontrolador tem um receptor de infravermelhos que

FEUP KNX 2008

84

permite receber comandos por aparelhos externos de infravermelhos (ex: comando de tv). Os blocos representados por sensores e actuadores podem ser por exemplo: lmpadas e motores elctricos para os actuadores e os sensores podem ser interruptores. No se optou pela utilizao de uma rede, como por exemplo o Modbus, para interligar a placa principal s placas secundrias, porque aumentaria

significativamente o custo do projecto. Recorreu-se a uma extenso das portas de entrada/sada do microcontrolador para ligar as placas secundrias directamente ao microcontrolador. A alimentao das placas secundrias feita pela placa principal, utilizando um dos pinos da ficha RJ11. Os restantes quatro pinos da ficha so reservados para duas entradas e duas sadas.

4.2 Arquitectura Hbrida

Esta arquitectura, permite comunicar com os dispositivos Domoitech sem efectuar qualquer alterao e permite comunicar com outros dispositivos KNXnet/IP existentes no mercado. A figura seguinte ilustra um esquema desta arquitectura.

Cliente KNXnet/IP (ETS, Falcon)

IP NETWORK

Servidor KNXnet/IP ( PC ou PICOTUX )

Servidor KNXnet/IP ( PC ou PICOTUX )

IP NETWORK

IP NETWORK

Domoitech

Domoitech

Domoitech

Domoitech

Ilustrao 42 - Arquitectura hbrida

FEUP KNX 2008

85

O servidor funciona como uma bridge entre as duas redes, Domoitech e KNXnet/IP. Nesta arquitectura, o servidor KNXnet/IP implementado sobre a tecnologia UNIX para computadores ou para sistemas UNIX embebido (PICOTUX). [14] Na figura anterior, todos os barramentos da rede IP so um s, mas para uma melhor compreenso da estrutura, separou-se os barramentos para reforar a ideia de que so redes diferentes, embora todas possam aceder a um meio fsico partilhado. Para o servidor KNXnet/IP comunicar com uma rede que contm dispositivos Domoitech necessita de ter um mecanismo de software compatvel com as tramas Domoitech porque estas so tramas KNX puras encapsuladas numa trama IP sem qualquer mecanismo referente na especificao do KNXnet/IP.

4.2.1 Projecto de Hardware

Com esta arquitectura, o servidor KNXnet/IP pode estar num computador ou num computador embebido como o exemplo do PICOTUX. [14] O PICOTUX fisicamente semelhante a uma XPORT mas a correr o sistema operativo Linux para sistemas embebidos. Utilizando um computador ou micro computador, o projecto de hardware simples porque s necessrio o computador e a alimentao do mesmo. A figura seguinte ilustra o diagrama de blocos da estrutura de hardware se for utilizado o PICOTUX para realizar o servidor KNXnet/IP.

Ilustrao 43 - Diagrama de blocos da estrutura de hardware FEUP KNX 2008

86

4.3 Comparao de arquitecturas

Para ambas as arquitecturas, o software a desenvolver compatvel e facilmente aplicado em sistemas embebidos sem sistema operativo

(microcontrolador PIC) ou em sistemas operativos ( Linux como tem o PICOTUX e Windows ). Cada arquitectura tm vantagens e desvantagens, mas em termos funcionais so idnticas. Para conseguir identificar as vantagens e desvantagens de cada arquitectura para as poder comparar, necessrio saber o custo do hardware de cada arquitectura. O preo final de um servidor KNXnet/IP da arquitectura Domoitech com KNXnet/IP, semelhante ao projecto Domoitech, diferenciando apenas a diferena de preo dos componentes: XPORT AR e microcontrolador PIC18F6520. A tabela seguinte resume o custo dos componentes de hardware do servidor KNXnet/IP.

Quantidade
1 1 7 7 1 1 1 1 1 1

Descrio
Gc-Xport AR Pic18f6520 TQFP Socket vertical 6/6 pcb Conector modular 6/6 Socket plcc 44 pinos Cristal de 20Mhz Pulsor Lm7805 regulador de 5v Ld1117av33 regulador 3.3v Resistncias Placa PCB 7x7mm

Preo unitrio ()
44.93 7.46 0.70 0.49 0.40 0.43 0.50 0.40 0.92 0.20

Valor ()
44.93 7.46 4.90 3.43 0.40 0.43 0.50 0.40 0.92 0.20

TOTAL Tabela 3 - Custo placa principal Domoitech com KNXnet/IP FEUP KNX 2008

63.57

87

Ao valor final de 63,57 necessrio acrescentar o custo de placas de interface com os sensores e actuadores. O custo mdio dessas placas de 8 . A diferena de custo entre o sistema Domoitech com KNXnet/IP e o sistema Domoitech normal de apenas 3,14. [20] de notar que estes preos foram consultados na empresa Farnell [9], tendo em conta a compra de apenas uma unidade e por isso, torna o preo dos componentes, mais elevado. possvel portanto reduzir o custo do projecto se comprado em bastantes unidades. Existem outros valores que no foram tidos em conta, como os custos de transporte, o custo das placas de circuito impresso e o custo de engenharia. O preo final de um servidor KNXnet/IP da arquitectura hbrida utilizando o PICOTUX o custo do mesmo acrescido do valor do regulador de tenso e dos conectores (RS232 e alimentao). O preo do PICOTUX mais simples de 100 na verso base de 2MB de flash preparado para receber a imagem do LINUX. O custo final dever ser de aproximadamente 122 comprando a verso Picotux 112 com 2 MB Flash.

Vantagens da Arquitectura Domoitech com KNXnet/IP: - Cada servidor KNXnet/IP tem uma rede KNX virtual e utiliza a arquitectura de hardware do projecto Domoitech; - O custo em hardware do servidor KNXnet/IP desta arquitectura em relao ao da arquitectura hbrida, mais baixo; - Implementa uma rede KNX interna.

Desvantagem da Arquitectura Domoitech com KNXnet/IP: - Necessitar de um upgrade na XPORT AR para implementar multicast.

Vantagens da Arquitectura Hbrida: - Pode ser utilizado num PC ou num microPC como o PICOTUX, JACK PC [13], Calao's USB-9260 [15]; - No necessita de efectuar alteraes no projecto Domoitech;

FEUP KNX 2008

88

- compatvel com dispositivos Domoitech e outros dispositivos KNXnet/IP.

Desvantagem da Arquitectura Hbrida: - Soluo mais cara que a arquitectura Domoitech com KNXnet/IP se utilizada com menos de 36 dispositivos Domoitech.

Ilustrao 44 - Grfico comparativo entre as arquitecturas

FEUP KNX 2008

89

FEUP KNX 2008

90

5 Implementao KNXnet/IP

do

Servidor

Depois de analisadas as arquitecturas fsicas do sistema, foi necessrio pensar qual delas iria implementar para posteriormente validar o que foi estudado e desenhado na teoria. Tendo em conta as semelhanas ao nvel de software em ambas as arquitecturas, a opo foi de realizar um software multi-plataforma, para ser facilmente adaptado a qualquer uma das arquitecturas. O software a implementar, seria um servidor KNXnet/IP e por isso, era necessrio um estudo do protocolo para ajudar no desenho da estrutura do mesmo.

5.1 Arquitectura do Software

De forma a realizar o software multi-plataforma, foram estudadas arquitecturas de software diferentes e linguagens de programao indicadas para o propsito. A linguagem de programao escolhida foi o ANSI C, e o compilador o GCC. O ANSI C uma norma publicada pelo instituto de normas nacionais Americanas (American National Standards Institute). Esta linguagem de programao fornece aos programadores, a vantagem de criarem cdigo que facilmente transportado para outras plataformas. A opo de utilizar esta linguagem de programao pela vantagem mencionada e tambm porque o compilador GCC, uma ferramenta livre e existe para diversas plataformas; Windows, Linux, Windows CE, PALM, Mac OS, etc. Depois de estudar o protocolo KNXnet/IP, foram identificados 5 mdulos de software essenciais: ncleo, gesto de dispositivos, tunneling, routing e cEMI. Foi necessrio a criao de um mdulo denominado por knxnet/ip cuja funo de gerir os restantes cinco mdulos e contm todas as definies de objectos KNXnet/IP. Para alm do software ser multi-plataforma, ter de ser funcionar em hardware diferente. Por exemplo, um microcontrolador PIC, contm diferentes interfaces de entradas/sadas em relao a um computador. De forma e contornar este obstculo, foram criados trs mdulos que sero diferentes para um microcontrolador PIC e um computador. Os trs mdulos so: configurao de hardware, HAL(IP) e HAL(TP1).

FEUP KNX 2008

91

O mdulo de configurao de hardware, contm as rotinas de inicializao e configurao das interfaces de entradas/sadas ( portas srie, ethernet, ). Os mdulos de HAL(IP) e HAL(TP1), tm funes semelhantes, servem para realizar a interface aos meios fsicos; TCP/IP sob Ethernet e Twisted-Pair 1 do KNX/EIB. A figura seguinte ilustra a arquitectura de software com todos os mdulos e os sentidos de comunicao entre eles.

Ilustrao 45 - Arquitectura de software

Na figura anterior, foi includo um bloco que contm o software Domoitech e onde visvel a sua interligao ao servidor KNXnet/IP atravs do mdulo HAL(TP1). Inclui tambm o mdulo framing cuja funcionalidade de tratar as tramas KNXnet/IP recebidas pela interface de ethernet. Para um melhor entendimento da funo de cada mdulo, ser feito o resume das funcionalidades de cada um. O HAL(IP) efectua a interface rede TCP/IP ethernet por onde envia e recebe tramas KNXnet/IP encapsuladas em tramas do protocolo TCP/IP. O framing recebe as tramas KNXnet/IP e efectua uma anlise primria da trama atravs da verificao do cabealho. Se for uma trama vlida, passa-a para o mdulo knxnet/ip. Quando recebe uma trama vinda do mdulo knxnet/ip, acrescenta

FEUP KNX 2008

92

o cabealho completando assim a trama KNXnet/IP e envia-a ao mdulo HAL(IP), indicando tambm qual o HPAI de destino. O mdulo knxnet/ip contm as definies de objectos KNXnet/IP como por exemplo; a definio da estrutura de um HPAI ou da estrutura de uma trama KNXnetn/IP. A sua principal funo distribuir as tramas KNXnet/IP para os mdulos correctos. O mdulo do ncleo contm todos os servios que esto definidos na norma KNXnet/IP que o ncleo implementa e que foram referidos anteriormente. Esses servios so: o search request, search response, description request, description response, connect request, connect response, connection-state request, connections state response, disconnect request e disconnect response. O mdulo devicemanagement implementa todos os servios da Gesto de Dispositivos que se encontra definida na norma KNXnet/IP. Os servios so: device configuration request e device configuration acknowledge. O mdulo tunneling contm os servios tunnelling request e tunnelling acknowledge definidos na norma. O mdulo de routing foi criado e preparado para a implementao dos dois servios routing indication e routing lost message. A criao destes servios foi deixada para o final pela inexistncia de um equipamento que permitisse testar estas funes. Este mdulo acabou por no ser preenchido devido ao curto prazo disponvel para a implementao do software. O mdulo cEMI, contm todas as funes e definies para tratamento das tramas cEMI definidas na norma e que esto descritas no sub-sub-captulo 2.5.2. Os mdulos de configuraes KNX e de hardware, contm o que o prprio nome indica. O mdulo configuraes KNX contm a definio e funes para tratamento de tramas KNX, e as propriedades dos device objects que o servidor cEMI gere. Essas propriedades esto definidas na tabela 5 do apndice 1. O mdulo HAL(TP1) tem a mesma funo que o HAL(IP) s que a interface feita com o barramento Twisted Pair 1 do KNX. Este mdulo recebe as tramas KNX do mdulo cEMI e envia-as para o barramento TP1 KNX e se receber alguma trama KNX do barramento TP1, verifica se a trama destinada a ele e envia para o mdulo cEMI.

FEUP KNX 2008

93

Ilustrao 46 - Diagrama UML da estrutura de ficheiros do software

A figura anterior ilustra um diagrama UML em que os componentes so os ficheiros que contm cdigo. Em vez da criao de um ficheiro s albergando todo o cdigo, dividiu-se o cdigo em vrios ficheiros de forma a facilitar a compreenso da estrutura do software apresentada anteriormente. Se observarmos o diagrama UML, reparamos que os ficheiros tm praticamente a mesma estrutura que a arquitectura do software. Desta forma possvel identificar facilmente os mdulos entre o cdigo o que facilita a compreenso das funes existentes em cada ficheiro. Os ficheiros Ncleo, Routing, Tunneling e Device Management contm os respectivos mdulos. O diagrama UML ilustra tambm a dependncia entre as funes existentes nos ficheiros. Aqui notria a dependncia bidireccional que quase todas as funes dos vrios ficheiros tm com funes e variveis do ficheiro KNXnet/IP. Alm da semelhana entre a estrutura de ficheiros e a arquitectura de software representada na figura 45, as dependncias tambm se assemelham aos sentidos de comunicao entre mdulos no diagrama da arquitectura. A nica diferena principal que as funes do ficheiro cEMI, no comunicam directamente com o HAL(TP1) como acontece no diagrama da arquitectura, mas comunicam com as funes existentes no ficheiro tunnelling e estas por sua vez que comunicam com

FEUP KNX 2008

94

o HAL(TP1). O ficheiro main contm a funo principal que serve para inicializar o servidor KNXnet/IP e coloca-lo no modo de escuta dos meios fsicos. O software praticamente a transcrio da norma KNXnet/IP para algoritmia acrescentando uns mdulos de manipulao do hardware. Para validar o software, necessrio efectuar testes a todos os servios do KNXnet/IP. S assim possvel verificar a solidez do mesmo e se todos os mdulos esto a funcionar correctamente.

5.2 Validao e Resultados

Depois da concluso do servidor KNXnet/IP, era necessrio efectuar testes com equipamentos KNX/EIB. Como o acesso a este tipo de equipamentos era muito demorado e no havia muito tempo para efectuar os testes, recorreu-se a vrios softwares aprovados, que pudessem comunicar com equipamentos KNX/EIB sob a rede TCP/IP Ethernet. Um desses softwares o ETS que permite configurar redes KNX/EIB que comuniquem sob TCP/IP Ethernet recorrendo a um servidor KNXnet/IP que funciona como uma gateway entre o barramento TCP/IP Ethernet e o barramento TP1 KNX/EIB. Os outros softwares testados tm a mesma

funcionalidade que o ETS, mas foram criados em projectos de investigao. Para alm do ETS, foram utilizados os softwares; Netn Node [6] que efectua testes e anlises de redes KNX/EIB e uma aplicao de demonstrao que o projecto Calimero [17] fornece. O Calimero um cliente KNXnet/IP realizado em Java formado por um conjunto de APIs que facilitam a criao de aplicaes para controlo e acesso remoto a sistemas KNX/EIB. Para validar todas as funcionalidades do servidor KNXnet/IP criado, era necessrio utilizar adicionalmente uma rede KNX/EIB TP1 para verificar se o servidor conseguia cumprir o seu papel. Ainda no foi criado um software que pudesse simular uma rede KNX/EIB TP1 por isso era necessrio obrigatoriamente um equipamento fsico KNX/EIB. Surgiu a ideia de utilizar o projecto Domoitech que nunca tinha sido testado com outros equipamentos KNX/EIB aprovados e assim, alm de validar o servidor KNXnet/IP, poderia ser possvel comprovar se o Domoitech implementava correctamente o protocolo KNX/EIB sob meio fsico TP1. Como foi explicado no sub captulo do Domoitech, este utiliza o protocolo de rede

FEUP KNX 2008

95

TCP/IP sob Ethernet para simular um barramento TP1. O meio fsico que ele utiliza uma iluso visto que as tramas que circulam no barramento so tramas KNX/EIB TP1 encapsuladas dentro de uma trama IP e como foi explicado anteriormente, este servidor KNXnet/IP multiplataforma criado, tem a funo de colmatar esta no conformidade com o protocolo KNX/EIB. Para poder ligar o servidor KNXnet/IP rede Domoitech, foi necessrio alterar o mdulo HAL(TP1) de forma a que em vez de enviar as tramas KNX/EIB para o barramento TP1, estas teriam de ser encapsuladas numa trama IP e enviadas pelo interface Ethernet que se liga ao barramento TCP/IP Ethernet partilhado com o Domoitech. Para uma melhor compreenso da instalao dos equipamentos na rede de testes, a figura seguinte ilustra o esquema dessa instalao:

Ilustrao 47 - Esquema da instalao da plataforma de testes

Apesar de o meio fsico ser partilhado, nesta instalao temos dois tipos de redes lgicas diferentes. Numa circulam tramas do tipo KNXnet/IP e na outra rede circulam tramas KNX/EIB TP1 encapsuladas numa trama IP normal. Depois da instalao e configurao dos endereos IP dos dispositivos, foi necessrio instalar no computador que tinha os softwares; ETS, Netn Node e a aplicao demo do Calimero, um outro software que permitiria verificar as tramas que passavam no barramento TCP/IP Ethernet. Esse tipo de software denominado

FEUP KNX 2008

96

por Sniffer de rede, cuja funcionalidade escutar continuamente o meio fsico e captar todas as tramas que por l passam. Existe uma variedade grande desse tipo de software, mas optou-se a utilizao do Analyzer [4] que foi desenvolvido no Politcnico de Torino em Itlia. Como foi descrito anteriormente, a validao do servidor KNXnet/IP, ter de ser feita testando o funcionamento de todos os servios do KNXnet/IP. Assim garantido um teste a todos os mdulos do software porque basta um falhar, que os servios no funcionam. Para testar o funcionamento dos servios, recorre-se ao software ETS ou tambm a qualquer um dos outros que j foram mencionados. Para testar alguns dos servios, como os do mdulo de Tunnelling e o mdulo cEMI, tambm necessrio utilizar o Domoitech para comprovar se as tramas KNX so bem construdas pelo servidor KNXnet/IP. Os testes que sero apresentados foram feitos todos com o ETS, mas estes mesmos testes foram realizados utilizando os outros softwares e os resultados foram os mesmos.

5.2.1 Testes aos servios do Ncleo

O primeiro servio que o ETS utiliza o Search Request para procurar servidores KNXnet/IP no barramento. A figura seguinte ilustra a interface da aplicao Analyzer, onde visvel a troca de pacotes TCP/IP sob o protocolo UDP entre o servidor KNXnet/IP e o ETS. O servidor KNXnet/IP tem o endereo IP 192.168.105.142 e o computador que corre o ETS tem o IP 192.168.105.39.

Ilustrao 48 - Teste Search Request

FEUP KNX 2008

97

 visvel na figura 48 que o ETS enviou uma trama KNXnet/IP com o servio Search Request para o endereo IP de multicast 224.0.23.12 e porta UDP nmero 3671. Como foi explicado no captulo da descrio da norma KNXnet/IP, este servio envia as tramas sempre para este endereo de multicast e porta UDP. O servidor ter de responder a este servio com um Search Response e como podemos ver na figura seguinte, o servidor KNXnet/IP, identificou o pedido do ETS e respondeu correctamente.

Ilustrao 49 - Teste Search Response

Os servios de procura e resposta de um servidor KNXnet/IP esto a funcionar correctamente como foi possvel verificar na figura 48 em que recebeu o Search Request e na figura 49 envia a resposta para o ETS como o servio Search Response. Depois do servidor KNXnet/IP conectado ao ETS possvel utilizar os restantes servios. Um dos servios que permitem saber mais informaes sobre o servidor KNXnet/IP o Description. Na figura seguinte possvel identificar a reposta ao pedido de Description Request enviado pelo ETS para o servidor KNXnet/IP.

Ilustrao 50 - Teste Description Response FEUP KNX 2008

98

Se observarmos com ateno a figura 50, o pacote anterior resposta enviada pelo servidor KNXnet/IP, o pedido de Description Request ao qual o servidor responde correctamente. Outro servio importante do Ncleo, o Connect. Existem dois tipos de conexes a criar, uma para o Tunnelling e outra para a Gesto de Dispositivos. Para ambos os pedidos de Connect Request feitos pelo ETS, o servidor KNXnet/IP, respondeu correctamente com o Connect Response indicando o nmero do canal de comunicao criado. Este servidor permite ter at 3 canais de comunicao activos. Esse valor facilmente alterado acedendo ao ficheiro KNXnet/IP que contm a varivel que define esse valor. A figura seguinte ilustra o exemplo de uma reposta a um Connect Request para uma ligao Tunnelling:

Ilustrao 51- Teste Connect Response

Existe um servio de teste da ligao que utilizado pelo ETS para verificar se o canal de comunicaes ainda se mantm activo ou se por algum problema existente (p.ex: quebra da ligao), foi desactivo. Esse servio o Connection State Request ao qual o servidor KNXnet/IP ter de responder com um Connection State Response caso o canal de comunicao esteja activo. A figura seguinte ilustra um exemplo de envio da trama Connection State Response pela parte do servidor KNXnet/IP como resposta ao Connection State Request que recebeu anteriormente.

Ilustrao 52 - TesteConnection State Response FEUP KNX 2008

99

Para terminar uma ligao criada atravs do servio de Connect, utiliza-se o Disconnect. A figura seguinte ilustra a trama de Disconnect Response enviada pelo servidor KNXnet/IP como resposta trama de Disconnect Request que recebeu anteriormente.

Ilustrao 53 - Teste Disconnect Response

5.2.2 Testes aos servios do Tunneling

Depois de iniciado o canal de comunicao de tunneling, dentro desse canal sero iniciadas trocas de tramas do tipo Tunneling Request e como resposta a esta trama, o destinatrio ter de enviar tramas do tipo Tunneling Acknowledge. Estes servios servem para enviar tramas KNX/EIB pelo barramento TCP/IP Ethernet. O servidor KNXnet/IP quando recebe uma Tunneling Request, ter de retirar a trama KNX/EIB que veio encapsulada numa trama cEMI que por sua vez veio encapsulada numa trama KNXnet/IP. Depois envia a trama KNX/EIB directamente para o barramento KNX/EIB TP1 que neste caso o barramento TCP/IP Ethernet que o Domoitech utiliza. A figura seguinte ilustra uma trama do tipo Tunneling Request que enviada pelo ETS cuja trama KNX/EIB tem a funo de mandar ligar a lmpada com o endereo 1 da rede KNX/EIB Domoitech.

Ilustrao 54 - Teste Tunneling Request FEUP KNX 2008

100

Como resposta recepo da trama anterior, o servidor KNXnet/IP envia uma trama de Tunneling Acknowledge ao ETS, informando de que recebeu correctamente a trama anterior e que a ir enviar para a rede KNX/EIB. A figura seguinte ilustra o envio da trama de Tunneling Acknowledge.

Ilustrao 55 - Teste Tunneling Acknowledge

Depois de retirada a trama KNX/EIB, o servidor KNXnet/IP envia-a para a rede Domoitech. A figura seguinte ilustra o envio dessa trama KNX/EIB para a rede Domoitech onde o endereo IP o endereo de broadcast 192.168.105.255.

Ilustrao 56 - Envio de trama KNX/EIB para o Domoitech

Aps o envio da trama KNX/EIB para a rede Domitech, foi verificado que a lmpada com o endereo 1 acendeu-se como era previsto caso ambos os softwares fossem verosmeis. Com este teste, comprova-se que os servios do mdulo Tunneling e cEMI do servidor esto bem implementados e o que Domoitech implementa correctamente o protocolo KNX/EIB sob TP1.

FEUP KNX 2008

101

5.2.3 Testes

aos

servios

da

Gesto

de

Dispositivos
Tal como os anteriores servios do Tunneling, depois de criado o canal de comunicaes para a gesto de dispositivos, as tramas a circularem dentro desse canal so do tipo Device Configuration Request e Device Configuration Acknowledge. No exemplo da figura seguinte, enviada uma trama Device Configuration Request pelo ETS com destino o servidor KNXnet/IP que transporta uma mensagem cEMI do tipo M_PropWrite cuja funo alterar o valor de uma propriedade.

Ilustrao 57 - Teste Device Configuration Request

Como resposta trama anterior, o servidor KNXnet/IP enviou uma trama com o servio Device Configuration Acknowledge para informar o ETS que recebeu correctamente o pedido. A trama de reposta est ilustrada na figura seguinte:

Ilustrao 58 - Teste Device Configuration Acknowledge

Aps a recepo da mensagem cEMI com pedido de alterao do valor de uma propriedade, o servidor KNXnet/IP actualizou de imediato a respectiva varivel com o novo valor. Isto comprova que o mdulo de gesto de dispositivos e o mdulo cEMI de gesto, esto a funcionar correctamente.

FEUP KNX 2008

102

6 Concluso
Esta dissertao teve como objectivo aproveitar o projecto Domoitech para criar uma arquitectura KNX/EIB de baixo custo que pudesse utilizar uma rede IP sob Ethernet. Devido recente aceitao da Domtica no mercado Portugus, os preos das solues existentes ainda so muito elevados. Tm surgido cada vez mais solues proprietrias de Domtica de forma a apresentar produtos a preos competitivos. O problema dessas solues que o cliente ficar de certa forma preso ao fabricante por no existirem no mercado outros equipamentos de concorrncia compatveis com a soluo que adquiriu. A opo de escolher um protocolo normalizado de Domtica serve para colmatar a incompatibilidade com outros equipamentos e permitir ao cliente a opo de escolha entre os equipamentos da concorrncia. O facto de utilizar um protocolo normalizado como o robusto KNX/EIB, aumenta significativamente o custo da soluo. Contudo, possvel rivalizar com a concorrncia no mercado, se a arquitectura for bem estudada ou apresentar solues inovadoras e adequadas s necessidades das pessoas. Depois de um estudo aprofundado do protocolo KNX/EIB e do KNXnet/IP, foram analisadas duas arquitecturas possveis. A arquitectura Domoitech com KNXnet/IP, consiste em efectuar alteraes de hardware e software ao Domoitech para acrescentar a norma KNXnet/IP. A arquitectura hbrida, consiste em manter intacto o Domoitech e criar uma gateway entre o Domoitech e redes KNXnet/IP. Nesta soluo, em vez de colocar o servidor KNXnet/IP dentro do Domoitech, este colocado num dispositivo exterior que pode ser um computador, PDA, etc. No confronto entre as arquitecturas, a mais econmica a arquitectura Domoitech com KNXnet/IP e s compensar a arquitectura hbrida para uma instalao que necessite de mais de 36 placas Domoitech. Apresentadas estas duas arquitecturas, concluiu-se que ao nvel do software foi necessrio criar um servidor KNXnet/IP que pudesse ser multi-plataforma para ser facilmente adaptvel a qualquer uma das arquitecturas. O servidor KNXnet/IP foi desenvolvido na linguagem de programao C no s pela razo de ser uma linguagem que permite multi-plataforma como pela razo de que os compiladores do microcontrolador PIC no fornecem outra linguagem para alm do C e Assembly.

FEUP KNX 2008

103

Aps a implementao do servidor KNXnet/IP, foram realizados testes utilizando vrios softwares como o ETS, Netn Node e uma aplicao feita com o Calimero. Ao longo da implementao do servidor, foram efectuados testes a cada servio e mdulo implementado, e no final efectuaram-se novos testes a cada um dos servios. Utilizando o Analyser pela agradvel interface que fornece, foi possvel verificar todo o trfego no barramento de Ethernet onde estavam ligados o servidor KNXnet/IP, o Domoitech e um computador a correr o ETS. Foi possvel observar o fluxo de tramas KNXnet/IP entre os dispositivos e verificar que os servios do servidor esto a funcionar correctamente. Com este servidor, foi tambm possvel comprovar que o Domoitech tem o protocolo EIB a funcionar correctamente. A configurao testada foi para o caso da arquitectura hbrida, contudo no foram efectuados testes para a arquitectura Domoitech com KNXnet/IP por falta de tempo. Ao longo da realizao deste trabalho o contacto com o mercado esteve sempre presente para uma constante actualizao e ateno s novidades. Visitas a exposies como a Concreta em Outubro de 2007 e pequenas exposies de produtos de alguns fabricantes, permitiram uma constante actualizao sobre o que existe no mercado. Foi notrio que o futuro da Domtica passar pela utilizao de redes TCP/IP sem fios. O KNX/EIB um dos protocolos que suporta este tipo de rede e a soluo apresentada est preparada para a utilizao deste tipo de redes sem fios porque funciona sob o protocolo TCP/IP.

6.1 Desenvolvimentos futuros

Para ser possvel colocar no mercado um produto, so necessrios passos importantes. No basta desenhar o produto, efectuar um estudo de mercado e calcular custos, sero necessrias mais etapas, tais como: a certificao do produto, efectuar testes de conformidade com normas europeias de segurana, etc. Quando se consegue lanar o produto no mercado, j este est ultrapassado, por isso a anlise do mercado ter de ser feita com uma previso futura para altura em que ser lanado o produto. Este trabalho que intitulei como FEUP KNX o incio da criao de uma soluo de domtica de baixo custo que utiliza um protocolo caro como o KNX/EIB e que utilizar a rede TCP/IP sob Ethernet ou as redes Wi-Fi. O principal objectivo do

FEUP KNX 2008

104

FEUP KNX fornecer solues de domtica KNX/EIB de fcil instalao, que no necessite de utilizar outra cablagem e bastante simples. No sero exploradas todas as potencialidades do KNX/EIB, mas no possvel equilibrar o custo com a complexidade. Pontos que no foram completados neste trabalho e que tero de ser implementados futuramente so: - Implementar o cdigo do mdulo de Routing; - Acrescentar o servidor KNXnet/IP ao software do Domoitech para ser possvel testar a arquitectura Domoitech com KNXnet/IP; - Implementar os restantes servios do KNX/EIB no Domoitech; - Melhorar o hardware do Domoitech; - Realizar testes do sistema KNX/EIB do Domoitech a funcionar com dispositivos KNX/EIB de outros fabricantes e - Certificar o produto junto da Konnex.

FEUP KNX 2008

105

Referncias
[1] WIKIPDIA, http://en.wikipedia.org, Fevereiro 2008 [2] MONTEIRO, Jos, Montagem de um sistema didctico utilizando a tecnologia Instabus/EIB da Siemens, FEUP, Dezembro 2004 . [3] DOMODESK, www.domodesk.com, Fevereiro 2008 [4] ANALYZER, http://analyzer.polito.it, Fevereiro 2008 [5] CASAINTELI, http://acasainteligente.blog.com, Fevereiro 2008 [6] NETNNODE, www.netnnode.com, Fevereiro 2008 [7] KNX, www.knx.org, Fevereiro 2008 [8] KNX HANDBOOK, KNX Specification, Konnex Association, Bruxelas, Fevereiro de 2004 [9] FARNELL, ww.farnell.com, Fevereiro 2008 [10] LANTRONIX, www.Xport-RJ45.com, Fevereiro 2008 [11] MICROCHIP, www.microchip.com, Fevereiro 2008 [12] ABB, www.abb.pt, Fevereiro 2008 [13] JADE, www.jadeintegration.com/jackpc.php, Fevereiro 2008 [14] PICOTUX, www.picotux.com, Fevereiro 2008 [15] CALAOS, www.linuxdevices.com/news/NS6730529835.html, Fevereiro 2008 [16] IANA, www.iana.org, Fevereiro 2008 [17] CALIMERO, http://calimero.sourceforge.net, Fevereiro 2008 [18] KNX LIVE CD, https://www.auto.tuwien.ac.at/a-lab/knx-eib.html, Fevereiro 2008 [19] KNXCALIBUR, https://www.auto.tuwien.ac.at/a-lab/knxcalibur.html, Fevereiro 2008 [20] DOMOITECH, Domoitech Domtica com protocolo EIB, Duarte Pinto e Diana Palma, FEUP - DEEC, Julho 2007.

FEUP KNX 2008

106

Apndice 1
A tabela seguinte contm todos os cdigos de mensagens cEMI. Quando um servidor cEMI recebe uma mensagem com um cdigo que no existe nesta tabela, a mensagem ignorada e portanto no enviada uma mensagem de confirmao.

Servio

Cdigo da mensagem cEMI

Destino

L_Busmon.ind L_Raw.ind L_Raw.req L_Raw.con L_Data.req L_Data.con L_Data.ind L_Poll_Data.req L_Poll_Data.con M_PropRead.req M_PropRead.con M_PropWrite.req M_PropWrite.con M_PropInfo.ind M_Reset.req M_Reset.ind

2Bh 2Dh 10h 2Fh 11h 2Eh 29h 13h 25h FCh FBh F6h F5h F7h F1h F0h

Camada de rede Camada de rede Camada ligao lgica Camada de rede Camada ligao lgica Camada de rede Camada de rede Camada ligao lgica Camada de rede Servidor cEMI de gesto Cliente cEMI de gesto Servidor cEMI de gesto Cliente cEMI de gesto Cliente cEMI de gesto Servidor cEMI de gesto Cliente cEMI de gesto

Tabela 4 - Cdigos das mensagens cEMI

FEUP KNX 2008

107

Os servios cEMI de configurao e gesto, tm a funcionalidade de alterar ou ler valores de propriedades de objectos. Existem 14 tipos de objectos no KNX/EIB, mas com estes servios apenas possvel alterar propriedades do Device Object. A tabela seguinte contm as vrias propriedades deste tipo de objecto.

PID

Nome da Propriedade

Tipo

Leitura/ Escrita

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

PID_PROJECT_INSTALLATION_ID PID_KNX_INDIVIDUAL_ADDRESS PID_ADDITIONAL_INDIVIDUAL_ADDRESSES PID_CURRENT_IP_ASSIGNMENT_METHOD PID_IP_ASSIGNMENT_METHOD PID_IP_CAPABILITIES PID_CURRENT_IP_ADDRESS PID_CURRENT_SUBNET_MASK PID_CURRENT_DEFAULT_GATEWAY PID_IP_ADDRESS PID_SUBNET_MASK PID_DEFAULT_GATEWAY PID_DHCP_BOOTP_SERVER PID_MAC_ADDRESS PID_SYSTEM_SETUP_MULTICAST_ADDRE SS

Unsigned Int Unsigned Int Unsigned Int[] Unsigned Char Unsigned Char Unsigned Char Unsigned Long Unsigned Long Unsigned Long Unsigned Long Unsigned Long Unsigned Long Unsigned Long Generic 6 hex Unsigned Long

L/E L/E L/E L/L/E L/L/L/L/L/E L/E L/E L/L/L/-

66 67 68 69

PID_ROUTING_MULTICAST_ADDRESS PID_TTL PID_EIBNETIP_DEVICE_CAPABILITIES PID_EIBNETIP_DEVICE_STATE

Unsigned Long Unsigned Char Unsigned Int Unsigned Char

L/E L/E L/L/-

FEUP KNX 2008

108

70 71 72 73 74 75 76

PID_EIBNETIP_ROUTING_CAPABILITIES PID_PRIORITY_FIFO_ENABLED PID_QUEUE_OVERFLOW_TO_IP PID_QUEUE_OVERFLOW_TO_KNX PID_MSG_TRANSMIT_TO_IP PID_MSG_TRANSMIT_TO_KNX PID_FRIENDLY_NAME

Unsigned Char Unsigned Char Unsigned Int Unsigned Int Unsigned Long Unsigned Long Unsigned Char [30]

L/L/L/L/L/L/L/E

Tabela 5 - Propriedades do device object

FEUP KNX 2008

109