We are starting a series of blog posts and podcasts as a part of our CES 2024 work to be showcased in Las Vegas between 9 and 12 January 2024.

The Autoware Foundation will be exhibiting Open AD Kit demos in a number of booths at the CES 2024 show floor and celebrate the inauguration of our partnership with the Indy Autonomous Challenge for Sim Racing, based on Autoware’s open-source simulation platform AWSIM.

If you are interested, we have blog posts about both the Open AD Kit and AWSIM, previously published at the Autoware Foundation blog on our website. Here are some links to those material:

• Autoware to demystify the software-defined autonomous mobility
• Open AD Kit: A quick review
• AWSIM: End-to-end digital twin simulation platform

In this blog post, we want to lay the groundwork for the upcoming posts, where we will delve deep into the Software-Defined Vehicle (SDV) by dissecting and analyzing the concepts and components that are the puzzle pieces of the entire paradigm.

The buzz around the software-defined vehicles

The topic of SDV didn’t take long to become a buzzword around the automotive sphere because of its potential to transform conventional automotive software development methodology. Shortening the time-to-market, collecting almost real-time feedback from the consumer to improve the user experience in the vehicle, enabling software testing at scale while reducing test and validation costs, and deploying and delivering software ubiquitously are big promises, and there are no reasons why automotive stakeholders should not aspire for the software-defined vehicles to become a reality.

But, (there’s always a but) there’s a need for a drastic change in today’s automotive software development practices, and this change is not super-straightforward. Thankfully, we are seeing deep commitment from the entire automotive industry stakeholders to work together (this is one of the key enablers of the concept), and again, thankfully, we already have some other software-defined industries from which we can take our inspiration.

Software-defined vehicle requirements. Good-to-haves and must-haves

In a nutshell, the SDV paradigm suggests a few key requirements. Let’s take a quick look at them to start looking at the big picture.

1. Defining open standards and specifications to develop automotive software and, instead of competing on standards, focusing on value-added differentiation to make the consumers happy.
2. Getting the vehicle more capable in time (software development doesn’t end after the vehicle leaves the factory) via regularly upgrading the in-vehicle software.
3. Functionalities in the vehicle are not defined by hardware but by software. Achieving this by avoiding an ECU for every function mentality, thus reducing complexity as well.
4. Shift left to enable testing at scale, improve code quality, reduce the losses due to recalls, and shorten the automotive software development cycle using agile methodologies.

At Autoware Foundation’s Open AD Kit, we’re ticking all the boxes for the above-mentioned software-defined vehicle requirements. We gave a thorough look at the Open AD Kit initiative before, that’s why we won’t revisit all the details again, but let’s see how we are addressing these requirements in a concise way:

1. First of all, the Autoware project is open-source. Not only that, but we’re also interacting with the entire automotive ecosystem using the Open AD Kit framework (let’s not forget that the Open AD Kit is the first blueprint of SOAFEE) to create synergies using open standards to enable moving software seamlessly across different environments, as well as focusing on delivering differentiated and value-added applications.
2. Upgrading the automotive software via OTA is an important thrust of the Open AD Kit framework. Autoware Foundation has a roadmap to gradually achieve higher levels of automation by continuously adding new use cases and scenarios.
3. The Autoware project promotes using zonal and consolidated, mixed-critical hardware platforms. The application components can use isolated processes within a given CPU/GPU architecture via virtualization, drastically improving resource use.
4. The Open AD Kit framework dictates the use of cloud-native paradigms. Instead of using the hardware-first approach, we try to utilize the software-first approach via simulation and validation on the cloud for scenario testing (let’s not forget hundreds of scenarios are being tested on Autoware’s CI/CD pipeline every week).

Now, let’s go a little bit more technical to understand the underlying principles of the Open AD Kit framework.

Taking a quick look at the SOAFEE architecture

As we mentioned several times, Open AD Kit is the first blueprint of SOAFEE. To have a better understanding, let’s take a look at the SOAFEE’s architecture.

SOAFEE architecture is consciously designed to be simple. The main idea of the SOAFEE architecture is to create a direct path to run and deploy various domain-specific applications in different environments.

The domain-specific application depicted here is any containerized workload working on top of the SOAFEE reference implementation, which provides the necessary hardware and software abstraction via container runtime, orchestration, and virtualization technologies.

SOAFEE reference implementations are sitting on top of the standards-based firmware, which enables alignment for the hardware platforms in the market so that the SOAFEE reference implementations can be moved from one platform to another, but also different types of hardware such as edge, cloud and virtual instances. Once the software is abstracted from the underlying hardware, the development, testing, validation, and deployment processes can be moved where they’re running best (e.g., edge, cloud, virtual) with the optimal use of resources.

Now that we understand the core principles of SOAFEE architecture, we can dive into the Open AD Kit blueprint.

Taking a quick look at the Open AD Kit Blueprint

Open AD Kit shares the same core principles with SOAFEE architecture: containerization of workloads and agreeing on open standards.

The Open AD Kit framework is developed at Autoware’s Open AD Kit working group. The main goal of the working group is to transform the monolithic Autoware architecture into containerized workloads.

“Autoware software stack already existed when we started the Open AD Kit, so we had a lot of legacy code, a lot of well-written code and great functionality, but it was also complicated to deploy them in a flexible way. We’ve decided to take on this huge effort by dividing it into smaller threads and processes”

said Kasper Mecklenburg from Arm and SOAFEE in our podcast session to explain how the Open AD Kit working group is tackling the task of containerization of the Autoware project gracefully and after diligent discussions to create agreement and alignment.

We call this effort DevOps Dojos, a permanent segment at every Open AD Kit working group meeting where we update and track progress in achieving software-defined Autoware. Gradually, we’re tackling ROS2 nodes that constitute the Autoware software and making necessary changes to modernize them to make Autoware software software-defined.

What do we do at the Open AD Kit working group?

There’s actually an open call for volunteers to help us with this task. Everyone that is familiar with Autoware and ROS, along with C/C++, YAML, and JSON schema skills, can come in and contribute to our efforts. Here’s the call for participation announcement.

We convene every Thursday at 3 pm CET (look at the Autoware calendar for more information) at the Open AD Kit working group to update and discuss the items on the task board. It’s a great opportunity to learn about this exciting initiative; please join us!

The Open AD Kit working group has ambitious goals, and the progress has been shown time after time at various global events. We’re working towards preparing very exciting, tangible and comprehensive demos for the upcoming CES show. As a part of that effort, we have already achieved good preliminary results on containerizing Autoware software into granular containers that can be moved from cloud to edge.

Future work and forward-looking statements

Unsurprisingly, the containerization of the Autoware software was the initial goal of the Open AD Kit working group; however, the work won’t end there. As mentioned earlier, once we achieve the containerized form of workloads, we can move those containers freely. By leveraging the open standards, we will target great software portability across different types of hardware. The good news is that processing hardware vendors strive for the same objective. Many PoCs are already in the works to deploy Autoware software on various hardware platforms compatible with the consortia-led open standards.

On the other hand, shift-left is an important aspect of the software-defined vehicle paradigm, so using the cloud and collaborating on the cloud is another objective the Open AD Kit working group will focus on soon. Our CES demo will definitely provide a glimpse of that idea, and we will continue working on prototyping demos and solutions to attract attention from parties across the board.

In the next blog post of this series, we will dial it down a bit on the technical side, take a broader look at the Software-Defined Vehicle realm and talk about business models that make sense, how the SDV will benefit the OEMs and consumers, and the activities of the active stakeholders and the roadmap to collaboration of the entire automotive ecosystem.

See you in our next blog!