SISTEMA INTEGRADO E MULTIPLATAFORMA PARA CONTROLE

REMOTO DE RESIDNCIAS
Fernando Gehm Moraes1
Alexandre Morais Amory 2
Juracy Petrini Jnior 2
Pontifcia Universidade Catlica do Rio Grande do Sul (PUCRS)
Faculdade de Informtica
Av. Ipiranga, 6681 - Prdio 30 / BLOCO 4
Telefone: +55 51 320-3611 - Fax: +55 51 320-3621
CEP 90619-900 - Porto Alegre - RS - BRASIL

Abstract
This work presents the implementation of a control system for house applications, belonging to a domain called
domotics or smart house systems [1-2]. The approach combines hardware and software technologies. The system is
controlled through the Internet, the home devices being connected using the control protocol. Users can remotely
control their houses using a standard Web navigator, characterizing a multiplatform system. The remote application is
the Client program. Locally, instructions sent or received from the Client are translated by the server, which
distributes the commands to a master controller. This master controller is a hardware bridge to the domestic
applications. The implemented system has the following characteristics, which distinguish it from existing approaches
[3-8]: (i) the client interface is automatically updated; (ii) a standard communication protocol is used in the hardware
implementation, providing reliability and error control; (iii) new applications are easily inserted in the system
database; (iv) system security is provided by user authentication; (v) user rights can be set up by an administration
interface.

Resumo
O presente trabalho apresenta a implementao de um sistema de controle para aplicaes domsticas, visando a
automao de lares (tambm chamada domtica [1-2]), integrando hardware e software, e prototipado via utilizao
de dispositivos programveis do tipo FPGA. Os dispositivos da casa so interligados pelo protocolo de controle
(CAN). O sistema acessvel via Internet, sendo que os usurios (moradores) podem controlar e administrar seu lar a
distncia usando um navegador Web comum (multiplataforma). A aplicao remota o programa Cliente.
Localmente, o Servidor traduz as instrues de e para o navegador Web e as distribui para as aplicaes domsticas.
O sistema proposto neste trabalho apresenta como diferencial dos sistemas existentes [3-8] as seguintes
caractersticas: (i) atualizao automtica da interface do Cliente; (ii) protocolo padro de comunicao utilizado no
hardware, o qual prov robustez e controle de erros; (iii) fcil insero de novas aplicaes no banco de dados do
sistema; (iv) mecanismos de autenticao de usurios garantindo a segurana do sistema; (v) interface de
administrao dos usurios do sistema.

Palavras Chave : Integrao hardware/software/Internet, domtica, teleao, VHDL, FPGA, Java, automao.

Doutor em Informtica, opo Microeletrnica (LIRMM, Frana, 1994), Engenheiro Eletrnico (UFRGS, 1987),
Professor Adjunto da Faculdade de Informtica/PUCRS.
E-mail: moraes@inf.pucrs.br
Bacharel em Cincia da Computao, PUCRS, 2001.

Introduo

Domtica a integrao de tecnologias e servios aplicados a lares, escritrios e pequenos prdios, com o
propsito de automatiz-los obtendo um aumento de segurana, conforto, comunicao e economia de energia [1] [2].
A domtica pode substituir o homem em diversas atividades rotineiras de forma a propiciar uma otimizao nas
condies de vida em uma casa. O prprio sistema zela pela satisfao dos moradores, sem a necessidade da contnua
interveno dos mesmos. Teleao a capacidade de se controlar algum dispositivo remotamente [2].
Unindo os dois conceitos acima descritos (domtica e teleao) surgiu a idia de interligar a rede interna de uma
casa (domtica) com a rede externa casa (Teleao/Internet) de forma que os moradores da casa possam controlar e
administrar seu lar a distncia. Unimos neste projeto uma realidade atual (Internet e micro computadores domsticos)
com uma tendncia para o futuro (domtica).
Os benefcios de domtica so classificados em quatro grupos: segurana, conforto, economia de energia e
comunicao. Segurana trata de proteger moradores e seus pertences em casos de eventualidades como invaso,
vazamento de gua, vazamento de gs, incndio, doenas, etc. Como conforto adicional que o sistema traria para seus
moradores podemos citar controle automtico de iluminao e temperatura, programao e escalonamento de
eletrodomsticos. Um sistema com controle inteligente pode evitar desperdcios de energia, contemplando o quesito
de economia de energia. J a comunicao trata da facilidade adicional que os moradores tero a respeito de
comunicao atravs do uso de videofone, chamada automtica a bombeiros e polcia e envio automtico de
mensagens eletrnicas.
Como exigncias tcnicas de um sistema de domtica podemos citar baixo custo (sistema de fcil instalao e
dispositivos baratos), plug and play, flexibilidade (sistema modular e extensvel), confiabilidade e fcil utilizao. O
sistema apresentado neste artigo contempla estes requisitos (alguns parcialmente) por se tratar de um sistema
estruturado de forma modular, utilizando recursos padro, tanto para software quanto para hardware.
Uma srie de outros sistemas com propostas semelhantes a esse projeto foram encontradas na Internet. Entre
eles citamos: HAI [3], Home Seer [4], HAL 2000 [5], Mister House [6] e Omnipotence[7], sendo que a referncia [8]
voltada para automao industrial.
Tem-se por motivao para o desenvolvimento deste trabalho o projeto integrado de hardware (o protocolo de
controle) e software (a comunicao Cliente/Servidor e a interface RS-232C), e o desenvolvimento da interface da
aplicao (home page da casa). Outra motivao ao desenvolvimento deste trabalho a criao de uma nova
aplicao para computadores e Internet. Essa aplicao poder contribuir para que o uso de computadores faa cada
vez mais parte do dia-a-dia do usurio comum.
Esse artigo organizado da seguinte forma. A Seo 2 descreve a arquitetura do sistema. As Sees 3 e 4
descrevem as implementaes do software e hardware, respectivamente. A Seo 5 apresenta algumas concluses e
trabalhos futuros.

