4

Easing automotive software migration - Automotive blog - Arm Community blogs -...

 6 months ago
source link: https://community.arm.com/arm-community-blogs/b/automotive-blog/posts/easing-automotive-software-migration
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Easing automotive software migration: From discrete ECUs to Zonal Controllers in emerging EE architectures

GettyImages_2D00_1465619757.jpg_2D00_900x506x2.jpg?_=638448832451400085
3 minute read time.

The automotive industry is on the cusp of seismic change. Multiple trends are occurring simultaneously that are impacting the entire supply chain of the industry. Software defined vehicles (SDVs), autonomy and electrification are motivating automotive OEMs to holistically rethink the vehicle’s software and hardware development cycles.

To better manage multiple compute elements and increasing software complexity along that includes support for over-the-air updates, there is a push towards revamping the vehicle architecture. Traditionally, discrete Electronic Control Units (ECUs) manage specific functions on the vehicle. These ECUs are then added to the architecture to continue adding new features and functions to the vehicle. However, this model is neither scalable nor suitable for SDVs, as it substantially increases the challenges of managing complex software and software updates.

As a result, there is a push towards a more centralized architecture. This means having discrete and spatially located ECUs managing multiple functions that are consolidated into fewer powerful zonal controllers that run multiple software workloads.

One of the key requirements to running multiple software workloads is ensuring freedom-from-interference (FFI) among the diverse software workloads. This is particularly important in the case where mixed-critical software is combined. For example, when there is a combination of quality managed, ASIL B or ASIL D level software components.

One way to achieve FFI is by sandboxing each software component into virtual machines isolated by a separation kernel. Armv8-R supports this feature by means of real-time virtualization. Through using a hypervisor, or simpler separation kernel, on Armv8-R based processors, like Cortex-R52 and Cortex-R52+, it is possible to achieve FFI among multiple software workloads.

Therefore, Cortex-R52 and Cortex-R52+ processors offer an ideal platform for building zonal controllers that can be useful for deploying multiple software workloads, which are currently running on discrete ECUs, many of which are based on Arm Cortex-M processors. For more information on virtualization supported by Armv8-R, please refer to the Best Practices for Armv8-R Cortex-R52+ Software Consolidation.

The push towards centralization in the architecture has also led to the growth of domain controller within vehicles. Domain controllers manage specific functions like digital cockpit, Advanced Driver Assistance Systems (ADAS), functional safety, gateway, body, and chassis. These controllers carry out compute-intensive tasks and connect to multiple I/Os or sensors.

The real-time high-performance offered by Cortex-R processors also make them ideal for use in domain controllers designs. The zonal controller functionality can be used in these designs, with the former carrying out the I/O aggregation while the domain controllers take care of the higher-level software tasks.

Going forward, Arm Cortex-R will play a vital role in the automotive designs that will increasingly use domain and zonal controllers. The automotive industry, which includes OEMs, Tier1s, and software and tools providers, will look for ways to seamlessly migrate their existing software from Cortex-M based designs onto Cortex-R52 and Cortex-R52+ based designs. To help ease this need, Arm has created a software migration guide that offers guidance on migrating existing software for Cortex-M Armv7-M based designs onto Cortex-R Armv8-R based designs.

At a high-level, the guide compares the Armv7-M and Armv8-R architectures and offers guidance on how software can be migrated from Cortex-M based designs to Cortex-R52 and Cortex-R52+ based designs. The guide covers the following topics.

  • Instruction set
  • Register set
  • Exception model
  • Interrupts
  • Virtualization
  • System registers
  • Memory model
  • Tools
  • Startup

The move towards a zonal architecture does not discount the importance of standalone ECUs, and the use of the many widely available Arm Cortex-M-based microcontrollers (MCUs), in vehicles. As noted by my colleague James Scobie in this blog, Cortex-M-based MCUs are set to play a defining role in  automotive compute platforms. These MCUs will be the enablers of remote edge sensing points, controlling specific operations within the vehicle with low power and high efficiency, and fit within the new software architecture of SDVs.

However, the new guide is useful for partners looking to reuse their existing software in Zonal controllers and also those with new projects using Cortex-M and/or Cortex-R based designs.

Learn more by reading: Software Migration Guide – Armv7-M to Armv8-R.

This blog is written by Prakash Mohapatra, Senior Product Manager, Automotive.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK