Cómo leer la información de diagnóstico de UDS
El protocolo de diagnóstico UDS (Unified Diagnostic Service) es un protocolo de diagnóstico automotriz universal definido por ISO 15765 e ISO 14229. Está ubicado en la capa de aplicación del modelo OSI y se puede utilizar en diferentes autobuses automotrices ( como CAN, LIN, Flexray, Ethernet y K-line). La definición de la capa de aplicación del protocolo UDS es ISO 14229-1 y la mayoría de los fabricantes de automóviles utilizan actualmente el protocolo de diagnóstico UDS a través de CAN.
UDS es esencialmente un conjunto de servicios***, que incluye 26 tipos en 6 categorías.
Debe recordar la forma de respuestas de sí y no.
De los 26 tipos de servicios que hay en UDS, 7 son muy importantes. Son:
Los 7 servicios se explican a continuación.
$10 incluye 3 subfunciones,
Cuando la ECU está encendida, ingresará a la sesión predeterminada (predeterminada). Si ingresa a una sesión no predeterminada, se ejecuta un temporizador y si no hay solicitudes durante un período de tiempo, cuando el tiempo expira, el diagnóstico vuelve a la sesión predeterminada 01. Por supuesto, tenemos un servicio de $3E que mantiene los diagnósticos en un estado no predeterminado.
El mensaje contiene 4 tipos, a saber
NRC: Código de respuesta negativa. Si la ECU rechaza una solicitud, responderá con un NRC, y diferentes NRC tienen diferentes significados.
Ocho bytes de datos, el primer byte lo ocupa la capa de red.
El 0 en 02 representa el SF de trama única de la capa de red, el 2 representa los dos bytes en el campo de datos; 10 es el SID y 02 es la subfunción.
02 Igual que arriba, 140 representa una respuesta positiva al SID, 02 es una subfunción.
03 Igual que el anterior, 7F significa respuesta negativa, 10 es SID, 22 es NRC.
El servicio 3E se utiliza para indicar al servidor que el programa de diagnóstico todavía está conectado a la red y que las capacidades del servicio de diagnóstico previamente activadas pueden permanecer activas.
Ejemplo:
27 servicios, más un subservicio, más una clave para desbloquear solicitudes de servicio.
Por ejemplo, en el siguiente ejemplo, 2n-1 es un determinado subservicio. A través de la primera ronda de solicitudes de semillas, la primera ronda de ECU devolverá 67+01+AA+BB+CC+. DD, AA~ DD es la semilla. Más tarde, en la segunda ronda, el grupo de diagnóstico operará en la semilla (usando el algoritmo del OEM), generará k1 (no necesariamente 1 byte) y luego enviará la solicitud 27+02+[k1]. La ECU también utilizará la semilla para calcular k2.
$22 Leer datos,
Solicitud:
Respuesta:
Parte del DID se especifica en ISO 14229-1. Por ejemplo, 0xF186 es el identificador de datos de la sesión de diagnóstico actual, 0xF187 es el identificador de datos del número de pieza de repuesto del fabricante del vehículo, 0xF188 es el identificador de datos del número de software de la ECU del fabricante del vehículo y 0xF189 es el identificador de datos del número de versión del software de la ECU del fabricante del vehículo.
$22 para escribir datos,
Solicitud:
Respuesta:
Nota, por ejemplo, 0xF186 (DID) no admite transferencia directa Los datos entrantes deben convertirse a $ 10 por sesión. Es decir, para solicitudes de escritura de datos, normalmente es necesario estar en una sesión no predeterminada o en un estado desbloqueado.
DTC (Código de diagnóstico de falla): Si el sistema detecta un error, se almacenará como un DTC, que puede manifestarse como: Falla evidente: pérdida de la señal de comunicación (no provoca que se encienda la luz indicadora de falla). para iluminar); fallas relacionadas con las emisiones; errores relacionados con la seguridad, etc. El DTC puede mostrar la ubicación y el tipo de falla. Normalmente, DTC ocupa 3 bytes y OBD II ocupa 2 bytes.
Los códigos de falla incluyen cuatro categorías principales: PCBU, P (tren motriz), C (chasis), B (carrocería) y U (sistema de comunicación de red). Un mensaje DTC contiene 4 bytes. El último byte es el estado del DTC. Los primeros dos bytes son el código de falla familiar, similar a P0047.
28 subfunciones por $19. Las subfunciones comúnmente utilizadas son: 02 (leer DTC a través de la máscara de estado de DTC), 04 (leer información de instantáneas), 06 (leer información extendida), 0A (leer todos los datos de DTC admitidos por la ECU).
Borra (restablece) el formato DTC y cambia el estado del DTC. 3 FF significa borrar todos los DTC.
El envío y recepción de datos de diagnóstico en UDS se basa en CAN, por lo que cada flujo de datos contiene la estructura del mensaje CAN básico.
Según la descripción del artículo anterior de UDS, cada PDU contiene control
Formato PDU (Unidad de datos de protocolo) de capa de red PCI (Información de control de protocolo): como se muestra en la siguiente figura:
En resumen, N_PDU = N_PCI+N_DATA, N_PCI El valor se concentra principalmente en los primeros tres bytes de N_DATA, el valor de N_PCI se concentra principalmente en los primeros tres bytes de N_DATA y el valor de N_DATA se concentra principalmente en los primeros tres bytes de N_DATA. N_PDU = N_PCI + N_DATA, el valor de N_PCI se concentra principalmente en los primeros tres bytes y el valor de N_DATA se concentra principalmente en los últimos siete bytes.
¡Usemos un ejemplo para ilustrar este punto!
[Error en la carga de la imagen... (image-b66bab-1538824826939)]
Dado que los datos se envían y reciben en un cuadro, los primeros datos Los cuatro bits superiores son 0, 02, 03, 02 y 06. Los cuatro bits inferiores del primer byte de los cuatro flujos de datos indican cuántos bytes de datos están contenidos en la trama. Los bits de datos sobrantes se rellenan con líneas 00 o AA.
[Error en la carga de la imagen... (image-b5e84b-1538824826939)]
Los datos se envían en un solo cuadro, por lo que 06 significa que los datos enviados contienen 6 bytes,
p>
La respuesta es una respuesta positiva, que es un cuadro continuo.
Referencias:.