PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS

Campus POÇOS DE CALDAS

Curso de Engenharia Elétrica – Ênfase Telecomunicações e Automação

SISTEMA DE DIAGNÓSTICO DE FALHAS AUTOMOTIVO COM

COMUNICAÇÃO BLUETOOTH

Marcus Vinícius de Paiva

Lucas Samuel Leopoldino

POÇOS DE CALDAS

2010
 Marcus Vinícius de Paiva

Lucas Samuel Leopoldino

SISTEMA DE DIAGNÓSTICO DE FALHAS AUTOMOTIVO COM

COMUNICAÇÃO BLUETOOTH

Trabalho apresentado a disciplina de

Orientação de Projeto de Fim de Curso do
programa de Graduação em Engenharia
Elétrica com ênfase em Telecomunicações
e Automação da Pontifícia Universidade
Católica de Minas Gerais – Campus Poços
de Caldas.

Orientador: Prof. Rodrigo Gonçalves

POÇOS DE CALDAS

2010
 Leopoldino, Lucas Samuel; Paiva, Marcus Vinícius
L587s Sistema de Diagnóstico de falhas automotivo com comunicação
Bluetooth. / Lucas
Samuel Leopoldino; Marcus Vinícius de Paiva. Poços de Caldas:
PUC-MG, 2010.
65p. ; il.

Orientador: Rodrigo Gonçalves

Trabalho de Conclusão de Curso – Pontifícia Universidade
Católica de Minas Gerais
Campus Poços de Caldas

1. Tecnologia bluetooth. 2. Sistema de comunicação sem fio. 3.

Microcontroladores.
 Marcus Vinícius de Paiva

Lucas Samuel Leopoldino

Sistema de diagnóstico de falhas automotivo com comunicação Bluetooth

Trabalho apresentado a disciplina de

Orientação de Projeto de Fim de Curso
do programa de Graduação em
Engenharia Elétrica com ênfase em
Telecomunicações e Automação da
Pontifícia Universidade Católica de
Minas Gerais – Campus Poços de
Caldas.

Prof. M.Sc. Rodrigo Gonçalves - Orientador

Prof. M.Sc. Ramiro Romankevicius Costa

Prof. Dr. Udo Fritzke Junior

Poços de Caldas, 09 de junho de 2010.

DEDICATÓRIA
 Marcus Vinícius de Paiva:

“A Deus, por me presentear com uma família que sempre me

apóia, amigos que sempre proporcionam bons momentos e pelo meu caráter e
dignidade, que sempre me fazem ter coragem para seguir em frente”

Lucas Samuel Leopoldino:

“Aos meus familiares por acreditarem em mim, pelo amor e carinho, e aos meus
amigos pelo incentivo e por estarem ao meu lado nos momentos bons e ruins”

AGRADECIMENTOS

Ao nosso orientador, Professor Rodrigo Gonçalves, pela dedicação, prontidão

e paciência ao nos transmitir os conhecimentos necessários.

Ao professor Ramiro, por todo o conhecimento que nos foi passado e o

professor Udo, por toda ajuda durante a realização deste trabalho.

Aos familiares e amigos por todos os momentos, em especial ao nosso

grande amigo Carlos Henrique Marcelino Balan, por dedicar parte de seu tempo em
ajuda ao nosso projeto e também ao amigo Breno Pêgo, pela boa vontade em
ajudar.
 RESUMO

Este trabalho tem por objetivo propor o desenvolvimento de um hardware capaz de

estabelecer uma conexão Bluetooth com um notebook e possibilitar que este,
também munido de um dispositivo Bluetooth, opere como uma ferramenta de
diagnóstico de falhas de um veículo automotivo, apresentando ao usuário os dados
recebidos do módulo central de controle, responsável por recolher e processar todas
as informações de sensoriamento do sistema eletromecânico do veículo. Dentro da
proposta principal estará o desenvolvimento de um sistema microcontrolado que
será conectado ao módulo de desenvolvimento Bluetooth, próprio para
microcontroladores, e realizará a comunicação sem fio com o laptop para o envio
dos dados colhidos dos sensores e atuadores. Sendo assim, o microcontrolador será
responsável por simular a ECU, tratar os dados enviados pelos componentes a ele
conectados e enviá-los através do dispositivo Bluetooth ao notebook. Este protótipo
possibilitará os futuros trabalhos de complementação deste trabalho. Um esquema
de fácil compreensão do sistema descrito será abordado durante o desenvolvimento
deste trabalho. Serão descritos também conceitos básicos sobre todas as
tecnologias envolvidas no projeto, inclusive o barramento CAN e o protocolo
KW2000, ambos ligados aos meios de acesso aos dados do módulo central.

Palavras-Chave: Bluetooth, microcontrolador, barramento CAN, KW2000, módulo

central.
 ABSTRACT

This paper aims to propose the development of hardware capable of establishing a

Bluetooth connection to a notebook and allow this, also equipped with a Bluetooth
device, to operate as a tool for fault diagnosis of an automotive vehicle, showing the
user data received from central control module, responsible for collecting and
processing all information from sensing the electromechanical system of the vehicle.
The main proposal is the development of a microcontroller system that is connected
to Bluetooth development module, suitable for microcontrollers, and perform wireless
communication with the laptop to send data collected from sensors and actuators.
Thus, the microcontroller will be responsible for simulating the ECU, process the data
sent by the components connected to it and send them via Bluetooth device
connected to it to the notebook. This prototype will enable future work to complement
and complete this work. A scheme for easy understanding of the system described
will be addressed during the development of this work. Also be described basics all
the technologies involved in the project, including the CAN bus and protocol
KW2000, both linked to the means of access to data from the central module.

Key-words: Bluetooth, Microcontroller, CAN bus, KW2000, central module.

 LISTA DE FIGURAS

Figura 1: Bluetooth SIG .............................................................................................18

Figura 2: Bluetooth Logo............................................................................................18
Figura 3: Frequency Hopping/Time Division Duplex
(FH/TDD)..................................21
Figura 4: Topologia de redes Bluetooth......................................................................22
Figura 5: Topologia.....................................................................................................25
Figura 6: Estrutura da mensagem...............................................................................26
Figura 7: Cabeçalho sem informação de endereço, sem o Additional Length
byte.............................................................................................................29
Figura 8: Cabeçalho sem informação de endereço, com o Additional Length
byte.............................................................................................................29
Figura 9: Cabeçalho com informação de endereço, sem o Additional Length
byte.............................................................................................................29
Figura 10: Cabeçalho com informação de endereço, com o Additional Length
byte............................................................................................................30
Figura 11: Exemplo de arbitragem no barramento.....................................................33
Figura 12: Relação entre comprimento da rede e taxa de transmissão.....................34
Figura 13: Bits dominantes e recessivos no CAN Bus...............................................35
Figura 14: Diagrama de Blocos de um módulo Bluetooth..........................................37
Figura 15: Diagrama de comunicação serial..............................................................39
Figura 16: Esquema do sistema proposto..................................................................41
Figura 17: Esquema do sistema proposto..................................................................42
Figura 18: Diagrama esquemático do circuito de testes da comunicação serial......43
Figura 19: Diagrama esquemático do circuito de testes pelo Hyperterminal.............44
Figura 20: Informações visualizadas pelo Hyperterminal...........................................45
Figura 21: Módulo Bluetooth GP-
GC021....................................................................46
Figura 22: Pinagem do Módulo GP-
GC021................................................................47
Figura 23: Conexão a um microcontrolador alimentado com 3.3V.............................48
Figura 24: Conexão a um microcontrolador alimentado com 5V................................49
Figura 25: Placa confeccionada para o módulo Bluetooth..........................................51
Figura 26: Fluxograma da transmissão de dados......................................................52
Figura 27: Diagrama completo do circuito proposto...................................................53
Figura 28: Primeira parte do circuito montado...........................................................54
Figura 29: Microcontrolador e módulo Bluetooth........................................................54
Figura 30: Alimentação do Circuito.............................................................................55
Figura 31: Circuito em funcionamento – Led ligado...................................................55
Figura 32: Vista de todos os componentes montados no circuito..............................56
Figura 33: Hyperterminal – Menu...............................................................................57
Figura 34: Hyperterminal – Código de acesso...........................................................57
Figura 35: Hyperterminal – Acesso permitido............................................................58
Figura 36: Hyperterminal – Informações mostradas na tela do computador............58
 LISTA DE TABELAS

Tabela 1: Classes de potência e alcance do Bluetooth.............................................19

Tabela 2: Forma do cabeçalho da mensagem...........................................................27
Tabela 3: Presença do comprimento de byte.............................................................28
Tabela 4: Lista de Parâmetros controlados pela ECU...............................................40
Tabela 5: Características do Módulo GP-GC021.......................................................46
Tabela 6: Descrição dos pinos do módulo Bluetooth.................................................47
 LISTA DE ABREVIATURAS E SIGLAS

