Latest News / October ‘24 / Join our panel discussion at the UXL Foundation's oneAPI DevSummit 2024 this week!

Autoware to Demystify the Software-Defined Autonomous Mobility

Author: SAMET KUTUK
Autoware to Demystify the Software-Defined Autonomous Mobility

Torque and horsepower are no longer what define automobiles, but the automobile’s innovative personalization features, intelligent connectivity solutions, and ever-improving safety capabilities. We have to thank the modern and elastic automotive software for this.

Since the arrival of mobile phones into our lives, people have gotten used to downloading and using new mobile phone applications to entertain, relax and nurture themselves, as well as receiving frequent software updates to fix bugs, optimize performance or get a refreshed feeling by acquiring a new style on their mobile devices. Automotive software is not immune to this desire for perpetual improvement and enhancement.

But when was the last time your vehicle got an update? Is it even feasible to do so? Maybe not with your current vehicle, but likely with your next vehicle.

Automotive is undergoing a dramatic change in so many ways. Electrification, on the one hand, and automated driving, on the other. Although this creates strain on the traditional automotive development processes, it also presents many opportunities to the whole automotive ecosystem. After all, vehicle drivers expect their vehicles to be integrated into their digital lives, which makes an automobile yet another intelligent device. So, it is safe to say that start of production is no longer the end of development.

So, let’s look at the differences between a software-defined vehicle and a non-software-defined vehicle.

Make a Google search on Software-Defined Vehicle, and you will most likely come up with three recurring concepts regarding a Software-Defined Vehicle and a non-Software-Defined vehicle:

  1. The ECU architectures are very different
  2. Moving the automotive software development to cloud instances
  3. How are the software updates/upgrades being deployed on the vehicle

Rightfully so. Because in a nutshell, a Software-Defined Vehicle promises a greater lifetime value to the car owners through frequent software updates and potential feature upgrades without the hassle of having the vehicle serviced at the dealer. To achieve this, above mentioned three concepts are paramount to the transformation of Software-Defined Vehicles.

Let’s dive into those three concepts and start demystifying the Software-Defined Vehicle with real-world use cases and solutions.

Modern vs. Legacy compute architectures

A modern vehicle today consists of somewhere between 100 to 150 ECUs (Electronic Control Units). These are isolated components, and they are pretty much programmed to deliver a very narrow-scoped functionality. These ECUs do not have much computing power since they only work for a specific function and are usually from different vendors with different protocols.

If you look at the newly released vehicles today, you can see the dramatic change, starting to unravel. Most significantly, vehicles designed to serve within a coherent mobility ecosystem with tasks such as robotaxis and autonomous delivery vehicles exemplify the Software-Defined Vehicle concept with a more centralized computing system placed within these vehicles.

Various automotive E/E architectures (image courtesy of Arm)

Instead of 150 ECUs per vehicle, the zonal architecture offers a few high-performance in-vehicle computers to undertake computationally-intensive tasks, while low-compute and low-power, real-time zonal controllers guarantee the traditional and indispensable functional safety and real-time requirements of the automotive software. The mixed-criticality is vital at the edge and in the automotive cloud (we will return to this topic later). In both realms, one key takeaway is the necessity to abstract the software from the underlying hardware. Again, we will come back to that later.

Here is how traditional E/E architectures and zonal E/E architectures compare:

Traditional E/E architecturesZonal E/E architectures
​ Approximately 100 – 150 ECUs per vehicleA few high-performance computers with zonal computing
Functionally isolated ECUsFunctions are defined by software (SW and HW are decoupled)
A lot of wiring/weightReduction in system complexity and wiring
Very limited cloud-based functionalityAlways connected

Developing automotive software at a massive scale, using cloud-native design patterns

Now… Assuming we have a vehicle with a zonal E/E architecture, we have endless possibilities to develop new functions or optimize the existing functionality with software only. But, of course, we can not expect vehicle hardware to change much. Still, the Software-Defined Vehicle concept allows automakers to build their vehicle hardware eligible for further upgrades (that can uphold future capacity, so to speak). But if all the vehicles can get updates now, how to keep up with the demand from the digital millennials? How to maintain development agility at a massive scale?

It turns out that cloud-native allows the development of applications simultaneously at scale and servicing millions of people. So is the vehicle the same as a personal mobile device? Not necessarily. Cloud computing or mobile phones do not concern themselves with some specific safety and certifiability topics. However, functional safety and resilience can not be overlooked in automotive.

