hablar de diagnóstico

Resumen:

Puede haber varias fallas en el automóvil, como que el instrumento tiene una luz defectuosa, el automóvil no se puede encender y hay ruidos extraños y anormales en el automóvil. La gran mayoría de estas fallas son diagnosticadas por una unidad de control electrónico (ECU) en el automóvil, y la alarma y el conductor se recuerdan a través del instrumento.

Fuente: La luz de falla del auto está encendida pero funciona normalmente_Ranking Daquan (pai-hang-bang.cn)

Esta serie presentará específicamente el diagnóstico de fallas de la ECU automotriz. Las preguntas centrales incluyen: ¿Cuáles son las fallas? ¿Cómo realiza la ECU el diagnóstico de fallas? ¿Cómo solucionar problemas? ¿Y como arreglarlo? Este artículo responderá a la primera pregunta: ¿Qué pasa?

1 Concepto de arquitectura de control de vehículos

Si un automóvil se desarma por completo, habrá muchas piezas, como se muestra en la siguiente figura:

Fuente: Una gran ola de "piezas recicladas de vehículos automotores desguazados" está en camino, y la nueva versión de "Medidas para la administración del reciclaje de vehículos automotores desguazados" entrará en vigencia el 1 de junio.

Si una de estas muchas piezas falla o se daña, será muy difícil identificar directamente la pieza defectuosa. Entonces, ¿cómo podemos identificar fallas con precisión y rapidez? Las partes anteriores se pueden clasificar desde la perspectiva del sistema funcional del automóvil, es decir, estas partes constituyen los diversos sistemas funcionales del automóvil (sistema de potencia, sistema de chasis, sistema en el vehículo y sistema de conducción inteligente, etc.). Y cada sistema contiene múltiples funciones de control, como el sistema de energía (vehículo de nueva energía como ejemplo) que incluye la unidad de control del motor (MCU), el sistema de administración de la batería (BMS) y la unidad de distribución de energía de alto voltaje (PDU), etc., para que estas partes se subdividen en cada unidad de función de control. Sobre la base de estas unidades funcionales de control, se forma una arquitectura de control del vehículo, como sigue:

Fuente: [Prueba de Ethernet automotriz] Serie 2: Garantizar el rendimiento y la consistencia de la red de vehículos de próxima generación - Prueba y medición

2 unidad de función de control electrónico

Concéntrese en una determinada unidad funcional de control electrónico, como la unidad funcional de control del motor, de la siguiente manera:

Fuente: ¿Diagrama de la ubicación de todos los sensores en el motor del automóvil? -Zhihu (zhihu.com)

Sus componentes son: cuerpo motor, sensores (posición, temperatura y velocidad, etc.), centralita electrónica ECU, actuadores (electroválvulas, motores ejecutivos) y actuadores, etc.

Su principio de funcionamiento es:

1. La ECU primero recopila estas señales de sensores y se comunica con otras ECU para enviar y recibir algunas señales;

2. Luego, la ECU usa algoritmos lógicos de control complejos para calcular las instrucciones de control del actuador;

3. El accionador finalmente acciona el accionador para controlar el movimiento de las partes mecánicas del motor, de modo que el motor funcione de la manera y el efecto deseados.

3 tipos de fallas

No es difícil encontrar que, a nivel del controlador, varios componentes pueden abstraerse aún más en sensores, comunicaciones, controladores, actuadores y sistemas mecánicos. Este es el punto de partida del diagnóstico de fallas para automóviles, es decir, hacer un diagnóstico de fallas para la ECU y diagnosticar qué fallas. Según esta idea, las fallas de la ECU se suelen dividir en 5 tipos:

• Las fallas mecánicas/del sistema se refieren principalmente a fallas de componentes mecánicos o fallas del sistema causadas por varios factores. Tome como ejemplo las fallas antes mencionadas involucradas en la unidad funcional de control del motor, tales como daños en el cilindro del pistón del motor, temperatura excesiva de funcionamiento del motor, etc.;

• Las fallas electrónicas y eléctricas se refieren principalmente a fallas de sensores y actuadores, por ejemplo, se pierde la señal del sensor de temperatura o se quema la válvula solenoide.

• La falla del hardware se refiere principalmente a la falla del controlador y varios chips en la PCB, por ejemplo, el chip de accionamiento de la válvula solenoide informa sobrevoltaje o bajo voltaje y otras fallas.

• Fallas de software, se refieren principalmente a fallas de software de la ECU, como bucle sin fin, división por cero, desbordamiento y otras fallas;

• La falla de comunicación se refiere principalmente a fallas como la interrupción de la comunicación, la interrupción de la comunicación y el error de datos de comunicación. Como el tiempo de espera de la señal de comunicación CAN y otras fallas.

Para comprender mejor los cinco tipos de fallas anteriores, aquí tomamos el sensor de posición como ejemplo para ilustrar las fallas de los aparatos electrónicos. Para el sensor de posición que se muestra en la siguiente figura, ¿qué fallas se consideran generalmente?

Considere las fallas desde dos aspectos.

