reder CAN

Prévia do material em texto

12 
 
UNIVERSIDADE FEDERAL DO PARANÁ 
 
CURSO DE ENGENHARIA ELÉTRICA 
 
 
 
 
 
 
EDUARDO HENRIQUE CORRÊA FERREIRA 
 
 
 
 
 
 
 
 
 
 
 
AUTOMAÇÃO RESIDENCIAL UTILIZANDO PROTOCOLO CAN 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CURITIBA, 2009 
13 
 
EDUARDO HENRIQUE CORRÊA FERREIRA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AUTOMAÇÃO RESIDENCIAL UTILIZANDO PROTOCOLO CAN 
 
 
 
 
 
Trabalho de Conclusão de Curso 
elaborado por Eduardo Henrique Corrêa 
Ferreira, sob a orientação do Professor 
Eduardo Parente Ribeiro, para obtenção 
de grau no Curso de Engenharia Elétrica 
da Universidade Federal do Paraná, 
UFPR. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CURITIBA, 2009 
14 
 
EDUARDO HENRIQUE CORRÊA FERREIRA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AUTOMAÇÃO RESIDENCIAL UTILIZANDO PROTOCOLO CAN 
 
 
 
Trabalho de Conclusão de Curso 
aprovado pela Banca Examinadora para 
obtenção do Grau de Eduardo Henrique 
Corrêa Ferreira, no Curso de Engenharia 
Elétrica da Universidade Federal do 
Paraná, com Linha de Pesquisa em 
Automação Residencial. 
 
Curitiba, 15 de Novembro de 2009. 
 
BANCA EXAMINADORA 
 
 
__________________________________________________ 
Professor Dr. Eduardo Parente Ribeiro – Orientador 
 
_________________________________________________ 
Professor M.Sc Ademar Luiz Pastro 
 
_________________________________________________ 
Professor Dr. Gideon Villar Leandro 
 
 
15 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
À minha noiva, Marciany, meus pais, 
Haroldo e Solange, e minha avó Maria 
José por terem me apoiado não só na 
elaboração deste trabalho como em tudo 
na minha vida. 
 
16 
 
 
 
 
AGRADECIMENTOS 
 
 
Em primeiro lugar agradeço a Deus por ter me dado esta oportunidade; 
 
Agradeço também à Universidade Federal do Paraná; 
 
Ao orientador, professor Dr. Eduardo Parente Ribeiro, por ter ajudado na 
criação deste trabalho; 
 
 Aos demais professores e colaboradores do curso de Engenharia Elétrica da 
Universidade Federal do Paraná; 
A todos que de uma maneira ou outra contribuíram para a realização deste 
trabalho. 
 
 
17 
 
RESUMO 
 
 
Este trabalho tem por objetivo a aplicação do protocolo CAN em 
aplicações de automação residenciais. Primeiramente é analisada a estrutura 
do protocolo de comunicação CAN. Em seguida é feito um pequeno resumo 
sobre outros protocolos utilizados em automação residencial. E por fim é 
mostrado como um sistema automatizado pode ser criado utilizando um 
computador pessoal como integrador da rede de dados CAN, os componentes 
usados para este sistema e um exemplo de software desenvolvido para esta 
finalidade. 
Palavras-chave: CAN, Automação Residencial, protocolo. 
 
 
 
 
18 
 
ABSTRACT 
 
 
This paper analyzes the application of CAN protocol for Home 
Automation. First, the structure of the CAN communication protocol is reviewed. 
Next comes a short summary on other protocols used in residential automation. 
And finally is showed how can an automation system be created using a 
personal computer as an integrator for the CAN network, the components used 
to make this system and an example of a software built to control this data flow. 
 
 
 
19 
 
 LISTA DE ILUSTRAÇÕES 
 
 
FIGURA 1 - TOPOLOGIAS PERMITIDAS PELO PADRÃO ZIGBEE .................................. 25 
FIGURA 2 - EXEMPLO DE TOPOLOGIA DE REDE CEBUS ........................................... 27 
FIGURA 3 - EXEMPLO DE APLICAÇÃO CEBUS ......................................................... 28 
FIGURA 4 - CAMADAS ISO E CAN ........................................................................ 30 
FIGURA 5 - TOPOLOGIA DE BARRAMENTO CAN ...................................................... 31 
FIGURA 6 - NÍVEL DE BARRAMENTO, SEGUNDO ISO 11898 ..................................... 32 
FIGURA 7 - GRÁFICO DE TAXA DE TRANSMISSÃO DE BITS PELA DISTÂNCIA DOS NÓS .. 32 
FIGURA 8 - MODELOS DE CONECTORES DB 9 ........................................................ 33 
FIGURA 9 - ESTRUTURA DE UM QUADRO DE DADOS ................................................ 34 
FIGURA 10 - CAMPOS DE ARBITRAGEM E CONTROLE DE MENSAGEM NO FORMATO CAN 
2.0 A........................................................................................................... 35 
FIGURA 11 - CAMPOS DE ARBITRAGEM E CONTROLE DE MENSAGEM NO FORMATO CAN 
2.0 B........................................................................................................... 36 
FIGURA 12 - ESTRUTURA DO PACOTE REMOTO ...................................................... 37 
FIGURA 13 - ESTRUTURA DO PACOTE DE ERROS/SOBRECARGA ............................... 37 
FIGURA 14 - EXEMPLO DE ARBITRAGEM ................................................................ 38 
FIGURA 15 - ESTADOS DE ERRO DE NÓS CAN ....................................................... 40 
FIGURA 16 - ESQUEMA DE FILTRAGEM .................................................................. 41 
FIGURA 17 - EXEMPLO DE DICIONÁRIO DE PARÂMETROS ......................................... 42 
FIGURA 18 - TRÊS PARTES DO PROTOCOLO CANOPEN .......................................... 42 
FIGURA 19 - HEARTBEAT DO PROTOCOLO CANOPEN ............................................ 42 
FIGURA 20 - REPRESENTAÇÃO DE UM SISTEMA DE AUTOMAÇÃO RESIDENCIAL .......... 43 
FIGURA 21 – PLACA PISO-CAN200E-D .............................................................. 46 
FIGURA 22 – PLACA PC276 ................................................................................ 47 
FIGURA 23 - PIC18F2455 .................................................................................. 48 
FIGURA 24 - DSPIC33FJ256GP710 ................................................................... 49 
FIGURA 25 - FLUXOGRAMA DA FUNÇÃO SENDUSBCAN ......................................... 51 
FIGURA 26 - FLUXOGRAMA DA FUNÇÃO GETUSBCAN ........................................... 52 
 
 
20 
 
LISTA DE TABELAS 
 
 
TABELA 1 - QUADRO COMPARATIVO DE TECNOLOGIAS SEM-FIO ............................... 26 
TABELA 2 - PINAGEM DOS CONECTORES DB9 SEGUINDO PADRÃO CAN................... 33 
TABELA 3 - TABELA DE PLACAS DE COMUNICAÇÃO CAN ......................................... 45 
TABELA 4 - COMPARATIVO DE FRAMES POR SEGUNDO ........................................... 46 
TABELA 5 - NÍVEIS DE PRIORIDADE DOS EQUIPAMENTOS ......................................... 54 
TABELA 6 - EXEMPLO DE IDENTIFICADORES DE MENSAGEM ..................................... 55 
21 
 
 LISTA DE ABREVIATURAS E SIGLAS 
 
 
 
 
