Protocolo de diagnóstico Ethernet DoIP (Protocolo de diagnóstico Ethernet DoIP)

Índice de contenidos de los artículos de la serie.

Serie de habilidades de C++
Serie de arquitectura de comunicación de Linux
Serie de programación optimizada de alto rendimiento de C++ Serie de
comprensión profunda de la serie de diseño de arquitectura de software Serie de patrones de diseño de
programación de subprocesos concurrentes avanzados de C++

¡Esperamos su atención! ! !

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

El diagnóstico es esencial ya sea por parte del OEM o del proveedor, desde el diseño de nivel superior o desde el diseño de nivel superior, como el diagnóstico CAN, el diagnóstico LIN y el diagnóstico Ethernet.

Independientemente de I+D, preventa o posventa, se requiere diagnóstico, como actualizaciones y flasheos de la ECU, actualizaciones y actualizaciones de la tienda 4S, actualizaciones de OTA, etc.

1.1 Función de la función de diagnóstico

(1) Identificar, inspeccionar y confirmar el estado del vehículo
(2) Proporcionar datos de mantenimiento, reparación y actualización del vehículo

1.2 Métodos de diagnóstico del vehículo

(1) Diagnóstico local (por ejemplo, el personal de la tienda 4S usa OBD para leer la información de la ECU y actualizarla y flashearla)
(2) Diagnóstico remoto (por ejemplo, diagnóstico remoto a través de la nube)
(3) Pantalla de instrumentos (por ejemplo, la luz indicadora en el tablero del vehículo muestra una presión de neumáticos insuficiente) )

1.3 Historial de desarrollo de funciones de diagnóstico.

tiempo	protocolo	describir
1996	ISO9141-2	Requisitos de CARB para el intercambio de información
1999	ISO14230	Protocolo de palabras clave 2000
1999	ISO/DIS15765	Diagnóstico en CAN - basado en KWP2000
2001	ISO15031	Comunicación para diagnósticos relacionados con emisiones.
2001	ISO15765	Diagnóstico en CAN - basado en UDS
2006	ISO14229	Servicios de Diagnóstico Unificado (UDS)
2013	ISO14229	Servicios de Diagnóstico Unificado (UDS)

1.4 Protocolo de función de diagnóstico del vehículo

El protocolo de diagnóstico UDS (Unified Diagnostic Services) es un protocolo de comunicación de diagnóstico en el entorno de la ECU electrónica del automóvil. En pocas palabras, se puede entender que el protocolo de diagnóstico UDS es el protocolo ISO 14229. El protocolo ISO 14229 define el uso del servicio UDS, el formato del servicio y otra información. El objetivo principal del diagnóstico UDS es determinar de forma rápida y precisa la falla y la causa del vehículo o de un controlador, proporcionando así una base confiable para el mantenimiento.

Norma UDS-ISO:14229

ISO14229	Servicios de Diagnóstico Unificado (UDS)
ISO14229_1	Especificaciones y requisitos: define el servicio de diagnóstico, solo la capa de aplicación, no involucra red ni implementación.
ISO14229_2	Servicios de capa de sesión
ISO14229_3	Servicios de diagnóstico unificado en la implementación de Can (UDSSonCAN): define la implementación de UDS en el bus CAN
ISO14229_4	Servicios de diagnóstico unificado en la implementación de FlexRay (UDSSonFR)
ISO14229_5	Servicios de Diagnóstico Unificado sobre implementación IP（UDSonIP）
ISO14229_6	Implementación de UDS en K-Line（UDSonk-Line）
ISO14229_7	UDS en red de interconexión local（UDSonk-LIN）

El protocolo de diagnóstico es una especificación de requisitos para la comunicación de diagnóstico en la industria automotriz, definida por la serie de normas ISO-14229. Aplicado a la capa de aplicación (capa 7) del modelo OSI de siete capas, solo especifica requisitos de servicio relacionados con el diagnóstico y no involucra mecanismos de comunicación, por lo que se puede utilizar en diferentes buses automotrices (como CAN, LIN, FleXRAY , Ethernet y línea K).

Cuando se utiliza ISO-14229, se pueden cambiar los siguientes mecanismos de comunicación, como basados ​​en CAN, basados ​​en LAN, basados ​​en FlexRay, etc. El proceso de comunicación de diagnóstico es en realidad muy simple: el instrumento de diagnóstico envía una solicitud de diagnóstico (solicitud) y la ECU da una respuesta de diagnóstico (respuesta). UDS define contenido y formato unificados para diferentes solicitudes y respuestas de funciones de diagnóstico.

1.5 Elementos de comunicación de la función de diagnóstico