Arquitetura do Sistema

O sistema desenvolvido baseado na comunicao entre dois ou mais computadores atravs do protocolo de
comunicao HTTP. Um destes computadores denominado de Servidor e os restantes denominados Clientes.
Internamente casa existe uma outra rede utilizando o protocolo CAN, responsvel por interligar os diversos
perifricos da casa. O protocolo Controller Area Network (CAN [17]) um protocolo de controle para diversos
ambientes industriais. Atravs de um Controlador Mestre (placa de aquisio CAN), esta rede interna comunica-se
com o computador Servidor atravs de uma porta serial RS-232C. A Figura 1 ilustra a estrutura geral do sistema.
O computador Cliente responsvel por permitir que o usurio possa interagir com sua residncia. Para que isso
seja possvel, h no computador Cliente um software responsvel pelo envio de sinais de controle denominados
pacotes de controle. Estes pacotes sero recebidos pelo Servidor que se encarrega de trat-los de maneira adequada.
Devido ao crescimento e popularizao da Internet, o software utilizado no lado Cliente um navegador Web. Sendo
assim, o navegador Web responsvel em enviar os pacotes de controle ao Servidor atravs do protocolo HTTP, e ao
mesmo tempo responsvel por manter a interface com o usurio atualizada medida que o Servidor envia
atualizaes.
O Servidor responsvel por receber pacotes de controle do Cliente (Figura 1-1) que sero enviados a partir do
navegador Web que estiver rodando na mquina Cliente. O Servidor por sua vez interpreta estes pacotes de controle

recebidos do Cliente, atualiza o banco de dados (Figura 1-4) e repassa estes pacotes de controle atravs da porta
serial RS-232C (Figura 1-5) para o Controlador Mestre da rede interna da casa (Figura 1-6).

CL

CL

Controlador
mestre

CL

CL

Figura 1 Estrutura completa do sistema.

Um servidor Web Apache, instalado no Servidor, responsvel por disponibilizar a interface do(s) Cliente(s).
Programas desenvolvidos em PHP (Figura 1-2) recebem os pacotes de controle enviados pelo usurio atravs do
navegador Web, atualizando um banco de dados (Figura 1-4) contido no Servidor. Este banco de dados tem como
principal funo manter o estado atualizado sobre cada aplicao domstica que est sendo controlada remotamente.
Tambm responsabilidade do Servidor a atualizao, de maneira transparente ao usurio, da interface do navegador
Web do Cliente. Este gerao dinmica de pginas gerenciada pela aplicao escrita em PHP. Em outras palavras,
isso possibilita que o usurio tenha sempre dados atualizados de sua residncia sem a necessidade de ficar acionando
um comando de atualizao da interface (navegador).
Ainda no contexto do Servidor, existe uma aplicao escrita em Java (Figura 1-3), responsvel pela
comunicao com a porta serial RS-232C, possibilitando o envio e recebimento de pacotes de controle do
Controlador Mestre. Outro objetivo da aplicao Java garantir a consistncia das aplicaes domsticas da
residncia de acordo com o seu respectivo status no banco de dados, pois este ltimo reflete diretamente os comandos
de atualizao enviados pelo usurio a sua casa.
A autenticao de usurios e encriptao dos dados so mecanismos utilizados para garantir a segurana do
sistema, impedindo que pessoas desautorizadas tenham acesso ao mesmo.
O Controlador Mestre da rede residencial faz a codificao dos dados recebidos pelo Servidor para o protocolo
CAN. Alm disso, tarefas como endereamento dos pacotes, gerenciamento do barramento e decodificao dos dados
recebidos dos perifricos para o Servidor, tambm so tarefas do Controlador Mestre.
Uma rede serial com protocolo CAN instalada na casa. Essa rede interliga todos os perifricos e nela trafegam
os comandos e dados necessrios para se atingir o objetivo de automatizar a casa. Cada perifrico tem um
Controlador Local (CL na Figura 1), que recebe (ou envia) comandos do (ou para o) barramento serial, controlado
pelo Controlador Mestre. O protocolo CAN implementado utilizando um IP Core escrito em VHDL.