ACL Tgt
CAN UART
CSMA/CD USART
CS USB
CTS Asynchronous Connection-Less
ECU Controller Area Network
FH-CDMA Carrier Sense Multiple Access/Collision Detection
FHS Checksum
FH/TDD Clear to send
Fmt Electronic Control Unit
FTP Frequency Hopping – Code Division Multiple Access
GCF Frequency Hopping Synchronization
HTTP Frequency Hopping/Time Division Duplex
IEEE Format
I²C File Transfer Protocol
ISM Generic Connection Framework
ISO Hypertext Transfer Protocol
KW2000 Institute of Electrical and Electronics Engineers
Len Inter-Integrated Circuit
L2CAP Industrial, Scientific, Medical
Mbps International Standardization Organization
MCU Keyword 2000
NDA Length
NRZ Logical Link Control and Adaptation Protocol
OBD Mega bits por segundo
RS232 Microcontrolador
RTS Non-Destructive Arbitration
SAE Non Return to Zero
SId On-Board Diagnosis
SIG Recommended Standard 232
SCO Request to send
Src Society of Automotive Enginneers
TCP / IP Service Identification
Special Interest Transport Control Protocol / Internet Protocol
Group Target
Synchronous Universal Asyncronous Receiver Transmiter
Connection-Oriented Universal Syncronous Asyncronous Receiver Transmiter
Source Universal Serial Bus
 SUMÁRIO

Figura 33: Hyperterminal –

Menu...............................................................................57.......................................11

1 INTRODUÇÃO.........................................................................................................13

1.1 Justificativa......................................................................................................15

1.2 Objetivos...........................................................................................................15

1.2.1 Objetivo Geral............................................................................................16

1.2.2 Objetivos Específicos...............................................................................16

2.1.1 Freqüência de operação e comunicação................................................20

2.1.3 Versões do Bluetooth..............................................................................25

2.2 O Protocolo KW2000......................................................................................26

2.2.2.1 Cabeçalho............................................................................................28

2.2.2.2 Format byte (Fmt)................................................................................28

2.2.2.3 Target address byte (Tgt)...................................................................30

2.2.2.4 Source address byte (Src)..................................................................30

2.2.2.5 Additional Length byte (Len).............................................................30

2.2.2.6 Formatos de mensagens....................................................................31

2.2.3 Byte de dados............................................................................................32

2.2.3.1 Byte de verificação (Checksum)........................................................33

2.2.4 Diagnóstico em KW2000...........................................................................33

2.3 Barramento CAN ...........................................................................................34

2.3.1 Conceituação básica ................................................................................34

2.4.1 Módulo USART..........................................................................................39

2.5 Módulo Bluetooth...........................................................................................40

2.6 Comunicação Serial e o Padrão RS232........................................................40

2.6.1 Comunicação de dados............................................................................40

 2.6.2 Comunicação Serial..................................................................................41

3 METODOLOGIA.....................................................................................................42

3.1 Simulações do sistema utilizando um microcontrolador PIC 16F877A........44

3.2 Conexão entre o microcontrolador e o módulo Bluetooth............................48

4 DESENVOLVIMENTO...........................................................................................52

.....................................................................................................................................57

Figura 28: Primeira parte do circuito montado......................................................57

.....................................................................................................................................57

Figura 29: Microcontrolador e módulo Bluetooth.................................................57

.....................................................................................................................................58

Figura 30: Alimentação do Circuito.........................................................................58

.....................................................................................................................................58

Figura 31: Circuito em funcionamento – Led ligado.............................................58

.....................................................................................................................................59

.....................................................................................................................................60

Figura 33: Hyperterminal - Menu.............................................................................60

Figura 34: Hyperterminal – Código de acesso.......................................................60

.....................................................................................................................................61

Figura 35: Hyperterminal – Acesso permitido.......................................................61

.....................................................................................................................................61

Figura 36: Informações mostradas na tela do computador.................................61

5 RESULTADOS.......................................................................................................62

6 TRABALHOS FUTUROS......................................................................................63

REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................64
 13

1 INTRODUÇÃO

Seguindo o avanço tecnológico, o desenvolvimento de novos e diferenciados

produtos é fundamental, levando-se em conta as facilidades e o conforto que estes
podem proporcionar. Com o surgimento da tecnologia Bluetooth, houve uma
revolução no mercado de comunicação sem fio. Por ser uma tecnologia de baixo
custo, hoje, uma grande diversidade de equipamentos já contam com sua
funcionalidade.
Outra revolução, agora no ramo automobilístico, foi o surgimento da Electronic
Control Unit (ECU), que há alguns anos foi introduzida nos veículos automotivos
para recolher dos sensores e atuadores, os dados de monitoramento de todo o
sistema e transmiti-los aos scanners (ou testers) de diagnóstico externo, aparelho
responsável por apresentar ao seu operador todas as falhas identificadas pela ECU.
Tais informações de sensoriamento são cruciais para o bom funcionamento dos
sistemas mecânico e elétrico dos veículos automotores, pois a partir delas serão
possíveis as correções necessárias.

O diagnóstico em veículos representa as funções ou ferramentas que permitem

a verificação do funcionamento de cada módulo eletrônico. Com o crescimento da
eletrônica embarcada, foi necessário o desenvolvimento de tais dispositivos
(scanners) que permitiram então, o diagnóstico de falhas dos sistemas. (Guimarães,
2007).

O veículo é monitorado pelos sensores, que convertem uma grandeza não

elétrica em um sinal equivalente de tensão e corrente. Este sinal é enviado ao
módulo eletrônico do veículo, que é responsável por identificá-lo, processá-lo e
então, ter todo o controle sobre o sistema eletrônico. No caso dos sensores do
veículo é usualmente uma tensão que representa um código no processador do
módulo de controle. Se estes valores estiverem fora do padrão especificado pela
montadora, a ECU verificará como uma entrada inválida, ou seja, registrará uma
falha. Um exemplo de monitoramento e controle ocorre no sensoriamento da rotação
do motor. O sensor de rotação envia constantes informações a ECU. Se esta
processar os dados recebidos e verificar um estado incomum, como rotação abaixo
do padrão, um sinal é enviado ao sistema de injeção que auto-acelera o motor e o
 14

coloca na rotação correta. Este é um exemplo de autocalibração do sistema

eletromecânico do veículo, porém algumas falhas só poderão ser corrigidas
manualmente, como é o caso de falhas em atuações de relés, situação em que os
mesmos devem ser substituídos ou regulados.

As falhas diagnosticadas podem ser classificadas de dois modos: as

possíveis de serem identificadas pelo motorista e as identificadas somente por
ferramentas especiais. O On-Board Diagnosis (OBD) é uma ferramenta que mede os
parâmetros de desempenho e comportamento do veículo e, pode ser definida como
a leitura das falhas dos sistemas do veículo realizada por meio de avisos sonoros e
visuais, existentes no painel de instrumentos. A segunda ferramenta é chamada de
Off-Board Diagnosis e é realizada pelos Testers.

Atualmente as ferramentas de diagnóstico são dispositivos que recolhem os

dados da ECU por meio de um cabo de comunicação serial, e as ECU's utilizam,
geralmente, dois princípios para a comunicação com os equipamentos externos, o
barramento Controller Area Network (CAN) e o protocolo de comunicação Keyword
2000 (KW2000).

Visando integrar as tecnologias de comunicação Bluetooth e o dispositivo de

controle ECU foi proposto o desenvolvimento de um dispositivo que, utilizando a
tecnologia Bluetooh, pudesse realizar a comunicação entre ECU e a ferramenta de
diagnóstico, que neste caso também possua a tecnologia Bluetooth dispensando
assim, os incômodos cabos. Vale salientar que qualquer dispositivo capaz de se
comunicar com a ECU e apresentar ao seu usuário as informações contidas nela, é
considerado uma ferramenta de diagnóstico, scanner ou tester. O grande diferencial
neste caso é que, uma vez presente em vários dispositivos portáteis já existentes,
como celulares, notebook’s e palm’s, por exemplo, qualquer um desses pode se
tornar uma ferramenta de diagnóstico, bastando apenas ter instalado no aparelho,
um software específico para o tratamento dos dados, com um ambiente gráfico para
a visualização dos mesmos.

Para a proposta do projeto foi escolhido um notebook por possuir um alto poder
de processamento o que possibilitará a realização de múltiplos diagnósticos
simultaneamente devido à capacidade de o Bluetooth permitir a criação de uma
pequena rede de até sete dispositivos. Tal assunto será abordado mais adiante na
 15

revisão de literatura sobre a tecnologia Bluetooth.

O presente trabalho será desenvolvido a partir da revisão de literatura a

respeito do tema e da elaboração de uma proposta para o dispositivo em questão.
Será realizada uma abordagem sobre o protocolo KW2000, seu princípio de
funcionamento, regras de comunicação e outras particularidades; o barramento CAN
e sua topologia, meios de acesso e transmissão; o Bluetooth e suas características,
velocidade de transmissão e operação em rede.

1.1 Justificativa

A principal motivação para o desenvolvimento deste trabalho é apoiar as

