DTC – Remover Avaria

Falar de códigos de avaria, e subsequente avarias, é quase uma necessidade, face à

crescente quantidade de tecnologia presente nas viaturas automóveis. Desde a
introdução dos sistemas electrónicos que os fabricantes se viram na necessidade de
identificar falhas e avarias nos respectivos sistemas. Anos volvidos e existe a
estandardização dos códigos de avaria, a famosa norma OBD, que evoluiu para OBDII e
actualmente, no espaço europeu, estamos agregados à norma EOBD.

Norma EOBD
EOBD é uma abreviação de European On-Board Diagnostics. Todos os carros a
gasolina vendidos na Europa após 1 de Janeiro de 2001, e os diesel fabricados após
2003, são obrigados a ter um sistema de monitorização de emissões. Estes sistemas
foram introduzidos em linha com a directiva europeia 98/69/EC, para monitorizar e
reduzir as emissões poluentes. Todos os carros que se enquadrem nestas datas têm que
possuir uma porta de diagnóstico EOBD:

Porta de diagnóstico EOBD/OBD-II

 

 EOBD2
EOBD2 não é uma nova versão da norma EOBD, EOBD2 é o acrónimo de “Enhanced
On-Board Diagnostics, Second Generation” e refere-se a um conjunto de possibilidades
adicionais, geralmente específicas a cada construtor, que passam a estar disponíveis via
a tradicional porta OBD2. Esta nova geração não substitui a anterior, isto é, uma
ferramenta de diagnóstico tradicional OBDII/EOBD, continua a funcionar da mesma
forma e com acesso a todos os dados que estão na norma, mas, caso esta ferramenta
possua ligação EOBD2, então haverá um conjunto extra de funcionalidades disponíveis.

Por este motivo as máquinas de diagnóstico actuais, tais como a Autocom/Delphi, a

KTS da Bosch, a Autel entre outras mais,  possuem uma série de funcionalidades
similares às de um concessionário, como programação de chaves, inicialização de
componentes, codificações e mesmo o carregamento de calibrações de centralinas.
 

Gestão de códigos de avaria

Feitas as introduções à norma OBD, a intenção deste artigo é a de explicar de que forma
os códigos de avaria são geridos pela ECU, de que forma são interpretados e em que
condições acontece o iluminar da famosa lâmpada amarela…

Por uma questão de facilidade e simplicidade iremos abordar a gestão em unidades

BOSCH EDC15.

Estrutura de códigos de avaria – EDC15P+ (1.9 TDI 130 HP)

 Nestas unidades os diferentes elementos são agrupados por sistema, por exemplo, a
quantidade de massa de ar, de recirculação de gases de escape, de pressão de
sobrealimentação, etc e a cada um deste elementos é adicionado uma variável de
monitorização, vulgarmente conhecida como SRC (Signal Range Check). Isto é, para
cada sistema temos um “policia” a monitorizar permanentemente os dados do sistema,
mas, nem sempre este passa multa, depende muito da situação, vejamos um exemplo:

Vamos na autoestrada a 120 km/h e, para facilitar uma ultrapassagem, aceleramos até
aos 150 km/h retomando logo de seguida aos 120 km/h. Esta situação, embora
ultrapasse o limite legal, não dá direito a multa (a menos que o polícia seja uma

besta…   ) no entanto, se na mesma situação permanecermos nos 150 km/h

demasiado tempo, então já nos estamos a sujeitar à multa.

Na gestão interna da ECU passa-se o mesmo, por exemplo, no controlo da pressão de

turbo… Ao calcar o acelerador estamos a requisitar mais combustível e mais pressão de
turbo, mas esta infelizmente não aparece de forma instantânea, há um período de tempo
em que existe um desvio entre a pressão pedida e a pressão real. Durante este período
temos um desvio de pressão negativo que poderá estar acima do permitido, mas, pode
ou não despoletar um código de avaria, apenas depende de uma outra variável…o
tempo.
Se este desvio se mantiver durante demasiado tempo (…e aqui o demasiado podem ser
apenas 0.5 segundos) então este desvio será enviado para a memória de gestão de erros,
que por sua vez o irá agrupar e monitorizar o seu estado, determinando a sua prioridade,
os valores de substituição para o mesmo e a condição da lâmpada de avaria. (Nem todos
os erros fazem a lâmpada iluminar, alguns podem ser substituídos por valores pré-
definidos, outros forçam o motor em “safe mode”)

Representação gráfica da gestão de códigos de avaria em sistema EDC15P+

 

Neste gráfico temos uma representação do processo, dividido em três áreas:

ERRO: É a representação real do nosso erro, ou seja, sempre que algum sinal excede o valor previsto
(SRC).

MEMÓRIA: Representa a memória interna que faz a monitorização e gestão da avaria, que por sua vez
comanda a luz de avaria e respectiva solução. (valor de substituição, safe-mode, etc)

LUZ DE AVARIA: É o resultado gráfico da avaria (que pode ser ou não com luz, algumas avarias
apenas ficam registadas e não surgem com luz de aviso).

O importante a reter desta representação é o facto de que é necessário um defeito existir