Implementao do Software

A implementao do software dividida em dois componentes, conforme explicado na Seo anterior. De uma
lado tem-se o Cliente, que envia/recebe pacotes de controle atravs da internet, utilizando o protocolo de
comunicao HTTP (HyperText Transfer Protocol), e de outro lado o Servidor, que atua como uma interface entre os
perifricos da casa e o Cliente.
3.1

Implementao do Cliente
A interface do Cliente um navegador Web. Sua principal funo exibir ao usurio o status de sua residncia,
alm de possibilitar a interao com este, permitindo que o mesmo possa executar comandos remotos na sua

residncia, como por exemplo desligar a lmpada da sala, capturar a imagem de vdeo de uma cmera na entrada da
casa, ou receber mensagens de alarme.
Para o desenvolvimento da interface foram utilizadas trs linguagens de programao: (i) HTML - usada para
montar estaticamente a interface da aplicao no Cliente; (ii) Javascript - responsvel por tornar a interface dinmica
a medida que o usurio interage com a mesma e para gerar atualizaes na interface quando ocorrem mudanas na
aplicao final (residncia); (iii) PHP [9]- gerao de pginas dinmicas para atender a interao entre clienteservidor.
A interface Web possui os seguintes frames: Frame 1 Biblioteca de funes Javascript; Frame 2 Programa
PHP de leitura do banco de dados; Frame 3 Programa PHP para atualizao do banco de dados; Frame 4 Menu de
opes; Frame 5 Aplicaes encontradas na residncia.
Os frames 1, 2 e 3 so invisveis para o usurio, pois so responsveis unicamente pelo processamento de
informaes que ocorrem em segundo plano na interface Cliente.
No frame 2 existe um programa desenvolvido em PHP cuja principal funo ler o banco de dados contido no
Servidor, verificando quais dos registros esto desatualizados em relao ao computador Cliente. Com base nestes
registros, o programa PHP gera comandos Javascript que atualizam a interface Web. Como se fosse uma thread, este
programa invocado de tempos em tempos garantindo a atualizao da interface Web. Com a utilizao de comandos
Javascript para atualizao da interface, esta ocorre de maneira automtica sem que o usurio precise apertar em um
boto Atualizar a todo instante, desde que esteja associada constante monitorao automtica do banco de dados.
Esta uma importante vantagem do sistema, uma vez que o usurio automaticamente informado de tudo que
monitorado na residncia, possibilitando, inclusive, o recebimento de mensagens de alarme na interface.
Devido dinmica utilizada para a atualizao da interface Cliente, criou-se uma biblioteca de funes
Javascript. Esta biblioteca est localizada no frame 1 e atualmente agrupa um nmero determinado de funes para as
aplicaes j desenvolvidas. medida que novos controles da residncia so implementados na interface, esta
biblioteca Javascript deve agregar as novas funcionalidades necessrias.
A Figura 2 ilustra um exemplo de interface do Cliente, tendo como perifricos lmpadas, dimmers e uma
cmera de vdeo.

Figura 2 Exemplo de interface do Cliente.

3.2

Servidor
O Servidor o computador da residncia e faz a interface entre o Cliente e os perifricos da casa. Dentre as
funcionalidades realizadas pelo Servidor, citamos: (i) envio, recepo e interpretao de pacotes de controle atravs
da porta RS-232 para o Controlador Mestre; (ii) monitorao do banco de dados em busca de alteraes no status da
aplicao; (iii) atualizao do banco de dados; (iv) atualizao dinmica da interface no(s) Cliente(s).
As funcionalidades do Servidor so divididas em trs conjuntos: comunicao com o Cliente, banco de dados e
comunicao com o Controlador Mestre.

