I. Resumen
Los servicios definidos por UDS se dividen lógicamente en 6 categorías, en el artículo anterior se ha interpretado la categoría de diagnóstico y gestión de la comunicación, “categoría de transmisión de datos” y “transmisión de datos de almacenamiento”, en este artículo se introducirán los tres tipos restantes de servicios UDS, a saber, “servicio de control IO”, “servicio de programa rutinario” y “servicio de carga y descarga”.
2. Contenido del servicio de diagnóstico
O servicios de control
1. Control de salida de entrada por identificador (0x2F)
$2F es un servicio que utiliza ID para controlar la entrada y salida de la ECU y, a menudo, se utiliza en la línea de producción para verificar el funcionamiento de las piezas. Por ejemplo, en la etapa de ensamblaje final, los trabajadores deben verificar si varias funciones en el automóvil son normales, como si las cuatro ventanas están arriba y abajo normalmente. Si presionan los interruptores uno por uno, la eficiencia es muy baja. Si pueden observar la ventana arriba y abajo a través de un comando de diagnóstico, la eficiencia es mucho mayor.
Por ejemplo, si la ECU recibe una señal de entrada A, podemos usar 2F para asignar un valor que necesitamos a este A; si la ECU controla un actuador B, podemos usar el servicio 2F y agregar algunos parámetros específicos para realizar el control de B, como el control de la puerta para controlar la elevación de la ventana, el plegado del espejo retrovisor, etc.
La solicitud de servicio de $2F consta de 4 partes
El primer byte: SID=0x2F
El segundo y tercer byte: dataIdentifier (2 bytes), utilizado para identificar el objeto IO controlado, por ejemplo, el siguiente ejemplo 0x9B00 (posición de la puerta de entrada)
El cuarto byte: controlOptionRecord, utilizado para identificar el tipo de control, y varios bytes de controlState utilizados por el fabricante. UDS define claramente cuatro tipos de control
0x00 Control de retorno a la ECU, es decir, control final
0x01 Establece la señal de entrada, los parámetros internos, la señal de salida, etc. del objeto identificado por DID al valor predeterminado
0x02 Congelar la señal de entrada, parámetros internos, señal de salida, etc. del objeto identificado por DID
0x03 Establecer la señal de entrada, los parámetros internos y la señal de salida del objeto identificado por el DID es equivalente a iniciar el control de la ECU, este tipo de control será seguido por el quinto byte, que puede representar el valor digital o analógico del objeto de control.
Por ejemplo:
Use 2F para controlar la posición de la puerta de entrada de aire (posición de la puerta de entrada de aire) y use DID (identificador) = 0x9B00 para identificar la posición de la puerta de entrada de aire.
Posición de la puerta de entrada de aire [%] = decimal(Hex) * 1 [%], es decir, use un porcentaje para representar esta posición.
paso 1:
El probador envía 22 9B 00 para leer la posición actual de la puerta de entrada de aire, donde 22 es el SID y 0x9B00 es el segundo y tercer byte DID.
ECU devuelve 62 9B 00 0A, donde 0x0A = 10 (dec), lo que significa que la posición actual es 10%
(UDS define que el identificador de datos utilizado en el servicio 2F puede ser leído por el servicio 22, y el valor devuelto es información de estado. La información de estado específica la define el usuario).
paso 2:
El probador envía 2F 9B 00 03 3C, lo que significa ajustar la posición de la puerta de entrada de aire al 60 %, y 0x3C = 60 (dec) significa establecer el valor analógico del objeto de control al 60 %.
La ECU devuelve 6F 9B 00 03 0C, lo que indica que se acepta el control y la posición actual de la puerta de entrada de aire es 12%. Debido a que la ECU responde inmediatamente después de recibir la solicitud, y el ajuste de la posición de la puerta lleva tiempo, por lo que no ha llegado al 60 %.
paso 3:
Después de un tiempo, el probador envía 22 9B 00 para leer la posición actual de la puerta de entrada de aire
ECU devuelve 62 9B 00 3C, 0x3C = 60 (dec), lo que indica que la posición actual ha alcanzado el 60%
etapa 4:
el probador envía 2F 9B 00 00 para devolver el control a la ECU
ECU devuelve 6F 9B 00 00 3A, lo que indica que se acepta la solicitud y la posición actual es 58%
paso5:
El probador envía 2F 9B 00 02 para congelar el estado de la posición de la puerta de entrada de aire representada por el ID 9B 00
La ECU devuelve 6F 9B 00 02 32, lo que indica que se acepta la solicitud y la posición actual permanece al 50 %
Además, hay un problema con el servicio 2F (citado por el autor de Zhihu "La flor del alma"). Si se modifica un cierto valor a través del servicio 2F y el control no se devuelve a la ECU, ¿continuará el tiempo efectivo de esta modificación? La forma correcta es volver a la sesión predeterminada si la sesión extendida se agota. En este momento, el derecho de control debe devolverse a la ECU. Después de todo, la subfunción 03 de 2F es "tomar temporalmente el control del derecho".
servicio de control de rutina
Control de rutina (0x31)
El servicio $31 es una interfaz para llamar a algunas secuencias de operación integradas en la ECU.La aplicación de este servicio es muy flexible, porque los fabricantes pueden definir varias operaciones internas para la ECU de acuerdo con sus propias necesidades, y para ejecutar estas operaciones, solo necesitan llamar al servicio 31. Los usos típicos incluyen verificar las condiciones de los límites, borrar la memoria flash, verificar datos, verificar dependencias de software y hardware, etc., e incluso restaurar la configuración de fábrica si es necesario, y también se pueden definir muchas operaciones relacionadas con las funciones lógicas propias de la ECU.
31 solicitud de servicio consta de 4 partes
SID=0x31
subfunción, subfunción, inicio (0x01), parada (0x02), resultado de la consulta (0x03)
identificador de rutina, el ID de la tarea, que se utiliza para identificar la rutina que se va a ejecutar
routeControlOptionRecord, este es un parámetro opcional, que se utiliza para identificar los parámetros necesarios para la ejecución de la rutina, y cada empresa puede personalizar su contenido
Por ejemplo:
Suponga que el ID 0x0809 se usa para representar la rutina que verifica si la ECU cumple con las condiciones de parpadeo del software (como la velocidad del vehículo y la velocidad de rotación son 0, KL15 está encendido, etc.).
El probador envía 31 01 08 09 para iniciar la rutina 0x0809
Si se cumplen todas las condiciones, la ECU devuelve como eco 71 01 08 09. Si no se cumplen las condiciones, la ECU devuelve 71 01 08 09 XX YY ZZ, y el siguiente XX YY ZZ indica qué condiciones no se cumplen, y el contenido específico lo define el fabricante.
Servicios de carga y descarga
La transmisión de datos de actualización de ECU se completa a través de servicios como 34 (solicitud de descarga), 36 (transmisión de datos), 37 (solicitud de salida de transmisión). Dado que el tamaño del búfer utilizado para almacenar en caché los datos del servicio de diagnóstico en la ECU automotriz es limitado, cuando necesitamos leer o escribir datos que excedan el tamaño del búfer, no podemos simplemente usar los servicios 2E y 22. Por lo tanto, UDS define varios servicios para escribir o leer grandes bloques de datos, a saber, descargar y cargar datos.
La unidad funcional Carga Descarga define un total de 5 servicios de diagnóstico, a saber:
RequestDownload (0x34): el instrumento de diagnóstico solicita a la ECU que descargue datos
RequestUpload (0x35) El instrumento de diagnóstico solicita a la ECU que cargue datos
TransferData (0x36) El instrumento de diagnóstico transmite datos a la ECU (descarga), o el servidor transmite datos al cliente (carga)
RequestTransferExit (0x37) Transferencia de datos completa, solicitud para salir
RequestFileTransfer (0x38) La operación de transferencia de archivos se puede utilizar para reemplazar los servicios de carga y descarga.
La siguiente figura muestra el proceso simplificado de descarga de datos. Se utilizan los tres servicios 34, 36 y 37. Si está cargando, el servicio 34 se reemplaza por el servicio 35 y la dirección de transmisión de datos cambia.
paso 1:
El instrumento de diagnóstico transmite la dirección de inicio del bloque y la información de longitud de datos del bloque a través de 34 servicios, solicitud de descarga;
Después de que la ECU recibe la solicitud de descarga del servicio 34, notifica al instrumento de diagnóstico a través de un mensaje de respuesta positiva 74, cuántos bytes de datos deben incluirse en cada siguiente mensaje de transmisión de datos (servicio 36) del (instrumento de diagnóstico). El instrumento de diagnóstico ajusta su propia capacidad de envío de acuerdo con los parámetros devueltos;
paso 2:
El instrumento de diagnóstico transmite los datos de este bloque a través de 36 servicios, y la cantidad de datos transmitidos por cada 36 servicios está determinada por los parámetros de los 34 servicios (es decir, SID=0x74) devueltos por la ECU; consulte los detalles a continuación.
La ECU devuelve una respuesta positiva al servicio 36;
Los datos se dividen y envían secuencialmente a través de 36 servicios, y la ECU responde con una respuesta afirmativa cada vez que se completa el envío de 36 servicios. Hasta que se envíe todo el bloque de datos;
paso 3:
El instrumento de diagnóstico realiza una solicitud de salida de transmisión enviando 37 servicios;
La ECU da una respuesta positiva.
La descripción de cada servicio es la siguiente:
La descripción de cada servicio es la siguiente:
Solicitud de descarga (0x34):
El servicio 0x34 se usa para iniciar la transmisión de descarga, y su función es informar a la ECU que está lista para aceptar datos, y la ECU le dice al instrumento de diagnóstico si debe permitir la transmisión y cuánto puede aceptar a través de la respuesta 0x74.
El formato de solicitud del servicio 0x34 incluye 5 partes
La primera parte: 1 byte SID=0x34
La segunda parte: 1 byte dataFormatIdentifier, utilizado para indicar el método de compresión y cifrado de datos. Entre ellos, los bits 7-4 definen el método de compresión, los bits 3-0 definen el método de cifrado. Cuando el byte es 0x00, significa que no se utiliza ni el método de compresión ni el método de cifrado. Las definiciones de otros valores distintos de 0x00 las estipulan los propios fabricantes de automóviles.
La tercera parte: addressAndLengthFormatIdentifier de 1 byte, que se utiliza para indicar el número de bytes ocupados por las dos últimas partes. Los 4 bits altos indican la longitud de bytes ocupada por memorySize, y los 4 bits bajos indican la longitud de bytes ocupada por memoryAddress. En este ejemplo puse estos dos valores en n y m respectivamente.
La cuarta parte: dirección de memoria de m bytes, indicada por los 4 bits inferiores en addressAndLengthFormatIdentifier. El significado es escribir la dirección lógica de los datos en la ECU.
La quinta parte: el tamaño de memoria de n bytes, indicado por los 4 bits altos en addressAndLengthFormatIdentifier. Significado es el número de bytes de datos a escribir.
Después de que la ECU reciba la solicitud, si se permite la transmisión, dará la siguiente respuesta
La primera parte: 1 byte Respuesta SID=0x74
La segunda parte: 1 byte dataFormatIdentifier como eco
La tercera parte: maxNumberOfBlockLength, la longitud es variable, lo que indica la cantidad máxima de datos que se pueden transmitir a la vez a través del servicio 0x36.
Transferir datos (0x36):
Si el servicio 34 obtiene una respuesta correcta, el probador iniciará el proceso de transmisión de datos y se utilizará el servicio 36. 36 El formato del servicio es el siguiente.
La primera parte: 1 byte SID=0x36.
La segunda parte: 1 byte blockSequenceCounter, que identifica la cantidad de bloques de datos que se están transmitiendo actualmente, es decir, el número de trama, o simplemente, la cantidad de veces que se llama al servicio 36.
La tercera parte: transferRequestParameterRecord, los datos transferidos. El límite superior de la cantidad de datos transmitidos por primera vez es maxNumberOfBlockLength en la respuesta del servicio 34.
Ejemplo: si la ECU informa al probador que maxNumberOfBlockLength = 20 (eco del servicio de $34), es decir, el probador solo puede enviar un máximo de 20 bytes cada vez a través del servicio 36, incluidos SID y blockSequenceCounter, por lo que, de hecho, la información de datos que se puede transmitir cada vez es solo de 18 bytes. Si los datos que debe transmitir el probador son 50 bytes, debe transmitirse tres veces, transmitiendo cada vez 18, 18 y 14 bytes respectivamente, es decir, llamando a 36 servicios tres veces.
La respuesta de 36 es muy simple, es decir, un byte de Response SID más un byte de blockSequenceCounter como eco.
Solicitud de salida de transferencia (0x37):
El servicio de $ 37 se usa para dejar de cargar y descargar. Si los servicios anteriores 34 y 36 se ejecutan con éxito, entonces el servicio 37 puede obtener una respuesta positiva de la ECU.
El formato es muy simple, la solicitud es 37 y la respuesta correcta es 77, ambas de un byte.
Si los 36 servicios anteriores no se ejecutan, tome el ejemplo que di anteriormente, por ejemplo, el bloque de datos tiene 50 bytes, pero el probador solo envía los 36 servicios dos veces y 36 bytes, entonces esta transmisión es una falla para la ECU, por lo que la ECU debe dar NRC 0x7F 37 24, lo que indica que hay un error en la ejecución de la secuencia de diagnóstico.
3. Equipos de aplicación de UDS
Entre los productos de diagnóstico UDS, el más conocido y ampliamente utilizado es la tarjeta CAN VN1630/1640 de la empresa alemana Vector.Con su software CANoe, el producto Vector tiene funciones completas y es adecuado para el desarrollo de autobuses automotrices a nivel de sistema, y es adoptado por la mayoría de los fabricantes de automóviles. Por lo general, los ingenieros primero usan CANdela de Vector para desarrollar el archivo cdd y luego importan el archivo cdd a CANoe.diva para realizar pruebas funcionales. El siguiente enlace es un conjunto completo de soluciones proporcionadas por Vector, y CANdesc es un software de generación de código UDS.
Los productos Vector son fáciles de usar, ahorran tiempo de desarrollo, no abren API y son caros, por lo que no son adecuados para pruebas automatizadas de equipos de desarrollo de hardware y líneas de producción. En la actualidad, hay muchos fabricantes de CAN (como Kvaser, ZLG, etc.) en el mercado que pueden proporcionar dispositivos de bajo costo, tamaño pequeño, controlador simple y API abierta, que son muy adecuados para el desarrollo secundario.
- resumen
Hasta ahora, se ha completado la actualización del protocolo de diagnóstico UDS.El protocolo UDS es oscuro y complicado, y requiere experiencia real para profundizar la memoria y profundizar la comprensión durante el uso.Bienvenido a comunicarse en cualquier momento.