CENTRO UNIVERSITRIO DE BRASLIA

FACULDADE DE TECNOLOGIA E CINCIAS SOCIAIS APLICADAS

CURSO DE ENGENHARIA DE COMPUTAO

SISTEMA DE MONITORAMENTO ELETRNICO AUTOMOTIVO

AUTOR(A): LVARO SANTANA DOS SANTOS JNIOR

MONOGRAFIA DE CONCLUSO DO CURSO DE ENGENHARIA DE
COMPUTAO
Orientador: Prof. MC. Maria Marony Sousa F. Nascimento
Braslia, 23 de novembro de 2009.

LVARO SANTANA DOS SANTOS JNIOR

SISTEMA DE MONITORAMENTO ELETRNICO

AUTOMOTIVO

Trabalho de concluso do curso de Engenharia

de Computao, da Faculdade de Tecnologia e
Cincias Sociais Aplicadas do Centro
Universitrio de Braslia - UniCEUB.

Prof Orientadora: MC. Maria Marony Sousa F. Nascimento

Braslia, 2009

AGRADECIMENTOS

Agradeo a todos que contriburam para a concluso deste projeto, principalmente a

minha famlia pela compreenso e apoio dados ao longo desse semestre.
No poderia deixar de agradecer ao corpo docente do curso de Engenharia de
Computao do UniCEUB, que foi fundamental para o aprendizado necessrio para a
implementao deste projeto. Em especial agradeo a minha orientadora, a professora Maria
Marony, pelo apoio, dedicao e contribuio para a melhoria e aperfeioamento do trabalho
aqui apresentado.
Aos meus colegas de turma agradeo pelo apoio e motivao, principalmente nas
dificuldades. Agradeo em especial os colegas Diego, Leandro, Marcus Vincius, Robson e
Tiago. Agradeo tambm aos meus amigos Paulo, Diogo, Davi e Marcus Tlio que me
auxiliaram nos testes com o veculo em movimento.
Por fim, agradeo tambm a equipe do SENAI-DF, representada pelos instrutores Lester e
Franco pelas informaes prestadas. Agradeo a equipe da Taguauto pelo atendimento corts
e atencioso.

RESUMO

Neste trabalho apresentado o prottipo de um sistema de monitoramento eletrnico

automotivo. Neste prottipo, so mostradas ao condutor do veculo, informaes de conduo
e das condies do sistema de gerenciamento do motor do veculo, com o objetivo de suprir a
falta das informaes disponibilizadas no painel de instrumentos, sobretudo em veculos
populares.
Este prottipo coleta os dados do sistema de injeo eletrnica do veculo atravs de uma
tomada de diagnstico, processa essas informaes, e as disponibiliza ao condutor do veculo
atravs de um dispositivo mvel, minimizando a perca de dirigibilidade do veculo.
Palavras-chave: Monitoramento automotivo, Key Word 1281, diagnose on-board II
(OBDII), computador de bordo.

II

ABSTRACT

This Project presents the prototype of a system of electronic monitoring automotive. In

this prototype, are showed to the vehicles driver, information of driving and of the conditions
of the management system of the vehicles engine, in order to compensate for the lack of
information available on the dashboard, especially in popular vehicles.
This prototype collects data from electronic injection system of the vehicle through a
connector of diagnostic, processes this information, and makes them available to the driver
through a mobile device, minimizing the loss of steerability.
Keywords: Monitoring automotive, Key Word 1281, on-board diagnostics II (OBDII),
board computer.

III

SUMRIO

LISTA DE FIGURAS...................................................................................................VI
LISTA DE TABELAS ................................................................................................ VIII
LISTA DE EQUAES ..............................................................................................IX
LISTA DE SMBOLOS E ABREVIATURAS................................................................ X
1 Introduo........................................................................................................... 12
1.1

Motivao.................................................................................................................... 12

1.2

Objetivo Geral ............................................................................................................. 13

1.3

Objetivos Especficos .................................................................................................. 13

1.4

Justificativa e Relevncia do Tema ............................................................................. 14

1.5

Escopo do Trabalho .................................................................................................... 15

1.6

Resultados Esperados ................................................................................................ 15

1.7

Estrutura do Trabalho.................................................................................................. 16

2 Apresentao do Problema ............................................................................... 17

3 Referencial Terico ............................................................................................ 20
3.1

Motor de Combusto Interna ...................................................................................... 20

3.2

Sistema de Gerenciamento do Motor ......................................................................... 22

3.2.1

Introduo ............................................................................................................................. 22

3.2.2

Sensores ............................................................................................................................... 22

3.2.3

Atuadores.............................................................................................................................. 26

3.2.4

Mdulos Eletrnicos .............................................................................................................. 29

3.2.5

Gerenciamento de Motor Motronic ........................................................................................ 31

3.3

Diagnose On-Board (On Board Diagnostic OBD) .................................................... 32

3.4

Key Word Protocol 1281 ............................................................................................. 36

3.4.1

Inicializao .......................................................................................................................... 36

3.4.2

Byte de Sincronizao ........................................................................................................... 37

IV

3.4.3

Keyword ................................................................................................................................ 38

3.4.4

Formato do Byte de Dados .................................................................................................... 39

3.4.5

Estrutura de Servio .............................................................................................................. 39

3.5

Padro ASCII .............................................................................................................. 41

3.6

Bluetooth ..................................................................................................................... 42

3.6.1

O Uso de Sistemas Bluetooth em Embarcaes Automotivas ............................................... 44

4 Proposta e Soluo do Modelo......................................................................... 46

4.1

Veculo Utilizado ......................................................................................................... 47

4.2

Interface VAG-COM .................................................................................................... 49

4.3

Interface de Integrao ............................................................................................... 52

4.4

Dispositivo Mvel ........................................................................................................ 53

4.5

O Software Desenvolvido............................................................................................ 54

4.5.1

Software de Conexo e Integrao Bluetooth ........................................................................ 55

4.5.2

Software de Apresentao da Informao ao Condutor ......................................................... 59

4.5.3

A Classe Comm .................................................................................................................... 59

4.5.4

A Classe FrmApresentao ................................................................................................... 59

5 Aplicao da Soluo com Resultados ........................................................... 62

5.1

Avaliao Global da Soluo Proposta ....................................................................... 68

6 Concluso ........................................................................................................... 71
Referncias bibliogrficas...................................................................................... 72
Apndice A Cdigo FOnte da aplicao embarcada no notebook- Conexo e
Integrao
Bluetooth ......................................................................................... 74
Apndice B Cdigo Fonte do Software embarcado em dispositivo Mvel
Apresentao da Informao ao Condutor ........................................................... 87
Anexo A Tabela AscII ............................................................................................ 91

LISTA DE FIGURAS