A comunicao com o Cliente ocorre atravs do protocolo HTTP. A distribuio das informaes atravs deste
protocolo feita atravs de um servidor Web Apache [10] rodando no Servidor. Todas as requisies que partirem do
Cliente so recebidas pelo servidor Web. O Servidor responsvel por gerenciar estas requisies e respond-las ao
longo do tempo.
A linguagem PHP utilizada para gerar sadas de texto no formato HTML/Javascript que, quando enviadas
atravs do protocolo HTTP ao Cliente (navegador Web), so interpretadas, montando a interface visual e um conjunto
de funcionalidades oferecidas ao usurio.
A Figura 3 apresenta a estrutura de banco de dados utilizado no sistema, assim como seus respectivos
relacionamentos.

Figura 3 Tabelas do Sistema.

A Figura 3 ilustra no canto superior esquerdo a tabela Usuarios. Sua principal funo armazenar os usurios
que possuem permisso de acesso homepage da residncia e, consequentemente, o acesso s aplicaes desta.
Tambm indica quais usurios possuem acesso interface de manuteno de usurios. Visando aumentar a segurana
e a confiabilidade do sistema, a senha do usurio criptografada e armazenada no banco de dados. O algoritmo de
criptografia utilizado pelo sistema o md5, com fingerprint de 128 bits [11].
A TabelaDados responsvel por armazenar os dados referentes s aplicaes existentes na residncia. Outra
tabela existente no banco de dados a TabelaNodos. Esta tabela responsvel por armazenar as informaes
referentes aos perifricos existentes na residncia. O relacionamento criado entre as tabelas TabelaNodos e
TabelaDados existe para permitir identificar quais so os dados pertencentes a cada aplicao (nodo).
Esta organizao do banco de dados garante independncia das aplicaes na atualizao dos dados. Em outras
palavras, pacotes de controle que chegam ao Servidor so gravados diretamente no banco de dados, no importando
que tipo de aplicao est enviando estes pacotes.
Para a comunicao com o Controlador Mestre desenvolveu-se um software em Java [12] [13] responsvel pelo
controle e atualizao do banco de dados, juntamente com o controle da porta de comunicao RS-232. O acesso ao
banco de dados acontece atravs dos mtodos da biblioteca JDBC, utilizando o driver JDBC-ODBC, que
responsvel por atualizar o banco de dados em relao aos perifricos da casa e vice-versa. Para a implementao da
comunicao serial utilizando RS-232, utilizou-se o pacote desenvolvido pela Sun Microsystems denominado de
CommAPI [14].
Todas as operaes realizadas pelo software so executadas atravs da chamada de mtodos de objeto em Java.
A utilizao da linguagem Java tambm garante a portabilidade do sistema entre diferentes plataformas. A Figura 4
ilustra o relacionamento dos mtodos utilizados pela aplicao para a comunicao com o banco de dados e porta de
comunicao RS-232.

enviaPacote( )
Controle da
Porta Serial

gravaPacote( )

MontaPacoteControle( )

RS-232

monitoraMestre( )

BANCO
DE DADOS

Figura 4 Mtodos de acesso ao banco de dados e porta serial de comunicao RS-232.

O mdulo de comunicao serial gerencia o envio e a recepo de pacotes de controle em paralelo. A qualquer
momento o controlador mestre pode enviar pacotes. Utilizou-se threads para possibilitar a monitorao da porta
serial, pois ao mesmo tempo em que a porta serial monitorada, outras operaes devem ser realizadas pelo software.
Para conseguir classificar os bytes que chegam na porta serial e montar um pacote de controle, seja ele de que
tipo for, criou-se um mtodo chamado de montaPacoteControle(), o qual sempre recebe o byte proveniente da porta
serial. Internamente a este mtodo, mecanismos de controle e sequenciamento foram implementados para que o
pacote de controle seja identificado dentro da seqncia de bytes que chegam. Atualmente classificamos os pacotes
como sendo de dois tipos: (i) pacotes pequenos pacotes com at 8 bytes de tamanho; (ii) pacotes grandes pacotes
maiores que 8 bytes.
No mdulo de acesso ao banco de dados existem dois eventos que necessitam que ocorra o acesso automtico aos
dados (registros): (i) chegada de pacotes atravs da serial; (ii) envio de pacote atravs da porta serial. Como
conseqncia da chegada de pacotes de controles da casa, necessita-se atualizar o banco de dados com as informaes
provenientes deste pacote. Visando alcanar este objetivo, criou-se um mtodo denominado gravaPacote().
Internamente a este mtodo realizada uma atualizao do registro, localizado na estrutura TabelaNodos. Criou-se o
mtodo monitoraMestre() cuja funo principal procurar no banco de dados aplicaes que estejam com o status
desatualizado em relao ao controlador mestre e enviar estas informaes atravs da porta serial, utilizando o
mtodo chamado enviaPacote().

