How Adaptive AUTOSAR Enables Autonomous Driving

In my last post, I discussed virtual ECUs, and I stressed AUTOSAR a lot as a basis for easily exchanging software functionality. However, it was all about classic AUTOSAR, or more precisely, the AUTOSAR Classic Platform. But in the context of autonomous driving, everyone is talking about adaptive AUTOSAR, or the AUTOSAR Adaptive Platform.

When the Adaptive Platform first came up in discussions with customers, it basically went like this: 
Customer: “We need flexibility in software architectures to do updates over the air.”
Me: “How are you going to do that?”
Customer: “We don’t know yet, but adaptive AUTOSAR will.”

That was a few months before the first release of the Adaptive Platform. So our expectations were high and they perfectly matched the eagerness with which my dSPACE colleagues were already working to support “adaptive” in our software-in-the-loop tool chain.

Of course, there is one fundamental fact everyone should know: Adaptive AUTOSAR is no successor of classic AUTOSAR; it does not replace it. Instead, it is an alternative way to define ECU software and how it is run on ECU hardware – or on virtual machines for that matter.

Why Another AUTOSAR Platform?

What's the reason for inventing a new Platform? The very first kick-off of AUTOSAR was in 2002, and as of today, the AUTOSAR Classic Platform has a mature version 4. If you are looking for a modular standard to code and exchange embedded software in the automotive domain, you are advised to use it.

But the automotive industry is reinventing itself. With autonomous driving, the requirements for software architectures have changed fundamentally.

Keep in mind, our self-driving cars have to:

• Communicate with their environment.
• Observe their environment using a multitude of sensors.
• Use this data to make lots of driving decisions, most of them critical to our health and, sometimes, life.

Let’s translate this into more technical terms:

• Our car acts as just another device and is connected to everything. This may include your smart home, but it first and foremost includes communication with data back-ends, other cars, and the traffic lights around the corner.
• It uses media streaming. Not for your kids in the back but for the sensors that are continuously scanning the environment and generating massive amounts of data to ensure your highway pilot or emergency break works.
• It needs enough computing power to run fully trained state-of-the-art neural networks to interpret sensor data and make correct decisions.
• It has to be regularly updated with the latest software after we buy it, and we do not want the hassle of flashing ECUs in the shop.

These items are just examples of considerations that come with partially automated and autonomous driving.

They have a huge impact on how software has to be developed.

Each to Their Own Software Architecture

When you decide how to develop software, then you also have to decide on a specific software architecture, and you don’t do it lightly. Every software architecture serves a purpose.

With the AUTOSAR Classic Platform, you design a software architecture with a dedicated goal. It is all about software that is "deeply embedded":

• It runs on small, specialized hardware (in terms of computing power).
• It is designed for, created for, and flashed to ECUs, and then it works –  no need to modify it.
• Its communication is (mainly) targeted at the cyclic broadcast of relatively small data packets using traditional automotive bus networks like CAN.

None of this works very well with our expectations for autonomous driving above. Just from the three examples we can already see that new requirements have to be met:

• Continuous streams of sensor data have to be exchanged between two or three functions, as opposed to small packets that are broadcast to the overall network.
• More computing power to crunch numbers really fast – even with the support of graphics processing units (GPUs).
• Flexible software that can be replaced at run time and which is also able to connect to state-of-the-art web systems (which do not care which communication protocol a car uses).

The AUTOSAR Classic Platform is just not designed for autonomous driving. Therefore, AUTOSAR created the Adaptive Platform – with exactly the new requirements in mind.

Flexibility Is Key

With the Adaptive Platform, communication between software functionalities is no longer conducted in cyclic bursts, but is service-oriented. An ’adaptive application’ (called ‘software component’ in the Classic Platform) announces which data it is able to provide, and which data it needs. A brokering service finds the correct match and the two applications communicate directly.

What’s more, the lower-level communication is no longer based on CAN or other classic automotive bus systems, which use dedicated protocols, but on Ethernet. In addition to Ethernet communication, SOME/IP [http://some-ip.com] is currently gaining a lot more attention. As a service-oriented middleware layer, it defines the actual way in which applications communicate. For example, you no longer have to define cyclic trigger times directly in the code behavior.

As someone who comes from the world of the Classic Platform, replacing software at run time is something I understand in non-embedded contexts, but not in an AUTOSAR context. The reason is simple: With the Classic Platform, the communication between software components is hard-wired and brought to life by the AUTOSAR Runtime Environment (RTE), which translates the communication from the architecture level to the ECU level. It does so by resolving static macros and translating them to appropriate basic software calls, e.g., for wrapping them into bus messages.

If you want to have software that can be replaced during run time, this does not work. The Adaptive Platform overcomes the drawbacks of hard-wired communication by implementing a service-oriented communication architecture.

As a result, the adaptive version of the AUTOSAR Runtime Environment (ARA, AUTOSAR Runtime for Adaptive Applications) works independently of the actual applications. It just provides the brokering service. Communication is established between any applications that ask for it.

The final result? You can add or replace software at run time, because communication will be established automatically only after you start the software – It is not determined in the design phase, not as in the Classic Platform.

Program Away

A last note about flexibility: We all know that state-of-the-art autonomous driving systems, especially in the context of sensor data processing, are developed on Linux systems. We need all the flexibility an operating system provides, including flexible memory allocation, thread handling, you name it. We don't want to – and probably cannot – forego this flexibility just because we have to compile our code for a specialized ECU operation system.

Because of this, the Adaptive Platform is based on a POSIX interface. By deploying their applications to an adaptive platform, developers can now exploit all the benefits of their beloved Linux.

That's something, isn't it?

Summary

My personal conclusion is that the Adaptive Platform is a sister of the Classic Platform. Both platforms have the same ancestors, the same overall intention: Providing methods and a standard to develop high-quality automotive software.

They are complementary: The Classic Platform is specialized for efficient, deeply embedded functions of the classic automotive domains, while the Adaptive Platform aims at the evolving domain of autonomous driving, with all the flexibility this domain requires and which we can achieve in terms of software architecture, means of communication, and processing power.

Therefore, we need both.

And at dSPACE, we support both. Our next post will go into the details.