Ethernet SOMEIP de Autosar

prefacio

Antes de nada, me gustaría hacerte unas preguntas, ya sabes:

• ¿Sabes qué es SOME/IP?
• ¿Sabe por qué hay SOME/IP, es decir, antecedentes relacionados?
• ¿Sabe cómo SOME/IP está íntimamente relacionado con SOA?
• ¿Cómo debería usarse SOME/IP en la práctica?

Hoy exploraremos y responderemos estas preguntas juntos. Para que sea más fácil de entender para todos, el siguiente es un resumen de los temas de este artículo:

---

texto

Introducción general

Como se presentó en el artículo anterior "Introducción a los enlaces Ethernet de vehículos ", la pila de protocolos Ethernet de vehículos se puede dividir en cinco capas, a saber , la capa física, la capa de enlace de datos, la capa de red, la capa de transporte y la capa de aplicación . SOME/IP es un protocolo de capa de aplicación .

Según la descripción en AUTOSAR, el contenido del protocolo SOME/IP se puede dividir en tres tipos de subprotocolos: el protocolo estándar SOME/IP en la capa de aplicación, el protocolo SOME/IP-SD y el protocolo SOME/IP-TP protocolo en la capa TP Los contenidos de estas tres partes se complementan entre sí, exponiendo completa y detalladamente todo el contenido del protocolo SOME/IP, que es la única forma de estudiar el protocolo SOME/IP.

Debido al gran contenido del protocolo SOME/IP y las asociaciones complejas, para que todos tengan una comprensión paso a paso de SOME/IP, este artículo explicará principalmente el protocolo estándar SOME/IP en la capa de aplicación debido debido a las limitaciones de espacio, y otro contenido del protocolo se continuará brindando en la siguiente parte. ¡Comparta con todos, preste más atención!

antecedentes y motivacion

En 2011, BMW desarrolló y diseñó un conjunto de middleware que puede realizar el método de comunicación orientado a servicios. Este middleware es diferente del método de comunicación tradicional orientado a señales. No solo puede reducir en gran medida la carga de la red y mejorar la comunicación entre ambos. Eficiencia de las partes, mientras que la introducción de la comunicación Ethernet también puede satisfacer en gran medida las crecientes necesidades de comunicación de los vehículos futuros.

La transmisión de datos orientada a señales siempre se enviará de forma cíclica independientemente de si la red lo necesita o no, mientras que el método de comunicación orientada a servicios es diferente. Solo cuando hay al menos un receptor en la red que necesita los datos, el remitente enviará datos Ventajas significativas del método de comunicación de servicio.

BMW llama al método de comunicación orientado a servicios SOME/IP (nombre completo: Scalable service-Oriented MiddlewarE over IP ). Como sugiere el nombre, se puede ver que el protocolo está muy relacionado con Ethernet, ¡sí! SOME/IP es el middleware que se ejecuta sobre la base de la pila de protocolos Ethernet en el vehículo , o también puede llamarse software de capa de aplicación.

Debido a su popularidad, AUTOSAR acepta gradualmente SOME/IP y está previsto que se incorpore a su estándar oficial y se integre en AUTOSAR 4.X ​​​​en 2014. Varios nodos de desarrollo clave son los siguientes:

• AUTOSAR 4.0 - Integración preliminar completada de mensajes BMW SOME/IP;
• AUTOSAR 4.1 - soporte para SOME/IP-SD y su funcionalidad de publicación/suscripción;
• AUTOSAR 4.2 - Agregar transformador para serialización y otras optimizaciones relacionadas;
• AUTOSAR 4.3: corrige algunos errores del transformador y agrega el protocolo SOME/IP-TP para una gran cantidad de paquetes UDP y otras optimizaciones SOME/IP-SD;
• Optimización continua. . . . . .

¿Qué es ALGUNA/IP?

Como el nombre completo de SOME/IP mencionado en la sección anterior, usemos su nombre completo para entender qué es SOME/IP:

• Escalable

  Una de las intenciones originales del diseño del protocolo es lograr escalabilidad e interoperabilidad entre dispositivos heterogéneos con diferentes plataformas de hardware, diferentes sistemas operativos o firmware incorporado y diferentes aplicaciones de software.