Por un lado, desde la perspectiva del voltaje de la fuente de alimentación, si es subtensión, sobretensión, si la fuente de alimentación está en cortocircuito a tierra o en circuito abierto, y si la fuente de alimentación está en cortocircuito a la fuente de alimentación. Por ejemplo, según la especificación del sensor de posición:

• Si el voltaje es inferior a 4,75 V, es un bajo voltaje;

• Si la tensión es superior a 5,25 V, se trata de una sobretensión;

• El voltaje es inferior a 1 V, que pertenece al cortocircuito de la fuente de alimentación a tierra o al circuito abierto;

• Si el voltaje es superior a 6V, es un cortocircuito de la fuente de alimentación a la fuente de alimentación.

Por otro lado, desde la perspectiva de la señal PWM, si el ciclo de trabajo de la señal PWM está en el rango válido y si la señal PWM está bloqueada. Por ejemplo, según la especificación del sensor de posición:

• El rango efectivo del ciclo de trabajo de la señal PWM es [2%, 98%]. Si el ciclo de trabajo de la señal PWM es inferior al 2 % o el ciclo de trabajo de la señal PWM es superior al 98 %, el ciclo de trabajo de la señal PWM no es válido.

• El rango efectivo de la frecuencia de la señal PWM es [1kHz, 3kHz]. Si la frecuencia de la señal PWM es inferior a 1 kHz, o si la frecuencia de la señal PWM es superior a 3 kHz, la frecuencia de la señal PWM no es válida.

¿Cómo gestionar eficazmente tantos fracasos? Código de problema de diagnóstico (Código de problema de diagnóstico, DTC), es decir, el identificador universal numérico de la condición de falla identificada por el sistema de diagnóstico en línea del vehículo.

Fuente：ISO15031-6

4 Cómo ver DTC

Use el DTC para indicar el tipo de falla específico, luego al leer el DTC, el personal de mantenimiento del automóvil puede determinar qué está mal y hacer las reparaciones correspondientes. El DTC generalmente consta de una serie de letras y números, como DTC es P0127, B0001, C0031 o U0105, ¿qué significan?

• P0127 significa que la temperatura del aire de admisión es demasiado alta

• B0001 representa el control de despliegue de la etapa 1 delantera del conductor (error secundario)

• C0031 representa el sensor de velocidad de la rueda delantera izquierda (sub-error)

• U0105 significa que se perdió la comunicación con el módulo de control de inyectores

¿Qué opinas? De acuerdo con la definición de DTC de ISO15031-6, es la siguiente:

Fuente：ISO15031-6

El DTC está representado por caracteres 5. Para los cuatro DTC anteriores, cada DTC ocupa 2 bytes de longitud de datos. en:

El primer carácter ocupa 2 bits de longitud de datos, indicando el sistema al que pertenece la falla , el significado específico de cada valor es el siguiente:

• 00 = P, por falla del tren motriz (motor y transmisión)

• 01 = C, que representa una falla del chasis, como una falla del sistema de frenos o del módulo de control del chasis

• 10 = B, en nombre de la falla del cuerpo, como la falla del sistema electrónico del cuerpo.

• 11 = U, que representa falla de comunicación de red, lo que indica falla de comunicación entre varios sistemas del vehículo

Fuente：ISO15031-6

El segundo carácter también ocupa 2 bits de longitud de datos, indicando el tipo de falla El significado de cada valor es el siguiente:

• 00 = 0, que representa el código de falla definido por el estándar ISO/SAE

• 01 = 1, que representa el código de falla personalizado por el fabricante del automóvil

• 10 = 2, reserva ISO/SAE

• 11 = 3, reserva ISO/SAE

El tercer carácter ocupa 4 bits de longitud de datos, indicando el subsistema al que pertenece la falla.Tomando como ejemplo el sistema de red,

• 0 representa dispositivo de red

• 1, 2 representan comunicación de red

• 3 representa software de red

• 4, 5 representan datos de red

Para obtener más información, consulte: ISO15031-6

Los caracteres 4 y 5 ocupan 1 byte de datos, lo que indica el objeto de falla específico y el tipo Continúe tomando el sistema de red como ejemplo.

• U0101, los tres primeros caracteres se analizan de acuerdo con la descripción anterior, y el objeto de falla específico y el tipo representado por los dos últimos caracteres 01 son pérdida de comunicación con TCM

• U0302, el objeto de falla específico y el tipo representado por los dos últimos caracteres 02 son incompatibles con el software del módulo de control de la transmisión

• U0405, el objeto de falla específico y el tipo representado por los dos últimos caracteres 05 es que los datos recibidos del módulo de control de crucero no son válidos

A través de la explicación anterior de la definición de DTC, sabrá cómo mirar DTC. Se puede decir que el DTC es el "ID de identidad" del tipo de falla, y un DTC se asigna a un tipo de falla.

formato de 5 DTC

El formato DTC se define de acuerdo con varios protocolos estándar, como ISO-14229-1, SAE J2012 OBD DTC y SAE J1939-73, etc. En general, DTC se divide en dos formatos no OBD y OBD, de la siguiente manera:

Los anteriores son todos los DTC en formato OBD (se omite 0x00), y aquí hay DTC que no son OBD. Este tipo de DTC contiene 3 bytes de datos, de los cuales:

• Los 2 bytes de HighByte y MiddleByte son los mismos que la definición DTC de OBD, correspondientes a códigos de falla estándar de 5 dígitos (el primer dígito es una letra y los últimos cuatro dígitos son números);

• LowByte indica el tipo de falla, incluida la categoría de falla DTC y el subtipo de falla DTC, que representa el tipo de falla en el circuito o sistema (como circuito abierto del sensor, cortocircuito a tierra del sensor, etc.), para obtener más detalles, consulte ISO15031- 6

Fuente：ISO15031-6

La categoría de falla DTC se define de la siguiente manera:

Fuente：ISO15031-6

Cuando el tipo de falla es información de falla general (Información de falla general), los subtipos de falla de DTC son los siguientes:

Fuente：ISO15031-6

Cuando el tipo de falla es fallas de señal general (Fallas de señal general), los subtipos de falla de DTC son los siguientes:

Fuente：ISO15031-6

Para comprender mejor el DTC en formato no OBD, veamos dos DTC nuevamente. De acuerdo con la definición anterior, la explicación es la siguiente:

• B0039-10 representa el control de despliegue del escenario del frente derecho de la primera fila - falla eléctrica general

• C0031-23 para sensor de velocidad de rueda delantera izquierda - falla de señal general - señal atascada baja

Para los dos formatos anteriores, cómo distinguirlos específicamente, puede usar el indicador de formato DTC para distinguir el método de análisis para distinguir el método de análisis. El indicador de formato DTC se define de la siguiente manera:

Fuente：ISO15031-6

El formato más utilizado en el diagnóstico OBD es SAE_J2012-DA_DTCFormat_00, que es el formato OBD DTC anterior; el formato más utilizado en el diagnóstico UDS es ISO_14229-1_DTCFormat, que es el formato DTC no OBD anterior. Cabe señalar que, aunque el estándar OBD-II define el formato de DTC, diferentes OEM pueden agregar DTC personalizados además de sus estándares. Por lo tanto, para el diagnóstico de un vehículo específico, es mejor consultar la hoja de interpretación de DTC o la documentación relacionada proporcionada por ese OEM.

6 Representación hexadecimal de DTC

El DTC obtenido a través de la comunicación de diagnóstico suele ser un valor hexadecimal, no en forma de 5 caracteres, y debe convertirse. Entonces, si el DTC en forma de carácter en el ejemplo anterior se expresa en hexadecimal, ¿cómo se calculará? Veamos primero un ejemplo:

Fuente：ISO15031-6

De esta forma, no es difícil calcular la representación hexadecimal de los cuatro DTC al comienzo del artículo, de la siguiente manera:

Lo anterior es en realidad el proceso de convertir las categorías de código en la tabla a continuación en valores hexadecimales.

7 Aplicación de DTC

En algunos servicios UDS de comunicación de diagnóstico de fallas, DTC estará involucrado, como el servicio 19 para leer información de DTC:

fuente: ISO14229-1

Este es solo un ejemplo simple de la aplicación DTC, más aplicaciones pueden referirse a ISO14229-1.

8 ¿Qué es el bit de estado DTC?   

El bit de estado de DTC, es decir, StatusOfDTC, se utiliza para indicar si se produce el fallo correspondiente al DTC, si se confirma, etc. El bit de estado de DTC contiene una longitud de datos de 1 byte y cada bit tiene una definición específica, como se indica a continuación:         

Pero no todos los bits se usan necesariamente, dependiendo de las necesidades de cada OEM. En ISO14229-1, excepto el bit 3: ConfirmedDTC es una restricción obligatoria, no hay ninguna restricción obligatoria.

Primero comprenda algunos conceptos: prueba (prueba), ciclo de operación (ciclo de operación) y envejecimiento (envejecimiento)

• La prueba se refiere al proceso de usar un algoritmo de software de diagnóstico en línea para determinar el estado de falla de un componente o sistema dentro de un ciclo operativo. En un ciclo operativo, es posible ejecutar la prueba solo una vez o periódicamente.

• El ciclo de operación define las condiciones de inicio y finalización de la prueba. Los dominios de la carrocería y el chasis generalmente están determinados por el OEM o el proveedor (como encendido y apagado, suspensión, activación, etc.), y existen otras normas estándar en el dominio de poder.

• Envejecimiento , el DTC registrado, si la falla ya no ocurre, no se registrará para siempre. En este momento, se debe pasar un proceso: el DTC se puede borrar solo cuando el resultado de la prueba ha pasado varias veces seguidas. llamado envejecimiento. ¿Cuántas veces se llama el umbral de envejecimiento.

Luego, lo siguiente introducirá la definición de cada bit del estado DTC en detalle:

1.0 Estado DTC bit0: prueba fallida

Si el resultado de la última prueba es Fallido, el bit de estado bit0 del DTC correspondiente se establece en 1. Cuando se cumple la condición de reinicio definida por el OEM, o se pasa el resultado de la última prueba, o se ejecuta el comando borrar DTC usando el equipo de diagnóstico, entonces el bit de estado bit0 del DTC correspondiente se reinicia a 0, y la lógica de conmutación es de la siguiente manera, el bit se inicializa El valor es 0.

fuente：ISO14229-1

