Image
Sam Gold
Sam Gold
Senior Manager, Automotive Digital Marketing at Renesas Electronics Europe
Image
Darren Buttle
Darren Buttle
Head of RTA Solutions at ETAS Germany
Published: April 28, 2022

Introduction

The advancing trend from traditional vehicle design towards CASE, 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.

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

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

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

One key challenge in the transition to CASE is thus how do more without increasing the number of physical ECUs. The key to solving this challenge lies in a new software 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 software meaning a migration from their existing federated E/E architectures, where one ECU corresponds to one vehicle function, to the Zone architecture.

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 AUTomotive Open System ARchitecture (AUTOSAR) Classic software architecture which provides a software component-based integration model, temporal and spatial separation, numerous mechanisms for safety and security, partial updates via the software clusters mechanism, etc.

The ECU software comprises parts from multiple stakeholders including the OEM (application), Tier 1 (middleware and 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 the 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 established 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, minimizing the downtime of other (un-related) functions on the same ECU

Zonal Architecture – Hardware Solutions: RH850 U2A/U2B

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

Renesas’ RH850/U2A MCU (microcontroller unit) is designed as a 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 28nm 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.

Image
RH850/U2A block diagram
Figure 3. RH850/U2A block diagram

The 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).

Image
RH850/U2B Block Diagram
Figure 4. RH850/U2B Block Diagram

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

  • Hypervisor hardware-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 software-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 software-partitions

Zonal Architecture – Software Solutions – RTA-HVR

ETAS’ hypervisor, RTA-HVR, provides the complimentary software to the Renesas RH850/U2x hardware 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 flashable 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 hardware). Typical examples here are Ethernet controllers, hardware security modules and watchdogs or to add additional CAN channels as shown in the figure below:

Image
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

Zone-ECU Virtualization Solution Platform Overview

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

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

Image
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 software for RH850/U2x MCUs as an easy-to-start development platform, containing a demonstrator software 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.

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 a “software-first” Renesas Winning Combination in April 2022

Share this news on