ACK – Acknowledge 
CAN – Controller Area Network 
CEBus – Consumer Electronic Bus 
CSMA/CR - Carrier Sense Multiple Access / Colision Resolution 
DLC – Data Length Code 
DSP – Digital Signal Processor 
EOF – End Of Frame 
FFD - Full-Function Devices 
IDE - Identifier Extension 
IEEE - Institute of Electrical and Electronics Engineers 
ISO - International Organization for Standardization 
MAC - Medium Access Control 
PAN – Personal Area Network 
PCI - Peripheral Component Interconnect 
RFD – Reduced-Function Devices 
RTR – Remote Transmission Request 
SAE – Society of Automotive Engineers 
SOF – Start of Frame 
SRR – Subistitute Remote Request 
USB – Universal Serial Bus 
 
22 
 
SUMÁRIO 
 
1 INTRODUÇÃO 23 
2 PROTOCOLOS UTILIZADOS EM APLICAÇÕES RESIDENCIAIS 24 
2.1 ZIGBEE24 
2.1.1 Camada Física .................................................................................. 25 
2.1.2 Camada MAC ................................................................................... 26 
2.1.3 Aplicações ........................................................................................ 26 
2.2 CEBUS 26 
2.2.1 Comunicação via rede elétrica .......................................................... 27 
2.2.2 Aplicações ........................................................................................ 28 
2.3 CONTROLLER AREA NETWORK (CAN) 29 
2.3.1 Histórico ............................................................................................ 29 
2.3.2 Camada Física .................................................................................. 30 
2.3.3 Camada de Enlace ........................................................................... 34 
2.3.3.1 Mensagens ................................................................................. 34 
 Quadros de Dados ........................................................................... 34 
 Quadros Remotos ............................................................................ 36 
 Quadros de Erros e Sobrecarga ...................................................... 37 
2.3.3.2 Arbitragem .................................................................................. 38 
2.3.3.3 Confinamento de Falhas ............................................................. 39 
2.3.3.4 Filtragem ..................................................................................... 40 
2.3.3.5 CANOpen ................................................................................... 41 
3 AUTOMAÇÃO RESIDENCIAL E REDES CAN 43 
3.1 PROPOSTAS 43 
3.2 ESTRUTURA DA REDE 44 
3.2.1 Hardware .......................................................................................... 44 
3.2.1.1 Comunicação via Placa PCI ....................................................... 44 
3.2.1.2 Comunicação via Controlador USB ............................................ 47 
3.2.1.3 Topologia da Placa ..................................................................... 48 
3.2.2 Software ............................................................................................ 50 
3.2.2.1 Sistema de controle de residências ............................................ 50 
3.2.3 Exemplos de Mensagens .................................................................. 52 
3.2.3.1 Equipamentos de uma residência .............................................. 53 
4 CONCLUSÕES 57 
REFERÊNCIAS BIBLIOGRÁFICAS 58 
ANEXOS 60 
1. FUNÇÕES DELPHI 60 
1.1 FindUSBCANTarget ............................................................................. 60 
1.2 getUSBCAN ......................................................................................... 61 
1.3 sendUSBCAN ...................................................................................... 63 
 
23 
 
1 INTRODUÇÃO 
 
 
 A automação, ou domótica, é o termo utilizado para descrever o conjunto 
de tecnologias voltado para a otimização de lares, escritórios e indústrias 
visando um aumento no conforto, melhorias na comunicação e segurança e 
uma diminuição no consumo de energia. 
 As residências estão se tornando ambientes cada vez mais 
automatizados, conseqüentemente, a necessidade de sistemas mais seguros 
e confiáveis aumentou. Com essa necessidade desenvolveram-se sistemas 
descentralizados de controle, ou seja, diversos dispositivos presentes na 
residência desempenham funções de verificação e checagem, como por 
exemplo, sensores, atuadores e controles remotos. 
 Com o crescimento destes sistemas e suas diferenças fez-se necessário 
a padronização de protocolos de comunicação. Na década de 80, década de 
início da popularização dos sistemas automatizados, surgiram diversos 
protocolos e com eles diversos grupos de pesquisa e desenvolvimento. 
 Destes protocolos criados, o protocolo CAN foi desenvolvido para a 
comunicação de dados entre equipamentos eletrônicos. Este padrão surgiu da 
indústria automobilística, mas logo se popularizou e atualmente é um dos 
protocolos mais utilizados em indústrias e escritórios onde uma rede de 
comunicação simples e de baixo custo é necessária para interligar diversos 
dispositivos. 
 Este trabalho tem por objetivo principal utilizar o protocolo CAN para 
interligar componentes de controle, visando automatizar uma residência e 
através de um software desenvolvido para computadores pessoais ter acesso a 
todos os dispositivos presentes na rede. 
24 
 
2 PROTOCOLOS UTILIZADOS EM APLICAÇÕES RESIDENCIAIS 
Para este projeto foram pesquisados alguns protocolos utilizados em 
automação residencial a fim de comparar suas características principais. 
Dentre os protocolos mais utilizados atualmente se destacam o protocolo 
ZigBee (comunicação sem fios), o protocolo CEBus (utilizando a rede elétrica), 
e também o protocolo CAN, muito utilizado em automação automobilística, mas 
com ótimas aplicações residenciais. 
A seguir é apresentado um breve resumo sobre cada protocolo bem 
como suas principais características. 
 
2.1 ZIGBEE 
 
ZigBee é uma tecnologia wireless utilizada para comunicação de baixo 
custo e baixo consumo de potência. Baseada no padrão IEEE 802.15.4, o 
protocolo ZigBee é voltado para a transmissão de dados em radio freqüência 
com baixa taxa de transmissão de bits. As freqüências de operação são as não 
licenciadas nas faixas de 868.0 a 868.6 MHz, 902 a 928 MHz e 2.400 a 2.484 
GHz. 
 O protocolo ZigBee só é definido para suas camadas mais baixas (Camada 
de Rede, de Enlace e Física), as camadas mais altas são desenvolvidas 
dependendo da aplicação. 
 A topologia da rede é baseada em nós, e podem ser configuradas tanto 
como peer-to-peer, como em estrela. Por definição, existem dois tipos de nós: 
os FFD (Full-Function Devices), ou dispositivos de funcionamento completo, e 
os RFD (Reduced-Function Devices), ou dispositivos de funcionamento 
reduzido. 
 Os FFD são responsáveis por controlar o envio de mensagens para qualquer 
dispositivo presente na rede. Eles podem ser configurados como os 
coordenadores da rede PAN (Persona-Area Network). 
 Já os RFD são nós extremamente simples que podem apenas se comunicar 
com os nós FFD, por isso seu consumo de energia é extremamente pequeno. 
25 
 
 As redes ZigBee por definição devem possuir pelo menos um dispositivo 
FFD como mostra a figura a seguir. 
 
 
Figura 1 - Topologias permitidas pelo padrão ZigBee 
 
2.1.1 Camada Física 
 
 Por adotar o padrão IEEE 802.15.4, o protocolo ZigBee incorporou a 
estrutura de camada física deste padrão, sendo que por definição, a camada 
física (PHY - Physical Layer) é responsável por gerenciar as funções de 
seleção de canal e de energia de sinal. 
 Como citado anteriormente, o enlace utilizando protocolo ZigBee pode 
operar numa destas três faixas de freqüências: 
 868.0-868.6 MHz, com taxa de transmissão de até 20kbps em apenas 
um canal; 
 902-928 MHz, com taxa de transmissão de até 40 kbps em 10 canais; 
 2400-2483.5 MHz, com taxa de transmissão de até 250 kbps em 16 
canais. 
 A transmissão do sinal utiliza técnicas de espalhamento espectral para 
melhorar a eficiência do sinal e diminuir as interferências. 
 
 
 
26 
 
2.1.2 Camada MAC 
 
 A camada MAC (Medium Access Control) é responsável pelo controle e 
transmissão dos pacotes. Esta camada é utilizada também para validação dos 
pacotes e configuração e associação dos nós presentes na rede. 
 Nesta camada o pacote é dividido em timeslots e enviado para a 
camada física parasua transmissão. 
 
2.1.3 Aplicações 
 
 O protocolo ZigBee foi desenvolvido para atender a demanda por um 