1.1 Bit 1 de estado de DTC :testFailedThisOperationCycle

Si el resultado de la prueba es Fallido una vez en el ciclo de operación actual , si es así, el bit de estado 1 del DTC correspondiente se establece en 1. El valor inicial de este bit es 0. Si se establece en 1, solo se puede restablecer a 0 cuando se cambia el ciclo operativo o se ejecuta la instrucción de borrado de DTC utilizando el dispositivo de diagnóstico, de la siguiente manera:

fuente：ISO14229-1

         

1.2 Estado DTC bit 2: DTC pendiente

Si el resultado de la prueba falla una vez en el último ciclo de operación o en el actual , si es así, el bit de estado bit2 del DTC correspondiente se establece en 1. El valor inicial de este bit es 0. Si se establece en 1, el bit se puede restablecer a 0 solo cuando se completa el ciclo de operación actual y la prueba se completa sin fallar, o se ejecuta la instrucción de borrar DTC usando el dispositivo de diagnóstico. , Como se muestra abajo:

fuente：ISO14229-1

         

1.3 Estado DTC bit 3: DTC confirmado

Cuando se detectan suficientes fallas , el DTC correspondiente debe almacenarse en la memoria no volátil . Si el DTC se almacenó en la memoria no volátil, entonces el bit de estado 3 del DTC se establece en 1, pero el hecho de que el bit sea 1 no significa que la falla aún exista. Si el resultado de la prueba es Aprobado, significa que desaparece el fallo indicado por el DTC. Cómo restablecer a 0, ejecutar el comando borrar DTC o alcanzar el umbral de envejecimiento, etc. utilizando el equipo de diagnóstico, de la siguiente manera:

fuente：ISO14229-1

         

1.4 Estado DTC bit 4: testNotCompletedSinceLastClear

Si se ha realizado una determinada prueba de DTC desde que se borró la información de falla la última vez (independientemente del resultado de la prueba, solo importa si se ha probado). Si se ejecuta, el bit de estado bit4 del DTC se establece en 0. Si se establece en 0, el bit se puede restablecer a 1 solo después de ejecutar la instrucción de borrado de DTC utilizando el dispositivo de diagnóstico, como se muestra a continuación:

fuente：ISO14229-1

         

1.5 Bit 5 de estado de DTC: prueba fallida desde el último borrado

Si el resultado de una prueba de DTC es Fallido desde que se borró la información de falla la última vez . Si ocurre, el bit de estado bit5 del DTC se establece en 1; si se establece en 1, el bit solo se puede restablecer a 0 cuando cambia el ciclo de operación y se cumple la condición del umbral de envejecimiento, o se ordena borrar el DTC. ejecutado usando el dispositivo de diagnóstico, etc. ,Como sigue:

fuente：ISO14229-1

         

1.6 Estado DTC bit 6: testNotCompletedThisOperationCycle

En el ciclo de operación actual , si ejecutar una prueba para un determinado DTC (no importa cuál sea el resultado de la prueba, solo importa si se ha probado). Si se ejecuta, el bit de estado bit6 del DTC se establece en 0; si se establece en 0, el bit se puede restablecer a 1 solo después de que se use el dispositivo de diagnóstico para ejecutar el comando para borrar el DTC o la operación actual se completa el ciclo, como se muestra a continuación:

fuente：ISO14229-1

         

1.7 Bit 7 de estado de DTC: Indicador de advertencia solicitado

Algunos DTC especiales se asociarán con indicaciones de advertencia visibles para el usuario , como luces de advertencia en el instrumento o mensajes de texto. El bit de estado bit7 de este DTC se utiliza para este tipo de DTC.Configurarlo en 1 significa que el servidor solicita la activación de la indicación de advertencia y configurarlo en 0 significa que el servidor no solicita la activación de la indicación de advertencia. las condiciones de ajuste son las siguientes:

fuente：ISO14229-1

Tenga en cuenta que este bit siempre se establece en 0 si el DTC no admite indicaciones de advertencia.

9 ¿Por qué se necesita el bit de estado DTC?  

A través de la sección anterior, ya conocemos la definición del bit de estado DTC, pero ¿por qué necesitamos definirlo de esta manera? ¿O por qué se necesita el bit de estado DTC? En general, la función del bit de estado DTC se puede entender mejor a partir de los siguientes aspectos:

• Reconocimiento de fallas: los bits de estado de DTC se pueden usar para confirmar si persiste una falla. Una vez que se ha detectado una falla y se ha generado un DTC, el bit de estado de DTC asociado puede indicar si la falla aún existe. Por ejemplo, como se muestra en la siguiente figura:

El caso 1 representa una falla transitoria (potencial), el caso 2 representa una falla histórica y el caso 3 representa una falla actual.

• Registro del historial de fallas : el bit de estado DTC puede registrar información del historial de fallas. Cuando ocurre una falla, el bit de estado del DTC se puede configurar para indicar que la falla ya ocurrió, como la falla histórica en el caso 2 anterior.

• Eliminación y restablecimiento de fallas : el bit de estado DTC también se puede usar para indicar si el código de falla se borró o restableció, como se muestra en la siguiente figura:

Hay una explicación para el caso 1 de que no hay falla después de que se borra el DTC, y hay una explicación para el caso 2 de que hay una falla después de que se borra el DTC.

Además, el bit de estado del DTC original se muestra como una falla, como en el siguiente caso 1. Después de ejecutar el comando de borrado de fallas, la visualización del bit de estado del DTC se ha restablecido, como en el siguiente caso 2.

• Monitoreo de fallas: los bits de estado de DTC se pueden usar para monitorear condiciones de falla de componentes o sistemas específicos. Al verificar el valor del bit de estado del DTC, la aparición y desaparición de fallas se puede conocer en tiempo real para la resolución de problemas y el mantenimiento.

Se puede decir que los bits de estado de DTC brindan una forma efectiva de administrar y rastrear el estado y el proceso de diagnóstico de fallas del vehículo. Ayudan a proporcionar información persistente, historial, estado de reparación y capacidades de monitoreo de fallas, lo que permite un diagnóstico y reparación de fallas más precisos.

10 Bit de estado de DTC Descripción  

Se describe la descripción general de la operación de OBD DTC relacionada con la emisión de bits de estado de DTC en dos ciclos operativos en ISO14229-1.

Fuente：ISO14229-1

En comparación con los números de serie que se muestran en la figura anterior, la descripción es la siguiente:

• 0 Se recibió el comando para borrar la información de la falla --> inicializar el bit de estado del DTC.

• 1, 2 Se completa la ejecución de la prueba y se pasa el resultado --> los bits de estado bit4 y bit6 del DTC cambian de 1 a 0, lo que indica que se ha ejecutado la prueba.Desde el último comando de borrado de DTC, el DTC se ha alcanzó el estado listo en el ciclo de operación 1.

• 3, 4, 5, 6 La ejecución de la prueba se completa y el resultado falla --> Los bits de estado DTC bit2-bit0 y bit5 cambian de 0 a 1, lo que indica que la falla se detectó pero no se confirmó (la confirmación requiere dos operaciones ciclo).

• 7 La ejecución de la prueba finaliza y el resultado vuelve a pasar --> El bit 0 de estado del DTC cambia de 1 a 0, lo que indica que la falla no ha vuelto a ocurrir.

• 8 La ejecución de la prueba se completa y el resultado es fallido --> El bit 0 de estado de DTC cambia de 0 a 1, lo que indica que la falla ocurre repetidamente en el ciclo de operación 1.

• 9,10 Finaliza el ciclo de operación 1 y comienza el ciclo de operación 2, luego el bit de estado bit1 del DTC cambia de 1 a 0, y el bit de estado bit6 del DTC cambia de 0 a 1. El tiempo de conmutación depende de cómo defina el OEM él.

• 11 Cuando comienza un nuevo ciclo de operación, si el bit de estado 0 del DTC permanece en el ciclo de operación anterior también depende de cómo lo defina el OEM.Después de ejecutar varias pruebas, el resultado vuelve a pasar --> el bit de estado 0 de el DTC cambia de 1 a 0, indicando que la falla no ha vuelto a aparecer.

• 12 Comienza un nuevo ciclo de operación, se completa la ejecución de la prueba y aún se pasa el resultado, el bit 6 cambia de 1 a 0, lo que indica que la prueba se ha ejecutado al menos una vez en el nuevo ciclo de operación.

• 13, 14 La ejecución de la prueba se completa y el resultado es fallido --> Los bits de estado DTC bit0 y bit1 cambian de 0 a 1, lo que indica que se ha detectado una falla en un nuevo ciclo de operación.

• 15 El bit de estado bit3 del DTC cambia de 0 a 1, lo que indica que la falla ha sido confirmada por dos ciclos de operación.

11 ¿Qué es la gravedad del DTC?  

La gravedad de DTC ocupa 1 byte de datos y contiene dos partes de información, información de gravedad de DTC (3 bits) e información de categoría de DTC (5 bits), como se muestra a continuación:

fuente：ISO15031-6 

La información de gravedad de DTC se refiere al grado de impacto o gravedad de un código de problema de diagnóstico en particular. Indica la gravedad de la falla y ayuda a priorizar las acciones necesarias para diagnosticar y tratar el problema. La gravedad generalmente clasifica las posibles consecuencias y efectos de las fallas identificadas, que se dividen en tres categorías en ISO14229-1, de la siguiente manera:

fuente：ISO15031-6     

• Solo mantenimiento (maintenanceOnly): cuando un código de diagnóstico o advertencia indica un problema que no es de emergencia o una tarea de mantenimiento de rutina que requiere atención, pero que no requiere una acción inmediata. Indica que el problema debe resolverse en la próxima cita de mantenimiento o servicio programada.

• Verificar en la próxima parada (checkAtNextHalt): significa que una falla o problema debe verificarse o repararse tan pronto como sea seguro, generalmente en la siguiente parada. Si bien este problema puede no ser un problema de seguridad inmediato, se recomienda una inspección temprana para evitar daños potenciales o mayores.