pesquisas em comunicação sem fio, particularmente neste caso, o Bluetooth, pois é
uma tecnologia de baixo custo que está em grande evidência no mercado
tecnológico e já se faz presente em diversos dispositivos, proporcionando uma
grande diminuição do uso de cabos que muitas vezes se torna incômodo ao usuário
de qualquer aparelho ou sistema. Sendo assim, a comunicação sem fio em questão,
cada vez mais robusta e segura, se tornou um meio muito viável para a
comunicação de dados em geral.
Outro ponto interessante do uso da tecnologia Bluetooth é a sua capacidade
de operar em pequenas redes de até oito dispositivos, o que possibilita diversas
aplicabilidades sobre esta característica.
Além disso, vale lembrar que os testers, que são as atuais ferramentas de
diagnóstico, são dispositivos muito caros e cabe dentro da proposta de
desenvolvimento, criar um dispositivo que seja mais barato sem perder em
qualidade e segurança.

1.2 Objetivos
 16

1.2.1 Objetivo Geral

Analisar as informações contidas na ECU de automóveis com padrão de

comunicação KW2000 através de um protótipo de uma ferramenta de diagnóstico
com transmissão sem fio.

1.2.2 Objetivos Específicos

• Desenvolver uma revisão de literatura a respeito da transmissão com

tecnologia Bluetooth e o dispositivo de controle de automóveis ECU.

• Compreender o funcionamento da ECU.

• Compreender as regras requisição e acesso aos dados, de acordo com o

protocolo KW2000 e o barramento CAN.

• Compreender o modo de operação do Bluetooth.

• Desenvolver a proposta de um hardware para a interface sem fio entre a ECU

e o dispositivo móvel;

• Comprovar a eficácia da comunicação Bluetooth entre um microcontrolador e

o notebook;

• Executar os testes de visualização das informações por meio do

hyperterminal do sistema operacional do notebook.
 17

2 REVISÂO DE LITERATURA

2.1 A tecnologia Bluetooth

O Bluetooth é um sistema de transmissão de dados sem fio, que possibilita

uma comunicação simples e rápida entre computadores, smartphones, celulares e
outros dispositivos e periféricos, utilizando ondas de rádio. Além disso, mostrou ser
uma tecnologia segura e de baixo custo. Assim, é possível fazer com que dois ou
mais dispositivos, que estejam dentro de suas áreas de alcance, troquem
informações.

A história desta tecnologia teve início em 1994, quando a Ericsson, grande

empresa do ramo de telecomunicações, resolveu iniciar um estudo sobre a
viabilidade de se desenvolver uma tecnologia que permitisse a comunicação entre
telefones celulares e outros dispositivos e acessórios, utilizando sinais de rádio, ao
invés de cabos. O estudo se baseou em um projeto sobre o uso de sistemas de
comunicação em redes de telefones celulares. Tal pesquisa resultou em um sistema
de rádio de curto alcance nomeado MCLink.
 18

Em 1997, o projeto despertou o interesse de outras empresas que passaram

a fornecer apoio. Em 1998 foi criado o consórcio Bluetooth Special Interest Group
(Bluetooth SIG), formado pelas empresas Ericsson, Intel, IBM, Toshiba e Nokia. O
grupo era composto por duas referências em telecomunicações (Ericsson e Nokia),
e duas referências na fabricação de computadores (IBM e Toshiba), além da líder no
desenvolvimento de chips e processadores (Intel).

A sede global do Bluetooth SIG está em Kirkland, Washington, EUA e tem

escritórios locais em Hong Kong, Pequim, China, Seul, Coréia, Minato-ku, Tokyo,
Taiwan e Malmo, na Suécia.

O grupo envolveu mais de treze mil membros e só na primeira década de

existência produziu mais de dois bilhões de produtos. A Figura 1 apresenta a
primeira formação do grupo liderado pela Ericsson.

A integração entre estas empresas permitiu o desenvolvimento de padrões

que garantiram o uso e a interoperabilidade da tecnologia nos mais variados
dispositivos. (Bluetooth SIG, 1998)

Figura 1: Empresas do Bluetooth SIG

Fonte: Bluetooth SIG - 2002

 19

Atualmente se uniram ao grupo principal a Microsoft e uma fabricante de

computadores pessoais, a japonesa Lenovo.

A denominação Bluetooth é uma homenagem ao rei dinamarquês Harald

Blåtand, mais conhecido como Harald Bluetooth. Devido à capacidade de
interoperabilidade e unificação de vários dispositivos, proposta da tecnologia
Bluetooth, esta foi uma homenagem conveniente, uma vez que um dos grandes
feitos do rei Harald foi a unificação da Dinamarca.

Figura 2: Bluetooth Logo

Fonte: Bluetooth SIG – 2002

A tecnologia tornou-se padrão global de comunicação sem fio, permitindo a

transmissão de dados entre dispositivos compatíveis com a tecnologia. Para isso,
uma combinação de hardware e software é utilizada para permitir que a
comunicação ocorra entre os vários tipos de aparelhos. A transmissão de dados é
feita através de radiofreqüência, permitindo que um dispositivo detecte o outro
independente de suas posições, desde que estejam dentro do limite de proximidade.

Para que se atenda aos diversos tipos de dispositivos, os níveis de alcance

máximo do Bluetooth foram divididos em três classes. A tabela 1 mostra a relação
entre a potência e o alcance de cada uma:
 20

Tabela 1
Classes de potência e alcance do Bluetooth

CLASSE POTÊNCIA MÁXIMA ALCANCE

1 100 mW 100 metros

2 2,5 mW 10 metros

3 1 mW 1 metro

Fonte: Bluetooth SIG, 2009

Um ponto importante, é que dispositivos de classes diferentes podem se

comunicar sem problema, bastando respeitar o limite daquele que possui menor
alcance. A velocidade de transmissão de dados é relativamente baixa, levando-se
em consideração outras tecnologias de transmissão sem fio. Até a versão 1.2, a taxa
alcançava 1 Mbps de velocidade máxima e na versão 2.0, até 3 Mbps. Estas taxas
são suficientes para uma conexão satisfatória entre a maioria dos dispositivos. No
entanto, a versão 3.0 poderá ser capaz de atingir taxas de até 24 Mbps.

2.1.1 Freqüência de operação e comunicação

Uma vez que o Bluetooth adota um padrão global, se fez necessária a adoção
 21

de uma freqüência de rádio aberta, que seja padrão internacional. A faixa ISM
(Industrial, Scientific, Medical), operando à freqüência de 2,45 GHz, é a que mais se
aproxima dessa necessidade e é utilizada em vários países, com variações que vão
de 2,4 GHz a 2,5 GHz.
Uma vez que a faixa ISM pode ser utilizada por qualquer sistema de
comunicação, é necessário garantir que o sinal do Bluetooth não sofra e nem gere
interferências. Para garantir tal necessidade, o sistema de comunicação Frequency
Hopping – Code Division Multiple Access (FH-CDMA), utilizado pelo Bluetooth,
permite fazer com que a freqüência seja dividida em vários canais. O dispositivo que
estabelece a conexão muda de um canal para outro de maneira muito rápida. Daí
denominação frequency hopping (salto de frequência). Isso faz com que a largura de
banda da freqüência seja muito pequena, diminuindo relativamente as chances de
uma interferência. Para a transmissão de dados utiliza FHSS (frequency hopping
spread spectrum). (ALECRIM, 2008)

O Bluetooth, dentro da faixa ISM, pode utilizar até 79 freqüências, ou 23,

dependendo do país, cada uma 1 MHz distante da outra.

Um dispositivo se comunicando por Bluetooth opera em modo full-duplex, ou

seja, pode tanto receber quanto transmitir dados. Para que isso ocorra, a
transmissão é alternada entre slots para transmitir e slots para receber, um esquema
denominado Frequency Hopping/Time Division Duplex (FH/TDD). Esses slots são
canais divididos em períodos de 625 µs (microsegundos). Cada salto de freqüência
deve ser ocupado por um slot, logo, em 1 segundo, tem-se 1600 saltos. Em alguns
casos, como a conexão com impressoras, a operação será Half-duplex. A figura 3
mostra um esquema de FH/TDD. (ALECRIM, 2008)

Quanto ao enlace entre o emissor e receptor, o Bluetooth faz uso de dois

padrões. O primeiro é o Synchronous Connection-Oriented (SCO), responsável por
estabelecer um link sincronizado entre o dispositivo mestre e o dispositivo escravo,
onde é feito uma reserva de slots para cada um. Assim, o SCO acaba sendo
utilizado principalmente em aplicações de envio contínuo de dados, como voz. Por
funcionar dessa forma, o SCO não permite a retransmissão de pacotes de dados
perdidos. Quando ocorre perda na transmissão de áudio, o dispositivo receptor
reproduzirá o som com ruído. A taxa de transmissão de dados no modo SCO é de
 22

432 Kbps, sendo de 64 Kbps para voz.

Figura 3: Esquema do Frequency Hopping/Time Division Duplex (FH/TDD)

Fonte: Ericsson Technology - 2003

O padrão Asynchronous Connection-Less (ACL) por sua vez, estabelece uma