FIGURA 2.1. CONTA GIROS VEICULAR. (FONTE: HTTP://WWW.AMERICANAS.COM.BR/ACOMPROD/17278/247751).18

FIGURA 2.2. EQUIPAMENTO DE DIAGNSTICO (TESTER) MULTIMARCA. (FONTE:
HTTP://WWW.DELTAFERRAMENTAS.COM.BR/LOJA/PRODUTOS_DESCRICAO.ASP?POPUPADDCARRINHO=S&CO
DIGO_PRODUTO=33) ...............................................................................................................................19

FIGURA 3.1. AS QUATRO FASES DO CICLO OTTO EM UM MOTOR DE COMBUSTO INTERNA. (FONTE:
WWW.MECANICA.UFRGS.BR/MMOTOR/4TEMPOS.JPG) .................................................................................21

FIGURA 3.2. SENSOR DE OXIGNIO. (FONTE: BOSCH, 2005) ..............................................................................23

FIGURA 3.3. MEDIDORES DE MASSA DE AR. (FONTE: BOSCH, 2005) ...................................................................24
FIGURA 3.4. SENSOR DE TEMPERATURA. (FONTE: BOSCH, 2005) .......................................................................24
FIGURA 3.5. SENSOR DO TIPO INDUTIVO (ESQUERDA) E SENSOR HALL (DIREITA). (FONTE: BOSCH, 2005) .............25
FIGURA 3.6. VLVULA INJETORA DE COMBUSTVEL. (FONTE: BOSCH, 2005) ......................................................26
FIGURA 3.7. SISTEMA EGAS .............................................................................................................................28
FIGURA 3.8. BOMBA DE COMBUSTVEL. (FONTE: BOSCH, 2005) ........................................................................29
FIGURA 3.9. DIAGRAMA DE BLOCO DE UMA UCE. (FONTE: GUIMARES, 2007)................................................30
FIGURA 3.10 CONECTOR PADRO OBD II (COM ADAPTAES). (FONTE:
HTTP://WWW.OBDII.COM/CONNECTOR.HTML#DATES) ................................................................................35

FIGURA 3.11. INICIALIZAO DA UCE. (FONTE: SAE, 2008) .............................................................................37

FIGURA 3.12. BYTE DE SINCRONIZAO. (FONTE: SAE, 2008) ............................................................................37
FIGURA 3.13. BYTES CHAVE. (FONTE: SAE, 2008) .............................................................................................38
FIGURA 3.14. FORMATO DO DADO. (FONTE: SAE, 2008) ....................................................................................39
FIGURA 3.15. FLUXO DE EXECUO DE UMA FUNO. (FONTE: SAE, 20008) .......................................................41
FIGURA 3.16. REDE LOCAL BLUETOOTH. (FONTE: BERNAL, 2002) ....................................................................42
FIGURA 3.17. PERIFRICOS BLUETOOTH. (FONTE: BERNAL, 2002)....................................................................43
FIGURA 3.18. APLICAES BLUETOOTH AUTOMOBILSTICAS. (FONTE: BERNAL, 2002) ......................................45
FIGURA 4.1. TOPOLOGIA DO SISTEMA DE MONITORAMENTO VEICULAR...............................................................46
FIGURA 4.2. VECULO VOLKSWAGEN GOL UTILIZADO NO PROJETO. (FONTE: AUTOR) ...........................................47
FIGURA 4.3. PAINEL DE INSTRUMENTOS DO GOL. (FONTE: AUTOR) ......................................................................48

VI

FIGURA 4.4. UCE MOTRONIC MP9.0.................................................................................................................48

FIGURA 4.5. CONECTOR OBDII DO GOL ............................................................................................................49
FIGURA 4.6. INTERFACE VAG-COM. (FONTE: AUTOR).......................................................................................50
FIGURA 4.7. APLICAO VAG-COM (EXIBIO DOS DADOS DE IDENTIFICAO DA UCE). (FONTE: AUTOR) .........51
FIGURA 4.8. APLICAO VAG-COM (VALORES DOS BLOCOS DE DADOS). (FONTE: AUTOR) ..................................51
FIGURA 4.9. HTC TYTNII. (FONTE: HTTP://WWW.ITREVIEWS.CO.UK/HARDWARE/H1387.HTM)............................54
FIGURA 4.10. VISO GERAL DA ORGANIZAO DO SOFTWARE .............................................................................55
FIGURA 4.11. DIAGRAMA DE CLASSE DA APLICAO. (FONTE: AUTOR) ...............................................................56
FIGURA 4.12. DIAGRAMA DE CASO DE USO DA APLICAO. (FONTE: AUTOR) ......................................................58
FIGURA 4.13. DIAGRAMA DE CLASSE DA APLICAO EMBARCADA NO DISPOSITIVO MVEL. (FONTE: AUTOR) .........59
FIGURA 4.14. GUIAS DE APRESENTAO DAS INFORMAES DA APLICAO. (FONTE: AUTOR) ..............................60
FIGURA 4.15. DIAGRAMA DE CASO DE USO (VISO DO SISTEMA). (FONTE: AUTOR) ..............................................61
FIGURA 4.16. DIAGRAMA DE CASO DE USO (VISO DO CONDUTOR). (FONTE: AUTOR)..........................................61
FIGURA 5.1 DADOS BRUTOS RECEBIDOS DA UCE DO VECULO. (FONTE: AUTOR) ..................................................62
FIGURA 5.2. DADOS RECEBIDOS DA UCE TRATADOS. (FONTE: AUTOR) ................................................................63
FIGURA 5.3. EXEMPLO DE CONVERSO DO BLOCO DE IDENTIFICAO. (FONTE: AUTOR) .......................................63
FIGURA 5.4. EXEMPLO DE CONVERSO DO BLOCO DE DADOS DE BORDO. (FONTE: AUTOR)....................................64
FIGURA 5.5. DADOS RECEBIDOS DA UCE TRATADOS COM O MOTOR DO VECULO LIGADO (FONTE: AUTOR) ............64
FIGURA 5.6 DADOS RECEBIDOS PELO DISPOSITIVO MVEL E MOSTRADOS EM APLICAO DO DISPOSITIVO MVEL.
(FONTE: AUTOR) .....................................................................................................................................65
FIGURA 5.7. RESULTADOS OBTIDOS DURANTE OS TESTES. (FONTE: AUTOR) .........................................................67

VII

LISTA DE TABELAS

TABELA 3.1. BYTES-CHAVE. (FONTE: SAE) .......................................................................................................38

TABELA 3.2. ESTRUTURA DO SERVIO. (FONTE: SAE, 2008) ..............................................................................40
TABELA 4.1. FICHA TCNICA DO VECULO. (FONTE:
HTTP://REVISTAAUTOESPORTE.GLOBO.COM/EDITORAGLOBO/COMPONENTES/ARTICLE/EDG_ARTICLE_PRINT/1

,3916,406657-1683-1,00.HTML, COM ADAPTAES) ................................................................................47

TABELA 4.2. ESPECIFICAO DO TYTNII (COM ADAPTAES). (FONTE:
HTTP://WWW.HTC.COM/WWW/PRODUCT /TYTNII/SPECIFICATION.HTML. COM ADAPTAES.) ........................53

TABELA 4.3. CLCULOS DE CONVERSO DAS INFORMAES DE BORDO. (FONTE: AUTOR) .....................................57
TABELA 4.4. BLOCOS DE DADOS E VALORES IDENTIFICADOS. (FONTE: AUTOR) .....................................................57

VIII

LISTA DE EQUAES

EQ. 5. 1. CLCULO DA DISTNCIA PERCORRIDA. (FONTE: AUTOR).......................................................................66

EQ. 5. 2. CLCULO DO VOLUME DE COMBUSTVEL. (FONTE: AUTOR)....................................................................67
EQ. 5. 3. CLCULO DO CONSUMO DE COMBUSTVEL. (FONTE: AUTOR).................................................................67

IX

LISTA DE SMBOLOS E ABREVIATURAS

ASCII: American Standart code for Information

AT: Alto Torque
CAN: Controller Area Network
CARB: California Air Resource Board
CI: Compression Ignition
CI: Circuito Integrado
CONAMA: Conselho Nacional do Meio Ambiente
CTN: Coeficiente de Temperatura Negativo
CTP: Coeficiente de Temperatura Positivo
EGAS: Acelerador Eletrnico
EPA: Federal Environmental Protection Agency
EPROM: Erasable Programmable Read Only Memory
ETX: End of Text
FTDI: Future Technology Devices International Limited
GND: Ground
X

GSM: Global System for Mobile

IEEE: Instituto de Engenheiros Eletricistas e Eletrnicos
ISO: International Organization for Standardization
KW1281: Key Word 1281
MSB: Most Significant Bit
OBD II: On Board Diagnosis II
PMS: Ponto morto superior
PWM: Pulse Width Modulation
RPM: Rotao (es) Por Minuto
SAE: Society of Automotive Engineers
SI: Spark Ignition
SID: Service Identification
SIM: Security Identify Module
TDC: Top Dead Centre,
UCE: Unidade de Controle Eletrnico
USB: Universal Serial Bus
VAG: Volkswagen Audi Group
ZrO: xido de Zircnia

XI

INTRODUO

1.1 Motivao
A tecnologia um fator essencial para a indstria automotiva. O crescente avano
tecnolgico e a converso entre as diferentes tecnologias existentes esto propiciando uma
integrao cada vez maior entre essas tecnologias e os automveis. Hoje, todos os sistemas de
gerenciamento automotivo so eletrnicos, e os sistemas de convenincia e conforto esto
mais amigveis e cada vez mais parecidos com os dispositivos de entretenimento usados em
nosso dia a dia. A tendncia no futuro uma total integrao entre o automvel e as diversas
tecnologias existentes.
Apesar de toda essa integrao tecnolgica, h um grande legado de automveis que
no dispem dela, tendo apenas alguns componentes de gerenciamentos eletrnicos mnimos,
que so exigidos em lei, e nenhum equipamento eletrnico que proporcione alguma
convenincia ou conforto ao motorista.
Analisando esta situao, possvel criar dispositivos para atender esse nicho, atravs
da integrao da tecnologia disponvel com esses automveis, para fornecer servios de alta
tecnologia.
Aproveitando este contexto, o projeto prope a integrao de um automvel com pouca
tecnologia embarcada com a tecnologia atual, para a elaborao de um sistema de
monitoramento do sistema de gerenciamento do motor, que disponibiliza ao usurio,
informaes de bordo e dados da situao do sistema de alimentao do veculo, atravs de um
dispositivo mvel e de uma interface de integrao entre o veculo e a aplicao, composta por
uma interface de conexo e um notebook.
12

1.2 Objetivo Geral

O objetivo deste projeto a elaborao de um sistema computacional auxiliar ao
veculo, formado por uma interface de hardware, um software embarcado em um notebook e
um software em dispositivo mvel, que disponibilize ao motorista diversas informaes de
bordo relativas ao sistema de alimentao do veculo. As informaes obtidas pelo dispositivo
proporcionam ao condutor do veculo um melhor gerenciamento do comportamento do
veculo, contribuindo para a melhoria da dirigibilidade e um melhor acompanhamento das
condies de funcionamento do veculo, reduzindo a necessidade de acompanhamento tcnico
apenas para a identificao de algum defeito no sistema de gerenciamento do motor do
veculo.
O sistema deve receber os dados do sistema de injeo eletrnica do veculo atravs da sua
tomada de diagnstico. A interface trata o sinal de sada da tomada de diagnstico para o
padro serial, e transmite os dados a um notebook, o software embarcado no notebook trata os
dados e gerencia a comunicao com o veculo, e transmite as informaes tratadas ao
dispositivo mvel atravs de uma conexo serial Bluetooth, que por sua vez possui uma
aplicao que interpreta os dados obtidos, e mostra ao condutor do veculo a informao
padronizada para leitura.
O sistema de hardware/software aqui proposto tem escopo acadmico, ou seja, no se
pretende neste projeto desenvolver uma aplicao automotiva comercial. O projeto se aplica a
veculos com sistema de gerenciamento eletrnico do motor, que utilize o protocolo Key Word
1281 e com pouca tecnologia embarcada, no qual se torna til a disponibilizao de
informaes adicionais.

1.3 Objetivos Especficos

Especificamente, o projeto tem como objetivo disponibilizar informaes adicionais sobre
o funcionamento do veculo, a qualquer instante, sem que o motorista necessite de auxilio
tcnico para identificar uma falha no sistema de injeo eletrnica do veculo. Por meio de uma
aplicao em dispositivo mvel e uma interface de integrao entre o veculo e a aplicao,
composta de um software embarcado em um notebook e uma interface de hardware para

13

integrao com o veculo, pretende-se demonstrar atravs do projeto, a leitura dos estados de
funcionamento dos dispositivos do sistema de injeo eletrnica veicular. Espera-se com isto:

Atuar de forma preventiva na manuteno do veculo;

Melhoria da conduo do veculo atravs de novas informaes disponveis;

Economia de combustvel, atravs do monitoramento em tempo real do

funcionamento do sistema de alimentao.

1.4 Justificativa e Relevncia do Tema

Sistemas de monitoramento veicular so ferramentas que propiciam um melhor controle
do comportamento do veculo, atravs da mensurao de valores em tempo real e sua
comparao com os dados esperados, assim possvel aferir o desempenho do automvel e
pode-se indicar algum problema encontrado, e ter um melhor controle sobre a conduo do
veculo.
Nos automveis, sistemas de monitoramento so muito importantes para garantir
seu funcionamento dentro dos padres pr-estabelecidos, que hoje so muito rgidos,
principalmente no que tange emisso de poluentes na atmosfera. Portanto, impossvel
atender esses padres sem ter um monitoramento eletrnico em tempo real do funcionamento
dos sistemas de um automvel.
A utilizao de um sistema de monitoramento veicular que visa informar ao
usurio as informaes de bordo e diagnstico do veculo importante para informar ao
condutor se existe algum problema no funcionamento do veculo, e acionar a manuteno,
caso necessrio. Assim, a assistncia eletro-mecnica torna-se desnecessria para a
identificao de qualquer erro que esteja armazenado na memria do sistema de injeo
eletrnica do veculo, mas vale ressaltar que a atuao na correo do problema continua sob a
responsabilidade das assistncias mecnicas. O projeto visa apenas identificao do erro
armazenado na memria da UCE do veculo e sua disponibilizao ao usurio, em um veculo
que no possui esta funcionalidade.
14

1.5 Escopo do Trabalho

O projeto visa coletar as informaes do sistema de alimentao do veculo atravs da
tomada de diagnstico veicular padro OBDII (On-Board Diagnosis II), tratar o sinal de sada
em um circuito eletrnico (interface), e converter o sinal para o padro serial USB. Esses
dados so transmitidos a um notebook, com uma aplicao que captura as informaes da
tomada de diagnostico, por meio da interface, trata esses dados e envia a informao a um
dispositivo mvel, que mostra ao usurio de uma forma mais amigvel os dados obtidos. O
software embarcado no dispositivo mvel feito de forma evitar ao mximo a perda de
dirigibilidade devido ao manuseio deste equipamento
Assim, o projeto aplica-se aos veculos de passeio que possuem central eletrnica,
interface de diagnstico OBDII, protocolo de comunicao de dados KW1281 (Key Word
1281), e que carecem de informaes de conduo do veculo, s possuem o indicador de
velocidade, temperatura do lquido de arrefecimento do motor, indicador de nvel de
combustvel, indicador de presso do leo do motor e indicador de problema no sistema de
carga do veculo.

1.6 Resultados Esperados

Pretende-se por meio deste projeto implementar em um veculo um sistema de
monitoramento veicular, com a aquisio das informaes da central eletrnica do veculo,
atravs da tomada de diagnstico, e a disponibilizao dessa informao ao condutor do
veculo. Para isso utilizada uma interface de comunicao que trata o sinal para o padro
serial USB. Um notebook recebe a informao atravs da porta USB e uma aplicao trata as
informaes e controla a comunicao. Aps esse processo, a informao transmitida atravs
de conexo Bluetooth para o dispositivo mvel que disponibiliza a informao para o usurio.
Espera-se com isto auxiliar o motorista na manuteno de seu veculo, sendo alertado durante
a execuo do software do sistema sobre a ocorrncia de algum defeito no sistema de
gerenciamento do motor.

15

1.7 Estrutura do Trabalho

Esta monografia est estruturada em seis captulos. O primeiro a Introduo, que trata
da motivao deste projeto, os objetivos gerais e especficos, a justificativa e relevncia do
tema proposto, o escopo do trabalho, os resultados esperados e a estrutura do trabalho.
O segundo captulo, Apresentao do Problema, apresenta com base no problema
identificado a descrio do trabalho, pesquisa e proposta de soluo
No terceiro captulo, Referencial Terico e Bases Metodolgicas, so apresentdas as
metodologias tcnicas e tecnologias e outras ferramentas utilizadas na formao do projeto
proposto. Ele est organizado em temas essenciais que referenciam o projeto final, so eles:
motor de combusto interna; sistema de gerenciamento do motor; diagnose on-board; keyword
protocol 1281, padro ASCII e comunicao Bluetooth.
O quarto captulo, Proposta de Soluo e Modelo, apresenta a topologia do projeto e a
descrio dos seus elementos. Este captulo descreve detalhadamente em seqncia, cada etapa
da implementao do projeto.
No quinto captulo, Aplicao da Soluo com Resultados, feita uma anlise geral dos
resultados obtidos, das dificuldades encontradas e das recomendaes a serem sugeridas para
aplicaes futuras. So apresentados tambm a avaliao global do modelo de sua
aplicabilidade, pontos fortes e fracos, limitaes e resultados mais importantes.
No sexto captulo, apresentada a concluso do trabalho como um todo.

16

APRESENTAO DO PROBLEMA

Existem diversos veculos que no apresentam informaes de bordo ao condutor do

veculo, e quase nenhum veculo informa ao usurio as informaes de diagnstico de forma
completa, que a indicao de qual o componente defeituoso do sistema de alimentao do
veculo. E todos os veculos com sistema de injeo eletrnica de combustvel produzidos no
Brasil e na maior parte do mundo tm, por lei, que possuir a chamada tomada de diagnstico,
que nada mais que uma interface de comunicao entre a UCE (Unidade de Controle
Eletrnico) do Veculo e um dispositivo de diagnstico externo.
Ferramentas de diagnose so fundamentais durante o desenvolvimento de novos veculos e
sistemas eletrnicos, assim como durante a realizao dos procedimentos de reviso e
manuteno. [GUIMARES, 2007]
Segundo publicao da Verso Comunicao (2009), o ndice de manuteno preventiva
do veculo cai de acordo com o aumento da idade do veculo. A Pesquisa revela que em cada
10 veculos com idades entre 10 e 15 anos apenas 4 fazem manuteno preventiva, j os mais
novos, com at dois anos, de 10 veculos 7 vo oficina para receber cuidados preventivos. A
soma dos veculos que no fazem manuteno com idades entre 10 e 15 anos totalizam mais de
5 milhes de unidades, volume superior a frota circulante de automveis dos Estados do Rio
de Janeiro, Minas Gerais e Bahia que equivale a 4,9 milhes.
Essa constatao preocupante, pois com o uso e o aumento da idade, h um desgaste
natural das peas que precisam ser repostas por outras de qualidade, conforme recomenda o
manual do fabricante para garantir as boas condies do veculo. O motorista brasileiro ainda
no tem o hbito de cuidar preventivamente de seu veculo, muitas vezes, isso acontece por
falta de informao sobre o assunto. [BENTO, 2009]
17

Com base nas informaes citadas acima de extrema importncia que o veculo esteja
funcionando de acordo com os padres estabelecidos pelo fabricante, isso garante que no
sejam emitidos poluentes atmosfera alm do estabelecido e a minimizao dos acidentes
devido a alguma falha no veculo.
Como foi citado, a divulgao das informaes de diagnstico e de bordo ao condutor do
veculo fundamental para que o mesmo tenha conscincia do real funcionamento do veculo e
realize as manutenes preventivas/corretivas de forma correta.
Nos veculos com idade entre 10 e 15 anos, as informaes de bordo e diagnstico em sua
maioria, no so informadas de forma completa. Vem-se muitos veculos com apenas os
indicadores bsicos de velocidade, nvel de combustvel, indicadores de presso do leo do
motor e indicador de temperatura do lquido de arrefecimento, e que no possui nenhum
indicador de diagnostico que informe algum problema no sistema de injeo eletrnica do
veculo.
Para adquirir informaes adicionais nesses veculos, ou o condutor procura a assistncia
tcnica para obter essas informaes pontualmente, ou adquire produtos de informao de
bordo adicionais como conta-giros, manmetro, voltmetro. Um desses equipamentos
exemplificado na figura 2.1.

Figura 2.1. Conta Giros veicular. (Fonte: http://www.americanas.com.br/AcomProd/17278/247751)

Para as informaes de diagnstico, so oferecidos no mercado os testers ou scanners,

como o apresentado na figura 2.2, que so vendidos para assistncias mecnicas e tm o
objetivo de identificar falhas no sistema de alimentao do veculo. Estes equipamentos por sua
especificidade possuem o preo bastante elevado.

18

Figura 2.2. Equipamento de Diagnstico (tester) multimarca. (Fonte:

http://www.deltaferramentas.com.br/loja/produtos_descricao.asp?popupAddCarrinho=S&codigo_produt
o=33)

Para a minimizao deste problema o projeto visa a elaborao de um sistema de

hardware/software, embarcado ao veculo que utilize as informaes da tomada de diagnstico
do veculo para disponibilizar ao usurio as informaes de conduo do veculo e as
informaes de diagnstico.
O sistema proposto se comunica com o veculo atravs da porta de diagnstico do
veculo. Para isso necessrio o entendimento do protocolo de comunicao kw1281, para
poder estabelecer conexo com a UCE do veculo e adquirir as informaes de bordo e
diagnstico.
Todo controle da comunicao fica a cargo do software embarcado no notebook, o
software tem a funo de adquirir as informaes do veculo, tratar essas informaes e
transmitir essas informaes ao usurio por meio de uma conexo Bluetooth. O dispositivo
mvel possui uma aplicao que mostra ao condutor a informao padronizada de forma
apropriada, minimizando a perda de dirigibilidade do condutor ao manipular este sistema.
Dessa forma, o condutor tem a sua disposio informaes adicionais que proporcionam
uma melhor viso do comportamento do veculo, podendo-se assim, conduzir o veculo de
uma forma mais racional. Tambm possvel verificar se existe alguma avaria no sistema de
injeo eletrnica do veculo, contribuindo para uma melhor manuteno do veculo.

19

REFERENCIAL TERICO

3.1 Motor de Combusto Interna

O Motor de combusto interna a fonte de energia usada com mais freqncia em
veculos automotores. Os motores de combusto interna geram energia atravs da converso
de energia qumica contida no combustvel em calor e o calor assim produzido, em trabalho
mecnico. A converso de energia qumica em calor realizada atravs de combusto,
enquanto a converso subsequente em trabalho mecnico realizada permitindo-se que a
energia do calor aumente a presso dentro de um meio, que ento realiza trabalho medida
que se expande. [BOSCH, 2005]
Segundo Stone (1999, traduo nossa), os dois principais tipos de motores de combusto
interna so: ignio por centelha (SI-Spark Ignition), onde a combusto iniciada por uma
centelha; e ignio por compresso (CI - Compression Ignition), onde o aumento da
temperatura e presso durante o processo de compresso suficiente para causar a combusto
espontnea do combustvel. O motor de ignio por centelha conhecido como o motor a
gasolina, a lcool ou a gs, que so os combustveis tpicos desse tipo de motor. O motor de
ignio por compresso conhecido como motor a diesel, por causa de seu combustvel
utilizado.
Segundo Stone (1999, traduo nossa) ambos os tipos de motores tem quatro ciclos de
operao, esse processo conhecido como ciclo Otto, e o que determina o funcionamento
do motor. Conforme a figura 3.1, os quatro ciclos de operao do motor so:

Admisso: Processo onde a vlvula de admisso se abre, e o pisto do cilindro

desce, enchendo-o com a mistura de ar e combustvel;
20

Compresso: Ambas as vlvulas esto fechadas, e o pisto move-se em direo

ao topo do cilindro. Como o pisto se aproxima do ponto mximo do cilindro
(PMS Ponto morto superior), a combusto ocorre;

Expanso: A combusto aumenta a temperatura e presso dentro do cilindro, e

fora o pisto para baixo. Este o processo onde o trabalho que movimentar o
veculo gerado.

Exausto ou escape: A vlvula de escape abre, e os gases resultantes da queima

da mistura ar combustvel so exauridos do interior do cilindro para o meio
externo.

Figura 3.1. As quatro fases do ciclo otto em um motor de combusto interna. (Fonte:
www.mecanica.ufrgs.br/mmotor/4tempos.jpg)

21

3.2 Sistema de Gerenciamento do Motor

3.2.1

Introduo

O gerenciamento do motor se encarrega de converter o desejo do motorista, p. ex.,

acelerao para uma determinada potncia do motor Otto. Ele regula todas as funes do
motor de tal maneira que o torque desejado esteja disponvel com o consumo e emisses
reduzidas. [BOSCH, 2005]
A funo principal do gerenciamento de motor coordenar os diversos sistemas parciais,
para ajustar o torque gerado pelo motor e satisfazer ao mesmo tempo as altas exigncias
quanto a: [BOSCH, 2005]

Emisso de gases de escape;

Consumo de combustvel;

Potncia;

Conforto;

Segurana;

3.2.2

Sensores

3.2.2.1

Sensor de Concentrao de Oxignio (Sensor Lambda de

Oxignio)
O sistema medidor de combustvel emprega o contedo residual do oxignio no
escapamento, conforme medido pelo sensor lambda de oxignio para regular bem precisamente
a mistura ar/combustvel para combusto, ao valor lambda ( ) 1 . [BOSCH, 2005]

22

O sensor um eletrlito em estado slido, feito de material cermico ZrO (xido de

Zircnia). Sob altas temperaturas, esse eletrlito torna-se condutor e gera uma carga galvnica
caracterstica nas conexes do sensor. Essa tenso um ndice do contedo do oxignio no
gs. A variao mxima ocorre em =1. [BOSCH 2005].
Para o tratamento cataltico do gs de escape por um catalisador de trs vias
imprescindvel a manuteno exata de =1 com o motor aquecido. Para conseguir isso,
necessrio determinar exatamente a massa de ar admitido e adicionar uma quantidade de
combustvel exatamente dosada. Pode-se observar na figura 3.2 o tpico fucionamento do
sensor de oxignio. [BOSCH 2005]

Figura 3.2. Sensor de Oxignio. (Fonte: BOSCH, 2005)

3.2.2.2

Medidor de Massa de Ar

Medidores de massa de ar funcionam de acordo com o princpio de filme ou fio aquecido;

a unidade no contm partes mecnicas mveis. Conforme a figura 3.3, o circuito de controle
em malha fechada no alojamento do medidor mantm um diferencial constante de temperatura
entre um fino fio de platina ou resistor de filme fino e a corrente de ar que passa. A corrente
exigida para o aquecimento fornece um ndice extremamente preciso, embora no linear de
taxa de fluxo de massa de ar. Geralmente o sistema UCE converte os sinais na forma linear e
assume outras tarefas de avaliao de sinal. [BOSCH, 2005]

23

Figura 3.3. Medidores de massa de ar. (Fonte: BOSCH, 2005)

3.2.2.3

Sensor de Temperatura

Medies de temperatura em veculos a motor so realizadas pela explorao da

sensibilidade variao de temperatura, encontrada na resistncia eltrica dos materiais com
coeficiente de temperatura positivo (CTP) ou negativo (CTN), como termmetros de contato.
Conforme a figura 3.4, a converso da variao de resistncia em tenso analgica
predominantemente desempenhada com a ajuda de resistores neutros de temperatura
complementares ou inversamente sensveis, como divisores de tenso (tambm fornecendo
linearidade aumentada). [BOSCH, 2005]

Figura 3.4. Sensor de Temperatura. (Fonte: BOSCH, 2005)

24

3.2.2.4

Sensores de Velocidade e RPM

Medies so basicamente tomadas com a ajuda de um sistema incrementado de sensor, e

consistem de engrenagem e sensor de velocidade rotativa. [BOSCH, 2005].
O sensor indutivo consiste de um m de barra, com um pino ferromagntico, sustentando
uma bobina de induo com dois terminais, como pode ser visto na figura 3.5. Quando uma
engrenagem de anel ferromagntico (ou rotor de projeo semelhante) passa por este sensor,
gera uma tenso na bobina, tenso esta diretamente proporcional variao peridica no fluxo
magntico. Um padro uniforme de dentes gera uma curva de tenso quase senoidal. A
velocidade rotativa reflete-se no intervalo peridico entre os pontos de transio por zero da
tenso, ao passo que a amplitude tambm proporcional velocidade rotativa. [BOSCH,
2005]

Figura 3.5. Sensor do tipo indutivo (esquerda) e sensor hall (direita). (Fonte: BOSCH, 2005)

25

3.2.3

Atuadores
Atuadores (elementos finais de controle) formam uma interface entre o processador de

sinal eletrnico (processamento de dados) e o processo real (movimento mecnico).

Convertem sinais de baixa potncia que transmitem informao sobre posicionamento em
sinais operacionais de um nvel de energia adequado ao controle do processo. Os
conversores de sinais so combinados com elementos amplificadores para explorar os
princpios de transformao fsica que regulam as inter-relaes entre as vrias formas de
energia (eltrica-mecnica-fluda-trmica). [BOSCH, 2005]

3.2.3.1

Vlvula Injetora para Injeo no Coletor de Admisso

As vlvulas injetoras consistem principalmente de: [BOSCH, 2005]

Uma carcaa da vlvula com bobina magntica e conexo eltrica;

Um assento de vlvula com placa de furos;

Uma vlvula de agulha mvel com induzido magntico.

Figura 3.6. Vlvula injetora de combustvel. (Fonte: BOSCH, 2005)

26

Conforme a figura 3.6, uma peneira de filtro na entrada do combustvel protege a vlvula
injetora de impurezas. Dois anis (O-ring) vedam a vlvula contra a galeria de combustvel e o
coletor de admisso. No caso de bobina sem corrente, as molas e a fora resultante da presso
do combustvel pressionam a agulha da vlvula sobre o assento da vlvula e vedam o sistema
de alimentao de combustvel contra o coletor de admisso. [BOSCH, 2005]
Quando a vlvula injetora alimentada, a bobina produz um campo magntico. O induzido
atrado pelo campo magntico, a agulha da vlvula se levanta do assento e o combustvel flui
atravs da vlvula injetora. [BOSCH, 2005]
O volume de combustvel injetado por unidade de tempo determinado principalmente
pela presso do sistema e do dimetro livre dos furos de injeo na placa. Quando a corrente
de excitao desativada, a agulha da vlvula fecha novamente. [BOSCH, 2005]

3.2.3.2

Borboleta de Acelerao

O elemento atuador central para a influncia do fluxo de massa de ar a borboleta de

acelerao. Quando a borboleta de acelerao no est totalmente aberta, o ar aspirado pelo
motor estrangulado e o torque produzido reduzido. Esse efeito estrangulador depende da
posio e, portanto, do dimetro da abertura da borboleta de acelerao, bem como da rotao
do motor. Com a borboleta de acelerao totalmente aberta atingido o torque mximo do
motor. [BOSCH, 2005]
Conforme a figura 3.7, em sistemas com acelerador eletrnico EGAS determinado, a
partir do torque desejado do motor (posio do pedal do acelerador), o enchimento de ar
necessrio para isso e ento aberta a borboleta de acelerao. [BOSCH, 2005]

27

Figura 3.7. Sistema EGAS

Em sistemas convencionais, o motorista comanda diretamente a abertura da borboleta de

acelerao atravs do acionamento do pedal do acelerador. [BOSCH, 2005]

3.2.3.3

Bomba eltrica de combustvel

A bomba eltrica de combustvel deve disponibilizar ao motor, sob todas as condies

operacionais, a quantidade suficiente de combustvel com a presso necessria para a injeo.
Os componentes da bomba de combustvel so apresentados na figura 3.8. [BOSCH, 2005]
As principais exigncias so: [BOSCH, 2005]

Vazo entre 60 e 250 l/h com tenso normal;

Presso no sistema de combustvel entre 300 e 650 KPa

Aumento da presso a partir de 50..60% da tenso nominal: determinante para isso

o funcionamento na partida a frio.

28

Figura 3.8. Bomba de Combustvel. (Fonte: BOSCH, 2005)

3.2.4

Mdulos Eletrnicos

Os mdulos eletrnicos so os dispositivos responsveis pela leitura das entradas,

acionamento das sadas e pelo gerenciamento do funcionamento dos protocolos de
comunicao utilizados nos veculos. [GUIMARES, 2007]
Um mdulo eletrnico automotivo como um computador. Possui internamente uma
placa de circuito impresso com um microprocessador ou microcontrolador e um programa
gravado em uma memria, isso pode ser observado na figura 3.9. Em funo do estado das
entradas conectadas ao mdulo, o software decide o que realizar com as sadas.
[GUIMARES, 2007]
Existem vrios tipos de mdulos de controle, basicamente diferenciados pelas funes
realizadas e pelas suas caractersticas tcnicas, especialmente em relao ao software.
[GUIMARES, 2007]

29

3.2.4.1

Conceituao Tcnica

uP/uC = Microcontrolador ou microprocessador: o crebro do mdulo eletrnico,

responsvel pela execuo dos programas e pelo processamento e controle das atividades do
mdulo.
Mem = memria: armazena o programa do mdulo eletrnico. No geral, o tipo PROM
ou Flash. O primeiro caso caracterizado por programa j gravado do fornecedor e no pode
mais ser alterado (processo conhecido como mascaramento). O segundo caso caracterizado
por permitir a troca do programa do mdulo a qualquer momento, procedimento comumente
utilizado em algumas aplicaes ou situaes especiais, que necessitam da atualizao da
verso do programa. [GUIMARES, 2007]
Entradas: Porta de entrada dos sinais digitais e/ou analgicos medidos pelos transdutores
(sensores). [GUIMARES, 2007]
Sadas: porta de sada dos sinais digitais e/ou analgicos controlados pelo mdulo
eletrnico. [GUIMARES, 2007]

Figura 3.9. Diagrama de bloco de uma UCE. (Fonte: GUIMARES, 2007)

30

3.2.5

Gerenciamento de Motor Motronic

Motronic o nome dado pela Bosch para sistemas de controle e regulagem do motor
Otto. Originalmente a Motronic tinha a funo bsica de combinar a injeo eletrnica com
uma ignio eletrnica em uma unidade de comando. Gradualmente foram adicionadas mais
funes que se fizeram necessrias em funo das exigncias das leis para reduo de emisso
de gs de escape, reduo do consumo de combustvel, aumento da demanda de potncia,
conforto e segurana ao dirigir. [BOSCH, 2005]
Uma outra funo importante da Motronic a monitorao da funcionalidade do sistema
geral de diagnstico on board (OBD). Atravs das exigncias legais so impostas exigncias
a Motronic, que resulta em torno da metade da capacidade do sistema Motronic (em termos de
poder de computao e necessidade de memria) seja dedicada ao diagnstico. [BOSCH
2005]
O sistema Motronic contm todos os sensores para detectar os dados operacionais do
motor e do veculo, bem como todos os atuadores para executar as intervenes de ajuste no
motor Otto. A unidade de comando usa os dados dos sensores para captar o estado do motor e
do veculo em intervalos muito curtos (a faixa de milissegundos para atender as exigncias em
tempo real do sistema). Circuitos de entrada suprimem as interferncias dos sinais dos sensores
e os colocam em uma faixa de tenso uniforme. Um conversor analgico-digital transforma
ento os sinais preparados em valores digitais. Outros sinais so captados atravs das
interfaces digitais (p. ex. Bus CAN) ou interfaces moduladas por largura de pulso (PWM
Pulse Width Modulation). [BOSCH, 2005]
A parte central da unidade de comando do motor um microcontrolador com a memria
de programa (EPROM ou flash), na qual esto armazenados todos os algoritmos de comando
de operaes so clculos baseados num determinado esquema e dados (parmetros,
curvas caractersticas, mapas caractersticos). As grandezas de entrada derivadas dos sinais dos
sensores influenciam os clculos nos algoritmos e com isso os sinais de comando para os
atuadores. O microcontrolador reconhece baseados nesses sinais de entrada, a reao do
veculo desejada pelo motorista e calcula a partir disso: [BOSCH, 2005]

O torque necessrio;

31

O enchimento dos cilindros resultantes e a respectiva quantidade injetada;

A ignio no tempo certo;

Os sinais de comando para os atuadores, p. ex. do sistema de reteno de

evaporao de combustvel, do turbo compressor do gs de escape, do sistema de
ar secundrio

Os dados do sinal de baixo nvel disponveis nas sadas do microcontrolador so adaptados

pelos estgios de sada de potncia aos nveis necessrios para os respectivos atuadores
[BOSCH, 2005].
A M-Motronic abrange todos os componentes necessrios para o controle de um motor
com injeo no coletor de admisso e borboleta de acelerao convencional [BOSCH, 2005].
O motorista ajusta o fluxo de massa de ar e com isso o torque diretamente atravs do
pedal do acelerador e da borboleta aceleradora. A Motronic adapta a necessidade de ar, p. ex.
com baixa temperatura do motor ou para regulagem de marcha lenta usando o atuador de ar
bypass. A partir da corrente de massa de ar aspirada, captada com a ajuda de sensores de carga
(p. ex. medidor de massa de ar, sensor de presso do coletor de admisso), a M-Motronic
calcula a massa de combustvel necessria, bem como o melhor ponto de ignio possvel para
o ponto de funcionamento ajustado. Um funcionamento otimizado do motor consegue-se com
a ativao das vlvulas de injeo e bobinas de ignio no tempo certo [BOSCH 2005].

3.3 Diagnose On-Board (On Board Diagnostic OBD)

O termo diagnose veicular (ou diagnstico veicular) representa as funes ou ferramentas
que permitem a programao ou verificao do funcionamento de cada mdulo eletrnico
existente em um veculo. Com o aumento da eletrnica embarcada, passa a ser mandatrio o
desenvolvimento de dispositivos que, por exemplo, permitam o diagnstico de falhas eventuais
dos sistemas. [GUIMARES, 2007]
Considerando esta necessidade, podemos classificar as falhas em duas categorias: as
possveis de serem identificadas pelo motorista e as identificadas somente com o auxlio de
ferramentas especiais. A primeira chamada de On-Board Diagnosis (OBD) e realizada por
32

meio de avisos sonoros e lmpadas especficas existentes no painel de instrumentos. A segunda

pode ser chamada de Off-Board Diagnosis e realizada pelos chamados Testers, dispositivos
eletrnicos capazes de se comunicar com os mdulos do veculo sistemas. [GUIMARES,
2007]
Segundo KIENCKE e NIELSEN (2005, traduo nossa), diagnsticos de motores
automotivos tm uma longa histria. Desde o primeiro motor automotivo do sculo XIV, era
necessrio encontrar defeitos nos motores. Por um longo tempo, os diagnsticos eram
realizados manualmente, mas ferramentas de diagnstico comearam a aparecer na metade do
sculo XX. Um exemplo o estroboscpio que usado para determinar o tempo de ignio.
Na dcada de 60, a mensurao do sistema de escape se tornou uma forma comum de se
diagnosticar o sistema de combustvel. At 1980 todos diagnsticos eram feitos manualmente e
de forma off-board. Foi nessa poca que a eletrnica e os microprocessadores gradualmente
foram introduzidos nos carros. Essa abertura possibilitou o uso do diagnstico on-board. O
objetivo foi criar uma forma fcil de encontrar falhas.
Pode-se definir a diagnose on-board, basicamente, como a leitura das falhas dos sistemas
do veculo por meio do painel de instrumentos. [GUIMARES, 2007]
Entre os diversos objetivos procurados pela diagnose on-board, destacam-se aqueles
ligados diretamente ao motorista ou ao condutor do veculo, como por exemplo:
[GUIMARES, 2007]

Alertar o motorista sobre o funcionamento inadequado dos sistemas, mesmo no

havendo um sintoma de anomalia perceptvel;

Facilitar ao motorista a identificao de falhas em caso de pane do veculo;

Auxiliar o motorista quanto correta utilizao dos diversos sistemas (mecnicos e

eletroeletrnicos) do veculo;

Dentre os principais desafios que se apresentam para que um sistema de diagnose onboard possa ser considerado eficaz, destacam-se: [GUIMARES, 2007]

Fcil acesso s informaes;

33

Fcil interpretao das informaes, no deixando dvidas;

No transmitir alerta maior (ou menor) que o necessrio.

Logicamente, um sistema de diagnose on-board que vise o desempenho timo deve ser
projetado em funo do conhecimento e at mesmo da cultura de quem opera o veculo.
Portanto, fornecer informaes insuficientes ou em demasia tambm uma questo de ponto
de vista, intrinsecamente ligada formao (tcnica e cultural) do condutor do veculo. No
caso de veculos comerciais que operam em frotas, podem-se minimizar esses efeitos por meio
de treinamento dos operadores e motoristas. [GUIMARES, 2007]
importante adicionar que, quando analisamos a evoluo da eletrnica embarcada nos
veculos e a evoluo dos sistemas de diagnose on-board, notamos que ambas esto
intimamente relacionadas. O conceito de diagnose on-board foi fundamental para o avano
tecnolgico que vemos atualmente nos veculos. [GUIMARES, 2007]
O componente que mais contribui para a modalidade de diagnstico embarcado o painel
de instrumentos (cluster). [GUIMARES, 2007]
Do final de 1920 at o final de 1950, a instrumentao bsica dos veculos era composta
por velocmetro, indicador de presso do leo, temperatura do lquido de arrefecimento do
motor e do indicador do nvel de combustvel. De fato, em muitos veculos, nenhum desses
instrumentos possua, necessariamente, caractersticas eltricas, e alguns deles foram
simplesmente substitudos por lmpadas de alarme, em veculos de menor preo e de produo
em grande escala. [GUIMARES, 2007]
A partir do ano de 1970 teve incio a instrumentao eletrnica propriamente dita,
ampliando sua funo dentro do sistema veicular como um todo. Dentre as funes do painel
de instrumentos adicionadas, podemos citar: [GUIMARES, 2007]

Indicador de informaes e alertas;

Gerenciador dos diversos sistemas eletrnicos;

Provedor de informaes de conduo tima do veculo;

34

Apresentador de dados relativos diagnose dos diversos sistemas

eletrnicos veiculares;

Aquisitor de dados de conduo, para melhor gerenciamento de frota,

entre outras.

Todas essas funes esto relacionadas diagnose on-board, deixando clara a importncia
do painel de instrumentos na estratgia de diagnstico.
Segundo KIENCKE e NIELSEN (2005, traduo nossa), em 1988, a primeira
regulamentao legal em relao ao diagnstico on-board, OBD, foi introduzida pelo CARB
California Air Resource Board, inicialmente essa regulamentao foi aplicada somente na
Califrnia, mas o Federal Environmental Protection Agency (EPA) adotou uma
regulamentao similar e a aplicou em todo o Estados Unidos. Isso forou a indstria a
introduzir mais e mais capacidade nos diagnsticos on-board dos veculos. Em 1994, uma nova
e mais rigorosa regulamentao, a OBDII foi aplicada na Califrnia. Hoje o padro OBDII est
na maioria dos sistemas de gerenciamento do motor. Seguindo o exemplo da Califrnia e dos
Estados Unidos, esse tipo de legislao tem sido aplicada em diversos outros pases. O
conector padro pode ser observado na figura 3.10.

Figura 3.10 Conector padro OBD II (com adaptaes). (Fonte:

http://www.obdii.com/connector.html#dates)

De acordo com o pargrafo 1, do artigo 13 da lei n 8.723, de 28 de outubro de 1993,

Os fabricantes de veculos automotores ficam obrigados a divulgar s concessionrias e
distribuidores as especificaes e informaes tcnicas necessrias ao diagnstico e regulagem
do motor, seus componentes principais e sistemas de controle de emisso de poluentes.
Considerando que a Resoluo CONAMA (Conselho Nacional do Meio Ambiente) n
315, de 2002, estabelece a utilizao de Sistemas de Diagnose de Bordo OBD por
35

constiturem tecnologia de ao comprovada na identificao de mau funcionamento dos

sistemas de controle de emisso possibilitando a antecipao de medidas corretivas e a
consequente preveno no aumento da emisso de poluentes atmosfricos. [RESOLUO
CONAMA n 354, de 13 de dezembro de 2004]
Considerando que a adoo do OBD nos veculos automotores representa expressivo
avano tecnolgico que possibilita ao usurio do veculo prevenir a ocorrncia de danos
severos aos sistemas de controle de emisso, contribuindo para a melhoria da qualidade
ambiental, e dessa forma salvaguardar os interesses do consumidor e da sociedade em geral.
[RESOLUO CONAMA n 354, de 13 de dezembro de 2004]

3.4 Key Word Protocol 1281

Segundo a SAE Society of Automotive Engineers (2008, traduo nossa), o Key Word
Protocol 1281 um protocolo de comunicao de diagnstico proprietrio do grupo
Volkswagen. O protocolo kw1281 necessita uma linha de comunicao bidirecional com o
dispositivo externo, essa linha de comunicao conhecida como K Line. Este canal de
comunicao pode ser utilizado por diversas Unidades de controle do veculo.

3.4.1

Inicializao

Segundo a SAE, a UCE kw1281 selecionada de todas as UCEs conectadas a k line por
uma comunicao da ferramenta de diagnstico (Scan Tool). Essa comunicao d-se com o
envio pela ferramenta de diagnstico do endereo da UCE kw1281.
Segundo a SAE, com o intuito de acessar o modo de diagnstico, uma palavra com o
endereo da UCE deve ser transmitida por meio da K line. A palavra com o endereo usado
para simulao deve ser transmitida no formato de 10 bits, sob uma taxa de transferncia de 5
baud, com variao de at de 1%.
Segundo a SAE, a palavra com o endereo dever ser composta, como descreve a figura
3.11, e na mesma sequncia:

36

Figura 3.11. Inicializao da UCE. (Fonte: SAE, 2008)

3.4.2

Byte de Sincronizao

Segundo a SAE, a comunicao deste protocolo baseada nas especificaes ISO 9141 e
ISO 14230-2.
Segundo a SAE, depois que a UCE recebeu o bit de stop na palavra com o endereo
identificado como sendo o prprio endereo da UCE, aguardado pelo perodo de 1 bit para
que a ferramenta de diagnstico possa se preparar para a comunicao subsequente.
Segundo a SAE, depois de aguardar o tempo, a UCE reage com o envio do byte de
sincronizao pela k line. O byte de sincronizao segue a seguinte estrutura, apresentada na
figura 3.12:

Figura 3.12. Byte de sincronizao. (Fonte: SAE, 2008)

37

Segundo a SAE, o byte de sincronizao transmitido com a mesma taxa de sinalizao

que usada pela transferncia subseqente. A taxa de sinalizao no deve ser diferente de
10400 baud, com variao de 1%.

3.4.3

Keyword
Segundo a SAE, dois bytes chave so transmitidos depois do byte de sincronizao.

As palavras tm a seguinte estrutura:

Tabela 3.1. Bytes-chave. (Fonte: SAE)

1 start bit

(logical 0, low potencial, reaction of UCE to 1-0 transition)

7 key data bits

1 parity bit

(parity odd)

1 stop bit

(logical 1, high potencial)

Estes bytes-chave devem ser considerados como pertencentes a uma informao de 14

bits, nessa informao o byte menos significativo 0x01 transmitido primeiro, seguido pelo
byte mais significativo 0x8A como apresentado na figura 3.13.

Figura 3.13. Bytes chave. (Fonte: SAE, 2008)

38

Segundo a SAE, depois da transmisso do segundo byte-chave, a UCE aguarda o envio

do complemento do segundo byte-chave pela ferramenta de diagnstico como confirmao
da efetivao da transmisso. Nessa transmisso a ferramenta de diagnstico deve observar
o intervalo de 25 ms antes de enviar o complemento. Este intervalo tem a finalidade de
permitir que a UCE tenha tempo suficiente para mudar para o modo de recebimento.
Segundo a SAE, concludo este processo de comunicao, a UCE transmite o primeiro
byte do servio de identificao da UCE.

3.4.4

Formato do Byte de Dados

Segundo a SAE, durante a comunicao, a ferramenta de diagnstico e a UCE deve

operar com o seguinte formato de byte de dados, de acordo com a figura 3.14:

Figura 3.14. Formato do dado. (Fonte: SAE, 2008)

3.4.5

Estrutura de Servio

Segundo a SAE, as informaes que so trocadas entre a ferramenta de diagnstico e a

UCE esto organizada em servios. Um servio deve ser combinado de vrias mensagens.
Todas as mensagens devem ter a mesma estrutura. Cada mensagem consiste de um byte, no
qual o tamanho da mensagem transmitido, um contador da mensagem, a identificao do
servio (SID Service Identification), mensagem especfica e o fim da mensagem. Na figura
3.2 apresentada a estrutura do servio.

39

Tabela 3.2. Estrutura do servio. (Fonte: SAE, 2008)

3.4.5.1

Tamanho da Mensagem

Segundo a SAE, o byte do tamanho da mensagem especifica o nmero de bytes

subseqentes que compe a mensagem.

3.4.5.2

Contador da Mensagem

Segundo a SAE, a primeira mensagem transmitida ( a primeira mensagem de

identificao da UCE) tem o contador de mensagem com o valor 1. O valor do contador de
mensagem incrementado a cada mensagem transmitida, este valor varia de 0 a 255. Duas
mensagens transmitidas em subseqncia devero sempre ter direes diferentes de
transmisso. O contador de mensagem dever sempre ser um valor par quando for enviado
pela ferramenta de diagnstico, e um valor par, quando enviado pela UCE.

3.4.5.3

Identificao do Servio

Segundo a SAE, a identificao do servio o terceiro byte a ser transmitido. Ele fornece
a informao do servio dos quais esto sendo enviados a informao ou servio requisitado.

3.4.5.4

Bytes Especficos da Mensagem

Segundo a SAE, bytes especficos da mensagem so necessrios se outra informao

solicitada em adio identificao do UCE.

40

3.4.5.5

Byte do Fim da Mensagem

Segundo a SAE, o ltimo byte da mensagem o byte do fim da mensagem. O byte sempre
tem algum contedo, normalmente o caractere ASCII ETX (End of Text), na qual
transmitida com o MSB (Most Significant Bit) =0, portanto, representa o nmero 0x03. A
razo para isto que somente o ltimo byte no salvaguardado por um handshake. O
receptor dever checar o ltimo byte para estabelecer se o mesmo contm o valor ETX com
base no tamanho da mensagem recebida. Abaixo, a figura 3.15 exemplifica o fluxo de execuo
de uma funo.

Figura 3.15. Fluxo de execuo de uma funo. (Fonte: SAE, 20008)

3.5 Padro ASCII

O American Standart code for Information Interchange ou ASCII atribui valores de 0
a 255 para letras maisculas, minsculas, dgitos numricos, marcas de pontuao e outros
smbolos. Caracteres ASCII podem ser divididos dentro das seguintes sees: [COZENS e
WAINWRIGHT, 2000]

41

0 31: Cdigos de controle;

32 127: Padro, implementao de caracteres independentes;

128 255: Smbolos especiais, conjunto de caracteres internacionais

3.6 Bluetooth
Bluetooth uma tecnologia destinada a servir como padro universal de conexo entre
equipamentos, ou entre equipamentos e seus perifricos por meio de uma faixa limitada de
rdio. Os perifricos interconectados podem ser desde terminais mveis, impressoras,
organizaes pessoais, notebooks, computadores pessoais, bem como qualquer tipo de
equipamento eletrnico, como mquinas de caf, relgios eletrnicos, terminais de pedgio
e caixas automticos, brinquedos de crianas, sistemas de reproduo de som domestico de
alta fidelidade, entre outros. Alguns destes perifricos podem ser vistos na figura 3.16 e
3.17. [BERNAL, 2002]

Figura 3.16. Rede local Bluetooth. (Fonte: BERNAL, 2002)

Foi escolhido o nome Bluetooth para esse padro em homenagem ao rei medieval
dinamarqus Harald Blaatand II ou Bluetooth (940-981). Esse rei se tornou notvel por sua
luta para unificar a Dinamarca e a Sucia, da mesma forma como os engenheiros modernos
42

passaram a lutar pela padronizao internacional do Bluetooth, inicialmente foram cinco

companhias promotoras do projeto: Ericsson, IBM, Intel, Nokia e Toshiba. Posteriormente,
juntou-se ao grupo a 3Com, Lucent, Microsoft e Motorola. Mais tarde outras 2.164
empresas e entidades passaram a integrar o grupo consorciado. [BERNAL, 2002]
Um trabalho conjunto com o IEEE (Instituto de Engenheiros Eletricistas e Eletrnicos)
802 formou o grupo 802.15.

Figura 3.17. Perifricos Bluetooth. (Fonte: BERNAL, 2002)

O sistema Bluetooth baseia-se em processos de comunicao, controlados por

protocolos, que so transportados pelas interfaces areas. As reas de cobertura dos
dispositivos Bluetooth so separadas em conjuntos de at oito dispositivos prximos que
compem uma pico net. Um dos dispositivos do conjunto pico net definido como
mestre e prov sinal de relgio como referncia e a seqncia de saltos hop de dados
para sincronizar as comunicaes entre todos os membros da pico net. [BERNAL, 2002]
As aplicaes potenciais para as redes Bluetooth so inmeras. Aparelhos de som
podem ser integrados via canal Bluetooth com o fone de ouvido do usurio, aparelhos de
medio sendo calibrados automaticamente pelas informaes providas pelos servidores,
informaes

sobre

pacientes

internados

em

hospitais

podem

ser

transmitidas
43

ininterruptamente para mdicos e enfermeiros, portando em seus cintos terminais mveis,

bem como garons podem anotar pedidos que sero transmitidos diretamente para os
servidores de controle de produo, suprimentos e cobrana dos restaurantes mais
automatizados. [BERNAL, 2002]

3.6.1

O Uso de Sistemas Bluetooth em Embarcaes Automotivas

Estender as funcionalidades do carro;

Proporcionar uma interface homem-mquina, permitindo aos usurios operarem

dentro de carros terminais celulares, rdios, fones de ouvido e outros dispositivos
de forma hands free. Permitir o uso de cartes inteligentes SIM do tipo usado
nos terminais GSM;

Os dispositivos portteis podem exportar sua interface com o usurio para o carro;

Personalizar a interao e as reaes dos dispositivos do veculo, tais como: rdio

e celulares. O prprio controle remoto de abertura das portas e desligamento do
sistema de alarmes pode ser controlado por meio de comunicao Bluetooth e
cdigos de segurana;

Acesso a posicionamento de veculos por meio de localizao por sensoriamento

Bluetooth;

Possibilidade de interao entre o terminal celular e os dispositivos internos do

veculo;

Diagnstico e programao de dispositivos internos por meio de interao com

gigas de teste, diagnstico e programao, localizados em oficinas, centros
automotivos e pontos de acesso fixados pelos fabricantes;

Os carros embutiro dispositivos de integrao com os dispositivos portados

internamente pelos usurios do automvel, bem como trocaro informaes com
dispositivos externos, localizados pelas vias nas quais transitaro os veculos.

44

Conforme a figura3.18, exemplificado um exemplo de aplicao automotiva que utiliza a

o padro de comunicao bluetooth

Figura 3.18. Aplicaes Bluetooth automobilsticas. (Fonte: BERNAL, 2002)

45

PROPOSTA E SOLUO DO MODELO

O projeto aqui proposto tem o objetivo de mostrar ao condutor do veculo

informaes referentes ao funcionamento do sistema de gerenciamento do motor do
veculo. A apresentao dessas informaes pretende propiciar ao condutor do veculo
uma melhoria na conduo do veculo utilizado na implementao, que fornece apenas
as informaes de velocidade, indicador do nvel de combustvel, indicador da
temperatura do lquido de arrefecimento, luz indicadora de presso do leo do motor, e
hodmetro total. Alm disso, o projeto tambm visa alertar ao motorista se existe
algum problema no sistema de gerenciamento do motor, indicando quando possvel, o
sistema ou componente com defeito.
Para atingir o objetivo almejado, foi definido o seguinte modelo de
implementao, apresentado na figura 4.1:

Figura 4.1. Topologia do Sistema de Monitoramento Veicular

46

4.1 Veculo Utilizado

O veculo utilizado para o projeto o Gol, ano 97 modelo 98, produzido pela montadora
Volkswagen, conforme figura 4.2. O veculo possui o motor AT 1.0 de 8 vlvulas e utiliza
como combustvel apenas gasolina e possui sistema de injeo eletrnica de combustvel
multiponto.

Figura 4.2. Veculo Volkswagen Gol utilizado no projeto. (Fonte: autor)

Tabela 4.1. Ficha tcnica do veculo. (Fonte:
http://revistaautoesporte.globo.com/EditoraGlobo/componentes/article/edg_article_print/1,3916,4066571683-1,00.html, Com adaptaes)
Gol 1.0 8v
Potncia (cv/rpm)

54,4/5.000

Torque (Kgfm/rpm)

8,5/3.5000

Velocidade Mxima (Km/h)

147

Acelerao 0-100 Km/h (s)

17,5

Consumo cidade (Km/l)

11,2

Consumo estrada (Km/l)

14,2

Peso (Kg)

935

Tanque de combustvel (l)

51

O veculo foi escolhido por que foi nele que foi identificada a ausncia de informaes
importantes de bordo e de diagnstico do veculo, o que dificulta um monitoramento adequado
das condies de funcionamento e conduo do veculo. O painel do veculo pode ser
visualizado na figura 4.3.

47

Figura 4.3. Painel de instrumentos do Gol. (Fonte: autor)

O sistema de gerenciamento do motor do automvel apresentado o Motronic MP9.0,

produzido pela empresa BOSCH e apresentado na figura 4.4. Esse sistema gerencia os
sensores e atuadores do sistema de injeo eletrnica do veculo.

Figura 4.4. UCE Motronic MP9.0. (Fonte: autor)

48

A UCE em questo possui uma tomada de diagnstico para a aquisio de informao.

Esta tomada utiliza o padro fsico OBDII, e fisicamente baseado no padro ISO 9141-2. O
padro possui 16 pinos para alimentao do dispositivo tester e para comunicao. Neste
veculo em particular, conforme a figura 4.5, a tomada de diagnstico possui apenas 3 destes
pinos conectados a UCE, os pinos so o pino 7, conhecido como K-line, que responsvel
pela comunicao com o dispositivo externo, o pino 4 que o pino que contm a conexo
GND, e o pino 16 que est conectado a alimentao de 12 V corrente contnua para
alimentao do dispositivo externo.

Figura 4.5. Conector OBDII do Gol. (Fonte: autor)

4.2 Interface VAG-COM

Para que a comunicao entre o notebook e a tomada de diagnstico possa ser realizada,
necessria a utilizao de uma interface para a atenuao do sinal de sada da tomada de
diagnstico, que no trabalha com os mesmos valores de tenso e corrente que os
computadores padro PC x386.
Pretendia-se elaborar o hardware da interface, utilizando o CI ELM 327, este CI (Circuito
Integrado) tem a funo de se comunicar com vrios protocolos de comunicao de
diagnsticos diferentes, todos baseadas no conector padro OBDII. Atravs do estudo do
49

conector do veculo e sua pinagem, foi identificado atravs de referncias em sites e livros
como o do Alexandre Guimares, que este conector era compatvel com o protocolo ISO
9141-2 no qual o CI ELM 327 era compatvel.
O CI foi adquirido e a interface de hardware foi elaborada e testada fora do veculo, e
constatou-se que todos os valores apresentaram os valores de tenso e corrente compatveis
com os descritos no datasheet do CI. Depois foram efetuados testes no veculo, e durante os
testes no foi possvel obter qualquer tipo de comunicao com o veculo.
Aps inmeros testes e pesquisas, constatou-se a inviabilidade de utilizao desta
interface baseada no ELM 327, pois apesar de toda literatura indicar que o tipo de conector do
veculo compatvel com o protocolo 9141-2, ele utiliza um protocolo proprietrio da
Volkswagen, o Keyword Protocol 1281, que apesar de ser compatvel fisicamente com o
protocolo ISO 9141-2, no compartilha as mesmas caractersticas de comunicao. Por essa
razo foi necessrio encontrar outra interface de comunicao, que fosse compatvel com o
protocolo kw1281. Este processo consumiu um tempo considervel da elaborao do projeto,
cerca de um ms.
A interface escolhida foi a VAG-COM, por que uma das poucas que se comunica com o
protocolo proprietrio KW1281, outro fator relevante para a utilizao da interface foi a
razovel facilidade para a aquisio deste produto.

Figura 4.6. Interface VAG-COM. (Fonte: autor)

Esta interface, visualizada na figura 4.6, produzida pela empresa Ross-Tech, que est
sediada na cidade de Lansdale, Pennsylvania, nos Estados Unidos. A Roos-Tech uma
50

empresa que produz software e hardware de diagnstico para automveis. Para a elaborao
deste projeto alm da interface, foi utilizado o software desenvolvido por esta empresa. O
software o VAG-COM, verso 311-2, conforme figuras 4.7 e 4.8. O software uma verso
shareware com algumas funcionalidades limitadas de diagnostico do veculo, esta verso
permite visualizar as informaes de bordo e a visualizao de alguns erros do sistema de
gerenciamento do motor do veculo. O software foi utilizado como modelo e tambm foi feita
a tentativa de engenharia reversa no processo de comunicao com a UCE, atravs do
monitoramento da porta serial do notebook.

Figura 4.7. Aplicao VAG-COM (exibio dos dados de identificao da UCE). (Fonte: autor)

Figura 4.8. Aplicao VAG-COM (valores dos blocos de dados). (Fonte: autor)

51

Uma caracterstica que merece ateno desta interface que ela apenas atenua o sinal e
faz a converso do padro de comunicao para USB. Portanto todo controle do fluxo da
informao com a UCE fica a cargo do software desenvolvido, o que demanda um
entendimento mais aprofundado do funcionamento do protocolo.

4.3 Interface de Integrao

Para a comunicao entre o veculo e o dispositivo mvel, previa-se inicialmente apenas a
utilizao de uma interface de hardware. Durante a pesquisa e implementao do software no
dispositivo mvel e testes da interface notou-se que a interface de comunicao necessitaria de
um dispositivo que possusse o USB host controller.
Para alcanar o objetivo do projeto, adotou-se outra soluo. Essa soluo utiliza um
notebook junto interface VAG-COM como mediador da comunicao entre a UCE do
veculo e o dispositivo mvel. A interface VAG-COM atenua o sinal oriundo da UCE do
veculo coletado na tomada de diagnstico e o repassa a porta USB do notebook, que possui
instalado o driver que possibilita a comunicao com a interface de diagnstico VAG-COM,
esse driver fornecido pela empresa FTDI- Future Technology Devices International Limited,
que produz o CI que est embarcado no VAG-COM e faz a converso do sinal para o padro
USB.
O notebook acessa os dados da interface por meio de uma porta de comunicao serial,
esta porta criada por meio do driver da FTDI. A porta serial permite o envio e recebimento
de dados da UCE do veculo.
Para estabelecer a comunicao com a UCE do veculo e o notebook foi desenvolvido um
software embarcado no notebook. Este software estabelece comunicao com a UCE do
veculo, e coleta os dados disponveis no canal de comunicao de forma sncrona. Aps a
coleta os dados so tratados, onde feita a identificao da informao coletada e seu
tratamento para posterior envio ao dispositivo mvel.
Aps o tratamento da informao ela enviada por meio de transmisso de dados
Bluetooth para o dispositivo mvel. Para tanto, utilizado um adaptador Bluetooth.
52

4.4 Dispositivo Mvel

O equipamento escolhido para a apresentao das informaes para o usurio foi o
dispositivo mvel smartphone da marca HTC, modelo TYTNII.
Tabela

4.2.

Especificao

do

TYTNII

(com

adaptaes).

(Fonte:

http://www.htc.com/www/product/tytnii/specification.html. Com adaptaes.)

Processor
Operating System
Memory
Dimension
Weight
Display
Connectivity

Battery

AC Adapter

TYTN II
Qualcomm MSM7200TM, 400MHz
Windows Mobile 6 Professional
ROM: 256MB
RAM: 128MB SDRAM
112 mm (L) X 59 mm (W) X 19 mm (T)
190g with battery
2.8 inch, 240 X 320 QVGA TFT-LCD display with
adjustable angle and backlight
Bluetooth 2.0
Wi-Fi: IEEE 802.11 b/g
HTC ExtUSB (11-pin mini-USB and audio jack
in one)
GPS antenna connector
1,350 mAh rechargeable Li-polymer battery
Standby time:

Up to 350 hours for UMTS

Up to 365 hours for GSM

Talk time:

Up to 264 minutes for UMTS

Up to 420 minutes for GSM

Up to 120 minutes for video

call
Voltage range/frequency: 100 ~ 240V AC,
50/60Hz
DC output: 5V and 1A

Este aparelho foi escolhido por sua capacidade relativamente alta de processamento para
um dispositivo mvel, possui uma tela com tamanho adequado para visualizao da
informao pelo condutor do veculo, sem prejudicar a visibilidade original do veculo e
minimizando a perda de ateno do motorista, e por ser um dispositivo compacto, pode ser
embarcado com facilidade no painel do veculo, em uma posio de fcil leitura para o
condutor do automvel.
Alm das caractersticas citadas anteriormente, o HTC TYTNII utiliza o sistema
operacional Windows Mobile 6.0, que um sistema operacional muito intuitivo e de fcil
manuseio pelo usurio, o que facilita a leitura das informaes e o manuseio do software
53

embarcado no dispositivo. Outra caracterstica do Windows Mobile sua integrao nativa

com as linguagens da plataforma de desenvolvimento .NET. O TYTNII apresentado na
figura 4.9.

Figura 4.9. HTC TYTNII. (Fonte: http://www.itreviews.co.uk/hardware/h1387.htm)

4.5 O Software Desenvolvido

O sistema desenvolvido neste projeto constitudo de dois softwares que trabalham de
forma integrada. O primeiro software est alocado no notebook e responsvel por
estabelecer uma conexo com a UCE, solicitar as suas informaes, coletar os dados
disponveis, identificar e tratar essa informao e disponibiliz-la para o outro software, que
est embarcado no dispositivo mvel. Este software por sua vez, recebe a informao j
padronizada e a disponibiliza para o condutor do veculo atravs de uma interface grfica.
O software embarcado no notebook do veculo chamado de software de conexo e
integrao Bluetooth, pois ele est encarregado de se conectar a UCE e transmitir os dados
ao dispositivo mvel, atravs de uma conexo Bluetooth. O software que est embarcado
no dispositivo mvel e tem a funo de apresentar as informaes padronizadas ao condutor
do veculo chamado de software de apresentao da informao ao condutor. Na figura
4.10, pode ser vita a viso geral do sistema.

54

Sistema de Monitoramento Veicular

Conexo e Integrao Bluetooth

Apresentao da Informao ao
Condutor

Conecta UCE

Solicita e
informao

recebe

Transmite informao
dispositivo mvel

Recebe
notebook

Apresenta
usurio

informao

informaes

do

ao

ao

Figura 4.10. Viso geral da organizao do software. (Fonte: autor)

4.5.1

Software de Conexo e Integrao Bluetooth

O Software de Conexo e Integrao Bluetooth a aplicao integrante do sistema de

monitoramento veicular que tem a funo de intermediar a comunicao entre o veculo e o
dispositivo mvel. A necessidade deste intermdio justifica-se pela ausncia de hardware
controlador de host USB no dispositivo mvel.
Este software, desenvolvido em C#, utiliza a metodologia de linguagem orientada a
objeto, e responsvel por coletar e transmitir as informaes de bordo e de diagnstico a
UCE do veculo. Para isso o software foi elaborado em 4 classes, onde 3 representam camadas
lgicas, e uma classe esttica auxiliar. O diagrama de classes apresentado na figura 4.11.

55

Figura 4.11. Diagrama de Classe da Aplicao. (Fonte: autor)

4.5.1.1

A Classe Conexo

A classe conexo responsvel por estabelecer a conexo com a UCE do veculo, atravs
da interface VAG-COM. Esta conexo utiliza o padro serial de comunicao para se
comunicar com a interface VAG-COM, que por sua vez repassa o sinal a UCE do veculo.
Essa classe contm os mtodos necessrios para a efetivao da conexo com a UCE, e
para o controle da comunicao.

4.5.1.2

A Classe TrataDados

Essa classe responsvel por receber os bytes recebidos da classe Conexo e computar
esses valores para obter a informao de bordo e diagnstico no padro convencional de
leitura. Ela utiliza a camada de conexo com base para a aquisio dos dados, e de acordo com
a informao obtida aplicado o mtodo adequado na camada de comunicao.

56

Na tabela 4.3 so mostrados os clculos utilizados na implementao do prottipo. Cada

valor composto de 3 bytes, um byte identifica o tipo de informao e os dois restantes
(chamados de byte a e byte b) so manipulados atravs de clculos para a apresentao do
valor padronizado ao condutor do veculo.
Tabela 4.3. Clculos de converso das informaes de bordo. (Fonte: autor)

Valor

Clculo *(Fonte:
http://www.blafusel.de/)

RPM
Tempo de Injeo
Tenso da Bateria
Temperatura do Lquido de Arrefecimento do Motor
Velocidade
Relao Lambda

0.2 * a * b
a * b * 0.01
0.001*a*b
a * (b - 100) * 0.1
0.01*a*b
0.0001 * a * (b - 128) + 1

4.5.1.3

A classe Comunicao

Esta classe responsvel por instanciar as classes anteriores de forma ordenada para que
os dados possam ser obtidos. Esta classe tambm responsvel por estabelecer a conexo e
envio de dados ao dispositivo mvel de forma sincronizada.
na classe de comunicao que so solicitadas atravs de dados as informaes de bordo
e de diagnstico da UCE do veculo. As informaes de bordo so solicitadas atravs dos
mtodos solicitaDados e blocoDados.
O mtodo solicitaDados, solicita UCE informaes de grupo de leitura de dados que so as
informaes de bordo, alm de requisitar o grupo de dados este mtodo tambm informa qual bloco de
dados que ser transmitido pela UCE. Cada bloco de dados contm quatro valores de bordo do veculo.
Tabela 4.4. Blocos de dados e valores identificados. (Fonte: autor)
Bloco de Dados
1
2
3
4
5
6
7
9

Valores por grupo

RPM, Temperatura do lquido de arrefecimento do motor,
RPM, Tempo de injeo, Tenso da bateria, temperatura do ar
admitido
RPM, Tempo de injeo, angulao da borboleta de acelerao
RPM, Tempo de injeo e velocidade
RPM, fator lambda
Fator lambda, Fator lambda
RPM, Temperatura do lquido de arrefecimento do motor
Fator lambda
57

Pode-se notar que o valor de RPM aparece de forma redundante em vrios blocos, isso
til na aplicao, pois este campo atualizado mais vezes que os outros campos.
As informaes apresentadas ao condutor foram selecionadas de acordo com sua
relevncia e facilidade de entendimento, ento foi dada prioridade nas informaes que o
condutor geralmente j tem familiaridade.
As informaes de erro de algum componente da UCE so adquiridas dos mtodos
solicitaErro e erroUce. O mtodo solicitaErro faz a requisio do grupo de leitura de erros, e o
mtodo erroUce retorna os erros encontrados, se no houver erro armazenado na memria de
erro da UCE, o valor retornado ser igual a zero, caso contrrio ser retornado trs bytes para
a identificao de cada erro.
Os dois primeiros bytes do erro so concatenados em valor hexadecimal e posteriormente
convertido em um valor inteiro, este valor inteiro comparado com os cdigos de erro
armazenados em um arquivo texto. Esse arquivo contm vrios cdigos de erro, com suas
respectivas descries, que so retornadas pelo mtodo erroUce, da classe trataDados.
Abaixo, na figuara 4.12 visulizado o diagrama de caso de uso na viso da aplicao.

Figura 4.12. Diagrama de Caso de Uso da Aplicao. (Fonte: autor)

58

4.5.2

Software de Apresentao da Informao ao Condutor

O software embarcado em dispositivo mvel responsvel por receber os dados

transmitidos pela aplicao embarcada em notebook e apresentar essa informao ao usurio
do veculo. Para isso o sistema possui duas classes que adquirem a informao e apresentam
esta informao ao condutor do veculo atravs de um formulrio padro do Windows Mobile.
Conforme a figura 4.13, o software composto de duas classes: a classe Comm e a classe
FormApresentacao.

Figura 4.13. Diagrama de classe da aplicao embarcada no dispositivo mvel. (Fonte: autor)

4.5.3

A Classe Comm

Esta classe responsvel pelas configuraes da comunicao serial Bluetooth. No

programa a comunicao feita de forma serial atravs de uma porta COM, isso proporciona
uma transparncia da implementao da comunicao Bluetooth entre o dispositivo mvel e o
notebook

4.5.4

A Classe FrmApresentao

Esta classe responsvel pelo controle do formulrio que apresenta graficamente as

informaes ao condutor do veculo, e tambm responsvel por coletar as informaes
transmitidas pelo notebook.

59

Esta Classe possui a implementao de uma Thread. A Thread necessria, pois existe
concorrncia de processamento entre a execuo e controle do formulrio e a coleta e
atualizao dos dados no formulrio, e a atualizao destas informaes s possvel com este
tipo de processamento paralelo.
As informaes so apresentadas em trs guias, duas so destinadas a informar as
informaes de conduo e a restante, as informaes de diagnstico.

Figura 4.14. Guias de apresentao das informaes da aplicao. (Fonte: autor)

Pode-se notar na figura 4.14 que so apresentadas as seguintes informaes:

Velocidade

Rotao do motor

Temperatura do lquido de arrefecimento

Distncia Percorrida

Tenso da bateria

Consumo de combustvel

Relao lambda;

Tempo de injeo;
60

Erros apresentados

A aplicao de apresentao de informaes ao condutor contm dois usurios, a prpria

aplicao que usuria da aplicao embarcada no notebook e o condutor do veculo, que
responsvel pela inicializao e finalizao da informao, alm da escolha da guia de
informao a ser exibida, essas aes so mostradas na figura 4.15 e 4.16.

Figura 4.15. Diagrama de Caso de Uso (Viso do sistema). (Fonte: autor)

Figura 4.16. Diagrama de Caso de Uso (Viso do Condutor). (Fonte: autor)

61

APLICAO DA SOLUO COM RESULTADOS

Aps a concluso das funcionalidades bsicas do software embarcado no notebook e no

dispositivo mvel, iniciaram-se os testes no veculo. Os primeiros testes ocorreram com o
veculo em repouso e com o motor desligado. Atravs deste teste foi possvel depurar a
aplicao para a identificao das informaes recebidas e verificar a preciso dos resultados
obtidos, atravs da comparao com os dados disponveis no veculo e com os dados obtidos
da aplicao VAG-COM. O software ficou em estado de execuo por cerca de 50 minutos
ininterruptos, sem perca de informao, conforme a fugura 5.1.

Figura 5.1 Dados brutos recebidos da UCE do veculo. (Fonte: autor)

62

Figura 5.2. Dados recebidos da UCE tratados. (Fonte: autor)

Pode-se notar nas figuras 5.3 e 5.4 o processo de converso dos bytes recebidos em
valores inteligveis pelo condutor.

Figura 5.3. Exemplo de converso do bloco de identificao. (Fonte: autor)

63

Figura 5.4. Exemplo de Converso do bloco de dados de bordo. (Fonte: autor)

Com a obteno e tratamento dos dados realizados com sucesso, foram feitos testes com
o carro em repouso, mas com o motor em funcionamento, e os resultados foram comparados
com os valores do painel de instrumentos do veculo e com os valores disponibilizados no
software VAG-COM. O resultado pode ser visto na figura 5.5.

Figura 5.5. Dados recebidos da UCE tratados com o motor do veculo ligado (Fonte: autor)

64

Aps a concluso do teste com o motor ligado, foi feita a integrao da comunicao
entre a aplicao do notebook e o dispositivo mvel, como pode ser visto na figura 5.6, com o
fornecimento das informaes do bordo.

Figura 5.6 Dados recebidos pelo dispositivo mvel e mostrados em aplicao do dispositivo mvel.
(Fonte: autor)

Aps os testes com o veculo em repouso, iniciaram-se os testes com o veculo em

movimento. O primeiro teste consistente com o veculo em movimento foi realizado no dia
28/10/2009, na rodovia BR-070, em um percurso de cerca de 25 quilmetros Neste percurso
realizou-se diversas repeties de testes de funcionamento, neste primeiro teste foram
mostradas ao condutor do veculo a velocidade, rotao do motor, temperatura do lquido de
arrefecimento e tenso da bateria.
Os valores citados acima apresentaram as informaes consistentemente ao condutor do
veculo. Os valores de velocidade e temperatura do lquido de arrefecimento quando
comparados aos valores fornecidos pelo painel de instrumentos mostraram-se bastante
precisos, ao valor muito prximo ao apresentado no painel. Mas a atualizao do valor da
velocidade no dispositivo mvel apresentou um atraso na disponibilizao da informao,
quando se aplicava alta carga ao motor, provocando uma variao rpida de velocidade.

65

Durante este teste foi identificado que o sistema interrompia seu funcionamento
constantemente antes dos 5 minutos de funcionamento. Aps alguns testes foi identificado que
ao requisitar o bloco de dados de bordo 0x05 da UCE, o mesmo funcionava e apresentava os
resultados esperados com o veculo em repouso, mas quando o veculo se movimentava, em
pouco tempo a comunicao se perdia. Quando se solicitou outro bloco de informao com a
mesma informao a comunicao persistiu em funcionamento.
Foi feito um percurso na rodovia BR 070 do quilmetro por cerca de 20 quilmetros, e
notou-se que aps no solicitar mais o bloco de dados 0x05 a comunicao manteve-se
ininterrupta durante todo trajeto, apresentado as informaes como desejado.
Depois do teste com o veculo em movimento em rodovia, foi feito um refinamento do
software embarcado em notebook e no do dispositivo mvel, para a automatizao da
sincronizao dos equipamentos, e tambm para fornecer todas as informaes ao condutor do
veculo.
Para a disponibilizao da relao lambda que era adquirida no bloco 5, foi utilizado o
bloco 9 para a aquisio dessa informao, aps teste de percurso de 12 km, o software
apresentou as informaes ininterruptamente. Alm disso, este bloco apresentado
alternadamente ao bloco 2 que fornece informao redundante de RPM, tempo de injeo e
tenso da bateria, uma vez que as informaes so redundantes e a tenso da bateria no
necessita de uma alta taxa de atualizao. Utilizou-se este recurso para a requisio de 3
blocos de dados, o que minimiza o atraso da apresentao das informaes ao condutor do
veculo.
Para disponibilizar as informaes de distncia percorrida e consumo de combustvel
necessria a implementao de alguns clculos, pois essas informaes no so nativas da UCE
do veculo. Para o clculo da distncia percorrida decidiu-se utilizar o parmetro de velocidade
como base para o clculo. Para informar a distncia utiliza-se a velocidade percorrida em um
intervalo de tempo, este intervalo constante, e baseado no tempo de fornecimento da
informao da velocidade do veculo. Ou seja, a cada intervalo de tempo ser adquirida a
velocidade do veculo e a distncia ser calculada e armazenada em uma varivel acumuladora.
distncia distncia _ anterior velocidade tempo(consante)

(Eq. 5. 1)

66

Para o clculo do consumo necessrio utilizar o valor do tempo de injeo fornecido

pela UCE do veculo e da vazo do bico injetor, este valor foi baseado na especificao de
fornecedoras de autopeas.

Volume Volume _ anterior tempo _ de _ injeo vazo _ bico _ injetor

Consumo

Distncia
Volume

(Eq. 5. 2)

(Eq. 5. 3)

Aps a implementao destas informaes, efetuou-se um teste com o veculo em

movimento, neste teste foi ajustado o valor da constante de tempo usada no clculo da
distncia, obtendo uma preciso de cerca de 85 metros. O consumo calculado apresentou
valores razoveis e dentro da realidade, entre 6 km/l e 14 km/l. Como o valor instantneo
no se pode se comparar tal valor com o consumo mdio. Para o valor do consumo de
combustvel apresentar valores aceitveis foi necessrio que o veculo percorresse uma
distncia superior a 8 km. Os resultados obitidos podem ser observados na figura 5.7.

Figura 5.7. Resultados obtidos durante os testes. (Fonte: autor)

Por ltimo foram feitos os ajustes de formatao da informao apresentada no dispositivo

mvel para acomodar os valores de uma forma mais apresentvel.

67

5.1 Avaliao Global da Soluo Proposta

De forma geral, a implementao do projeto apresentou resultados satisfatrios. Foi
possvel se conectar UCE do veculo, solicitar dados, calcular e converter valores, e
disponibilizar as informaes ao condutor do veculo. Como a maior parte das informaes
adquirida da UCE do veculo elas mostram o valor real interpretado pelo mdulo.
Em relao s informaes de distncia percorrida e consumo, que so calculadas com
base nas informaes obtidas os resultados foram relativamente precisos. distncia
percorrida se mostrou condizente com a informao do hodmetro total do veculo e com
testes feitos entre dois pontos com distncia conhecida.
O valor do consumo instantneo de combustvel mostrou durante os primeiros testes
variaes bruscas do valor e s vezes no condiziam com a realidade. Aps tal constatao o
calculo foi ajustado e os resultados obtidos se aproximaram da realidade de consumo do
veculo.
Durante os testes do projeto com o veculo em movimento notou-se uma menor
velocidade de atualizao das informaes em relao s disponibilizadas no painel de
instrumentos do veculo, o que provoca uma defasagem na apresentao da informao em
relao ao valor mostrado no painel de instrumentos. Mas mesmo assim possvel utiliz-las
como referncia para conduo.
Notou-se, principalmente no incio do projeto uma grande dificuldade de adquirir
informaes a respeito do assunto aqui tratado e as informaes obtidas em referncias
acadmicas se mostraram algumas vezes incompletas, pela prpria natureza dessas
informaes, que so informaes industriais automobilsticas.
Aps pesquisa em diversas fontes, e principalmente na internet foi possvel identificar qual
o protocolo de diagnstico da UCE do veculo, e atravs do site http://www.blafusel.de/, que
fornece informaes tcnicas do protocolo que no esto descritas na norma da SAE que
especfica o protocolo kw1281. Este site foi a base do desenvolvimento do software e foi
fundamental para a concluso deste projeto.
A autonomia do prottipo est limitada durao das baterias do dispositivo mvel e do
notebook, esta autonomia maior no dispositivo mvel, que aps carga apresentou
68

funcionamento por mais de 6 horas durante os testes. Por outro lado a bateria do notebook
no ultrapassou 2 horas e 30 minutos de carga durante os testes.
Durante os testes aconteceram alguns erros espordicos, alguns identificados e outros no.
Aps o refinamento do software, durante os testes por um perodo prolongado, o notebook s
vezes travava, aps tal constatao foram feitos ajustes de configurao e desempenho do
notebook, esse procedimento otimizou o desempenho do notebook e minimizou o risco deste
tipo de incidente.
Raramente, durante a comunicao a mesma era interrompida pela UCE e no foi
identificada a causa deste problema, permanecendo como um erro pontual.
Para a realizao dos testes encontrou-se certa dificuldade, pois os testes foram realizados
em vias publicas do Distrito Federal, e as condies de trfego e tempo no so controladas,
foi necessrio em algumas situaes o auxlio de uma pessoa para conduzir o veculo enquanto
outra observava os dados adquiridos.
Outra caracterstica do projeto que o mesmo um prottipo que tem o objetivo de
mostrar a viabilidade de se utilizar as informaes da UCE que so fornecidas atravs da
tomada de diagnstico para fornecer ao condutor do veculo informaes do bordo e
diagnstico, e a maioria dessas informaes esto ausentes no veculo utilizado. Ou seja, no
se pretende neste projeto implementar uma soluo comercial de alta qualidade e desempenho.
Para a implementao de um sistema para uso comercial, seria necessrio aperfeioar o
software para a identificao e tratamento dos erros pontuais apresentados, alm disso, seria
necessrio efetuar testes em diversas UCEs que possuem este protocolo, para analisar se elas
possuem as mesmas informaes. Alm disso, os testes efetuados teriam que ser feitos em
ambientes controlados apropriados como campo de provas, e a montadora do veculo teria que
homologar tal sistema.
Para a elaborao de projetos futuros, sugere-se a integrao dos componentes em um
dispositivo nico, embarcado ao veculo, de forma a reduzir o custo e complexidade do projeto
atual e melhorar a integrao do sistema com o veculo. Sugere-se tambm o estudo de como
utilizar as informaes provenientes da UCE do veculo de forma consolidada, para produzir
indicadores de conduo do veculo.
69

Outra sugesto de projeto futuro o estudo de viabilidade de atuao na UCE do veculo

para implementao de um piloto automtico com controle de velocidade ou um sistema de
atuao na UCE para evitar colises.

70

CONCLUSO

Os resultados obtidos foram satisfatrios, tanto com o veculo em repouso

quanto em movimento. O prottipo desenvolvido mostrou que possvel utilizar as
informaes de diagnstico do veculo para o monitoramento do sistema de
gerenciamento do motor, fornecendo informaes adicionais ao veculo utilizado no
projeto.
Para alcanar os objetivos almejados, foi necessrio superar algumas
dificuldades encontradas no decorrer do desenvolvimento do projeto, que no eram
esperadas, como a falta de informao sobre o protocolo de comunicao kw1281,
ausncia de exemplos de software que realizam esta funo, no disponibilizao de
informaes tcnicas pela montadora do veculo e pela fabricante da UCE do veculo.
Para projetos futuros sugerida a implementao do prottipo em um conjunto
de hardware/software embarcado ao veculo, atravs de um hardware eletrnico
integrado, de forma a no se utilizar a intermediao de um notebook durante a
comunicao. Tambm pode ser feito um estudo para utilizar as informaes adquiridas
da UCE e gerar indicadores grficos e sonoros dinmicos de conduo do veculo,
como tambm a atuao na UCE do veculo, para a implementao de um piloto
automtico.

71

REFERNCIAS BIBLIOGRFICAS

BERNAL, Paulo Srgio Milano. Comunicaes Mveis Tecnologias e Aplicaes. So

Paulo: rica, 2002.
BOSCH, Robert. Manual de Tecnologia Automotiva. So Paulo: Edgar Blucher, 2005.
Brasil. Lei n 8.723, de 28 de outubros de 1993. Dispe sobre a reduo de emisso de
poluentes por veculos automotores e d outras providncias, 28 out. 1993. Disponvel em:
<http://www.planalto.gov.br/ccivil_03/LEIS/L8723.htm>. Acesso em: 02 Out. 2009. 10:00.
Brasil, Resoluo n 354, de 13 de dezembro de 2004. Dispe sobre os requisitos para adoo
de sistemas OBD nos veculos automotores leves objetivando preservar a funcionalidade dos
sistemas de controle de emisso, 14 dez. 2004. Disponvel em:
<http://www.ibama.gov.br/proconve/ArquivosUpload/1354.pdf>. Acesso em: 02 Out. 2009.
11:26.
COZENS, Simon, WAINWRIGHT, Peter. Beginning Perl. Chigago:Wrox Press, 2000.
GONALVES, Maj. Pesquisa Revela Nmeros sobre Manuteno Preventiva. Disponvel
em < http://www.coisasdeagora.com.br/noticias.asp?id=260>. Acesso em: 16 Set 2009. 09:43

72

GUIMARES, Alexandre. Eletrnica Embarcada Automotiva. So Paulo: Editora rica

Ltda. 2007.
KIENCKE, Uwe, NIELSEN, Lars. Automotive Control Systems: For Engine, Driveline,
and Vehicle. Illus: Springe. 2005.
Society of Automotive Engineers. Keyword Protocol 1281. USA: SAE. 2008.
STONE, Richard. Introduction to Internal Combustion Engines.USA: SAE, 1999.

73

APNDICE A CDIGO FONTE DA APLICAO

EMBARCADA NO NOTEBOOK- CONEXO E INTEGRAO
BLUETOOTH

Classe Conexao
using
using
using
using
using

System;
System.Collections.Generic;
System.Text;
System.IO;
System.IO.Ports;

namespace Projeto_Final
{
class Conexao : System.IO.Ports.SerialPort
{
Inicializao da UCE - enviado um sinal de 5 baud (simulado em uma conexo de 9600 bps
atravs de timers
// de 200ms entre os sinais) e com o parmetro 01(endereo da UCE)
public void configuraPorta(SerialPort rs) {
rs.PortName = SetPortName(rs.PortName);

// configura a porta COM a ser

usada - COM1
rs.BaudRate = SetPortBaudRate(rs.BaudRate);
sinalizao da conexo
rs.Parity = SetPortParity(rs.Parity);
rs.DataBits = SetPortDataBits(rs.DataBits);
bits de dados
rs.Handshake = SetPortHandshake(rs.Handshake);
conexo

// configura a taxa de
// configura a paridade de bits
// configura a quantidade de
// configura o handshake da

}
public int conectaUce(SerialPort rs){
int sync=0;
int kw1=0;

//varivel que recebe o byte de sincronizao

//varivel que recebe o keyword1, byte menos significativo,

int kw2=0;

//varivel que recebe o keyword2, byte mais significativo,

0X01
0X8A
rs.BreakState = true; //bit 0
System.Threading.Thread.Sleep(200);

//timer para simular comunicao de 5

rs.DtrEnable = false;

//habilita a opo de dado para

rs.BreakState = false;
System.Threading.Thread.Sleep(200);
rs.BreakState = true;
System.Threading.Thread.Sleep(200);
rs.BreakState = true;
System.Threading.Thread.Sleep(200);
rs.BreakState = true;

//bit 1

baud
transmitir
//bit 0
//bit 0
//bit 0

74

System.Threading.Thread.Sleep(200);
rs.BreakState = true;
//bit 0
System.Threading.Thread.Sleep(200);
rs.BreakState = true;
//bit 0
System.Threading.Thread.Sleep(200);
rs.BreakState = true;
//bit 0
System.Threading.Thread.Sleep(200);
rs.BreakState = true;
//bit 0
System.Threading.Thread.Sleep(200);
rs.BreakState = false;
//bit 1
System.Threading.Thread.Sleep(200);
rs.DtrEnable = true;
//Habilita a opo para recepo de
dados, neste caso da ECU
System.Threading.Thread.Sleep(200);
//Rotina para a recepo dos dados esperados da ECU, que confirmam que o
processo de
//inicializao da UCE ocorreu com Sucesso
rs.ReadByte();
//recebe informao no necessria para a aplicao
rs.ReadByte();
//recebe informao no necessria para a aplicao
sync = rs.ReadByte();
kw1 = rs.ReadByte();
kw2 = rs.ReadByte();
rs.ReadByte();
rs.ReadByte();
rs.ReadByte();
if (sync == 0x55 && kw1 == 0x01 && kw2 == 0x8A){
return kw1;
}else
return 0;
}
//-----------------------------------------------------------------------------------public int[,] idEcu(SerialPort rs){
int resp,j,ctrl,k,l;
int i=0;
int[,] idEcu=new int[5,16];
byte[] dado=new byte[1];

//array para retornar o id da ECU

//varivel que envia o byte como complemento a

ECU
dado[0] = 0x75; //Atrbui o complemeto de 0x8A para envio a a UCE
rs.Write(dado, 0, 1);
//envia byte de complemento a ECU
i = 0;
while(i<5){
rs.ReadByte();
resp = rs.ReadByte(); //tamanho do bloco
k=0;
j = resp;
l = j;
while (j >0){

//loop para pegar os dados do bloco

ctrl = 255 - resp;

//calcula o complemento do dado recebido

a ser enviado pela UCE

dado[0] = (byte)ctrl;//trata o complemento para envio a UCE
rs.Write(dado, 0, 1);
rs.ReadByte();
resp = rs.ReadByte();
if (j == l) {CountBloco.setCount(1);}
//contator do bloco
//verifica se o cabealho o cabealho de dados de id
if(resp==0xf6){
//idEcu[i, k] = i - 1; ;
ctrl = 255 - resp;
//calcula o complemento do dado
recebido a ser enviado pela UCE
dado[0] = (byte)ctrl;
//trata o complemento para envio a
UCE
rs.Write(dado, 0, 1);
while(j>=0){
rs.ReadByte();
resp=rs.ReadByte();
if(resp!=0X03){

//verifica se foi recebido o

byte que indica o final do bloco

idEcu[i,k]=resp;

//atribui ao array os bytes

k++;

//incrementa a varivel que

da id da UCE
controla as colunas do array
j--;
ctrl = 255 - resp;

//calcula o complemento

dado[0] = (byte)ctrl;

//trata o complemento

do dado recebido a ser enviado pela UCE

para envio a UCE

75

rs.Write(dado, 0, 1);
}else{
encerraBloco(rs); //funo pra encerra bloco
break;
}
}
}
j--;
}
++i;
}
return idEcu;
}
//-----------------------------------------------------------------------------------private void encerraBloco(SerialPort rs){
//System.Console.Write("\n");
int resp,j,ctrl;
byte[] dado=new byte[1];
dado[0] = 0x03;
rs.Write(dado, 0, 1);
rs.ReadByte();
rs.ReadByte();
dado[0] =(byte)CountBloco.getCount(); //n do bloco
rs.Write(dado, 0, 1);
rs.ReadByte();
rs.ReadByte();
dado[0] = 0x09;
rs.Write(dado, 0, 1);
rs.ReadByte();
rs.ReadByte();
dado[0] = 0x03;
rs.Write(dado, 0, 1);
resp = rs.ReadByte();
if (resp == 0x03)
{
j = 0;
for (j = 0; j < 3; j++)
{
ctrl = 255 - resp;
dado[0] = (byte)ctrl;
// converter int recebido para byte
rs.Write(dado, 0, 1);
resp = rs.ReadByte();
}
}
}
public void trataLixo(SerialPort rs) {
int resp,ctrl;
int i=0;
byte[] dado = new byte[1];
resp = rs.ReadByte();
while (i < resp)
{
ctrl = 255 - resp;
dado[0] = (byte)ctrl;
rs.Write(dado, 0, 1);
rs.ReadByte();
resp = rs.ReadByte();
i++;
}
CountBloco.setCount(1);
}
//-----------------------------------------------------------------------public int solicitaDados(SerialPort rs,int nuSub){
byte[]dado=new byte[1];
int resp;
dado[0] = 0x04;
rs.Write(dado, 0, 1);
System.Threading.Thread.Sleep(10);
rs.ReadByte();
System.Threading.Thread.Sleep(10);
resp = rs.ReadByte();

76

dado[0] = (byte)CountBloco.getCount();
rs.Write(dado, 0, 1);
System.Threading.Thread.Sleep(10);
rs.ReadByte();
System.Threading.Thread.Sleep(10);
rs.ReadByte();
dado[0] = 0x29;
//solicitao de leitura de grupo
rs.Write(dado, 0, 1);
rs.ReadByte();
System.Threading.Thread.Sleep(10);
rs.ReadByte();
dado[0] = (byte)nuSub; //0x01;
rs.Write(dado, 0, 1);
System.Threading.Thread.Sleep(10);
rs.ReadByte();
rs.ReadByte();
dado[0] = 0x03;
rs.Write(dado, 0, 1);
rs.ReadByte();
return (1);
}
//------------------------------------------------------------------------public int[] blocoDados(SerialPort rs){
CountBloco.setCount(1);
int resp, j, ctrl;
int k=0;
byte[] dado=new byte[1];
int[] blocoDados= new int[16];
rs.ReadByte();
System.Threading.Thread.Sleep(10);
resp = rs.ReadByte();
j = resp;
while (j > 0)
{
ctrl = 255 - resp;
dado[0] = (byte)ctrl;
//converte int recebido para byte
rs.Write(dado, 0, 1);
System.Threading.Thread.Sleep(10);
rs.ReadByte();
System.Threading.Thread.Sleep(10);
resp = rs.ReadByte();
System.Threading.Thread.Sleep(10);
if (resp == 0xE7)
{
ctrl = 255 - resp;

//calcula o complemento do dado recebido a ser

enviado pela UCE

dado[0] = (byte)ctrl;
//trata o complemento para envio a UCE
rs.Write(dado, 0, 1);
System.Threading.Thread.Sleep(10);
while (j > 0)
{
rs.ReadByte();
resp = rs.ReadByte();
if (resp != 0X03){

//verifica se foi recebido o byte que

indica o final do bloco

blocoDados[k] = resp;

//atribui ao array os bytes da id da

UCE
k++;

//incrementa a varivel que controla as

colunas do array
j--;
ctrl = 255 - resp;

//calcula o complemento do dado

recebido a ser enviado pela UCE

dado[0] = (byte)ctrl;
//trata o complemento para envio a UCE
System.Threading.Thread.Sleep(10);
rs.Write(dado, 0, 1);
}
else
{
j -= 3;
}
}
j--;
}
}

77

return blocoDados;
}
//-------------------------------------------------------------------------------public int solicitaErro(SerialPort rs) {
byte[] dado = new byte[1];
int resp;
dado[0] = 0x03;
rs.Write(dado, 0, 1);
rs.ReadByte();
resp = rs.ReadByte();
dado[0] = (byte)CountBloco.getCount();
rs.Write(dado, 0, 1);
rs.ReadByte();
rs.ReadByte();
dado[0] = 0x07;
//solicitao de leitura de grupo
rs.Write(dado, 0, 1);
rs.ReadByte();
rs.ReadByte();
dado[0] = 0x03;
rs.Write(dado, 0, 1);
rs.ReadByte();
return 1;
}
//---------------------------------------------------------------------------public int[] erroUce(SerialPort rs) {
CountBloco.setCount(1);
int resp, j, ctrl;
int k=0;
byte[] dado=new byte[1];
int[] erroUce= new int[16];
rs.ReadByte();
resp = rs.ReadByte();
j = resp;
while (j > 0)
{
ctrl = 255 - resp;
dado[0] = (byte)ctrl;
rs.Write(dado, 0, 1);
rs.ReadByte();
resp = rs.ReadByte();
if (resp == 0xFC)
{
ctrl = 255 - resp;

//calcula o complemento do dado recebido a ser

dado[0] = (byte)ctrl;
rs.Write(dado, 0, 1);
while (j > 0)
{
rs.ReadByte();

//trata o complemento para envio a UCE

enviado pela UCE

resp = rs.ReadByte();
if (resp != 0X03){

//verifica se foi recebido o byte que

indica o final do bloco

erroUce[k] = resp;

//atribui ao array os bytes da id da

UCE
k++;

//incrementa a varivel que controla as

colunas do array
j--;
ctrl = 255 - resp;

//calcula o complemento do dado

recebido a ser enviado pela UCE

dado[0] = (byte)ctrl;
rs.Write(dado, 0, 1);

//trata o complemento para envio a UCE

}
else
{
j -= 3;
}

78

}
j--;
}
}
return erroUce;
}
//---------------------------------------------------------------------------//Funes baseadas ma referncia da Microsoft sobre portas serias no site da MSDN
(http://msdn.microsoft.com/pt-br/library/system.io.ports.serialport(VS.80).aspx)
public static string SetPortName(string defaultPortName)
{
string portName;
portName = "COM1";
if (portName == "")
{
portName = defaultPortName;
}
return portName;
}
public static int SetPortBaudRate(int defaultPortBaudRate)
{
string baudRate;
baudRate = "9600";
if (baudRate == "")
{
baudRate = defaultPortBaudRate.ToString();
}
return int.Parse(baudRate);
}
public static Parity SetPortParity(Parity defaultPortParity)
{
string parity;
parity = "None";
if (parity == "")
{
parity = defaultPortParity.ToString();
}
return (Parity)Enum.Parse(typeof(Parity), parity);
}
public static int SetPortDataBits(int defaultPortDataBits)
{
string dataBits;
//Console.Write("Data Bits({0}): ", defaultPortDataBits);
dataBits = "8";// Console.ReadLine();
if (dataBits == "")
{
dataBits = defaultPortDataBits.ToString();
}
return int.Parse(dataBits);
}
public static StopBits SetPortStopBits(StopBits defaultPortStopBits)
{
string stopBits;
stopBits = "None"; //Console.ReadLine();
if (stopBits == "")
{
stopBits = defaultPortStopBits.ToString();

79

}
return (StopBits)Enum.Parse(typeof(StopBits), stopBits);
}
public static Handshake SetPortHandshake(Handshake defaultPortHandshake)
{
string handshake;
handshake = "None";

//Console.ReadLine();

if (handshake == "")
{
handshake = defaultPortHandshake.ToString();
}
return (Handshake)Enum.Parse(typeof(Handshake), handshake);
}
}
}

Classe Count Bloco

using System;
using System.Collections.Generic;
using System.Text;
namespace Projeto_Final
{
public static class CountBloco //classe esttica utilizada para a istanciao dos mtodos
estticos
{
public static int nuBloco=0;//varivel que armazena o numero do bloco de comunicao
public static double dist = 0; //varivel que armazena a distncia percorrida
public static double litros = 0;//vrivel que armazena o combustvel gasto
public static void setCount(int count) {
nuBloco +=count;
if (nuBloco > 0xff) { nuBloco = 0; }
}
public static int

getCount(){

//mtodo que incrementa o numero do bloco

//mtodo que retorna o numero do bloco

nuBloco++;
if (nuBloco > 0xff) { nuBloco = 0; }
return nuBloco;
}
public static double distancia(int v) {
dist = dist + v * 0.00083; //valor constante dessa formula calculado com base no
tempo de atualizao das informaes pelo software
return (dist);
}
public static double consumo(double tInj) {
double consumo = 0;
litros+=(tInj*1.8)/1000;
if (litros != 0)
{
consumo = dist / litros;
return consumo;
}
else {
return 0;
}
}
}
}

Classe TrataDados
using System;
using System.Collections.Generic;
//using System.Linq;

80

using System.Text;
using System.IO;
namespace Projeto_Final
{
class TrataDados
{
//Calcula a rotao do motor do veulo
public int Rpm(int a, int b) {
double rpm = 0.0;
rpm = 0.2 * a * b;
return ((int)rpm);
}
//Calcula a temperatura do lquido de arrefecimento do motor
public int TempMotor(int a, int b) {
double temp=0.0;
temp = a * (b - 100) * 0.1;
return((int)temp);
}
//Calcula a tenso da bateria
public double TensaoBat(int a, int b){
double v=0.0;
v=0.001*a*b;
return(v);
}
//Calcula o valor da relao da sonda lambda
public double Lambda(int a, int b) {
double lambda = 0.0;
lambda = 0.0001 * a * (b - 128) + 1;
return (lambda);
}
//Calcula a velocidade do veculo
public int Velocidade(int a, int b){
double vel=0.0;
vel=0.01*a*b;
return((int)vel);
}
//Calcula o tempo de injeo do veculo
public int TempoInjecao(int a, int b) {
double tempInj = 0.0;
tempInj = a * b * 0.01;
return((int)tempInj);
}
//Calcula consumo de combustivel
public double consumo() {
double cons=0.0;
return (cons);
}
//busca a descrio do erro em um arquivo texto de acordo com com os bytes recebidos
public string erroUce(int a , int b){
string comp = "";
string err = "Erro no catalogado";
int erro = 0;
erro=Convert.ToInt32(a.ToString("X") + b.ToString("X"), 16);
StreamReader sr = new StreamReader("codigos de erro.txt");
while (!sr.EndOfStream) {
comp=sr.ReadLine();
if (comp== erro.ToString("D5")) {
err = sr.ReadLine();
}
}
sr.Close();
return (erro+":"+err);
//retorna numero e descrio do erro
}
}
}

Classe Comunicacao
using System;

81

using
using
using
using

System.Collections.Generic;
System.Text;
System.IO;
System.IO.Ports;

namespace Projeto_Final
{
class Comunicacao
{
public static void Main()
{
Comunicacao comm=new Comunicacao();
usada para acessar metodos no formulrio
int addEcu;
KW1
int[,] idEcu=new int[5,12];
identificao da UCE
int[] dados = new int[16];
do veculo
int[] erro = new int[16];
provenientes da UCE do veculo
Conexao con = new Conexao();
int rpm=0;
double temp=0;
arrefecimento
double tensaoBat=0;
double TInj = 0;
double lambda=0;
double consumo = 0;
combustvel
int ctrlBloco = 0;
a informao lambda
int vel = 0;
string erroUce="";
erro da UCE
TrataDados trtds = new TrataDados();
SerialPort bt = new SerialPort();
transmisso via bluetooth
bt.PortName = "COM8";
aberta para comunicao bluetooth
bt.BaudRate = 9600;
porta
bt.Open();

//instncia da classe Comunicao,

//Endereo de Inicializao da ECU, o
//array que armazena os dados de
//array que armazena os dados de bordo
//array que armazena os erros
//instancia da classe de conexo
//RPM - rotaes por minuto
//temperatura do lquido de
//Tenso da bateria
//tempo de injeo
//relao estequiomtrica
// varivel que armazena o consumo de
//varivel de controle para apresentar
//velocidade
//string que coleta a descrio do
//instncia da classe trataDados
//instncia de cinexo serial para
//configura o numero da porta com
//configura a taxa de sinalizao da
//abre a porta

//--------------------------------Cabealho da aplicao-------------------------------------------------------System.Console.WriteLine("-----------------------------------------------------------------------------");
System.Console.WriteLine("|
UniCEUB - Projeto Final
|");
System.Console.WriteLine("|
Sistema de Monitoramento Veicular
|");
System.Console.WriteLine("|
Alvaro Santana dos Santos Junior - Ra:
2051593/0
|");
System.Console.WriteLine("|
Interface de Comunicao SerialBluetooth
|");
System.Console.WriteLine("-----------------------------------------------------------------------------");
//---------------------------------Estabelece conexes com notebook e dispositivo
mvel--------------------------------------------------con.configuraPorta(con);
//mtodo que efetua a configurao da
porta serial para comunicao com a UCE do veculo
con.Open();
// estabelece conexo com a porta
COM1;
if (con.IsOpen == true)
//Verifica se a porta est aberta
{
System.Console.WriteLine("");
System.Console.WriteLine("Porta Serial " + con.PortName + " Inicializada.");
System.Console.WriteLine("");
}
else {
System.Console.WriteLine("Erro!!! - Porta serial no encontrada. Verifique a
conexo.");
}
System.Console.Write("Sincronizando comunicao com dispoitivo mvel: ");
if (comm.sincroniza(bt) == 1) //estabelece a sincronizao com o dispositivo mvel
{

82

System.Console.WriteLine("Comunicao estabelecida!");
System.Console.WriteLine(" ");
}
//----------------------------------------------Estabelece conexo com UCE do
veculo e adquire----------------------------------//------------------------------------------------------os dados de identificao
da mesma----------------------------------------addEcu=con.conectaUce(con);
if (addEcu == 0x01)

//recebe o endereo da UCE

//verifica se a conexo com a ECU foi

efetuada
{
System.Console.WriteLine("Conexo estabelecida com a UCE");
System.Console.WriteLine("");
System.Console.WriteLine("Endereo da ECU: 0X0"+addEcu);
//retorna o
enderreo da ECU que determinado pelo KW1
idEcu = con.idEcu(con);
//funo que
retorna os dados de identificao da UCE
System.Console.WriteLine("");
//Id da UCE
System.Console.WriteLine(
"ID: " + (char)idEcu[0, 0] + (char)idEcu[0, 1] +
(char)idEcu[0, 2] + (char)idEcu[0, 3]
+ (char)idEcu[0, 4] + (char)idEcu[0, 5] +
(char)idEcu[0, 6]+ (char)idEcu[0, 7] + (char)idEcu[0, 8]
+ (char)idEcu[0, 9] + (char)idEcu[0, 10] +
(char)idEcu[0, 11]
);
//Nome da UCE
System.Console.WriteLine(
"NOME: " + (char)idEcu[1, 0] + (char)idEcu[1, 1] +
(char)idEcu[1, 2] + (char)idEcu[1, 3]
+ (char)idEcu[1, 4] + (char)idEcu[1, 5] +
(char)idEcu[1, 6] + (char)idEcu[1, 7] + (char)idEcu[1, 8]
+ (char)idEcu[1, 9] + (char)idEcu[1, 10] +
(char)idEcu[1, 11]+ (char)idEcu[1, 12]+ (char)idEcu[2, 0]
+ (char)idEcu[2, 1] + (char)idEcu[2, 2] +
(char)idEcu[2, 3] + (char)idEcu[2, 4]
+ (char)idEcu[2, 5] + (char)idEcu[2, 6] +
(char)idEcu[2, 7] + (char)idEcu[2, 8]
);
//Cdigo do software da UCE
System.Console.WriteLine(
"COD SOFTWARE: " + (char)idEcu[3, 0] +
(char)idEcu[3, 1] + (char)idEcu[3, 2]+ (char)idEcu[3,3]
+ (char)idEcu[3, 4] + (char)idEcu[3, 5] +
(char)idEcu[3, 6] + (char)idEcu[3, 7] + (char)idEcu[3, 8]
+ (char)idEcu[3, 9] + (char)idEcu[3, 10]+
(char)idEcu[3,11]
);
//Cdigo da pea
System.Console.WriteLine(
"COD PECA: " + (char)idEcu[4, 0] + (char)idEcu[4,
1] + (char)idEcu[4, 2] + (char)idEcu[4, 3]
+ (char)idEcu[4, 4] + (char)idEcu[4, 5] +
(char)idEcu[4, 6] + (char)idEcu[4, 7] + (char)idEcu[4, 8]
+ (char)idEcu[4, 9] + (char)idEcu[4, 10] +
(char)idEcu[4, 11]
);
}
else {
System.Console.WriteLine("Erro!!! - No foi possvel estabelecer conexo com a
UCE do veculo");
System.Console.WriteLine("--> Verifique se a ignio est ligada ou se a
interface est conectada na tomada de diagnstico do veculo");
}
con.trataLixo(con);
identificao da UCE

//funo que ignora bytes recebidos aps a

//-------------------------Solicita os erros armazenados na memria de erro da

UCE------------------------------------------------if (con.solicitaErro(con) == 1)
{
System.Console.WriteLine(" ");
erro = con.erroUce(con);

83

//se o valor for diferente de 0, existe um erro na UCE

//teste para o 1 grupo de erro
if (erro[2] != 0)
{
erroUce = trtds.erroUce(erro[0], erro[1]);
System.Console.WriteLine(erroUce);
bt.WriteLine("1"+ erroUce);
System.Threading.Thread.Sleep(30);
}
//teste para o 2 grupo de erro
if (erro[5] != 0)
{
erroUce = trtds.erroUce(erro[3], erro[4]);
System.Console.WriteLine(erroUce);
bt.WriteLine("2" + erroUce);
System.Threading.Thread.Sleep(30);
}
//teste para o 3 grupo de erro
if (erro[8] != 0)
{
erroUce = trtds.erroUce(erro[6], erro[7]);
System.Console.WriteLine(erroUce);
bt.WriteLine("3" + erroUce);
System.Threading.Thread.Sleep(30);
}
//teste para o 4 grupo de erro
if (erro[11] != 0)
{
erroUce = trtds.erroUce(erro[9], erro[10]);
System.Console.WriteLine(erroUce);
bt.WriteLine("4" + erroUce);
System.Threading.Thread.Sleep(30);
}
}
//------Requisita as informaes de conduo coletadas da tomada de diagnstico e
as envia para o dispositivo mvel,-------------//--------------------------por meio de uma trasmisso bluetooth utilizando uma
porta COM-----------------------------------------System.Console.WriteLine("Trasmitindo informaes de conduo...");
bt.RtsEnable = true;
while (true)
//loop infinito para aquisio dos dados e
envio das informaes
{
if (con.solicitaDados(con, 1) == 1){ //solicita o 1 bloco de dados de bordo
da UCE
dados = con.blocoDados(con);
//RPM
rpm = trtds.Rpm(dados[1],dados[2]);
System.Console.Write("|\r");
bt.WriteLine("R" + rpm);
System.Threading.Thread.Sleep(30);
correta recepo da informao pelo dispositvo mvel

//delay necessrio para a

//temperatura do motor
temp = trtds.TempMotor(dados[4], dados[5]);
System.Console.Write("/\r");
bt.WriteLine("T" + temp);
}
else{
System.Console.Write("erro: bloco1");
}
if (ctrlBloco % 2 != 0){
if (con.solicitaDados(con, 2) == 1){

//bloco2

dados = con.blocoDados(con);
//Tempo de Injeo
TInj = trtds.TempoInjecao(dados[4],dados[5]);
System.Console.Write("-\r");
bt.WriteLine("I"+TInj);
System.Threading.Thread.Sleep(30);
//RPM

84

rpm = trtds.Rpm(dados[1], dados[2]);

//System.Console.WriteLine(rpm + "RPM ");
System.Console.Write("\\\r");
bt.WriteLine("R" + rpm);
System.Threading.Thread.Sleep(30);
//Tenso da Bateria
tensaoBat = trtds.TensaoBat(dados[7], dados[8]);
System.Console.Write("|\r");
bt.WriteLine("U" + tensaoBat.ToString("F2"));
System.Threading.Thread.Sleep(30);
}else{
System.Console.Write("erro: bloco2");
}
}
if (con.solicitaDados(con, 4) == 1)
{
dados = con.blocoDados(con);

//bloco 04

//RPM
rpm = trtds.Rpm(dados[1], dados[2]);
System.Console.Write("/\r");
bt.WriteLine("R" + rpm);
System.Threading.Thread.Sleep(30);
//Tempo de Injeo
TInj = trtds.TempoInjecao(dados[4], dados[5]);
System.Console.Write("-\r");
bt.WriteLine("I" + TInj);
System.Threading.Thread.Sleep(30);
//consumo
consumo = CountBloco.consumo(TInj);
System.Console.Write("\\\r");
bt.WriteLine("C" + consumo.ToString("F2"));
System.Threading.Thread.Sleep(30);
//Velocidade
vel= trtds.Velocidade(dados[7],dados[8]);
System.Console.Write("|\r");
bt.WriteLine("V"+vel);
System.Threading.Thread.Sleep(30);
//distncia
CountBloco.distancia(vel);
System.Console.Write("/\r");
bt.WriteLine("D" + CountBloco.dist.ToString("F3"));
System.Threading.Thread.Sleep(25);
}else{System.Console.Write("erro: bloco 4");}
if (ctrlBloco % 2 == 0)
{
if (con.solicitaDados(con, 9) == 1)
{
dados = con.blocoDados(con);

//bloco 09

//lambda
lambda = trtds.Lambda(dados[1], dados[2]);
bt.WriteLine("L" + lambda);
System.Console.Write("-\r");
System.Threading.Thread.Sleep(30);
}
else {
System.Console.Write("erro: bloco 9");
}
}
System.Console.SetCursorPosition(0,23);
ctrlBloco++;
}
}
//mtodo utilizado para sincronizao com o dispositivo mvel
public int sincroniza(SerialPort bt)
{
string sync = "";

85

while (sync != "sync") {

bt.WriteLine("sync");
sync = bt.ReadLine();
}
return 1;
}
}}

86

APNDICE B CDIGO FONTE DO SOFTWARE

EMBARCADO EM DISPOSITIVO MVEL APRESENTAO
DA INFORMAO AO CONDUTOR

Classe FrmApresentacao

using System;
using System.Linq;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO;
using System.IO.Ports;
using System.IO.Compression;

namespace SmartDeviceProject3
{

public delegate void recebeDados();

//declarao do mtodo delegado

public partial class FrmApresentacao : Form

{
public FrmApresentacao()
{

byte[] dado = new byte[1];

InitializeComponent();
System.Windows.Forms.TabControl tab = new TabControl();
System.Threading.Thread atualiza=new
System.Threading.Thread(atualizaInf);
Comm rs = new Comm();

87

rs.BaudRate = rs.txSinal();
rs.PortName = rs.con();
rs.DataBits = rs.bitDados();
rs.Handshake = rs.handShake();
rs.Parity = rs.paridade();
try
{
rs.Open();
if (sincroniza(rs) == 1)
{
atualiza.Start();
}

}
catch (Exception ) {
MessageBox.Show("Erro de sincronizao",
MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1);

"Erro",

MessageBoxButtons.OK,

}
}
//mtodo que sincroniza a comunicao com a aplicao embarcada no notebook
public int sincroniza(SerialPort rs) {

string sync = "";

while (sync != "sync") {
sync=rs.ReadLine();
rs.WriteLine("sync");

return 1;
}
public void atualizaDado(){

Comm rs = new Comm();

rs.PortName = "COM1";
rs.BaudRate = 9600;
//

rs.ReadTimeout = 5000;

rs.ReadTimeout = 30000;
rs.Open();

rs.DtrEnable = true;

string str;
str = rs.ReadLine();
if
str.Length - 1); }

(Convert.ToString(str[0]) == "1") { txtErro1.Text

//coleta o 1 erro do bloco de erros

str.Substring(1,

if
str.Length - 1); }

(Convert.ToString(str[0]) == "2") { txtErro2.Text

//coleta o 2 erro do bloco de erros

str.Substring(1,

88

if
str.Length - 1); }

(Convert.ToString(str[0]) == "3") { txtErro3.Text

//coleta o 3 erro do bloco de erros

str.Substring(1,

if
str.Length - 1); }

(Convert.ToString(str[0]) == "4") { txtErro4.Text

//coleta o 4 erro do bloco de erros

str.Substring(1,

str.Substring(1,

if (Convert.ToString(str[0]) == "R") { txtRpm.Text

str.Length - 1) + " RPM"; }
//coleta a rotao do motor

if (Convert.ToString(str[0]) == "T") { txtTemp.Text = str.Substring(1,

str.Length - 1) + " C"; }
//coleta a temperatura do lquido de arrefecimento
if (Convert.ToString(str[0]) == "I") { txtTInj.Text
str.Length - 1) + " ms"; }
//coleta tempo de injeo

str.Substring(1,

if (Convert.ToString(str[0]) == "U") { txtTensao.Text

str.Length - 1) + " V"; }
//coleta a tesno da bateria

str.Substring(1,

if (Convert.ToString(str[0]) == "C")
str.Length - 1) + " Km/l"; }
//coleta o consumo

str.Substring(1,

txtConsumo.Text

if (Convert.ToString(str[0]) == "V") { txtVelocidade.Text = str.Substring(1,

str.Length - 1) + " Km/h"; }
//coleta a velocidade
if (Convert.ToString(str[0]) == "D") {
str.Length - 1) + " Km"; }
//coleta a distncia
if
str.Length - 1); }

txtDist.Text

str.Substring(1,

(Convert.ToString(str[0]) == "L") { txtLambda.Text = str.Substring(1,

//coleta a relao lambda ( relao estequiomtrica)

rs.Close();
}
public void atualizaInf()
{
recebeDados da = new recebeDados(atualizaDado);
//loop

infinito

para

aquisio

dos

//instncia do mtodo delegado

dados,

para

que

os

campos

sejam

atualizados
// necessrio utilizar o mtodo invoke
while (1 == 1)
{
txtRpm.Invoke(da);
txtTemp.Invoke(da);
txtTInj.Invoke(da);
txtTensao.Invoke(da);
txtVelocidade.Invoke(da);
txtDist.Invoke(da);
txtLambda.Invoke(da);
txtErro1.Invoke(da);
txtErro2.Invoke(da);
txtErro3.Invoke(da);
txtErro4.Invoke(da);
}

}
private void menuItem2_Click(object sender, EventArgs e)
{
//mtodo que fecha a aplicao
if (MessageBox.Show("Deseja sair?", "Confirmao",
MessageBoxButtons.YesNo, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button1)==DialogResult.Yes)
{
Comm com = new Comm();

89

com.Close();
Application.Exit();
}
}

Classe Comm
using System;
using System.Linq;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.IO.Ports;

namespace SmartDeviceProject3
{
class Comm : System.IO.Ports.SerialPort
{
public const int InfiniteTimeout = 0;

public string con(){

string Nporta="COM1";

//Nome Porta virtual serial de

comunicao
return Nporta;
}
public int txSinal(){
int taxa = 9600;

//taxa de sinalizao da porta seria, 9600

baud
return (taxa);
}
public Parity paridade() {
string par = "None";

//Configurao do bit de paridade

return (Parity)Enum.Parse(typeof(Parity), par,true);

}
public int

stopBit() {

int stop = 1;

//Configurao do bit de stop

return (stop);
}
public Handshake handShake() {
string hndSke = "None";

//Confiura do handshake

return (Handshake)Enum.Parse(typeof(Handshake),hndSke,true);
}
public int bitDados() {
int bit = 8;
return(bit);
}

90

ANEXO A TABELA ASCII

91

92