Implementao de Hardware

A crescente demanda de comunicao, conectividade e fluxo de informaes impulsionou a criao de vrios

protocolos de comunicao. O estudo das caractersticas de protocolos depende muito da aplicao destes. Por
exemplo, se procurarmos um protocolo para ser usado em uma grande indstria metalrgica esse protocolo deve ter
longo alcance para poder se estender por toda empresa, poder ligar vrios nodos, ter grande imunidade a rudos
usando tcnicas de deteco e correo de erros, ter alta disponibilidade e tolerncia a falhas, uma vez que grandes
valores e vidas humanas podem estar em jogo. J um protocolo para aplicao de entretenimento, basicamente usado
somente dentro do ambiente domstico, no necessita ter alta disponibilidade, precisa ter grande taxa de transferncia
para transportar vdeo e som, um alcance curto o suficiente, compatibilidade entre vrios fabricantes necessria,
etc.
Os dois exemplos citados acima, de uma certa forma ortogonais, nos mostram que as caractersticas e requisitos
de um protocolo podem variar muito, dependendo exclusivamente de sua aplicao. Porm, conhecendo-se apenas a
aplicao no se faz uma escolha adequada de protocolo. A seguir descrevemos mais algumas caractersticas tcnicas
que devem ser avaliadas: (i) a relao custo/benefcio da tcnica de cabeamento. A tcnica de cabeamento e conexo
um dos itens que mais influenciam o custo total de instalao de uma rede; (ii) plug and play, confiabilidade,
disponibilidade, flexibilidade, compatibilidade, sincronizao e padronizao; (iii) variabilidade de aplicaes o
mesmo protocolo pode ser empregado em aplicaes diferenciadas?; (iv) existncia de protocolos de nvel de
aplicao; (v) ferramentas para teste e diagnstico, interface com PC e drivers de hardware e software; (vi) taxa de
comunicao, resposta em tempo real, tcnica de acesso ao meio, topologia, comprimento fsico mximo da rede e
nmero de bytes de dados; (vii) a rede deve ser multi-mestre ou com um nico mestre? suporta broadcasting e
multicasting? suporta requisio remota de dados e reconhecimento ? (viii) maior aceitao no mercado e potencial de
crescimento.
Com o objetivo de encontrar um protocolo de controle que atendesse os requisitos citados acima, analisou-se
uma srie de protocolos de controle dentre eles EHS, BDLC, LON, EIB, X-10, CeBus e CAN. Detalhes sobre a
escolha do protocolo e uma tabela comparativa entre estes protocolos pode ser encontrada em [1].
4.1

Controller Area Network (CAN)

Dentre os protocolos estudados, o Controller Area Network [15][16][17] foi o protocolo que atendeu o maior
nmero de itens e o que se adaptou melhor ao desenvolvimento deste trabalho.

CAN um protocolo de comunicao serial que suporta controle em tempo real distribudo, com um grande
nvel de segurana. Foi originalmente desenvolvido para aplicaes automotivas, mas hoje em dia j existem outras
aplicaes variando de sistemas de controle industrial a sistemas de aplicao especficas como satlites artificiais e
sistemas mdicos. Neste trabalho propomos o emprego de CAN a uma nova aplicao. Essa aplicao um sistema
de superviso de domtica via web, servindo o protocolo como rede de controle da casa.
Dentre as principais caractersticas do protocolo CAN citamos: (i) mtodo de acesso ao barramento com
priorizao de mensagens; (ii) taxa de transferncia de at 1Mbps; (iii) garantia do tempo de latncia (tempo real);
(iv) flexibilidade de configurao; (v) recepo multicast com sincronizao; (vi) vrias tcnicas para manter
consistncia de dados e sinalizao de erros; (vii) multi-mestre; (viii) tcnicas de deteco e sinalizao de erros; (ix)
desligamento automtico de nodos com defeitos; (x) possui tcnica de requisio remota de dados; (xi) possui at 8
bytes no campo de dados.
A Figura 5 ilustra o formato do pacote de dados CAN.
BUS
IDLE

DADOS

CRC ACK EOF

Intermission

0 a 8 bytes

16 bits 2 bits 7bits

3 bits

SOF Arbitrao Controle

1 Bit

12 ou 32 bits

6 bits

Figura 5 Formato de um pacote de dados CAN.

