En mayo del año pasado, Jiuzhang Zhijia publicó "La situación actual y la estructura del mercado de los sistemas operativos de conducción autónoma", que provocó una fuerte respuesta en la industria. Sin embargo, el objetivo de este artículo es hablar sobre el sistema operativo limitado, que es el "núcleo". ", y al "núcleo" como parte del sistema operativo amplio. "Middleware", pero no se escribe mucho al respecto. Entonces, ¿qué es exactamente el middleware y en qué categorías se incluye? ¿Cuál es el significado especial de cada categoría? ¿Quiénes son los principales actores del mercado actualmente?
Con estas preguntas en mente, "Nine Chapters Smart Driving" entrevistó a Bi Xiaopeng, cofundador de Huayu Tongsoft, Wang Haowei, ex arquitecto jefe de Thunderstar (ahora arquitecto jefe de Junlianzhixing), Neusoft Ruichi Director de línea comercial y ventas globales en Europa y América. el gerente general Mao Haiyan, el experto en productos Vector Cai Shouqun y muchos otros expertos en el campo de los sistemas operativos.
A continuación, combinaremos los resultados de esta serie de entrevistas para hacer una simple "ciencia popular" sobre la conducción autónoma a través de cuatro artículos: este es el primer artículo.
uno. La definición y el papel del middleware.
1. ¿Qué es el software intermedio?
La imagen está tomada de la cuenta pública "Volteretas en la nube y conducción autónoma".
Durante la comunicación, el autor descubrió que diferentes personas tienen diferentes conocimientos sobre el middleware, incluso se puede decir que este concepto sigue siendo vago hasta ahora. Por ejemplo:
(1) Algunas personas piensan que el middleware solo se refiere a la parte de los componentes ubicados encima del núcleo del sistema operativo y debajo del software funcional, que proporciona servicios como gestión de procesos y gestión de actualizaciones para la capa superior; mientras que algunas personas piensan que el middleware también debería incluir software funcional y la parte intermedia del software de aplicación (ver imagen arriba). Según Mao Haiyan, el primero es "middleware universal", mientras que el segundo es "middleware especializado". El "middleware" mencionado en este artículo se refiere específicamente al "middleware general", a menos que se especifique lo contrario.
(2) Algunas personas mencionaron middleware de conducción autónoma, incluido AUTOSAR (también dividido en AUTOSAR CP y AUTOSAR AP), y algunas personas mencionaron middleware, específicamente ROS2, Cyber RT, DDS, etc.
(3) Xiao Meng, vicepresidente de Weidong Technology, cree que el término "intermedio" es relativo. Cuando hay varias capas apiladas, cada capa es la capa intermedia de las dos capas superiores e inferiores. Por lo tanto, cuando se utiliza el término "middleware " Cuando utilizamos una palabra, debemos especificar específicamente "entre qué dos niveles se encuentra". Según Xiao Meng, cuando llamamos "ROS/ROS2 como middleware", su significado no es equivalente a "AUTOSAR AP como middleware".
(4) El experto en productos vectoriales, Cai Shoequn, dijo que el middleware que entiende "proporciona soporte funcional para el desarrollo de aplicaciones y no tiene representación funcional para el mundo exterior; pero desde la perspectiva del núcleo del sistema operativo, no existe una diferencia esencial entre el middleware y la aplicación". ."
2. El papel del middleware
Wang Haowei dijo: "El middleware especializado era originalmente parte de la aplicación, pero muchas empresas necesitan usarlo para la conducción autónoma, por lo que se eliminó".
Entonces, ¿para qué se utiliza exactamente?
Bi Xiaopeng cree que la función más importante del middleware de conducción autónoma es: en primer lugar, puede adaptarse a diferentes núcleos y arquitecturas del sistema operativo; en segundo lugar, puede proporcionar una interfaz estándar unificada que es responsable de la comunicación entre varios módulos de software de aplicación y la programación del sistema subyacente. recursos.
Según la explicación de Bi Xiaopeng, el primero elimina la necesidad de que los desarrolladores consideren cuál es el kernel del sistema operativo subyacente o cuál es el entorno de hardware, es decir, no solo logra el desacoplamiento del software de la aplicación y el sistema operativo, sino que también realiza el desacoplamiento de la aplicación. software y hardware; este último garantiza que los datos puedan transmitirse de forma segura y en tiempo real y que los recursos puedan programarse de forma razonable.
¿Por qué utilizar middleware para respaldar el desacoplamiento de software y hardware? Bi Xiaopeng explicó:
Desarrollo un software de aplicación, muchos de los cuales no tienen nada que ver con la lógica de la aplicación específica, incluida la comunicación de datos, la seguridad de la comunicación, la programación de recursos del sistema, etc. Se implementan y configuran por separado. En respuesta a esta situación, podemos abstraer la parte repetida en un servicio, sellarla en una capa de cosas (esto es middleware) y proporcionar una biblioteca, interfaz y método de configuración unificados para que la capa superior los llame. En este caso, algunas personas se especializan en middleware y quienes trabajan en aplicaciones de la capa superior no necesitan considerar la interacción con la capa inferior.
Por ejemplo, si desea crear un sistema de estacionamiento automático, tiene diferentes módulos o diferentes software con lógica de negocios independiente. Al comunicarse, interactuar con datos o llamar a recursos subyacentes, solo necesita una interfaz en el middleware para implementar otras cosas. No es necesario pensar en ello, para que los desarrolladores puedan centrarse en su lógica empresarial.
Por otro ejemplo, si una cámara necesita detectar líneas de carril, semáforos, etc., los desarrolladores se especializarán en algoritmos de detección de semáforos y líneas de carril. La interacción con datos externos solo requiere el uso de servicios de comunicación de middleware (como la suscripción a información de la cámara y publicación de resultados de detección), sin tener que preocuparse de dónde provienen los datos y a quién se envían.
El Dr. Miao Qiankun, director de la plataforma del sistema de nueva tecnología Nullmax, escribió en un artículo anterior:
" La potencia informática del chip ha aumentado significativamente, los píxeles de la cámara se han duplicado y el lidar aparece en más planes de automóviles nuevos... Nadie puede decir cuántos sensores debería haber en el automóvil o qué hardware se agregará a los automóviles futuros. Pero todos sabe que los cambios de hardware serán más dramáticos.
"Por lo tanto, también podemos ver que los automóviles tienen requisitos cada vez más altos en cuanto a arquitectura de software y hardware. No sólo deben satisfacer las necesidades actuales, sino también tener una considerable visión de futuro, compatibilidad y escalabilidad, y ser capaces de soportar actualizaciones posteriores de software y hardware. Necesidad de actualizar, agregar o quitar módulos. El middleware para la conducción autónoma es un invernadero moderno que se puede ajustar según sea necesario para satisfacer diversas necesidades.
"En las primeras etapas del desarrollo, el middleware se puede dividir en partes, descomponiendo un enorme proyecto de software en varias tareas pequeñas, y resolverlas de manera descentralizada. En aplicaciones posteriores, se puede dividir nuevamente en partes, como bloques de construcción, y se puede colocar una "Se unen según las necesidades. Los módulos se combinan formando un todo y encajan perfectamente".
En una transmisión en vivo antes del Festival de Primavera, An Zhipeng, director de ventas de productos de Neusoft Reach, dijo que después de desacoplar el software y el hardware y modularizar la administración, si vuelve a encontrar problemas, no necesita cambiar todo el sistema, solo cambie el partes correspondientes. . De esta manera, la reutilización del software mejora enormemente, al mismo tiempo que reduce considerablemente la carga de trabajo de verificación y mejora la eficiencia general del desarrollo.
Por el contrario, sin middleware, la capa de aplicación tiene que llamar directamente a la interfaz del sistema operativo. Si el sistema operativo se cambia más tarde, es posible que sea necesario anular el código y el algoritmo de la capa de aplicación.
En resumen, el middleware abstrae plataformas informáticas, sensores y otros recursos, adopta una gestión modular de algoritmos, subsistemas y funciones y proporciona interfaces unificadas, lo que permite a los desarrolladores centrarse en el desarrollo de sus respectivos niveles comerciales sin tener que comprender detalles irrelevantes.
Según An Zhipeng, director de ventas de productos de Neusoft Reach, el desarrollo de middleware como AUTSOAR no sólo beneficia a los fabricantes de equipos originales: "También se amplía la elección de proveedores de componentes: una vez que la aplicación está lista, se pueden adquirir el siguiente software y chips. Elegir varios proveedores es mucho más rápido que el modelo de desarrollo tradicional, por lo que los proveedores de repuestos también se benefician".
En palabras de Xiao Meng, el beneficio más directo del middleware es "proteger la complejidad de la capa subyacente de la capa superior". Los desarrolladores de software pueden ignorar las diferencias en hardware como chips y sensores, integrando así de manera eficiente y flexible las aplicaciones de la capa superior y Algoritmos funcionales en diferentes plataformas: implementar, iterar y trasplantar. Xiao Meng cree que el middleware puede considerarse una "nueva infraestructura" en el contexto de las aplicaciones de conducción autónoma.
(La imagen está tomada del artículo "¿Es AUTOSAR una bendición o una preocupación para el desarrollo de software básico?" escrito por el Dr. Feng Zhanjun. AUTOSAR es sólo un tipo de middleware, pero las "ventajas del desarrollo de AUTOSAR" escritas aquí básicamente también se aplican a otro middleware.)
Sin embargo, desde el punto de vista de un desarrollador, el significado de middleware puede no ser del todo positivo. Por ejemplo, el Dr. Feng Zhanjun escribió en "¿AutoSAR es bueno o malo para el desarrollo de software básico?" "El artículo menciona los dos puntos siguientes:
Los ingenieros de software de bajo nivel se han convertido en gente de herramientas: "Siempre que hagas clic con el ratón y utilices las herramientas para cooperar, será suficiente". Muchas pruebas que originalmente hacían ellos mismos también las realizan los proveedores, lo que a su vez provoca que La sensación de logro de los ingenieros se reducirá seriamente; con el tiempo, la capacidad de los ingenieros para desarrollarse de 0 a 1 también se reducirá.
(La imagen está tomada del artículo del Dr. Feng Zhanjun. Aunque el artículo habla de Autosar, de hecho, estos problemas también existen en el uso de otro middleware como ROS).
Para los ingenieros de software, el problema de la "degradación de la capacidad" causada por el middleware es casi irresoluble. Sin embargo, el Dr. Feng Zhanjun cree que "sería mejor si los ingenieros de la empresa usuaria estuvieran profundamente involucrados en el proceso de desarrollo de este middleware, plantearan requisitos y los implementaran juntos".
Además, Yin Wei mencionó en un artículo que los niveles 1 deberían ser muy reacios a utilizar middleware como AUTOSAR, "porque si no aumenta el costo, gradualmente puede convertirse en un fabricante de hardware". Pero no se puede decir que esto sea culpa del middleware: bajo la tendencia de los automóviles definidos por software, esto es casi inevitable.
dos. Conceptos básicos comunes
1. AUTOSAR CP 与 AUTOSAR AP
Entre todas las soluciones de middleware, la más famosa es AUTOSAR.
Estrictamente hablando, AUTOSAR no se refiere específicamente a un determinado sistema operativo o producto de middleware desarrollado por una determinada empresa de software, sino que está formulado conjuntamente por los principales fabricantes de automóviles, proveedores de repuestos, software, hardware y industrias electrónicas del mundo.Estándar de arquitectura de sistema abierto automotriz . Sin embargo, en la práctica, el middleware desarrollado por varias empresas basándose en el estándar AUTOSAR también se denomina "AUTOSAR".
Actualmente, AUTOSAR se puede dividir en dos plataformas: Plataforma Clásica y Plataforma Adaptativa, que se denominan AUTOSAR CP y AUTOSAR AP respectivamente.
En pocas palabras, AUTOSAR CP se ejecuta principalmente en MCU de 8, 16 y 32 bits, correspondientes al control tradicional de la carrocería, el control del chasis, el sistema de energía y otras funciones. Si se trata de conducción automática, es posible que AUTOSAR CP no pueda lograr; si bien AUTOSAR AP se ejecuta principalmente en MPU/SOC de alto rendimiento por encima de 64 bits, admite sistemas electrónicos de alto rendimiento para conducción autónoma.
Estrictamente hablando, AUTOSAR CP no es sólo un "middleware", es un "sistema operativo" completo equivalente a " OS kernel + middleware". AUTOSAR CP define la programación básica de tareas de la capa superior, la programación de prioridades, etc.
Entre las funciones ADAS basadas en arquitectura distribuida, AUOTSAR CP es el "sistema operativo" más común. Después de que se formó el ecosistema AUTOSAR, las MCU de muchos fabricantes de chips vinieron de serie con AUTOSAR CP, lo que dejó a los OEM con pocas opciones.
Dado que el chip bajo la arquitectura distribuida es principalmente MCU, hay un dicho que dice que "AUTOSAR CP se ejecuta principalmente en MCU".
En la arquitectura distribuida, diferentes funciones corresponden a diferentes MCU, y cada MCU necesita ejecutar un conjunto de AUTOSAR CP. Si hay muchos tipos de sensores, solo las funciones relacionadas con ADAS requieren muchos conjuntos de AUTOSAR CP, entonces, ¿cómo cargar un paño de lana? ?
El método convencional es: cargar según el tipo de MCU: si la MCU son dos MCU heterogéneas, entonces AUTOSAR CP se cargará como dos conjuntos; si la MCU es isomorfa, entonces AUTOSAR CP se cargará como un conjunto.
Con la evolución de la arquitectura EE de distribuida a centralizada y la evolución de los chips de MCU a SOC, la cantidad de cálculo y comunicación ha aumentado en un orden de magnitud. Además, la demanda de procesadores multinúcleo, GPU, FPGA, y los aceleradores dedicados, así como OTA, etc., están más allá del rango de soporte de AUTOSAR CP.
(Las fotografías fueron tomadas de la clase en vivo de An Zhipeng)
En 2017, para cumplir mejor con los requisitos de middleware de la conducción autónoma de alto nivel en la era de la arquitectura centralizada + SOC, la Alianza AUTOSAR lanzó la plataforma AUTOSAR AP con capacidades de comunicación más sólidas, una capacidad de configuración de software más flexible y mayores mecanismos de seguridad.
Cabe destacar que, a diferencia del propio AUTOSAR CP , que ya contiene un sistema operativo basado en el estándar OSEK , AUTOSAR A P es solo un middleware que se ejecuta en un sistema operativo basado en OSIX, como Lunix y QNX ; no contiene un sistema operativo en sí.
Combinado con "¿Por qué usar AP?" publicado por aFakeProgramer en CSDN en 2020. ¿Qué ofrece exactamente Adaptive AutoSAR a las empresas? 》 artículo y lo que dijo Neusoft Reichi An Zhipeng en una transmisión en vivo antes del Festival de Primavera de 2022, las principales diferencias entre AUTOSAR CP y AUTOSAR AP son las siguientes:
1) Diferentes lenguajes de programación: AUTOSAR CP se basa en el lenguaje C, mientras que AUTOSAR AP se basa en el lenguaje C ++;
2) Diferentes arquitecturas: AUTOSAR CP adopta la arquitectura FOA (arquitectura orientada a funciones), mientras que AUTOSAR AP adopta la arquitectura SOA (arquitectura orientada a servicios);
3) Diferentes métodos de comunicación: AUTOAR CP utiliza un método de comunicación de configuración estática basado en señales (LIN\CAN... matriz de comunicación), mientras que AUTOSAR AP utiliza un método de comunicación dinámica SOA basado en servicios (SOME/IP);
4) Diferentes relaciones de conexión: en AUTOSAR CP, la relación de conexión de los recursos de hardware se limita a la conexión del mazo de cables, mientras que en AUTOSAR AP, la relación de conexión entre los recursos de hardware está virtualizada y no se limita a la relación de conexión del mazo de cables de comunicación;
5) Diferentes métodos de programación: AUTOSAR CP utiliza una configuración de programación de tareas fija. Los módulos y configuraciones se compilan y vinculan estáticamente antes del lanzamiento y se ejecutan en secuencia de acuerdo con las reglas establecidas. Sin embargo, AUTOSAR CP admite una variedad de estrategias de programación dinámica y los servicios pueden Se pueden personalizar según la aplicación. Los requisitos se cargan dinámicamente y se pueden actualizar individualmente.
6) La ejecución del código y el espacio de direcciones son diferentes: en AUTOSAR CP, la mayor parte del código se ejecuta estáticamente en ROM y todas las aplicaciones comparten un espacio de direcciones, mientras que en AUTOSAR AP, las aplicaciones se cargan en RAM y se ejecutan, y cada aplicación es exclusiva. (virtual) un espacio de direcciones.
Estas diferencias aportan las siguientes ventajas a AUTOSAR AP:
1) La ECU es más inteligente: basada en la comunicación SOA, la ECU en el AP puede conectarse dinámicamente con otras ECU para proporcionar u obtener servicios;
2) Potencia informática más potente: basado en la arquitectura SOA, el AP puede admitir mejor el procesamiento paralelo de múltiples núcleos, múltiples ECU y múltiples SoC, proporcionando así una potencia informática más poderosa;
3) Más seguro: basado en la arquitectura SOA, cada módulo de servicio en el AP es independiente y se puede cargar de forma independiente, e IAM gestiona los derechos de acceso;
4) Desarrollo ágil: los servicios AUTOSAR adaptativos no se limitan a implementarse localmente en la ECU, sino que pueden distribuirse en la red del vehículo, lo que permite que los módulos del sistema se implementen de manera flexible y se actualicen de forma independiente más adelante (FOTA);
5) Alto ancho de banda de comunicación: se puede realizar comunicación por bus basada en un alto ancho de banda de comunicación como Ethernet;
6) IoT más sencillo: la comunicación SOA basada en Ethernet facilita la realización de conexiones inalámbricas, remotas y en la nube, lo que facilita la implementación de aplicaciones V-2-X.
(Foto tomada de Neusoft Reichi)
Por supuesto, en algunos aspectos, AUTOSAR AP tiene algunas "desventajas" en comparación con AUTOSAR CP. Por ejemplo, la latencia de AUTOSAR CP puede ser tan baja como microsegundos y el nivel de seguridad funcional alcanza ASIL-D, en tiempo real; mientras que la latencia de AUTOSAR AP está en el nivel de milisegundos y el nivel de seguridad funcional alcanza ASIL- B, suave en tiempo real.
Las diferencias anteriores también conducen a diferencias en los campos de aplicación de los dos: AUTOSAR CP se usa generalmente en escenarios que requieren un alto rendimiento en tiempo real y seguridad funcional y bajos requisitos de potencia informática, como las ECU tradicionales, como el control del motor y el frenado; mientras que AUTOSAR CP Se utiliza en escenarios que tienen ciertos requisitos de rendimiento en tiempo real y seguridad funcional, pero requieren mayor potencia informática, como ADAS, conducción autónoma y escenarios de infoentretenimiento que persiguen un mayor grado de libertad en el despliegue dinámico.
Aunque AUTOSAR AP tiene varias ventajas, en general no está lo suficientemente maduro en la actualidad, principalmente debido a la inmadurez de la seguridad de la información y los módulos UCM. Hay muchos vehículos producidos en masa equipados con AUTOSAR AP, pero se utilizan principalmente en escenarios de entretenimiento y muy pocos se utilizan realmente en escenarios de conducción autónoma.
Además, dado que el fenómeno de la combinación SOC + MCU existirá durante mucho tiempo, AUTOSAR AP no podrá reemplazar completamente a AUTOSAR CP durante mucho tiempo en el futuro; la división del trabajo más común es entregar tareas que requieren alta potencia informática a AUTOSAR AP, mientras que el trabajo que requiere un alto rendimiento en tiempo real se entrega a AUTOSAR CP.
(Foto tomada de Super Star Future)
2.ROS 2 _
ROS es la abreviatura en inglés de Robot Operating System. El ROS nativo es originalmente un sistema operativo de robot y no puede satisfacer directamente todas las necesidades de la conducción autónoma. ROS 2 se utiliza como middleware para la conducción autónoma.
Las principales diferencias entre ROS 2 y ROS 1 son las siguientes:
(1).ROS 1 se basa principalmente en el sistema Linux y es principalmente compatible con Ubuntu; ROS 2 adopta una nueva arquitectura, la capa inferior se basa en el mecanismo de comunicación DDS (Servicio de distribución de datos) y admite tiempo real, integrado y distribuido. y sistemas multioperativos. Los sistemas soportados por ROS 2 incluyen Linux, Windows, Mac, RTOS e incluso bare metal sin sistemas operativos como microcontroladores.
(2) El sistema de comunicación de ROS 1 se basa en TCPROS / UDPROS y depende en gran medida del procesamiento del nodo maestro, el sistema de comunicación de ROS 2 se basa en DDS, que cancela el maestro y al mismo tiempo proporciona un resumen. Implementación de capa de DDS internamente. Con esta capa de abstracción, los usuarios no tienen que prestar atención a qué API de comerciante utiliza el DDS subyacente.
(3) ROS depende de roscore cuando se ejecuta. Una vez que hay un problema con roscore, causará un desastre importante en el sistema. Al mismo tiempo, debido al gran volumen de instalación y operación, causará una carga para muchos usuarios de bajo nivel. sistemas de recursos; ROS2 usa DDS para la transmisión de datos, y DDS se basa en el marco de comunicación descentralizada de RTPS, que elimina la dependencia de roscore, hace que el sistema sea más estable y reduce el consumo de recursos.
(4) Debido a la falta del mecanismo Qos en ROS, la estabilidad y la calidad de los temas son difíciles de garantizar; ROS2 proporciona un mecanismo Qos para admitir funciones de comunicación en tiempo real, completas, históricas y otras, lo que mejora en gran medida la funciones framework., evitando problemas como la dificultad en la aplicación de sistemas de alta velocidad.
Sin embargo, la configuración QoQ de ROS2 es relativamente compleja. Actualmente la utilizan principalmente algunas universidades o laboratorios profesionales en el extranjero, y solo unas pocas empresas nacionales lo están intentando. Además, la madurez ecológica de ROS2 es mucho menor que la de ROS. lo que también trae dificultades para la promoción y aplicación, es un inconveniente.
Al igual que AUTOSAR AP , ROS 2 también funciona con chips SoC y se utiliza para satisfacer las necesidades de conducción autónoma de alto nivel. Sin embargo, Xiao Meng enfatizó en una serie de artículos el año pasado que cuando llamamos "ROS/ROS2 como middleware", su significado no es equivalente a "AUTOSAR AP como middleware".
El artículo de Xiao Meng decía:
Cuando decimos que AutoSar es middleware, este middleware tiene una semántica de capa L.BSW muy clara, es decir, está entre el sistema operativo de la computadora y la implementación de funciones específicas de la ECU del vehículo, y protege la capa de implementación de funciones de la ECU del procesador específico. y detalles relacionados con el sistema operativo de la computadora y proporcionar servicios básicos necesarios para interactuar con las redes de vehículos, fuentes de alimentación y otros sistemas;
ROS/ROS2 es un marco de aplicación para el desarrollo de robots. Proporciona un marco de capa intermedia común y módulos de software comunes (paquete ROS) entre las aplicaciones de robots y el sistema operativo de la computadora. Además, el equipo de ROS cree que este marco es lo suficientemente bueno como para llamarlo sistema operativo. (SO).
Aunque ROS 2 tiene muchas superposiciones funcionales con AUTOSAR AP, las dos ideas son diferentes:
(1). Desde la perspectiva de la expresión, AUTOSAR AP es ante todo un conjunto de estándares. Este estándar define una serie de componentes básicos de la plataforma. Cada componente de la plataforma define una interfaz estándar para las aplicaciones, pero no define los detalles de implementación. (Estos las partes se dejan a cargo de los proveedores de AUTOSAR AP para implementarlas); ROS2 ha sido el código primero desde el principio. Cada versión tiene una implementación de código completa y también define interfaces API estándar orientadas a aplicaciones.
(2) AUTOSAR AP ha estado orientado a aplicaciones ASIL-B desde el principio; ROS 2 no está diseñado de acuerdo con los estándares ASIL. La solución para que ROS 2 logre seguridad funcional es reemplazar la capa inferior con un RTOS y una cadena de herramientas comerciales que cumplir con los requisitos de ASIL (dispositivo de compilación).
ROS 2 "no puede pasar las regulaciones de los automóviles" parece haberse convertido en un consenso muy amplio de la industria. Pero en opinión de Xiao Meng, ROS2 no fue diseñado originalmente para el dominio del tiempo real. Si los algoritmos de control de vehículos con altos requisitos de tiempo real deben ejecutarse en ROS2, "eso es un error de diseño de software, no un problema con ROS2".
Xiao Meng cree que siempre que pueda completar todas las funciones requeridas por la capa L.BSW y completar las características requeridas por todos los aspectos del eje A, ROS 2 se puede utilizar en vehículos autónomos de producción en masa. Por ejemplo, Apex.AI, una empresa que acaba de recibir inversión de ZF y otros gigantes hace algún tiempo, ha personalizado y desarrollado Apex.OS basado en ROS 2 y ha superado el nivel más alto de certificación ASIL D.
Xiao Meng dijo: "Esto en realidad se basa en la arquitectura ROS 2 para implementar un conjunto de especificaciones AUTOSAR AP. Esto puede convertirse en un producto separado y puede desarrollarse invirtiendo tiempo + personas + dinero. Solo vea si es necesario y si vale la pena." .
En la práctica específica, ROS 2 compite directamente con AUTOSAR AP; aunque no existe un problema estricto de "elegir uno" para los usuarios, en términos generales, si eligen ROS 2, no elegirán AUTOSAR AP; si elijo AUTOSAR AP , No elegiré ROS 2.
3. CiberRT
Cyber RT es un middleware desarrollado por Baidu Apollo y lanzado oficialmente en Apollo 3.5. Cyber RT es similar a ROS2 y su capa inferior también utiliza una versión de código abierto de DDS.
Baidu usó ROS 1 por primera vez, pero durante el proceso de uso, descubrió gradualmente que ROS 1 tenía el problema de "si el ROS Master falla, la comunicación entre dos nodos cualesquiera se verá afectada", por lo que espera usar un " "No intermedio middleware de comunicación "nodo" para reemplazar ROS 1. No había ROS 2 en ese momento, así que hice un Cyber RT yo mismo.
Para resolver los problemas encontrados por ROS, Cyber RT eliminó el mecanismo maestro y lo reemplazó con un mecanismo de descubrimiento automático. Este mecanismo de red de comunicación es exactamente el mismo que la red automotriz CAN. Además, el diseño central de Cyber RT traslada la programación y las tareas del espacio del kernel al espacio del usuario.
(Fuente de la imagen: https://blog.csdn.net/xhtchina/article/details/118151673)
Comparado con otros sistemas, una de las principales ventajas de Cyber RT es que está especialmente diseñado para conducción no tripulada. Baidu tiene Cyber RT de código abierto y el middleware utilizado por el equipo de conducción autónoma de un gigante de Internet es Cyber RT de código abierto de Baidu.
También existe competencia entre Cyber RT y ROS 2.
Al hablar sobre la relación entre AUTOSAR AP, ROS 2 y el middleware Cyber RT, el experto en productos Vector, Cai Shoequn, explicó:
"No es necesario clasificarlos mecánicamente. Se puede pensar en AUTOSAR AP, ROS y Cyber RT como un supermercado que proporciona un conjunto de middleware. Los usuarios pueden comprarlo en diferentes supermercados según sea necesario. Eso no significa que tengan Compré uno en un supermercado. El middleware no se puede comprar en otros supermercados.
Cai Shouqun dijo: AUTOSAR AP también incluye soporte para la interfaz ROS. No se sabe qué día ROS y Cyber RT agregarán componentes AUTOSAR AP, o qué día AUTOSAR AP introducirá componentes Cyber RT.
4. DDS (middleware de comunicación)
(1) ¿Qué es DDS?
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 sus funciones son comunicación, que en un sentido estricto es middleware de comunicación.
La comunicación se puede dividir en dos tipos: de código abierto y de código cerrado. Los de código abierto son OPEN DDS, FAST DDS, Cyclone, etc. Los de código cerrado son DDS de RTI y SOME/IP de Vector. DDS significa Servicio de distribución de datos, que se refiere a un estándar de servicio de distribución de datos formulado por Object Management Group (OMG).
DDS puede realizar servicios de fusión de datos de baja latencia, alta confiabilidad y alto tiempo real, reducir fundamentalmente el acoplamiento y la complejidad del software y mejorar la modularidad del software. La conducción autónoma de alto nivel ahora básicamente está explorando el uso de DDS para resolver desafíos como la comunicación heterogénea y la baja latencia que no pueden resolverse mediante CP.
El software automotriz integrado con DDS puede funcionar mejor en la arquitectura de los automóviles de próxima generación, reducir los costos de desarrollo, acortar el tiempo de investigación y desarrollo y llevar los productos al mercado más rápido.
( 2 ) Relación entre DDS y ROS 2, AUTOSAR AP
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. Sin embargo, algunos ingenieros de empresas de conducción autónoma creen que DDS puede reemplazar a ROS 2. Desde la perspectiva del usuario, en realidad existe una relación de "elige uno" entre los dos.
AUTOSAR CP nunca ha incluido nada relacionado con DDS, pero AUTOSAR AP comenzó a admitir el estándar DDS en la última versión (versión 18-10) en marzo de 2018. La combinación de DDS con AUTOSAR AP no solo garantiza y amplía la funcionalidad de interoperabilidad dentro del sistema AUTOSAR AP, sino que también lo abre a personas de diferentes ecosistemas (es decir, ROS 2).
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 oponentes 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, con dominios funcionales que proporcionan una superposición flexible sobre el vehículo físico, lo que se denomina arquitectura particionada.
Por supuesto, DDS es sólo un tipo de middleware de comunicación. Con respecto a las similitudes y diferencias entre varios middleware de comunicación, las explicaremos con más detalle en el segundo artículo de esta serie.
tres. ¿Se está debilitando el estado de A UTOSAR AP ?
Aunque AUTOSAR es el middleware de conducción autónoma más famoso en este momento, "Nine Chapters Smart Driving" llegó a una conclusión en su encuesta a muchos fabricantes de middleware: la posición de AUTOSAR en la cadena industrial puede estar debilitándose. Por supuesto, los fabricantes que se centran en los sistemas AUTOSAR no están de acuerdo con esta opinión.
Hemos mencionado anteriormente que a medida que la arquitectura EE evoluciona de distribuida a centralizada, MCU es reemplazada por SOC y CP AUTSAR es reemplazado por AUTOSAR AP, ROS 2 y Cyber RT, etc., es la tendencia general. hable sobre "¿Se debilitará el estatus de AUTOSAR AP?"
A mediados de diciembre de 2021, los dos patrocinadores de AUTOSAR, Continental, Toyota y ZF Friedrichshafen, Jaguar Land Rover, Volvo, Hella y muchas otras empresas líderes de la industria automotriz anunciaron su inversión en la startup de sistemas operativos para vehículos Apex.AI y Apex. .AI's El producto principal, Apex.OS, está desarrollado en base a ROS 2.
ZF, que ha adquirido una participación del 15% en Apex.AI, dijo en una entrevista con los medios: "Esto significa que podemos ofrecer a los clientes una alternativa a AUTOSAR AP".
Aunque existe un estándar para AUTOSAR AP, aún no se ha implementado. Las soluciones proporcionadas por empresas como Aptiv, ZF y Continental todavía se basan en la interfaz estándar AUTOSAR CP. De hecho, cada vez más fabricantes de equipos originales no quieren utilizar AUTOSAR por completo para resolver los problemas de los sistemas operativos de conducción inteligente.
No solo Tesla no utiliza AUTOSAR AP, sino también varias nuevas fuerzas de fabricación de automóviles nacionales (utilizan AUTOSAR CP+DDS). Incluso algunas empresas de automóviles tradicionales que están en proceso de transformación no planean utilizar AUTOSAR AP.
A juzgar por las reacciones de todas las partes de la cadena industrial, las principales razones del "estado inestable" de AUTOSAR AP son las siguientes:
1 . El costo de uso es demasiado alto.
Dr. Feng Zhanjun en "¿AUTOSAR es bueno o malo para el desarrollo de software básico?" "El artículo revela que el costo de AUTOSAR generalmente comienza en "unos pocos millones" y que se requieren "cargos repetidos" para diferentes controladores de dominio y diferentes chips, lo que simplemente está fuera del alcance de los pequeños fabricantes comunes y corrientes. "Puede que no haya producción, pero se gastarán millones".
Además del alto costo de compra, tanto Bi Xiaopeng como Xiao Meng mencionaron que AUTOSAR es muy difícil de aprender en la etapa inicial y el costo de aprendizaje también es muy alto. Para aprender a utilizar AUTOSAR, las empresas incluso tienen que capacitar a un grupo de personas. Si las personas capacitadas se van temporalmente, el costo de la capacitación se desperdiciará.
2. No eficiente
Bi Xiaopeng cree que AUTOSAR AP tiene muchas configuraciones, implementa sus funciones a través de la configuración y parte del código, pero después de demasiadas configuraciones, la eficiencia no es alta y el código está inflado.
3. Conflicto conceptual entre implementación estática y implementación dinámica
El Dr. Bi Xiaopeng mencionó que AUTOSAR AP en realidad se desarrolló a partir de AUTOSAR CP. AUTOSAR CP es una implementación estática y solo es adecuado para funciones y lógica de negocios relativamente simples. Su código está solidificado, un poco como los teléfonos con funciones anteriores: las funciones no se pueden cambiar. , es imposible agregarle una aplicación, pero AUTOSAR AP es un poco como los teléfonos inteligentes actuales. Los desarrolladores de software desarrollan una aplicación y pueden usarla en diferentes teléfonos móviles en diferentes plataformas. Este concepto de implementación dinámica es diferente del concepto de implementación estática anterior. No es exactamente lo mismo, pero su metodología se deriva del despliegue estático, por lo que encontrará muchos problemas a nivel práctico.
4. No se pueden satisfacer las necesidades de conexión de red inteligente
Dado que los sistemas operativos utilizados por la nube y el automóvil son diferentes, AUTOSAR solo puede ser responsable de la comunicación en el automóvil y no puede soportar la comunicación desde el automóvil a la nube. Por lo tanto, no puede soportar el escenario de colaboración vehículo-carretera (el La comunicación entre el automóvil y la nube se realiza a través de MQTT (implementado por middleware como Kafka). Además, también existen grandes dudas sobre si AUTOSAR es compatible con la plataforma de datos, la plataforma de comunicación y la plataforma de mapas necesarias para la interconexión de vehículos.
Bi Xiaopeng dijo que después de descubrir estos problemas, algunos OEM comenzaron a abandonar gradualmente la arquitectura AUTOSAR y "se dedicaron a desarrollar una nueva arquitectura de software que sea más adecuada para una implementación dinámica y de menor costo".
Los fabricantes de automóviles tradicionales provienen del uso de CP, por lo que en términos de inercia, es posible que aún consideren si AP es adecuado para la conducción inteligente, pero están tratando de transformarse lentamente. Por ejemplo, zFAS, el middleware de comunicación producido conjuntamente por Audi y TTTech, no utiliza AP.
A diferencia de AUTOSAR CP, que ya está muy estandarizado y todo el mundo no tiene problemas para utilizarlo, el estándar actual de AUTOSAR AP no es muy completo y se actualiza cada año. Nadie sabe en qué se puede desarrollar el AP específico, y la mayoría de ustedes también. Espera y verás la actitud.
Bi Xiaopeng cree que el estándar AUTOSAR no puede respaldar bien el desarrollo de aplicaciones e innovación de conducción autónoma, por lo que es necesario que establezcamos una arquitectura técnica y un ecosistema que sea más adecuado para el desarrollo de la conducción inteligente en China y que sea autónomo y controlable. .
Xiao Meng cree que debido al linaje continuo de AUTOSAR CP a AUTOSAR AP, algunas empresas que han formado una dependencia de AUTOSAR insistirán en usar AUTOSAR AP, pero después de experimentar las dificultades de contratación y el largo ciclo de desarrollo, pueden cambiar a ROS. 2.
Por supuesto, las empresas que tienen a AUTOSAR como su negocio principal obviamente no estarán de acuerdo con el punto de vista antes mencionado de "sospecha de malas palabras" de AUTOSAR AP.
Por ejemplo, Vector Cai Shouqun cree que AUTOSAR AP será cada vez más importante, porque es un conjunto de especificaciones que se ajusta al desarrollo continuo de la tecnología de los vehículos, y su cobertura será cada vez más amplia.
Neusoft Ruichi Mao Haiyan también cree que sería difícil fusionar los controladores de dominio de vehículos y los controladores de dominio de conducción inteligente en una plataforma informática central unificada sin el apoyo de AUTOSAR AP. "No todas las empresas pueden construir un sistema desde cero como Tesla. Actualmente, la mejor herramienta es AUTOSAR AP".
Investigación especial sobre el informe de la industria de la conducción inteligente
Para comprender mejor el enfoque de la conducción inteligente en la industria, Jiuzhang Zhijia lo invita sinceramente a tomarse unos dos minutos para escanear el código QR a continuación para participar en esta encuesta. ¡Gracias por su atención y apoyo a Jiuzhang!
Referencias:
Automóviles definidos por software (2) -middleware de software (Autosar como ejemplo)
https://zhuanlan.zhihu.com/p/261291971
Un artículo para entender el "middleware" de la conducción autónoma
https://zhuanlan.zhihu.com/p/372712318
"Icebuck": ¡el "middleware" que respalda el futuro de la conducción autónoma!
https://www.sohu.com/a/413809647_362550
Arquitectura de software de conducción autónoma: middleware y SOA (3)
https://mp.weixin.qq.com/s/vFHw3U3ESJs_16x6e2kctg
¿AUTOSAR es una bendición o una preocupación para el desarrollo de software básico?
https://mp.weixin.qq.com/s/EDiVWZ027s7zlWAaC5nMFA
Comparación de ROS y ROS2
https://blog.csdn.net/tuziaaa/article/details/103358145
Comparación de middleware ROS/CyberRT/AutoSAR
https://blog.csdn.net/xhtchina/article/details/118151673
Diseño de middleware y arquitectura en los campos de la conducción autónoma y la robótica.
https://www.likecs.com/show-126986.html
¿Por qué utilizar AP? ¿Qué ofrece exactamente Adaptive AutoSAR a las empresas?
https://blog.csdn.net/usstmiracle?type=blog
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 actual al agregar WeChat
Además de información como las posiciones previstas, ¡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 actual al agregar WeChat
Además de información como las posiciones previstas, ¡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 ser invisible en otros medios, si se basa en información pública debe tener un punto de vista especialmente potente y excluyente. Gracias por su comprensión y apoyo.
Lectura recomendada:
◆ Nueve capítulos: una colección de artículos en 2021
◆ Algunas observaciones sobre los controladores de dominio de conducción inteligentes
◆ Quitar fusibles y relés para hacer más segura la conducción autónoma