CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA
FATEC SANTO ANDRÉ
Tecnologia em Eletrônica Automotiva
LUIZ RICARDO TRAJANO DA SILVA
TIAGO SANTOS DE ARAÚJO
FERRAMENTA DE DIAGNÓSTICO
AUTOMOTIVO OBD II
Santo André – São Paulo
2010
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Guias e Dicas
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Encontrar documentos
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Pesquisar documentos Store
Os melhores documentos à venda: Trabalhos de alunos formados
Videoaulas
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Quiz
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Comunidade
Pergunte à comunidade
Peça ajuda à comunidade e tire suas dúvidas relacionadas ao estudo
Ranking universidades
Descubra as melhores universidades em seu país de acordo com os usuários da Docsity
Guias grátis
Os eBooks que salvam estudantes!
Baixe gratuitamente nossos guias de estudo, métodos para diminuir a ansiedade, dicas de TCC preparadas pelos professores da Docsity
Ferramenta de Diagnostico Automotivo OBDII, Teses (TCC) de Eletrônica
Trabalho de Conclusão de Curso
Tipologia: Teses (TCC)
2020
1 / 108
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Documentos relacionados
Pré-visualização parcial do texto
Baixe Ferramenta de Diagnostico Automotivo OBDII e outras Teses (TCC) em PDF para Eletrônica, somente na Docsity!
CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA
FATEC SANTO ANDRÉ
Tecnologia em Eletrônica Automotiva
LUIZ RICARDO TRAJANO DA SILVA
TIAGO SANTOS DE ARAÚJO
FERRAMENTA DE DIAGNÓSTICO
AUTOMOTIVO OBD II
Santo André – São Paulo
CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA
FATEC SANTO ANDRÉ
Tecnologia em Eletrônica Automotiva
LUIZ RICARDO TRAJANO DA SILVA
TIAGO SANTOS DE ARAÚJO
FERRAMENTA DE DIAGNÓSTICO
AUTOMOTIVO OBD II
Monografia apresentada ao Curso de Tecnologia em Eletrônica Automotiva da FATEC Santo André, como requisito parcial para conclusão do curso em Tecnologia em Eletrônica Automotiva. Orientador: Professor. Weslley Medeiros Torres.
Santo André – São Paulo
AGRADECIMENTOS
Atenciosamente, a Deus e afetuosamente, as nossas famílias, enviamos nossa eterna
gratidão, pelo exemplo de vida, por oferecerem todo o suporte para nossa educação, semente
deste trabalho. E principalmente, por vibrarem a cada conquista.
De maneira especial, ao nosso orientador, o Professor Weslley Medeiros Torres, da
Faculdade de Tecnologia de Santo André – FATEC, por sua paciência e comprometimento
durante nosso trabalho em conjunto.
Gostaríamos de agradecer aos Professores Mestre. Cleber William Gomes, Mestre
Edson Kitani e Orlando Salvo Junior, pelo apoio que tivemos, e a todos aqueles que direta ou
indiretamente contribuíram para a realização deste trabalho. Agradecemos aos professores,
colaboradores e funcionários da Fatec Santo André por terem reservado um tempo de suas
vidas para a transmissão de seus conhecimentos e por sempre estarem dispostos a nos ajudar.
“É a chave que abre a porta lá do
quarto dos segredos. Vem mostrar que nunca
é tarde, vem mostrar que é sempre cedo. E
que para cada pecado sempre existe um
perdão. Não tem certo nem errado, todo
mundo tem razão, e que o ponto de vista é que
é o ponto da questão.”
Raul Seixas
ABSTRACT
With the increase of electronics, becomes crucial to the development of equipment, improve performance, enhance comfort and safety, controlling the emissions of pollutants and so on. In view of this, we propose a system that performs data acquisition, monitoring the operation of the vehicle and detecting possible failures. This monograph aims to develop an automotive scanner, whose function is the data acquisition modules present in existing electronic systems in vehicles equipped with onboard diagnostics, second-generation. Compound of hardware elements, based on a microcontroller and an integrated circuit family ELM.
Key Word: Vehicle Diagnose, OBD II (on board diagnostics), automotive scanner, DTCs (Diagnostic Trouble Codes).
LISTA DE ILUSTRAÇÕES
- FIGURA 1: COMBUSTÍVEL DA ELETRÔNICA EMBARCADA.........................................................
- FIGURA 2 ARQUITETURA CENTRALIZADA
- FIGURA 3: ARQUITETURA DISTRIBUÍDA
- FIGURA 4 : RESPONSABILIDADE X COMPLEXIDADE.................................................................
- FIGURA 5: CONECTOR OBDII................................................................................................
- FIGURA 6: EXEMPLO DO CÓDIGO DTC P0143........................................................................
- FIGURA 7: ARQUITETURA DE REDE OBD-II............................................................................
- FIGURA 8: BARRAMENTO DE DIAGNÓSTICO ISO 9141-2.........................................................
- FIGURA 9: TOPOLOGIA KWP
- FIGURA 10 : TEMPO DE 1 BIT
- FIGURA 11: EXEMPLO DE COMUNICAÇÃO USART ASSÍNCRONO.............................................
- FIGURA 12: PINAGEM DO ELM-327
- FIGURA 13: DIAGRAMA DE BLOCOS DA FERRAMENTA DE DIAGNÓSTICO AUTOMOTIVO
- FIGURA 14: ESQUEMA DO HARDWARE DA COMUNICAÇÃO COM O VEÍCULO.
- FIGURA 16: CIRCUITO DE INTERFACE ENTRE USUÁRIO E HARDWARE DE CONTROLE...................
- FIGURA 15: CONFIGURAÇÃO BÁSICA DO MICROCONTROLADOR...............................................
- FIGURA 17: ESQUEMA LIGAÇÃO E COMUNICAÇÃO COM O DISPLAY DE LCD
- FIGURA 18: ESQUEMA GERAL DA FERRAMENTA DE DIAGNÓSTICO AUTOMOTIVO......................
- FIGURA 19:ESQUEMA DE LIGAÇÃO DO ELM327.....................................................................
- FIGURA 20: SOFTWARE OBDSPY
- FIGURA 21: AQUISIÇÃO DE DADOS SOFTWARE DE MONITORAMENTO.
- FIGURA 22: FUNÇÃO ENVIA
- FIGURA 23: FUNÇÃO RECEBEMASK.
- FIGURA 25: FUNÇÃO ASCII
- FIGURA 24: DESIGN DE SOFTWARE DE ALTO NÍVEL
- FIGURA 26: FUNÇÃO FALHA
- FIGURA 27: TRATAMENTO DO DADO DA PRESSÃO DO COLETOR DE ADMISSÃO
- FIGURA 28: TRATAMENTO DE DADOS DA ROTAÇÃO
- FIGURA 29: TRATAMENTO DE DADOS DE VELOCIDADE
- FIGURA 30: TRATAMENTO DE DADOS DO AVANÇO DA IGNIÇÃO
- FIGURA 31: TRATAMENTO DE DADOS DA TPAR
- FIGURA 32: TRATAMENTO DE DADOS DA POSIÇÃO DA VÁLVULA BORBOLETA
- FIGURA 33: TRATAMENTO DOS DADOS DO DTC
- FIGURA 34:FUNÇÃO APAGAR CÓDIGO DE FALHA
- FIGURA 35: TELA INICIAL
- FIGURA 36 : TELA PRINCIPAL
- FIGURA 37 : PARÂMETROS DTC1
- FIGURA 38 : PARÂMETROS DTC2
- FIGURA 39: NÚMERO DE DTC`S
- FIGURA 40: NÚMERO DTC`S
- FIGURA 41: IDENTIFICAÇÃO DTC`S
- FIGURA 42: APAGAR DTC`S..................................................................................................
- TABELA 1: CÓDIGO DE FALHA 1 º DÍGITO LISTA DE TABELAS
- TABELA 2: CÓDIGO DE FALHA 2 º DÍGITO
- TABELA 3: CÓDIGO DE FALHA 3 º DÍGITO
- TABELA 4: PARÂMETROS DE LEITURA
- TABELA 5: INICIALIZAÇÃO
- TABELA 6: EXEMPLO DE MENSAGENS ENVIADAS E RECEBIDAS
- TABELA 7: EXEMPLO DE REQUISIÇÃO DE CÓDIGOS DE FALHA
- TABELA 8: REQUISIÇÃO PARA APAGAR MEMÓRIA
- TABELA 9: SIMULAÇÃO DA FERRAMENTA DE DIAGNÓSTICO AUTOMOTIVO
- 1 INTRODUÇÃO SUMÁRIO
- 1.1 OBJETIVOS E MOTIVAÇÃO
- 1.2 CONTEÚDO
- SISTEMA DIAGNÓSTICO EMBARCADO
- 2.1 ELETRÔNICA EMBARCADA
- 2.2 TECNOLOGIAS DE ARQUITETURAS ELETRÔNICAS
- 2.2.1 Arquitetura Centralizada
- 2.2.2 Arquitetura Distribuída
- 2.3 DIAGNÓSTICO VEICULAR
- 2.3.1 OBD no Brasil..........................................................................................
- 2.3.2 Resolução CONAMA Nº
- 2.3.3Resolução CONAMA Nº
- 2.4 CONECTOR PADRÃO OBD II
- 2.4.1 Localização
- 2.4.2 Pinagem
- 2.5 CÓDIGOS DE FALHA DE DIAGNÓSTICO
- 2.6 PROTOCOLOS DE COMUNICAÇÃO DE DIAGNOSE
- 2.6.1 Protocolo ISO 9141-2 – A norma mais utilizada.......................................
- 2.6.2 Protocolo ISO 14230 (KWP 2000)
- 2.6.3 Protocolo SAE J1850
- 2.6.4 Protocolo ISO
- 2.6.5 Protocolo ISO 1939..................................................................................
- 2.7 COMUNICAÇÃO SERIAL – UART
- 2.7.1 Modo Assíncrono
- 2.8 ELM
- 2.8.1 As aplicações do dispositivo ELM327
- 2.8.2 Características Principais:
- 3.METODOLOGIA
- 3.1 REQUISITOS DO PRODUTO
- 3.2 SOLUÇÕES TÉCNICA
- 3.2.1 Hardware
- 3.2.1.1 ELM 327.
- 3.2.1.2 Microcontrolador PIC16F877A
- 3.2.1.3 Teclas e Display de interface.
- 3.2.2 Software
- 3.2.2.1 Requisitos do software.......................................................................
- 3.2.2.2 Design do Software.
- 3.2.2.2.1 Design de Alto Nível
- 3.2.2.2.1 Design detalhado
- 3.2.2.2.1.1 Inicialização
- 3.2.2.2.1.1 Parâmetros de leitura.
- 3.2.2.2.1.3 Códigos de falha DTC.
- 3.2.2.2.1.4 Apagar DTC
- ANÁLISE DOS RESULTADOS
- 4.1 SIMULAÇÃO.
- 4.2 TESTES NO VEÍCULO
- 4.3 RESULTADOS
- 4.3 SESSÃO DE DIAGNÓSTICO
- 4.3.1 Parâmetros de Leitura..............................................................................
- 4.3.2 Leitura dos DTC`s
- CONCLUSÃO.....................................................................................................
- 5.1 PROPOSTAS FUTURAS
- REFERÊNCIAS..................................................................................................
- ANEXO
- ANEXO A – CÓDIGO DO PROGRAMA.
- ANEXO B – DATASHEET ELM-327 – COMANDO AT.
- ANEXO C - LISTA COM OS DTC`S
1 INTRODUÇÃO
A indústria automotiva motivada pela redução nos custos de produção, pelas leis que limitam os níveis de emissões de gases resultantes do processo de combustão, pelo aumento da segurança e conforto dos ocupantes e por melhorias de desempenho, iniciou a substituição dos antigos sistemas (mecânicos, hidráulicos e pneumáticos) que possuíam eficiência muito menor por sistemas eletrônicos. (TOSI & GALVÃO & LIMA, 2008).
Segundo Guimarães (GUIMARÃES, 2003), a eletrônica embarcada representa todo e qualquer sistema eletro-eletrônico montado em uma aplicação móvel. Este conceito iniciou-se nos veículos através da ECU, Unidade Eletrônica de Controle (Electronic Control Unit) , que fisicamente, nada mais é que um módulo eletrônico responsável por realizar um determinado controle. Em um primeiro momento foram colocadas diversas ECUs responsáveis pelo controle de diferentes componentes, porém com o passar do tempo comprovou se ser indispensável a troca de informação entre elas, o que levou ao surgimento de um barramento eletrônico eficiente, robusto e flexível. Desenvolvia-se então o CAN (Controller Area Network).
Tornava-se então indispensável uma ferramenta padrão que permita a verificação do funcionamento de cada módulo eletrônico existente em um veículo. No principio cada fabricante desenvolveu seu próprio sistema de diagnóstico, com software e interface específica, o que acarretava a ocorrência de inúmeros problemas, devido a quando houvesse uma falha, como cada fabricante tinha códigos e especificações próprias, era relativamente complexo realizar o diagnóstico.
Então, em 1988, a SAE (Society of Automotive Engineers) com ajuda da EPA
(Environmental Protection Agency) criou o OBD (On ‐ Board Diagnosis) , o sistema de
diagnose de bordo para controle das emissões e de identificação da provável origem das falhas DTCs (Diagnostic Trouble Codes) armazenados na memória da unidade de controle do motor. Serve também para monitorar componentes do carro e pode também executar rotinas de diagnóstico permitindo prever falhas e adiantar consertos e substituições necessárias.
Sua primeira versão era simples, conforme Belo (BELO, 2003), não se padronizava as mensagens utilizadas pelas diversas montadoras, eram realizadas leituras de um reduzido número de códigos de falha e monitorava-se alguns sensores. Na segunda versão esses problemas foram solucionados e inúmeros dados podem ser lidos através do agora OBDII,
comunicação serial. No capítulo 3 será detalhado todo processo de aplicação da metodologia utilizada no desenvolvimento do projeto. No capítulo 4 descrevem os ensaios e os resultados obtidos, estratificando-os para um estudo comparativo entre o desejado e o realizado. Analisar-se-á se a meta foi atingida e quais foram as dificuldades encontradas neste projeto. Finalmente, no capítulo 5 discutem-se as conclusões obtidas dos resultados e a proposição de novos estudos e desafios.
2. SISTEMA DIAGNÓSTICO EMBARCADO
2.1 Eletrônica embarcada
Segundo Guimarães, a eletrônica embarcada representa todo e qualquer sistema eletro- eletrônico montado em uma aplicação móvel, seja em um automóvel, um navio ou um avião. (GUIMARÃES, 2003).
Conforme Andreatini (ANDREATINI, 2003), o processo da penetração da eletrônica no mercado automotivo, foi lento, devido principalmente à relação de custo benefício. Historicamente a eletrônica embarcada teve seu início na década de 1960, porém naquele momento, devido a ser uma imposição e não por um desejo dos consumidores, não obteve sucesso. Durante a década de 1970 dois eventos retomaram sua inclusão:
- A redução do consumo de combustível e a introdução de leis governamentais para a redução da emissão de poluentes na atmosfera.
- O desenvolvimento a custos relativamente baixos de dispositivos em estado sólido, o que facilitou a introdução da eletrônica digital no gerenciamento de motores.
A indústria automotiva vem há anos utilizando-se de sistemas eletro-eletrônicos no controle de funções do veículo, boa parte destes foi desenvolvido de forma independente, sendo cada um responsável por um determinado tipo de função. Contudo com o passar do tempo provou-se indispensável o compartilhamento de informações, mais facilmente conseguido através da utilização dos sistemas eletro-eletrônicos interligados, sendo cada um responsável por uma função, na qual todas juntas se completam. (TOSI & GALVÃO & LIMA, 2008).
Desde então a utilização da eletrônica embarcada se incrementa dia à dia, e será ainda maior no futuro. Abaixo, descrevem-se algumas das presentes e futuras aplicações da eletrônica embarcada no automóvel:
- Redes de comunicação, navegação e entretenimento.
- Direção ativa
- Freios eletrônicos
- Conforto e Segurança
Atualmente, no setor automobilístico destacam-se dois tipos: arquitetura centralizada e a arquitetura distribuída.
2.2.1 Arquitetura Centralizada
Neste tipo de arquitetura uma única ECU ( Eletronic Control Unit ) é responsável por todo o controle existente no sistema, recebendo os sinais de entrada (através dos sensores), os processando e comandando as respectivas saídas (atuadores) de controle do sistema.
Figura 2 Arquitetura Centralizada (Fonte: Notas de aula do professor Kleber N. Hodel, 2009)
O diagrama esquemático que representa este conceito de arquitetura é apresentado na figura 2. Dentro da ECU são encontrados o hardware e software que permitem a leitura das entradas, seu processamento e a atuação das saídas, além da diagnose para verificação de seu funcionamento.
Como vantagens podem destacar:
- Facilidade na coleta de informações do sistema devido a todos os dados de entrada serem disponíveis para ECU durante toda a operação.
- Simplicidade do hardware , sendo constituído de sensores e atuadores, cabeamento e uma ECU para controle e processamento de dados.
- Baixo custo de desenvolvimento Como desvantagens podem destacar:
- Limitação das possibilidades de expansão do sistema.
- Grande quantidade de cabeamento. 2.2.2 Arquitetura Distribuída
Neste tipo de arquitetura, num mesmo sistema de controle, várias ECU´s interligadas, dividem o controle e processamento de diversas funções existentes no veículo.
Figura 3: Arquitetura Distribuída (Fonte: Notas de aula do professor Kleber N. Hodel, 2009)
O diagrama esquemático que representa este conceito de arquitetura é apresentado na figura 3. As ECU´s encontram-se interligadas, dividindo entre elas a execução de diversas funções existentes no veículo. Tendo seu funcionamento monitorado pela diagnose através de um protocolo de comunicação.
Como vantagens podemos destacar:
- Maior robustez do sistema de controle.
- Facilidade na ampliação do sistema.
- Quantidade reduzida de cabeamento.
- Possibilita modularização do projeto do sistema e da execução dos testes de validação, aumentando assim a confiabilidade.
Como desvantagens podemos destacar:
-Implica a existência de um software de controle da rede de comunicação.