Para a implementao deste trabalho foi adaptado um IP Core chamado HurriCANe que implementa o protocolo
CAN. Esse IP Core foi descrito em VHDL e desenvolvido na ESA (European Space Agency) [18].
A Figura 6 ilustra a estrutura hierrquica do HurriCANe com a ocupao de slices (bloco lgico bsico do
FPGA) para um FPGA xcv300-5-bg352 da famlia Virtex 300 da Xilinx. Detalhes de como esse IP Core foi utilizado
neste trabalho so encontrados na referncia [1].
CAN
controller

603 slices

CAN
core

749 slices

CAN
interface
212 slices

CAN rx
264 slices

CAN tx
99 slices

Stuff
handler
6 slices

CRC calc
21 slices
Error
frame
24 slices

Syncro
31 slices
Error
Counter
68 slices

Figura 6 Estrutura do HurriCANe.

O mdulo Interface prov ao usurio do core uma interface padro entre dispositivos, baseando-se em
comandos de escrita (transmisso) e leitura (recepo). Esse mdulo especialmente importante caso use-se o
HurriCANe associado a um processador comercial, pois esta interface facilitar o controle e o trfego de dados entre
a aplicao do usurio e o core CAN. O mdulo CAN Core o principal mdulo do protocolo. Ele interliga todos os
mdulos que esto abaixo na hierarquia. Pelo fato de no ter sido proposto neste projeto o desenvolvimento da
interface entre CAN e um processador, usou-se somente este mdulo, CAN core.
4.2

Nodos Escravos
Os nodos Escravos, tambm chamados de nodos de aplicao, so os nodos que esto distribudos pela casa
responsveis por controlar perifricos variados. Os nodos Escravos variam entre si de acordo com sua aplicao.
Podemos ter, por exemplo, um nodo que controla lmpadas, sensores de temperatura, entre outras aplicaes
possveis.
Cada aplicao controlada existente na casa deve possuir um suporte tanto em hardware quanto em software.
Por exemplo, para se fazer o controle de lmpadas necessrio existir no sistema mdulos (hardware) que fazem a

interface das lmpadas com o barramento CAN, e mtodos (software) no Servidor para gerenciar lmpadas. Foi
implementado para este projeto uma aplicao de lmpadas, que demonstra o funcionamento do sistema.
A aplicao de lmpadas foi implementada em VHDL [19] em uma plataforma de prototipao XS40 [20] com
FPGA xc4010-3-EPC84 com capacidade de cerca de 10.000 portas lgicas. Esta aplicao suporta at 64 lmpadas,
uma vez que o protocolo CAN possui 8 bytes de dados (8bytes x 8bits). Cada bit do campo de dados representa o
estado de uma lmpada (acesa ou apagada). Mais detalhes da arquitetura dos nodos de lmpadas so encontrados na
referncia [1].
Dentre as informaes geradas no relatrio de sntese da ferramenta Xilinx Foundation em relao a um FPGA
xc4010e-3-pc84, destacamos a rea em nmero de CLBs (294 CLBs com 73% de utilizao total) e o relatrio de
temporizao com uma freqncia mxima (9.018MHz) que essa descrio suporta.
4.3

Nodo Mestre
O Nodo Mestre responsvel por fazer a interface entre a rede CAN e o Servidor. Ele foi implementado na
plataforma de prototipao VW300 [21] com um FPGA xcv300-5-bg352 [22], possuindo 3072 slices (cerca de
300.000 portas lgicas equivalentes).
A arquitetura do nodo Mestre pode ser visualizada na Figura 7. Ela baseada em um sistema de filas pelo fato
das duas interfaces (serial e CAN) terem velocidades de transmisso diferentes. Quando a interface CAN recebe um
pacote, o mesmo dividido em at 13 bytes e gravado byte a byte na fila CAN. Enquanto a fila CAN no est vazia a
interface serial transmite dados desta fila pela serial. De forma anloga, quando a interface serial recebe algum dado,
a mesma o grava na fila Serial. Enquanto essa fila no est vazia, a interface CAN transmite dados pelo barramento
CAN para que o nodo destino possa receb-lo.

Fila
Serial

SERVIDOR
Interface
Serial

Interface
CAN

Fila
CAN

PERIFRICOS

CAN

Figura 7 Arquitetura do nodo Mestre.

As filas da interface CAN e serial so implementadas utilizado memrias RAM internas ao FPGA chamadas
Block Select Ram [23]. Nessa implementao o Block Select Ram est configurado para ser uma memria dual port
(sendo uma porta somente de escrita e outra somente de leitura) de 8 bits de tamanho de palavra, com 512 palavras
A interface serial responsvel por enviar/receber dados ao/do Servidor. Esse mdulo funciona sem paridade,
com 1 stop bit e com taxa de transmisso de 19200 bps expansvel at 115200 bps.
A interface CAN composta pelo IP Core HurriCANe com alguma lgica adicional especfica para essa
implementao.
A Tabela 1 apresenta um resumo com as principais informaes geradas durante o processo de sntese do nodo
Mestre, utilizando o sistema de CAD Foundation, fornecido pela XILINX. Esses dados foram gerados levando-se em
considerao a utilizao do FPGA xcv300-5-bg352, sem uso de esforo mximo de sntese.
Mdulos
Mestre
Interface CAN
Interface Serial
Fifos

Ocupao
(Slices)
731
512
65
116

Ocupao
(%)
23
16
2
3

Freqncia Mxima
(MHz)
26.134
25.028
85.434
37.448

Tabela 1 Resumo de relatrios de sntese do Mestre (freqncias obtidas por snteses independentes).

O pacote CAN recebido ou enviado pelo Controlador Mestre dividido em at 13 pacotes de um byte no
protocolo serial. Os byte 1 a 4 formam o identificador da mensagem, o byte 5 de controle e os 8 bytes restantes
contm os 8 bytes de dados do protocolo CAN.

4.4

Protocolo de Aplicao
O protocolo CAN possui um limitao para ser aplicado a domtica. Ele transmite somente at 8 bytes de dados.
Para que aplicaes que contm pacotes de dados com tamanho superior a 8 bytes necessrio acrescentar um nvel
de abstrao superior ao protocolo CAN, denominado de protocolo de aplicao. Os autores propem neste trabalho
uma forma de transmitir informaes complexas, tais como udio, imagens e vdeo utilizando CAN. A idia dividir
os pacotes CAN em dois grupos: pacotes de dados e de controle. Diferenciam-se pacotes de dados e pacotes de
controle pelo nmero de identificao do nodo ou servio (Id, inserido no campo Arbitrao da Figura 5). Ids mpares
identificam mensagens de controle, pares identificam mensagens de dados.
Os pacotes de dados so os pacotes normalmente transmitidos pela rede. Esse pacote possui o limite de 8 bytes
de dados. Os pacotes de controle so servios especiais do sistema que solicitam ou informam alguma caracterstica
especfica para determinada aplicao. Por exemplo, uma cmera de vdeo pode enviar um pacote de controle para o
Servidor informando que comear a transmitir uma imagem de 100 Kbytes. Outro possvel exemplo seria a
transmisso de uma mensagem de controle do Servidor para um nodo de lmpadas solicitando um auto teste do nodo.
Vale ressaltar que com essa tcnica a compatibilidade com o protocolo CAN foi preservada. As alteraes
refletem-se em um nvel de abstrao acima do CAN Core, nvel este onde so implementadas as aplicaes que
controlam os perifricos em questo.
Essa abordagem possibilitou uma grande flexibilidade ao sistema. Quando for um pacote de controle, dos 8
bytes de dados, 1 utilizado para identificar o servio e 7 para identificar o(s) parmetro(s) de execuo. Assim, h
suporte para a criao de at 256 servios para cada aplicao existente no sistema, sendo que cada servio pode ter
at 7 bytes de parmetros. Por exemplo, se o servio requer mais de 8 bytes de informao, e utiliza os 7 bytes
restantes par especificar o tamanho (em bytes) da informao a ser transmitida, o hardware suporta uma transmisso
terica de at 2^56 (8bits*7bytes) bytes de dados.
4.5

Validao
Para depurao do sistema de hardware foi utilizado o Simulador VHDL da Mentor Graphics chamado QHSIM,
osciloscpio Tektronix TDS 220 e analisador lgico HP 16663E. A plataforma de teste de sntese usada para validar
sistema de hardware apresentada na Figura 8. Os seguintes recursos foram usados: (i) um micro-computador que
funciona como o Servidor do sistema, comunicando-se com o Controlador Mestre pela porta serial; (ii) osciloscpio
que monitora o sinal no barramento CAN; (iii) analisador Lgico que monitora sinais do Mestre usados para
depurao; (iv) placa de prototipao VW300 [21] onde a descrio VHDL do Controlador Mestre executada; (v)
Placa de prototipao XS40 [20] onde a descrio VHDL da aplicao de lmpadas executada.

ii
iii
i
iv
v
Figura 8 Ambiente de teste do Controlador Mestre

Concluses e Trabalhos Futuros

Este trabalho apresentou a implementao de um sistema de domtica que possibilita o controle remoto de
residncias com o uso de um navegador web. Este trabalho integrou diversas tecnologias em nveis de abstrao
variados (hardware/software/Internet). O hardware foi totalmente implementado em VHDL, adaptando um IP Core

que implementa o protocolo CAN. O software foi desenvolvido em Java com mtodos de acesso a interface serial
para comunicao com hardware e mtodos para acesso ao banco de dados. A Internet foi empregada a partir de
aplicaes desenvolvidas nas linguagens HTML e PHP, responsveis pela implementao da interface do sistema que
roda em um navegador web.
Alm de integrar hardware e software, o sistema multiplataforma, pois o Cliente necessita apenas um
navegador web para controlar sua residncia. O servidor tambm multiplataforma, pois o software Apache
disponvel para diferentes arquiteturas, alm de utilizarmos linguagens padro, como Java e PHP.
Como proposta para trabalhos futuros pode-se citar: (i) a mudana da interface de comunicao entre hardware e
software de serial para PCI; (ii) o servio que implementa um protocolo Plug and Play; (iii) para verificar o correto
funcionamento dos nodos de aplicao distribudos pela casa sugerimos tcnicas de keep alive, testabilidate remota
usando auto teste (BIST); (iv) servio de reconfigurao remota usado para atualizao de verso e manuteno dos
nodos de aplicao; (v) mecanismo de time to live para pacote segmentados (dados com mais de 8 bytes); (vi) controle
de acesso Web com mltiplas permisses possibilitando desabilitar a interao de, por exemplo, crianas com o
sistema de segurana.

Agradecimentos
Agradecemos as contribuies dadas por Eduardo Bezerra (E.A.Bezerra@sussex.ac.uk) a este trabalho e a Luca
Stagnaro (lstagnaro@estec.esa.nl), da Agncia Espacial Europia (ESA), por ter cedido o IP Core HurriCANe. O
autor Fernando Gehm Moraes agradece o suporte do CNPq (projeto integrado nmero 522939/96-1) e da FAPERGS
(projeto nmero 96/50369-5).

Bibliografia
[1]

[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]

Moraes, Fernando; Amory, Alexandre M.; Petrini, Juracy Jr. Sistema Cliente-Servidor para Superviso de Processos
atravs da Web. trabalho de concluso do curso de informtica da PUCRS. dezembro de 2000. 167p.
[http://www.ee.pucrs.br/~amory/Trabalho_de_Conclusao/trabalho_de_conclusao.html ]
F. Baumann; B. Jean-Bart; A. Kung, P. Robin. Eletronic Commerce Services for Home Automation. Trialog.
[ http://www.trialog.com/emmsec9-97.pdf ].
Home Automation, Inc. HAI Web-Link Software Homepage. [http://homeauto.com/web-link/index.htm].
Keware Tecnologies. HomeSeer Software. [http://www.homeseer.com].
Home Automated Living. HAL 2000 Software. [http://www.automatedliving.com/ ].
MisterHouse. Home Automation Software. [http://www.misterhouse.net/ ].
Omnipotence Software. Event Control System - ECS. [http://www.usit.com/omnip/home-automation-1.htm].
Brando, Eduardo Scharnberg. Sistema Cliente-Servidor para Superviso de Processos atravs da Web. trabalho de
concluso do curso de informtica da UFRGS. fevereiro de 1999. 57p.
PHP Hypertext Preprocessor. [http://www.php.net].
The Apache Software Foundation. [http://www.apache.org]
The MD5 Message - Digest Algorithm. [http://www.faqs.org/rfcs/rfc1321.html]
Cornell, Gary; HorstMann, Cay S. Core Java Second Edition. Califrnia, SunSoft Press, 1997.
Wigglesworth, Joe; Lumby, Paula Java Programming Advanced Topics. Thomson Learning, 2000.
Java(TM) Communications API. [http://www.java.sun.com/products/javacomm/index.html]
Bosch CAN Homepage. [http://www.bosch.de/k8/can/ ].
ROBERT BOSCH GmbH. CAN Especification Version 2.0. Stuttgart. 1991.
[http://www.bosch.de/k8/can/docu/can2spec.pdf].[http://www.can-cia.de/CAN20B.pdf].
Lawrenz, Wolfhard. CAN System Engineering From Theory to Practical Applications. 1997. 468 pp.
HurriCANe Home Page. [ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/can.htm].
Mazor, Stanley; Langstraat, Patricia. A guide to VHDL. Boston : Kluwer Academic, 1996. 250p.
XESS Inc. XS40 Board V1.4 User Manual . XESS Corporation. [http://www.xess.com/manuals/xs40-manual-v1_4.pdf].
VCC Inc. The Virtual WorkBench Guide. Virtual Computer Corporation. [ http://www.vcc.com].
Xilinx Inc. Virtex 2.5V Field Programmable Gate Arrays (DS003). Virtex Series.
Xilinx Inc. Using the Virtex Block SelectRAM+ Features (Application Note XAPP130). Virtex Series.

10