controle melhor e uma melhor segurança nas redes domésticas sem fios e 
também foi criado para ser de baixo custo e possuir baixo consumo de energia. 
 ZigBee é voltado para aplicações de baixa complexidade e de curto 
alcance (em média 100m), podendo substituir soluções de maior custo como, 
por exemplo, Bluetooth e WiFi. 
Padrão 
ZigBee® 
802.15.4 
Wi-Fi™ 
802.11b 
Bluetooth™ 
802.15.1 
Alcance (metros) 1 – 100* 1 - 100 1 – 10 
Vida útil da bateria (dias) 100 – 1,000 0.5 – 5.0 1 - 7 
Tamanho da rede (nós) > 64,000 32 7 
Taxa de transmissão (kbps) 20 – 250 11,000 720 
Tabela 1 - Quadro comparativo de tecnologias sem-fio 
 
2.2 CEBus 
 
 CEBus (Consumer Elctronics Bus) é um protocolo de código aberto, 
totalmente baseado no modelo de camadas OSI, desenvolvido pela Associação 
das Industrias de Eletrônicos dos Estados Unidos (EIA - Electronic Industries 
Association) primeiramente para padronizar os sinais de infra-vermelho emitido 
pelos controles remotos dos aparelhos eletrônicos tentando evitar 
27 
 
interferências e incompatibilidades. Atualmente o padrão CEBus se extende 
dos circuitos RF até as comunicações utilizando a rede elétrica. 
 Por ser de código aberto o protocolo CEBus permite que a rede opere 
ponto-a-ponto sem a necessidade de um nó controlador. E outra grande 
característica do protocolo aberto é a capacidade de comunicação em diversos 
meios de transmissão, como ilustrado a seguir. 
 
 
Figura 2 - Exemplo de topologia de rede CEBus 
 
2.2.1 Comunicação via rede elétrica 
 
 A comunicação via rede elétrica utilizando o padrão CEBus é realizada 
através de modulação por espalhamento espectral, modulando a partir da 
freqüência de 100 MHZ incrementando linearmente até 400MHz em um 
intervalo de 100 milissegundos. Por definição do protocolo, o bit 1 corresponde 
a um pulso de 100 milissegundos e o bit 0 corresponde a um pulso de 200 
milissegundos. 
 Devido ao fato de possuir pulsos assimétricos a taxa de transmissão de 
bits varia dependendo da quantidade de bits transmitidos. Para evitar colisões, 
é utilizado um método de "escuta" de barramento, neste caso usa-se o padrão 
CSMA-CDR (Carrier Sense Multiple Access - Colision Detection and 
Resolution), forcando ao dispositivo que quer transmitir verificar se o 
barramento está livre antes de começar a comunicação. 
28 
 
 O protocolo CEBus define que o endereço de destino e o endereço de 
origem estejam em cada pacote enviado, assim como no protocolo TCP/IP. Os 
endereços de cada componente são definidos pela empresa fabricante 
seguindo as recomendações do EIA e possuem 32 bits. Sendo assim o pacote 
mínimo transmitido pela rede possui 64bits. 
 
 
2.2.2 Aplicações 
 
 Assim como o padrão ZigBee, as aplicações utilizando a tecnologia 
CEBus são voltadas para a automação, seja ela residencial ou industrial. 
 Empresas como Microsoft, IBM, Compaq, AT&T, Panasonic e Sony vem 
desenvolvendo equipamentos capazes de se comunicar utilizando o protocolo 
CEBus. Em 2006, em uma feira de eletrônica em Las Vegas, EUA, foi 
apresentado um aparelho de televisão com um roteador CEBus interno. 
Através deste roteador é possível acender as luzes apenas utilizando o 
controle remoto do televisor. 
 
Figura 3 - Exemplo de aplicação CEBus 
 
29 
 
2.3 CONTROLLER AREA NETWORK (CAN) 
 
 Para a aplicação proposta neste projeto o protocolo utilizado foi o 
protocolo CAN. Dentre os protocolos analisados este se mostrou o mais flexível 
em relação à aplicação e com uma ótima detecção de erros. 
 A seguir é apresentado um histórico sobre este protocolo e em seguida é 
feita uma explicação teórica da estrutura de rede deste padrão. 
 
2.3.1 Histórico 
 
O formato de rede e o protocolo CAN foram desenvolvidos em 1983 por 
Robert Bosch Gmb para melhorar a comunicação entre os diversos 
componentes presentes em um veículo. 
Com o aumento do número de dispositivos de controle e sensores nos 
veículos a espessura dos chicotes (grupo de cabos de conexão) cresceu o que 
tornava a manutenção e detecção de falhas muito complexas. 
Por este motivo, em 1986, a empresa Bosch apresentou a solução CAN 
para a Sociedade de Engenheiros Automotivos (Society of Automotive 
Engineers - SAE), e esta foi amplamente aceita e se tornando um dos padrões 
mais utilizados em automóveis atualmente. 
A regulamentação geral da rede CAN está presente na resolução ISO 
11898 da International Organization for Standardization e sua regulamentação 
específica para as diversas aplicações em automóveis foi padronizada pela 
SAE. 
A rede CAN possui diversas vantagens, o que acabou espalhando sua 
utilização para as áreas industriais, como por exemplo, a indústria 
aeroespacial, marítima, militar e também em aplicações rurais. 
Dentre as principais características da rede CAN podem-se citar: 
 
 Faixa de Operação de até 1Mbps para curtas distâncias; 
 Possui uma excelente detecção de erros; 
30 
 
 Usa mensagens curtas de até 8 bytes por mensagem; 
 Configuração altamente flexível; 
 Controle da rede por prioridades nas mensagens. 
 
Atualmente existem dois padrões de protocolo CAN. O CAN versão 2.0 
A, com identificador de mensagens de 11bits e a versão 2.0B com identificador 
de 29bits. 
O modelo do protocolo CAN segue o padrão de camadas OSI/ISO. Um 
das vantagens da rede CAN é que tanto a camada de enlace como a camada 
física são implementadas diretamente no microchip de controle, deixando 
apenas a camada de aplicação a ser desenvolvida. 
 
 
Figura 4 - Camadas ISO e CAN 
 
 
2.3.2 Camada Física 
 
O barramento CAN é formado por um par de fios trançados com 
impedância característica de 150 ohms. O Sinal é transmitido neste barramento 
de forma diferencial, ou seja, a diferença de tensão entre os terminais do 
31 
 
barramento é que carrega a informação, os fios deste barramento são 
denominados CAN_H (High) e CAN_L (Low). 
O conceito envolvido na transmissão de mensagens CAN é baseado na 
técnica CSMA/CR (do inglês, Carrier Sense Multiple Access/ Colission 
Resolution) onde, em caso de colisão a mensagem que apresentar o primeiro 
bit dominante, ou seja, o bit que causar uma diferença de tensão entre CAN_H 
e CAN_L, levará vantagem e continuará a ser enviado sem destruição ou 
interferência. Este processo será visto mais profundamente no tópico sobre 
mensagens CAN. 
 
Figura 5 - Topologia de barramento CAN 
 
Por convenção, o bit 1 é considerado o bit recessivo e o bit 0 o bit 
dominante. Para gerar um bit dominante é necessário que a tensão em CAN_H 
seja cerca de 3,5V e a tensão em CAN_L seja de 1,5V (padrão ISO 11898), 
como mostra a figura a seguir: 
32 
 
 
Figura 6 - Nível de barramento, segundo ISO 11898 
 
 A rede CAN apresenta a capacidade de monitoramento de bits para 
verificação de utilização do barramento e devido a este fato a capacidade de 
transmissão de bits diminui com a distância dos nós presentes na rede. 
 
Figura 7 - Gráfico de Taxa de Transmissão de bits pela distância dos nós 
 
