Este artículo es el segundo de una serie de divulgación científica sobre middleware de conducción autónoma. El artículo anterior trataba sobre el middleware de conducción autónoma: ¿Se está "marginando" a AUTOSAR?
Con el creciente número de sensores, más y más fuentes de datos y escalas más grandes, ¿cómo se pueden transmitir de manera eficiente y estable estos datos heterogéneos de múltiples fuentes entre chips y entre diversos procesos de tareas? ¿Qué pasa con garantizar que "los datos correctos se entreguen en el momento adecuado y que los datos lleguen al lugar adecuado"?
¿Qué información se compartirá entre los módulos? ¿Cómo enviar esta información codificada en el mensaje? ¿Cómo pasar mensajes de un módulo a otro módulo? ¿Cómo decodificar el mensaje después de recibirlo? ¿Cuánto tiempo se tarda en comunicarse entre cada módulo?
¿Cómo no se puede interrumpir el proceso durante la OTA?
Estos problemas deben resolverse mediante "middleware de comunicación".
En el campo de la conducción autónoma, las funciones del middleware implican comunicación, actualización de módulos, programación de tareas y gestión de ejecución, pero su función más importante es la comunicación. En el mercado actual, ya sea Cyber RT o ROS, básicamente el 90% de las funciones son comunicación, en sentido estricto son middleware de comunicación (también conocido como "middleware de mensajes").
Entonces, ¿qué características debe tener un buen middleware de comunicación? ¿En qué tipos de middleware de comunicación se pueden dividir? ¿Cuáles son las ventajas y desventajas comunes de SOME/IP y DDS? ¿Cómo evolucionará el panorama del mercado? A continuación, analizaremos brevemente estos contenidos.
uno. ¿Qué tipo de middleware de comunicación se necesita para la conducción autónoma?
En la comunicación de red tradicional, bajo el protocolo TCP, después de enviar la información, el receptor necesita enviar una señal para decirle al remitente "lo recibí". Si no se recibe la señal, no se puede enviar el siguiente mensaje; en la transmisión UDP modo, independientemente de si el receptor lo recibe o no, el remitente seguirá enviándolo.
En el pasado, cuando no se utilizaba middleware de comunicación, para desarrollar aplicaciones de capa superior, los desarrolladores tenían que definir ellos mismos el formato de los datos, el remitente y el receptor de los datos; Modelo de publicación y suscripción "centrado en datos", los desarrolladores solo necesitan saber qué tipo de datos necesito y dónde enviarlos, sin saber quién y cómo se envían los datos.
El centrado en los datos es diferente del tradicional "centrado en los mensajes", la diferencia esencial es que el middleware de comunicación sabe qué datos almacena y puede controlar cómo compartirlos.
Con el middleware tradicional centrado en mensajes, los programadores deben escribir código para enviar mensajes, mientras que con el middleware centrado en datos, los programadores solo necesitan escribir código sobre cómo y cuándo compartir datos, y luego compartir el valor de los datos directamente.
El middleware de comunicación incluye tres modos de trabajo: punto a punto, cola de mensajes y publicación/suscripción. Tanto SOME/IP como DDS adoptan el modo de publicación/suscripción.
El modo punto a punto tiene un fuerte acoplamiento de tiempo y espacio, lo que limita en gran medida la flexibilidad de la comunicación; el modo de cola de mensajes transmite mensajes a través de una cola de mensajes, lo que resuelve el problema del acoplamiento flojo de tiempo y espacio entre las partes que se comunican, pero no puede implementar mensajes. La comunicación del consumidor es asincrónica, y también hay cuellos de botella en el servidor y fallas de un solo punto, y no se puede garantizar la confiabilidad; en el modelo de publicación / suscripción, los editores y suscriptores están relacionados a través de temas, y ambas partes no necesitan saber dónde la otra parte no necesita estar en línea al mismo tiempo, logrando un acoplamiento flexible multidimensional de las partes de la comunicación en el tiempo, el espacio y la comunicación de datos.
Además, en comparación con CAN orientado a señales, DDS y SOME/IP son protocolos de comunicación orientados a servicios. La diferencia entre las dos es: la transmisión de datos orientada a señales siempre se enviará en un bucle independientemente de si la red lo necesita o no; mientras que la comunicación orientada a servicios es diferente, solo se enviará al cliente cuando el cliente lo solicite o el servidor notifica a un suscriptor específico. Los datos se intercambian en una configuración de servidor final, lo que garantiza que nunca se desperdicie el ancho de banda y que los datos se comuniquen/intercambien solo cuando y donde se necesiten.
Por lo tanto, los protocolos de comunicación orientados a servicios pueden reducir en gran medida la carga de la red y mejorar la eficiencia de la comunicación.
El ingeniero de SAIC, Yin Wei, dijo en un artículo que la introducción del middleware de comunicación puede ayudar a los desarrolladores a mejorar la eficiencia del trabajo en su conjunto.
Tanto SOME/IP como DDS han sido incluidos en los estándares de plataforma de AUTOSAR AP.
Chuangjing Information Technology dijo en un artículo en su cuenta pública oficial de WeChat: "Dejando de lado los intereses comerciales, desde una perspectiva de ingeniería, la mayor ventaja de combinar AUTOSAR y DDS es que los dominios funcionales y la topología de red ya no son rivales, sino aliados en el vehículo. La topología de la red es más capaz de adaptarse a las limitaciones físicas del vehículo, mientras que los dominios funcionales proporcionan una superposición flexible sobre el vehículo físico".
El middleware de comunicación debe incluir los siguientes módulos: lenguaje de especificación de tipo de datos, sistema de mensajería, herramientas de registro/reproducción y herramientas de análisis en tiempo real. Estos módulos deberán tener las siguientes características:
1. El lenguaje de especificación del tipo de datos debe ser independiente de la plataforma y del lenguaje de programación específico para eliminar la necesidad de que los usuarios implementen código de clasificación (Marshalling) y al mismo tiempo garantizar la seguridad del tipo de tiempo de ejecución;
2. Los sistemas de mensajería deben transmitir mensajes entre diferentes procesos y proporcionar capacidades de mensajería de baja latencia y eliminar la dependencia de las comunicaciones centrales, facilitando el trabajo con fuentes mixtas de simulación, grabación y datos en tiempo real;
3. Es necesario proporcionar una gran cantidad de herramientas de registro, reproducción e inspección de tráfico para simplificar las tareas comunes de desarrollo y depuración.
Los principales criterios para medir la calidad de un middleware de comunicación son los siguientes:
1. ¿Es conveniente la interfaz? La conveniencia de la interfaz es la razón por la que a muchas personas les gusta usar ros.
2. ¿Es seguro y estable? La seguridad significa que la pérdida de datos no puede ocurrir durante el proceso de comunicación; la estabilidad significa que el proceso de publicación y suscripción no puede interrumpirse incluso si se ejecuta durante varios días y noches.
3. ¿Cuántos nodos y en cuántos núcleos puede admitir la transmisión?
4. ¿Es posible configurar de forma flexible y rápida en diferentes escenarios y requisitos de comunicación?
5. Rendimiento y latencia. Al enviar paquetes del mismo tamaño, ¿el rendimiento es mayor y la latencia menor que con otros métodos?
El rendimiento se refiere a la cantidad de datos que pasan por unidad de tiempo; la latencia se refiere al retraso en la transmisión de paquetes de datos. Si la velocidad de comunicación es muy lenta y la información percibida tarda 200 milisegundos en transmitirse al sistema de ejecución, entonces será inútil por muy buena que sea la percepción.
En escenarios donde la velocidad del vehículo es mayor y la cantidad de datos es mayor, los requisitos para la capacidad de rendimiento de datos y la latencia del middleware son mayores. Un fabricante de middleware de comunicaciones informó que sus productos se vendieron muy bien en el mercado de automóviles de pasajeros, pero no respondieron bien en el mercado de vehículos comerciales. Una razón es que los escenarios de conducción de los vehículos comerciales son simples y las capacidades de procesamiento de datos y la latencia del El middleware se ve afectado y los requisitos son relativamente bajos.
dos. Middleware de comunicación común
Dependiendo de si el código fuente es abierto o no, el middleware de comunicación se puede dividir simplemente en código cerrado y código abierto. El middleware de comunicación de código cerrado incluye principalmente SOME/IP de Vector, DDS de RTI, etc., el middleware de comunicación de código abierto incluye principalmente OPEN DDS, FAST DDS, Cyclone DDS, etc.
A continuación, daremos una breve introducción a estos tipos de middleware de comunicación.
01
ALGUNOS/IP
El nombre completo de SOME/IP es: Middleware escalable orientado a servicios sobre IP, que es un protocolo de transmisión orientado a servicios. En sentido estricto, SOME/IP no es un producto específico, sino un estándar técnico. Fue desarrollado por primera vez por BMW en 2012-2013 y se integró en AUTOSAR 4.2.1 en 2014.
Actualmente, el mayor proveedor mundial de productos comerciales SOME/IP es Vector. La versión de código abierto de SOME/IP es mantenida por la Asociación Genivi.
02
DDS (Servicio de distribución de datos)
Cuando mencionas DDS, debes mencionar la organización OMG. OMG es una asociación internacional de estándares de la industria informática, abierta y sin fines de lucro. Muchos estándares familiares (como UML) provienen de OMG. DDS es también uno de los estándares lanzados por la organización OMG.
(La imagen proviene de Chuangjing Information Technology Company)
El nombre completo de DDS es Servicio de distribución de datos (Servicio de distribución de datos), es una especificación de comunicación distribuida publicada por OMG, que adopta un modelo de publicación / suscripción y proporciona una variedad de estrategias de calidad de servicio QoS para garantizar tiempo real, eficiencia y flexibilidad. distribución de datos Varios requisitos de aplicaciones de comunicación distribuida en tiempo real.
DDS define los datos transmitidos en la red distribuida como un "tema" y define los objetos que generan y reciben datos como "editor" y "suscriptor" respectivamente, formando así un modelo de transmisión de publicación/suscripción de datos. No existe una relación lógica maestro-esclavo entre cada nodo. Existe una relación de igual a igual entre los puntos. El método de comunicación puede ser punto a punto, punto a muchos, muchos a muchos, etc. La conexión se establece bajo el control de QoS y los parámetros de red se descubren y configuran automáticamente.
DDS se utilizó por primera vez en la Marina de los EE. UU. para resolver los problemas de compatibilidad de una gran cantidad de actualizaciones de software en el complejo entorno de red de los barcos, y luego se expandió a la aviación, el sector aeroespacial, la construcción naval, la defensa nacional, las finanzas, las comunicaciones, los automóviles y otros campos. , incluidos sistemas de combate, sistemas de control y navegación de buques, sistemas de defensa de buques, sistemas de conducción de vehículos aéreos no tripulados y sistemas de control terrestre, sistemas de control de vehículos blindados, sistemas de simulación y entrenamiento, sistemas de procesamiento de radar y gestión del tráfico aéreo, sistemas financieros, etc.
En 2018, DDS se introdujo por primera vez en AUTOSAR AP como uno de los métodos de comunicación opcionales. En marzo de 2018, RTI Corporation, el principal proveedor de DDS, anunció que la última versión de AUTOSAR AP (versión 18-03) ya tiene una vinculación de red completa del estándar DDS.
Tanto ROS 2 como Cyber RT utilizan DDS de código abierto en la capa inferior, utilizando DDS como el mecanismo de comunicación más importante. En consecuencia, las interfaces DDS también están reservadas en chips SOC para conducción autónoma como Xaver y Orin.
La especificación estándar de AUTOSAR CP no admite DDS, pero después de realizar algunas modificaciones, DDS también se puede integrar en el CP.
A nivel mundial, el proveedor con la mayor cuota de mercado de DDS (alrededor del 80%) es la empresa estadounidense RTI (nombre completo Real-Time Innovations), fundada en 1991. RTI, como miembro de la junta directiva de la organización OMG, lideró la formulación del estándar DDS y desde 2004 es responsable de albergar el trabajo del grupo de trabajo DDS y ahora se ha convertido en un líder en esta industria. y tiene autoridad suficiente para el estándar DDS.
El DDS desarrollado por RTI tiene la marca Connext, por lo que también se llama Connext DDS.
03
DDS de código abierto: FAST DDS y OPEN DDS
El DDS de código abierto se compara principalmente con el RTI Connext DDS comercial, etc. También se desarrolla de acuerdo con los estándares oficiales de OMG, pero el código fuente es abierto.
El DDS de código abierto más influyente en el campo de la conducción autónoma es FastDDS lanzado por eProsima, una empresa fundada en Europa por antiguos miembros del equipo central de RTI. Después de que eProsima abre el código fuente de FastDDS, los usuarios pueden descargarlo directamente en github de forma gratuita. Sin embargo, FastDDS es más problemático de usar: en este momento, los usuarios deben pagar a eProsima para obtener soporte.
OpenDDS fue desarrollado por el equipo ACE/TAO de Object Computing en St. Louis y Phoenix y tiene ciertas similitudes con FastDDS: ambos se basan en RTPS, un marco de comunicación orientado a datos, y siguen el mismo estándar. Las características típicas de este tipo de marco son la descentralización, el soporte para mecanismos de QoS y el soporte para comunicación en tiempo real. Por lo general, se vinculan herramientas de serialización como protobuf.
En muchos casos, FastDDS y OpenDDS pueden interoperar/comunicarse con Connnext DDS de RTI. Por supuesto, depende de la escena. Por ejemplo, el DDS de código abierto tiene 23 QoS (políticas de servicio). Si todos usan estos 23 QOS para interactuar, pueden interoperar; si Connext usa QoS que excede estos 23 rangos personalizados, entonces el DDS de código abierto no puede analizarlo. Además, si utiliza herramientas DDS que no son de código abierto por OMG, no serán interoperables.
El responsable de un fabricante de middleware en China presentó que, debido a consideraciones de costo, OpenDDS como FastDDS u OpenDDS se utilizan en Driver.OS de Xavier de Nvidia.
RTI cree que el DDS de código abierto es su mayor competidor.
Por supuesto, el umbral para utilizar DDS de código abierto también es muy alto. Por ejemplo, RTI DDS tiene más de 50 políticas de servicio, pero el DDS de código abierto tiene solo 23 políticas de servicio, lo que es mucho menos completo que el primero. Además, el DDS de RTI ha pasado la certificación ASIL-D, pero el DDS de código abierto no.
Según Bi Xiaopeng, cofundador de Huayutongsoft, el middleware de comunicación desarrollado sobre la base de la versión de código abierto de DDS tiene el problema de una "estabilidad insuficiente".
04
MQTT (código abierto)
MQTT es un protocolo de mensajería instantánea desarrollado por IBM, su nombre completo es Message Queuing Telemetry Transport. El protocolo MQTT también adopta el modo de publicación/suscripción. Todos los terminales IoT están conectados a la nube a través de TCP. La nube gestiona el contenido de comunicación de cada dispositivo a través de temas y es responsable de reenviar mensajes entre dispositivos.
Debido al control de retraso deficiente y otras funciones y menos estrategias de servicio, MQTT no es adecuado para proyectos de alta velocidad y proyectos a gran escala, pero puede usarse en escenarios de red poco confiables y de bajo ancho de banda para proporcionar transmisión de datos y monitoreo de dispositivos remotos. basado en plataformas en la nube. . En el campo de la conducción autónoma, un escenario de aplicación típico de MQTT es V2X.
Además, MQTT también es aplicable en el ámbito de los vehículos de baja velocidad. Es extremadamente pequeño y puede proporcionar garantías de QoS simples, muy adecuado para proyectos con funciones simples y recursos de hardware limitados, como autos de juguete y barredoras.
MQTT también es un middleware de comunicación de código abierto.
三．ALGUNOS/IP & DDS
En esta etapa, SOME/IP y DDS son los dos tipos de middleware de comunicación más utilizados en la conducción autónoma. Como se mencionó anteriormente, los principales puntos comunes entre los dos son: ambos son protocolos de comunicación orientados a servicios; ambos adoptan un modelo de publicación y suscripción "centrado en datos". Entonces, ¿cuáles son las principales diferencias entre los dos?
01
Diferentes escenarios de aplicación
SOME/IP está especialmente diseñado para el campo automotriz, define un conjunto de estándares de comunicación para las necesidades del campo automotriz y ha estado profundamente involucrado en el campo automotriz durante mucho tiempo, DDS es un fuerte sistema de comunicación en tiempo real a nivel industrial. Estándar Tiene una gran adaptabilidad a las escenas, pero requiere una adaptación especial cuando se utiliza en el campo de la conducción automotriz/autónoma.
02
Diferente flexibilidad, escalabilidad.
En comparación con SOME/IP, DDS introduce una gran cantidad de características integradas estándar, como filtrado basado en contenido y tiempo, confiabilidad independiente del transporte, persistencia, capacidad de supervivencia, monitoreo de demoras/fechas límite, tipos extensibles, etc. Cuando AUTOSAR AP trabaja con DDS para construir un marco de comunicación, el marco no solo es compatible con las API y aplicaciones ara::com existentes, sino que también proporciona importantes beneficios de confiabilidad, rendimiento, flexibilidad y escalabilidad.
03
Si el suscriptor y el editor están fuertemente acoplados
En SOME/IP, antes de la transmisión normal de datos, el cliente necesita establecer una conexión de red con el servidor y preguntarle al servidor si proporciona los servicios requeridos. En este nivel, todavía existe un cierto grado de acoplamiento entre nodos. El suscriptor del servicio necesita saber dónde está el servidor y el editor del servicio debe decirle al servidor qué tipo de servicio proporciona. Por ejemplo, si escribe un programa que necesita utilizar datos de sensores, este programa debe Pregunte al servidor si puede proporcionar datos de sensores; según el estándar DDS, cada suscriptor o editor solo necesita suscribirse o publicar datos de sensores en su propio programa, y no necesita preocuparse por ninguna conexión. Se puede entender que en DDS, el suscriptor del servicio y el editor están más completamente desacoplados. Si necesita algún dato, simplemente escriba una línea de código y no es necesario vincularlo.
04
Diferentes estrategias de servicio.
Una mejor QoS (política de servicio) es la característica más importante del estándar DDS en comparación con SOME/IP.
SOME/IP tiene solo una QoS, que es la definición de confiabilidad, mientras que RTI DDS y DDS de código abierto tienen más de 50 y más de 20 QoS respectivamente, que básicamente pueden cubrir la mayoría de los escenarios de conducción inteligente previsibles.
¿Qué es QoS específicamente y cuál es su propósito? Bi Xiaopeng, cofundador y vicepresidente de tecnología de Huayutongsoft, dio varios ejemplos:
(1) La prioridad de transmisión, la confiabilidad de los datos, las restricciones de recursos, el filtrado de tiempo, etc. en la comunicación deben configurarse en QoS.
(2) Puede producirse una pérdida de tramas durante la transmisión de datos, es decir, no todas las tramas pueden llegar al extremo receptor. Para abordar este fenómeno, debemos considerar los requisitos de la escena. Si se trata de información crítica (comando de alarma), necesitamos que el remitente la reenvíe. Si se trata de información no crítica (datos de sensores de alta frecuencia), el sistema no tiene que recuperar todas las piezas perdidas. Todo lo que se requiere es configurar la confiabilidad de QoS.
(3) En el caso de redundancia en el sistema de detección, una vez que un sensor deja de funcionar, se necesita un segundo sensor para tomar el control. En respuesta a esta situación, QoS puede configurar una propiedad para priorizar los datos de los dos sensores. No es necesario volver a compilar después de la configuración, porque se implementa dinámicamente. Después de la configuración, se puede ejecutar de acuerdo con la última configuración para completar la publicación y suscripción entre diferentes nodos.
(4) El modo de desacoplamiento de DDS permite que un editor de temas aún publique datos sin suscriptores, pero los suscriptores que se unan más tarde pueden estar interesados en los registros históricos de este tema. Por ejemplo, después de que un nuevo nodo se conecta, necesita monitorear el funcionamiento de otros nodos. Estos nodos pueden emitir un mensaje diciendo que están "funcionando normalmente" cada largo período de tiempo. Luego, el nuevo nodo en línea debe comprender la liberación. historial de otros nodos Información para determinar su estado de ejecución, es decir, espera recibir datos históricos publicados por otros nodos antes de conectarse. Esta situación se puede lograr simplemente configurando QoS: el nuevo nodo puede saber cuánto tiempo y cuánto duró el flujo de datos del nodo antes de conectarse, y prestar atención a sus datos históricos, etc.
(5) Una vez que el nuevo nodo responsable del monitoreo se conecta, es necesario monitorear el funcionamiento de otros nodos. Por lo general, estos nodos publican un mensaje cada hora diciendo que están "funcionando normalmente", pero también es posible que el nodo "funcionando normalmente" lo publique primero y el nodo de monitoreo lo publique media hora después. ¿El nodo de monitoreo aún recibe el mensaje? ¿Los datos publicados por otros nodos antes de conectarse? Esta situación también debe configurarse a través de QoS. QoS puede configurar cuánto tiempo y cuánto tiempo durará el flujo de datos del nodo antes de que el nuevo nodo entre en línea, preste atención a sus datos históricos, etc.
Además, QoS puede proporcionar el rendimiento, la previsibilidad y la controlabilidad de recursos que requieren los sistemas en tiempo real, y puede garantizar la modularidad, escalabilidad y solidez del modelo de publicación/suscripción. Por lo tanto, DDS puede cumplir requisitos de flujo de datos muy complejos y flexibles.
Por el contrario, SOME/IP solo resuelve el problema de publicación-suscripción, pero debido a que no existe tal QoS, el resultado es que muchas funciones que se pueden realizar mediante la configuración automática de políticas de servicio deben ser realizadas por los desarrolladores de software que escriben código, lo que provocará Pierde mucho tiempo.
Además, debido a que no hay QoS, SOME/IP no puede resolver el problema de la pérdida de paquetes cuando la cantidad de datos es grande, lo que hace que los comandos se queden atascados en algún lugar y no se puedan enviar, y entonces todo el sistema no puede funcionar normalmente.
05
Diferentes escenarios de aplicación
Desde la perspectiva de los escenarios de aplicación, SOME/IP está más sesgado hacia las redes de vehículos y solo se puede utilizar en entornos de red basados en capas de red de tipo IP, mientras que DDS no tiene restricciones especiales en los métodos de transmisión y no es adecuado para no IP. entornos de red basados. Se pueden admitir redes como memoria compartida, comunicación entre núcleos, PCI-e y otros tipos de redes. Además, DDS también cuenta con una solución completa de Internet de vehículos. Sus exclusivas funciones DDS Security y DDS Web pueden proporcionar a los usuarios una solución integral para automóvil, nube y móvil.
En la implementación comercial, DDS y SOME/IP compiten directamente. Según un representante de RIT, para los usuarios, DDS y SOME/IP son una "elección entre dos".
Sin embargo, Bi Xiaopeng, el gerente general de marketing de Neusoft Ruichi, Mao Haiyan, y el arquitecto jefe de Junlian Zhixing, Wang Haowei, creen que aunque DDS y SOME/IP tienen una fuerte relación competitiva, también pueden coexistir.
Bi Xiaopeng dijo que algunos OEM usan tanto DDS como SOME/IP, pero los escenarios utilizados son diferentes: a veces comunicación entre procesos en un núcleo y, a veces, comunicación entre núcleos, a veces el controlador de dominio se comunica con otros sistemas de entretenimiento del automóvil, etc. "Ahora ya no es necesario 'elegir uno del otro'. También es posible elegir DDS para algunos escenarios y SOME/IP para otros escenarios".
Mao Haiyan dijo que en AP AUTOSAR, algunos marcos estándar proporcionados por CM son compatibles tanto con DDS como con SOME/IP. "Hemos utilizado tanto SOME/IP como DDS. En términos generales, SOME/IP enfatiza la comunicación y es de tamaño relativamente pequeño; DDS tiene más funciones, pero es de tamaño relativamente grande y debe adaptarse antes de poder usarse para la conducción autónoma. ".
Wang Haowei señaló que DDS es adecuado para el ámbito de la conducción autónoma, mientras que SOME/IP se puede extender a todo el ámbito del vehículo.
Cai Shouqun, un experto en productos Vector, dijo: "DDS y SOME/IP se utilizan en algunos proyectos con los que hemos estado en contacto". Cai Shouqun incluso cree que DDS y SOME/IP no están en una relación competitiva. razonable y los usuarios pueden elegir según sus necesidades.
Entonces, en la práctica, ¿quién tiene una mayor cuota de mercado?
Bi Xiaopeng dijo: "Debido a que SOME/IP en sí es un estándar de comunicación formulado para la industria automotriz, la tasa de uso de SOME/IP será ligeramente mayor antes, y DDS solo ha sido adoptado gradualmente por muchos fabricantes y empresas de automóviles nuevos en el pasado. "Dos años. adoptado por los OEM. Pero a juzgar por la tendencia, en el futuro, la cuota de mercado de DDS será mayor que la de SOME/IP."
Por supuesto, "DDS es mejor que SOME/IP" es principalmente el argumento de los fabricantes de DDS. Para evitar que las opiniones de este artículo se vean influenciadas por las posiciones de los fabricantes, el autor pidió a Vector Cai Shouqun que confirmara estas dudas. En este sentido, la respuesta de Cai Shouqun es la siguiente——
"Muchas personas ahora dicen que DDS es mejor que SOME/IP, en gran medida desde la perspectiva de la riqueza de funciones. De hecho, DDS contiene más funciones que SOME/IP, pero se dice que DDS es mejor que SOME/IP sólo por esta razón . Es inapropiado para ALGUNOS/IP. Es como comparar un auto con un motor:
SOME/IP es el producto de AUTOSAR CP. El principio de diseño de AUTOSAR es modularizar las funciones y lograr la alta reutilización de los módulos mejorando la granularidad de los módulos, y luego mejorar los módulos mediante la reutilización y pruebas continuas. , SOME/IP no consideró agregar funciones continuamente cuando se produjo por primera vez. Por ejemplo, SD usado junto con SOME/IP es un módulo separado.
Por el contrario, la QoS adicional proporcionada por DDS se implementa en el controlador del controlador Ethernet basado en VLAN en AUTOSAR CP; los datos se almacenan en AUTOSAR con un módulo de gestión de almacenamiento separado; la seguridad también tiene la correspondiente seguridad de comunicación en AUTOSAR y el módulo de gestión de cifrado.
"Los fabricantes de DDS creen que, en comparación con SOME/IP, DDS tiene otras funciones disponibles además de proporcionar un protocolo de comunicación. Pero, de hecho, estas funciones las llevan a cabo otros módulos funcionales, ya sea en CP o AP. Además, la implementación se puede seleccionar en función en los requisitos del sistema. SOME/IP es sólo una parte de CP/AP.
"Por otro lado, las ricas funciones de DDS inevitablemente requerirán que ocupe más recursos. En el campo de las MCU automotrices, los recursos son un tema muy delicado. Para ejecutar DDS en la MCU (incluido el núcleo en tiempo real del SoC chip), solo puede La adaptación artificial de las funciones a nivel de proyecto dificulta la reutilización entre proyectos y plataformas, lo que dificulta lograr una productización madura; además, la adaptación de ingeniería durante la fase de desarrollo y las pruebas posteriores aumentará significativamente los costos del proyecto.
"Por supuesto, esta es solo la situación actual que veo personalmente. No sé si la versión comercial de DDS ya está considerando la modularización funcional y la capacidad de configuración de herramientas dentro de DDS para compensar esta deficiencia". (Jiuzhang Zhijia en Los comentarios obtenidos del agente de RTI, Chuangjing Technology, para verificación es: a juzgar por nuestros proyectos actuales de producción en masa, muchos clientes han implementado DDS en múltiples generaciones de productos que contienen MCU. DDS es reutilizable. No hay ningún problema "inmaduro").
"Además, DDS todavía tiene el problema de que no se puede integrar perfectamente en la cadena de herramientas de prueba, desarrollo y diseño electrónico y eléctrico automotriz existente. Aunque ya hemos comenzado a respaldar DDS en diseño (PREEvision) y pruebas (CANoe), pero este trabajo apenas ha comenzado: las herramientas de ambas partes deben probarse y ajustarse continuamente, y una compatibilidad perfecta no será posible en el corto plazo.
"Desde el punto de vista del protocolo, DDS es un sistema de acceso orientado a datos, adecuado para escenarios de aplicaciones de interacción de big data con múltiples nodos; SOME/IP es un sistema de acceso orientado a servicios, que se puede utilizar fácilmente para RPC (procedimiento remoto). Llamada) y notificaciones de cambios. Con respecto al rendimiento de datos, desde la perspectiva de la proporción de datos válidos, no existe una diferencia obvia en el rendimiento de DDS y SOME/IP.
"Por lo tanto, siempre pienso que DDS y SOME/IP coexistirán en la comunicación del vehículo, y la aplicación puede elegir el canal de comunicación apropiado según el escenario de la aplicación. Es por eso que tanto DDS como SOME/IP son compatibles con AUTOSAR AP.
"También sabemos que algunos OEM están considerando usar DDS como el único protocolo de comunicación de la red troncal (plataforma informática central + controlador de dominio azimutal), pero en términos de madurez, ocupación de recursos (debe haber nodos basados en MCU en la red troncal) y Desde la perspectiva de la cadena de herramientas, creemos que esto todavía está abierto a discusión".
Referencias:
Middleware de comunicación de conducción autónoma
https://blog.csdn.net/qq_23981335/article/details/106563676
SOME/IP de Ethernet automotriz de una sola vez (Parte 1)
https://mp.weixin.qq.com/s/kDDIvnijKo2tn07t20M4Cg
SOME/IP de Ethernet automotriz (Parte 2)
https://mp.weixin.qq.com/s/iMi1TVhhUK1xZbuOlSZUZw
Middleware DDS (Servicio de Distribución de Datos)
https://zhuanlan.zhihu.com/p/428892842
Diálogo con Huayu Tongsoft Bi Xiaopeng: Conducción inteligente en carreteras nacionales, algunas personas abren caminos cuando se encuentran con montañas y otras construyen puentes cuando se encuentran con agua | Huayu Wiki
https://mp.weixin.qq.com/s/IVZtiOwUOwqdiIv2_OztyA
Un artículo para entender el "middleware" de la conducción autónoma
https://zhuanlan.zhihu.com/p/372712318
Introducción a RTI DDS
https://blog.csdn.net/liulihuo_gyh/article/details/79704062
escribe al final
Comunicarse con el autor.
Si desea comunicarse directamente con el autor del artículo, puede escanear directamente el código QR a la derecha y agregar el WeChat del autor.
Nota: asegúrese de anotar su nombre real, empresa y puesto al agregar WeChat
Esperando la información, gracias!
Grupo de intercambio de sistema operativo
Si los profesionales en campos relacionados con sistemas operativos desean unirse a un grupo para comunicarse, puede escanear el código QR a la derecha para agregar un miembro del personal en WeChat y proporcionar su tarjeta de presentación, y luego se lo agregará al grupo.
Nota: asegúrese de anotar su nombre real, empresa y puesto al agregar WeChat
Esperando información, gracias.
Acerca de la presentación
Si está interesado en contribuir a "Nueve capítulos de conducción inteligente" (artículos tipo "acumulación y compilación de conocimientos"), escanee el código QR a la derecha y agregue el WeChat del personal.
Nota: asegúrese de anotar su nombre real, empresa y puesto al agregar WeChat
E información como la intención de envío, ¡gracias!
Requisitos de calidad para manuscritos en la categoría “Acumulación de conocimientos”:
R: La densidad de información es superior a la de la mayoría de los informes de la mayoría de las empresas de corretaje y no inferior al nivel medio de "Nueve capítulos de conducción inteligente";
B: La información debe ser muy escasa y más del 80% de la información debe no estar disponible en otros medios, y si se basa en información pública debe tener una perspectiva especialmente potente y excluyente. Gracias por su comprensión y apoyo.
Lectura recomendada:
◆ Uno de los middleware de conducción autónoma: ¿Se está "marginando" a AUTOSAR?
◆ Esta empresa sin conductor en realidad se posiciona como una “empresa de saneamiento ambiental”
◆ Esta empresa sin conductor en realidad inició un negocio de transporte de "conducción tripulada".
◆ ¿ Cuál es la “tecnología de motor” de lidar? Un artículo explica las barreras técnicas de la industria
◆ Dos puntos débiles de la prueba de simulación de conducción autónoma