conexão entre um dispositivo mestre e os dispositivos escravos existentes em sua
rede. Essa conexão é assíncrona, já que utiliza os slots previamente livres. Ao
contrário do SCO, o ACL permite o reenvio de pacotes de dados perdidos,
garantindo a integridade das informações trocadas entre os dispositivos. Assim,
acaba sendo útil para aplicações que envolvam transferência de arquivos. A
velocidade de transmissão de dados no modo ACL é de até 721 Kbps. (ALECRIM,
2008)
 23

2.1.2 Redes Bluetooth

Quando dois ou mais dispositivos se comunicam através de uma conexão

Bluetooth, eles formam uma rede denominada piconet. Nessa comunicação, o
dispositivo que iniciou a conexão assume o papel de mestre, enquanto os demais
dispositivos se tornam escravos. O mestre é responsável por regular a transmissão
de dados entre a rede e o sincronismo entre os dispositivos.

Cada piconet pode suportar até oito dispositivos (um mestre e sete escravos),
portanto, é possível aumentar esse número através da sobreposição de piconets, ou
seja, fazer com que uma piconet se comunique com outra dentro de um limite de
alcance. Esse esquema é denominado scatternet. Neste modo, um dispositivo
escravo pode fazer parte de mais de uma piconet ao mesmo tempo, no entanto, um
mestre só pode ocupar essa posição em uma única piconet. Vale lembrar que um
dispositivo mestre em uma Piconet será um escravo a partir do momento em que ele
se conecta em outra Piconet. A figura 4 apresenta os esquemas de uma rede
Piconet Simples, uma Piconet Multi-Escravos e uma Scatternet. (ALECRIM, 2008)
 24

Figura 4: Topologia Bluetooth

Fonte: PRIESS e outros - 2003

É necessário fazer uso de um esquema de identificação para que cada

dispositivo saiba quais outros fazem parte de sua piconet. Para isso, um dispositivo
que deseja estabelecer uma conexão em uma piconet já existente pode emitir um
sinal denominado Inquiry (consulta). Os dispositivos que recebem tal sinal
respondem enviando um pacote Frequency Hopping Synchronization (FHS),
informando a sua identificação e os dados de sincronismo da piconet. Com base
nessas informações, o dispositivo pode então emitir um sinal chamado Page para
estabelecer uma conexão com outro dispositivo. (ALECRIM, 2008)

Para oferecer economia de energia, um terceiro sinal, denominado Scan é

utilizado para fazer com que os dispositivos que estiverem ociosos entrem em stand-
by. Isto garantirá que o dispositivo poupe energia. Assim que outros aparelhos
tentam estabelecer alguma conexão, o dispositivo retorna do estado de espera.
 25

2.1.3 Versões do Bluetooth

Até o momento, as versões disponíveis para o Bluetooth são: (ALECRIM,

2008)

• Bluetooth 1.0: Por ser a primeira versão, os fabricantes encontravam

problemas que dificultavam a implementação e a interoperabilidade entre
dispositivos com Bluetooth;

• Bluetooth 1.1: representa o estabelecimento do Bluetooth como um padrão

802.15 do Institute of Electrical and Electronics Engineers (IEEE 802.15).
Nela, muitos problemas encontrados na versão 1.0 foram corrigidos.

• Bluetooth 1.2: conexões mais rápidas, melhor proteção contra interferências,

suporte aperfeiçoado a scatternets e processamento de voz mais avançado;

• Bluetooth 2.0: diminuição do consumo de energia, aumento na velocidade de

transmissão de dados para 3 Mbps (2.1 Mbps efetivos), correção às falhas
existentes na versão 1.2 e melhor comunicação entre os dispositivos;

• Bluetooth 2.1: permite uma seleção melhorada dos dispositivos antes de

estabelecer uma conexão, melhorias nos procedimentos de segurança e
melhor gerenciamento do consumo de energia;
 26

• Bluetooth 3.0: altas taxas de velocidade de transferência de dados podendo

atingir a marca de 24 Mbps de transferência devido incorporação de
transmissões 802.11, além do controle mais inteligente do gasto de energia
exigido para as conexões.

• Bluetooth 4.0: melhor sistema de economia de energia e mais segurança,

com 128 bits de codificação. Previsão para entrada no mercado em 2010.

Uma característica do Bluetooth é que versões mais recentes são compatíveis

com versões mais antigas, porém ocorre uma limitação na velocidade de
transmissão. Neste caso, prevalece o dispositivo que possui a menor velocidade de
transmissão.

2.2 O Protocolo KW2000

No final dos anos 80 e começo dos anos 90, teve-se um grande salto da
eletrônica no ramo automobilístico. Com isso, cada montadora recorreu a protocolos
de comunicação próprios para obter dados de diagnóstico eletrônico em veículos
automotores.

Em meados dos anos 90, as empresas do ramo automotivo se juntaram para

criar um protocolo padrão, que foi batizado como “Protocolo KW2000”.

Hoje o Protocolo KW2000 é muito utilizado no desenvolvimento de módulos

eletrônicos e ferramentas de diagnóstico para automóveis. Sistemas de diagnóstico
KW2000, são implementados na camada física da estrutura de comunicação
baseados no padrão 9141 do International Standardization Organization (ISO 9141).
Nesta estrutura são implementados os serviços de diagnósticos de falha. Este
protocolo é aplicado em veículos alimentados com 12V e 24V.
 27

2.2.1 Topologia física

O protocolo “KW2000” utiliza o barramento CAN para a transmissão de

dados, que requer as informações entre um dispositivo usuário e uma rede, tendo
como estrutura duas linhas seriais: Linha k, que é utilizada para comunicação e
inicialização e, linha L, que é opcional e utilizada somente para inicialização. A
Figura 5 ilustra tal estrutura. (PÓVOA, 2007)
Outra estrutura é a conexão nó-a-nó, onde há somente um módulo eletrônico
conectado à ferramenta de diagnóstico e também utiliza a transmissão da
informação na forma de barramento.

Figura 5: Topologia
Fonte: Póvoa, 2007
 28

2.2.2 Estrutura da mensagem

A mensagem é constituída por três partes, como mostra a Figura 6:

- cabeçalho;
- bytes de dados;
- verificação (Checksum).

Figura 6: Estrutura da mensagem

Fonte: ISO 14230 – 2, 1999

2.2.2.1 Cabeçalho

O cabeçalho é constituído por 4 bytes, são eles: Format byte (Fmt), Target
byte (Tgt), Source byte (Src) e o Additional Lenght byte (Len), onde cada byte
representa um tipo de informação, que serão descritos na sequência. O cabeçalho é
mostrado na Figura 6.

2.2.2.2 Format byte (Fmt)

O Format Byte inclui informações sobre o formato de mensagens, onde tem 6

 29

bits L5 a L0 de comprimento de informações que informa a quantidade de bytes de

dados que serão enviados na mensagem e define o comprimento do campo de
dados de uma mensagem, ou seja, desde o início do campo de dados o Service
Identification byte (SId) incluído, para o byte (Checksum) não incluído. Também é
possível um comprimento de mensagem de 1 a 63 bytes.
.

Os bits A1 e A0 indicam o endereçamento da mensagem e definem a forma

do cabeçalho da mensagem conforme mostra a tabela 2:

Tabela 2
Forma do cabeçalho da mensagem

A1 A0 Modo de Operação

0 0 Sem informação de endereço

0 1 Modo de exceção (CARB)

1 0 Com informação de endereço, endereçamento físico

1 1 Com informação de endereço, endereçamento funcional

Fonte: ISO 14230 – 2, 1999

O modo de exceção CARB não será estudado neste trabalho. Informações

sobre este modo podem ser encontradas nas normas ISO 9141- 2 e SAE J1979.
 30

2.2.2.3 Target address byte (Tgt)

Este é o byte de endereço de destino da mensagem e é sempre utilizado

junto com o byte de endereço de origem (Source address byte). Pode ser um
endereço físico ou funcional, quando utilizado na mensagem de solicitação, enviada
da ferramenta de diagnóstico para os módulos eletrônicos. As mensagens de
resposta enviadas dos módulos eletrônicos para a ferramenta de diagnóstico deve
ser somente o endereço físico. O Target address byte é opcional, usado somente
em estrutura com conexões de múltiplos nós.

2.2.2.4 Source address byte (Src)

Este é o byte de endereço do dispositivo de transmissão da mensagem e é

sempre utilizado junto com o byte de endereço de destino (Target address byte).
Este byte é opcional, usado somente em estrutura com conexões de múltiplos nós.
Deve ser somente o endereço físico, especificado na norma SAE J2178-1.
.

2.2.2.5 Additional Length byte (Len)

Este byte define o tamanho de uma mensagem desde o início do byte de

dados com Service Identification byte (SId) incluído, para o byte (Checksum) não
incluído. Este byte é transmitido se o comprimento do byte do “Format byte” (L0 a
L5) for igual a zero, como mostra a tabela 3. Pode ser utilizado para mensagens com
byte de dados menor que 64 bytes, para isto o comprimento pode ser incluído no
Format byte ou no Additional Length byte conforme a tabela 3. Também é opcional e
permite um comprimento de dados de até 255 bytes.
 31

