DOMOITECH – Domótica com Protocolo...

DOMOITECH – Domótica com

Protocolo EIB

2006 / 2007

Departamento de Engenharia Electrotécnica e

de Computadores

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Faculdade de Engenharia da Universidade do Porto

Trabalho realizado por:

Diana Sobreiro da Costa Palma – ee05241

Duarte Gonçalves Pinto – ee01163

http://domoitech.pt.vu

Faculdade de Engenharia da Universidade do Porto

DOMOITECH – Domótica com

Protocolo EIB

2006 / 2007

Departamento de Engenharia Electrotécnica e

de Computadores

Julho de 2007

Projecto realizado sob a supervisão de

Prof. Dr. Mário de Sousa,

do Departamento de Engenharia Electrotécnica e de Computadores

da Faculdade de Engenharia da Universidade do Porto

Trabalho realizado por:

Diana Sobreiro da Costa Palma – ee05241

Duarte Gonçalves Pinto – ee01163

Domoitech – Domótica com protocolo EIB – 2007 XIII

Resumo

Este projecto assenta na ideia de criar um sistema Domótico de baixo custo,

em relação às soluções existentes no mercado, e que seja compatível com essas

mesmas soluções.

Neste relatório, será descrito como inicialmente pensamos em várias

soluções e tentamos achar a que para nós é a mais económica e compatível com

soluções existentes no mercado. Esta solução difere das existentes, porque ao invés

de um cliente comprar o seu sistema Domótico por partes, a solução que

apresentamos é para automatizar no mínimo uma divisão da casa.


Prefácio

Os sistemas Domóticos existentes no mercado têm um custo elevado, como

por exemplo, um simples interruptor de parede que funciona em X-10, tem um custo

superior a 50€.

A motivação para a realização deste projecto surgiu na ideia de criar um

sistema Domótico de baixo custo e compatível com outros equipamentos que

existam em mercado.

Numa fase inicial, realizamos um estudo de soluções existentes no mercado

e escolhemos a tecnologia e a arquitectura do sistema, tentando sempre minimizar

os custos.

Em primeiro lugar gostaríamos de agradecer às nossas famílias,

especialmente aos pais e irmãos, por terem estado sempre presentes e nos terem

apoiado ao longo deste percurso escolar.

Ao nosso orientador, professor Mário de Sousa agradecemos a sua

disponibilidade e orientação ao longo deste projecto.

Aos nossos amigos e colegas que nos apoiaram neste percurso universitário

e que partilharam connosco as vivências mais importantes e estiveram sempre ao

nosso lado.


Índice

1 Introdução ...........................................................................................................13

1.1 Protocolos utilizados em Domótica .............................................................15

1.1.1 Protocolo Lonworks.............................................................................17

1.1.2 Protocolo X-10.....................................................................................19

1.1.3 Protocolo EHS .....................................................................................21

1.1.4 Protocolo BatiBUS...............................................................................23

1.1.5 Protocolo EIB ......................................................................................25

1.1.6 Protocolo KNX.....................................................................................27

1.2 Objectivos ....................................................................................................29

1.3 Escolha do Protocolo.........................................................................................30

1.4 Escolha do Meio Físico .....................................................................................32

2 Descrição detalhada do Protocolo EIB..............................................................33

2.1 Camada de Aplicação ..................................................................................35

2.1.1 Serviços EIB.........................................................................................36

2.1.1.1 Serviço GroupValue_Read...............................................................38

2.1.1.2 Serviço GroupValue_Res .................................................................38

2.1.1.3 Serviço GroupValue_Write ..............................................................39

2.1.2 Objectos EIB ........................................................................................39

2.1.2.1 EIS 1 - Switching..............................................................................40

2.1.2.2 EIS 7 – Drive Control ......................................................................40

2.2 Camada de Transporte ................................................................................43

2.3 Camada de Rede ..........................................................................................43

2.4 Camada de Ligação Lógica .........................................................................45


2.5 Camada Física .............................................................................................45

3 Recursos de Hardware ........................................................................................46

3.1 Microcontrolador PIC18F452.....................................................................46

3.2 XPORT .........................................................................................................48

4 Desenvolvimento Hardware................................................................................51

4.1 Estrutura do hardware.................................................................................51

4.2 Placa Principal ............................................................................................53

4.3 Placa Saída a Relés .....................................................................................55

4.4 Placa Saída a Triac’s...................................................................................56

4.5 Comando Infravermelhos.............................................................................57

4.6 Programador................................................................................................58

5 Desenvolvimento Software..................................................................................59

5.1 Estrutura do Software ..................................................................................59

5.1.1 Divisão da Stack por camadas.............................................................61

5.1.2 Descrição dos processos camada física. .............................................63

5.1.2.1 Protocolo RC5 .................................................................................64

5.1.2.2 Mecanismo Recepção de tramas......................................................67

5.1.3 Descrição dos processos camada ligação de dados............................69

5.2 Camada Aplicação.......................................................................................70

5.2.1 Serviços EIB implementados................................................................71

5.2.2 EIS implementados...............................................................................72

5.3 Estruturação de ficheiros.............................................................................73

6 Integração do Sistema.........................................................................................75

7 Conclusão............................................................................................................82

7.1 Custo do Projecto ........................................................................................83


7.2 Futuros Melhoramentos...............................................................................87

Referências ..................................................................................................................88

Anexo A: Descrição Protocolo X-10 ..........................................................................89

Anexo B: Esquema Eléctrico Placa Central ..............................................................92

Anexo C: Esquema Eléctrico Placa Saída em Relés .................................................93

Anexo D: Esquema Eléctrico Placa Saída em Triac’s ..............................................94

Anexo E: Esquema Eléctrico Programador ..............................................................95


Índice de Figuras

Ilustração 1 – Esquema de disposição do sistema pela casa .................................................................14

Ilustração 2 - Trama Batibus..................................................................................................................24

Ilustração 3 – Modelo do Sistema KNX .................................................................................................31

Ilustração 4 – Modelo Camadas OSI vs Modelo Camadas EIB.............................................................34

Ilustração 5 - Formato Trama EIB.........................................................................................................35

Ilustração 6 - Formato de aplicação ......................................................................................................36

Ilustração 7 – Códigos dos serviços EIB................................................................................................37

Ilustração 8 – Exemplo Trama GroupValue_Read ................................................................................38

Ilustração 9 - Exemplo Trama GroupValue_Res ...................................................................................39

Ilustração 10 – Exemplo Trama GroupValue_Write..............................................................................39

Ilustração 11 – EIS Switching ................................................................................................................40

Ilustração 12 – EIS Drive Control - Move .............................................................................................41

Ilustração 13 – EIS Drive Control – Step...............................................................................................41

Ilustração 14 – Máquina de estados do Drive Control ..........................................................................42

Ilustração 15 – Interface com a camada de transporte entre os dispositivos EIB .................................43

Ilustração 16 – Interface com a camada de rede entre os dispositivos EIB...........................................44

Ilustração 17 – Formato da trama NPDU .............................................................................................44

Ilustração 18 – Interface com a camada de ligação lógica entre os dispositivos EIB ...........................45

Ilustração 19 – Diagrama de pinos do PIC18F452 ...............................................................................47

Ilustração 20 – Dimensões Xport ...........................................................................................................48

Ilustração 21 – Atribuição endereço IP da XPORT ...............................................................................49

Ilustração 22 – Configuração Porta Série e Ethernet ............................................................................50

Ilustração 23 - Diagrama de blocos da estrutura de hardware .............................................................52

Ilustração 24 – Placa Principal .............................................................................................................53

Ilustração 25 – Placa Saída Relés..........................................................................................................55

Ilustração 26 – Placa Saída a Triac’s....................................................................................................56


Ilustração 27 – Placa Programador.......................................................................................................58

Ilustração 28 – Estrutura do software....................................................................................................60

Ilustração 29 – Diagrama de blocos das camadas.................................................................................62

Ilustração 30 – Codificação de um bit RC5 ...........................................................................................65

Ilustração 31 –Trama RC5.....................................................................................................................65

Ilustração 32 – Sequência de duas tramas RC5 .....................................................................................65

Ilustração 33 – Modelação de um bit .....................................................................................................66

Ilustração 34 – Diagrama de descodificação das tramas RC5 ..............................................................66

Ilustração 35 – Passagem de vector linear a circular............................................................................67

Ilustração 36 – Incremento do apontador ApPrimeiro ..........................................................................68

Ilustração 37 – Salto do apontador para a posição inicial ....................................................................68

Ilustração 38 – Diagrama de blocos da aplicação.................................................................................70

Ilustração 39 – Estrutura de ficheiros do programa..............................................................................73

Ilustração 40 – Exemplo de uma instalação do Domoitech ...................................................................75

Ilustração 41 – Expositor do projecto ....................................................................................................76

Ilustração 42- Imagem da parte traseira do expositor...........................................................................77

Ilustração 43 - Esquema servidor web ...................................................................................................78

Ilustração 44 –Página web de autenticação...........................................................................................78

Ilustração 45 – Página web de navegação.............................................................................................79

Ilustração 46 – Página web de uma divisão...........................................................................................79

Ilustração 47 – Aplicação feita em Lazarus ...........................................................................................80

Ilustração 48 - Exemplo de uma trama de endereço X-10 .....................................................................91

Ilustração 49 - Exemplo de uma trama de comando X-10 .....................................................................91


Índice de Tabelas

Tabela 1 – Protocolos de Rede utilizados na Domótica.........................................................................16

Tabela 2 – Custo da placa principal ......................................................................................................83

Tabela 3- Custo placa relés....................................................................................................................84

Tabela 4- Custo placa triac’s .................................................................................................................84

Tabela 5- Orçamento para uma casa utilizando Domoitech..................................................................85

Tabela 6 – Orçamento para uma casa utilizando a solução da Siemens ...............................................86

Tabela 7 – Códigos de casa....................................................................................................................89

Tabela 8 - Códigos de unidades e funções .............................................................................................90


Notação e Glossário

Esta secção apresenta os conceitos (glossário de termos) ordenados

alfabeticamente e acrónimos utilizados no corpo do texto do relatório.

EIB - European Installation Bus Association

LON - Local Operating Network

node - Localização de um dispositivo na rede LonWorks. Pode ter acima de 255 variáveis de rede definidas

bps - Bits por segundo

octetos - Oito bits, equivalente a um byte

multicast - Comunicação de muitos para muitos

broadcast - Comunicação de todos para todos

HVAC - Heating, Ventilation, Air-conditioning and Cooling

BIM - Bus Interface Modules

BCU - Bus coupling units

TP - Sigla de Twisted pair , Par entrançado

E/S - Entradas e Saídas

ms - Milissegundos

EIS - EIB Interworking Standards

Dispositivo - Refere-se a uma saída que pode ser ligada a uma lâmpada ou estore

Router - É um equipamento usado para fazer a comutação de tramas entre redes provendo a comunicação entre computadores.

Switch - É um equipamento usado para fazer o encaminhamento de tramas entre computadores distantes entre si.

Fat Client - É uma aplicação cliente numa arquitectura do tipo cliente-servidor e que tipicamente realiza funções e não precisa de um servidor central.

CC - Corrente/Tensão Contínua

CA - Corrente/Tensão Alternada

Domoitech – Domótica com protocolo EIB - 2007 13

1 Introdução

A Domótica é uma tecnologia recente que permite a gestão de todos os

recursos habitacionais. O termo “Domótica” resulta da junção da palavra “Domus”

(casa) com “Telemática” (electrónica + informática). São estes dois últimos

elementos que, quando utilizados em conjunto, rentabilizam o sistema, simplificando

a vida diária das pessoas satisfazendo as suas necessidades de comunicação, de

conforto e segurança. Quando a Domótica surgiu (com o primeiros edifícios, nos

anos 80) pretendia-se controlar a iluminação, condições climáticas, a segurança e a

interligação entre os 3 elementos.

Nos nossos dias, a ideia base é a mesma, a diferença é o contexto para o

qual o sistema está pensado: já não um contexto militar ou industrial mas doméstico.

Apesar de ainda ser pouco conhecida e divulgada, mas pelo conforto e comodidade

que pode proporcionar, a Domótica promete ter muitos adeptos.

A Domótica utiliza vários elementos, que normalmente são independentes,

de uma forma sistémica. Vai aliar as vantagens dos meios electrónicos aos

informáticos, de forma a obter uma utilização e uma gestão integrada dos diversos

equipamentos de uma casa. A Domótica vem tornar a vida mais confortável, mais

segura e até mais divertida! Vem permitir que as tarefas mais rotineiras e

aborrecidas sejam executadas automaticamente. No manuseamento do sistema

poderá faze-lo de acordo com as suas próprias necessidades. Poderá optar por um

manuseamento mais ou menos automático. Nos sistemas passivos o elemento

reage só quando lhe é transmitida uma ordem, dada directamente pelo utilizador

(interruptor) ou p Nos sistemas mais avançados, com mais inteligência, não só

