2016-08-24 07:56:37 +0000 2016-08-24 07:56:37 +0000
9
9

Os códigos de falha são registados com um carimbo de tempo num registo com um histórico de DTCs?

Acabei de digitalizar o meu veículo pela primeira vez para verificar o código de um Check Engine Light. Fiquei curioso se estes códigos de falha fossem registados algures com um carimbo de data e hora de algum tipo na altura em que foram lançados. Estou a imaginar algum desenho semelhante ao Registo de Eventos utilizado em sistemas operativos de computador, mas posso estar totalmente enganado neste.

O que é exactamente o desenho em torno destes códigos de falha, na medida em que são registados. Um aspecto óbvio do desenho é a utilização de códigos únicos específicos para algum problema em particular. Será que a história completa com uma falha, existem outros metadados em torno de uma instância de falha que possam ser consultados? Como funcionam as histórias de falhas nos veículos? As histórias são mesmo registadas ou são falhas simplesmente uma coisa binária, quer estejam actualmente ligadas ou desligadas, independentemente de alguma vez terem estado ligadas em qualquer ponto da vida do veículo. Sei que é possível limpar códigos usando ferramentas de scanner, será isto para sugerir que as falhas permaneceriam marcadas num sistema perpetuamente até as limpar manualmente? Isto levar-me-ia a crer que a luz do motor de verificação permaneceria iluminada mesmo após a reparação da causa raiz de uma avaria. Será isto correcto?

Respostas (3)

9
9
9
2016-08-24 10:13:04 +0000

Depende realmente da implementação do OBD2. O que o meu Subaru de 1997 regista (praticamente nada) em comparação com um Chevy Cruise de 2015 são coisas completamente diferentes.

Contudo, na maioria dos casos, um Código de Problemas de Diagnóstico (DTC) é registado com um freeze frame, que é um armazém completo de todos os Parâmetros ID’s (PIDS). Estes parâmetros cobrem tudo, desde RPM, velocidade do veículo, dados do sensor O2, dados do fluxo de ar de massa, guarnições de combustível a longo e curto prazo, avanço de ignição, entrada e temperatura do líquido de refrigeração, e talvez dezenas de outros. Estes são acedidos através do Modo OBD2 2. O simples “Pxxxx”. As falhas do DTC são acedidas através do Modo OBD2 3, que é muitas vezes a medida em que simples ferramentas de digitalização do consumidor são capazes de exibir.

Em ferramentas de varrimento mais sofisticadas, os dados do Modo 2 “congelar frame” podem ser mostrados, o que são dados inestimáveis, uma vez que revelam a condição exacta de funcionamento no preciso instante em que o código DTC foi definido.

A história de tais códigos varia novamente com a implementação do OBD2, e muito provavelmente como o veículo é novo. No meu Subaru de 1997, os dados são limitados - dado que o OBD2 não era um mandato até ao ano do modelo de 1996.

No entanto, todos os veículos têm duas categorias de DTC: “Pendente”, que é uma falha detectada, mas não define o Check Engine Light (CEL, SES) até que a condição seja detectada de novo um certo número de vezes. (Acede-se a isto através do Modo OBD2 7.) O número de “ciclos de condução” necessários para promover um “pendente” a um CEL depende da falha, da implementação, e do veículo.

A outra categoria de DTC é “armazenada” ou “registada”. Estes são códigos de falha verdadeiros que foram promovidos do estado “pendente” para um código de falha real, e que por definição OBD2 têm de definir o CEL.

Além disso, algumas Unidades/Módulos de Controlo de Motores (ECU/ECM) têm a capacidade de registar algumas ou dezenas de códigos de falha “históricos”, independentemente de terem sido reparados e/ou limpos. Isto fornece um historial a um técnico astuto, mesmo quando não há falhas DTC actuais dependentes ou logadas. Os códigos

DTC NÃO têm de ser limpos “manualmente”. Se a condição que causou a falha for reparada, ou simplesmente já não ocorrer (eficiência do catalisador P0420 um exemplo clássico), o código “apagar-se-á” por assim dizer, após um certo número de ciclos de condução, sem que a falha se repita. O número de ciclos de condução necessários para limpar um CEL DTC activo depende da falha e da implementação de software. Na maioria dos casos, contudo, um técnico limpa estes códigos após uma reparação válida para garantir ao cliente que a reparação está completa. Mas não temos de o fazer; é uma cortesia. O ECU/ECM monitoriza constantemente o PID e as condições de emissão, e acabará por ceder, dado o número suficiente de ciclos de condução “limpos”.

Como um aparte, existe uma categoria de DTC que provoca um FLASHING CEL. Estes diferem dramaticamente do CEL “sólido em”, na medida em que, se este se ligar e permanecer ligado, é uma indicação de que algo está errado, e o condutor deve procurar o serviço numa oportunidade conveniente. Contudo, uma CEL FLASHING CEL indica algo gravemente errado que pode causar danos ao veículo. Normalmente, isto é uma indicação de uma condição demasiado rica, normalmente causada por graves falhas de ignição ou injecção de combustível, que se deixada sozinha poderia danificar um catalisador dispendioso. Estas luzes de verificação “intermitentes” do motor devem ser imediatamente abordadas - alguns OEMs sugerem que se encoste o veículo e o mande rebocar.

