La evolución de la conducción de automóviles inteligentes: análisis de los tipos de ECU virtuales y sus ventajas y desventajas

El precio de los automóviles modernos más seguros, cómodos e inteligentes es el rápido crecimiento del número de ECU (unidades de control electrónico) a bordo. En consecuencia, la escala del software de las ECU es cada vez mayor y los costos de desarrollo de software representan gran parte de los costes de fabricación de vehículos, y la proporción es cada vez mayor. Las empresas de automóviles pueden resolver los problemas anteriores desde dos perspectivas: reglas y métodos:

• Agarre las reglas con una mano: AUTOSAR, la arquitectura de sistema abierto para automóviles;

• Enfoque con una sola mano: cree una ECU virtual mediante tecnología de modelado de simulación para realizar el "gemelo digital" del automóvil.

En base a esto, este artículo analizará los distintos tipos de ECU virtuales basadas en la arquitectura AUTOSAR y sus ventajas y desventajas en la evolución de la conducción de automóviles inteligentes.

01. Arquitectura del sistema abierto del automóvil AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) se originó en 2003. Es una alianza de arquitectura de sistemas abiertos para automóviles establecida conjuntamente por fabricantes de automóviles, proveedores de componentes y otras empresas de sistemas electrónicos, semiconductores y software de renombre mundial. Las especificaciones introducidas por la alianza se denominan Es una especificación AUTOSAR que mejora la compatibilidad, reutilización y confiabilidad de las ECU automotrices al estandarizar la definición de software básico automotriz.

AUTOSAR sigue un método de desarrollo de arriba hacia abajo, es decir, el diseño del sistema se lleva a cabo primero, luego el desarrollo y la implementación se llevan a cabo por separado y finalmente se lleva a cabo la integración del sistema. Principalmente hizo las siguientes tres cosas:

• Estandarizar la interfaz entre el software de aplicación y el software subyacente y entre el software de aplicación;

• Proporcionar una arquitectura de referencia del software del controlador;

• Estandarizar el formato de intercambio en el proceso de desarrollo distribuido.

Según los datos de AUTOSAR GBR, arquitectura de software de capa AUTOSAR R4.4.0, su marco general es un diseño en capas, con el middleware RTE (Runtime Environment, RTE) como límite, aislando la capa de aplicación superior (Application Layer, APPL) y el Software Básico de capa inferior (Software Básico, BSW).

▲Arquitectura del software AUTOSAR

Después de 20 años de desarrollo a largo plazo, la arquitectura AUTOSAR ha madurado y el grado de acoplamiento de software y hardware de los sistemas integrados automotrices se ha reducido considerablemente. Hasta ahora, AOTOSAR se ha utilizado ampliamente en el desarrollo de software de ECU y diseño electrónico automotriz. , como el desarrollo de sistemas de control de chasis de automóviles, el diseño de software de comunicación de bajo nivel, el diseño de arquitectura eléctrica y electrónica de vehículos, el desarrollo de sistemas de diagnóstico electrónico de automóviles y el diseño de sistemas de control de motores proporcionan nuevas soluciones para satisfacer las crecientes necesidades de los usuarios de conducción inteligente.

02. Análisis de los tipos y pros y contras de la ECU virtual.

Según los diferentes niveles del marco AUTOSAR, las ECU virtuales se pueden dividir en las cuatro categorías siguientes:

▲ Clasificación de ECU virtual

La primera categoría: solo contiene ASW y RTE (RTE puede contener un sistema operativo)

• Solo simula el entorno RTE y solo puede probar las funciones básicas de ASW, ignorando los detalles de comunicación en el software básico.

• Si el código ASW es ​​compatible con AUTOSAR, se puede probar el código ASW.

**Este tipo de ECU virtual tiene una estructura relativamente simple porque no involucra hardware, pero no puede garantizar el mismo comportamiento de ejecución que una ECU real.

La segunda categoría: incluye ASW, RTE y BSW virtual.

• Este tipo de ECU virtual es más realista que el primer tipo y puede probar códigos ASW y RTE.

• La función del BSW virtual es abstraer y encapsular las características y la complejidad del hardware subyacente y proporcionar interfaces y funciones simplificadas para el software de aplicación de la capa superior, logrando así la virtualización del hardware subyacente.

** Algunos comportamientos de implementación reales en hardware real no se pueden probar.

La tercera categoría: SO y una MCAL (Capa de abstracción de microcontrolador) virtual se agregan sobre la base de lo anterior.

• En comparación con el segundo tipo, es más realista y puede probar la programación de tareas y las funciones BSW.

• Virtual MCAL es responsable de encapsular el acceso al hardware subyacente, completar las funciones relacionadas con el hardware a través de la simulación de software y proporcionar una interfaz unificada para el software de la capa superior, de modo que los desarrolladores de software puedan escribir aplicaciones de manera más conveniente sin preocuparse por las diferencias en el hardware subyacente.

**Vale la pena señalar que la MCAL virtual también trae algunos problemas:

Pérdida de rendimiento: dado que el MCAL virtual realiza la virtualización de las funciones de hardware subyacentes a través de la simulación de software, el rendimiento de la simulación puede ser relativamente menor que el del acceso directo al hardware real, especialmente en escenarios de aplicaciones con altos requisitos en tiempo real; puede aparecer Latencia asuntos.

Problema de adaptabilidad: debido a que necesita ser desarrollado y adaptado para diferentes hardware subyacentes para lograr la simulación, el MCAL virtual original tiene una alta probabilidad de no poder cubrir completamente todas las características y funciones del hardware subyacente. aumentará.

Complejidad y costo de mantenimiento: El desarrollo y mantenimiento de MCAL virtual puede requerir una gran inversión de mano de obra y recursos. Aunque el MCAL virtual puede proporcionar una interfaz abstracta y unificada, su implementación subyacente está relacionada con el hardware y requiere que los ingenieros tengan un conocimiento profundo de las especificaciones del hardware para implementar el mantenimiento. La complejidad y el costo del desarrollo y el mantenimiento también aumentarán.

Limitaciones funcionales: dado que es posible que la implementación de simulación de MCAL virtual no pueda reproducir completamente las funciones de todo el hardware subyacente, estará limitada en algunas funciones complejas y no podrá satisfacer las necesidades de todos los escenarios de aplicación, especialmente en algunas funciones y características de hardware complejas. .

Poca flexibilidad: este tipo de ECU virtual no puede ejecutar directamente el código binario de la ECU real y carece de soporte para controladores de dispositivos complejos (CDD). 

Categoría 4 (Mejor): Igual que la Categoría 3, pero MCAL es MCAL de hardware real.

• Se implementa una emulación completa, lo que permite un comportamiento del hardware real casi idéntico.

• El funcionamiento directo de [el mismo código binario que la ECU real] se puede realizar simulando completamente el procesador de la ECU, los periféricos relacionados, el bus y otras instalaciones.

• Sobre esta base, se puede realizar la inyección de fallas que no se puede lograr con hardware real para probar la seguridad y confiabilidad del software.

• Tiene una gran flexibilidad y puede aumentar el modelado y la simulación de CDD.

**Debido a la necesidad de simular los detalles técnicos del hardware, existe una cierta carga de trabajo y ciclo de modelado; al mismo tiempo, para garantizar un cierto rendimiento en tiempo real, la construcción de este tipo de ECU virtual a menudo Tiene alta dificultad técnica.

Solución de ECU virtual basada en SkyEye

SkyEye, el software de simulación nacional en tiempo real totalmente digital y autocontrolable de Tianmu , como plataforma de simulación de nivel de comportamiento de hardware basada en modelado visual, respalda la construcción del cuarto tipo de ECU virtual, que puede simular en gran medida el controlador real. Además de las ventajas originales del cuarto tipo de ECU virtual, la solución de ECU virtual basada en SkyEye también tiene las siguientes características:

• Las tareas de desarrollo se pueden descargar desde pruebas de unidades y bancos de pruebas a PC con Windows/Linux para un desarrollo eficiente de software en bucle (SIL) del software de ECU.

• El sistema en sí también es un potente entorno experimental, que puede interactuar con los modelos de simulación de varias herramientas (incluida la ejecución de MATLAB/Simulink y otras herramientas a través de la interfaz FMI estandarizada) a través de la herramienta de plataforma de bus de cosimulación.

• La configuración relacionada de la ECU virtual se puede copiar y ampliar rápidamente, el costo de copia es bajo y es mucho más fácil que el hardware real.

• Cada ingeniero puede tener un entorno de desarrollo personal sin ocupar recursos escasos, como bancos HIL o vehículos de prueba, evitando el problema de los largos ciclos de I+D causados ​​por la escasez de recursos de hardware, y más ingenieros pueden beneficiarse de ello.

En general, la solución de ECU virtual basada en SkyEye tiene las siguientes ventajas:

• El desarrollo, la integración y las pruebas de software se pueden llevar a cabo en la etapa inicial de desarrollo, lo que acelera todo el proceso de desarrollo y mejora la eficiencia del desarrollo.

• Reduzca la demanda de pruebas de vehículos reales, reduzca el costo y el tiempo de las pruebas y reduzca los riesgos y pérdidas causados ​​por las pruebas de vehículos reales.

• Proporciona resultados de simulación visualizados para ayudar a los desarrolladores a comprender el comportamiento y el rendimiento del sistema de control de forma más intuitiva.

• La prueba se puede realizar en un entorno simulado, lo que mejora la precisión y repetibilidad de la prueba y reduce el error humano en la prueba.

Como tecnología innovadora, la ECU virtual tiene una importancia práctica importante para el desarrollo de software de ECU. No solo mejora la eficiencia del desarrollo y la reutilización del software automotriz, sino que también facilita la integración y verificación del sistema, también proporciona un mejor entorno para el desarrollo y las pruebas de software y desempeña un papel importante en la seguridad y el aislamiento del software de la ECU del automóvil. role. La ECU virtual desempeñará un papel cada vez más importante en el desarrollo de futuros sistemas electrónicos automotrices, impulsando a la industria automotriz hacia un futuro más inteligente y seguro.