• orientado al servicio

  Indica que es un protocolo básico orientado a servicios. Por lo tanto, los datos se intercambian en una configuración cliente-servidor solo cuando el cliente lo solicita o el servidor lo notifica a un suscriptor específico, lo que garantiza que nunca se desperdicie ancho de banda y que los datos se comuniquen/intercambien solo cuando y donde se necesiten.

• Guerra intermedia

  También es un middleware. Es decir, se ubica en la capa de aplicación y tiene su propia capa de protocolo general para manejar operaciones y aplicaciones más específicas;

• sobre ip

  También es un protocolo basado en Ethernet. Utiliza una interfaz de hardware similar, lo que garantiza hasta 100 Mbps de ancho de banda. Al mismo tiempo, los datos se comunican a través del middleware (es decir, la capa de aplicación) a través del cable de red utilizando el protocolo TCP/IP o UDP.

  Cuando un cliente necesita datos de un servidor, el cliente puede solicitarlos utilizando el protocolo TCP. Si el servidor debe transmitir datos a todos los suscriptores activos, se puede transmitir a través del protocolo UDP. La comunicación de datos sobre el protocolo UDP puede ser unidifusión, multidifusión o difusión.

Como se muestra en la Figura 1 a continuación, muestra claramente la posición de SOME/IP en la pila de protocolos de Ethernet automotriz y la relación con otros módulos:

Figura 1 Relación entre SOME/IP y la pila de protocolos Ethernet del vehículo

Entonces, en la pila de protocolos AUTOSAR, ¿cuál es la posición del protocolo SOME/IP? Como se muestra abajo:

Como se muestra en la figura anterior, el protocolo SOME/IP involucra la interacción con módulos estándar AUTOSAR como RTE, COM, PDUR y SOAd, mientras que SOME/IP-SD utilizado para el descubrimiento de servicios involucra la interacción con BswM, SD y Módulos SoAd . La relación interactiva entre el protocolo SOME/IP y cada módulo se mencionará en el siguiente artículo. Se menciona aquí para que todos tengan un concepto general de la asociación entre el protocolo SOME/IP y la pila de protocolos AUTOSAR. Este artículo no se expandirá demasiado.

SOME/IP se desarrolló originalmente como un mecanismo RPC alternativo para garantizar la compatibilidad con los dispositivos AUTOSAR y brindar la máxima funcionalidad requerida para los casos de uso automotriz, y también es una capa de red diseñada para el protocolo de serialización cliente-servidor entre ECU.

Actualmente, el protocolo se puede implementar en una variedad de diferentes sistemas operativos, incluidos  AUTOSAR, OSEK y GENIVI . También se puede implementar en firmware incorporado que no ejecuta un sistema operativo.

Los dispositivos grandes como cámaras, hosts, dispositivos telemáticos, dispositivos AUTOSAR e incluso sistemas de información y entretenimiento pueden intercambiar mensajes entre ECU de manera eficiente utilizando el protocolo SOME/IP. El soporte de SOME/IP ha sido público desde  el lanzamiento de Wireshark 3.2  SOME/IP, lo que permite el análisis de datos de SOME/IP en Wireshark.

En resumen, podemos resumir las características básicas de SOME/IP como un protocolo de comunicación orientado a servicios, un protocolo de capa de aplicación basado en la pila de protocolos Ethernet del vehículo, como se muestra a continuación en la Tabla 1. Cinco características básicas del protocolo IP:

Tabla 1 Cinco características básicas del protocolo SOME/IP

Relación entre SOME/IP y SOA

SOA

En resumen, SOA es una arquitectura orientada a servicios ( Service-Oriented Architecture ), y por supuesto también es una forma importante de diseño de software.Fue propuesta por Gartner, una empresa de investigación y consultoría de TI, en 1996. No es una nuevo concepto en sí mismo, y ha sido popular en el campo de Internet de TI durante más de 20 años.

De acuerdo con la definición de W3C: "SOA es una arquitectura de aplicación en la que todas las funciones se definen como servicios independientes con interfaces de llamada bien definidas que se pueden llamar en un orden definido. servicios para formar procesos comerciales.

Servicio:  un servicio es una colección de información que es más granular que un componente. En realidad, contiene una combinación lógica que implementa múltiples requisitos comerciales asociados y permite que cada servicio use una plataforma, arquitectura o solución técnica específica;