33 
 
A conexão dos nós ao barramento CAN geralmente é realizada através 
de conectores DB 9, a configuração dos pinos do conector está apresentada na 
tabela abaixo: 
Pinos Nome do Sinal Descrição 
1 Reservado A ser definido 
2 CAN_L Dominante nível baixo 
3 CAN_GND Terra 
4 Reservado A ser definido 
5 CAN_SHLD Blindagem (Opcional) 
6 GND Terra 
7 CAN_H Dominante nível alto 
8Reservado A ser definido 
9 CAN_V+ Fonte 
Tabela 2 - Pinagem dos conectores DB9 seguindo padrão CAN 
 
Figura 8 - Modelos de conectores DB 9 
 
34 
 
2.3.3 Camada de Enlace 
 
2.3.3.1 Mensagens 
 
 As mensagens transmitidas pela rede CAN, conforme apresentado 
anteriormente, possuem duas versões bastante utilizadas pela indústria 
atualmente. A versão 2.0 A onde o campo destinado para o identificador da 
mensagem possui 11 bits, e a versão 2.0 B onde o campo de identificação de 
mensagem possui 29 bits. 
 Uma mensagem CAN pode ser encapsulada em quatro tipos básico de 
datagramas, são eles: 
 
 Data Frames, ou quadros de dados; 
 Remote Frames, ou quadros remotos; 
 Erro Frames, ou, quadros de erros; 
 Overload frames, ou, quadros de sobrecargas. 
 
 Cada um destes quadros possui uma função diferente na rede CAN. A 
seguir é apresentado um resumo de cada quadro e suas características: 
 
 Quadros de Dados 
 
A seguir é apresentada a estrutura de um quadro de dados: 
 
 
Figura 9 - Estrutura de um quadro de dados 
 
35 
 
 O campo de início de quadro (Start of Frame – SOF) é composto por 
apenas um bit dominante, este bit é responsável por informar o barramento que 
uma mensagem irá começar a ser transmitida. 
 O campo de arbitragem (Arbitration Field) na versão 2.0 A possui um 
campo de 11 bits chamado de Identificador da mensagem, e um campo de 
requisição de retransmissão de dados (RTR – Remote Transmission Request). 
O campo Identificador de Mensagens é responsável por informar ao 
barramento a prioridade da mensagem. E o campo RTR é composto por 
apenas um bit, se este bit for dominante, é responsável por informar aos 
componentes que um quadro remoto deve ser enviado após o recebimento 
desta mensagem. 
 
Figura 10 - Campos de arbitragem e controle de mensagem no formato CAN 2.0 A 
 
 Na versão 2.0 B, o campo de arbitragem é um pouco maior, possuindo 
29 bits no campo de identificação dividido em um campo de 11 bits, e um de 18 
bits. Os campos que dividem o campo de identificação são um campo RTR 
recessivo denominado de SRR (Subistitute Remote Request), e o campo IDE 
(Identifier Extension), presente também no campo de controle, este bit, se 
recessivo, informa se o próximo campo é a extensão do identificador ou apenas 
o campo de controle. 
 
36 
 
 
Figura 11 - Campos de arbitragem e controle de mensagem no formato CAN 2.0 B 
 
 O campo de controle é composto por um (versão 2.0 A) ou dois (versão 
2.0 B) bits reservados e um campo de 4 bits informando o comprimento da 
mensagem (DLC – Data Lenght Code). 
 Em seguida, é apresentada a mensagem propriamente dita. O campo da 
mensagem pode ser composto de 0 a 8 bytes. 
 Após o campo da mensagem é transmitido um campo de verificação de 
redundância cíclica, ou checksum, de 2 bytes. Este campo é usado para 
verificar a integridade da mensagem. Se o CRC enviado não for idêntico ao 
calculado, a aplicação definirá o que deve ser feito. 
 Em seguida, o campo de confirmação de recebimento (ACK) é 
dominante somente se a mensagem enviada foi recebida corretamente pelo 
receptor. 
 E finalmente o campo de fim de transmissão (EOF – End Of Frame) é 
enviado. Este campo de 7 bits informa o fim do pacote e caso tenha 
apresentado algum erro seta bits para informar estes erros. 
 O campo de entre quadros (Interframe Space) é compostos por 3 bits 
recessivos e é somente um espaço definido entre dois pacote de mensagem. O 
IFS só é enviado após pacotes de dados e pacotes remotos. 
 
 Quadros Remotos 
 
 A estrutura dos pacotes remotos é semelhante a dos pacotes de dados e 
é apresentada a seguir: 
 
37 
 
 
Figura 12 - Estrutura do pacote remoto 
 
 Como mostra a figura acima, o pacote remoto é composto pelos 
mesmos campos do pacote de dados exceto que o pacote remoto não 
apresenta mensagens. 
 O quadro remoto é usado, por exemplo, para solicitar dados de um 
componente da rede. Ou somente para informar o recebimento de uma 
mensagem. 
 
 Quadros de Erros e Sobrecarga 
 
O pacote de erros é enviado por qualquer nó da rede que detecte um 
erro. 
 
Figura 13 - Estrutura do pacote de erros/sobrecarga 
 
 Os seis primeiros bits do pacote são flags definidas pela aplicação. O 
Delimitador do quadro é composto por 8 bits recessivos. 
 O pacote de sobrecarga apresenta a mesma estrutura do pacote de erro 
e é utilizado quando se necessita um atraso maior na transmissão de pacotes. 
 
38 
 
 
2.3.3.2 Arbitragem 
 
 
A arbitragem utiliza o processo de dominância de bits para garantir que a 
prioridade entre as mensagens venha a ser mantida. A dominância previne que 
a mensagem com maior prioridade seja sobreposta ou destruída por outra 
mensagem de menor prioridade. 
 A rede CAN utiliza o principio de detecção de portadora para verificar se 
a mensagem transmitida corresponde de fato à mensagem que o transmissor 
enviou. E este principio é utilizado também para verificar se o canal está 
liberado para o inicio de transmissão. 
 A seguir é apresentado um exemplo de quatro nós e o canal CAN: 
 
Figura 14 - Exemplo de arbitragem 
 Neste exemplo, os nós A, B e C começam a transmitir a mensagem no 
mesmo instante, o nó D detecta o inicio de transmissão e entra no modo de 
recepção. 
 O identificador das mensagens possui os mesmos últimos dígitos (bits 
6,7,8,9 e 10). Até este ponto nenhum dos nós detectou a superposição do 
canal. 
39 
 
 Quando o bit 5 (recessivo) é enviado o nó B detecta um erro e entra no 
modo de recepção. O que será feito com a mensagem B é definido pela 
aplicação. 
 O nó A só percebe a sobreposição ao enviar o bit 3, neste momento ele 
entra em modo de escuta de canal e o nó C envia o restante da mensagem 
sem perceber que ouve a sobreposição. 
Percebe-se então que a prioridade sobre a rede não é do nó e sim da 
mensagem, e mensagens com o primeiro bit dominante enviado terá 
prioridade. 
 
2.3.3.3 Confinamento de Falhas 
 
 O CAN apresenta o confinamento de falhas que consiste no isolamento 
de nós defeituosos ou no total desligamento do barramento dependendo da 
gravidade do erro detectado na rede. 
Fisicamente consiste em dois contadores presentes nos nós e no 
barramento, um contador é responsável por detectar erros de transmissão e 
outro para detectar erros de recepção. 
Por definição, cada contagem equivale a um ponto. Inicialmente os nós 
se encontram no estado denominado de “error active”. Ao detectar um erro é 
enviado um flag de erro ativo e o contador aumenta a pontuação para este nó. 
Se a próxima mensagem enviada por este nó não apresentar a flag de erro os 
pontos dados anteriormente são descontados. Se um nó apresentar contagem 
maior do que 127 pontos consecutivos o nó entra no estado “error passive”, no 
qual continua enviando mensagens com um tempo entre mensagens um pouco 
maior. 
Se o nó no modo “error passive” continuar a enviar flags de erro passivo, 
e sua pontuação aumentar até 255 pontos ele é desligado do barramento 
entrando no modo “bus off” até ser resetado manualmente ou até que sejam 
detectados 128 pacotes de 11bits recessivos e volte para o estado de “error 
passive”. 
40 
 
 
Figura 15 - Estados de erro de nós CAN 
 
