Arquitectura de software del vehículo: la misma y diferente entre CP y AP

prefacio

AUTOSAR (Arquitectura de sistema abierto AUTmotive) es un nodo importante en el desarrollo de sistemas E/E electrónicos automotrices. Este estándar es una arquitectura de software de ECU de referencia abierta definida por una organización de desarrollo de estándares dirigida por OEM como BMW, DAIMLER, GM, TOYOTA y Ford, y proveedores como Bosch y Continental.

El propósito original es evitar el desarrollo repetido de módulos de software con funciones iguales y similares. El uso de una plataforma de software estándar independiente del sistema puede acortar el tiempo de comercialización, reducir el trabajo de desarrollo y desarrollar más productos a partir del mismo conjunto de componentes, mejorar la calidad del producto y lograr el desacoplamiento de software y hardware.

Ya sea AP AUTOSAR o CP AUTOSAR, el objetivo general inicial del estándar es el mismo:

1. Mejor gestión de ECU automotrices con mayor cantidad y mayor complejidad funcional; 

2. Mejorar la calidad y confiabilidad del software ECU;

3. Mejorar la flexibilidad de las actualizaciones de productos y acortar el tiempo de comercialización de los productos;

4. Soluciones de arquitectura escalable.

Los contenidos preconizados por los estándares CP AUTOSAR y AP AUTOSAR son los mismos:

1. Diseño estándar de arquitectura de software automotriz;

2. Diseño detallado del módulo de software subyacente;

3. Descripción de datos estandarizados para cada campo de productos de automóviles;

4. Definición de procesos y cadena de herramientas de software adecuadas para esta arquitectura.

Las similitudes radican más en comenzar desde la perspectiva macro e implementar las estrategias de implementación específicas, que reflejan las diferencias.

---

1. La diferencia entre los dos

Teniendo en cuenta los principales escenarios de aplicación de las dos arquitecturas de software, los requisitos de rendimiento del chip (tiempo real y potencia informática):

CP AUTOSAR generalmente se ejecuta en microcontroladores (MCU) de 8 bits, 16 bits y 32 bits, y la potencia informática del chip que ejecuta CP AUTOSAR generalmente es inferior a 1000 DMIP.

AP AUTOSAR puede ejecutarse en procesadores de alto rendimiento (MPU), CPU, etc. de 64 bits. AP AUTOSAR también puede ejecutarse en hardware virtual y AP AUTOSAR puede ejecutarse en chips con una potencia informática superior a 20 000 DMIP.

La arquitectura del software CP AUTOSAR está en capas, y existe una relación relativamente obvia entre las capas superior e inferior. Para obtener más información, consulte la siguiente figura:

Como se muestra en la figura anterior, la arquitectura en capas incorporada implementa diferentes funciones (de abajo hacia arriba):

1. Capa de microcontrolador (HW);

2. Capa de software básica (BSW):

• Capa de abstracción del microcontrolador

• Capa de abstracción de ECU

• capa de servicio

• unidad compleja

3. Capa RTE: incorpora todas las interfaces de la aplicación, interactúa entre módulos de software a través de RTE y accede a BSW a través de RTE;

4. Capa de aplicación: no depende del hardware.

En comparación con CP AUTOSAR, AP AUTOSAR generalmente se refiere a ARA (AUTOSAR Runtime for Adaptive Applications), que consta principalmente de dos partes:

1. Base;

2. Servicio.

El diagrama específico se muestra en la siguiente figura:

Nota:

Todos los módulos se denominan clústeres funcionales (Functional Clusters, FC), el FC azul pertenece a la parte Foundation y la parte naranja pertenece a la parte Service. Ya sea el FC de la parte de la Fundación o el FC de la parte del Servicio, no es una relación entre las capas superior e inferior.

2. Principios de diseño de arquitectura

Los principios de diseño de la arquitectura CP AUTOSAR son:

• CP AUTOSAR define las funciones generales y relacionadas con el hardware del sistema como módulos BSW

• Las funciones de la aplicación se definen como componentes de software independientes SWC

• RTE separa SWC y BSW

• BSW es ​​configurable y puede ser reutilizado por ECU de múltiples líneas de productos

• No es de código abierto

Los principios de diseño de la arquitectura AP AUTOSAR son:

• Siga el paradigma de diseño SOA de arquitectura orientada a servicios (este concepto no es un concepto nuevo, el concepto de aplicación madura se ha utilizado en Internet original, pero el escenario de la aplicación se cambia al vehículo)

• Aproveche al máximo las tecnologías de software maduras en otros campos, reutilice componentes maduros en el mercado de software y acorte el ciclo de desarrollo.

• Aproveche al máximo varios software de código abierto (en comparación con el código no abierto de CP)

Desde la perspectiva del proceso de desarrollo, tanto CP como AP incluyen principalmente las siguientes tres etapas:

Fase de diseño: diseñar ARXML;
generación de código: generar código basado en ARXML;
integración: integrar aplicación, compilar y depurar, etc.

Para la fase de desarrollo, también existen diferencias, como se detalla a continuación:

En la fase de diseño de AP AUTOSAR se requiere el diseño de Servicio y Manifiesto, en la fase de diseño de CP AUTOSAR se requiere diseño de configuración de ECU, pero AP no tiene el elemento de diseño de configuración de ECU.

El proceso de desarrollo de CP y AP se muestra en la siguiente figura:

El cuadro azul punteado representa el proceso de desarrollo de CP AUTOSAR y el verde representa el proceso de desarrollo de AP AUTOSAR.

CP AUTOSAR se basa en la comunicación de señales, incluyendo principalmente CAN, Lin, FlexRay, etc.

AP AUTOSAR es una comunicación orientada a servicios que soporta SOME/IP, IPC, RPC, etc. basada en Ethernet.

Aunque CP AUTOSAR puede admitir SOME/IP, SOME/IP en CP AUTOSAR solo convierte la comunicación CAN emisor-receptor en comunicación Ethernet cliente-servidor, y todo el enlace de comunicación aún está configurado estáticamente, no es una comunicación real orientada a servicios.

PD : Las ECU integradas tradicionales realizan principalmente la función de reemplazar o mejorar el sistema eléctrico. El software de estas ECU controla principalmente las señales eléctricas que emiten en función de las señales eléctricas de entrada y la información de salida de otras ECU en la red del vehículo, y tienden a no cambiar significativamente a lo largo de la vida útil del vehículo.

La próxima generación de aplicaciones para vehículos, como la conducción autónoma, requerirá un software más complejo con mayores recursos informáticos y cumplirá requisitos más estrictos de integridad y seguridad. Este software debe implementar funciones como la conciencia ambiental y la planificación del comportamiento, y debe integrar vehículos en sistemas de infraestructura y sistemas back-end externos. Con el desarrollo continuo o las funciones mejoradas de los sistemas externos, se requiere que el software del vehículo se actualice continuamente.

Classic AUTOSAR (CP) satisface las necesidades de las ECU integradas tradicionales, pero no se pueden satisfacer las necesidades de las ECU mencionadas anteriormente. Por lo tanto, AUTOSAR especifica otra plataforma de software, Adaptive AUTOSAR (AP). AP está más centrado en proporcionar mecanismos de comunicación y computación de alto rendimiento, y proporciona una configuración de software flexible, como la compatibilidad con la actualización de software por aire (FOTA).

Ventajas del AUTOSAR Adaptativo:

• La ECU es más inteligente: basada en la comunicación SOA, la ECU en el AP puede proporcionar u obtener servicios dinámicamente con otras ECU y conectarse dinámicamente con otras ECU;

• Capacidad informática más potente: basado en la arquitectura SOA, el AP puede soportar mejor el procesamiento paralelo multi-core, multi-ECU y multi-SOC, proporcionando una capacidad informática más potente;

• 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, y IAM administra los derechos de acceso;

• 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, de modo que los módulos del sistema puedan implementarse de manera flexible y actualizarse de forma independiente más tarde (FOTA);

• Alto ancho de banda de comunicación: basado en comunicación de bus con alto ancho de banda de comunicación como Ethernet;

• Internet de las cosas más fácil: la comunicación SOA basada en Ethernet facilita la realización de conexiones inalámbricas, remotas y en la nube, y la implementación de aplicaciones Car-2-X;

• Compatibilidad del sistema: AP puede comunicarse con ECU como CP/Non-AUTOSAR a través de protocolos como SOME\IP.

• P AUTOSAR se usa generalmente en escenarios con altos requisitos de rendimiento en tiempo real, altos requisitos de seguridad funcional y bajos requisitos de potencia informática, como el control del motor y los sistemas de frenado.

  AP AUTOSAR se usa generalmente en escenarios que tienen ciertos requisitos de rendimiento en tiempo real, seguridad funcional y alta potencia informática, como:

  1. Procesamiento de fusión de sensores y actualización dinámica en tiempo de ejecución

  2. Durante la conducción automática:

• Comunicación con la infraestructura de transporte

• Comunicarse con el servidor de la nube

• dominio del cuerpo

• campo de entretenimiento

• dominio dinámico

En los últimos siete u ocho años, el tema de la arquitectura de software AUTOSAR ha sido muy popular y han surgido muchos proveedores de soluciones basados ​​en esta arquitectura de software. Confiando en las ventajas de la entrada temprana, calidad estable y otras ventajas en la industria. A medida que la interpretación del protocolo se vuelve más transparente, también han surgido proveedores de servicios de soluciones en esta área en China.Con la optimización continua en el proceso de uso (desarrollo ágil, iteración rápida), las tecnologías clave no se estancarán tan pronto como sea posible. Por otra parte, Tesla es el mejor en vehículos eléctricos, pero no ha adoptado la arquitectura de software AUTOSAR. Basándose en las capacidades de software de su propio equipo, ha desarrollado su propia arquitectura de software en el vehículo. En cuanto al software en el vehículo, la única forma de lograr sus funciones basadas en su propia arquitectura de software y garantizar la solidez del software es la forma real.