Interfaz llamable:  La interfaz orientada a servicios es diferente a la interfaz del componente, su implementación no tiene nada que ver con un lenguaje específico o una plataforma específica, y es muy conveniente para realizar la interacción de diferentes plataformas heterogéneas;

Contacto y diferencia:

• En primer lugar, debe quedar claro que ALGUNA/IP no es SOA, y SOA no es ALGUNA/IP;
• Dado que SOME/IP también es un protocolo orientado a servicios, generalmente se cree que SOME/IP es solo una opción de protocolo factible para SOA;
• En términos generales, tanto la comunicación basada en mensajes como la comunicación RPC (llamada a procedimiento remoto) pueden realizar SOA, y SOME/IP es un protocolo basado en el marco RPC;
• Puede usarse para realizar SOA a través de SOME/IP, pero la realización de SOA no necesariamente tiene que usar SOME/IP;

ALGUNOS/Análisis de protocolo IP

A continuación, deja que mango lleve a todos a descubrir el misterio de SOME/IP analizando SOME/IP juntos. , a fin de sentar una base sólida para el posterior aprendizaje de Ethernet automotriz.

Identificadores relacionados y notas de la versión

La figura 2 a continuación muestra la estructura de encabezado del protocolo SOME/IP:

Figura 2 Encabezado de protocolo SOME/IP

La explicación detallada de la ID del mensaje, la ID de la solicitud, la versión del protocolo y la versión de la interfaz marcadas en la figura anterior se muestra en la Tabla 2 a continuación:

Tabla 2 Identificadores relacionados y notas de versión

Longitud

La longitud, como se muestra en la Figura 2 anterior, cubre el rango desde el comienzo de la ID de solicitud hasta el final del mensaje SOME/IP.

Tipo de mensaje

Se utiliza para identificar diferentes tipos de mensajes, los tipos existentes actualmente se muestran en la Figura 3 a continuación, donde TP representa un mensaje subcontratado, el cual se define de la siguiente manera según el estándar AUTOSAR (R21-11 ) :

Figura 3 Tabla de tipos de mensajes

Código de retorno

El código de retorno se utiliza para indicar si el mensaje se procesó correctamente o para proporcionar información sobre el contenido del error en la solicitud. La figura 4 a continuación muestra el tipo de código de retorno definido en AUTOSAR ( R21-11 ):

Figura 4 Tabla de definición de código de retorno

Mecanismo de comunicación SOME/IP

Después de comprender la definición detallada del estándar de protocolo SOME/IP, es necesario discutir qué reglas debe seguir la ECU del vehículo para lograr la transmisión de datos. Por lo tanto, la familiarización con esta parte del contenido será esencial para el desarrollo y prueba del vehículo Ethernet SOME/IP importante.

Descubrimiento de servicios

El mecanismo de comunicación de descubrimiento de servicios se realiza a través del protocolo SOME/IP-SD, principalmente para informar al cliente de la disponibilidad y método de acceso de la instancia de servicio actual en el vehículo Ethernet, lo que se puede realizar a través de Find Service y Offer Service.

Antes de transmitir datos a través del protocolo SOME/IP, necesitamos saber qué servicios existen en la red de vehículos completa actual, qué tan disponibles están los servicios y si el cliente se suscribe a los servicios proporcionados por el servidor.

Dado que el protocolo SOME/IP-SD también es una parte muy importante, no se ampliará aquí, pero se presentarán brevemente sus funciones y mecanismos básicos. El contenido específico del protocolo SOME/IP-SD se presentará por separado más adelante. ¡así que estad atentos!

Como se muestra en la Figura 5 a continuación, es la función básica de SOME/IP-SD, que muestra la interacción entre el Cliente y el Servidor.

Figura 5 Diagrama de interacción entre SOME/IP-SD Client y Server

Como se puede ver en la figura anterior, el proceso de descubrimiento del servicio SOME/IP se puede dividir en los siguientes tres pasos básicos:

• El cliente busca instancias de servicio disponibles en la red de vehículos mediante el envío de un mensaje Find Service;
• El servidor envía la respuesta del servicio de oferta a través de UDP después de recibir el servidor de búsqueda del cliente;
• El cliente suscribe Eventos relacionados enviando Suscribir grupo de eventos;
• El servidor verifica si el cliente cumple con las condiciones de suscripción y, si las cumple, responderá ACK, si no, responderá NACK;
• Después de que el Cliente se suscriba con éxito al evento relevante, el Servidor publicará el Cliente que se ha suscrito al evento de acuerdo con los atributos del evento mismo;