Nevertheless, with functional safety and resilience in mind, automotive software and application development can use the cloud-native approach, where the application is developed, tested and validated on the cloud and pushed globally with automated workflows. This way, instead of releasing a new feature in a vehicle line does not take six to seven years for an automaker (instead months, maybe weeks).

There are several add-on upsides of using cloud-native for automakers. First of all, using a cloud-native, automated workflow for application development helps automakers to utilize a better efficient engineering workforce, the possibility to upsell, use new features, and a much shorter time to market.

Instead of 150 ECUs per vehicle, the zonal architecture offers a few high-performance in-vehicle computers to undertake computationally-intensive tasks, while low-compute and low-power, real-time zonal controllers guarantee the traditional and indispensable functional safety and real-time requirements of the automotive software. The mixed-criticality is vital at the edge and in the automotive cloud (we will return to this topic later). In both realms, one key takeaway is the necessity to abstract the software from the underlying hardware. Again, we will come back to that later.

Here is how traditional E/E architectures and zonal E/E architectures compare:

Traditional E/E architecturesZonal E/E architectures
​ Approximately 100 – 150 ECUs per vehicleA few high-performance computers with zonal computing
Functionally isolated ECUsFunctions are defined by software (SW and HW are decoupled)
A lot of wiring/weightReduction in system complexity and wiring
Very limited cloud-based functionalityAlways connected

Developing automotive software at a massive scale, using cloud-native design patterns

Now… Assuming we have a vehicle with a zonal E/E architecture, we have endless possibilities to develop new functions or optimize the existing functionality with software only. But, of course, we can not expect vehicle hardware to change much. Still, the Software-Defined Vehicle concept allows automakers to build their vehicle hardware eligible for further upgrades (that can uphold future capacity, so to speak). But if all the vehicles can get updates now, how to keep up with the demand from the digital millennials? How to maintain development agility at a massive scale?

It turns out that cloud-native allows the development of applications simultaneously at scale and servicing millions of people. So is the vehicle the same as a personal mobile device? Not necessarily. Cloud computing or mobile phones do not concern themselves with some specific safety and certifiability topics. However, functional safety and resilience can not be overlooked in automotive.

Nevertheless, with functional safety and resilience in mind, automotive software and application development can use the cloud-native approach, where the application is developed, tested and validated on the cloud and pushed globally with automated workflows. This way, instead of releasing a new feature in a vehicle line does not take six to seven years for an automaker (instead months, maybe weeks).

There are several add-on upsides of using cloud-native for automakers. First of all, using a cloud-native, automated workflow for application development helps automakers to utilize a better efficient engineering workforce, the possibility to upsell, use new features, and a much shorter time to market.

Automotive stacks getting more granular but complex (image courtesy of Arm)


Cloud to the edge, edge to the cloud

Now that we have a system in place to develop the automotive software in the cloud, how do we transfer a new function developed on the cloud (or a function optimized using ingested data created by a vehicle fleet)? Bidirectional data transmission between the cloud and edge (inside the automobile) is called Over-the-Air updates. This concept probably is the most familiar to the consumer among all three essential software-defined vehicle pillars we’ve been addressing.

Millions of consumers receive very frequent software updates to their mobile phones. Over-the-Air updates for automotive software is not very different from that. Historically, the automotive software did not change much and did not receive updates in the olden days, except for minimal bug fixes. To get this done, you had to go to a dealer or a service center where your car was hooked to a computer to get the latest software. Nowadays, more or less all modern cars have connectivity systems built up. But, the usage of software updates creates immense opportunities for both the automaker and the car owners.

Automakers (or 3rd party technology suppliers) can develop a new function for automated driving (or a better battery optimization algorithm) and offer this to car owners after the vehicle is shipped from the factory. This brings new revenue streams for the automakers. They can benefit from defining the vehicle with software as a flexible and capable platform rather than a static and predetermined chassis and body.

On the flip side, car owners can use some of the new functionality developed by the automaker on a trial basis to try and evaluate, as well as use some specific function (automated lane change, for instance) for a limited time only in the pay-as-you-go fashion for that long drive they will take for a vacation.

SOAFEE (Scalable Open Architecture for Embedded Edge)

It’s been some time since the automotive industry realized that the software-defined vehicle is not something that can be achieved single-handedly. Thankfully an ecosystem comes to the aid.

On September 15, 2021, Arm, in collaboration with leaders across the automotive supply chain, announced it is delivering a new software architecture and reference implementation, Scalable Open Architecture for Embedded Edge (SOAFEE), and two new reference hardware platforms to accelerate the software-defined future of automotive.