2.3.3.4 Filtragem 
 
Por ser uma rede que não utiliza endereçamento no envio e recebimento 
de mensagens, a identificação de nós é feita através de um processo simples 
de filtragem de mensagens. 
Todas as mensagens são transmitidas em broadcast, ou seja, a 
mensagem transmitida é recebida por todos os nós da rede. Ao receber umamensagem o equipamento faz a filtragem analisando o campo de identificação 
e verifica se deve ou não completar o pedido enviado. 
O exemplo a seguir mostra como a mensagem enviada pelo nó A é 
filtrada por todos os outros nós presentes na rede. Somente o nó D possui o 
filtro capaz de receber as mensagens de A. 
41 
 
 
Figura 16 - Esquema de Filtragem 
 
2.3.3.5 CANOpen 
 
 CANOpen é o nome dado ao padrão de protocolo desenvolvido pelo 
grupo de fabricantes denominado CAN in Automation (CIA). 
 Este protocolo foi desenvolvido para suprir a falta de padronização do 
protocolo CAN nas camadas maiores (baseando-se no modelo OSI). O 
CANOpen foi inicialmente criado para aplicações com máquinas motoras, mas 
atualmente domina grande parte dos sistemas de automação, inclusive o ramo 
residencial. 
 O protocolo CANOpen pode ser resumido em três partes: A aplicação, o 
dicionário de objetos e o protocolo propriamente dito. A aplicação faz apenas a 
tradução dos dados recebidos e enviados para que o usuário interaja. O 
dicionário de objetos contem diversos parâmetros comuns a todos os 
equipamentos. Esses parâmetros contém informações sobre o estado do 
equipamento, estado da rede e ainda possui valores específicos para os 
fabricantes. 
 E por fim o protocolo que é o responsável pela padronização dos dados 
enviados na rede, lembrando que os dados a serem enviados são 
encapsulados no protocolo CANOpen e em seguida no protocolo CAN e são 
transmitidos na rede. 
42 
 
 
Figura 17 - Exemplo de dicionário de parâmetros 
 
Figura 18 - Três partes do protocolo CANOpen 
 
 O controle de erros do protocolo CANOpen é atravez de um método 
chamado Heartbeat (Batida do coração) que é um pacote de mensagem 
enviado ciclicamente para todos os equipamentos do barramento contendo o 
identificador do equipamento e seu estado. O heartbeat também é usado como 
timer de sincronismo de rede. 
 
Figura 19 - Heartbeat do protocolo CANOpen 
43 
 
3 AUTOMAÇÃO RESIDENCIAL E REDES CAN 
 
3.1 Propostas 
 
 O projeto visa teoricamente criar um integrador para automatizar uma 
residência utilizando como meio de comunicação entre seus componentes o 
protocolo CAN. Devido ao baixo custo dos microcontroladores CAN e as ótimas 
características já citadas no capitulo anterior (prioridade de mensagens, 
flexibilidade de configuração, vários nós mestres), a rede CAN é uma rede 
extremamente confiável e de fácil aplicação. 
 
 
 
O sistema de automação consiste em um ou mais nós mestres e nós 
atuadores ou sensores. Neste caso, os nós mestres seriam computadores 
pessoais conectados ao barramento CAN através de conectores RS-232C ou 
através de conectores USB dependendo da configuração dos mesmos. Os nós 
Figura 20 - Representação de um sistema de automação residencial 
44 
 
escravos seriam sensores e atuadores que possuem microcontroladores 
capazes de interpretar mensagens CAN. 
 Para a aplicação de controle do sistema pode se usar qualquer 
linguagem de programação que tenha acesso às portas seriais do computador, 
como por exemplo, C#, Java ou Delphi. Este sistema teórico também pode ser 
estendido para uma aplicação de WebService, onde a casa estaria conectada 
remotamente na internet. 
 
3.2 Estrutura da rede 
 
 A estrutura do sistema é composta de componentes de controle 
(alarmes, sensor de temperatura, dimmers, ares-condicionados, etc.) 
espalhados por diversos pontos da residência e um sistema de controle central 
composto por um computador rodando um software de gerenciamento e 
controle. 
 
3.2.1 Hardware 
 
 Como explicado anteriormente a estrutura física do sistema consiste em 
um (ou mais) computador principal e diversos sensores espalhados pela 
residência conforme necessidade do nível de automação. 
 A interligação do computador com o barramento principal é feita através 
de uma placa de comunicação CAN, ou através de um dispositivo que faça 
esta conexão através de um controlador USB. 
 
3.2.1.1 Comunicação via Placa PCI 
 
 
 Para elaboração deste trabalho foram pesquisadas algumas placas PCI 
capazes de realizarem a comunicação CAN de forma simplificada. As placas 
encontradas são dos seguintes fabricantes: 
 
45 
 
Modelo Fabricante Preço 
Kvaser PCIcanx HS/HS Kvaser US$ 650,00 
PISO-CAN200E-D ICP DAS Não fornecido 
PC276 PLS Não fornecido 
Tabela 3 - Tabela de placas de comunicação CAN 
 
 A placa Kvaser PCIcanx HS é uma placa PCI que se adapta tanto ao 
padrão PCI-X como ao PCI comum. Possui duas saídas D-sub 9 (RS232) 
capazes de trabalhar independentes graças aos dois microcontroladores 
SJA1000 da empresa Philips. 
 Esta placa é compatível com os protocolos CAN 2.0 A e 2.0 B. Possui 
um oscilador de 16MHz para a comunicação com o barramento. E é compatível 
com os sistemas operacionais: Windows Vista, Windows 2000/XP/Server 2003, 
Windows 95/98/ME, Windows NT4.0 e Linux. 
 A placa PISO-CAN200E-D também possui dois canais CAN compatíveis 
com os padrões 2.0 A e 2.0 B. Suporta taxas de transmissão de 10 Kbps a 
1Mbps. Seu controlador CAN é o controlador NXP SJA1000 CAN Controller 
with 16MHz da Philips, assim como o da placa da empresa Kvaser. Seus 
drivers são suportados pelos sistemas operacionais: Windows 2000/XP/Server 
2003, Windows 95/98/ME, Windows NT4.0. 
 A seguir é mostrada uma tabela de desempenho desta placa rodando 
em um computador com sistema operacional Windows XP Service Pack 3, com 
processador Intel Core 2 Duo de 2GHz e com 512 MB de memória: 
 
Baud Rate(bps) 
CAN 2.0 A CAN 2.0 B 
Frame per sec. Frame per sec. 
1000 k 7498 6187 
800 k 5625 5154 
500 k 4091 3465 
250 k 2135 1809 
46 
 
125 k 1096 925 
50 k 439 370 
20 k 175 148 
10 k 88 74 
Tabela 4 - Comparativo de Frames por segundo 
 
 
 
Figura 21 – Placa PISO-CAN200E-D 
 
 A terceira placa, PC276, é uma placa com maior complexidade do que 
as demais, pois permite ser reconfigurada através de uma memória Flash-
EPRON de 1MB. Seu processador é um ST10F276 da empresa 
STMicroelectronics. Assim como as placas citadas acima, está também possui 
duas saídas para barramentos CAN (2.0 A e 2.0 B) com taxa de transferência 
de até 1Mbps. 
 Esta placa possui a capacidade de expandir sua memória em até 2MB 
