Darren Buttle
Darren Buttle
Head of RTA Solutions at ETAS Germany
Sam Gold
Sam Gold
Senior Manager, Automotive Digital Marketing at Renesas Electronics Europe

1.1 Introduction

The advancing trend from traditional vehicle design towards C.A.S.E., the acronym standing for Connectivity, Autonomous, Sharing, Electrification of the future vehicle, requires an exponential growth of overall calculation performance and communication load within the car.

CASE: Connected, Autonomous, Shared, Electric vehicle
Figure 1 CASE: Connected, Autonomous, Shared, Electric vehicle

To realize the C.A.S.E. approach, the necessary computing power and networking complexity cannot be achieved with conventional EE-architectures in an economically reasonable way because the distributed EE-structure would require a significantly larger number of ECUs (Electronic Control Units), a corresponding increase in both the complexity and weight of the cable harness, increased overall power consumption, and higher cost.

E/E architecture today and tomorrow
Figure 2 E/E architecture today and tomorrow

One key challenge in the transition to C.A.S.E is thus how do more without increasing the number of physical ECUs. The key to solve this challenge lies on new SW Platform supported by Hardware.

Automakers developing new, legacy-free, Zone ECUs can adopt a Domain/Zone architecture from the start. In practice however, many automakers are not starting from a “green field” and need to preserve existing investments in ECU SW meaning a migration from their existing federated EE architectures, where one ECU corresponds to one vehicle function, to the Zone architecture.

1.2 Challenges of the Zonal architecture

A Zone-oriented architecture moves the integration of numerous functions and services into one ECU. The network concept must deal with the associated higher demands for bandwidth, determinism, and maximum latency, and the Zone-related ECUs, depending on their role as Zone-aggregator, -controller or -processor, have an obvious need for high computing performance to run multiple functions. On the other hand they must also ensure freedom from interference between concurrent applications for safety and security, preserve real-time behavior and support internal network routing acceleration.

Most modern ECUs will be running the AUTOSAR (AUTomotive Open System ARchitecture) Classic Software Architecture which provides a SW component-based integration model, temporal and spatial separation, numerous mechanisms for safety and security, partial updates via the software clusters mechanism etc.

The ECU SW comprises parts from multiple stakeholders including the OEM (application), Tier 1 (middleware & integration), Tier 2 (MCAL) and 3rd parties (AUTOSAR BSW, OS, Security firmware, etc.). Integrating an ECU with this set of stakeholders is already a significant engineering undertaking today. It is difficult to see how the same approach scales for a Zone ECU for a number of reasons:

  • Who is responsible for integrating applications from multiple vendors?
  • Who is liable when ECU fails? How to retain security barriers of a multiple ECU system? How do multiple vendors protect IP?
  • Who performs root cause analysis for debugging?
  • High re-testing effort of the complete ECU when one tiny part changes

A solution to these challenges is to use a hypervisor to turn 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 as today by preserving the loose coupling of the establish ECU integration model and provides the following advantages:

  • Each VM is compiled and linked separately
  • Each VM has its own RTE. Changes in one RTE configuration do not require the whole system to be rebuilt.
  • Each VM has full, virtualized access to the processor hardware
  • Changes to one VM do not necessarily need the whole system to be retested
  • One VM can be re-started independently of the whole system, minimising the downtime of other (un-related) functions on the same ECU

1.3 Zonal architecture – HW solutions: RH850 U2A/U2B

The RH850/U2x high performance Microcontroller product lines for next generation Zone/Integration-ECUs support a rich set of embedded HW key-features which are specific for Zone-applications, such as Hypervisor HW-support, Quality-of-Service (U2B only), Safety & Security functions to enable freedom from interference. On top, a high-performance NoC (Network on Chip) structure can ensure real-time behavior of each individually integrated application concerning peripheral and memory access.

Renesas’ RH850/U2A MCU (Micro Controller Unit) is designed as cross-domain platform for high-end body and chassis applications to cover the growing need to integrate multiple applications into a single chip. Based on 28 nm process technology, the 32-bit RH850/U2A MCU builds on key functions from Renesas’ RH850/Px Series for chassis control and RH850/Fx Series for body control to deliver improved performance.

RH850/U2A block diagram
Figure 3 RH850/U2A block diagram