• Comprobar inmediatamente : significa que un código de diagnóstico o advertencia indica un problema crítico o grave que requiere atención inmediata. Indica que se debe detener el vehículo tan pronto como sea seguro hacerlo, y se deben tomar las medidas necesarias para resolver el problema de manera oportuna. Continuar conduciendo el vehículo sin abordar el problema podría representar un riesgo para la seguridad o causar más daños.   

La definición exacta y la gravedad variarán según el fabricante y el sistema de diagnóstico utilizado.

La información del nivel de DTC se refiere a la clasificación o clasificación de los DTC según los sistemas o componentes afectados, aplicable a los sistemas OBD que cumplen con WWH-OBD GTR. Entre ellos, la categoría A, categoría B1, categoría B2 o C son los atributos de los DTC relacionados con las emisiones. Estos atributos describen el impacto de las fallas en las emisiones o en las capacidades de monitoreo del sistema OBD. Las definiciones específicas son las siguientes:

fuente：ISO15031-6 

12 ¿Qué es la información instantánea de DTC?

La información instantánea de DTC es un registro de datos específico obtenido a través del protocolo UDS para ayudar a diagnosticar fallas del vehículo. De acuerdo con lo establecido en la norma ISO 14229, la información instantánea del DTC es como una cámara, cuando ocurre una falla, se presiona el botón del obturador sobre la información del vehículo y se realiza un registro para el posterior análisis del problema.

La información instantánea de DTC puede incluir varios aspectos de los datos, como códigos de falla, condiciones de falla, datos del sensor, estado de la unidad de control, etc. La siguiente figura muestra la información instantánea del DTC relacionada con el control del motor, incluida la temperatura del refrigerante del motor, la posición del acelerador, la velocidad del motor, la velocidad del vehículo y otra información, como se muestra a continuación:

fuente：ISO14229-1  

Esta información instantánea de DTC se registra y almacena de manera prescrita, y luego se puede obtener enviando una solicitud de UDS específica a través del instrumento de diagnóstico. En general, la información instantánea de DTC proporciona un registro detallado de la escena de la falla, para que los técnicos puedan comprender con mayor precisión el estado y los parámetros del vehículo cuando ocurre la falla durante el diagnóstico de fallas y el proceso de mantenimiento, y pueden analizar las diferencias de datos cuando ocurre la falla, Identificar fuentes potenciales de falla y tomar las medidas correctivas apropiadas.

Cabe señalar que no todos los vehículos admiten o implementan la información instantánea de DTC en el estándar ISO 14229. Los modelos y fabricantes de vehículos específicos pueden elegir admitir y proporcionar la función de información instantánea de DTC de acuerdo con sus propias necesidades y diseños.

13 ¿Qué son los datos extendidos DTC?  

Los datos extendidos de DTC se refieren a información adicional relacionada con los códigos de diagnóstico de problemas, que proporciona una descripción más detallada de la falla, las condiciones de ocurrencia de la falla, el impacto de la falla y otros datos:

• Descripción de la falla: proporciona una descripción detallada de la falla, como el tipo de falla, la ubicación de la falla, la causa de la falla, etc. Estas descripciones pueden ayudar a los técnicos a comprender mejor la naturaleza y las características de la falla.

• Condiciones de ocurrencia de fallas: Describe las condiciones y circunstancias bajo las cuales ocurren las fallas. Esto incluye condiciones de diagnóstico, estado del vehículo, datos de sensores y más. Conocer las condiciones bajo las cuales ocurrió una falla puede ayudar a los técnicos a simular condiciones similares durante el diagnóstico para reproducir mejor las fallas y solucionarlas.

• Efecto de falla: ilustra el impacto de una falla en el rendimiento y la funcionalidad del vehículo. Esto incluye el impacto en la seguridad, la capacidad de conducción, el rendimiento de las emisiones y más. Conocer el impacto de una falla puede ayudar a los técnicos a evaluar la urgencia y prioridad de la falla y tomar las medidas correctivas adecuadas.

• Sugerencias para la solución de problemas: proporciona sugerencias para la solución de problemas y pasos de reparación para fallas específicas. Estas recomendaciones pueden incluir elementos de inspección, procedimientos de reparación, piezas de repuesto y más. Los técnicos pueden utilizar estas sugerencias para llevar a cabo operaciones de solución de problemas y reparación.

El contenido específico de esta información generalmente lo define el cliente. Los datos extendidos de DTC se obtienen e intercambian a través de la prueba de diagnóstico universal y el protocolo de comunicación de programación (UDS), como se muestra a continuación:

 fuente：ISO14229-1   

El técnico envía una solicitud específica a la ECU del vehículo para obtener datos adicionales relacionados con el DTC, de modo que el técnico pueda diagnosticar y resolver las fallas del vehículo con mayor precisión.

DTC 

         

La forma en que se aplica la información sobre DTC podrá obtener una comprensión más profunda a partir de la introducción de 19 servicios de la UDS posterior. Al comienzo de este artículo, continuaré respondiendo la segunda pregunta: ¿Cómo realiza la ECU el diagnóstico de fallas?

14 Sistema de diagnóstico de fallas  