através de módulos de memória vendidos separadamente. 
 Seus Drivers são compatíveis com os sistemas operacionais Windows 
Vista, Windows XP and Windows 2000. 
47 
 
 
Figura 22 – Placa PC276 
 
3.2.1.2 Comunicação via Controlador USB 
 
 
 Outra maneira de interligar o computador principal ao barramento CAN 
seria através de um dispositivo controlador USB. Este dispositivo consiste em 
uma entrada USB, um ou mais microcontroladores e uma saída CAN, a 
vantagem sobre os demais circuitos apresentados e seu baixo custo e sua fácil 
implementação. 
 Existem vários equipamentos com esta função, mas este projeto irá 
tratar apenas de um componente desenvolvido pela empresa InTRACK - 
Industria e Comercio de Equipamentos Eletrônicos, uma empresa totalmente 
brasileira que produz equipamentos de rastreamento e controle de veículos. 
 A placa desenvolvida por esta empresa tem o intuito de se comunicar 
com veículos que possuem barramento CAN, como por exemplo, veículos das 
montadoras Volvo, Scania, Mercedez Bens e Opel/Chevrolet. Mas por ser 
apenas um componente que encapsula os pacotes CAN em pacotes USB e os 
envia para o computador nada impede que esta placa seja usada em 
automação residencial. 
483.2.1.3 Topologia da Placa 
 
 
 A placa possui um microcontrolador PIC18F2455 responsável por 
montar os pacotes USB e um DSP DSPIC33FJ256GP710 que analisa e 
gerencia os dados enviados do barramento e do microcontrolador. 
 O controlador PIC18F2455 é um voltado para conexão e comunicação 
USB, possui 24KB de memória Flash e 2KB de memória RAM. É responsável 
por 12 milhões de instruções por segundo a 48MHz. 
 Este microcontrolador tem a capacidade de realizar operações do 
padrão RS-232, o mesmo usado em controladores CAN, o que o torna uma 
ótima escolha para o projeto. 
 
 
Figura 23 - PIC18F2455 
 
 O segundo controlador, DSPIC33FJ256GP71, é um processador digital 
de sinais baseado na arquitetura Harvard de 16 bits, com 256 KB de memória 
de programa e 32 KB de memória RAM. Este DSP é capaz de realizar 40 
49 
 
milhões de instruções por segundo e possui duas saídas Tx e Rx para 
comunicação CAN. 
 Este processador possui ainda dois acumuladores com 40 bits cada, 
cinco tipos de interrupção externa e sete níveis de prioridade totalmente 
programáveis. 
 
 
Figura 24 - DSPIC33FJ256GP710 
 
 Resumidamente estes dois microcontroladores operam 
simultaneamente, ao receber um pacote, o controlador PIC18F2455 verificar o 
identificador da mensagem para confirmar se a mensagem está no formato 
50 
 
CAN, em caso afirmativo o pacote é enviado para o DSP que se encarrega de 
processar e enviar a mensagem ao barramento. 
 O caminho inverso ocorre da mesma forma, ao receber um pacote do 
barramento CAN o processador filtra as mensagens CAN, se alguma 
mensagem for destinada ao computador, o DSP envia o pacote para o PIC que 
encapsula a mensagem no pacote USB e envia ao computador. 
 
 
3.2.2 Software 
 
 Conforme visto anteriormente, o protocolo CAN não possui qualquer 
especificação para as camadas de aplicação, o que o torna um padrão 
extremamente flexível em relação à linguagem de programação. 
 Para este projeto foi escolhida a linguagem Object Pascal através do 
ambiente de desenvolvimento Borland Delphi versão sete. A escolha desta 
linguagem levou em conta sua grande biblioteca voltada a objetos e o grande 
número de componentes desenvolvidos para este ambiente de programação. 
 
 
3.2.2.1 Sistema de controle de residências 
 
 
 A principal função do sistema é informar ao usuário o estado de toda a 
residência bem como permitir que o mesmo possa interagir com os diversos 
componentes presentes na rede, como por exemplo, acender luzes ou verificar 
os sensores de presença. 
 Para o projeto foram usados vários componentes comuns de 
desenvolvimento Delphi e um componente especifico, chamado COMport 
(gratuito até a versão 1.3), para realizar a comunicação com a porta serial 
virtual criada pelo microcontrolador. 
 Com este componente é possível ler e escrever na porta serial utilizando 
simplesmente as respectivas funções read() e write() do componente, 
passando como parâmetros o pacote a ser escrito e seu tamanho. 
 Devido a essa facilidade na comunicação a interpretação das 
mensagens se torna dinâmica fazendo com que o programa consiga interpretar 
de três a quatro mensagens por segundo, que para automação residencial é 
um ótimo valor, levando em consideração que para acionar um alarme ou 
51 
 
iniciar a gravação de uma câmera demora-se em média 200 a 500 
milissegundos. 
 O sistema desenvolvido possui três funções principais: a função 
findUSBCANTarget, a função getUSBCAN e a função sendUSBCAN. O código 
destas funções se encontra anexo a este trabalho. 
 A função findUSBCANTarget tem por objetivo localizar um componente 
CAN através de mensagens definidas. Por exemplo, o sistema enviaria um 
Remote Frame com o identificador da mensagem e em seu campo RTR um bit 
dominante para informar que o componente que receber esta mensagem e 
possuir o mesmo identificador deverá enviar outro Remote Frame para o 
barramento. Esta função então é responsável por enviar um remote frame e 
escutar a porta até que outro quadro com a mesma identificação seja recebido, 
se for recebido corretamente o componente está presente no barramento. 
 As funções getUSBCAN e sendUSBCAN são responsáveis por ler e 
escrever respectivamente pacotes CAN no barramento. Estas funções são 
usadas para a interação com toda a rede. Através de procedimentos definidos 
basta utilizarmos as funções descritas acima para interpretar os dados 
recebidos e mostrar na tela o estado dos componentes. 
 A seguir são apresentados os fluxogramas de funcionamento das 
funções getUSBCAN e sendUSBCAN: 
 
Figura 25 - Fluxograma da função sendUSBCAN 
 
52 
 
 
Figura 26 - Fluxograma da função getUSBCAN 
 
 Como em automação residencial os dados enviados por equipamentos 
pode ser maior do que 8 bytes, é necessário que haja uma função que verifique 
o tamanho dos dados e os fracione em pacotes menores. Para isso é 
necessário utilizar alguns bytes da área de dados para indicar qual fração do 
pacote está sendo encaminhado. 
 Esta função seria muito útil no caso de câmeras de vigilância, ou então 
em um sistema distribuído de áudio, onde os pacotes multimídia possuem 
tamanhos de alguns quilobytes. 
 
 
 3.2.3 Exemplos de Mensagens 
 
 Como em uma residência o número de nós presentes na rede é 
pequeno, optou-se por desenvolver uma aplicação simples e que se comunique 
de forma direta utilizando o protocolo CAN 2.0A com 11 bits de identificação. A 
seguir é analisado um exemplo de rede residencial CAN, mostrando como a 
identificação do nó atua como forma de priorização de mensagens. 
 
53 
 
3.2.3.1 Equipamentos de uma residência 
 
 Uma residência comum no Brasil possui pelo menos quatro cômodos, 
sendo estes: uma sala, um quarto, uma cozinha e um banheiro. Para 
exemplificar a utilização dos identificadores a distribuição de eletrodomésticos 
nesta residência se dará da seguinte forma: 
 Na sala existem um aparelho de som, uma televisão, um computador 
pessoal, cinco tomadas de 110V e uma lâmpada. 
 Na cozinha estão presentes a geladeira, um fogão elétrico, um forno 
micro-ondas, cinco tomadas e uma lâmpada. 
 No quarto existem uma televisão, quatro tomadas e uma lâmpada. 