Para complicar ainda mais este processo, a eliminação de um CEL elimina o código de falha da categoria “activa”, mas tal como a analogia do seu computador, é um ALT_CTRL-DEL. Reinicia completamente o ECU/ECM, e limpa o que é referido como os “monitores”.

Os monitores são uma pletora completa de testes que funcionam continuamente, ou na maioria dos casos quando certos critérios PID (temperatura, carga do motor, nível de combustível, ciclo de condução) são satisfeitos. (Isto é o que torna particularmente difícil passar os monitores do sistema de emissões evaporativas; os critérios são exactos e até dependem da quantidade de combustível no tanque).

É necessário um certo número de ciclos de condução bem sucedidos, obedecendo a todos os critérios necessários, para “passar” nestes testes de monitorização. Neste momento, o veículo pode passar uma inspecção de emissões OBD2 - quando todos os monitores tiverem passado. (Em Nova Iorque, os veículos produzidos antes de 2001 podem ter dois testes de monitorização incompletos, 2001 e os mais recentes são permitidos um, e pode ser que veículos recentes sejam permitidos nenhum incompleto. Isto é apenas trivialidades).

O resultado é que, embora um veículo possa ter tido reparações adequadas e os códigos de falha limpos, isto NÃO significa que passará uma inspecção de emissões OBD2. Isto impede a técnica de desligar a bateria e levá-la imediatamente à inspecção. O veículo deve completar o número necessário de ciclos de condução com todos (ou a maioria) dos critérios cumpridos, a fim de obter a nota de aprovação. Enquanto um veículo chamado “não pronto” não falha nos testes de emissões, também não passa. Após a lobotomia ALT-CTRL-DEL ECU/ECM, a O veículo instala-se e não fica “pronto” para inspecção até que se prove a si próprio que todos os monitores estão desligados, e que o veículo está a funcionar limpo.

4
4
4
2016-08-24 10:11:28 +0000

Existem dois tipos de códigos de falha; uma viagem e duas viagens.

Um único código de falha de disparo é geralmente uma falha importante como um grave erro de disparo. Isto acenderá a luz do motor de verificação imediatamente após a detecção.

Um código de falha de dois disparos tem de ser verificado em dois disparos. O primeiro disparo estabelece um código pendente sem iluminar a luz. Se a falha for detectada novamente, a luz acender-se-á.

Teoricamente, quando uma falha grave (luz acesa) passa o teste duas vezes consecutivas, a luz apagar-se-á. O código é então desclassificado para pendente de falha grave. Isto é estipulado se o teste ainda for executado com uma avaria grave. Há alguns casos em que o teste é suspenso com uma falha grave e, em seguida, a limpeza da luz com uma ferramenta de varrimento é a única forma de desligar a luz. Um código pendente desaparecerá se o teste passar 60 ciclos de condução consecutivos (arrancar e desligar o carro 60 vezes não constitui um ciclo de condução)

Sempre que um código é armazenado, os dados da moldura de congelamento são armazenados com ele. Freeze frame data (FFD) é um instantâneo dos dados mais comuns quando a falha foi detectada. O problema com ele é que os valores armazenados diferem por fabricante e por ano do veículo. Os valores podem incluir, mas não estão limitados a: temperatura do líquido de arrefecimento, rpm, temperatura do ar, corte de combustível a curto prazo, viagem de combustível a longo prazo, estado do laço, durante quanto tempo se passou num ciclo de condução a falha foi definida, quantos ciclos de condução passaram desde que a falha foi definida…. a lista continua e continua.

Os veículos mais antigos só podiam armazenar um único quadro de FFD e o código de falha mais grave tinha prioridade. Os veículos mais recentes podem armazenar múltiplas moldura de FFD. Embora se possa descobrir por que ordem os códigos ocorreram, não existe um carimbo de tempo proverbial como num registador de eventos.

2
2
2
2018-09-15 15:33:49 +0000

Respostas já muito detalhadas! Só queria acrescentar algo sobre os testes de emissões após a limpeza dos códigos de falhas. Alguns fabricantes incluem uma forma de criar as condições que determinarão se os componentes de emissões passam/falhas sem tempos de condução prolongados. O software VCDS que tenho para a Volkswagen (e as suas outras marcas) tem uma opção “set readiness” no CPU do motor. Acompanha-o passo a passo através dos componentes de emissões, indicando quanto tempo tem de manter o motor a uma determinada RPM e quando o teste é realizado. Os veículos mais recentes assumirão automaticamente o controlo e a rotação do motor enquanto os mais antigos têm de ser feitos precisamente por alguém no lugar do condutor, mantendo RPMs bastante precisas. Em suma, provavelmente o melhor será levar um carro a um concessionário real para uma inspecção de emissões, se tiver recentemente autorizado os códigos do motor para que este tenha uma oportunidade de passar.