extra

Seen Holistically in theDevelopment Process

E/E DESIGNC OVER STORY

E / E Architecture

Real-time Software
Enablement in Zonal Controllers
In future zonal E/E architectures, dedicated ECUs will handle the interzonal communication ofdata as well as its uplink to the central compute. Arm describes the consolidation of real-time
software as an important requirement – also for Safety Islands in heterogeneous system-on-chip
designs, such as in cockpit assemblies or ADAS.

2W R I TT E N BY

Bernhard Rillis director of automotive­p artnerships in the EMEA
region of Arm in Munich.

James Scobie
is director of productmanagement within Arm`s
Automotive Line of Businessin Cambridge (UK).

© top images | adobe.stock.com | ATZelektronikg The automotive industry is cur-rently experiencing a disruptive period.
New ADAS features – and the generalmove towards autonomous driving –are significantly increasing the number of functions in vehicles. Consumer
electronics, such as the cell phone, areinfluencing consumer needs in the car,which, like the smartphone, is expected
to update and improve over its lifetime

from the end user’s perspective. This iscreating the stimuli for the automotive
world to move towards the Software-­Defined Vehicle (SDV). The rise of SDVs
and ever-evolving consumer demands
are going hand-in-hand with – and often
driving – the changes in E/E architecturein the vehicle.
These architectures are migratingfrom the traditional distributed ap­­

proach for ECUs through the current state-of-the-art domain controller
architecture to, ultimately, a zonal­a rchitecture with high-performance­central ­pro­cessing ­systems. One clear
goal of this architectural change is tominimize the absolute number of ECUs.
The software-defined functions will belocated in the central compute units,
and the zonal controller platforms

3

C OVER STORY

E / E Architecturei­ mplement the signal-to-­service con­version in order to abstract sensor and­actuator data.
Arm addresses the automotive sector
with a dedicated IP product line. This
includes the Cortex-A computing coresfor the highest performance requirements,-R for real-time and safety applications,and -M for highly efficient functions,particularly in microcontrollers. They
are used in current ECUs but are alsocapable of enabling both domain andzonal architectures.
From a software enablement per­spec­
tive, there is a broad trend towards de­­velopment in the cloud, often referred
to as cloud-native, but always aimed
at deployment on an embedded system in the vehicle. Software enablement in vehicles is addressed by theSOAFEE initiative in collaboration
between automotive and semicon­
ductor manufacturers, open source
and independent software and cloud­providers [1].
REAL-TIME SOFTWAREINTEGRATION OPTIONS

Automotive systems are frequently
built with real-time operating sys­­tems
using Autosar APIs, both in classic

FIGURE 1 Automotive compute scalability (© Arm Ltd)

4and adaptive forms as their standard
software stack. However, there arealso other ­real-time operating systems
that are used and deployed in automotive systems (e.g. Green Hills Software,uVelosity, Integrity, Blackberry QNX,
ESol, Windriver VXworks, Zephyr, etc.).
­Furthermore, there are simple bare metal
applications that directly run without
any abstraction level.
Automotive real-time software inte­
gration can be deployed across a diverse
range of compute platforms. These range
from simple MCUs to highly complex
Systems-on-Chip, FIGURE 1.
However, automotive compute scalability faces some challenges. Due tothe recent chip shortage, it has been­difficult for OEMs to maintain supplyof various parts needed in vehicles
today. In particular, sourcing existing
8-bit/16-bit compute platforms has
been difficult, and if available, they
have been relatively expensive. To
ensure supply stability and the continued availability of the ­silicon, OEMs
are migrating their legacy software topower-efficient 32-bit compute basedon Arm Cortex-M processors, forexample.
This is part of a wider trend to upliftlegacy software to 32-bit compute, as

it provides both access to a common
compute platform and security of supply through availability from multiple
semiconductor vendors that offer Armbased MCUs. Integration of 8-bit/16-bit
applications can be done with either
simple proprietary Real-Time Operating Systems (RTOS) or classic Autosar
software stacks.
Additionally, OEMs want to design
their system in a way that gives them
freedom to deploy software functions
variably depending on available compute resources and according to theirtiming behavior. This is summarizedunder the term portability/consoli­
dation. When it comes to these realtime s­ oft­­ware integration principles, ­cohe­­­­­­sion and separation have to be
distinguished:– Cohesion refers to applications thatare closely related, rely on strong­coordination and share a common
development base, with example
implementations including ClassicAutosar featuring the platform flexi­
bility principle – the binary updateof software components – and Autosar
CP-Flex with Logical Timing Extension (LTE) integration.
– Separation, like Exception Level 2(EL2) separation, applies to distinct

FeatureClassic Autosar

EL2 separation

Architectural
freedom

Integration options are based on classic Autosar options(e.g. FlexCP), normally a software stack is pinned to (a) CPU(s)EL2 separation allows to host several virtual machines
within a cluster or even a CPU (with additional scheduling­mechanisms). The toolchain needs to be enhanced though(no standardization as of now)

System supervision/
exception handlingSupervision opportunities minimized as there is noEL2 ­exception levelEL2 separation allows hierarchical supervision(e.g. independent shutdown/restart of VMs)

Heterogenous SW
platforms support

All software artefacts should at least support similar
Autosar architecture features. Preferably they are of
the same classic Autosar version

Different software stacks (e.g. classic Autosar with different
versions and different suppliers, bare metal code, FreeRTOS,etc.) can be integrated

Memory requirements

Every stack maintains the existing memory footprint as
part of the Basic Software (BSW) stack architecture

Potential optimization of duplicated BSW software components(e.g. communication stacks)

Software suppliers

Integration is expected to be limited to one classic
Autosar vendor (detailed analysis needs to follow)

Flexible model allows sourcing from different software vendors

Toolchain

Classic Autosar has a well-established mature toolchain. Testing is done as a single monolithic system

EL2 separation integration toolchain needs to be established,further standardization is beneficial. Integration and Testing
can be done at VM level granularity

TABLE 1 Cohesion and separation – comparing the characteristics of consolidation options (© Arm Ltd)

workloads that are developed separately and therefore built on independence as a principle. The overall aim
is to reduce ECU count. The software
stacks used in the separate integrations may still use common implementations like Classic Autosar, but mustremain independent.
EL2 SEPARATIONWITH MICROCONTROLLER
HYPERVISOR

Cohesion and separation integration
options commonly support Freedom
From Interference (FFI) from both a­spatial and temporal perspective, withindividual software updates possiblefor dedicated building blocks.
TABLE 1 helps understand some ofthe differences between the cohesion
and the separation integration options.
It is up to the integrator to decide whichconsolidation option is most suitable.
In the next section, we focus on EL2­separation, which is supported by theArmv8-R architecture.

and a two-stage MPU ensuring the­real-time characteristics of the processor, F­ IGURE 2.
In a fully virtualized system with­Virtual Memory System Architecture(VMSA), the software can be developed
without any knowledge of other VMs.
However, this approach can result inthe loss of determinism. Within the
Armv8-R architecture, the sep­a ration
offered with the PMSA solution canmaintain real-time deter­minism butrequires users to be aware of otherVMs. Furthermore, access to sharedresources should be orchestrated.

Armv8-R CPUs support this realtime virtualization capability, with­Cortex-R52+ offering additional visibility to a system of more transactions inorder to enhance control of the resourcesin a virtualized system.
Within state-of-the-art automotive s­ ilicon designs, the existing
Armv8-R products (Cortex-R52 andCortex-R52+) are integrated in two
different types:– Cortex-R class, which is the primaryprocessor within designs that can bereferred to as MCUs
– Armv8-R CPUs, which are used for

CORTEX-R IN
AUTOMOTIVE SYSTEMS

The introduction of the Armv8-R­a rchitecture was the first to enable
the hardware separation of tasks into
Virtual Machines (VMs), which can­represent multiple independent guests.
The approach is based on Physical­Memory System Architecture (PMSA)
using additional exception levels

FIGURE 2 Armv8-R Cortex-R exception levels (© Arm Ltd)5C OVER STORY

E / E Architecture

Application typeInterrupt virtuaIization

Virtual processor coresPara-virtualization/
trap-and-emulate

Example applications

Ultra-low latency
hard real-timeNoNo

Yes, if the application allows

Powertrain, braking

Low-latency hard
real-timeYes, dynamic scheduling
may be needed

Yes, dynamic scheduling
may be needed

Yes, if the application allows

Other chassis

Latency focusedreal-time

Yes

Yes

Yes, if the application allows

General body functions (e.g.
­immobilizer, ambient lighting, etc.)

Best effort

Yes

Yes

Yes

Convenient body functions(e.g. road noise suppression)

TABLE 2 Integration of real-time software functions based on EL2 separation. Applications with the respective Armv8-R separation technology (© Arm Ltd)the real-time compute and within the socalled Safety Island of heterogenous
SoC (System-on-Chip) designs, withan­­­­­­other CPU block in the designthat is responsible for the high-per­formance compute tasks.
Based on the versatility of the
Armv8-R CPUs, a very flexible deployment of s­ oft­ware artefacts is possible.
Since the Arm IP is widely used invarious SoC designs, there are now
many software ecosystem partners
that have developed products forArmv8-R CPUs. These in­c lude Etas,
Elektrobit, OpenSynergy, Green Hills
Software, Kernkonzept, V­ ector, andSysgo.
To better understand the EL2 separation options, Arm has released a whitepaper titled ‘Best practices for Armv8-R

FIGURE 3 Potential zonal-controller use cases for SOP 2028 (© Arm Ltd)

6

Cortex-R52 software consolidation’with ETAS. The white paper is available for download at [2].
The paper conveys an overview
of how the integration of real-time­software functions based on EL2­separation can be achieved. FIGURE 4
shows ­relevant applications and theArmv8-R separation technique usedin each case.

Arm has published another whitepaper that focuses on device assignment,
including how on-chip modules - suchas communications peripherals, memoryor hardware security modules - can be
assigned to individual independent
guests and virtual machines [3].

USE CASES 2025
AND 2028 OUTLOOKAfter considering all the integration
options for software consolidation, thequestion is which use cases and scenarios OEMs want to consolidate. Startingfrom 2025, many leading OEMs will

move to a zone-based EE architecture.
This move will be driven by the factthat the wiring harness is too complex
and needs to be split into multiple spatial areas. Once this is done, the Zonal-­
Controller platforms are important toensure highly efficient networking,such as converting CAN, LIN or Flexray to Ethernet, and to direct intelligent power – via smart fuses – to theappropriate area of the car. M­ ore­­over,the p­ latforms are used to drive some
simple I/O-related body funtions
based on 32-bit classic Autosar appli­cations.
Zonal-Controller platforms are a­perfect transition point from signal-­

The Futureof Automotive
is Built on Armarm.com

based to service-based communications. Currently, the industry is investigating how to use Zonal-Controller platforms for a Start of Production (SOP)
2028. Next to the network and simple
IO abstraction applications mentioned
above, investigations are focused on
three additional areas, FIGURE 3:– Pre-processing of sensor data
– Integration of high-integrity
chassis functionality– Cabin-/interior-driven use cases.
Aside from the SOP-2028 timeframe,
the authors see further func­tionality
requirements that need to be hosted
in the Cortex-R-based Safety Island ofheterogenous SoCs, F­ IGURE 4.

C OVER STORYE / E Architecture

FIGURE 4 Potential Safety Island SOP 2028 use cases (© Arm Ltd)SUMMARY

This outlook on the future of E/E architecture development emphasizes theneed for further real-zonal software in­­tegration; a focus on zone controllers
and the Safety Islands of heterogeneous
SoCs. The Armv8-R CPU family is prominently used in this compute class. Invest­­­ment in this product line will help drive
software reuse across current and future
platforms over the long term. As the auto­­motive industry moves towards SDVs
and ever more complex compute requirements, Arm see their commitment to thedevelopment of this product line as being

IMPRINTSpecial Edition 2023 in cooperation with Arm,110 Fulbourn Road, Cambridge, UK; Springer Fachmedien
Wiesbaden GmbH, Postfach 1546, 65173 Wiesbaden,
Amtsgericht Wiesbaden, HRB 9754, USt-ldNr. DE81148419

8

particularly important for future automotive platforms.
REFERENCES[1] Scalable Open Architecture for Embedded Edge
(SOAFEE) project; https://www.soafee.io/; access:April 12, 2023
[2] Paul Austin, Andrew Coombes,Paul Hughes,
James Scobie, Bernhard Rill: Best practices forArmv8-R Cortex-R52+ software consolidation; Arm/
Etas White Paper, https://armkeil.blob.core.windows.net/developer/Files/pdf/white-paper/bestpractices-for-armv8-r-cortex-r52-st2-whitepaper.
pdf; access: April 12, 2023
[3] Alexandre Romana: Introducing device virtualization principles for real-time systems; Arm White Paper,https://community.arm.com/arm-community-­blogs/b/
automotive-blog/posts/device-virtualization-­principlesfor-real-time-systems; access: April 13, 2023

MANAGING DIRECTORS:
Stefanie Burgmaier | Andreas Funk | Joachim Krieger
PROJECT MANAGEMENT: Anja Trabusch

COVER PHOTO:© [top images | adobe.stock.com | ATZelektronik