Puede haber fallas en cualquier parte o entre las partes del automóvil. Incluso si la probabilidad de falla es extremadamente baja, no hay garantía de que no haya fallas. Solo podemos identificar fallas potenciales tanto como sea posible y evitar lesiones personales tanto como sea posible. Por lo tanto, cada ECU del automóvil tiene su propio sistema de diagnóstico de fallas para detectar si hay una falla.Si hay una falla, por un lado, se deben tomar medidas temporales para minimizar el daño, y por otro lado, la falla la información se guarda para su posterior investigación y solución de problemas. Por lo tanto, el sistema de diagnóstico de fallas de la ECU se puede dividir simplemente en dos partes: el sistema de diagnóstico en línea dentro del vehículo y el sistema de diagnóstico fuera de línea fuera del vehículo. La siguiente es una introducción detallada a estas dos piezas:

1.1 Sistema de diagnóstico en línea en el vehículo  

El sistema de diagnóstico en línea en el vehículo se refiere a las condiciones bajo las cuales la ECU usará la lógica para detectar si hay una falla y cómo manejar la falla.

Tomando como ejemplo el sensor de posición del análisis de la función de diagnóstico de fallas de la ECU automotriz serie 1 (qq.com), suponga que es necesario diagnosticar la falla de que el ciclo de trabajo de la señal PWM no es válido. De acuerdo con la especificación del sensor de posición, el rango efectivo del ciclo de trabajo de la señal PWM es [2%, 98%], entonces, ¿cómo diagnosticar?

En primer lugar, aclare con qué frecuencia monitorear , ¿es un monitoreo periódico o un monitoreo de activación intermitente? En este ejemplo, el sensor de posición se usa para monitorear la posición del cigüeñal, es decir, el estado en tiempo real de la operación del motor.La validez de esta señal es muy importante, por lo que se debe adoptar un método de monitoreo periódico, como una vez cada 10 ms.

Luego, cómo detectar fallas , de acuerdo con la definición, la lógica de detección de fallas aquí se puede configurar si el ciclo de trabajo de la señal PWM es [2%, 98%], si no, se produce una falla. ¿Significa una falla que ha ocurrido una falla? No necesariamente, el algoritmo anti-vibración (Debounce) generalmente se usa para confirmar si ocurre una falla acumulando una cierta cantidad o tiempo.

En segundo lugar, qué datos relacionados con la falla deben registrarse , es decir, durante el proceso de generación de la falla, es necesario registrar algunos datos relevantes para que el personal técnico o de mantenimiento posterior pueda encontrar la falla y analizar la causa de la falla, como la instantánea. información y datos ampliados mencionados en el artículo anterior, definen específicamente qué señales necesitan ser registradas.

Finalmente, cómo tratar la falla Cuando se confirma la falla, es necesario tomar las medidas de procesamiento de fallas correspondientes, como la degradación de la función, y encender la lámpara de falla correspondiente, que se muestra en el instrumento para recordar al conductor.

1.2 Sistema de diagnóstico fuera de línea fuera del vehículo  

El sistema de diagnóstico en línea del vehículo mencionado anteriormente registra los datos de fallas relevantes, y estos datos serán utilizados por el personal técnico o de mantenimiento. Específicamente, el personal técnico o de mantenimiento utiliza equipos de diagnóstico externos (como un instrumento de diagnóstico) para obtener información sobre fallas y también pueden usar el instrumento de diagnóstico para eliminar fallas y actualizar el software. Aquí, el sistema que soporta estas operaciones se denomina sistema de diagnóstico fuera del vehículo fuera del vehículo , de la siguiente manera:

De la figura anterior, se puede entender que el sistema de diagnóstico fuera del vehículo fuera del vehículo es un sistema de comunicación para diagnóstico de fallas.De hecho, es un sistema de comunicación de diagnóstico basado en servicios UDS, es decir, un dispositivo de diagnóstico externo (como un instrumento de diagnóstico) envía una solicitud, y luego la ECU responde con una respuesta. Por ejemplo, use un instrumento de diagnóstico para solicitar leer la información de falla del ciclo de trabajo de la señal PWM. Si la ECU pasa la verificación, responderá DTC, bit de estado de DTC, gravedad de DTC y otros datos; o use el instrumento de diagnóstico para borrar la falla, la ECU responderá si la falla está clara; o use la herramienta de diagnóstico para actualizar el software, luego la ECU responderá al progreso en tiempo real de la actualización del software.

Es decir, el núcleo del sistema de diagnóstico fuera de línea del vehículo es el servicio UDS, cuya definición puede referirse a la norma ISO 14229-1. En general, el servicio UDS se puede dividir en 6 categorías según las funciones, con un total de 26 servicios, que son:

• Unidades funcionales de diagnóstico y gestión de la comunicación, incluyendo 10 servicios de 10, 11, 27, 28, 3E, 83, 84, 85, 86, 87;

• Unidad funcional de transmisión de datos, que incluye 7 servicios de 22, 23, 24, 2A, 2C, 2E y 3D;

• Unidad funcional de transmisión de datos de almacenamiento, que incluye 2 tipos de servicios 14 y 19;

• Unidades funcionales de control de entrada y salida, incluidos los servicios 2F;

• Unidad funcional de rutina, que incluye 31 servicios;

• Unidad funcional de control de carga y descarga, que incluye 5 servicios 34, 35, 36, 37, 38.

15 Por qué se necesita Debounce  