Llamada a procedimiento remoto (RPC)

Las llamadas a procedimientos remotos se pueden dividir principalmente en cuatro modos de comunicación:

• El modo de comunicación Solicitud/Respuesta se puede resumir como uno de los Métodos ; su modelo de comunicación básico se muestra en la Figura 6 a continuación:

  El modelo de Solicitud-Respuesta es uno de los métodos de comunicación más comunes, su tarea principal es que el cliente envía la información de la solicitud y el servidor recibe la solicitud, realiza el procesamiento correspondiente y luego responde en consecuencia.

Figura 6 Modelo de comunicación Solicitud-Respuesta

• El modo de comunicación Fire&Forget se puede resumir como uno de Método ;

  La tarea principal de este modelo de comunicación es que el cliente envía una solicitud al servidor y el servidor no necesita dar ninguna respuesta, lo que es similar a la respuesta positiva de supresión en el servicio de diagnóstico.

Figura 7 Modelo de comunicación Fire&Forget

• Modo de comunicación de evento de notificación ;

  Este modo de comunicación describe principalmente el contenido del mensaje de publicación/suscripción. La tarea principal es permitir que el cliente se suscriba al grupo de eventos relevante en el servidor. Publicar contenido actualizado.

Figura 8 Modelo de comunicación de eventos de notificación

• Control remoto de procesos (Campo)

  El mecanismo de comunicación del proceso de acceso es principalmente para lograr la adquisición y modificación de datos para la aplicación. La tarea principal es permitir que el cliente obtenga el valor del Servidor a través del Getter y establezca el valor del Servidor a través del Setter.

  El campo puede entenderse como el atributo básico de un Servicio, que puede incluir Getter, Setter y Notifier de tres maneras. Entre ellos, Getter es un método para leer un valor en Field, Setter es un método para cambiar el valor de Field y Notifier es un evento desencadenante cuando cambia el valor en Field.

  

  Figura 9 Modelo de comunicación de Field

Como se puede ver en la figura anterior, usamos el mecanismo de Solicitud/Respuesta a la manera de Getter y Setter. En el mensaje de solicitud Getter hay una carga útil vacía, la carga útil en el mensaje de respuesta es el valor que se obtendrá; al usar la solicitud Setter, la carga útil en el mensaje de solicitud es el valor que se establecerá, si la configuración es exitosa, entonces el mensaje de respuesta En este artículo, Carga útil es el valor para establecer el éxito.

Al mismo tiempo, también podemos concluir que la entidad de servicio es un concepto muy importante en el protocolo SOME/IP. Una entidad de servicio puede ser cualquier combinación de Campo, Eventos y Método .

SOME/mecanismo de manejo de errores de IP

Siempre hay varios errores en cualquier proceso de comunicación, y SOME/IP no es una excepción como un protocolo de aplicación orientado a servicios, por lo tanto, para localizar los problemas en el proceso de comunicación de manera más eficiente, AUTOSAR ha formulado un mecanismo de manejo de errores para verificar la contenido del formato de protocolo SOME/IP.

Por ejemplo, verificación de información de versión, ID de servicio, etc. Se puede definir otra información de falla en Carga útil en detalle. Actualmente, SOME/IP admite los siguientes dos mecanismos de manejo de errores, que se pueden seleccionar según la configuración.

• Tipo de mensaje 0x80, Información de respuesta, es decir, el problema se puede ubicar a través del Código de retorno en el Mensaje de respuesta;
• Tipo de mensaje 0x81, mensaje de error explícito;

La Figura 10 a continuación muestra el flujo básico de SOME/IP que maneja errores generales:

Figura 10 Proceso de manejo de errores SOME/IP

Si desea obtener más información sobre cómo implementar el contenido de la pila de protocolos SOME/IP, puede consultar el código fuente abierto en GitHub liderado por BMW y buscar la palabra clave " vsomeip " en GitHub para encontrar el código fuente abierto correspondiente. código para aprender .

Vale la pena señalar que vsomeip es una pila de protocolos SOME/IP desarrollada con lenguaje C++ basada en la plataforma Linux.