Tabela 3
Presença do comprimento de byte

Fonte: ISO 14230 – 2, 1999

Sendo: - XX - 2 bits com informação do modo de endereço

- LL LLLL – 6 bits com informação de comprimento do byte de dados

2.2.2.6 Formatos de mensagens

Com as definições acima, existem quatro formas de mensagens possíveis,

como mostram as figuras 7, 8, 9 e 10.

Figura 7: Cabeçalho sem informação de endereço, sem o Additional Length byte

Fonte: FIAT STANDARD DIAGNOSTIC PROTOCOL, 2000
 32

Figura 8: Cabeçalho sem informação de endereço, com o Additional Length byte

Fonte: FIAT STANDARD DIAGNOSTIC PROTOCOL, 2000

Figura 9: Cabeçalho com informação de endereço, sem o Additional Length byte

Fonte: FIAT STANDARD DIAGNOSTIC PROTOCOL, 2000

Figura 10: Cabeçalho com informação de endereço, com o Additional Length byte
Fonte: FIAT STANDARD DIAGNOSTIC PROTOCOL, 2000

Fmt – Format byte

Tgt - Target address byte (opcional)
Src - Source address byte (opcional)
Len - Additional Length byte (opcional)
Sld - Service Identification byte
Dados – Dados da mensagem
CS – Checksum byte

2.2.3 Byte de dados

Tal campo de dados pode conter até 63 ou até 255 bytes, dependendo de
como é definido a informação de comprimento, e o primeiro byte é o Service
Identification (Sld), que pode ser acompanhado por parâmetros e dados,
dependendo do serviço selecionado. Estes bytes são especificados na norma ISO
 33

14230-3 para serviços de diagnósticos.

2.2.3.1 Byte de verificação (Checksum)

Este byte inserido no final da mensagem é definido como a soma de todos os

bytes da mensagem, excluindo ele próprio. É usado para verificar a integridade de
dados transmitidos e é recalculado na recepção. Se o valor obtido for o mesmo do
calculado durante a transmissão, as informações não sofreram alterações e portanto
não estão corrompidas e não precisam ser reenviadas. Esta técnica não garante a
correção de erros, apenas a verificação de alguma incompatibilidade entre a
informação enviada e a recebida.

2.2.4 Diagnóstico em KW2000

Todas as mensagens que trafegam em um barramento com padrão ISO 9141

são definidas por palavras-chave que retornam ao equipamento de diagnóstico
durante a inicialização das comunicações. Daí a expressão Keywords, usada para
definir o protocolo. (GUIMARÃES, 2007)
Os requisitos para a implementação da troca de informações entre módulos
eletrônicos e Testers são especificadas pela ISO 9141. Vejamos algumas das
especificações da ISO 9141:

• Os módulos eletrônicos devem ter uma (K) ou duas (K e L) linhas de

comunicação para inspeção, teste e diagnóstico.

• A linha K é definida como a que envia informação na forma digital serial,

do módulo eletrônico para o testador de diagnóstico e, pode ser usada
também bidirecionalmente, onde transmite dados ou comandos do
testador para o módulo eletrônico.

• A linha L é definida como unidirecional do testador de diagnóstico para

o módulo eletrônico. Pode ser usada também para inicialização da
 34

comunicação serial ou transmitir dados e comandos.

• Se as linhas K ou L de dois ou mais módulos eletrônicos são

conectadas juntas, o sistema é chamado de barramento.

2.3 Barramento CAN

O barramento de dados CAN foi um dos primeiros na indústria de automóveis

e, o mais usado. Foi desenvolvido pela empresa alemã BOSCH em 1986 para
conectar dispositivos de controle em automóveis e sua primeira aplicação foi
realizada em ônibus e caminhões. Atualmente, é utilizado na indústria de
automóveis, navios e tratores, entre outros.

O barramento CAN oferece uma comunicação muito mais rápida e, com isso
uma melhor troca de informações. Isto é importante quando os módulos eletrônicos
precisam ser acessados durante o processo de fabricação do veículo, onde as
comunicações muito longas e demoradas podem prejudicar o processo.

2.3.1 Conceituação básica

Sendo o CAN um protocolo de comunicação serial síncrono, o sincronismo

entre os módulos conectados à rede é realizado em relação ao início de cada
mensagem lançada ao barramento. Tal sincronismo ocorre em intervalos de tempo
conhecidos e regulares. (GUIMARÃES, 2007).
O barramento trabalha baseado no conceito multimestre, onde os módulos
serão mestres em certo momento e escravos em outro e, para o envio de
mensagens utiliza o modo multicast, onde envia a mensagem para todos os módulos
da rede.
Para o acesso dos dispositivos ao barramento é necessário utilizar técnicas
de acesso ao barramento. Uma técnica utilizada é o Carrier Sense Multiple
Access/Collision Detection with Non-Destructive Arbitration (CSMA/CD com NDA),
 35

ou seja, os módulos verificam o estado do barramento, para saber se outro

dispositivo conectado não está enviando mensagens. Caso o barramento esteja
ocioso o dispositivo então envia a mensagem. Caso ocorra a tentativa de dois
dispositivos (A e B) enviarem mensagem simultaneamente, somente o dispositivo
que apresenta maior prioridade irá enviar e após o término da sua transmissão o
dispositivo com menor prioridade poderá transmitir.
No barramento CAN existe um quadro de mensagens que é composto de um
identificador de mensagens, onde é realizada a arbitragem que determina a
prioridade da mensagem. Arbitragem vem de um conceito de dominância, isto
garante que somente a mensagem mais importante tenha prioridade no barramento.
Os módulos escutam o barramento e, não detectando nenhuma transmissão, iniciam
sua própria transmissão. Cada mensagem tem seu próprio quadro de mensagem,
como o quadro de mensagem inicialmente de ambos é igual, não é detectado a
colisão com isso continuam a transmissão. Logo após, os módulos iniciam o
processo de escrita do identificador da mensagem.
Durante o processo de escrita do identificador, supondo que o próximo bit que
o dispositivo A escreve seja um dominante e o bit a ser escrito pelo dispositivo B é
recessivo, quando é realizada a escrita de ambos, o bit de A sobrescreve o bit de B.
Lembrando que o que interessa ao módulo é o bit dominante. O dispositivo B,
quando identifica o bit lido e o escrito, fica em modo de escuta, indicando que sua
mensagem tem menor prioridade e, quando A terminar de transmitir, B tentará enviar
a sua mensagem. Tal processo de arbitragem e escrita do identificador é mostrado
na Figura 11.
 36

Figura 11: Exemplo de arbitragem no barramento.

Fonte: Barbosa, 2003

O barramento apresenta a técnica chamada Non Return to Zero (NRZ) em

que cada bit, seja ele 0 ou 1, é transmitido por um valor de tensão específico e
constante. (GUIMARÃES, 2007)
A aplicação com CAN nos sistemas de controle e automação foi devido a
possibilidade de trabalhar com uma taxa de transmissão de até 1Mbps que depende
da distância a ser transmitida. A relação entre o comprimento da rede e a taxa de
transmissão dos dados é mostrada na Figura 12.
 37

Figura 12: Relação entre comprimento da rede e taxa de transmissão.

Fonte: Eletrônica Embarcada Automotiva, 2007

O barramento CAN trabalha com fios elétricos como meio de transmissão dos
dados. Existem três tipos de barramento CAN, sendo com um, dois e quatro fios. Os
barramentos de dois e quatro fios trabalham com sinais de dados definidos como
CAN High (CAN_H) e CAN Low (CAN_L) e são do tipo par trançado diferencial. Isto
atenua os efeitos das interferências eletromagnéticas. No caso da rede com quatro
fios, além dos sinais de dados possui um fio com VCC (alimentação) e outro GND
(referência). No caso do barramento com um único fio, este é utilizado apenas para
trafegar os dados, denominado de linha CAN. (GUIMARÃES, 2007)

No CAN, os dados são representados por bits dominantes e recessivos,

devido aos fios CAN_H e CAN_L. O fio dominante é representado pelo nível lógico
baixo (0), já o recessivo pelo nível lógico alto (1). A interface de nível físico da rede
CAN tem a missão, de a cada tempo de transmissão de um bit, gerar um bit
dominante se o nível lógico recebido for baixo e de fazer nada se o nível lógico
recebido for alto.

A interface quando quer gerar um bit dominante, ela faz com que o nível
elétrico do fio CAN_H se eleve a 3,5 volts e o fio CAN_L para 1,5 volts. E com isso,
 38

fica determinado uma diferença de potencial de 2 volts. Isto caracteriza o bit

dominante. Os níveis de tensão e os bits dominantes e recessivos na rede CAN são
mostrados na Figura 13.

Pode haver uma colisão entre as mensagens, pelo fato que os módulos
podem ser mestres e enviar suas mensagens. Para evitar isto, o barramento CAN
utiliza-se de uma arbitragem bit a bit não destrutiva. Após enviar um bit, cada
módulo analisa o barramento e verifica-se o outro módulo na rede está em
operação. Então, um módulo interrompe sua transmissão, se o mesmo perceber que
o outro está transmitindo uma mensagem com preferência, ou seja, quando seu bit
recessivo é sobrescrito por um dominante na rede.