durante um período maior do que o estipulado pelo “tempo p/ON” para que seja de
facto interpretado como um defeito e, ao mesmo tempo, será necessário o inverso,
ultrapassar o “tempo p/off” para que o erro deixe de existir e a luz se apague.

Estrutura dos códigos de avaria

Quando os códigos de avaria são despoletados existem um conjunto de condições,
chamadas de condições ambientais, que são lidas, normalizadas e transferidas para a
memória de erros. Qualquer alteração na avaria não tem qualquer influência nas
condições ambientais, isto é, após as mesmas serem transferidas para a memória as
mesmas ficam retidas até que sejam limpos os códigos de avaria. Estas condições são
seleccionadas utilizando numeração específica e não servem para as máquinas de
diagnóstico comuns, mas sim internamente para o construtor (e respectivos
equipamentos de diagnóstico). Por esse motivo a numeração é sempre superior a 3840.

A estrutura de um código de avaria é a seguinte:

Prioridade Contador para erro ON Contador para erro OFF Condições ambientais (>3840) Temporizador para erro ON

8 bit 8 bit 8 bit 16 bit 16 bit

0a3 0 a 255 0 a 255 1 2 3 4 5 0 a 65535

A prioridade é definida de 0 a 3, sendo a prioridade mais baixa e 3 a prioridade mais

alta. Em caso de existirem demasiados erros, os erros com prioridade mais baixa serão
eliminados da memória, para dar lugar aos restantes.

Um exemplo de um código de avaria, de uma unidade EDC15P:

17663/P1255 – Engine Coolant Temperature Circuit (G62): Short to Ground

Estrutura de código de avaria P1255 em unidade EDC15P VAG

Seguindo a estrutura de erro apresentada acima temos:

 Prioridade: 0
 Contador p/ ON: 0
 Contador p/OFF: 0
 Condição ambiental 1: 3856
 Condição ambiental 2: 3968
 Condição ambiental 3: 3848
 Condição ambiental 4: 3845
 Condição ambiental 5: 3843
 Tempo p/ ON: 48000
 Tempo p/OFF: 48000
 Tipo contador: 8977
 Código VAG: 17663
  Código CARB(OBD): 4693 (1255 em HEX)

Trata-se então de um código de avaria despoletado por tempo e não por número de
eventos, para o qual são necessários 480000 us (0.48 segundos) em erro para que a luz
de avaria se acenda, e os mesmos 0.48 segundos para que a avaria seja dada como
reparada, ainda que a lâmpada de avaria fique ligada até os códigos serem limpos.

Remover códigos de avaria

Conhecendo esta estrutura é fácil de de a manipular de forma a que o código de avaria
não seja despoletado, e com isso, nos livremos da respectiva luz de avaria. No caso da
avaria acima representada não fará qualquer sentido eliminar a avaria, visto que se trata
apenas de um sensor de temperatura de água, mas, assumamos que por algum motivo o
queríamos desligar e eliminar a respectiva avaria.

Neste caso em que a avaria é despoletada por tempo, vamos então manipular essas
variáveis de forma a ficarem assim:

Código de avaria P1255 eliminado

 A alteração do “tempo p/ON” para 65535 implica que será necessário um tempo
infinito, em erro, para que a avaria passe para definitivo. Ao mesmo tempo, se isso
acontecer, o tempo necessário para o mesmo regressar ao estado normal é zero, isto é, o
erro nunca fica activo.

É preciso lembrar que eliminar um código de avaria não significa que a mesma fica
resolvida, nem tão pouco que o motor passe a rodar sem problemas. Neste mesmo
exemplo, ter um sensor de temperatura de água avariado origina uma cadeia de eventos,
por forma a garantir o funcionamento do motor, por esta ordem:

1.  É registado o respectivo código na memória da ECU.  (P1255 – Curto circuito no sensor de

temperatura com a massa)
2. O código de avaria aparece no painel, iluminando a nossa luz de motor. (P1255)
3. A ECU, dependendo da configuração, atribui um valor de substituição ou utiliza outro sensor
para monitorizar a temperatura. 
1. Neste caso é utilizado um valor de substituição de 49.96ºC, não havendo lugar a
qualquer alteração. Em algumas codificações o sensor de temperatura de óleo é
utilizado como forma de monitorizar o motor.

Neste exemplo vemos que, após apagar o erro, tudo continuará funcional, sendo
necessário lembrar que existem imensas correcções que são feitas tendo em conta a
temperatura do motor, pelo que, não ficará a 100%. A alteração dos mapas de avanço,
por via dos selectores de avanço, será a mais evidente. O mesmo não aconteceria caso o
erro fosse relativo a algum sensor vital para o funcionamento do motor, como um sensor
de rotação, sensor de massa de ar, entre outros.

Localizar os códigos de avaria, e eliminar os mesmos, é uma tarefa relativamente

simples, bastando para isso localizar o erro e reconhecendo a respectiva estrutura, mas o
mesmo já não +e verdade para quando queremos alterar e modificar os valores de SRC
dos respectivos sensores, ou então modificar o comportamento de um código de avaria
(para remover um sensor MAF, p.ex). Para estes é fundamental ter informação, já que
não existe um padrão para a localização dos mesmos, e essa informação pode vir a partir
dos ficheiros DAMOS ou via mappacks mais extensivos.