E no banheiro apenas duas tomadas. 
 A residência também possui um sistema de alarme (juntamente com o 
integrador CAN) e controle eletrônico de portas. 
A partir do perfil de cada equipamento é possível dividir os 
equipamentos em grupos de controle. 
 Neste caso optou-se por dividir os eletrodomésticos por cômodos e 
funcionalidade. 
 Deste modo obteve-se a seguinte configuração: 
 
 
 
 
 
 
 
 
 
 
 
54 
 
Cômodo Equipamento Nível de Prioridade 
Sala 
Televisão Médio 
Aparelho de Som Médio 
Computador Pessoal Médio 
Tomadas Baixo 
Lâmpada Alto 
Cozinha 
Geladeira Médio 
Fogão Elétrico Médio 
Forno Microondas Médio 
Tomadas Baixo 
Lâmpada Alto 
Quarto 
Televisão Médio 
Tomadas Baixo 
Lâmpada Alto 
Banheiro 
Tomadas Baixo 
Lâmpada Alto 
 Controle de Portas Alto 
 Sistema de Alarme Alto 
Tabela 5 - Níveis de prioridade dos equipamentos 
 
 
 
55 
 
Seguindo a lógica de arbitragem foram escolhidos os identificadores de 
cada equipamento como mostra a tabela a seguir: 
 Identificador (bits) 
Equipamento b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 Nível 
Alarme 0 0 0 0 0 0 0 0 0 1 0 0 Alto 
Controle de Portas12 0 0 0 0 0 0 0 0 0 1 1 1 
 
Lâmpada Sala 0 0 0 0 0 0 0 1 0 0 0 0 
Lâmpada Cozinha 0 0 0 0 0 0 0 1 1 00 0 
Lâmpada Quarto 0 0 0 0 0 0 0 1 1 1 0 0 
Lâmpada Banheiro 0 0 0 0 0 0 0 1 1 1 1 0 
Computador Pessoal 0 0 0 0 0 1 0 0 0 0 0 0 
Médio 
Televisão da Sala 0 0 0 0 0 1 1 0 0 0 0 0 
Aparelho de Som 0 0 0 0 0 1 1 1 0 0 0 0 
Geladeira 0 0 0 0 0 1 1 1 1 0 0 0 
Fogão elétrico 0 0 0 0 0 1 1 1 1 1 0 0 
Microondas 0 0 0 0 0 1 1 1 1 1 1 0 
Televisão do Quarto 0 0 0 0 0 1 1 1 1 1 1 1 
Tomada 1 da Sala (TS1) 1 0 0 0 0 0 0 0 0 0 0 0 
Baixo 
TS2 1 0 1 0 0 0 0 0 0 0 0 0 
TS3 1 0 1 1 0 0 0 0 0 0 0 0 
TS4 1 0 1 1 1 0 0 0 0 0 0 0 
TS5 1 0 1 1 1 1 0 0 0 0 0 0 
Tomada 1 da Cozinha 
(TC1) 1 0 1 1 1 1 1 0 0 0 0 0 
TC2 1 0 1 1 1 1 1 1 0 0 0 0 
TC3 1 1 0 0 0 0 0 0 0 0 0 0 
TC4 1 1 1 0 0 0 0 0 0 0 0 0 
TC5 1 1 1 1 0 0 0 0 0 0 0 0 
Tomada 1 do Quarto (TQ1) 1 1 1 1 1 0 0 0 0 0 0 0 
TQ2 1 1 1 1 1 1 0 0 0 0 0 0 
TQ3 1 1 1 1 1 1 1 0 0 0 0 0 
TQ4 1 1 1 1 1 1 1 1 0 0 0 0 
TQ5 1 1 1 1 1 1 1 1 1 0 0 0 
Tomada 1 do Banheiro 
(TB1) 1 1 1 1 1 1 1 1 1 1 0 0 
TB2 1 1 1 1 1 1 1 1 1 1 1 0 
Tabela 6 - Exemplo de identificadores de mensagem 
 
12
 Para o controle de portas cada porta possui um identificador passado juntamente com os dados do pacote. 
56 
 
 
 
 Este exemplo serve para mostrar o método de priorização de 
mensagens, e detecção de erros a partir de seu identificador. Seguindo o 
princípio de dominância de bits, as mensagens com baixo nível de prioridade 
possuem um bit recessivo logo no começo do seu identificador, e conforme 
aumenta o nível de prioridade o código binário do identificador diminui. Cada 
equipamento ira filtrar somente as mensagens contendo seu próprio 
identificador, mostrando que a comunicação utilizando o protocolo CAN é uma 
comunicação totalmente segura, pois cada equipamento só opera se seu 
identificador foi reconhecido. 
 O protocolo CAN permite muitas outras configurações, o exemplo 
acima poderia ser refeito de modo que cada nível de prioridade possuísse um 
identificador fixo e cada equipamento possuiria um identificador passado como 
um dado no pacote. 
A escolha do padrão de mensagens é feita de modo singular levando em 
conta as prioridades desejadas, a freqüência de uso de cada equipamento e a 
função deste na rede. 
 
57 
 
4 CONCLUSÕES 
 
 Os sistemas de automação residencial necessitam ser seguros, 
confiáveis e principalmente possuírem um baixo custo de instalação. Assim 
sendo, cada projeto deve realizar a melhor combinação destas características, 
para que haja maior conforto e economia para o usuário. 
 Para a realização deste trabalho foi escolhido uso do protocolo CAN 
para a comunicação de dados entre os diversos componentes do sistema. Esta 
escolha levou em consideração a flexibilidade na camada de aplicação do 
protocolo, a possibilidade da rede CAN ser controlada por diversos nós, e seu 
excelente código de detecção e correção de erros. 
 A rede CAN também se mostrou econômica no quesito cabeamento por 
necessitar apenas de pares de fio trançados, que possuem baixo custo no 
mercado. 
 A implementação do integrador também foi realizada visando às 
características principais de um sistema de automação. Para isto, foi utilizado 
um computador pessoal rodando uma aplicação desenvolvida em linguagem 
Object Pascal. 
 A interface entre o computador e o barramento foi desenvolvida através 
de uma placa desenvolvida pela empresa InTRACK, para utilizar portas de 
comunicação USB do computador. Esta placa utiliza componentes de baixo 
custo comparado com placas desenvolvidas para se comunicarem diretamente 
com a rede CAN. 
 Através deste trabalho foi possível perceber que aplicações residenciais 
de controle podem ser realizadas utilizando-se componentes de baixo custo e 
protocolos flexíveis. Isso aumenta a popularização de casas inteligentes. Mas 
para que esta popularização se dê de forma correta, é necessário investimento 
na criação de componentes simples e seguros e na padronização de estruturas 
de rede de alto desempenho. 
 
58 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
 
VOSS, Winfred, 2002. Comprehensible Guide To Controller Area Network. 
Copperhill Technologies Corporation. 
 
PINHEIRO, José Maurício Santos, 2006. ZigBee em Home Area Network. 
Projeto de Redes. Disponível em: http://www.projetoderedes.com.br. Acesso 
em 25/02/2006. 
 
INTILLE, S., Designing a Home of the Future. Massachusetts Institute of 
Technology. Pervasive Computing. 
 
MESSIAS, A. R. Porta Paralela. Disponível em: 
<http://www.rogercom.com/index.htm>. Acesso em 07/09/2009. 
 
ZigBee® Wireless Standard. Disponível em: <http://www.digi.com/technology/rf-
articles/wireless-zigbee.jsp Acesso em 15/09/2009>. 
 
ZigBee Tutorials. Disponível em: <http://www.tutorial-
reports.com/wireless/zigbee/zigbee-architecture.php> Acesso em 15/09/2009. 
 