Directly quoting from the Arm’s announcement: “As vehicle architectures and capabilities evolve, automotive developers today are challenged by the increasing code complexity needed to deliver Advanced Driver Assistance Systems (ADAS), In-vehicle Infotainment systems (IVI), electrified powertrains, and autonomy. To meet these evolving consumer demands, computing must become more centralized, and software is increasingly critical to allowing this. The resulting changes to how software is being developed, deployed and managed means that cloud-native development, best known for driving reductions in cost, time and complexity across the cloud infrastructure industry, is more applicable to automotive development than ever before.

However, to address the software-defined needs of cars today quickly and seamlessly, it is imperative to deliver a standardized framework that enhances proven cloud-native technologies that work at scale with the real-time and safety features required in automotive applications. This framework can also benefit other real-time and safety-critical use cases such as robotics and industrial automation.”

The Scalable Open Architecture for Embedded Edge (SOAFEE) project is an industry-led collaboration defined by automakers, semiconductor suppliers, open-source and independent software vendors, and cloud technology leaders. The initiative intends to deliver a cloud-native architecture enhanced for mixed-criticality automotive applications with corresponding open-source reference implementations to enable commercial and non-commercial offerings.

Building on technologies like Project Cassini and SystemReady, which define standard boot and security requirements for the Arm architecture, SOAFEE adds the cloud-native development and deployment framework while introducing functional safety, security, and real-time capabilities required for automotive workloads.

Cloud-native approach bringing environment parity to automotive software development (image courtesy of Arm)

This high-level view of an automotive central compute solution stack shows hardware, software, and cloud levels. At the bottom level, standards-based firmware and security interfaces ensure system integrators and software developers have a consistent platform enabling seamless, secure boot and system bring-up across all compliant hardware.

The SOAFEE architecture will seek to re-use existing open standards for the different components in the framework and will extend those standards as necessary to meet the mixed-criticality requirements of automotive applications.

SOAFEE builds on these specifications and standards with a reference framework to standardize key non-differentiating middle layers, such as the hypervisor, operating systems, container runtime and hardware abstraction layers.

An initial version of SOAFEE called the SOAFEE R1 is available to download. Instructions on how to build it are available at the SOAFEE GitLab repository. It serves as a starting point to enable automotive DevOps using cloud-native fundamentals.

The first blueprint of SOAFEE: The Autoware Open AD Kit

SOAFEE was announced a little over a year ago at the Arm DevSummit 2021. Since then, a lot of milestones have been achieved. A good read about SOAFEE’s progress can be found in this blog post.

One of the key approaches adopted by the SOAFEE initiative is evangelizing cloud-native with code. This means leaving slides behind and implementing reference systems with cloud-native design patterns. The first reference implementation of SOAFEE was released in the form of EWAOL (Edge Workload Abstraction and Orchestration Layer, https://gitlab.com/Linaro/ewaol) with a reference autonomous workload using Autoware project from the Autoware Foundation.

The key objective of this release was to showcase a containerized delivery of autonomous workload on ADLINK’s AVA Developer Platform, a platform architected by Arm, utilizing Ampere Ultra silicon. These are industry-first, Arm-based, high-performance computing, and server-grade platforms for automotive workload development.

The Open AD kit is based on Arm’s SOAFEE initiative, which brings the real-time and safety needs of automotive together with the advantages of a cloud-native approach, using Autoware as the reference workload for autonomous driving applications. The Open AD kit will run both natively in cloud instances on the AD development and on reference hardware platforms provided by ADLINK Technology and Autocore.

Key technologies from the SOAFEE architecture that provide some of the baseline capabilities of the Open AD kit include containers, allowing for workloads to be easily developed in the cloud and then deployed as microservices to the vehicle, and an orchestration service that enables that deployment from cloud to vehicle.

The first version of the Open AD Kit is available here, and the project continues to mature. Soon Open AD Kit 2.0 will be released, allowing both commercial and open-source workloads to be made readily available to developers.

Key contributors to the Open AD kit releases include TIER IV, Autocore, Arm, ADLINK, and Excelfore, supported by various working groups in the Autoware Foundation. These companies will provide their expertise and technologies to bring the Autoware autonomous driving solution into cloud and vehicle environments, providing a seamless autonomous development and deployment environment.

Conclusion

We have analyzed what is needed for the Software-Defined Autonomous Mobility transformation and addressed these needs with collaborative solutions.

In the next blog post, we will dive deep into the cloud-native paradigm and give examples of how Autoware and Open AD Kit utilize the cloud-native approach for real-world demonstrations.

– – –

Consider signing up for the Autoware Foundation mailing list to receive the latest news about Autoware Foundation and our quarterly newsletters.