RH850/U2B family builds on the strengths of the RH850/U2A and is tailored to solve the challenges of innovative E/E architectures for the upcoming vehicle generations. With its new levels of performance and memory integration of up to 32MB the RH850/U2B is positioned above the RH850/U2A Series to cover the increased requirements of future automotive integration platform concepts while still providing a cost sensitive monolithic MCU solution in comparison to a System-on Chip (SoC).

RH850/U2B Block Diagram
Figure 4 RH850/U2B Block Diagram

The RH850/U2x MCUs are equipped with the latest HW-support technologies to realize the integration of multiple ASIL-D SW-partitions:

  • Hypervisor HW-assist function to enable a Hypervisor-OS in a high-performance manner (fast context switching, HV interrupt concept)
  • Quality of Service (QoS): Latency monitoring and active regulation functions for all bus masters to ensure minimum bandwidth is available by preventing a bus master from consuming all the bandwidth (U2B only).
  • Memory Protection Unit (MPU): Fine granular separation of bus master access to memory and other resources
  • Guard concept: Highly flexible slave protection system for peripheral memory and peripheral modules
  • Safety: Multiple individual Error output signals to ensure individual treatment on a SW-partition level
  • Security: Multiple instances of AES128 lockstep modules for conflict-free and deterministic secure and safe communication
  • No-wait OTA: Background operation on flash banks to ensure independent update of individual SW-partitions

1.4 Zonal architecture – SW solutions – RTA-HVR

ETAS’ hypervisor, RTA-HVR, provides the complimentary SW to the Renesas RH850/U2x HW to meet strict automotive safety and security requirements. RTA-HVR uses the hardware virtualization features of the Renesas RH850/U2x family to create multiple VMs. 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 compliable and flash-able ECU image that can be built and shipped by a 3rd party. RTA-HVR supports “bare metal” and AUTOSAR Classic platform guests.

RTA-HVR supports flexible VM to physical CPU core allocation. When a VM has unique access to one (or more) CPU cores then there is zero VM scheduling overhead. When multiple VMs share a CPU core, a choice of either:

  • A statically configured round-robin scheduler; or
  • A dynamic reservation-based scheduler driven by RH850U2x background interrupts.

RTA-HVR uses the MPU and guard concept to provide spatial isolation between VMs, partitioning the memory and peripheral space for each VM.

In addition, RTA-HVR provides a mechanism called “Virtual Device Extension” (VDE) allowing ECU integrators to customize the binding between virtual and physical peripherals for a specific Zone ECU. VDEs provide a safe way to share peripherals between VMs (e.g. when the number of VMs needing a peripheral exceeds the number of physical peripherals in the HW). Typical examples here are ethernet controller, HW security modules and watchdogs or to add additional CAN channels as shown in the figure below:

VDEs also allow the creation of fully virtual peripherals devices for optimized inter-VM communication channels
Figure 5 VDEs also allow the creation of fully virtual peripherals devices for optimized inter-VM communication channels

1.5 Zone-ECU Virtualization Solution Platform Overview

To support automotive customers for the conceptual Zone-ECU development with focus of integrating multiple applications, ETAS and Renesas have realized the Zone-ECU Virtualization Solution Platform.

This platform combines Renesas’ RH850/U2x HW capabilities with ETAS’ RTA-HVR, a set of VMs each of which host an ECU image using ETAS’ RTA-CAR AUTOSAR Classic Platform and a PC-hosted interaction tool.

Zone-ECU Virtualization Solution Platform Laboratory setup
Figure 6 Zone-ECU Virtualization Solution Platform Laboratory setup

The Zone-ECU Virtualization Solution Platform provides a pre-configured and pre-built SW for RH850/U2x MCUs as an easy-to-start development platform, containing a demonstrator SW as well as a benchmark environment that enables automotive customers to quickly start with design exploration for their individual Zone-ECU projects. The Zone-ECU Virtualization Solution Platform allows customers to benefit from reduced development effort, cost and risk.

2. Summary / Outlook

  • The Zone-ECU Virtualization Solution Platform is a comprehensive package to support customers to develop, showcase and benchmark ECUs targeting new E/E architecture development or investigation.
  • Zone-ECU Virtualization Solution Platform will be released as “SW-first” Renesas Winning Combination in April 2022

Share this news on

Log in or register to post comments