CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA FATEC SANTO ANDRÉ

Transcrição

1 CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA FATEC SANTO ANDRÉ Tecnologia em Eletrônica Automotiva ADEMAR DULTRA CERQUEIRA FERNANDO VENEZIAN BEZERRA GUILHERME ZAMBONI THOMAS EDSON SISTEMA DE DIAGNÓSTICO PARA VEÍCULOS QUE UTILIZAM OS PROTOCOLOS ISO 9141 E ISO ATRAVÉS DE UMA PLATAFORMA EM LabVIEW Santo André São Paulo 2009

2 CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA FATEC SANTO ANDRÉ Tecnologia em Eletrônica Automotiva ADEMAR DULTRA CERQUEIRA FERNANDO VENEZIAN BEZERRA GUILHERME ZAMBONI THOMAS EDSON SISTEMA DE DIAGNÓSTICO PARA VEÍCULOS QUE UTILIZAM OS PROTOCOLOS ISO 9141 E ISO ATRAVÉS DE UMA PLATAFORMA EM LabVIEW Monografia apresentada ao Curso de Tecnologia em Eletrônica Automotiva da FATEC Santo André, como requisito parcial para conclusão do curso de Tecnologia em Eletrônica Automotiva Orientador: Prof. Orlando Salvo Junior Co-orientador: Prof. Edson Kitani Santo André São Paulo 2009

3 Dedicamos este trabalho a nossas famílias e amigos que sempre estiveram próximos durante esta jornada.

4 AGRADECIMENTOS Gostaríamos de agradecer a todos aqueles que direta e indiretamente contribuíram para a realização deste trabalho e principalmente aos colegas de sala que mantiveram estímulos nos momentos mais árduos desta jornada. Agradecemos aos professores, colaboradores e funcionários da Fatec Santo André que sempre estiveram prontos a nos ajudar. Agradecemos também ao professor Cleber Gomes que nos disponibilizou o hardware utilizado do desenvolvimento deste trabalho, e à Fatec por disponibilizar o veículo Volkswagen Golf e os demais equipamentos que tornaram possível o desenvolvimento deste trabalho.

5 RESUMO Os sistemas de diagnóstico veicular surgiram para controlar os níveis de emissões de poluentes dos veículos automotores, através da leitura de informações e detecção de falhas nos veículos. Este trabalho teve como idéia inicial o desenvolvimento de um sistema de diagnóstico veicular, para permitir ao usuário acesso às informações do veículo através de uma interface gráfica amigável e de fácil manuseio. Esta interface foi desenvolvida através de uma plataforma em LabVIEW que realiza a comunicação através de uma porta serial. Para a comunicação desta porta serial com o conector de diagnóstico OBD II, foi utilizado um hardware baseado em um circuito integrado da família ELM para a leitura dos protocolos ISO 9141 e ISO (KWP 2000). Como resultado, foram extraídas informações do veículo, como tensão da bateria, rotação do motor e os códigos de falhas armazenados. Palavras chaves: OBD II, ISO 9141, ISO 14230, KWP 2000 e LabVIEW.

6 ABSTRACT The vehicle diagnostic systems have emerged to control the emissions of pollutants from motor vehicles, by reading information and fault detection in vehicles.this work had as an initial idea to develop a diagnostic system for vehicles, to allow the user access the vehicle information through a friendly interface and easy to use. This interface was developed using LabVIEW platform that performs communication through a serial port. For the communication of this serial port with the diagnostic connector OBD II, it was used a hardware based on an integrated circuit from the ELM family that read the protocols ISO 9141 and ISO (KWP 2000). Datas were extracted from the vehicle, such as battery voltage, engine speed and the fault codes stored. Key word: OBD II, ISO 9141, ISO 14230, KWP 2000 and LabVIEW.

7 LISTA DE ILUSTRAÇÕES Figura 2.1 Barramento de diagnóstico ISO Figura 2.2 Topologia KWP Figura 2.3 Conector OBD II Figura 2.4 Formato do código DTC através de 2 bytes Figura 2.5 Painel Frontal e diagrama de blocos do LabVIEW Figura 3.1 Esquema elétrico para a utilização dos protocolos ISO 9141 e ISO através do ELM Figura 3.2 Circuito fonte de alimentação Figura 3.3 Circuito USB/Serial usando CP Figura 3.4 VI para escrita e leitura de dados na serial Figura 3.5 Leitura da rotação do motor Figura 3.6 Tratamento da leitura de tensão da bateria Figura 3.7 Gráfico da relação entre o valor de rotação obtido e o valor de rotação real indicado no conta-giros Figura 3.8 Tratamento da leitura de rotação Figura 3.9 Tratamento da verificação da quantidade de falhas Figura 3.10 Tratamento da leitura dos códigos de falha Figura 4.1 Leituras de tensão da bateria e rotação Figura 4.2 Leitura dos códigos de falha Figura Aparência final do Software... 41