Figura 13: Bits dominantes e recessivos no CAN Bus.

Fonte: Eletrônica Embarcada Automotiva, 2007.
2.4 Microcontrolador PIC 16F877A

O Microcontrolador PIC 16F877A da Microship é um dos mais utilizado por

desenvolvedores por possuir características interessantes como:
• 8 kbytes de memória de programa;
• 368 bytes de memória de dados volátil;
 39

• 256 bytes de memória de dados não volátil;

• 15 interrupções;
• 33 pinos I/O (Port’s A, B, C, D e E);
• 3 timers (2 de 8 bits, 1 de 16 bits);
• Universal Syncronous Asyncronous Receiver Transmiter (USART) para
comunicação serial Recommended Standard 232 (RS232);
• Comunicação serial pelo Inter-Integrated Circuit (I²C);
• 8 canais de conversão A/D com 10 bits cada.

Existem muitos outros microcontroladores da família PIC, porém somente o

PIC 16F877A será abordado por ser parte do projeto.
A pinagem completa do PIC 16F877A, com suas denominações pode ser
vista no Anexo A. Praticamente todos os pinos deste microcontrolador possuem
mais de uma função. Isso se deve a um processo de multiplexação destes pinos
possibilitando uma quantidade maior de aplicações. A utilização de uma função ou
outra é definida via software, através da programação do PIC de acordo com a
necessidade.

2.4.1 Módulo USART

A USART é um módulo de recepção e transmissão de dados serial de forma

full-duplex, transmitindo e recebendo dados simultaneamente. A USART possui um
canal para transmissão e um para recepção chamados TX e RX, respectivamente.
Esta característica de se ter canais diferentes para transmissão e recepção é
o que possibilita a comunicação full-duplex. No PIC 16F877A, os canais TX e RX
são os pinos RC6 e RC7, respectivamente. Vale lembrar que a USART deste
microcontrolador não possui suporte para controle de fluxo de dados. Esta função
deve ser implementada por software.
 40

2.5 Módulo Bluetooth

Os módulos Bluetooth são os dispositivos de transmissão de dados sem fio

presentes em vários aparelhos eletrônicos ou equipamentos eletroeletrônicos e que
possibilitam a comunicação entre dispositivos, seja para uma troca de dados ou até
como controles remotos. Porém estes módulos já são vendidos separadamente e
são facilmente encontrados no mercado para o desenvolvimento de aplicações
profissionais ou até mesmo amadoras e estará presente no projeto desta proposta.
Existem também os adaptadores Bluetooth Universal Serial Bus (USB) que
são direcionados a aparelhos que possuem entradas USB e que não possuem
dispositivos Bluetooth integrados. A Figura 14 ilustra o diagrama de blocos de um
módulo Bluetooth .

Figura 14: Diagrama de Blocos de um módulo Bluetooth

Fonte:SURE Electronics, 2008

2.6 Comunicação Serial e o Padrão RS232

2.6.1 Comunicação de dados

 41

A comunicação de dados procura estudar os meios de transmissão de dados

em geral, para dispositivos externos ao circuito original da mensagem. Dispositivos
externos são geralmente circuitos com fonte de alimentação. Quanto à taxa de
transmissão máxima de uma mensagem, esta é diretamente proporcional a potência
do sinal, e inversamente proporcional ao ruído. A função de qualquer sistema de
comunicação é fornecer a maior taxa de transmissão possível, com a menor
potência e com o menor ruído possível. (CANZIAN, 2009)

2.6.2 Comunicação Serial

A maioria das mensagens digitais são longas e por questões de praticidade a

transferência de dados não é realizada enviando todos os bits simultaneamente. A
transmissão bit-serial converte a mensagem em um bit por vez através de um canal.
Cada bit representa uma parte da mensagem. Os bits individuais são então
rearranjados no destino para compor a mensagem original. Em geral, um canal irá
passar apenas um bit por vez. A transmissão bit-serial é normalmente chamada de
transmissão serial, e é o método de comunicação escolhido por diversos periféricos
de computadores.
A transmissão byte-serial, também chamada de transmissão paralela,
converte 8 bits por vez através de 8 canais paralelos. Embora a taxa de
transferência seja 8 vezes mais rápida que na transmissão bit-serial, são
necessários 8 canais, e o custo poderá ser maior do que 8 vezes para transmitir a
mensagem. Quando as distâncias são curtas, é comum usar canais paralelos como
justificativa para as altas taxas de transmissão. A interface Centronics de
impressoras mais antigas é um caso típico de transmissão byte-serial. (CANZIAN,
2009)
2.6.3 Taxa de Transferência (Baud Rate)

A taxa de transferência refere-se a velocidade com que os dados são

enviados através de um canal e é medido em transições elétricas por segundo. Na
norma EIA232, ocorre uma transição de sinal por bit, e a taxa de transferência e a
 42

taxa de bit são idênticas. Nesse caso, uma taxa de 9600 bauds corresponde a uma
transferência de 9600 dados por segundo, ou um período de aproximadamente, 104
ms (1/9600 s). (STRANGIO, 2006)
Outro conceito é a eficiência do canal de comunicação que é definido como o
número de bits de informação utilizável enviados pelo canal por segundo. Ele não
inclui bits de sincronismo, formatação, e detecção de erro que podem ser
adicionados à informação antes da mensagem ser transmitida, e sempre será no
máximo igual a um. A Figura 15 ilustra uma comunicação serial.

Figura 15: Diagrama de comunicação serial

Fonte: Edmur Canzian, 2009

Os valores mais utilizados de baud rate são 1200, 2400, 4800, 9600, 19200
baud.
3 METODOLOGIA

Os estudos acerca do dispositivo proposto foram conduzidos a partir do

veículo Brava, ano 2000, que é o objeto de pesquisas cedido pela montadora Fiat ao
curso de Engenharia Elétrica da PUC Minas – campus Poços de Caldas.
A ECU presente no veículo é da marca MAGNETI MARELLI , modelo IAW
 43

1AB. Nela será instalado o dispositivo proposto. Todas as informações controladas

pela ECU, assim como os parâmetros de cada uma podem são apresentados na
tabela 4. Já as fórmulas de conversão dos dados se encontram no Anexo B. (FIAT,
1996)

Tabela 4
Lista de Parâmetros controlados pela ECU

Fonte: Fiat Normazione, 2000

Inicialmente é necessário identificar os padrões utilizados pela ECU para
transmissão dos dados colhidos do motor. Tais informações são cruciais para um
futuro desenvolvimento do projeto. A Figura 16 ilustra o esquema do projeto
proposto.
 44

Figura 16: Esquema Geral do Projeto Proposto

A unidade de controle ECU, que tem conectados a ela todos os sensores e

atuadores do sistema eletromecânico do veículo. A unidade se comunica com tais
sensores, armazena as informações, processa, e atua de acordo com os parâmetros
pré-definidos na sua programação. Caso a unidade identifique falhas em
determinados sensores há a necessidade de uma intervenção externa para
solucionar o problema, ou seja, é necessário um profissional qualificado com os
dispositivos de diagnóstico para corrigir os possíveis defeitos.
Sendo assim, a ECU é dentro do trabalho, o principal bloco a ser estudado
para que sejam alcançados os objetivos, pois todas as informações necessárias
dizem respeito a ela, desde o barramento CAN, o protocolo KW2000 e os dados e
serem tratados.

3.1 Simulações do sistema utilizando um microcontrolador PIC 16F877A

Para apresentação da proposta, foi desenvolvido um protótipo onde uma ECU

foi simulada através de um PIC 16F877A e os sensores e atuadores foram
simulados através de chaves e potenciômetros. A Figura 17 ilustra o esquema do
projeto proposto.
 45

Figura 17: Esquema Geral do Protótipo Proposto

A princípio, a comunicação serial foi realizada via cabos, de um PIC para

outro, para realização dos testes de comunicação. Com este teste inicial foi possível
confirmar que a comunicação serial entre o PIC transmissor, que simula a ECU e o
PIC receptor estava funcionando corretamente. O diagrama esquemático é ilustrado
na Figura 18.
Nesta simulação inicial o microcontrolador transmissor foi programado para
controlar os led’s conectados no microcontrolador receptor de acordo com a
mudança de estados das chaves e potenciômetros. Isto foi possível devido a
comunicação serial entre os dois. Na programação do PIC TX foi necessária a
declaração de um vetor de 8 bytes, onde cada byte recebeu a informação de cada
chave e potenciômetro. Em seguida os bytes foram enviados serialmente para o PIC
RX, que também necessitou da declaração de um vetor de 8 bytes, que recebeu os
8 bytes enviados pelo PIC TX. Ambos foram programados para operar de forma
sincronizada. Desta maneira, foi possível que a rotina funcionasse a contento. O
Microcontrolador TX consegui controlar o microcontrolador RX.
Após observado o funcionamento da comunicação serial, os testes passaram
a ser realizados usando apenas o microcontrolador transmissor e o hyperterminal do
sistema operacional, para o envio de comandos ao PIC e o recebimento das
informações nele contidas. A Figura 19 apresenta a nova configuração.
 46

