Introducción
La tendencia de avance del diseño de vehículos tradicional hacia C.A.S.E., el acrónimo que representa los temas clave de la automoción de Conectividad, Autónomo, Compartir (Share), Electrificación del vehículo del futuro, requiere un crecimiento exponencial del rendimiento de cálculo general y la carga de comunicación dentro del automóvil.
Para realizar el C.A.S.E. enfoque, la potencia informática necesaria y la complejidad de la red no se pueden lograr con arquitecturas E/E convencionales de una manera económicamente razonable. Esto se debe a que la estructura E/E distribuida requeriría una cantidad significativamente mayor de ECU (Unidades de control electrónico), un aumento correspondiente tanto en la complejidad como en el peso del arnés de cables, un mayor consumo de energía general y un costo más alto.
Por lo tanto, un desafío clave en la transición a C.A.S.E es cómo hacer más sin aumentar la cantidad de ECU físicas. La clave para resolver este desafío radica en una nueva arquitectura de software respaldada por soluciones de hardware capaces, pero aún rentables.
Los fabricantes de automóviles que desarrollan nuevas ECU de zona sin las limitaciones actuales, pueden adoptar una arquitectura de dominio/zona desde el principio. En la práctica, sin embargo, muchos fabricantes de automóviles no parten de un “campo verde” y necesitan preservar las inversiones existentes en ECU SW. Esto implica una migración de sus arquitecturas E/E federadas existentes, donde una ECU corresponde a una función del vehículo, a la arquitectura de Zona.
Un cambio en la arquitectura y las tecnologías de soporte siempre presenta nuevas compensaciones de diseño que deben explorarse. Los desafíos clave son definir qué ECU deben agregarse y en qué parte de la arquitectura SW debe ocurrir la agregación. Además, qué nivel de separación se requiere entre software de diferentes partes (OEM, T1, terceros) o SW de diferentes niveles de seguridad funcional. Finalmente, se debe decidir dónde reutilizar el software existente y dónde aprovechar la oportunidad de reingeniería.
Las opciones están influenciadas fundamentalmente por las cargas de trabajo de SW planificadas y heredadas, la estructura de la cadena de suministro, las políticas de mantenimiento de posproducción, etc. demostrador.
Las siguientes secciones analizan más de cerca el HW y las tecnologías SW complementarias que permiten construir una arquitectura de Dominio/Zona y presentan un demostrador Zone-PoC.
Desafíos de la arquitectura Zonal
Una arquitectura orientada a zonas mueve la integración de numerosas funciones y servicios en una ECU. El concepto de red debe hacer frente a las mayores demandas asociadas de ancho de banda, determinismo y latencia máxima. Dichos controladores de zona, dependiendo de su principal objetivo de diseño como administrador de tráfico, procesador integrado en tiempo real o procesadores de aplicaciones/proveedor de servicios, tienen una necesidad obvia de alta potencia informática para realizar múltiples funciones en paralelo. Por otro lado, también deben garantizar la ausencia de interferencias entre aplicaciones concurrentes por razones de seguridad y preservar el comportamiento en tiempo real en caso de que se aplique dicho requisito.
La mayoría de las ECU modernas ejecutarán la arquitectura de software clásica AUTOSAR (AUTomotive Open System ARchitecture) que proporciona un modelo de integración basado en componentes SW, separación temporal y espacial, numerosos mecanismos de seguridad, actualizaciones parciales a través del mecanismo de clústeres de software, etc.
El ECU SW comprende partes de múltiples partes interesadas, incluido el OEM (aplicación), el Nivel 1 (middleware e integración), el Nivel 2 (MCAL) y terceros (AUTOSAR BSW, SO, firmware de seguridad, etc.). La integración de una ECU con este conjunto de partes interesadas ya es una tarea de ingeniería importante en la actualidad. Es difícil ver cómo el mismo enfoque escalaría para una futura ECU de zona por varias razones: ¿Quién es responsable de integrar aplicaciones de múltiples proveedores? ¿Quién es responsable cuando falla una ECU? ¿Cómo se pueden mantener las barreras de seguridad en un sistema de múltiples ECU? ¿Cómo protegen la propiedad intelectual varios proveedores? ¿Quién realiza el análisis de causa raíz para la depuración? Finalmente, se requerirá un gran esfuerzo de volver a probar la ECU completa cuando cambie una pequeña parte.
Una solución a estos desafíos es usar un hipervisor para convertir una ECU física en varias ECU virtuales. En términos de AUTOSAR, cada ECU virtual es una ECU separada (con su propio EcuExtract) que se comunica con otras ECU virtuales a través de COM y una red virtual.
Esta solución permite que cada ECU virtual se integre conservando el acoplamiento flexible del modelo de integración de ECU establecido y brinda varias ventajas, una de las cuales es que cada VM se compilará y vinculará por separado, mientras que cada VM tiene su propio RTE. Los cambios en la configuración de un RTE no requieren que se reconstruya todo el sistema. Además, dichas máquinas virtuales tienen acceso completo y virtualizado al hardware del procesador. Además, los cambios en una VM no necesariamente requieren que se vuelva a probar todo el sistema, y una VM puede reiniciarse independientemente de todo el sistema, lo que minimiza el tiempo de inactividad de otras funciones (no relacionadas) en la misma ECU.
Arquitectura zonal – Soluciones HW: RH850/U2A y RH850/U2B
Las líneas de productos de microcontroladores de alto rendimiento RH850/U2x para ECU de integración/zona de última generación admiten un amplio conjunto de características clave de HW integradas que son específicas para las aplicaciones de zona. Además, una estructura NoC (Network on Chip) de alto rendimiento puede garantizar el comportamiento en tiempo real de cada aplicación integrada individualmente en relación con el acceso a la memoria y los periféricos.
La MCU (unidad de microcontrolador) RH850/U2A de Renesas está diseñada como una plataforma de dominio cruzado para aplicaciones de carrocería y chasis de alta gama para cubrir la creciente necesidad de integrar múltiples aplicaciones en un solo chip. Basado en la tecnología de proceso de 28 nm, el MCU RH850/U2A de 32 bits se basa en funciones clave de la serie RH850/Px de Renesas para el control del chasis y la serie RH850/Fx para el control del cuerpo para ofrecer un rendimiento mejorado.
La familia RH850/U2B se basa en las fortalezas del RH850/U2A y está diseñada para resolver los desafíos de las arquitecturas E/E innovadoras para las próximas generaciones de vehículos. Con sus nuevos niveles de rendimiento e integración de memoria de hasta 32 MB, el RH850/U2B se posiciona por encima de la serie RH850/U2A para cubrir los mayores requisitos de los futuros conceptos de plataforma de integración automotriz, al mismo tiempo que proporciona una solución MCU monolítica sensible al costo en comparación. a un sistema en chip (SoC).
Los MCU RH850/U2x están equipados con las últimas tecnologías de soporte de HW para facilitar la integración de múltiples particiones ASIL-D SW. La función de asistencia de Hypervisor HW hace posible ejecutar un sistema operativo de hipervisor de una manera de alto rendimiento (cambio rápido de contexto, concepto de interrupción HV). La calidad de servicio (QoS) proporciona funciones de control de latencia y regulación activa para todos los maestros de bus para garantizar que haya un ancho de banda mínimo disponible al evitar que un maestro de bus consuma todo el ancho de banda (disponible solo en RH850/U2B). La Unidad de protección de memoria (MPU) implementa una fina separación granular del acceso maestro del bus a la memoria y otros recursos. La función MPU va acompañada del concepto Guard. Aquí, un sistema de protección esclavo altamente flexible para la memoria y los módulos periféricos proporciona protección a nivel de recursos. Las funciones de seguridad adicionales incluyen múltiples señales de salida de error individuales para garantizar el tratamiento individual en un nivel de partición SW. Además, las múltiples instancias de los módulos lockstep AES128 garantizan una comunicación segura y segura sin conflictos y determinista. Para cubrir las actualizaciones inalámbricas (OTA) sin espera, la posibilidad de funcionamiento en segundo plano de los bancos flash individuales garantiza la actualización independiente de las particiones SW individuales.
Arquitectura zonal – Soluciones SW – RTA-HVR
El hipervisor de ETAS, RTA-HVR, proporciona el SW complementario al Renesas RH850/U2x HW para cumplir con los estrictos requisitos de seguridad y protección automotriz. RTA-HVR utiliza las funciones de virtualización de hardware de la familia Renesas RH850/U2x para crear varias máquinas virtuales. Cada VM tiene uno o más núcleos de CPU virtuales, una sección de espacio de memoria y un conjunto de periféricos.
Cada «invitado» de VM es una imagen de ECU compilable y flasheable de forma independiente que un tercero puede crear y enviar. RTA-HVR admite invitados de plataforma «bare metal» y AUTOSAR Classic.
RTA-HVR admite la asignación flexible de VM a núcleo de CPU física. Cuando una VM tiene acceso único a uno (o más) núcleos de CPU, no hay sobrecarga de programación de VM. Cuando varias máquinas virtuales comparten un núcleo de CPU, existe la opción de aplicar un programador rotatorio configurado estáticamente o un programador dinámico basado en reservas impulsado por interrupciones en segundo plano RH850/U2x.
RTA-HVR utiliza el concepto de protección y MPU para proporcionar aislamiento espacial entre las máquinas virtuales, dividiendo la memoria y el espacio periférico para cada máquina virtual.
Además, RTA-HVR proporciona un mecanismo llamado Extensión de dispositivo virtual (VDE), que permite a los integradores de ECU personalizar el enlace entre los periféricos virtuales y físicos para una ECU de zona específica. Los VDE proporcionan una forma segura de compartir periféricos entre máquinas virtuales (por ejemplo, cuando la cantidad de máquinas virtuales que necesitan un periférico supera la cantidad de periféricos físicos en el HW). Los ejemplos típicos aquí son los controladores de Ethernet, los módulos de seguridad HW y los perros guardianes, o para agregar canales CAN adicionales como se muestra en la figura a continuación:
Descripción general de la plataforma de soluciones de virtualización Zone-ECU
Para apoyar a los clientes de automoción en el desarrollo conceptual de Zone-ECU con un enfoque en la integración de múltiples aplicaciones, ETAS y Renesas han creado la plataforma de soluciones de virtualización de Zone ECU.
Esta plataforma combina las capacidades de HW RH850/U2x de Renesas con RTA-HVR de ETAS, un conjunto de VM, cada una de las cuales aloja una imagen de ECU utilizando la plataforma RTA-CAR de AUTOSAR Classic de ETAS y una herramienta de interacción alojada en PC.
La plataforma de solución de virtualización Zone-ECU proporciona un SW preconfigurado y preconstruido para MCU RH850/U2x como una plataforma de desarrollo fácil de iniciar. Contiene software de demostración, así como un entorno de referencia que permite a los clientes de la industria automotriz comenzar rápidamente con la exploración del diseño para sus proyectos individuales de Zone-ECU. La plataforma de solución de virtualización Zone-ECU permite a los clientes beneficiarse de un esfuerzo, costo y riesgo de desarrollo reducidos.
Plataforma de solución de virtualización Zone-ECU HW
Hay dos opciones de HW disponibles, como se muestra a continuación:
Software de plataforma de solución de virtualización Zone-ECU
La pila Zone-PoC SW comprende una configuración RTA-HVR y 4 máquinas virtuales. Cada máquina virtual se ha configurado para ejecutar un conjunto simple de SWC AUTOSAR en la pila completa de SW ETAS RTA-CAR AUTOSAR Classic. La comunicación entre máquinas virtuales utiliza VDE RTA-HVR para CAN virtual, vigilancia virtual y acceso al RH850/U2x.
RTA-HVR está configurado para mapear las máquinas virtuales en 3 configuraciones representativas diferentes. Estos comprenden: Partición A: 1 máquina virtual de un solo núcleo asignada a 1 núcleo de CPU; Partición B: 1 máquina virtual multinúcleo asignada a 2 núcleos de CPU; Partición C: 1 máquina virtual de un solo núcleo asignada a 1 núcleo de CPU compartido con la partición D; y, por último, Partición D: 1 máquina virtual de un solo núcleo asignada a 1 núcleo de CPU compartido con la partición C.
Se proporcionan 2 configuraciones alternativas de RTA-HVR que permiten explorar la diferencia en las políticas de programación de VM.
Plataforma de solución de virtualización Zone-ECU: herramientas de exploración de diseño
La plataforma de solución de virtualización Zone-ECU proporciona una aplicación alojada en PC que captura y muestra datos de estado de VM en tiempo real (consulte las figuras 6 y 8).
La ejecución de las diferentes políticas de programación de RTA-HVR proporcionadas permite una fácil integración del desarrollador con el HW y el SW integrados, al tiempo que permite la exploración de elementos como la inyección de fallas en las VM (por ejemplo, la violación del acceso a la memoria del desencadenador), el rendimiento y la temporización utilizando la instrumentación de la plataforma de solución de virtualización Zone-ECU. , así como las funciones HW del RH850/U2x (OTA, QoS, etc.)
Productos y requisitos previos de Zone-ECU Virtualization Solution Platform
La plataforma de solución de virtualización Zone-ECU se envía con el HW RH850/U2x de elección (ya sea el kit de inicio RH850/U2A o el Piggy board RH850/U2B), imágenes binarias compatibles con flash para RTA-HVR y cada VM, incluidas VM alternativas y compilaciones para explorar programación y flasheo en chip, así como con una herramienta de exploración de diseño alojada en PC.
Los usuarios que deseen obtener más información pueden solicitar una licencia de evaluación de 3 meses que cubra:
- Renesas RH850 MCAL y herramientas de configuración
- Herramientas de configuración y generación de código ETAS RTA-CAR
o ISOLAR-A para la configuración del sistema y software de aplicación
o ISOLAR-B para configuración básica de software
o RTA-RTE un generador de código para el AUTOSAR RTE
o RTA-OS, un generador de código para el sistema operativo AUTOSAR más pequeño y rápido, incluidas las adiciones específicas de destino para los dispositivos RH850/U2x
o RTA-BSW un generador de código para los módulos del software básico AUTOSAR, incluida la comunicación CAN
- Software prototipo RTA-HVR
- Todos los archivos de configuración, el código fuente y las secuencias de comandos del depurador para permitir que los usuarios amplíen y reconstruyan la Zone-ECU.
Otras herramientas necesarias son el compilador GreenHills RH850/U2x (2019.1.5) y los depuradores Lauterbach Trace32 o Renesas E2 para RH850/U2x, que deben obtenerse por separado.
Resumen / Perspectiva
La plataforma de solución de virtualización de Zone-ECU es un paquete integral para ayudar a los clientes a desarrollar, mostrar y comparar ECU que tienen como objetivo el desarrollo o la investigación de nuevas arquitecturas E/E.