• El servicio
  de diagnóstico UDS incluye 6 categorías y 26 tipos de servicios, cada servicio tiene su propio ID independiente, a saber, SID (Identificador de servicio).
  

• La sesión
  puede entenderse como un determinado modo o permiso de diagnóstico, es decir, en diferentes modos, existen restricciones en el uso de diferentes servicios de diagnóstico.
  

Código de función	ilustrar
1	Sesión predeterminada
2	Programación
3	Extendido

• DTC

1.6 Proceso de comunicación de la función de diagnóstico

De hecho, el mecanismo de comunicación diagnóstica es muy simple, basado en eventos, una pregunta y una respuesta.

De manera análoga al método de comunicación cliente-servidor, el instrumento de diagnóstico es el cliente, que envía la solicitud. El servidor es la ECU. Después de recibir la solicitud, la procesa y luego responde con una respuesta al instrumento de diagnóstico.

• Servicios que requieren confirmación
  

• Servicios que no requieren confirmación
  

Sin embargo, el protocolo de diagnóstico tiene sus propias características: estipula el formato de la solicitud y la respuesta, y el formato debe verificarse cuando se recibe la solicitud. Al mismo tiempo, debido a los diferentes métodos de direccionamiento, si existe soporte de subfunciones, etc., también afectarán los métodos de procesamiento y los resultados de la solicitud y la respuesta.

1.7 protocolo DoIP

DoIP: comunicación de diagnóstico a través del protocolo de Internet.

• Un protocolo de comunicación Ethernet para la funcionalidad UDS.
• ISO 13400

1.7.1 Escenarios de aplicación DoIP:

(1) Local uno a uno
(2) Local muchos a muchos
(3) Remoto uno a muchos
(4) Híbrido remoto

1.7.2 Estándar DoIP ISO:13400

Estándar:
ISO:13400_1: Definir información básica y casos de uso
ISO:13400_2: Protocolo de capa de red, servicio de capa de transporte
ISO:13400_3: Basado en 802.3, definir secuencia de líneas e interfaz
ISO:13400_4: Definir conector de diagnóstico
ISO:13400_5: Prueba de conformidad

1.7.3 Formato de mensaje DoIP:

Los mensajes DoIP constan de un encabezado DoIP y una carga útil, como se muestra en la siguiente figura.

• (1) El encabezado DoIP contiene: número de versión del protocolo DoIP, actualmente 0x02 (DoIP 2012).
• (2) El número de versión del protocolo está invertido, actualmente 0xFD. Nota: El protocolo establece específicamente que la versión del protocolo puede ser 0xFF. El propósito de establecer este valor es que cuando las versiones del protocolo del cliente y del servidor no coinciden, este valor se puede configurar para evitar el caso en el que la versión del encabezado del protocolo no coincida. no coincide y la solicitud es rechazada.
• (3) Tipo de carga útil, dividido en 3 categorías principales:
  ① Categoría de gestión de nodos, incluida la respuesta negativa del encabezado DoIP, declaración e identificación del vehículo, activación de ruta, verificación en línea;
  ② Categoría de información del vehículo, incluido el estado de la entidad DoIP, información del modo de energía de diagnóstico;
  ③ Clase de datos de diagnóstico, incluidos los mensajes de diagnóstico.
  El significado de cada tipo de mensaje se muestra en la siguiente tabla. Para significados específicos, consulte el estándar.
  

1.7.4 Proceso de comunicación DoIP

Las 4 etapas de la comunicación DoIP
(1) Conexión física: el probador utiliza métodos cableados o inalámbricos para establecer una conexión con el vehículo.
Diagrama de línea de conexión física:

(2) Asignación de direcciones IP: asigne direcciones IP de forma estática o dinámica para que el probador y los vehículos puedan comunicarse a través de la red.

• Asignación estática: el probador debe configurarse antes de conectarse al vehículo (la asignación estática se puede realizar durante el desarrollo y las pruebas iniciales)
• Asignación dinámica: el protocolo DHCP asigna dinámicamente direcciones IP (recomendado: dispositivo externo como servidor, vehículo como cliente para iniciar la solicitud DHCP)

(3) Descubrimiento del vehículo: el probador identifica y confirma el vehículo diagnosticado.

• El proceso de encontrar e identificar un vehículo.
• Identificador: VIN, EID, GID del vehículo y otra información
  (4) Comunicación de sesión de diagnóstico: el probador se comunica con el vehículo para funciones de diagnóstico
• Establecer conexión TCP
• Comunicación de la función de diagnóstico
  

1.7.5 Función de puerta de enlace DoIP

Proceso de comunicación de la puerta de enlace DoIP