Figura 18: Diagrama esquemático do circuito de testes da comunicação serial

 47

Figura 19: Diagrama esquemático do circuito de testes pelo Hyperterminal

Foi necessária a inserção de comandos na programação do microcontrolador

para que esse pudesse ser controlado via hyperterminal. Tais comandos possibilitam
que as informações que o microcontrolador recebe dos potenciômetros, que
simulam sensores presentes no motor do veículo, e das chaves, simulando
atuadores ou relés, sejam enviadas para a tela do hyperterminal podendo assim,
serem visualizadas pelo usuário. A Figura 20 mostra como as informações são
apresentadas na tela do hyperterminal.
 48

Figura 20: Informações visualizadas pelo Hyperterminal

3.2 Conexão entre o microcontrolador e o módulo Bluetooth

Após estes testes iniciais, o PIC receptor é retirado e dá espaço ao notebook.

Já o PIC transmissor, simulando a ECU, tem conectado em seus canais TXRX, o
módulo de desenvolvimento Bluetooth Serial Converter UART Interface, da marca
Sure Electronics. Esse módulo possui uma velocidade de transmissão de 9600bps,
ou seja, possui um baud rate de 9600bps. É um dispositivo de classe 2 podendo
alcançar então, até 10m de visada com outros dispositivos, suficiente para esta
aplicação.
 49

Figura 21: Módulo Bluetooth GP-GC021

Fonte: Sure Electronics - 2008

Algumas das principais características deste dispositivo são:

Tabela 5
Características do Módulo GP-GC021

Frequência de Operação 2.4GHz -2.48GHz na banda ISM

Especificações do Bluetooth V2.0+EDR
Classe de Potência Classe 2
Tensão de Operação 3.3V
Interface do Host USB 1.1/2.0 or UART
Interface de Áudio PCM e interface analógica
Consumo em operação 10mA
Temperatura de Operação - 40°C à +105°C
Consumo em Standby 40uA
Memória Flash 8Mbit
Dimensões 26.9mm x 13mm x 2.2mm
Peso 10 g / 0.4 oz
Fonte: Sure Electronics, 2008

A utilização desse módulo Bluetooth foi importante, pois facilitou relativamente

a desenvolvimento do projeto com o microcontrolador. Isso devido à interface UART
utilizada por ele. Com isso, o módulo necessita apenas da utilização dos pinos GND
e VCC, e os pinos TX e RX, que serão conectados aos pinos RX e TX do
microcontrolador. A tabela 5 mostra os pinos necessários para o funcionamento do
módulo, além de outros pinos opcionais, e a Figura 22 apresenta a pinagem do
 50

dispositivo.

Tabela 6
Descrição dos pinos do módulo Bluetooth

Nº do Pino Nome Tipo Função

1 UART - TX Saída - CMOS Saída de dados
2 UART - RX Entrada - CMOS Entrada de dados
11 Reset Entrada - CMOS Reset em nível baixo
12 3.3V Alimentação +3.3V
13 GND GND Terra
14 GND GND Terra
21 GND GND Terra
22 GND GND Terra
Fonte: Sure Electronics, 2008

Figura 22: Pinagem do Módulo GP-GC021

Fonte: Sure Electronics, 2008

Existem duas configurações comuns para o uso do módulo Bluetooth GP-

GC021. Tais configurações levam em consideração a tensão de alimentação do
módulo. Sendo assim, na conexão com um microcontrolador que também é
alimentado com +3.3V não será necessário o uso de nenhum tipo de regulador de
tensão. Já no caso mais comum, onde a conexão é utilizada com microcontroladores
alimentados com +5V será necessária a utilização de qualquer componente capaz
de adequar o nível de tensão para +3.3V. As Figuras 23 e 24 mostram exemplos
 51

destas conexões.

Figura 23: Conexão a um microcontrolador alimentado com 3.3V

Fonte: Sure Electronics, 2008

Como já foi mencionado, no caso de microcontroladores alimentados com

tensões de 3.3V, as conexões com o módulo podem ser feitas de forma direta entre
os pinos TX e RX de cada dispositivo.
 52

Figura 24: Conexão a um microcontrolador alimentado com 5V

Fonte: Sure Electronics, 2008

Nesse caso, o fabricante propôs a utilização de transistores para regular a

tensão de 5V para 3.3V. Outros componentes também podem ser utilizados como
optoacopladores, drivers, ci’s reguladores, etc.
Devido às características do microcontrolador PIC16F877A, que admite
tensão de alimentação entre 2,0V e 5,5V, a primeira configuração apresentada
poderia ser utilizada na montagem do circuito, porém durante os testes de
comunicação, com tensão de 3,3V aplicados no microcontrolador, este não operou
adequadamente, não respondendo aos comandos a ele enviados.
Foi necessária a aplicação da tensão padrão de funcionamento do
microcontrolador ou seja, 5V. Sendo assim, a configuração usada na montagem do
circuito foi a correspondente a Figura 24. Com esta configuração o hardware operou
corretamente, estabelecendo a perfeita comunicação entre o microcontrolador e o
notebook.
4 DESENVOLVIMENTO
 53

Neste momento, completados e conferidos todos os testes realizados em

simulação, o projeto foi testado com os componentes reais que fizeram parte do
projeto. Neste caso, o circuito proposto foi montado e os testes de comunicação sem
fio foram realizados utilizando o hyperterminal do notebook.
Para isso, foi necessária a configuração do hyperterminal para que este
criasse uma porta de comunicação com o dispositivo Bluetooth instalado no
notebook. Tais configurações e procedimentos serão descritos durante o
desenvolvimento.
Grande parte dos componentes utilizados na montagem do projeto foram
citados anteriormente, porém uma listagem completa dos componentes utilizados na
montagem final do projeto é a seguinte:

• Microcontrolador PIC16F877A;
• Módulo Bluetooth SURE ELECTRONICS classe 2 e interface UART;
• 4 Potênciometros – 1KΩ;
• 4 Chaves on/off simples;
• 1 Led;
• 5 Resistores de 220Ω;
• 1 Resistor de 680Ω;
• 2 Resistores de 1KΩ;
• 2 Resistores de 10KΩ;
• 1 Capacitor de 1uF;
• 2 Transistores BC548;
• Placa de fenolite;
• Cristal de 4MHz;
• Fios diversos.

Inicialmente, para o início da montagem do protótipo, foi necessária a

confecção de uma placa simples de circuito impresso, utilizando a placa de fenolite,
como mostra a Figura 25, na qual foi soldado o módulo Bluetooth.
 54

Figura 25: Placa confeccionada para o módulo Bluetooth

O próximo passo foi a montagem completa do circuito, com todos os

componentes citados anteriormente. Em seguida iniciaram-se os testes de
comunicação. Para habilitar o hyperterminal a receber os dados do microcontrolador
através do módulo Bluetooth foram necessárias algumas configurações. Uma vez
que o módulo Bluetooth Sure GP-GC021 foi identificado pelo notebook e teve a sua
conexão permitida, duas portas COM (portas de comunicação serial) virtuais são
habilitadas, uma vez que não existem cabos conectados ao notebook. Uma das
portas COM é de saída, o que permite que o notebook inicie a conexão com o
dispositivo externo. Já a outra porta é de entrada, onde permite que o dispositivo
externo inicie a conexão.
Outra configuração é do baud rate de cada porta COM habilitada para a
conexão com o módulo GP_GC021. Ambas devem ser alteradas para operar com
um taxa de 9600 baud, que é a taxa de transmissão padrão do módulo Bluetooth.
Caso estas taxas de transmissão não estejam sincronizadas, o sistema terá um
funcionamento instável. Os dados recebidos pelo notebook não serão interpretados
corretamente e o hyperterminal não apresentará ao usuário as informações corretas
e sim, caracteres desconexos.
Vale lembrar que toda a autenticação e estabelecimento do enlace Bluetooth
entre o notebook e o módulo GP-GC021 é realizada automaticamente e não
necessita de nenhum tipo de comando específico por parte do usuário. Apenas,
após o enlace de comunicação estabelecido, será realizada a autenticação com o
 55

microcontrolador para que este possa enviar os dados. Até então este envia apenas
o menu dos comandos para transmissão dos dados.
Enfim, o módulo Bluetooth Sure GP-GC021 atua apenas como um meio físico
entre o PIC16F877A e o notebook.
O fluxograma da transmissão de dados entre o microcontrolador e o
computador é apresentado na Figura 26.

Figura 26: Fluxograma da transmissão de dados

Finalmente, a Figura 27 apresenta o digrama completo do circuito montado.
 56

Figura 27: Diagrama completo do circuito proposto

As imagens a seguir mostram os testes realizados e o circuito montado.

 57

Figura 28: Primeira parte do circuito montado

Figura 29: Microcontrolador e módulo Bluetooth

 58