CEBus. Disponível em: 
<http://www.hometoys.com/htinews/aug97/articles/kwacks/kwacks.htm> Acesso 
em: 17/09/2009 
 
ICP DAS, Placa PISO-CAN 200-E. Disponível em: 
<http://www.icpdas.com/products/Remote_IO/can_bus/piso-can200e.htm> 
Acesso em: 20/09/2009 
 
PLS, Placa PC276, Disponível em: <http://www.pls-
mc.com/content/view/32/47/> Acesso em: 20/09/2009 
59 
 
 
Kvaser, Placa PCIcanx HS/HS. Disponível em: 
<https://secure.assurebuy.com/98057/98057.htm> Acesso em 25/09/2009 
 
Microchip, Datasheet PIC18F2455. Disponível em: 
<http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId
=1480>. Acesso em: 28/09/2009 
 
Microchip, Datasheet DSPIC33FJ256GP710. Disponível em: 
<http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024679
> Acesso em: 28/09/2009 
 
Leão, Marcelo, 2003. Curso Completo Borland Delphi 7. Axcel Books do 
Brasil. 
 
Aureside. Disponível em: <http://www.aureside.org.br/> Acesso em: 07/09/2009 
 
Saber Eletrônica, Rede CAN: a troca de dados em aparelhos eletrônicos. 
Disponível em: <http://www.sabereletronica.com.br/secoes/leitura/1301> 
Acesso em: 04/10/2009 
 
CAN in Automation. Disponível em: <http://www.can-cia.org> Acesso em: 
09/11/2009 
60 
 
ANEXOS 
 
1. Funções Delphi 
 
1.1 FindUSBCANTarget 
 
procedure TfrmPrincipal.findUSBCANTarget; 
var i,j: Integer; 
 serverResponse, porta: LongWord; 
begin 
 if not Port.Connected then 
 begin 
 Port.Timeouts.ReadInterval := 50; 
 porta:= $FEAD1234; 
 
 txdata[0] := $40; // START 
 txdata[1] := Make8($FEAD1234,3); // MID01 
 txdata[2] := Make8($FEAD1234,2); // MID02 
 txdata[3] := Make8($FEAD1234,1); // MID03 
 txdata[4] := Make8($FEAD1234,0); // MID04 
 txdata[5] := $1; // EXTENDED IDENTIFIER 
 txdata[6] := $0; // RETURN REQUEST 
 txdata[7] := $0; // NUMBER OF DATA BYTES 
 txdata[8] := $0; // DB00 
 txdata[9] := $0; // DB01 
 txdata[10] := $0; // DB02 
 txdata[11] := $0; // DB03 
 txdata[12] := $0; // DB04 
 txdata[13] := $0; // DB05 
 txdata[14] := $0; // DB06 
 txdata[15] := $0; // DB07 
 txdata[16] := CheckSum; // CHECKSUM 
61 
 
 txdata[17] := $0D; // STOP <CR> 
 
 Port.Open; 
 for i:=0 to 17 do 
 Port.Write(txdata[i],1); 
 sleep(60); 
 for i:=0 to 17 do 
 Port.Read(rxdata[i],1); 
 
 serverResponse := Make32(rxdata[8],rxdata[9], rxdata[10], rxdata[11]); 
 
 if (serverResponse = porta) then 
 begin 
 mmCAN.Lines.Add('Dispositivo CAN Encontrado e Conectado.'); 
 mmCAN.Lines.Add(''); 
 SendUSB($FEAD1000, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0); 
 btCal.Enabled := True; 
 btnDesconectar.Enabled := True; 
 btnConectar.Enabled := False; 
 Exit; 
 end; 
 
 Port.ClearBuffer(True,True); 
 end; 
end; 
 
1.2 getUSBCAN 
 
function TfrmPrincipal.getUSBCAN(mensagem: LongWord; EXT, RTR, NB, 
DB0, DB1, DB2, DB3, DB4, DB5, DB6, DB7: Byte):Boolean; 
var i: Integer; 
begin 
62 
 
 try 
 for i:=0 to 17 do 
 rxdata[i] := $0 
 
 Port.Timeouts.ReadInterval := 250; 
 txdata[0] := $40; // START 
 txdata[1] := Make8(mensagem,3); // MID01 
 txdata[2] := Make8(mensagem,2); // MID02 
 txdata[3] := Make8(mensagem,1); // MID03 
 txdata[4] := Make8(mensagem,0); // MID04 
 txdata[5] := EXT; // EXTENDED IDENTIFIER 
 txdata[6] := RTR; // RETURN REQUEST 
 txdata[7] := NB; // NUMBER OF DATA BYTES 
 txdata[8] := DB0; // I2C DB00 
 txdata[9] := DB1; // I2C DB01 
 txdata[10] := DB2; // I2C DB02 
 txdata[11] := DB3; // I2C DB03 
 txdata[12] := DB4; // I2C DB04 
 txdata[13] := DB5; // I2C DB05 
 txdata[14] := DB6; // I2C DB06 
 txdata[15] := DB7; // I2C DB07 
 txdata[16] := CheckSum(); // CHECKSUM 
 txdata[17] := $0D; // STOP <CR> 
 if Port.Connected then 
 begin 
 for i:=0 to 17 do 
 Port.Write(txdata[i],1); 
 sleep(60); 
 for i:=0 to 17 do 
 Port.Read(rxdata[i],1); 
 
 if (rxdata[1] = $0) and (rxdata[2] = $0) and (rxdata[3] = $0) and (rxdata[4] = 
63 
 
$0) then 
 begin 
 Result := False; 
 Port.ClearBuffer(True,True); 
 Exit; 
 end; 
 if ((rxdata[1] = 0) and (rxdata[2] = 0) and (rxdata[3] = 0))then 
 Result:= False; 
 Result:= True; 
 end 
 else 
 begin 
 TimerRun.Enabled := False; 
 btRun.Caption := 'Run'; 
 ShowMessage('Dispositivo Não Conectado!'); 
 Result:= False; 
 end; 
 Port.ClearBuffer(True,True); 
 except 
 on E : Exception do 
 begin 
 Result:= False; 
 Port.ClearBuffer(True,True); 
 Log.AdicionarErroCritico(E, 'Erro ao ler dados USB.'); 
 end; 
 end; 
end; 
 
1.3 sendUSBCAN 
 
procedure TfrmPrincipal.sendUSB(mensagem: LongWord; EXT,RTR, NB, 
DB0, DB1, DB2, DB3, DB4, DB5, DB6, DB7: Byte); 
64 
 
var i:Integer; 
begin 
 Sleep(25); 
 txdata[0] := $40; // START 
 txdata[1] := Make8(mensagem,3); // MID01 
 txdata[2] := Make8(mensagem,2); // MID02 
 txdata[3] := Make8(mensagem,1); // MID03 
 txdata[4] := Make8(mensagem,0); // MID04 
 txdata[5] := EXT; // EXTENDED IDENTIFIER 
 txdata[6] := RTR; // RETURN REQUEST 
 txdata[7] := NB; // NUMBER OF DATA BYTES 
 txdata[8] := DB0; // I2C DB00 
 txdata[9] := DB1; // I2C DB01 
 txdata[10] := DB2; // I2C DB02 
 txdata[11] := DB3; // I2C DB03 
 txdata[12] := DB4; // I2C DB04 
 txdata[13] := DB5; // I2C DB05 
 txdata[14] := DB6; // I2C DB06 
 txdata[15] := DB7; // I2C DB07 
 txdata[16] := CheckSum(); // CHECKSUM 
 txdata[17] := $0D; // STOP <CR> 
 
 if Port.Connected then 
 begin 
 for i:=0 to 17 do 
 Port.Write(txdata[i],1); 
 end 
 else 
 ShowMessage('Dispositivo Não Conectado!'); 
 Port.ClearBuffer(True,True); 
end; 
 
65