interpreta parâmetros, como reage ás circunstâncias (informação 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 habitação deixa de ser uma utopia. A

Domótica permite o acesso às funções vitais da casa, como aquecimento,

electrodomésticos, alarme, fechaduras das portas, quer seja através de um

comando remoto, da Internet ou do seu telemóvel. [1]


Existem algumas soluções no mercado, mas os produtos são ainda muito

caros. O principal objectivo deste projecto é criar um sistema de controlo de

dispositivos existentes na casa apresentando uma solução mais económica.

Analisando várias opções e arquitecturas, optamos por uma solução

descentralizada, composta por uma placa com os sensores e actuadores que será

colocada em cada divisão da casa e que estarão ligadas num bus que contém todas

as placas e poderá ter um computador central que funciona como servidor web,

permitindo assim o acesso pelo exterior de forma a controlar remotamente os

equipamentos. Esta arquitectura é melhor que uma arquitectura centralizada na

medida em que não é necessário utilizar um servidor central para gerir todas as

placas e assim não se tinha o problema do servidor falhar, toda a rede deixava de

funcionar. Isto para não falar de que um computador central para gerir a rede era

mais um custo acrescido.

A figura seguinte ilustra a disposição das várias placas pelas divisões e a sua

ligação em rede a um computador servidor que poderá ou não ser utilizado:

Ilustração 1 – Esquema de disposição do sistema pela casa


1.1 Protocolos utilizados em Domótica

A gestão da rede que será utilizada para interligar as placas e um

Computador servidor, é uma questão complexa; requer, em particular, a realização

de um grande número de funções bem diferenciadas e com diversos graus de

dificuldade.

A escolha das regras de comunicação (protocolo) entre os dispositivos da

rede, terá de ser adequada para o sistema em causa.

É grande a variedade de protocolos standards direccionados para a

Domótica. É necessário diferenciar quais os que são proprietários e os de alianças

ou grupos de trabalho e ainda quais são livres e abertos.

Cada protocolo pode utilizar um ou vários meios físicos e como tal, numa

fase inicial não é muito importante a escolha do meio físico.

O nível inferior físico é a junção das camadas de rede, ligação de dados e

física do modelo OSI, e diz respeito a que meio físico iremos utilizar e que pode ser

independente das camadas superiores. Possíveis meios físicos a utilizar é o

bluetooth, wifi, modbus, rádio-frequência, par-entrançado, infravermelhos, corrente

eléctrica, RS232, RS485, ethernet, S.N.A.P....

A camada de aplicação é onde se situa o protocolo de comunicação. A

escolha do protocolo terá de ser bem analisada.

Os protocolos mais utilizados actualmente na Domótica são o X-10 e o

EIB/KNX. A tabela seguinte apresenta uma breve descrição de alguns Protocolos

standards utilizados na Domótica [3] :

Protocolos de Rede - Alianças e Grupos de Trabalhos

Standard Meio Físico Descrição

BatiBUS Par Entrançado

Sensores de união e actuadores para construir sistemas que controlem HVAC (Ar Condicionado),

sistemas de segurança e acesso. Em convergência com EIB e EHS para KNX.

CEBus (Consumer Electronics

Bus)

Todos O Standard CEBus (EIA-600) é um protocolo criado pela Associação de Industrias Electrónicas

(EIA) para ser possível a interligação e comunicação entre dispositivos electrónicos da

casa.


EIB (European Installation Bus)

Par Entrançado

Sensores e actuadores para construir sistemas que controlem HVAC (Ar Condicionado), sistemas

de segurança e acesso. Em convergência com EHS e BatiBus para KNX.

EHS (European Home System)

Todos Uma colaboração entre industrias e governos Europeus sobre Domótica. Entre alguma das suas

missões a EHSA tem o objectivo de ser um standard na Europa de um BUS comum (EHS). Em convergência com EIB e BatiBus para KNX.

HomeRF (Home Radio

Frequency Working Group)

RF A missão do grupo de trabalho HomeRF é tornar possível uma vasta gama de produtos electrónicos de consumo que operem entre si, estabelecendo

uma especificação aberta para comunicações digitais de RF (sem licença), para PC,s e produtos

electrónicos de consumo em qualquer sitio e arredores da casa.

LonMark Interoperability

Association

Todos A associação LonMark tem a missão de integrar facilmente dispositivos baseados em redes LonWorks, fazendo uso de ferramentas e

componentes standards.

ZIGBEE RF Pensa-se que este pode ser um dos standards que irá ser bastante utilizados no mundo da

domótica. É uma versão melhorada do HomeRF e destinada a ambientes industriais.

Protocolos de Rede - Proprietários

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.

X-10 Corrente eléctrica/RF

O protocolo mais utilizado na domótica, utiliza a rede eléctrica e facilita o controlo de dispositivos

domóticos sem instalação de qualquer fio em casa, por utilizar a instalação de rede eléctrica já

existente.

Tabela 1 – Protocolos de Rede utilizados na Domótica

Desta vasta lista de protocolos, apenas estudamos os mais encontrados em

sistemas existentes no mercado que são: Lonworks, X10, EHS, BatiBUS, EIB e

KNX.


1.1.1 Protocolo Lonworks

LonWorks é uma plataforma de trabalho em rede criada especificamente

para dirigir-se ao desempenho, à confiabilidade, à instalação, e às necessidades

originais da manutenção de aplicações de controlo. A plataforma é construída num

protocolo de largura de banda baixo criado por Echelon Corporation para

dispositivos de trabalho em rede utilizando meios físicos como o twisted pair, os

powerlines, o sistema de fibra-óptica, e o RF. É bastante utilizado para a

automatização de várias funções dentro dos edifícios, tais como a iluminação e os

sistemas HVAC. [1]

O protocolo de comunicação (LonTalk) implementa vários serviços que

fornecem robustez e eficiência de comunicação. As principais vantagens deste

protocolo são:

• O projectista de produtos compatíveis com LONWORKS não precisa

conhecer detalhadamente a informação que circula numa rede.

• Fornece aos instaladores de redes LONWORKS, uma enorme flexibilidade

em seleccionar e configurar os nós de uma rede

• Assegura a previsibilidade do comportamento de uma rede, sob todas as

circunstâncias.

O êxito que o LonWorks tem tido em aplicações profissionais nas quais importa

muito mais a fiabilidade e a robustez que o preço em si, deve-se a que desde a

origem oferecem uma solução com arquitectura descentralizada, ponto-a-ponto, que

permite distribuir a inteligência entre os sensores e os actuadores instalados e que

cobre desde o nível físico até ao nível de aplicação a maioria dos projectos de redes

de controlo.

Qualquer dispositivo LonWorks, ou nodo, está baseado num microcontrolador

especial chamado Neuron Chip. Tanto este circuito integrado como o firmware que

implementa o protocolo LonTalk foram desenvolvidos pela Echelon no ano de 1990.

Em relação ao Neuron Chip podemos salientar:

• Tem um identificador único, o Neuron ID, que permite direccionar qualquer

nodo de forma unívoca dentro de uma rede de controlo LonWorks. Este


identificador, com 48 bits, é gravado na memória EEPROM durante o fabrico

do circuito.

• Tem um modelo de comunicação que é independente do meio físico sobre o

qual funciona, isto é, os dados podem transmitir-se sobre cabos de pares do

tipo telefónico, correntes portadoras, fibra óptica, radiofrequência,

infravermelhos e cabo coaxial, entre outros.

• O firmware que implementa o protocolo LonTalk, proporciona serviços de

transporte e routing ponto-a-ponto.

Estes circuitos comunicam entre si enviando telegramas que contêm a direcção

do destinatário, informação para o routing, dados de controlo assim como os dados

da aplicação do utilizador e um checklist como código detector de erros. Todas as

comunicações de dados são iniciadas num Neuron Chip. Um telegrama pode ter até

229 octetos de informação para aplicação distribuída.

Os dados podem existir sob duas formas:

As mensagens explícitas são a forma mais simples de enviar e receber

dados entre duas aplicações residentes em dois Neuron Chip do mesmo segmento

LonWorks.

As variáveis de rede proporcionam um modelo estruturado para a troca

automática de dados distribuídos num segmento LonWorks. São menos flexíveis

que as mensagens explícitas mas evitam que o programador da aplicação

distribuída esteja dependente dos detalhes das comunicações.

Meio Físico

O Neuron Chip proporciona uma porta específica de cinco pinos que pode

ser configurada para actuar como interface de diversos transmissores-receptores de

linha e funcionar a diferentes velocidades binárias. O LonWorks pode funcionar

sobre RS-485 com isolamento óptico, acoplado a um cabo coaxial ou de pares

entrançados, sobre correntes portadoras, fibra óptica e inclusivamente

radiofrequência ou infravermelhos. O transmissor-receptor é encarregado de adaptar

os sinais do Neuron Chip aos níveis de que necessita cada meio físico. [4]


1.1.2 Protocolo X-10

O X-10 é o protocolo mais antigo usado nas aplicações domóticas. Foi

desenvolvido entre 1976 e 1978 com o objectivo de transmitir dados por linhas de

baixa tensão (110V nos EUA e 230V na Europa) a muito baixa velocidade (60 bps

no EUA e 50 bps na Europa) e com custos muito baixos. Ao usar as linhas eléctricas

da habitação, não se torna necessário ter novos cabos para ligar os dispositivos.

Graças ao seu amadurecimento (mais de 20 anos no mercado) e à

tecnologia implementada, os produtos X-10 têm um preço muito competitivo sendo

líderes no mercado residencial Norte-Americano com as instalações a serem

realizadas por electricistas sem conhecimentos de automação ou informática ou até

pelos próprios utilizadores.

O X-10 é de momento a tecnologia mais acessível para a realização de uma

instalação domótica não muito complexa. Contudo, tem a desvantagem de ser um

protocolo pouco robusto.

Meio Físico

O protocolo X-10 usa uma modulação muito simples quando comparado com

as que são usadas noutros protocolos de controlo por correntes portadoras. O

Transmissor/Receptor do X-10 está dependente do ciclo da onda sinusoidal de 50hz

para introduzir um instante depois desta passar pelo zero um sinal muito curto numa

frequência fixa.

Pode introduzir-se este sinal nos ciclos positivo ou negativo da onda

sinusoidal. A codificação de um bit 1 ou de um bit 0, depende de como este sinal é

emitido nos semiciclos. O 1 binário é representado por um impulso de 120 kHz

durante 1 milissegundo e o 0 binário é representado pela ausência desse impulso de

120 kHz. Num sistema trifásico o impulso de 1 milissegundo é transmitido três vezes

para que coincida com a passagem pelo zero das três fases.

Como tal, o tempo de 1 bit coincide com os 20msg que dura o ciclo do sinal,

de forma a que a velocidade binária de 50 bps é imposta pela frequência da rede

eléctrica que temos na Europa.

A transmissão completa de um telegrama X-10 necessita de onze ciclos de

corrente. A trama divide-se em três campos de informação:

- Dois ciclos representam o Código de Início


- Quatro ciclos representam o Código de Casa (letras de A-Z)

- Cinco ciclos representam o Código Numérico (1-16) ou o Código de Função

(acender a luz, apagar a luz, variar a luz, etc...).

Para aumentar a fiabilidade do sistema, esta trama, (Código de Inicio, Código

de Casa e Código de função ou numérico) transmite sempre duas vezes, separadas

por três ciclos completos de corrente. Há uma excepção, nas funções de variação de

intensidade é transmitido de forma contínua (pelo menos duas vezes) sem

separação entre tramas.

Protocolo

Existem três tipos de dispositivos X-10: os que só podem transmitir ordens,

os que só as podem receber e os que as podem receber e enviar.

Os transmissores podem direccionar até 256 receptores. Os receptores vêm

dotados de dois pequenos comutadores giratórios, um com 16 letras e o outro com

16 números, que permitem identificar uma direcção das 256 possíveis. Numa

mesma instalação pode haver vários receptores configurados com a mesma

direcção, todos realizam a função pré-designada, desde que um transmissor envie

um telegrama com esta direcção. Evidentemente qualquer receptor pode receber

ordens de diferentes transmissores.

Os dispositivos bidireccionais, têm a capacidade de responder e confirmar a

realização correcta de uma ordem (feedback), a qual pode ser muito útil quando o

sistema X-10 estiver ligado a um programa de visualização que mostre os estados

em que se encontra a instalação. [4]

No Anexo A encontra-se uma descrição pormenorizada do tipo de tramas do

protocolo e as tabelas contendo os códigos.


1.1.3 Protocolo EHS

O protocolo EHS (European Home System) foi uma das invenções que a

indústria europeia no ano de 1984, apoiada pela Comissão Europeia para criar uma

tecnologia que permitia a implantação da domótica no mercado residencial do forma

massiva. O resultado foi a especificação do EHS no ano de 1992. Esta baseada

numa topologia de camadas OSI em quais se especificam os níveis: físico, ligação

de dados, rede e de aplicação.

Desde o início estiveram envolvidos: os fabricantes europeus de

electrodomésticos mais importantes, empresas de electricidade, operadoras e

telecomunicações e os fabricantes de equipamento eléctrico. A ideia era criar um

protocolo aberto que permitiria cobrir as necessidades de interligação dos produtos

de todos os fabricantes e provedores de serviços.

Tal como foi pensado, o objectivo da EHS é cobrir as necessidades de

automatização da maioria das vivendas europeias cujos proprietários que não se

podem dar ao luxo de utilizar sistemas mais potentes e mais caros devido à mão de

obra especializada que exigem essas instalações.

O EHS vem a cobrir, por prestações e objectivos, a parcela que têm no

CEbus norte-americano e o HBS japonês

Nivel Físico

Durante os anos de 1992 a 1995 a EHSA suportou o desenvolvimento de

componentes electrónicos que implementaram a primeira especificação. Como

resultado nasceu um circuito integrado da ST-Microelectronics (ST7537HS1) que

permitia transmitir dados por um canal série assíncrono através das linhas de baixa

tensão das vivendas (ondas portadoras ou "powerline communications"). Esta

tecnologia, baseada na modulação FSK, consegue velocidades superiores a 2400

bps e também podem utilizar cabos de pares entrançados como suporte de o sinal.

Actualmente, estão a ser utilizados os seguintes meios físicos:

- PL-2400: Ondas Portadoras a 2400 bps.

- TP0: Par Entrançado a 4800 bps (idêntico ao nível físico do BatiBUS).


- TP1: Par Entrançado/Coaxial a 9600 bps.

- TP2: Par Entrançado a 64 Kbps.

- IR-1200: Infravermelhos a 1200 bps.

- RF-1100: Radiofrequência a 1100 bps.

Protocolo

Este protocolo está totalmente aberto, isto é, qualquer fabricante associado à EHSA

pode desenvolver os seus próprios produtos e dispositivos que implemente o EHS.

Com uma Plug&Play, é pretendido contribuir para as seguintes vantagens aos

utilizadores finais:

- Compatibilidade total entre dispositivos EHS.

- Configuração automática dos dispositivos, mobilidade dos mesmos e ampliação

fácil das instalações.

- Compartilhar o mesmo meio físico entre diferentes aplicações sem interferir entre

elas.

Cada dispositivo EHS tem associada uma subdirecção única dentro do

mesmo segmento de rede que para além de identificar univocamente a um nodo

também leva associada informação para receptor dos telegramas por diferentes

segmentos de rede EHS.

Depois da aparição de diversos produtos e soluções baseadas em EHS, esta

tecnologia está a convergir juntamente com o EIB e o BatiBUS para um standard

europeu chamado KNX. [5]


1.1.4 Protocolo BatiBUS

Inicialmente projectado para interligar sensores inteligentes, actuadores e

unidades terminais de controlo, num edifício, o sistema BatiBUS foi criado em 1988,

em França, por Merlin Gerin, AIRELEC, EDF e LANDIS & GYR. Foi também o

primeiro bus de campo a aparecer no mercado.

Em 1989, as referidas companhias decidiram criar o BCI (BatiBUS Club

International) com o intuito de desenvolver produtos que comunicassem sobre

BatiBUS. Dotaram-no também de um conjunto completo de ferramentas de apoio.

Hoje em dia, o BCI já tem mais de 80 parceiros em muitos países, contando com

seis delegações nacionais (Espanha, França, Grã-Bretanha, Itália, Holanda e "outros

países").

O BCI escolheu o LCIE (Laboratoire Central des Industries Electriques) para

a certificação dos produtos, a qual permite garantir a conformidade à norma de

referência do protocolo BatiBUS e a inter operacionalidade de produtos diferentes

sobre BatiBUS.

Trata-se de um bus único que permite a intercomunicação entre todos os

módulos (CPUs, sensores e actuadores) do sistema de controlo de aquecimento, ar

condicionado, iluminação, etc.

O suporte físico do BatiBUS é um simples par entrançado, isolado ou não,

dependendo do tipo de ambiente electromagnético, que alimenta os sensores que

lhe estão acoplados. Um único cabo BatiBUS é suficiente para controlar todas as

operações no mesmo edifício e permite alimentar dispositivos que não consumam

mais de 3 mA.

O BatiBUS pode usar qualquer topologia de rede: bus, estrela, token-ring,

combinações destas, etc. A sua arquitectura flexível torna o sistema fácil de

aumentar.

O BatiBUS usa um protocolo aberto, baseado em CSMA/CA (Carrier Sense

Multiple Access with Collision Avoidance), descrito nas normas francesas NFC

46620 e secções seguintes, nas normas europeias (CENELEC) e mundiais (ISO/IEC

JTC 1 SC25), operando de uma forma distribuída sem um ponto de controlo central.

Todos os módulos podem comunicar desde que a linha se encontre disponível. São

identificados por endereços BatiBUS, os quais são definidos na altura da instalação,


com a ajuda de selectores rotativos, interruptores ou teclados com displays. Para

sistemas mais complexos, o controlo pode ser programado a partir de um módulo de

comando central.

Sempre que se torne necessário modificar o posicionamento dos módulos ou

das funções usadas, basta mudar o endereço ou ligar um componente adicional ao

bus.

Os dispositivos comunicam entre si a uma taxa de transmissão de 4800 bps.

A informação transmitida no bus é descrita em termos de tramas como a da figura

seguinte:

Ilustração 2 - Trama Batibus

O campo tipo da mensagem descreve o conteúdo da trama, indicando se ela

contém, por exemplo, uma medida de temperatura, o estado de entrada binária, o

comando de uma saída binária, etc; o segundo campo indica quais os tipos de

dispositivos que transmitem/recebem a trama (sensor de temperatura, interruptores,

etc); o terceiro campo indica os endereços físicos dos dispositivos que

transmitem/recebem a trama; o campo de dados contém os dados da trama (permite

a transmissão de um máximo de 25 bytes por trama). Finalmente o campo check

permite evitar os erros de comunicação. [6]


1.1.5 Protocolo EIB

O EIB é um protocolo de comunicação desenvolvido por um conjunto de

empresas líderes no Mercado Europeu do material eléctrico com o objectivo

declarado de criar um sistema que constitua uma barreira às importações de

produtos e sistemas semelhantes que estavam e estão sendo produzidos nos

mercados Japonês e dos Estados Unidos da América onde estas tecnologias

possuem, melhor dizendo possuíam, um grau de maturidade superior ao produzido

na Europa. O objectivo era criar um standard Europeu que permita a comunicação

entre todos os dispositivos de uma instalação, esteja ela numa casa ou num edifício

de escritórios. O EIB possui uma arquitectura descentralizada. Ele define uma

relação elemento – a – elemento entre os dispositivos, o que permite distribuir a

inteligência entre os sensores e actuadores instalados.

A EIBA é uma associação actualmente com 114 membros, empresas lideres no

Mercado do material eléctrico, que se iniciou em 1990, com 15 membros apenas,

para implantar o uso o sistema de instalação inteligente EIB.

A EIBA tem sede em Bruxelas e os seus membros cobrem cerca de 90% do

negócio do material eléctrico na Europa. As principais áreas de actuação desta

associação são:

• Estabelece as directrizes técnicas para o sistema e produtos EIB, assim

como estabelecer os procedimentos de ensaio e certificação de qualidade e

mandar realizar esses mesmos ensaios

• Divulga o conhecimento e experiências das empresas que trabalham com o

EIB, assim como dos novos produtos e/ou inovações.

• Ú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 normalização e adaptação do EIB ás normas

internacionais.

• Participa na iniciativa de "convergência" KONNEX, juntamente com o BCI

(Batibus) e a EHSA (EHS). [4]


Meio Físico

Apesar de no inicio se usar unicamente um cabo do tipo telefónico, designado

por y(st)y 2x2x0,8, com de 2 pares de fios (só se usa um desses pares) como

suporte físico das comunicações, pretendeu-se que no nível MAC (Médium Access

Control) do OSI o EIB pudesse funcionar sobre os seguintes meios físicos:

• EIB.TP: Sobre o par de condutores a 9600 bps. Igualmente por estes dois

fios é fornecida a alimentação a 24 Vdc para os participantes. Usa o

protocolo de comunicação CSMA-CA onde são evitadas as colisões,

maximizando a largura de banda disponível. Foi o primeiro meio de

comunicação a ser disponibilizado e é o único a ter expressão. Todos os

outros pouco mais conseguiram que algumas instalações ou aplicações de

referência.

• EIB.PL: Transmite o sinal por correntes Portadoras comunicando a

1200/2400 bps sobre os 230V/50Hz. Usa a modulação SFSK (Spread

Frequency Shift Keying), semelhante á FSK mas com maior separação entre

as portadoras. A distância máxima sem repetidor é de 600 metros.

• EIB.net: Utiliza a rede Ethernet a 10 Mbps (IEC 802-2). É usado como linha

principal entre linhas e/ou áreas do EIB, permitindo a transferência de

telegramas EIB através do protocolo IP entre instalações muito afastadas.

Antes este problema era resolvido utilizando modems EIB e a rede telefónica

comutada.

• EIB.RF: Transmite o sinal por radiofrequência, conseguindo-se distâncias até

300 metros em campo aberto. Para maiores distâncias podem ser usados

repetidores. Também para ser usado no interior das casas ou dos edifícios.

• EIB.IR: Transmite o sinal por infravermelho, até uma distância máxima de

aproximadamente 12 metros. Ideal para o uso com comandos à distância em

salas ou salões onde se pretende controlar os dispositivos EIB instalados e o

número destes ou as distâncias a cobrir estão dentro do limite indicado.


1.1.6 Protocolo KNX

O Konnex é uma iniciativa promovida por três associações Europeias

1. EIBA (European Installation Bus Association)

2. BCI (Batibus Club International)

3. EHSA (European Home Systems Association)

com o objectivo de criar um único standard Europeu para a automação das

casas e edifícios.

Os objectivos desta iniciativa, com o nome de "Convergência", são:

• Criar um único standard para a domótica e automação de edifícios que cubra

todas as necessidades e requisitos das instalações profissionais e

residenciais no âmbito europeu;

• Melhorar as prestações dos diversos meios físicos de comunicação

sobretudo na tecnologia de radiofrequência, fundamental para a efectiva

consolidação da domótica;

• Introduzir novos modos de funcionamento que permitam aplicar uma filosofia

Plug&Play a muitos dispositivos típicos de uma casa;

• Envolver as empresas fornecedoras de serviços como as de

telecomunicações e de electricidade, com o objectivo de desenvolver a

telegestão 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, prestações e

preços, com outros sistemas norte-americanos como o Lonworks ou CEBus.

Actualmente a associação Konnex está a terminar as especificações do novo

standard (versão 1.0) o qual será compatível 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 versão 1.0 contempla três modos de funcionamento:

1. S-mode (System mode): a configuração do modo sistema usa a mesma

filosofia que o EIB actual, isto é, os diversos dispositivos ou modos da nova


instalação, são instalados e configurados por profissionais com ajuda de um

software (ETS) especialmente concebido para este propósito.

2. E-mode (Easy mode): na configuração do modo simples os dispositivos são

programados em fábrica para realizar uma função concreta. Mesmo assim

devem ser configurados alguns detalhes no local da instalação mediante o

uso de um controlador (como uma porta residencial ou uma set-top-box) ou

mediante micro-interruptores alojados nos dispositivos (semelhante ao X-10

ou outros dispositivos proprietários que há no mercado).

3. A-mode (Automatic mode): na configuração do modo automático, com uma

filosofia Plug&Play, nem o instalador nem o utilizador final têm de configurar

o dispositivo. Este modo será especialmente indicado para ser usado em

electrodomésticos e equipamentos de entretenimento (consolas, set-top

boxes, áudio e vídeo).

Respeitante ao meio físico o novo standard poderá funcionar sobre:

• Par de condutores (TP1): aproveitando a norma EIB equivalente.

• Par de condutores (TP0): aproveitando a norma Batibus equivalente.

• Correntes portadoras (PL100): aproveitando a norma EIB equivalente.

• Correntes portadoras (PL132): aproveitando a norma EHS equivalente.

• Ethernet: aproveitando a norma EIB.net.

• Radiofrequência: aproveitando a norma EIB.RF [4]


1.2 Objectivos

Como foi descrito desde o início, os principais objectivos é criar uma solução

de domótica de baixo custo e compatível com soluções existentes no mercado.

Para uma fácil integração numa casa, outro objectivo principal é criar um

sistema domótico que pudesse utilizar as instalações de redes dessa mesma casa e

fosse de fácil instalação.

Ao logo do projecto, outros objectivos pessoais foram acrescentados partindo

sempre da satisfação dos principais requisitos.


1.3 Escolha do Protocolo

No mercado, os sistemas mais usuais utilizam o protocolo X-10. Por essa

razão, a nossa escolha inicial recai na utilização do X-10, que descartamos logo de

seguida pela sua fraca robustez e ser muito rudimentar.

O segundo protocolo mais utilizado em sistemas domóticos existentes no

mercado, é o EIB/KNX. Este protocolo oferece muita robustez e flexibilidade

contudo, os produtos são de elevado custo. Para ter uma noção, um interruptor de

pressão quadruplo da Siemens, custa aproximadamente 70,91€. [2]

Como os outros protocolos vistos anteriormente, não são muito usuais no

mercado, foram colocados de parte porque tendo em conta um dos nossos

objectivos, não iria existir muitas soluções no mercado compatíveis.

O principal requisito de escolha do protocolo é a importância da solução a

criar ser compatível com outros produtos de outros fabricantes. Assim podemos ter

esta solução de domótica com EIB e por exemplo acrescentar um touch panel EIB

da Siemens e uns interruptores EIB da Jung e o sistema funcionar correctamente.

O sistema EIB tem sido desenvolvido dentro do contexto da União Europeia,

com o fim de fazer frente aos produtos domóticos já existentes na América e Japão.

O protocolo EIB permite a utilização de vários meios físicos, mas o mais utilizado é o

par entrançado onde todos os dispositivos estão ligados a um Bus. Mas com esta

solução de par entrançado (TP), era necessária uma fonte de alimentação para o

barramento que normalmente tem um custo elevado, na ordem dos 160€.

Uma das principais vantagens do EIB é a economização de energia porque

existe uma maior gestão dos dispositivos eléctricos de um edifício. Por exemplo, se

saímos de casa para o trabalho e alguma luz ficou ligada, é possível desligar a

mesma quando chegamos ao trabalho sem ter a necessidade de alguém se deslocar

a casa.

O EIB é um protocolo aberto e por esta razão, existem no mercado alguns

fabricantes que têm os seus produtos a utilizarem EIB. Qualquer pessoa, pode

desenvolver produtos EIB bastando para isso adquirir um livro denominado por EIB

Handbook com nove volumes cujo valor comercial é de aproximadamente 1000€.

Com este livro de milhares de páginas, têm-se toda a documentação necessária

desde a parte de desenvolvimento à certificação do produto EIB.


Em 14 de Abril de 1999, as associações responsáveis pelos protocolos: EIB,

EHS e o BatiBUS, decidiram juntar-se e criar uma só associação denominada

Konnex, com o protocolo mais conhecido pelas suas siglas: KNX. O KNX veio

acrescentar ao EIB outras funcionalidades tais como: permite a utilização de mais

meios físicos e o controlo de mais sistemas, como é o exemplo de sistemas HVAC.

A imagem seguinte [7] ilustra que o sistema de base do KNX é o EIB e que

utiliza o software ETS para configurar os dispositivos EIB.

Ilustração 3 – Modelo do Sistema KNX

Para desenvolver um produto KNX/EIB como acontece com o EIB, é

necessário adquirir o KNX/EIB Handbook cujo valor comercial é também

aproximadamente 1000€. Como tivemos apenas à nossa disposição o handbook do

EIB, não nos foi possível realizar o projecto com KNX. Contudo, é de notar que

numa rede domótica um sistema EIB pode estar ligado a um sistema KNX, porque

são totalmente compatíveis.


1.4 Escolha do Meio Físico

Foi feita uma análise de vários meios físicos que são compatíveis com EIB

assim como o protocolo de rede a utilizar.

Inicialmente a nossa escolha recaiu pela utilização do Twisted Pair. Era uma

solução bastante utilizada noutros sistemas domóticos e uma óptima solução para o

nosso sistema. Contudo, para nos diferenciarmos das soluções existentes do

mercado e como a tendência é evoluir para redes mais complexas e tendo em conta

que seria necessário adquirir uma dispositivo que não era de baixo custo, optamos

por não utilizar esta solução.

O interessante era utilizar uma rede sem fios para utilizar em casas já

terminadas onde inserir uma rede com cabos significava partir paredes já prontas.

Para isso, pensamos na opção de utilizar Rádio-Frequência. Era uma boa solução e

os dispositivos de interface à rede RF eram mais baratos, mas surgiu a

desvantagem de existirem algumas interferências provocadas por aparelhos como

campainhas sem fios ou o sistema de alarme de uma casa onde os sensores de

ultra-sons interferem com os demais dispositivos sem fios.

Decidimos fazer um sistema para qualquer tipo de habitação e aproveitar a

instalação de rede ethernet que algumas habitações possam ter. Pensamos então

em ter o nosso sistema a funcionar em conjunto com uma rede ethernet normal, ou

seja, ambas as redes utilizavam a mesma cablagem onde passariam tanto as

tramas da rede ethernet como as tramas da rede EIB.

Escolhido então o protocolo TCP/IP e o meio físico ethernet para transportar

as tramas EIB, surgiu uma dificuldade, não existem microcontroladores simples que

corram o protocolo IP. Fazendo um estudo dos microcontroladores e de dispositivos

de conversão de um protocolo de rede para o outro, verificamos que existiam

bastantes conversores de RS232 para um outro protocolo e raros eram os

microcontroladores que não tinham uma porta USART (Universal Synchronous

Asynchronous Receiver Transmitter). Escolhemos então um conversor RS232 para

ethernet denominado por XPORT da empresa LANTRONIX. O RS232 passa a ser a

interface entre o microcontrolador e a XPORT. O facto de utilizarmos o RS232 para

interface com um meio físico, permite mais tarde, substituir a XPORT por outro

conversor e utilizar outros meios físicos.


2 Descrição detalhada do

Protocolo EIB

Depois de escolhido o protocolo e o meio físico, seguem-se as outras questões:

Quais são os objectos de comunicação a utilizar?, qual o seu formato de dados?,

quais são os requisitos de hardware?, já existem componentes standard EIB?, vai

ter algum modo de configuração?, que funções implementar?. Estas são algumas

das questões que criadores de dispositivos EIB se colocam numa fase inicial de

projecto. Uma forma de ajuda a responder a essas questões é efectuar uma

pesquisa no mercado e verificar o que as soluções existentes implementam.

Encontram-se soluções variadas, mas em todas elas que utilizam como meio físico o

par entrançado, utilizam um dispositivo físico que pode ter várias denominações

dependendo das camadas EIB que ele implementa.

Um dos dispositivos mais conhecidos é o BCU (Bus coupling units), este é um

dispositivo que inclui o circuito de interface à rede TP EIB. É composto por um

microprocessador que implementa quase todas as camadas EIB exceptuando as de

nível de aplicação. O colaborador apenas precisa de desenvolver a aplicação num

microcontrolador à parte e utilizar o BCU como interface ao bus.

O outro dispositivo muito conhecido é o BIM (Bus Interface Modules), em que

basicamente são BCU mas com portas adicionais de entradas e saídas. Os BIM’s

são vendidos como módulos que podem ser soldados directamente na placa de

circuito do projecto. Existem algumas versões disponíveis: com 8Kbyte e 48Kbyte de

memória flash para o software de aplicação. Assim, não é necessário uma

microcontrolador à parte, visto que se utiliza o micro do BIM. Estes módulos têm um

valor comercial superior a 40€. [8]

Estes BIM’s são necessários para cada componente de uma casa, uma

lâmpada, um interruptor, um estore, ….

No sistema Domoitech que desenvolvemos o objectivo principal era a redução

de custos e se utilizarmos estes BIM’s no nosso projecto, o custo fica bastante

elevado. Optamos por criar os nossos próprios BIM’s e assim temos um

microcontrolador com poder de processamento e memória razoáveis onde irá ser

implementado todas as camadas do protocolo EIB, exceptuando a camada de


protocolo de rede IP que será a XPORT a implementar. Poderemos comparar a

XPORT ao BCU porque a sua função é semelhante excepto o acesso ao meio físico,

em que um é para rede Ethernet e outro é para rede TP EIB. Futuramente, se for

pretendido a utilização do meio físico TP, basta acrescentar uma camada que

implementa o protocolo FT1.2 e em vez da XPORT utilizar um BCU que faz a

interface ao barramento TP do EIB.

O EIB funciona em quase todas as camadas do modelo OSI e ainda

acrescenta uma superior à de aplicação, a camada de utilizador. As únicas camadas

que não implementa é a de sessão e de apresentação.

De todas as camadas, apenas nos interessa a de aplicação, visto que as

restantes camadas, algumas vão ser preenchidas pela interface de rede Ethernet

que já implementa o protocolo TCP/IP.

Para uma melhor compreensão das camadas de rede do EIB, o diagrama

seguinte ilustra as camadas do modelo OSI e as camadas do EIB:

Ilustração 4 – Modelo Camadas OSI vs Modelo Camadas EIB


Uma trama EIB tem o seguinte formato:

Ilustração 5 - Formato Trama EIB

A trama EIB é composta por vários cabeçalhos de quatro camadas do protocolo.

Na parte inferior da trama encontra-se uma barra de cores que facilita a visualização

das camadas de rede. Até ao octeto 4, mais 5 bits do octeto 5 e último octecto,

pertencem à camada de ligação lógica. Neste cabeçalho, estão indicados os

endereços de destino e origem, um caractere inicial de controlo e no final um octecto

com um NOT XOR de todos os octetos anteriores. A este octeto terminal, chamamos

de check octet e serve para detecção de erros na trama. Os 3 bits do octeto 5

pertencem à camada de rede e indicam se os endereços que vêm são do tipo

endereços de grupo ou físicos. O octeto 6 contém o cabeçalho da trama de

transporte que será fixo porque todas as tramas que iremos enviar são do tipo data

packet. Os restantes octetos a partir o 7 excepto o último, pertencem à camada de

aplicação. O tamanho máximo de uma trama EIB é de 23 octectos.

2.1 Camada de Aplicação

A camada de aplicação corresponde, à camada 7 que contém os serviços da

parte do cliente e do servidor. Os serviços são respectivos a quatro modos de

comunicações, o modo multicast, broadcast, um-para-um sem conexão e um-para-

todos orientada à conexão que a camada 4 implementa.


Formato da trama de aplicação:

Ilustração 6 - Formato de aplicação

Uma trama EIB pode ter até um máximo de 23 bytes. A aplicação utiliza dois

bits do octeto 6 e o octeto 7. Os restantes octetos são para dados. A trama de

aplicação é denominada por APDU e vai encapsulada na trama de transporte.

É nesta camada que estão definidos os serviços e o EIS que serão

explicados a seguir.

2.1.1 Serviços EIB

Restam as questões de software em que terá de ser decidido quais as funções

e os objectos de comunicação a implementar e como pode ser configurado o nosso

sistema.

Devido ao curto espaço de tempo que temos para o desenvolvimento do

projecto, só foi possível escolher algumas das funções mais simples e não foi

possível criar as funções que permitiam configurar o nosso sistema quando a rede

tivesse montada. Assim é necessário, o sistema ir já configurado antes da sua

instalação e se for preciso efectuar alguma alteração, todas as placas terão de ser

reprogramadas com um programador especial e não via rede.

Estes serviços estão definidos no volume 3, parte 3 e capítulo 7 do EIB

Handbook.

Os serviços do modo de comunicação broadcast, servem para configurar a rede

EIB. Como foi explicado anteriormente, devido à falta de tempo, estes serviços não

vão ser implementados. Os serviços do modo um-para-um orientada à conexão


servem para aceder à memória do microcontrolador que implementa o protocolo e

esses serviços não serão necessários utilizar. Quanto ao modo um-para-um sem

conexão, apenas foi criado o serviço PropertyValue_Write, mas não está a ser

utilizado. Este tipo de serviço é utilizado para alterar a propriedade de um objecto e

no nosso projecto não irá ser utilizado, embora essa função e a respectiva tabela de

objectos esteja implementada.

O modo de comunicações que iremos utilizar é o multicast e todas as suas

funções: GroupValue_Read, GroupValue_Write e GroupValue_Response.

Estes serviços alteram ou lêem estados de dispositivos de um certo endereço

de grupo.

O código correspondente ao serviço pode ter até 10 bits e em alguns dos casos

só são necessários 4 bits. Nos serviços que iremos implementar, só serão

necessários 4 bits para os identificar. Assim sendo, os dados poderão preenchidos a

partir do bit 6 do octeto 7. É de notar que nos dados, para o caso dos nossos

serviços, vão os estados dos dispositivos E/S.

Os códigos para os serviços são os seguintes:

Ilustração 7 – Códigos dos serviços EIB

É de notar que para estes serviços o cabeçalho da trama de rede terá de indicar

que pelo menos o endereço de destino é um endereço de grupo. Por esta razão, o

código do serviço só é validado em conjunto com o cabeçalho de rede.


2.1.1.1 Serviço GroupValue_Read

Este serviço serve para enviar tramas com pedidos de leitura de estados de

variáveis ou E/S. O código deste serviço tem o valor decimal 0 se retirarmos os bits

8, 7, 2 e 1 do octeto 6 e o octeto 7. Para realizar essa validação do código,

aplicamos uma máscara de bits com o valor hexadecimal 0xC3FF aos octetos 6 e 7.

O receptor da trama requerente deste serviço, deverá enviar uma resposta com

os estados pedidos, utilizando o serviço GroupValue_Res.

Um exemplo de uma trama EIB com este serviço a efectuar um pedido da placa

com o código físico 1 para o endereço de grupo 23 é a seguinte:

Ilustração 8 – Exemplo Trama GroupValue_Read

2.1.1.2 Serviço GroupValue_Res

Este serviço serve para enviar tramas de resposta aos pedidos de leitura de

estados de variáveis ou E/S. O código deste serviço tem o valor decimal 1 se

retirarmos os bits 8, 7, 2 e 1 do octeto 6 e os bits 8 e 7 do octeto 7. Para realizar

essa validação do código, aplicamos uma máscara de bits com o valor hexadecimal

0xC3C0 aos octetos 6 e 7.

Os estados das variáveis vão guardados nos dados, ou seja, são colocado a

partir do octeto 7. Se um dos estados é um valor binário então é possível colocar no

octeto 7 porque sobram 6 bits para dados.

Um exemplo de uma trama de resposta à anterior da ilustração 13, em que só

existe um dispositivo binário com estado 0 e com aquele endereço de grupo, é a

seguinte:


Ilustração 9 - Exemplo Trama GroupValue_Res

2.1.1.3 Serviço GroupValue_Write

Este serviço serve para enviar tramas de escrita em que mudam o estado das

varáveis ou E/S que estejam no grupo do endereço de destino. O valor do estado vai

no octeto 7 para o caso de ser binário ou vai no octeto seguinte para o caso de ser

um valor decimal de 8 bits. O código deste serviço tem o valor decimal 2 se

retirarmos os bits 8, 7, 2 e 1 do octeto 6 e os bits 8 e 7 do octeto 7. Para realizar

essa validação do código, aplicamos uma máscara de bits com o valor hexadecimal

0xC3C0 aos octetos 6 e 7.

Um exemplo de uma trama EIB com este serviço que envia um pedido para

modificar um estado para o valor binário 1 e para o grupo 23, é:

Ilustração 10 – Exemplo Trama GroupValue_Write

2.1.2 Objectos EIB

Os objectos de comunicação, são os chamados EIS (EIB Interworking

Standards), decidimos utilizar apenas dois, o objecto do tipo SWITCHING e o do tipo

DRIVE CONTROL. Os EIS são explicados no volume 3, parte 7 e capítulo 1 do EIB

Handbook e explica todos os objectos do standard EIB. Ao todo são 15 os EIS, mas

como foi explicado, só vamos utilizar dois. No standard é especificado que a leitura

de E/S deverá ser feita com um tempo de refrescamento inferior a 200ms. É

garantido no nosso sistema um tempo bastante inferior a esse, ronda os 10ms.


É utilizado também um mecanismo de definir prioridades aos objectos. Por

exemplo, podemos definir que o interruptor da sala, tem prioridade sobre o

interruptor da cozinha para ligarem uma mesma lâmpada. No nosso sistema, não é

utilizado o mecanismo de prioridades, deixando por defeito, como refere a norma, a

prioridade baixa.

2.1.2.1 EIS 1 - Switching

Este objecto, implementa uma função com 1bit, logo dois estados e com ela

é possível actuar numa carga do tipo ON/OFF ligada ao actuador. Utilizamos esta

função para as lâmpadas. Mas as saídas das lâmpadas podem ser utilizadas para

qualquer carga do mesmo tipo, como por exemplo: tv, portas eléctricas, etc.

Tem o valor de 1 bit e o código dele é 10 e que pode ter os seguintes

estados: (on / off), (enable / disable), (alarm / no alarm) e (true / false).

Ilustração 11 – EIS Switching

2.1.2.2 EIS 7 – Drive Control

Este objecto consiste em duas subfunções denominadas por “move” e “step”.

Com a subfunção “move” é possível colocar o drive em movimento para um sentido

ou para o outro. O tempo de movimento é escolhido pelo utilizador e é facilmente

configurável. Com a subfunção “step” é possível realizar movimentos graduais em

ambos os sentidos. Este tempo de movimento gradual é também facilmente

configurável. Este objecto é utilizado para controlar os estores.


A saída do actuador é também binária, de 1 bit, mas neste caso temos duas

subfunções: uma coloca a saída num determinado estado a um determinado tempo

e a outra subfunção, também tem os dois estados, mas o tempo é bastante inferior

em relação ao outro.

A subfunção Move é utilizada para fechar ou abrir totalmente o estore e pode ter

dois estados possíveis: mover para baixo ou mover para cima. A imagem seguinte

ilustra os dois estados possíveis:

Ilustração 12 – EIS Drive Control - Move

A subfunção Step é utilizada para fechar ou abrir gradualmente o estore e

pode ter dois estados possíveis: mover para baixo ou mover para cima. A imagem

seguinte ilustra os dois estados possíveis:

Ilustração 13 – EIS Drive Control – Step

Para este EIS será necessário uma máquina de estado mais complexa em que

precisamos de quatro estados possíveis: em movimento, parado, gradualmente para

cima e gradualmente para baixo. A norma EIB também especifica a máquina de

estados como podemos ver na figura seguinte:


Ilustração 14 – Máquina de estados do Drive Control


2.2 Camada de Transporte

A camada de transporte corresponde à camada 4 que implementa os vários

modos de comunicação: o modo multicast, broadcast, um-para-um sem conexão e

um-para-todos orientada à conexão. Os modos de comunicação são identificados

por um código (cr_id) que tem de ser único. A camada de transporte converte o cr_id

num endereço de destino e vice-versa.

Ilustração 15 – Interface com a camada de transporte entre os dispositivos EIB

A trama de transporte, TPDU corresponde à trama NPDU mas reduzida, pois

não tem o cabeçalho de controlo de rede. O campo de controlo da camada de

transporte é codificado e descodificado pela camada 4 e contém os códigos dos

serviços da camada 4.

2.3 Camada de Rede

A camada de rede, denominada por camada 3, faz a interligação entre a

camada de ligação lógica e a camada de rede do utilizador. Esta camada, utiliza o

serviço L_Data da camada de ligação lógica e disponibiliza os serviços: N_Data,

N_GroupData e N_Broadcast para a camada de rede do utilizador como podemos

ver na figura seguinte.


Ilustração 16 – Interface com a camada de rede entre os dispositivos EIB

O formato da trama de rede:

Ilustração 17 – Formato da trama NPDU

A trama de rede, denominada por NPDU, corresponde a uma trama que tem

encapsulada a trama de transporte TPDU e corresponde a uma trama LPDU, mas

sem o cabeçalho de ligação lógica (endereço destino, origem, flag endereço de

destino e a informação do comprimento. A NPDU é mostrada na figura anterior onde

é perceptível que o cabeçalho da NPDU é de apenas 3 bits situados no octeto 5.


2.4 Camada de Ligação Lógica

A camada de ligação lógica, denominada por camada 2, faz a interface entre o

nível físico e a camada de ligação lógica do utilizador. Esta camada utiliza serviços

da camada física e fornece alguns serviços como estão representados na figura 18.

O cabeçalho de controlo do nível da ligação lógica examina o formato da trama,

endereço de destino e decide se essa trama é para ser recebida. Esta camada,

detecta erros de transmissão e efectua repetições de tramas. Os bytes da camada

física com o serviço Ph_Data.ind, são colocados juntamente com um serviço de

ligação (LSDU). LSDU`s que são transmitidas para um destino, são entregues à

camada física com o pedido Ph_Data.req.

Ilustração 18 – Interface com a camada de ligação lógica entre os dispositivos EIB

2.5 Camada Física

Esta camada situa-se no nível mais baixo e é aí onde se insere no caso do EIB,

todos os meios físicos compatíveis que são: o TP, Ethernet, rede eléctrica, rádio

frequência e infravermelhos.


3 Recursos de Hardware

Tendo em conta os requisitos do sistema, fizemos uma pesquisa de hardware

que podemos utilizar. Numa fase inicial, foi decidido utilizar um microcontrolador da

Microchip [11] devido à vasta gama de produtos que apresenta. Efectuando uma

pesquisa de microcontroladores PIC, optamos pelo PIC16F877, que numa fase

intermédia do projecto, teve de ser substituído por um PIC18F452 que tem maior

capacidade de processamento, tem tecnologia mais recente e a diferença de custo é

pequena. Foi escolhido este microcontrolador porque correspondia com todos os

requisitos e permite futuros upgrades.

Como já foi referido, utilizamos uma XPORT para interface entre o

microcontrolador e o meio físico Ethernet. A XPORT é um servidor web embebido

que implementa o protocolo RS232 e insere tramas deste protocolo em tramas

ethernet. É proprietário da Lantronix [10] que fabrica uma grande variedade de

conversores de rede.

3.1 Microcontrolador PIC18F452

O PIC18F452 é um microcontrolador composto por uma unidade de

processamento, memória e portas de entrada/saída (I/O).

A maioria das pessoas limita o conceito de sistema computacional ao

computador que temos em casa, o vulgar PC (Personal Computer). No entanto todo

sistema que a partir de dados de entrada, executa algum processamento mediante

um programa armazenado em uma memória gerando uma saída é chamado de

sistema computacional. Podemos definir um microcontrolador como sendo um

sistema computacional integrado, pois ele possui unidade de processamento,

memória e entradas e saídas integrados em um único chip.

Características técnicas do PIC

- Arquitectura RISC;

- 32K de memória FLASH;

- 1536 bytes de memória RAM;

- 256 bytes de memória EEPROM;


- 16384 instruções suportadas pela memória de programa;

- 18 fontes de interrupção;

- Operação de 4.2V até 5.5V;

- Universal Synchronous Asynchronous Receiver Transmitter (USART/SCI) com

o 9 bit;

- 4 Temporizadores;

- 5 portas de 8bits;

- 8 canais de entradas/saídas analógicas;

- Relógio máximo de entrada de 40MHz.

A figura seguinte ilustra a disposição e descrição dos pinos do microcontrolador:

Ilustração 19 – Diagrama de pinos do PIC18F452


3.2 XPORT

A XPORT é um componente que efectua uma conversão bidireccional entre o

protocolo RS232 e Ethernet. É a solução integrada mais compacta para permitir uma

interface web a qualquer componente com uma interface série. A XPORT incorpora

todas as características essenciais de rede, incluindo uma ligação Ethernet de

10Base-T/ 100Base-TX, provado de um sistema operativo, um servidor web, alertas

de e-mail, a pilha TCP/IP completa e uma encriptação de 256-bit AES.

A XPORT tem a seguinte apresentação:

Ilustração 20 – Dimensões Xport

Características técnicas da XPORT

- Serial Interface

Interface: CMOS (Assíncrono, com 5V tolerância)

Taxa Transmissão de dados: 300 bps to 921,600 bps

Tamanho do caractere: 7 ou 8 bits de dados

Paridade: ímpar, par e nenhuma

Stop Bits: 1 ou 2

Sinais de controlo: RTS/DCD, CTS,RTS

Controlo de fluxo: XON/XOFF,RTS/CTS

- Interface de Ethernet

Interface: Ethernet 10Base-T ou 100Base-TX (Auto-Sensing)

Conector: RJ45

Protocolos: TCP/IP, UDP/IP,ARP, ICMP,SNMP,TFTP,Telnet,


DHCP, BOOTP, HTTP e AutoIP

- Capacidade de Armazenamento: 384 Kbytes para páginas web

- Arquitectura

CPU: 16-bit, 48MHz ou 88MHz, x86 arquitectura

Memoria: 256 Kbytes SRAM e 512 Kbytes de flash

Firmware: actualizável via TFTP e porta série

- Tensão de alimentação: 3.3 V CC

É possível configurar todos os parâmetros da XPORT via web browser, telnet ou

utilizando um software fornecido com a mesma. Utilizamos o web browser para

configurar as definições da porta série e da Ethernet. Mas antes de poder aceder à

página de configuração é necessário a atribuir um endereço IP à XPORT. Para isso,

utilizamos o software Xport Installer fornecido pelo fabricante e utilizamos a

ferramenta Assign IP para atribuir o endereço IP.

Ilustração 21 – Atribuição endereço IP da XPORT

A figura anterior ilustra a janela de atribuição de IP, onde é necessário inserir o

endereço MAC da XPORT e o IP que queremos atribuir.

Após a atribuição do endereço IP, configuramos os parâmetros da XPORT

recorrendo ao browser e acedendo à página web do servidor. Seleccionando no

menu da esquerda port properties obtemos a seguinte interface:


Ilustração 22 – Configuração Porta Série e Ethernet

A partir desta interface configuramos a velocidade da porta série a 9600 bps,

o tamanho do caractere 8bits, a paridade nula, 1 stop bit e sem controlo de fluxo.

Configuramos ainda o protocolo de Ethernet no modo UDP, com o datagrama

type 01 e configuramos os dados de ligação com o endereço IP remoto

192.168.105.255 (Endereço de broadcast da rede), porta remota e porta local com o

mesmo número: 10001.

Em cada vez que se altera uma definição, é necessário reiniciar a XPORT.


4 Desenvolvimento Hardware

Um dos principais requisitos deste projecto é desenvolver um sistema eficiente

sem que isso se traduza num elevado preço do produto final. Dado que o preço 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

utilização de componentes standards e de fácil obtenção no mercado uma vez que

estes se podem adquirir a preços mais competitivos. Só assim poderemos competir

com o nosso produto no mercado, podendo assegurar qualidade e preços baixos.

Tivemos também em conta que uma das aplicações possíveis para este sistema

seria a sua utilização em instalações que não tenham sido projectadas para a

aplicação de sistemas de domótica, por isso tentamos minimizar o máximo possível

as dimensões do hardware, para que possa ser instalado nas caixas de derivação já

existentes na instalação, com possibilidade de utilização das aparelhagens de

comando já existentes.

4.1 Estrutura do hardware

Após várias fases de testes de hardware, em que numa primeira fase, montamos

um microcontrolador numa placa perfurada com led’s para simular saídas, pulsores

para simular entradas e um receptor de infravermelhos sendo este protótipo apenas

para nos familiarizarmos com a programação da PIC. Numa segunda fase

desenvolvemos quatro protótipos de placas baseadas num barramento principal que

fazia a interface entre elas, chegamos a conclusão que não seria a melhor

alternativa a seguir devido ao elevado espaço necessário para acondicionar todo

este hardware. Decidimos então optar por uma terceira versão baseada na seguinte

arquitectura de hardware:


Ilustração 23 - Diagrama de blocos da estrutura de hardware

Nesta arquitectura existe uma placa principal, a qual contem todo o

processamento necessário e os vários módulos de interface com os sistemas

exteriores, existem ainda dois tipos de placas secundarias, saídas em relés e saídas

em triac’s, para fazerem de interface com os equipamentos que pretendemos

controlar.


4.2 Placa Principal

A figura seguinte é uma foto da placa principal, que contém todo o

processamento e foi projectada com dimensões reduzidas para que seja possível

instalar sem qualquer dificuldade numa instalação que não tenha sido projectada

para este tipo de sistemas.

Ilustração 24 – Placa Principal

Características técnicas:

• Alimentação 8~12 Vcc

• Corrente Max consumida 400 mA

• Corrente nominal 200 mA

• Saída de alimentação nos conectores RJ11 5Vcc

• Velocidade de processamento 20Mhz

Micro

controlador

18f452

Alimentação

12v DC

Conectores RJ11 Para

as placas de controlo

XPort- Interface de

rede Ethernet

Botão de

Reset

Conector de

Programação

Receptor

Infravermelho


• Reconhecimento de comandos infravermelhos RC5

• 7 Conectores para dispositivos de controlo externos

• Conector de programação por RS232

• Conector de programação por JDM

• Botão de reset

• Connector ethernet RJ45 10-base T, 100-base TX

• Configuração via web server

• Arquitectura baseada num micro controlador pic18f452 com 512 Kbytes RAM e 1024Kbytes Flash

• Dimensões 73x73x20mm

• Led indicador de alimentação

Esta placa permite-nos ligar no máximo 14 dispositivos podendo ser do tipo

sensores ou actuadores, na sua configuração normal estão previstos 7 sensores e 7

actuadores, podendo esta ser alterada bastando para isso reconfigurar o software.

Dispõe de uma Xport que faz a interface entre o meio físico, barramento (Ethernet) e

o micro controlador. A comunicação entre esta interface e o micro controlador é feita

através do protocolo RS232 permitindo assim alterar para outro meio físico

suportado pelo protocolo EIB bastando para isso trocar de interface desde que esta

suporte comunicação RS232.

Inclui ainda um receptor de infravermelhos que nos permite controlar os

dispositivos através de um comando que implemente o protocolo RC5. Este receptor

é alimentado a 5Vcc e contem no seu interior um circuito de filtragem que faz com

que o sinal na sua saída seja uma onda quadrada sem a componente de modulação

usada em comunicações de infravermelhos.


4.3 Placa Saída a Relés

Para controlar os dispositivos de potência desenvolveu-se uma pequena placa

de controlo que faz a interface entre estes e a placa principal. Neste caso a actuação

é feita através de relés capazes de comutar correntes até 2 Amperes, o que é

suficiente no caso dos dispositivos não ultrapassarem os 400W. Esta placa conta

com duas entradas para dois sensores (interruptores) e duas saídas para dois

actuadores. Neste caso não necessitamos de colocar isolamento óptico pois o

próprio relé já faz o isolamento entre a parte de potência e a parte de controlo.

A placa tem o seguinte aspecto:

Ilustração 25 – Placa Saída Relés


• Alimentação 5Vdc

• 1 Conector e RJ11

• Corrente nominal 50mA

• Duas saídas em relés (Imax=4 A Vnom=230V)

• Duas entradas

Saídas para controlar dois

equipamentos

Entradas para dois

Interruptores

Conector RJ11 para ligar a

placa principal


4.4 Placa Saída a Triac’s

Tal como a placa anterior esta permite controlar dois dispositivos e possui

também duas entradas. Neste caso a comutação é feita com o recurso a triac’s uma

vez que estes são mais baratos e ocupam menos espaço. Foi necessário usar

isolamento óptico para proteger a parte de controlo de possíveis anomalias na parte

de potência.

A placa tem o seguinte aspecto:

Ilustração 26 – Placa Saída a Triac’s



• 1 Conector e RJ11

• Corrente nominal 20mA

• Duas saídas triac’s (Imax=2 A Vmax=600V)

• Duas entradas

Saídas para controlar dois

equipamentos

Entradas para dois

Interruptores

Conector RJ11 para ligar

a placa principal


Comando Infravermelhos

Uma das funcionalidades do sistema é permitir controlar os equipamentos

através de um controlo remoto de infravermelhos. Como a maioria dos comandos

usados em nossas casas implementam o protocolo RC5, configuramos a placa

principal para que possa responder a este tipo de comandos. Assim basta usarmos

um simples comando de tv ou um comando universal para controlar todos os

dispositivos.

Mais uma vez ao optarmos por esta solução estamos a reduzir os custos finais,

pois é possível adquirir um comando destes por um preço insignificante ou se for o

caso usarmos um que já exista em nossa casa.


4.5 Programador

Através deste programador é possível descarregar de forma rápida o ficheiro

hex a partir de um computador, sem que para isso seja necessário retirar o micro

controlador da placa principal.

A sua programação é feita através da porta UART. É de notar que para que

este método de programação funcionar foi necessário programar o micro controlador

com um código (bootloader para pic18f452) fornecido pelo fabricante. Este código

deve ser programado no microcontrolador através de um programador de PIC’s

(JDM programer).

A placa do programador tem o seguinte aspecto:

Ilustração 27 – Placa Programador



• 1 Conector rs232

• Saídas Rx,Tx 0-5V

• Led indicador de alimentação

Conector Rs232 para

ligar ao PC

Conector de

programação


5 Desenvolvimento Software

O software foi desenvolvido utilizando o programa PCWH Compiler versão

4.0. Criamos um projecto ao qual lhe demos o nome de eib2.pjt. Com este programa

é possível compilar código c e gerar um ficheiro hex para posteriormente programar

na memória do microcontrolador através do ICprog, que é um software livre e

permite programar PIC’s e memórias.

5.1 Estrutura do Software

No diagrama seguinte está ilustrado de uma forma simplificada, a estrutura

usada para o software. Trata-se de uma estrutura baseada no principio de

funcionamento de um sistema operativo, onde existem dois níveis de abstracção

sendo um deles o núcleo, o qual é responsável por fazer a configuração do micro no

inicio da execução do programa, faz ainda a gestão dos processos determinando

qual o que deve ser executado e qual a ordem de execução.

O segundo nível de abstracção designa-se por nível de utilizador que é onde

a aplicação vai ser executada. Dentro deste nível estão todos os processos, sendo a

ordem execução controlada pelo núcleo.


Ilustração 28 – Estrutura do software

Para que estes dois níveis possam comunicar entre si criamos uma estrutura

que define o nome de cada processo, o estado, activo ou desactivo, bem como a

sua prioridade, esta estrutura pode ser acedida de três formas distintas:

Proc_SetReady(Nome_processo) - Permite que um processo active outro, é

necessário indicar qual o nome do processo a ser activado.

Proc_ClrReady(Nome_processo) - Idêntico ao anterior mas neste caso serve

para desactivar um processo, normalmente é usado no núcleo para desactivar um

processo que já tenha sido dada a ordem de execução.

Proc_GetReady(Nome_processo) - Usado no núcleo do sistema operativo para

verificar o estado da flag que determina se um processo deve ser executado ou não.


Como já foi referido neste sistema a ordem de execução dos processos é

definida no núcleo, os processos são executados dependendo do nível de prioridade

que lhe esta associado, aqueles que necessitam de ser executados o mais rápido

possível são os de maior nível de prioridade, na atribuição de prioridades tivemos

ainda em conta o sentido do fluxo de dados, se um determinado processo necessita

de informação fornecida por outro então este deve ter um nível de prioridade inferior.

Este sistema é ainda preemptivo pois alguns dos processos, com nível de

prioridade inferior tem capacidade para interromper um processo em execução que

tenha um nível de prioridade superior.

5.1.1 Divisão da Stack por camadas

Para tornar a aplicação mais robusta e de fácil compreensão foi dividida em

quatro camadas, que correspondem as camadas definidas pelo protocolo EIB com

exclusão da camada de rede pois trata-se de uma camada pequena e foi integrada

juntamente com a de transporte. A primeira camada, Physical Layer, faz a

comunicação entre o software e o hardware, controla a recepção e envio de tramas

EIB, faz a leitura das entradas digitais e implementa a descodificação do protocolo

RC5.

Na segunda camada, Transport Layer, é feita a descodificação e a

codificação das tramas EIB, faz-se o tratamento dos endereços físicos e endereços

de grupo, do check octeto e do control field.

A camada seguinte do software trata dos dados que dizem respeito ao

campo de transporte da trama EIB.

Por último temos a camada da aplicação que trata os serviços EIB e os

EIS’s. Esta camada será tratada com maior detalhe mais a frente devido à sua

complexidade.


Ilustração 29 – Diagrama de blocos das camadas

As setas representadas indicam o sentido do fluxo de informação entre

processos e módulos ou entre processos e o nível de hardware. Neste sistema os

processos, que estão na camada física, acedem directamente ao hardware sem que

para isso seja necessário passar informação pelo núcleo, isto deve-se ao facto de se

tratar de um acesso simples sendo para isso desprezável a criação de uma estrutura

ao nível do núcleo para fazer a interface entre este e a aplicação.

A comunicação entre os vários processos é feita recorrendo a variáveis globais

ou a chamada de funções que trocam informação através da passagem de


parâmetros. Mais à frente, na descrição pormenorizada dos processos, é possível

ver com maior detalhe que tipo de variáveis são usadas para estas operações e

quais os processos que as usam.

5.1.2 Descrição dos processos camada física.

• EIB_ReadRxByte- Sempre que recebe um byte pela porta série este

processo é chamado para o guardar no vector circular, a partir do 8 byte

recebido que significa que já recebeu o numero de byte’s mínimos para que

possa ser do tipo trama EIB, activa o processo EIB_FindFrame. A

comunicação entre estes dois processos é feita através do vector Rxbufer[ ].

• EIB_FindFrame- Faz a pesquisa de tramas válidas no vector Rxbufer[ ], o

qual é uma variável global que faz a comunicação entre este processo e o

processo EIB_ReadRxByte, esta pesquisa é feita pelo método de vector

circular. Sempre que é encontrada uma trama válida activa o processo

EIB_DecodeFrame.

• EIB_SendFrame - Envia a trama EIB guardada numa variável global TxBuf[

], é esta variável que serve para fazer a comunicação entre este processo e

todos aqueles que necessitam de enviar uma trama EIB pela porta série.

• IR_ReadBit- sempre que ocorra uma interrupção na porta B, mudança de

flanco do pino RB4 o que significa que esta a receber um comando IV, este

processo é activo. Descodifica qual o bit recebido e guarda-o na variável

RC5_FrameBuf. Se recebeu 14 bits e se ocorreu interrupção do timer0 então

activa o processo IR_Decode.

• IR_Decode- Descodifica qual o comando RC5 recebido e activa o processo

IRHandleInstruction. Estes dois processos comunicam através da variável

RC5_Instruction.

• IRHandleInstruction- Este processo chama o serviço GroupValueW_REQ

para procurar qual o endereço de grupo correspondente ao comando RC5


recebido e constrói a trama para que possa ser enviada pelo processo

(Proc_EIB_SendFrame), activando ainda o processo EIB_SendFrame.

• Timer2_Over- Sempre que ocorrer uma interrupção do timer2 este processo

é activo, e é incrementado a variável de contagem contido no módulo clock.

• Clock- trata-se de um módulo de código que implementa dois contadores

para activar dois processos com períodos de execução diferentes.

• ReadInputs- Verifica o estado das entradas, caso haja alguma entrada

activa, testa o intervalo de tempo durante o qual esta foi activa para detectar

impulsos de pequena e longa duração. Este método é usado para

implementar dois interruptores lógicos existindo apenas um único interruptor

físico. Caso haja mudança de estado no interruptor lógico, chama o serviço

GroupValueW_REQ o qual procura o endereço de grupo correspondente, na

tabela de associação, e constrói a trama para que possa ser enviada pelo

processo EIB_SendFrame. Activa ainda o processo EIB_SendFrame. Trata-

se também de um processo activado ciclicamente com um tempo de

refrescamento de 20ms.

5.1.2.1 Protocolo RC5

O protocolo RC5 permite gerar 2080 comandos diferentes. Estes comandos

estão organizados em 32 grupos cada um contendo 64 comandos e cada grupo está

normalmente associado a um determinado tipo de aparelho.

Uma trama com o formato RC5 é composta por 14 bits organizados da seguinte

forma :

• 2 bits para indicar o início da trama

• 1 bit de transição que indica se a tecla está a ser pressionada durante muito

tempo

• 5 bits de endereçamento que indicam qual o endereço do aparelho que

pretendemos controlar 2^5=32 grupos de endereçamento


• 6 bits de comando que indicam qual a instrução a executar 2^6=64

instruções .

Os bits do código RC5 são codificados pelo método de Manchester em que cada

bit é constituído por dois semi-bits alternados: uma transição positiva corresponde a

1 e uma transição negativa corresponde a 0.

Na figura seguinte está representado a codificação de um bit.

Ilustração 30 – Codificação de um bit RC5

Cada bit tem um tempo de duração de 1.778ms que se multiplicarmos por 14

bits obtemos o tempo correspondente a uma trama completa que é de 24.889ms.

Ilustração 31 –Trama RC5

As tramas RC5 são enviadas com um período de 113.778ms que corresponde

ao tempo que demoraria a enviar 64 bits.

Ilustração 32 – Sequência de duas tramas RC5

A modulação de comandos infravermelhos é feita aplicando uma onda quadrada

com uma frequência de 36Khz ao emissor, sempre que se quer enviar o nível lógico

1 para enviar o nível lógico 0 não é aplicado qualquer sinal ao emissor. A onda

resultante esta representada na figura seguinte .


Ilustração 33 – Modelação de um bit

A figura seguinte ilustra a máquina de estados de descodificação de uma trama

RC5.

Ilustração 34 – Diagrama de descodificação das tramas RC5


5.1.2.2 Mecanismo Recepção de tramas

Para tornar a recepção de tramas pela porta UART o mais robusta possível,

criamos um vector circular no qual são colocados todos os bytes recebidos pela

porta série de uma forma sequencial pelo processo EIB_ReadRxByte e

posteriormente é executado o processo EIB_FindFrame para encontrar uma trama

válida. O vector tem a seguinte estrutura: 8

9

12

13

2

19

….

ApActual

Ilustração 35 – Passagem de vector linear a circular

Para implementar este vector circular criamos uma estrutura que permite

executar operações sobre o mesmo como que se tratasse de um vector linear de

tamanho infinito. As operações permitidas são:

IncPtr(NumInc,Ptr) - Incrementa N vezes o apontador especificado por Ptr em

que N=NumInc.

TamanhoDados(Tamanho) - Calcula o tamanho dos dados entre o apontador

ApPrimeiro e o ApActual.

EscreveByte(Byte) - Escreve na posição apontada pelo apontador ApActual o

Byte recebido pela porta série.


LeByte(Posicao, Byte) - Retorna o Byte apontado pelo apontador especificado

pela variável Posicao.

3

456

7

8

13

2

1415 16 17

18

19

ApActual

ApPrimeiro

Se tamanho >=MinTamTramaEIB

verifica se se trata de uma trama EIB válida

ApPrimeiro

Se for uma trama válida iguala o ApPrimeiro ao

ApPrimeiro+ tamanho da trama válida

Ilustração 36 – Incremento do apontador ApPrimeiro

37

14 18

Ilustração 37 – Salto do apontador para a posição inicial


5.1.3 Descrição dos processos camada ligação

de dados.

• EIB_DecodeFrame- Descodifica a trama EIB, procurando qual o serviço

associado a esta, através de uma pesquisa na tabela de descodificação de

serviços, caso seja um serviço válido chama a função que o vai tratar,

actualiza directamente as saídas. Este processo comunica com o processo

EIB_FindFrame através de uma variável global TramaEIB[ ].

• EIB_EncodeFrame- Acrescenta os endereços de grupo e/ou físicos nas

tramas EIB que são para enviar pela porta série bem como o check octeto e

o campo de controlo.

• CalculaCO() – Esta função serve apenas para calcular o check octeto

fazendo o NOT XOR a todos os octetos da trama EIB excluindo o último que

é o check octeto. Recebe como parâmetros a trama EIB e o tamanho da

mesma.


5.2 Camada Aplicação

Nesta secção será feita uma descrição pormenorizada da camada aplicação

do software.

No diagrama seguinte é possível ver o fluxo de dados entre os vários módulos e

processos desta camada e das camadas inferiores. Optamos por dividir esta

camada em duas sub camadas em que uma trata os serviços EIB e a outra

implementa os EIS.

Ilustração 38 – Diagrama de blocos da aplicação


5.2.1 Serviços EIB implementados

• GroupValueWrite – Este módulo implementa o serviço responsável por

alterar o estado de uma variável ou saída. Se for recebida uma trama EIB

deste serviço, esta função é executada e verifica na tabela de associação

quais os dispositivos associados ao código de grupo recebido. Se

encontrar algum dispositivo, verifica numa outra tabela de EIS, o tipo de

objecto a que pertencem esses dispositivos. Se existirem, é chamada a

função que implementa esse tipo de EIS. No capítulo 2, esta função EIB é

descrita com mais pormenor.

• GroupValueREAD_REQ – Este módulo implementa o serviço Group

Value Read Request pertencente ao modo de comunicação multicast.

Este serviço encontra-se descrito no capítulo 2. Tem a função de

pesquisar na tabela de associação que contém uma relação entre os

códigos de grupo e os códigos dos dispositivos, quais os dispositivos que

correspondem ao endereço de grupo destino recebido na trama EIB. Se

existirem dispositivos são guardados numa lista e passa-se por

parâmetro à função que envia implementa a função de resposta a esta

serviço.

• GroupValueREAD_RES – Este módulo é chamado pelo anterior e envia

uma resposta com o estado dos dispositivos que recebeu por parâmetro.

Recebe também a quantidade de dispositivos que tem de enviar para

calcular o tamanho da trama EIB a enviar. Constrói a trama EIB

colocando como endereço de origem, o endereço físico da placa

remetente e como endereço destino, o da placa que efectuou o pedido de

leitura. Ou seja, o endereço de destino é o mesmo endereço de origem

da trama recebida anteriormente. Este serviço está descrito com mais

pormenor no capítulo 2.

• GroupValueW_REQ – Este módulo implementa o serviço EIB de

alteração no estado dos dispositivos tal como o modulo GroupValueW(),

mas esta só tem a funcionalidade de enviar uma trama de pedido de

muda de estado às outras placas. É que para além de receber pedidos de

trocar estados, estas placas também podem efectuar pedidos a outras.

Assim pode-se utilizar os interruptores ligados a uma placa para ligarem


dispositivos de outras placas. Esta função faz o inverso da

GroupValueW(), em que recebe o código de dispositivo e, o estado e a

subfunção para o caso do Drive Control e procura na tabela de

associação, para esse dispositivo, qual o código de grupo a enviar.

Verificado o código de grupo, chama-se a função que constrói a trama

deste serviço e envia-a.

5.2.2 EIS implementados

• EIS_SWITCHING() – Esta função implementa um objecto do tipo

comutação ON/OFF em que muda o estado de uma variável ou saída

binária. Recebe como parâmetros o valor do estado e o código do

dispositivo de saída. No capítulo 2 é descrito como funciona este objecto

e para que serve.

• EIS_DRIVECONTROL() – Esta função é semelhante à anterior, mas

neste caso implementa um objecto do tipo drive control. Recebe como

parâmetros o estado, o código do dispositivo que se deseja mudar o

estado e a subfunção que indica se é uma acção do tipo STEP ou MOVE.

No capítulo 2 é descrito com mais pormenor este objecto.

• Troca_Estados() – Esta função recebe como parâmetro o código do

dispositivo e muda o estado das saídas mediante o pretendido. É aqui

que se actua directamente nas saídas.

• TimeEstoreMoving – Sempre que um dispositivo do tipo estore é activo,

inicia um contador para determinar o tempo durante o qual este está

activo, compara este tempo com o tempo definido nas variáveis

Time_max_step ou Time_max_mouving, dependendo do tipo de

movimento pedido, e quando for igual desactiva a saída associada a este

dispositivo. Este processo é activado ciclicamente com um tempo de

refrescamento de 10ms.


5.3 Estruturação de ficheiros

O software do micro controlador foi optimizado ao máximo e estruturado de

forma a funcionar como um sistema operativo. Desta forma cada processo tem um

nível de prioridade associado.

Dentro do projecto existem 5 subgrupos: o main, sched, decodeeib, readinput e o

ir. A imagem seguinte ilustra como está organizado os ficheiros do código do PIC.

Ilustração 39 – Estrutura de ficheiros do programa

Para facilitar a compreensão, os subgrupos foram estruturados de acordo com o

tipo de dados a tratar:

Main- Executa as inicializações do hardware e faz a gestão da execução dos

processos, esta associado ao nível do núcleo.

Sched- Contém a estrutura que define os processos bem como os mecanismos

de manipulação sobre estes.

Decodeeib- Contém toda a stack correspondente ao protocolo eib.


Ir- Implementa todas as funções necessárias ao funcionamento do comando de

infravermelhos, a descodificação do protocolo RC5 e a execução das instruções

correspondentes ao comando recebido.

Readinput- Verifica se ouve alteração no estado das entradas, e implementa

entradas lógicas.


6 Integração do Sistema

A construção do hardware e do software foi realizada de forma paralela e à

medida que se evoluiu no software foi existindo a necessidade de evoluir no

hardware de forma a torná-lo mais robusto e de pequenas dimensões. O que não

era possível realizar por hardware, fazia-se por software e assim criou-se um

sistema mais robusto e respeitando todos os objectivos propostos.

Uma possível instalação deste sistema numa casa é ilustrada na figura

seguinte:

Ilustração 40 – Exemplo de uma instalação do Domoitech

Neste exemplo, foram necessárias 3 placas principais fazendo um total de 21

saídas e 21 entradas. A linha desenhada com um tracejado a verde representa o

barramento Ethernet que interliga todas as placas através de um router ou switch

representado por um quadrado verde. As linhas com um tracejado a azul

P

P

R

P


representam a rede entre sensores e actuadores. É o que faz a interligação entre a

placa principal e as placas de saídas a relés e triac’s, que também têm duas

entradas respectivamente. Os pontos azuis representam as placas de saídas a relés

porque servem para ligar luzes ou outros dispositivos de accionamento do tipo

ON/OFF. Os pontos de cor violeta representam as placas de saída a triac’s para

accionamento de estores. Junto a essas placas é possível ter interruptores ligados

às mesmas, pois cada placa possui duas entradas para interruptores.

Para podermos exemplificar o funcionamento do sistema, fizemos um

expositor com duas placas principais, uma para cada divisão da casa, à qual

dividimos em um quarto e uma sala. Cada divisão tem duas lâmpadas, quatro

interruptores de pressão e um estore, simulado por duas lâmpadas indicando o

sentido de movimento do estore. O aspecto final do expositor é o seguinte:

Ilustração 41 – Expositor do projecto

As placas principais, localizam-se na parte superior do expositor e ficaram

inseridas dentro da caixa de derivação. Foram desenhadas com as medidas ideais

para caber dentro de caixas como estas. As outras placas, encontram-se dentro das

caixas dos interruptores, aproveitando o espaço que sobra entre o mecanismo do

interruptor e o fundo da caixa. Utilizamos um comando de uma televisão da Philips


porque utiliza o protocolo RC5, e com ele comandamos também as lâmpadas e

estores.

Na parte traseira do expositor, encontra-se a cablagem com a rede Ethernet e a

rede de sensores e actuadores. A cablagem que transporta os 230V CA da rede

para alimentar interruptores e lâmpadas, encontra-se completamente isolada da

cablagem que transporta os 8-12V CC da alimentação das placas principais.

Ilustração 42- Imagem da parte traseira do expositor

Para testar ainda o funcionamento de um computador servidor de web na

rede, desenvolvemos uma pequena aplicação feita em Lazarus, para comunicar com

o barramento de Ethernet enviando tramas EIB pela rede. Esta mesma aplicação,

efectua uma ligação a uma base de dados que pode ser interna ou externa e que

guarda os estados dos dispositivos. Para poder aceder a essa base de dados e

comandar remotamente dispositivos pela rede, criamos também uma aplicação web

feita em PHP.


O esquema de comunicação deste servidor é o seguinte:

Ilustração 43 - Esquema servidor web

Na parte superior encontram-se os clientes web que utilizam um browser e

com um acesso à Internet podem saber o estado ou actuar num dispositivo da casa.

Para segurança, o acesso à página só é possível com autenticação. Quando se

pede ao servidor web para mostrar a página web surge a seguinte janela:

Ilustração 44 –Página web de autenticação


Para aceder à página da habitação é necessário ter uma conta de acesso e

efectuar a validação através desta interface web. Depois de autenticado, surge outra

janela onde é possível efectuar a navegação pela habitação.

Ilustração 45 – Página web de navegação

Nesta interface web é possível seleccionar a divisão da casa que se deseja

saber o estado da mesma. Se for seleccionado a divisão sala, surge uma nova

janela como ilustrada na imagem seguinte, com a informação do estado das

lâmpadas e estores na sala e é possível actuar no estado das mesmas.

Ilustração 46 – Página web de uma divisão

Esta divisão contém das lâmpadas e um estore. É notório que as lâmpadas

encontram-se acesas pois estão sinalizadas com uma cor verde. O estore encontra-


se parado porque os sinalizadores de movimento para cima ou para baixo, estão

desligados e representados pela cor vermelha.

Como já foi explicado o servidor web comunica com uma base de dados para

alterar ou ler o valor de estados de dispositivos. Mas quem é responsável por ler

esses valores e actuar directamente na rede Domoitech, é a aplicação Fat Client

feita em Lazarus. Esta aplicação tem a seguinte interface:

Ilustração 47 – Aplicação feita em Lazarus

Com esta aplicação também é possível actuar directamente nos dispositivos

sem utilizar a página web. Assim, temos quatro maneiras possíveis de actuar por

exemplo numa lâmpada. Pode ser feita por um comando de IV, um interruptor, pela

página web ou pela aplicação feita em Lazarus. Para se poder utilizar a página web,

esta aplicação tem de estar ligada à rede Domoitech e à base de dados para poder

actualizar todos os estados. Esta aplicação está continuamente a verificar o estado

dos dispositivos da rede, enviando comandos EIB que perguntem o estado dos

mesmos e actualiza a Base de Dados com os estados. Verifica também se ocorreu

na Base de Dados alguma alteração de forma a identificar se algum cliente web

enviou alguma ordem. Se ocorrer alguma alteração, o dispositivo correspondente, é

actualizado.

É de notar que o protocolo de transporte ethernet utilizado é o UDP. Assim

não é necessário efectuar uma conexão e a transferência de tramas é feita


rapidamente. A aplicação feita em Lazarus está configurada para ser um servidor e

as placas principais são os clientes. Nesta configuração, necessitamos apenas de

definir o número da porta a utilizar e configurar nas placas principais a porta remota

com o mesmo número. É de notar que como a XPORT não permite a utilização de

multicast, todas as tramas EIB que circulam na rede, são em broadcast. Por essa

razão, é necessário configurar na XPORT como endereço remoto, o endereço de

broadcast da rede. Como a aplicação feita em Lazarus é um servidor, não é

necessário colocar um endereço IP remoto e apenas a porta pela qual comunica.


7 Conclusão

Os objectivos iniciais foram atingidos, e outros objectivos pessoais, tais como o

rigor na estruturação do software e a apresentação do hardware, foram tidos em

conta até o final do projecto e foram conseguidos.

Num tempo de projecto de aproximadamente 13 semanas com um tempo de

trabalho semanal médio de 48 horas, as primeiras 4 semanas foram para pesquisas

de soluções (protocolos, meios físicos e arquitectura). Para um bom projecto, a

análise de requisitos é uma parte muito importante e foi a de maior duração. Nas

últimas 7 semanas do projecto implementamos o software e do hardware e

montamos expositor. Realizamos 4 versões de placas principais e de software foram

realizadas 17 versões. Em cada versão de software, era criada uma nova função e

testada, se funcionasse correctamente incrementava-mos a versão de forma a

poder salvaguardar o trabalho funcional. O software foi estruturado de forma que

caso fosse necessário acrescentar alguma função ou alguma alteração, poderia ser

feito sem que isso altera-se o que já tinha sido desenvolvido. Foi necessário rever

alguns conhecimentos de redes e de sistemas operativos para nos auxiliar na

implementação do código.

Uma das principais dificuldades encontradas ao longo do projecto, foi a

adaptação ao microcontrolador desconhecido até à data e encontrar ferramentas de

trabalho gratuitas e com muitas potencialidades.

Ao nível do hardware, foi necessário rever conhecimentos de electrónica e

sentimos dificuldades na criação dos desenhos das placas de circuito impresso.

Para criação do software de um servidor de web foram necessários

conhecimentos em programação PHP e Pascal utilizada na aplicação Lazarus. As

ferramentas de criação do servidor são gratuitas, assim como a Base de Dados

utilizada (Postgresql) e que permitem diminuir ainda mais o custo do projecto.

Ao longo do projecto tivemos contacto com outros sistemas semelhantes a este,

inclusive efectuamos um estudo de mercado junto de empresas concorrentes. Não

foi possível realizar a experiência de interligar este sistema com outros, devido a

questões de tempo.


O sub capítulo seguinte contém o custo final do projecto e apresenta para um

caso igual, uma solução de um sistema concorrente.

7.1 Custo do Projecto

Placa principal:

Quantidade Descrição Preço

unitário (€)

Valor (€)

1 Gc-Xport 37.10 37.10

1 Pic18f452 plcc 12.15 12.15

7 Socket vertical 6/6 pcb 0.70 4.90

7 Conector modular 6/6 0.49 3.43

1 Socket plcc 44 pinos 0.40 0.40

1 Cristal de 20Mhz 0.43 0.43

1 Pulsor 0.50 0.50

1 Lm7805 regulador de 5v 0.40 0.40

1 Ld1117av33 regulador 3.3v 0.92 0.92

- Resistências 0.20 0.20

1 Placa PCB 7x7mm

TOTAL 60.43 €

Tabela 2 – Custo da placa principal


Placa de relés:


unitário (€)

Valor (€)



2 Relé 5v CC 5A 2.50 5.00

2 Optoacoplador 0.60 1.20

2 Conector de 5mm 4 pinos 0.84 1.68

1 Placa PCB 4x4mm

TOTAL 9.07 €

Tabela 3- Custo placa relés

Placa de triac’s:


unitário (€)

Valor (€)



2 Bt137 Triac de 600Vac 2 A 0.79 1.58

2 Optoacoplador 0.60 1.20

2 Optotriac 0.68 1.36

2 Conector de 5mm 4 pinos 0.84 1.68

1 Placa PCB 4x4mm

TOTAL 7.01€

Tabela 4- Custo placa triac’s


Orçamento para uma casa com dois quartos, uma cozinha, uma sala, uma casa

de banho, um corredor e duas varandas:


unitário (€)

Valor (€)

3 Placa principal 60.43 181.29

6 Placa de reles 9.07 54.42

14 Placa de triac’s 7.01 119.17

1 Switch D-link DES-1005D 5

Portas

18.60 18.60

TOTAL 373.48

Tabela 5- Orçamento para uma casa utilizando Domoitech

É de notar que estes preços foram consultados na empresa Farnell [9], tendo

em conta a compra de apenas uma unidade e por isso, torna o preço dos

componentes, mais elevado. É possível portanto reduzir o custo do projecto se

comprado em bastantes unidades. Existem outros valores que não foram tidos em

conta, como os portes e o custo das placas de circuito impresso, mas que não

alteram muito o valor final do projecto.

Para ter uma comparação com outros sistemas existentes no mercado,

investigamos o preço de uma solução igual a esta mas utilizando o sistema KNX/EIB

da Siemens [8]. Então, um orçamento para uma casa média com três quartos, uma

cozinha, uma sala, duas casas de banho e um corredor fica por:



unitário (€)

Valor (€)

1 Fonte de Alimentação N121 160.44 160.44

1 Filtro Indutivo N120 48.90 48.90

1 Interface RS232 N148 55,44 55,44

5 Entradas Binárias 4 p/botões

de pressão – UP220

93.81 469.05

4 Saída Binária 4 – N561 216.25 865

3 Saída de estores 2 – N521 207.60 622.8

3 Receptor de Infravermelhos 56.26 168.78

1 Comando IV – AP25 78.11 78.11

1 Descodificador de IV – N450 163.26 163.26

5 Botões de Pressão 4 Delta

Style –UP287

70.91 354.55

TOTAL 2986.33

Tabela 6 – Orçamento para uma casa utilizando a solução da Siemens

Esta solução é para um sistema com uma rede Twisted Pair e por isso necessita

de uma fonte de alimentação e um filtro para alimentar o barramento.

É notório a diferença de quase 8 vezes mais o custo entre a solução da

Siemens e a solução utilizando este projecto.


7.2 Futuros Melhoramentos

Um projecto nunca está terminado, existe sempre algo a melhorar. Neste

projecto, os principais pontos a melhorar são:

- Desenvolver mais funções e objectos EIB

- Convergir para KNX

- Compatibilidade com o software ETS para configuração das placas

- Realizar testes de compatibilidade com outros sistemas

- Criar umas caixas blindadas para colocação das placas obtendo uma melhor apresentação para venda no mercado

- Certificação do sistema


Referências

• [1] WIKIPÉDIA, http:// en.wikipedia.org, Junho 2007

• [2] MONTEIRO, José, Montagem de um sistema didáctico utilizando a

tecnologia Instabus/EIB da Siemens, José Monteiro, Dezembro 2004 .

• [3] DOMODESK, http://www.domodesk.com/, Junho 2007

• [4] CASAINTELI, http://acasainteligente.blog.com/,Março 2007

• [5] CASADOMO, http://www.casadomo.com/,Março 2007

• [6] UA, http://portal.ua.pt/bibliotecad/default1.asp?Obra=28&H1=2&H2=0,

Junho 2007

• [7] KNX, http://www.knx.org/, Março 2007

• [8] OPTERNUS, www.opternus.com, Março 2007

• [9] FARNELL, ww.farnell.com, Março 2007

• [10] LANTRONIX, www.Xport-RJ45.com, Março 2007

• [11] MICROCHIP, www.microchip.com, Março 2007


Anexo A: Descrição Protocolo X-10

O X-10 é um protocolo de comunicação, desenhado para enviar sinais pela

rede eléctrica. É um protocolo bastante utilizado na Domótica porque utiliza a

instalação prévia da rede eléctrica de uma casa, mas em contrapartida, é um pouco

lento a actuar.

As transmissões em X-10 são sincronizadas com detectores de passagem

por zero na rede eléctrica AC. Monitorizando os detectores de passagem por zero,

os dispositivos X-10, sabem quando por transmitir ou receber informação. Um dígito

binário '1' é representado por a subida da onda para 220V com a duração de 1ms e

perto do valor onde a onda passou por zero.

Uma trama X-10 é composta por um código que indica o início da mensagem

representado por '1110', seguido do código da casa e do código que pode ser de

uma função ou de endereço de uma unidade. As tabelas seguintes, indicam os

possíveis códigos para a casa, unidades e funções.

Tabela 7 – Códigos de casa


Tabela 8 - Códigos de unidades e funções

Quando os códigos das tabelas são transmitidos, cada bit é complementar de

um par de bits, por exemplo, um '0' é representado por '01' e um '1' é representado

por '10'. Utilizando o exemplo do código de casa '0110', este é transmitido com os

seus bits complementares '01101001'. O código de unidades e função é

representado por 5 bits, logo enviado com 10 bits. O último bit é '0' no caso de ser

um código de unidade e '1' no caso de ser um código de função.


Uma trama X-10 completa, é constituída por um código de início, código da

casa, código de unidade ou função e um sufixo. Cada trama é enviada duas vezes

com 3 ciclos da rede eléctrica, ou seis passagens por zero, entre um par de tramas.

Por exemplo, para ligar um módulo X-10 com o código de casa A e unidade 2, envia-

se a seguinte trama de endereço duas vezes:

Ilustração 48 - Exemplo de uma trama de endereço X-10

Depois espera-se três ciclos (seis passagens por zero) e envia-se a seguinte

trama de comando duas vezes:

Ilustração 49 - Exemplo de uma trama de comando X-10

Existem excepções neste formato, no caso de um comando de iluminação e

diming, não é necessário esperar os três ciclos entre os comandos.

Do

mo

itech

– D

omó

tica com

pro

toco

lo E

IB - 20

07

92

Anexo B: Esquema Eléctric

o Placa

Central

Title

Size Document Number Rev

Date: Sheet of

1 1.1

Placa principal

A

1 1Tuesday , June 19, 2007

SW1

RESET

R28

10k

R29

10k

R30

10k

J9

RJ11654321

J14

PROG

1 23 45 6

J1312V

1 2

LM7905RC5

GND2

VO

UT

3V

IN1

LD1117cd3.3VRC5

GND2

VO

UT

3V

IN1

VCC

U3

PIC16F877A

RE0/RD/AN59

RE1/WR/AN610

RE2/CS/AN711

GN

D13

OSC2/CLKOUT15

RC0/T1OSO/T1CKI16

RC1/T1OSI/CCP218

RC2/CCP119

RC3/SCK/SCL20

RD0/PSP021

RD1/PSP122

RD2/PSP223

RD3/PSP324

RC4/SDI/SDA25

RC5/SDO26

RC6/TX/CK27

RC7/RX/DT29

RD4/PSP430

RD5/PSP531

RD6/PSP632

RD7/PSP733

GN

D34

MCLR/VPP2

OSC1/CLKIN14

RA0/AN03

RA1/AN14

RA2/AN25

RA3/AN3/VREF6

RA4/TOCKI7

RA5/AN4/SS8

RBO/INT36

RB137

RB238

RB339

RB441

RB542

RB643

RB744

VDD35

VDD12

NC1

NC28

NC17

NC40

R210k

C1

22pf

C2

22Pf

R25100R

J4

Xport

12345678

IRreceptor

RC5

GN

D2

VOUT3

VIN1

D17BZX84C3V3/SOT

Y 320Mhz

D19LED

D20 LED

C5

10uF

C610uF

R26

470RR27

470R

J10

RJ11

654321

C710uF

J11

RJ11

654321

J12

RJ11

654321

J15

CON2

12

J16

RJ11

654321

J17

RJ11

654321

J18

RJ11

654321

Do

mo

itech

– D

omó

tica com

pro

toco

lo E

IB - 20

07

93

Anexo C: Esquema Eléctric

o Placa

Saída em Relés

Title


Date: Sheet of

2 1.1

Saida em relés

A

1 1Saturday , May 05, 2007

J1

Output

123456

J2

RJ11

123456

J3

Input

1234

Q1BC547

Q2BC547

R1

1k

R2

1k

D1DIODE

D2DIODE

LS1

Saida1

35

412

LS2

Saida2

35

412

VCC

VCC

VCC

U3A

4050

3 2

1

8

U3B

4050

5 4

1

8

R31k

R41k

Do

mo

itech

– D

omó

tica com

pro

toco

lo E

IB - 20

07

94

Anexo D: Esquema Eléctric

o Placa

Saída em Triac’s

Title


Date: Sheet of

3 1.1

Saidas em triac's

A

1 1Saturday , May 05, 2007

VCC

U3B

4050

5 4

1

8

R15

R

R14180R

R16

R

R17

R

U13MOC3011

1

2

64

Q2TRIAC

U12MOC3011

1

2

64

Q1TRIAC

J3

INPUT

1234

U3A

4050

3 2

18

R31k

R41k

J4

OUTPUT

1234

J2

RJ11

123456

Do

mo

itech

– D

omó

tica com

pro

toco

lo E

IB - 20

07

95

Anexo E: Esquema Eléctric

o

Programador

Title


Date: Sheet of

4 1.1

Programador

A

1 1Sunday , May 06, 2007

U1

MAX232A

C1+1

C1-3

C2+4

C2-5

VC

C16

GN

D15

V+2

V-6

R1OUT12

R2OUT9

T1IN11

T2IN10

R1IN13

R2IN8

T1OUT14

T2OUT7

P1

CONNECTOR DB9

594837261 J1

4 HEADER

1234

VCC

C1

10uF

C2

10uFC310uF

C410uF D1

LED

470RR

DOMOITECH – Domótica com Protocolo...

Documents

Transcript of DOMOITECH – Domótica com Protocolo...