Figura 30: Alimentação do Circuito

Figura 31: Circuito em funcionamento – Led ligado

 59

Figura 32: Vista de todos os componentes montados no circuito

 60

Figura 33: Hyperterminal - Menu

Figura 34: Hyperterminal – Código de acesso

 61

Figura 35: Hyperterminal – Acesso permitido

Figura 36: Informações mostradas na tela do computador

 62

5 RESULTADOS

A partir das simulações do protótipo via software e da realização dos testes

reais com o hardware desenvolvido, foi possível comprovar a eficiência da
comunicação sem fio entre o notebook e o módulo Bluetooth utilizado no trabalho.
Pode-se afirmar com certeza que as características do módulo Bluetooth GP-GC021
facilitaram consideravelmente o desenvolvimento do projeto, pois não foi necessário
nenhum comando específico para o funcionamento deste.
O dispositivo se mostrou confiável e a comunicação extremamente estável,
garantindo o recebimento perfeito de todas as informações enviadas ao computador.
Mesmo com as limitações do hyperterminal, que é um aplicativo relativamente
simples, com restrições de reconhecimento de caracteres e visualização
relativamente simplória, foi possível analisar os dados recebidos.
Algumas dificuldades foram encontradas durante o desenvolvimento, porém
nenhuma que trouxesse transtornos relevantes. Alguns problemas na montagem do
circuito e na configuração da porta COM (porta serial habilitada pelo notebook para
comunicação com o módulo Bluetooth Sure GP-GC021) surgiram, mas foram logo
sanados.
Comprovada a funcionalidade do projeto, certamente será possível realizar a
complementação do trabalho, onde a comunicação Bluetooth será entre a própria
ECU do veículo e o notebook.
 63

6 TRABALHOS FUTUROS

Diversas aplicações para este trabalho podem ser analisadas, além da própria
complementação deste.
Sobre a aplicação do Bluetooth é possível o desenvolvimento de diagnóstico
em rede, onde um notebook poderá atuar como ferramenta de diagnóstico de até
sete automóveis simultaneamente. Esta característica pode ser interessante para
testes realizados em linhas de produção ou até mesmo para as redes autorizadas
que realizam serviços de diagnóstico de falhas e correções.
Outra atividade a ser desenvolvida é criação de uma aplicação com interface
gráfica, mais atrativa ao usuário. Tal aplicação pode ser desenvolvida em qualquer
linguagem gráfica como Java, Delphi, Linguagem C, entre outras.
Uma excelente opção, devido ao grande suporte a tecnologia Bluetooth, é a
plataforma Java, que ultimamente vem ganhando muito espaço devido as suas
funcionalidade e segurança.
Quanto ao suporte oferecido a esta linguagem, existe o J2ME, próprio para
dispositivos com pouco poder de memória e processamento e J2SE, próprio para
computadores pessoais. Além disso, existem diversas ferramentas e ambientes de
desenvolvimento gratuitas no próprio site da empresa desenvolvedora da linguagem.
Ainda existem possibilidades além do contexto deste trabalho, como sistemas
de automação em geral.
 64

REFERÊNCIAS BIBLIOGRÁFICAS

ALECRIM, Emerson – TECNOLOGIA BLUETOOTH – 2008. Disponível em:

< http://www.infowester.com/bluetooth.php>. Acesso em: 15 out. 2009.

BARBOSA, Luiz Roberto G. Rede CAN. Escola de Engenharia da UFMG –

Universidade Faderal de Minas Gerais, Belo Horizonte, 2003. Disponível em:
<http://www.cpdee.ufmg.br/~elt/docs/DSP/Resumo_CAN.pdf>. Acesso em: 05 out.
2009.

Bluetooth SIG. Official site. 2009. Disponível em: <http://www.bluetooth.com>.

Acesso em: 10 out. 2009.

BONNICK, Allan W. M. Automotive Computer Controlled Systems: Diagnostic

tools and techniques. First published 2001, Pg. 112-113.

CANZIAN, Edmur. Minicurso de Comunicação Serial / RS232 - 2009. Disponível

em: <http://www.verlab.dcc.ufmg.br /_media /cursos /introrobotica /2009-
2/comunicacao_serial.pdf>. Acesso em 17 nov. 2009.

FIAT AUTO NORMAZIONE. FIAT STANDARD DIAGNOSTIC PROTOCOL ON

K−LINE KWP2000 – 2000. Acesso em: 15 nov. 2009.

FONSECA, Enrico. iMasters – Ciclo de vida do MIDlet. Disponível em:

<http://imasters.uol.com.br/artigo/3416/java/ciclo_de_vida_do_ midlet>. Acesso em
13 jan. 2010.

GUIMARÃES, Alexandre de Almeida. Eletrônica embarcada automotiva. 1.ed.

Protocolos de Comunicação Automotivos, São Paulo, 2007, Pg. 216-244.

HODGDON, Charles. ADAPTIVE FREQUENCY HOPPING FOR REDUCED

INTERFERENCE BETWEEN BLUETOOTH® AND WIRELESS LAN. Ericsson
Technology Licensing – mai. 2003. Disponível em: <http://www.design-
reuse.com/articles/5715/adaptive-frequency - hopping - for -reduced - interference -
between - bluetooth - and -wireless - lan.html>. Acesso em: 22 dez. 2009.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14229:

Road Vehicles - Diagnostic Systems Diagnostic Services Specification – 1998.
Acesso em: 5 out. 2009.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14230-1:

Road Vehicles - Diagnostic Systems – Physical Layer – 1999. Acesso em: 5 out.
2009.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14230-2:

Road Vehicles - Diagnostic Systems – Keyword Protocol 2000 - Part 2: Data
 65

Link Layer – 1999. Acesso em: 5 out. 2009.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9141-2:

CARB Requirements for Interchange of Digital Information – 1994. Acesso em: 5
out. 2009.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14230: Road

Vehicles - Diagnostic Systems Keyword Protocol 2000 - Part 1 - Physical Layer
Swedish Implementation Standard, October 22, 1997. Acesso em: 5 out. 2009.

JÚNIOR, Nelson Abu Sanra Rahal; LEITE, Mário. Programação Orientada ao

Objeto – uma abordagem didática - 2002. Artigo publicado na Revista de
Informação e tecnologia da Unicamp - Universidade Estadual de Campinas.
Disponível em: <http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html>
Acesso em: 27 fev 2010.

LANA, Luiz dos Reis. REDE CAN - Tráfego de Dados, Conectividade e

automação em Automóveis – Parte II. Disponível em:
<www.Administradores.com.br.html > Acesso em: 13 set. 2009.

LAYTON, Julia; FRANKLIN, Curt. HowStuffWorks. Como funciona o Bluetooth.

Disponível em: <http://informatica.hsw.uol.com.br/bluetooth2.htm>. Acesso em:10
out. 2009.

MICROSHIP TECNOLOGY INC. PIC 16F87XA DATA SHEET – 2003. Disponível

em: < http://ww1.microchip.com/downloads/en/DeviceDoc/39582b.pdf>. Acesso em:
15 nov. 2009.

NILSSON, Mats. Ericsson Review. Third-generation radio access standards.

1998. Disponível em: <http://www.ericsson.com/ about/publications/
review/1998_03/files/1998031.pdf>. Acesso em: 15 out. 2009.

PÓVOA, Rodrigo. APLICAÇÃO DO PROTOCOLO “KW2000” PARA LEITURA DE

DADOS DISPONÍVEIS NO MÓDULO DE CONTROLE DO MOTOR DE UM
VEÍCULO POPULAR. Trabalho de conclusão de curso (Mestrado) - Escola
Politécnica da Universidade de São Paulo, 2007.

PRIESS, Werner, RESENDE, José Ferreira de, PIRMEZ, Luci, CARMO, Luiz
Fernando Rust da Costa - UM MECANISMO DE ESCALONAMENTO
PARAMETRIZÁVEL PARA SCATTERNETS BLUETOOTH, XXI SIMPÓSIO
BRASILEIRO DE REDES DE COMPUTADORES - SBRC'2003, pp. 5-20, Natal, RN,
Brasil. Maio de 2003. Disponível em: <http://www.gta.ufrj.br/ftp/gta/TechReports
/PRPC03.pdf>. Acesso em: 10 out. 2009.

STRANGIO, Christopher E. – THE RS232 STANDARD – 2006. Disponível

em:<http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html#anchor
1154232>. Acesso em: 15 mar. 2010.
 66

ZANCO, Wagner da Silva. Microcontroladores PIC – Técnicas de Software e

Hardware para projetos de Circuitos Eletrônicos com base no PIC 16F877A. 1ª
Edição. São Paulo – SP. 2006

V Seminário sobre a Eletro-Eletrônica Aplicada à Mobilidade: DIAGNOSE

VEICULAR. São Paulo: AEA - Associação Brasileira de Engenharia Automotiva,
2003.
 67

ANEXO A - Microcontrolador PIC16F877A

 68

ANEXO B – Lista de Parâmetros e fórmulas de conversão da

ECU.
 69

ANEXO B – Continuação
70