La razón para usar el rebote (debounce) en la resolución de problemas es resolver el problema de la inestabilidad de la señal. La fluctuación de señal es la recepción de una señal errática breve en un circuito, que puede ser causada por el ruido de la fuente de alimentación, la física de los interruptores u otros factores de interferencia. Al realizar un diagnóstico de fallas, generalmente es necesario monitorear el estado de la señal de entrada y hacer los juicios y operaciones correspondientes de acuerdo con el estado de la señal. Si hay fluctuaciones en la señal, puede provocar un error de juicio, lo que resulta en resultados de diagnóstico erróneos.

         

Para resolver este problema, se introduce el algoritmo de rebote. Específicamente, si la estrategia de diagnóstico de fallas determina que se ha producido una posible señal de falla, se iniciará un temporizador/contador. Durante la operación del temporizador/contador, si se detecta un cambio en el estado de la señal, el temporizador/contador ser reiniciado Las fallas solo se pueden reconocer después de que el temporizador/contador haya alcanzado el tiempo de estabilización/número de veces establecido. De esta manera, a través del algoritmo antirrebote, se puede eliminar el problema de juicio erróneo causado por la fluctuación de la señal y se puede mejorar la precisión y confiabilidad del diagnóstico de fallas.

16 Algoritmo de rebote  

El paso de diagnóstico de fallas es realizar primero la detección de fallas, es decir, monitorear en tiempo real de acuerdo con las condiciones previas y las condiciones de juicio para juzgar si existe una falla potencial. Por lo general, se utilizan cuatro estados (PREPASO, PASO, PREFAILED, FAILED) para representar el resultado de la evaluación. Para algunas fallas, no es necesario confirmar la falla a través del algoritmo Debounce. En este momento, los resultados de la evaluación son solo APROBADO y FAILED, que se confirman directamente; Algunas fallas pueden ser causadas por algunas fluctuaciones de la señal, no fallas, así que llamémoslas fallas potenciales. En este momento, PREFAILED y PREPASSED se introducen para indicar que necesita usar el algoritmo Debounce para confirmar aún más si es una falla. Actualmente, hay dos algoritmos antirrebote de uso común: el algoritmo antirrebote basado en contador y el algoritmo antirrebote basado en tiempo.

Algoritmo de rebote basado en contador  

El algoritmo utiliza un contador de rebote (el rango de conteo depende de la definición específica) para registrar el resultado de la evaluación. Cuando se obtiene un estado PREFAILED de acuerdo con la condición previa y la condición de evaluación, el contador (Contador de detección de fallas) aumentará en uno. paso, de modo que la Acumulación continua, cuando el conteo acumulativo alcanza el límite de falla establecido, el estado de falla se convierte en Falla, es decir, la falla potencial se confirma, como se muestra en la figura a continuación en el momento t1.

Después de que se confirmen algunas fallas, es posible recuperarlas, es decir, siempre que se obtenga el estado PREPASADO de acuerdo con las condiciones previas y las condiciones de juicio, el contador (Contador de detección de fallas) se reducirá en un paso, de modo que Cuando alcanza el límite de Aprobado, el estado de falla se convierte en Aprobado, es decir, la falla ha sido eliminada, como se muestra en el tiempo t2 en la siguiente figura.

Para los dos valores en la figura anterior (valor de salto hacia abajo y valor de salto hacia arriba), es necesario explicarlo aquí nuevamente. El llamado valor de salto hacia abajo significa que se confirma que la falla está en estado de falla En el estado PREAPROBADO, el valor del contador no disminuirá en un paso desde el límite FALLIDO establecido, sino que saltará al valor de Salto hacia abajo y comenzará a disminuir en un paso. De la misma manera, comprenda el valor de Jump up, ambos definidos por el usuario.

Algoritmo de rebote basado en el tiempo  

El algoritmo utiliza un temporizador de rebote (el rango también es de -128 a 127) para registrar el resultado de la evaluación. Cuando se obtiene un estado PREFAILED de acuerdo con la condición previa y la condición de evaluación, el temporizador (Contador de detección de fallas) comienza a contar y acumula durante un período de tiempo t_failed, aún no aparece el estado PREPASSED o PASSED, luego el estado de falla se convierte en Failed, como se muestra en la siguiente figura en el tiempo t1; dentro de t fail, si aparece el estado FAILED, entonces el estado de falla se convierte directamente en Failed , es decir, se confirma la falla, como se muestra en la siguiente figura en el tiempo t4.

Cuando se confirma la falla, luego cuando se obtiene el estado PREPASADO de acuerdo con las condiciones previas y las condiciones de juicio, entonces el contador se reinicia a cero y comienza a contar nuevamente. De manera similar, el estado PREPASSED permanece. Después de un período de tiempo t_passed, significa que la falla ha sido eliminada. Como se muestra en la siguiente figura en el tiempo t2.

Cuando se confirma la falla, luego cuando se obtiene el estado APROBADO de acuerdo con las condiciones previas y las condiciones de juicio, el contador no necesita acumular tiempo e indica directamente que la falla se ha eliminado, como se muestra en el tiempo t3 en la figura a continuación.

Fuente |  Automoción y software básico