Introduction
The trend of advancing traditional vehicle design towards CASE, the acronym representing the key automotive themes of Connectivity, Autonomous, Sharing, Electrification of the vehicle of the future, requires exponential growth in overall computing performance and load communication inside the car.
To realize the CASE approach, the necessary computing power and network complexity cannot be achieved with conventional E/E architectures in an economically reasonable manner. This is because the distributed E/E structure would require a significantly higher number of ECUs (Electronic Control Units), a corresponding increase in both wire harness complexity and weight, higher overall power consumption, and cost higher.
Therefore, a key challenge in the transition to CASE is how to do more without increasing the number of physical ECUs. The key to solving this challenge lies in a new software architecture supported by capable, yet still cost-effective hardware solutions.
Automakers developing new zone ECUs without the current limitations can adopt a domain/zone architecture from the start. In practice, however, many car manufacturers do not start from a "green field" and need to preserve existing investments in SW ECUs. This involves a migration from their existing federated E/E architectures, where an ECU corresponds to a vehicle function, to the Zone architecture.
A change in architecture and supporting technologies always presents new design trade-offs that need to be explored. The key challenges are defining which ECUs need to be added and where in the SW architecture the aggregation should occur. Also, what level of separation is required between software from different parties (OEM, T1, third party) or SW of different levels of functional security. Finally, you must decide where to reuse existing software and where to take advantage of the reengineering opportunity.
Choices are fundamentally influenced by planned and legacy SW workloads, supply chain structure, post-production maintenance policies, etc. demonstrator.
The following sections take a closer look at the complementary HW and SW technologies that allow building a Domain/Zone architecture and present a Zone-PoC demonstrator.
Challenges of Zonal architecture
A zone-oriented architecture drives the integration of numerous functions and services into an ECU. The network concept must cope with the increased demands associated with bandwidth, determinism, and maximum latency. Such zone controllers, depending on their primary design goal as traffic manager, embedded real-time processor, or application processors/service provider, have an obvious need for high computing power to perform multiple functions in parallel. On the other hand, they must also guarantee the absence of interference between concurrent applications for security reasons and preserve real-time behavior in case such a requirement is applied.
Most modern ECUs will run the classic AUTOSAR (AUTomotive Open System ARchitecture) software architecture which provides an integration model based on SW components, temporal and spatial separation, numerous security mechanisms, partial updates via the software clustering mechanism , etc.
The ECU SW comprises parts from multiple stakeholders, including the OEM (application), Tier 1 (middleware and integration), Tier 2 (MCAL) and third parties (AUTOSAR BSW, OS, security firmware, etc.). Integrating an ECU with this set of stakeholders is already a major engineering task today. It's hard to see how the same approach would scale for a future zone ECU for several reasons: Who is responsible for integrating multi-vendor applications? Who is responsible when an ECU fails? How can safety barriers be maintained in a multi-ECU system? How do various vendors protect intellectual property? Who performs root cause analysis for debugging? Finally, it will take a lot of effort to retest the entire ECU when you change a small part.
One solution to these challenges is to use a hypervisor to convert one physical ECU into multiple virtual ECUs. In AUTOSAR terms, each virtual ECU is a separate ECU (with its own EcuExtract) that communicates with other virtual ECUs via COM and a virtual network.
This solution allows each virtual ECU to be integrated while retaining the loose coupling of the established ECU integration model and provides several advantages, one of which is that each VM will be compiled and linked separately, while each VM has its own RTE. Changes to the configuration of an RTE do not require the entire system to be rebuilt. In addition, such virtual machines have full, virtualized access to the processor hardware. Also, changes to a VM do not necessarily require the entire system to be retested, and a VM can be rebooted independently of the entire system, minimizing downtime of other (unrelated) functions on the same ECU.
Zonal architecture – HW solutions: RH850/U2A and RH850/U2B
The RH850/U2x high-performance microcontroller product lines for next-generation zone/integration ECUs support a rich set of key embedded HW features that are specific to zone applications. In addition, a high-performance NoC (Network on Chip) structure can guarantee the real-time behavior of each individually embedded application regarding access to memory and peripherals.
The Renesas RH850/U2A MCU (Microcontroller Unit) is designed as a cross-domain platform for high-end body and chassis applications to meet the growing need to integrate multiple applications on a single chip. Based on 28nm process technology, the RH850/U2A 32-bit MCU builds on key functions from Renesas' RH850/Px series for chassis control and RH850/Fx series for body control to deliver a improved performance.
The RH850/U2B family builds on the strengths of the RH850/U2A and is designed to solve the challenges of innovative E/E architectures for the next generations of vehicles. With its new levels of performance and memory integration of up to 32 MB, the RH850/U2B positions itself above the RH850/U2A series to meet the increased requirements of future automotive integration platform concepts, while providing a cost sensitive monolithic MCU solution in comparison. to a system on chip (SoC).
RH850/U2x MCUs are equipped with the latest HW support technologies to facilitate the integration of multiple ASIL-D SW partitions. The Hypervisor HW support feature makes it possible to run a hypervisor operating system in a high-performance manner (fast context switching, HV interrupt concept). Quality of Service (QoS) provides latency control and active throttling features for all bus masters to ensure that a minimum bandwidth is available by preventing one bus master from consuming all the bandwidth (available only on RH850 /U2B). The Memory Protection Unit (MPU) implements a fine granular separation of the bus master access to memory and other resources. The MPU function is accompanied by the Guard concept. Here, a highly flexible slave protection system for memory and peripheral modules provides protection at the resource level. Additional security features include multiple individual error output signals to ensure individual treatment at a SW partition level. In addition, the multiple instances of the AES128 lockstep modules ensure safe and secure communication without conflicts and determinism. To cover over-the-air (OTA) updates without waiting, the ability to run in the background of individual flash banks ensures independent updating of individual SW partitions.
Zonal Architecture – SW Solutions – RTA-HVR
ETAS' hypervisor, RTA-HVR, provides the complementary SW to the Renesas RH850/U2x HW to meet stringent automotive safety and security requirements. RTA-HVR uses the hardware virtualization features of the Renesas RH850/U2x family to create multiple virtual machines. Each VM has one or more virtual CPU cores, a section of memory space, and a set of peripherals.
Each VM "guest" is an independently flashable and buildable ECU image that can be created and shipped by a third party. RTA-HVR supports bare metal platform guests and AUTOSAR Classic.
RTA-HVR supports flexible mapping of VM to physical CPU core. When a VM has unique access to one (or more) CPU cores, there is no VM scheduling overhead. When multiple virtual machines share a CPU core, there is the option of applying a statically configured rotary scheduler or a dynamic reservation-based scheduler driven by RH850/U2x background interrupts.
RTA-HVR uses the concept of shielding and MPU to provide spatial isolation between virtual machines, dividing memory and peripheral space for each virtual machine.
Additionally, RTA-HVR provides a mechanism called Virtual Device Extension (VDE), which allows ECU integrators to customize the link between virtual and physical peripherals for a specific zone ECU. VDEs provide a secure way to share peripherals between virtual machines (for example, when the number of virtual machines that need a peripheral exceeds the number of physical peripherals on the HW). Typical examples here are Ethernet controllers, HW security modules and watchdogs, or to add additional CAN channels as shown in the figure below:
Zone-ECU Virtualization Solutions Platform Overview
To support automotive customers in the conceptual development of Zone-ECUs with a focus on multi-application integration, ETAS and Renesas have created the Zone-ECU Virtualization Solutions Platform.
This platform combines Renesas RH850/U2x HW capabilities with ETAS RTA-HVR, a set of VMs each hosting an ECU image using ETAS AUTOSAR Classic RTA-CAR platform and an interaction tool hosted on PC.
Zone-ECU Virtualization Solution Platform provides pre-configured and pre-built SW for RH850/U2x MCUs as an easy-to-start development platform. It contains demo software as well as a reference environment that allows customers in the automotive industry to quickly get started with design exploration for their individual Zone-ECU projects. The Zone-ECU virtualization solution platform enables customers to benefit from reduced development effort, cost, and risk.
Zone-ECU HW Virtualization Solution Platform
There are two HW options available, as shown below:
Zone-ECU Virtualization Solution Platform Software
The Zone-PoC SW stack comprises an RTA-HVR configuration and 4 virtual machines. Each virtual machine has been configured to run a simple set of SWC AUTOSAR on the full stack of SW ETAS RTA-CAR AUTOSAR Classic. Communication between virtual machines uses VDE RTA-HVR for virtual CAN, virtual surveillance, and access to the RH850/U2x.
RTA-HVR is configured to map the virtual machines in 3 different representative configurations. These comprise: Partition A: 1 single-core virtual machine assigned to 1 CPU core; Partition B: 1 multicore virtual machine assigned 2 CPU cores; Partition C: 1 single-core virtual machine assigned to 1 CPU core shared with partition D; and finally, Partition D: 1 single-core virtual machine assigned to 1 CPU core shared with partition C.
2 alternative RTA-HVR configurations are provided to allow you to explore the difference in VM scheduling policies.
Zone-ECU Virtualization Solution Platform - Design Exploration Tools
The Zone-ECU Virtualization Solution Platform provides a PC-hosted application that captures and displays real-time VM status data (see Figures 6 and 8).
Execution of the different RTA-HVR scheduling policies provided allows for easy developer integration with embedded HW and SW, while allowing exploration of elements such as fault injection into VMs (for example, breach of the trigger memory access), performance, and timing using Zone-ECU virtualization solution platform instrumentation. , as well as the HW functions of the RH850/U2x (OTA, QoS, etc.)
Zone-ECU Virtualization Solution Platform Products and Prerequisites
The Zone-ECU Virtualization Solution Platform ships with the RH850/U2x HW of choice (either the RH850/U2A Starter Kit or the RH850/U2B Piggy board), flash-compatible binary images for RTA-HVR and each VM , including alternate VMs and builds to explore programming and on-chip flashing, as well as with a PC-hosted layout exploration tool.
Users who want more information can request a 3-month evaluation license that covers:
- Renesas RH850 MCAL and configuration tools
- ETAS RTA-CAR code generation and configuration tools
o ISOLAR-A for system configuration and application software
o ISOLAR-B for basic software configuration
o RTA-RTE a code generator for the AUTOSAR RTE
o RTA-OS, a smaller and faster AUTOSAR operating system code generator, including target-specific additions for RH850/U2x devices
o RTA-BSW a code generator for AUTOSAR basic software modules, including CAN communication
- RTA-HVR prototype software
- All configuration files, source code and debugger scripts to allow users to extend and rebuild the Zone-ECU.
Other required tools are the GreenHills RH850/U2x compiler (2019.1.5) and the Lauterbach Trace32 or Renesas E2 debuggers for RH850/U2x, which must be obtained separately.
Summary / Perspective
Zone-ECU Virtualization Solution Platform is a comprehensive package to help customers develop, display and compare ECUs that are aimed at developing or researching new E/E architectures.