8 LISTA DE TABELAS Tabela 2.1 Principais normas ISO e SAE Tabela 2.2 Primeiro dígito do código de falhas Tabela 2.3 Primeiro e segundo dígitos do código de falhas Tabela 2.4 Terceiro dígito do código de falhas Tabela 2.5 Diferenças entre o ELM323 e ELM Tabela 3.1 Relação entre o valor de rotação obtido e o valor de rotação real indicado no conta-giros Tabela 3.2 Lista de caracteres que devem substituir o primeiro dígito do código de falha recebido... 37

9 SUMÁRIO 1 INTRODUÇÃO HISTÓRICO DOS SISTEMAS DE DIAGNÓSTICO VEICULAR E DA LINGUAGEM LABVIEW Protocolos de Comunicação Automotivos Classe A Classe B Classe C Utilizados em diagnóstico Utilizados em Mobile Media Utilizados em Safety Bus Utilizados em aplicações BY-WIRE Protocolos de Comunicação Utilizados em Diagnóstico O protocolo ISO O protocolo KWP 2000 (ISO 14230) O Conector OBD II Localização Pinagem Códigos de Falha O Circuito Integrado ELM Comunicação O Circuito Integrado ELM Comunicação Instrumentação Virtual Considerações Finais METODOLOGIA O Hardware Utilizado Funcionamento do circuito Desenvolvimento do Software Tratamento da leitura de tensão da bateria Tratamento da leitura de rotação Leitura dos códigos de falha Tratamento da verificação da quantidade de falhas Tratamento da leitura dos códigos de falha... 36

10 4 ANÁLISE DE RESULTADOS Leitura de Tensão da Bateria Leitura de Rotação Leitura da Quantidade de Falhas Leitura dos Códigos de Falha (DTC) Apagando os Códigos de Falha Software Final CONCLUSÃO Propostas Futuras REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS Anexo A Código do Programa em LabVIEW Anexo B Lista dos DTC s Anexo C Datasheet ELM 327 Anexo D Esquema Elétrico ELM 327

11 1 INTRODUÇÃO Todos os veículos produzidos atualmente dispõem de uma ou mais ECU s (Electronic Control Unit), responsáveis pelo gerenciamento de determinados parâmetros do veículo para garantir seu correto funcionamento. As relações entre esses parâmetros devem permanecer delimitadas, e dependendo das condições externas podem sair de sua faixa, gerando um mau funcionamento do veículo. Os principais parâmetros que determinam o funcionamento do motor, que devem ser verificados se estão funcionando corretamente são: velocidade, carga, temperatura do motor, consumo de combustível, temperatura ambiente, fluxo de ar e emissões de poluentes, sendo que este último é o principal parâmetro para o qual o sistema de diagnóstico foi desenvolvido. Para ler estes parâmetros, os automóveis atuais incorporam um grande número de sensores, que fornecem informações para a ECU referentes às condições externas do veículo, para que a ECU decida como atuar sobre o motor. Se algum dos parâmetros estiver fora da faixa delimitada, o sistema OBD II (On-Board Diagnostics Second Generation) é responsável por armazenar esta informação e notificar ao motorista através do painel de instrumentos que há alguma anormalidade no veículo, orientando-o a encaminhar o veículo a uma oficina ou concessionária. Quando o veículo chega à oficina ou concessionária, os técnicos podem acessar as informações armazenadas pelo sistema OBD II e verificar quais as falhas que ocorreram no veículo, corrigindo-as quando necessário, sem precisar realizar vários testes para detectar a procedência do erro. Evidentemente, o sistema não é perfeito, e geralmente quando ocorre uma falha no veículo, esta pode desencadear uma série de falhas induzidas, que também são armazenadas. Neste caso, é necessário um conhecimento mais profundo para detectar a origem ou procedência do problema. Este trabalho tem o objetivo de desenvolver um sistema de diagnóstico veicular utilizando um software desenvolvido em LabVIEW. O LabVIEW é um ambiente de programação criado pela National Instruments que utiliza a linguagem gráfica para o desenvolvimento de aplicativos. Sua forma de programação é altamente produtiva na construção de sistemas voltados para aquisição de dados e instrumentação e permite também a comunicação (transmissão e aquisição de dados) através de uma porta serial RS232. Para realizar a comunicação entre o sistema OBD II do veículo e a porta serial, foi utilizado um hardware baseado em circuito integrado da família ELM. Este circuito integrado

12 11 permite a conversão entre o formato de dados OBD II para o formato de dados do padrão serial RS232. Com isto, através do software desenvolvido no LabVIEW foi possível obtermos a comunicação com o veículo através de um computador pessoal utilizando somente uma porta serial. No capítulo 2, é relatado um histórico sobre os temas que foram pesquisados para o desenvolvimento deste trabalho. Entre estes temas estão os sistemas de diagnóstico veicular, bem como os protocolos de comunicação automotivos utilizados em diagnóstico, o padrão OBD II, os circuitos integrados da família ELM e a instrumentação virtual baseado em LabVIEW. No capítulo 3 descreve-se a metodologia utilizada no desenvolvimento do trabalho. No capítulo 4 apresentam-se os resultados de comunicação e monitoração, bem como a plataforma de teste com o veículo. Finalmente, no capítulo 5 encontram-se as conclusões e propostas futuras.

13 2 HISTÓRICO DOS SISTEMAS DE DIAGNÓSTICO VEICULAR E DA LINGUAGEM LABVIEW Segundo Guimarães (2007), o termo diagnóstico veicular representa as ferramentas que permitem a verificação do funcionamento dos módulos eletrônicos existentes em um veículo e também a programação dos mesmos. Durante os anos 70 e início dos anos 80, alguns fabricantes começaram a utilizar sistemas eletrônicos para controle e diagnóstico de falhas em veículos. A princípio, estes sistemas eram utilizados apenas para conhecer e controlar os níveis de emissões dos veículos e adaptá-los aos padrões exigidos, porém com o passar do tempo estes sistemas foram se tornando cada vez mais sofisticados, até que nos anos 90 surgiu o padrão OBD II. ( O OBD II, sigla de On Board Diagnostic Second Generation, é um sistema para diagnosticar as falhas que ocorrem no veículo sem a necessidade de desmontar as peças para descobrir a origem do erro. Belo (2003), afirma que os sistemas de diagnóstico a bordo foram desenvolvidos para controlar o nível de emissões de poluentes dos veículos automotores dentro dos padrões determinados. A primeira geração destes sistemas controlava o nível de emissões de forma relativamente eficaz, porém havia alguns problemas graves no sistema. O principal problema estava relacionado ao fato de os mesmos poderem detectar falhas apenas quando o componente era completamente danificado, fazendo com que o veículo permanecesse durante muito tempo operando em condições inadequadas, aumentando o nível de emissão de poluentes. Outro problema era a falta de padronização das informações fornecidas por estes sistemas para o diagnóstico de falhas, pois cada fabricante era livre para incorporar seu próprio conector e utilizar códigos proprietários. Desta forma, o acesso às informações de diagnóstico era obtido somente por ferramentas proprietárias de cada fabricante. Este sistema de codificação única encontra-se implantado em todos os veículos de passageiros e veículos comerciais leves produzidos atualmente, e diferente dos sistemas desenvolvidos antes de 1996, é caracterizado como um sistema padronizado, que permite visualizar facilmente quais as falhas ocorridas no veículo utilizando códigos padronizados.

14 Protocolos de Comunicação Automotivos Protocolos de comunicação são meios de transmissão e recepção de dados utilizados para intercomunicar módulos eletrônicos e/ou sensores e atuadores inteligentes equipados com microcontroladores e tranceivers, por exemplo. Existem vários tipos de protocolos de comunicação, cada qual com suas características técnicas específicas e, portanto, com as suas aplicações mais apropriadas. (GUIMARÃES, 2007, p.209). A seguir, descreveremos as classes de protocolos existentes e os diversos tipos de protocolos existentes em cada uma destas classes Classe A Estão nesta classe os protocolos que utilizam taxa de transmissão de até 10Kbps. Segundo Guimarães (2007), estes protocolos geralmente estão relacionados às funções de conforto de um veículo. Alguns dos protocolos pertencentes à Classe A são: - SINEBUS - 1ºC - SAE J CCD - ACP - BEAN - LIN Classe B Estão nesta classe os protocolos que utilizam taxa de transmissão de 10Kbps a 125Kbps. Segundo Guimarães (2007), estes protocolos geralmente estão relacionados ao controle dos sistemas de entretenimento de um veículo. Alguns dos protocolos pertencentes à Classe B são: - CAN 2.0 ISO11898 e ISO CAN 2.0 SAE J J1859 Classe 2 - J1850 SCP - J1850PCI

15 Classe C Estão nesta classe os protocolos que utilizam taxa de transmissão de 125Kbps a 1Mbps. Segundo Guimarães (2007), estes protocolos geralmente estão relacionados ao controle dos sistemas de segurança de um veículo. Alguns dos protocolos pertencentes à Classe C são: - CAN 2.0 ISO11898 e ISO CAN 2.0 SAE J Utilizados em diagnóstico Nesta classe, estão os protocolos utilizados nos sistemas de diagnóstico embarcado On-Board Diagnosis (OBD). Alguns dos protocolos pertencentes à classe de Diagnóstico são: - J1850 Classe 2 - J1850 SCP - J1850 PCI - ISO ISO14230 (KWP2000) Utilizados em Mobile Media Segundo Guimarães (2007), são os protocolos utilizados na implementação do conceito PC-on-wheels ou computador sobre rodas. Alguns dos protocolos pertencentes à classe Mobile Media são: - IDB-C - MOST - MML - USB - IEEE Utilizados em Safety Bus São os protocolos utilizados em sistemas de airbag. Alguns dos protocolos pertencentes a esta classe são: - BST - Safe By Wire - DSI - Byte Flight

16 Utilizados em aplicações BY-WIRE Segundo Guimarães (2007), são os protocolos utilizados em aplicações nas quais sistemas eletromecânicos substituem os sistemas puramente mecânicos (direção, freio, aceleração, entre outros). Alguns dos protocolos pertencentes a esta classe são: - TTP - FlexRay - TTCAN 2.2 Protocolos de Comunicação Utilizados em Diagnóstico Existem vários protocolos de comunicação utilizados nos sistemas de diagnóstico, e algumas organizações de padronizações trabalham no desenvolvimento de padrões para protocolos de diagnose veicular. As duas principais organizações são a ISO (International Organization for Standardization) e a SAE (Society of Automotive Engineers). Cada protocolo exige um tratamento de informações antes de utilizar o conector de diagnóstico do veículo com o equipamento de diagnóstico externo, portanto necessitam de interfaces de conexão diferentes. Há equipamentos de diagnóstico capazes de utilizar todos os protocolos e ainda selecionar automaticamente qual o protocolo utilizado pelo veículo. Além da norma ISO 9141 que é a mais utilizada para diagnóstico, a Tabela 2.1 mostra as outras principais normas utilizadas em diagnóstico veicular. ISO SAE J J J J J2284 Tabela 2.1 Principais normas ISO e SAE (Fonte: Baseado no Seminário de Diagnose Veicular, AEA 2003) O protocolo ISO 9141 A norma ISO 9141 é a mais utilizada e referenciada por outras normas que também são utilizadas para diagnóstico. Segundo Guimarães (2007), ela descreve os requisitos

17 16 necessários para realização da comunicação entre os módulos eletrônicos do veículo e os equipamentos de diagnóstico. Os módulos eletrônicos do veículo devem possuir uma ou duas linhas de comunicação utilizadas para inspeção, teste e diagnose. Nos veículos que possuem apenas uma linha de comunicação, esta linha é a chamada linha K (K-line), e nos veículos que possuem duas linhas de comunicação, estas linhas são chamadas de linhas K e L (K-line e L-line). A linha K é a que fornece informação em uma forma digital serial, a partir do módulo eletrônico até o equipamento de diagnóstico. Ela pode ser utilizada também bidirecionalmente, transmitindo comandos ou dados a partir do equipamento de diagnóstico para o módulo eletrônico. Já a linha L é unidirecional a partir do equipamento de diagnóstico para o módulo eletrônico (GUIMARÃES, 2007). A Figura 2.1 ilustra um barramento com a conexão das linhas K e L simultaneamente a dois ou mais módulos eletrônicos. Figura 2.1 Barramento de diagnóstico ISO (Fonte: Baseado no Seminário de Diagnose Veicular, AEA 2003) O protocolo KWP 2000 (ISO 14230) Segundo Póvoa (2007), em meados dos anos 90 várias empresas se uniram para criar um protocolo de comunicação padronizado. Este protocolo posteriormente foi chamado de Keyword Protocol 2000, ou KWP Hoje este protocolo é muito utilizado no desenvolvimento de módulos eletrônicos e ferramentas de diagnóstico para o setor automobilístico. Este protocolo, assim como a ISO 9141 possui como estrutura duas linhas seriais para transmissão de dados: a linha K, que é utilizada para comunicação e inicialização, e a linha L, que é opcional e utilizada apenas para inicialização. A Figura 2.2 ilustra a forma geral desta comunicação serial.

18 17 Figura 2.2 Topologia KWP 2000 (Fonte: ISO :1999) Segundo Guimarães (2007), o KWP 2000 foi desenvolvido para possibilitar a implementação de serviços em uma ligação física da norma ISO Permite a compatibilidade com as implementações ISO existentes, e ao mesmo tempo inclui novas opções para permitir maior flexibilidade e desempenho. 2.3 O Conector OBD II O conector do sistema OBD II deve atender as seguintes especificações, segundo a norma ISO :2004: Localização Em veículos de passageiro e veículos comerciais leves, a localização do conector deve atender às seguintes especificações: Próximo ao assento do passageiro ou motorista Próximo ao painel de instrumentos Distância de 300mm além da ECU Fácil acesso ao assento do motorista Entre a coluna de direção e a ECU

19 Pinagem 2.3. O conector possui 16 pinos, sendo que os pinos utilizados estão descritos na Figura Figura 2.3 Conector OBD II (Fonte: Notas de aula do professor Orlando Salvo Junior, 2009) 2.4 Códigos de Falha Os códigos de falha devem seguir o seguinte padrão: O primeiro dígito indica a localização da falha no veículo. Os possíveis valores deste código são mostrados na Tabela 2.2. Valor P B C U Grupo Sistema Motor (Power Train) Carroceria (Body) Chassi (Chassis) Rede Tabela 2.2 Primeiro dígito do código de falhas (Fonte: BELO, 2003)

20 19 O segundo dígito indica qual a entidade responsável pela sua definição. Através deste dígito é possível verificar se o código em questão é comum a todos os fabricantes (padrão ISO/SAE) ou se é um código específico do fabricante. A Tabela 2.3 mostra os possíveis valores deste dígito. Grupo Sistema (Primeiro Dígito) P Controle (Segundo Dígito) ISO/SAE Fabricante Fabricante Reservado B ISO/SAE Fabricante Fabricante Reservado C ISO/SAE Fabricante Fabricante Fabricante/Reserva ISO/SAE U ISO/SAE Fabricante ISO/SAE Fabricante/Reserva ISO/SAE Tabela 2.3 Primeiro e segundo dígitos do código de falhas (Fonte: Notas de aula do professor Orlando Salvo Junior, 2009) O terceiro dígito refere-se a um subgrupo de funções do veículo, e o quarto e quinto dígitos referem-se à falha específica no referido subgrupo. Na Tabela 2.4 são exibidos os valores do terceiro dígito. Valor Descrição 0 Sistema Eletrônico Completo 1 Controle Ar/Combustível 2 Controle Ar/Combustível; Circuito de Injeção 3 Sistema de Ignição 4 Controle Auxiliar de Emissões 5 Controle de Velocidade do Veículo e Controle de Rotação em Marcha Lenta 6 Circuitos de Entrada e Saída da Central Eletrônica 7 Transmissão 8 Transmissão Tabela 2.4 Terceiro dígito do código de falhas (Fonte: Notas de aula do professor Orlando Salvo Junior, 2009) O código de falhas DTC (Diagnostic Trouble Code) é formado por dois bytes, dispostos conforme a Figura 2.4. Figura 2.4 Formato do código DTC através de 2 bytes. (Fonte: ISO :2006)

21 O Circuito Integrado ELM323 Desde 1996, os veículos fabricados nos Estados Unidos da América devem possuir uma porta de dados OBD II para a conexão com equipamento de teste. Esta porta é utilizada para se obter informações de diagnóstico relacionadas a emissões e, em alguns casos, pode ser utilizada também para se obter parâmetros de operação do veículo em tempo real. O ELM 323 é um circuito integrado de 14 pinos capaz de converter dados entre o formato de dados OBD II e o formato de dados serial RS232 padrão. Isto permite que qualquer computador pessoal se comunique com um veículo usando apenas uma porta serial padrão e um programa terminal. Este circuito suporta grande parte dos protocolos veiculares inclusos na ISO9141 e ISO14230 (KWP2000), mas não todos Comunicação O ELM323 depende de uma conexão serial do tipo RS232 padrão para poder se comunicar com o usuário. Todas as respostas dadas pelo ELM323, são terminadas com um caractere simples de retorno. No início da comunicação, o ELM323 envia uma mensagem informando a versão do CI (circuito integrado), o que permite que seja verificado se as configurações do software utilizado estão de acordo com as do CI. Sempre que o ELM323 está em estado de espera, pronto para receber dados pela porta RS232, é enviado o caractere ">". As mensagens enviadas pelo computador também podem ser destinadas para uso interno do ELM323 ou para reformatar e passar pelo barramento OBD. Uma vez que a mensagem completa tenha sido recebida, o ELM323 pode determinar rapidamente para onde os dados devem ser enviados, isso através da análise completa dos dados recebidos. Comandos para uso interno do ELM323 sempre devem começar com os caracteres "AT", enquanto que comandos para o barramento OBD devem conter apenas os códigos ASCII para dígitos hexadecimais (de 0 a 9 e de A a F). As mensagens que não são compreendidas pelo ELM323 sempre serão sinalizadas por um ponto de interrogação. Mas isso não significa que a mensagem foi ou não

22 21 compreendida pelo veículo, pois o ELM323 não verifica se a mensagem enviada para o veículo está errada. É importante mencionar que o ELM323 não distingue letras maiúsculas de minúsculas e, também, que ele ignora caracteres de espaço e todos os caracteres de controle (tab, enter, etc.) 2.6 O Circuito Integrado ELM327 Quase todos os novos veículos produzidos hoje em dia devem possuir, por lei, alguma interface pela qual os equipamentos de teste possam obter informações de diagnóstico. A transferência de dados pode ser feita por essas interfaces pode ser feita através de diversos padrões, e nem um deles é diretamente compatível com os computadores. O ELM327 funciona como uma ponte entre as portas OBD II (On-Board Diagnostics) e uma interface RS232 padrão. O ELM327 é baseado em outros circuitos integrados, o ELM320, o LM322 e o ELM323 e foram adicionados a ele 7 protocolos CAN. O resultado é um circuito integrado que pode automaticamente perceber e converter a maioria dos protocolos que estão em uso atualmente. Também há outras melhorias como, por exemplo, uma opção de RS232 de alta velocidade, monitoramento da tensão de bateria e características personalizáveis através de parâmetros programáveis. O ELM327 requer poucos componentes externos para poder utilizar todas as funções do circuito integrado Comunicação Um dos métodos mais simples de se comunicar com o ELM327, através de um computador, é utilizando-se algum programa "terminal" disponível (Hyper Terminal, ZTerm, etc.) para se poder digitar caracteres diretamente do teclado do computador utilizado. Para utilizar um programa terminal é necessário configurar o software utilizado para se comunicar corretamente com o ELM327. Todas as respostas dadas pelo ELM327, são terminadas com um caractere simples de retorno.

23 22 No início da comunicação, o ELM327 envia uma mensagem informando a versão do CI, o que permite que seja verificado se as configurações do software utilizado estão de acordo com as do CI. Sempre que o ELM327 está em estado de espera, pronto para receber dados pela porta RS232, é enviado o caractere ">". As mensagens enviadas pelo computador também podem ser destinadas para uso interno do ELM327 ou para reformatar e passar pelo barramento OBD. Uma vez que a mensagem completa tenha sido recebida, o ELM327 pode determinar rapidamente para onde os dados devem ser enviados, isso através da análise completa dos dados recebidos. Comandos para uso interno do ELM327 sempre devem começar com os caracteres "AT", enquanto que comandos para o barramento OBD devem conter apenas os códigos ASCII para dígitos hexadecimais (de 0 a 9 e de A a F). As mensagens que não são compreendidas pelo ELM327 sempre serão sinalizadas por um ponto de interrogação. Mas isso não significa que a mensagem foi ou não compreendida pelo veículo, pois o ELM327 não verifica se a mensagem enviada para o veículo está errada. É importante mencionar que o ELM327 não distingue letras maiúsculas de minúsculas e, também, que ele ignora caracteres de espaço e todos os caracteres de controle (tab, enter, etc.). Uma outra característica do ELM327 é a habilidade de repetir qualquer comando quando algum caractere de retorno é recebido. Se for enviado um comando, não será mais necessário reenviar o comando inteiro, mas apenas o caractere de retorno. Porém a memória armazena apenas o último comando enviado. As principais diferenças entre o ELM323 e ELM327 são apresentadas na tabela 2.6.

24 23 Diferenças ELM323 ELM327 Frequencia do cristal 3,58 MHz 4,00 MHz Quantidade de pinos Velocidade da RS ou Comandos AT Parcialmente configurável via Totalmente Configurável via Comandos AT comandos AT N de protocolos suportados 2 12 Monitora a tensão da bateria Não Sim Tabela 2.5 Diferenças entre o ELM323 e ELM Instrumentação Virtual A instrumentação virtual pode ser entendida como sendo uma solução de medição e automação baseada em computador pessoal, sendo personalizada pelo usuário (Regazzi R. D., et al., 2005). O LabVIEW Laboratory Virtual Instruments Engineering Workbench (Regazzi R. D., et al., 2005) é o ambiente desenvolvido pela National Instruments que utiliza a linguagem gráfica (conhecida também por linguagem G), para o desenvolvimento de aplicativos. Sua forma de programação que é altamente produtiva na construção de sistemas voltados para aquisição de dados e instrumentação. Segundo o site da empresa National, a linguagem G por sua vez, permite que o programador utilize uma interface gráfica para a criação dos códigos de programação em blocos. Isto facilita o processo de aprendizagem permitindo que pessoas mesmo com pouco treinamento sejam capazes de realizar tarefas que em outras linguagens demandariam maior esforço e muito mais tempo. Os programas em LabVIEW são chamados de VI Virtual Instruments que fornecem duas interfaces: uma interface de fluxo de dados que é o código fonte chamado de Diagrama de blocos; e o Painel Frontal que permite que o usuário insira os valores de entrada e observe

25 24 os valores de saída processados pelos blocos, podendo ser em gráficos ou vários tipos de indicadores. (veja figura 2.5). Figura 2.5 Painel Frontal e diagrama de blocos do LabVIEW 2.8 Considerações Finais Conforme apresentado nos capítulos anteriores, o uso de protocolos de comunicação padroniza e torna viável a transmissão e recepção de dados entre módulos de controle eletrônicos e aparelhos de diagnóstico. Desta forma, as organizações como a SAE e ISO, desempenham um papel importante no desenvolvimento de padrões para protocolos de diagnose veicular. O padrão OBD surgiu da necessidade de se padronizar e criar métodos que facilitem a diagnose de um problema no veículo, sem a necessidade de desmonta os componentes nele instalados e de uma forma mais precisa identificar quando o componente eletrônico está fora de sua faixa de funcionamento, conforme as especificações estabelecidas pelo fabricante. Dentre as normas para diagnose veicular destacam-se: ISO9141 e ISO14230(KWP2000), que padronizam os requisitos para se estabelecer uma comunicação entre módulos eletrônicos no veículo, como por exemplo tipo de conector ODB e sua configuração entre outros. Nestas normas define-se que o veículo deve possuir uma ou duas linhas de comunicação utilizadas para inspeção, teste e diagnose, chamadas de Linha K e Linha L(K-line e L-line). Nesta configuração, a linha K transmite dados de forma serial e

26 25 bidirecionalmente, enquanto a Linha L transmite de forma unidirecional a partir do equipamento de diagnóstico para o módulo eletrônico do veículo. Outra característica é o padrão do código de falhas, chamado de DTC s (Diagnostic Trouble Code) que é um conjunto de caracteres de 5 dígitos que definem o tipo e origem da falha. Por exemplo, se na consulta com um aparelho de diagnose apresentar o código P0143, o primeiro digito indica a localização da falha, o segundo digito indica a entidade responsável pela definição desta falha e o terceiro digito indica o subgrupo de funções do veículo, enquanto o quarto e quinto dígitos definem a referida falha. Para este projeto foi utilizado um módulo de comunicação eletrônico entre um microcomputador e o veículo. Este módulo é conhecido por ELM327, que tem a função de converter os dados fornecidos no padrão OBDII do veículo para uma conexão serial do tipo RS232 interpretada pelo microcomputador. Através de comandos implementados em um software é possível coletar informações do veículo e apresenta de forma de fácil entendimento para um usuário de informática ou reparador automotivo.

27 3 METODOLOGIA Este projeto propõe o desenvolvimento de um sistema de diagnóstico veicular através de uma interface gráfica de computador de fácil manuseio ao usuário. Para tratar os protocolos ISO 9141 e ISO 14230, utilizamos o circuito integrado da família ELM. Para este fim, o circuito integrado ELM323 já seria o suficiente, visto que o mesmo trata exatamente os protocolos que pretendemos trabalhar (ISO 9141 e ISO 14230), porém como estes circuitos integrados da família ELM não são comercializados no Brasil e devido à falta de tempo para importação do ELM323, encontramos com maior facilidade o ELM327, que conforme já visto anteriormente, trata vários protocolos de diagnóstico automotivo, inclusive os protocolos ISO 9141 e ISO Neste trabalho, o ELM327 foi utilizado para tratar somente os protocolos ISO 9141 e ISO Para o desenvolvimento de uma interface gráfica de computador de fácil manuseio ao usuário, foi utilizado um software desenvolvido em plataforma LabVIEW. A escolha do LabVIEW para o desenvolvimento do software se deu devido à possibilidade de se obter uma comunicação (escrita e leitura) com uma porta serial RS232 através do software, além de ser uma ferramenta computacional muito utilizada na indústria. Outro motivo para a escolha é o domínio que todos os integrantes do grupo possuem sobre esta ferramenta, visto que esta linguagem é parte integrante de uma disciplina ministrada em nosso curso. 3.1 O Hadware Utilizado Conforme descrito anteriormente, para o desenvolvimento deste trabalho foi utilizado o circuito integrado ELM327. A Figura 3.1 descreve o esquema elétrico para a utilização dos protocolos ISO 9141 e ISO (linhas K e L) através do ELM327.

28 27 Figura 3.1 Esquema elétrico para a utilização dos protocolos ISO 9141 e ISO através do ELM327. Os terminais ISO-K e ISO-L do circuito são ligados respectivamente aos pinos 7 e 15 do conector OBD II, e utiliza-se um conector fêmea DB9 para a interface RS232. O modelo do veículo utilizado nos testes descritos neste trabalho foi um Golf 2.0 ano 2004 a gasolina. O protocolo utilizado em todos os módulos do referido veículo (motor, transmissão, ABS, air-bag, conforto, radio, gateway, painel de instrumentos e imobilizador) é o KWP Funcionamento do circuito Todo o trabalho é feito pelo circuito integrado ELM327. A tensão de alimentação é derivada da tensão da bateria do veículo existente no pino 16 do conector OBD-2 e que apresenta 12 V com o motor desligado e 14,4 V com o motor funcionando. A massa do circuito (GND) está ligada ao pino 5 do conector OBD-2, que, por sua vez, está no potencial do chassi do veículo. Pelo fato de nosso microcontrolador funcionar com 5V, elaboramos uma fonte de alimentação do circuito, mostrado na Figura 3.2, onde o CI U2 estabiliza em +5 V a tensão de alimentação e os diodos D1 e D2 evitam problemas com a tensão de entrada se for aplicada com polaridade invertida e ajuda a diminuir a tensão de entrada do regulador. O

29 28 LED1 acende sempre que o circuito estiver alimentado pelo OBD ou pela USB (universal serial bus). Figura 3.2 Circuito fonte de alimentação Nosso circuito de interface apenas utiliza os sinais existentes nos pinos 7 e 15 do conector OBD-2 (pinos dos sinais das normas ISO 9141 e 14230). De acordo com essas normas, o pino 7 é a entrada/saída K, enquanto o pino 15 é a entrada L. O CI ELM327 controla essas duas linhas de acordo com as normas, através de transistores com resistor de polarização de 510 Ω. O CI ELM327 recebe os sinais de diagnóstico quando o pino 7 do OBDII (linha K) está configurado como saída, sendo assim, os sinais são aplicados no pino 12 (ISO In) de U1e o pino 21 é usado para enviar dados para linha K. Para fazer a comunicação com o computador, o ELM327 disponibiliza sinais de comunicação serial UART (universal asynchronous receiver-transmitter - receptortransmissor assíncrono universal), porém em níveis TTL (Transistor-Transistor Logic), sendo necessário o uso de um circuito integrado driver/receiver TTL to TIA/EIA-232-F (conhecido antigamente como RS232) como por exemplo o MAX232. Conforme mostra a Figura 3.3, o nosso circuito usa um conversor USB/Serial CP2101 para fazer a comunicação com o computador. O CP2101 é um circuito integrado fabricado pela empresa Silicon Laboratories que converte sinais UART nível TTL em sinais USB. Quando a USB do CP2101 é conectada á porta USB do computador, automaticamente é detectado um novo dispositivo e através de um driver, fornecido pela Silicon Laboratories, o computador cria uma porta serial virtual. Nós escolhemos usar o CP2101 porque atualmente os computadores, principalmente os notebooks, netbook e PDAs, não são fabricados com porta serial.

30 29 Figura 3.3 Circuito USB/Serial usando CP2101 O pino 7 de U1 está ligado VCC para selecionar o envio de caracteres LF (Line Feed = nova linha) sendo um caracter hexadecimal e mais um CR (carriage return) de terminação na mensagem serial. Os quatro LEDs ligados nos pinos de 25 a 28 e indicam o fluxo de dados nos dois sentidos (TX e RX) do OBD e da USB. 3.2 Desenvolvimento do Software Primeiramente, foi estudado um exemplo de uma VI (Virtual Instrument) no LabVIEW para a escrita e leitura de dados na serial. As principais funções no LabVIEW responsáveis por esta comunicação serial são as funções VISA Whrite (escreve na serial) e VISA Read (lê os dados da serial).

31 30 Figura 3.4 VI para escrita e leitura de dados na serial. Com esta VI, podemos escrever a solicitação dos dados que queremos obter utilizando alguns comandos do ELM327 no campo string to write e ler os dados obtidos no campo read string. No exemplo da Figura 3.4, ao escrevermos o comando atrv (lê tensão da bateria), podemos ler o dado 12.2V seguido do eco do comando que foi escrito (atrv). Da mesma forma, ao escrevermos o comando 010c (lê rotação do motor), podemos ler os dados 41 0C (hexadecimal) seguido do eco do comando que foi escrito (010c), conforme ilustrado na Figura 3.5.

32 31 Figura 3.5 Leitura da rotação do motor Após estes resultados, começamos a trabalhar no desenvolvimento de uma interface gráfica amigável e de fácil manuseio. Para isto, foi necessário tratar os dados recebidos para exibi-los de forma a permitir uma leitura mais fácil destes dados. Apesar de o sistema permitir a leitura de várias informações do veículo, nosso trabalho se limitará à leitura e tratamento dos seguintes dados: tensão da bateria, rotação do motor e códigos de falha (DTC) Tratamento da leitura de tensão da bateria Todos os dados recebidos no campo read string, como o próprio nome diz é uma string, ou seja, um conjunto de caracteres onde cada caractere é codificado como um inteiro de 8 bits. A interface gráfica que escolhemos para a leitura de tensão da bateria é uma variável do tipo DBL (Double Precision) e permite a leitura apenas de dados numéricos. Para