Sven Flake, Product Engineer Virtual Validation, dSPACE GmbH
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.
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:
Let’s translate this into more technical terms:
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.
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":
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:
The AUTOSAR Classic Platform is just not designed for autonomous driving. Therefore, AUTOSAR created the Adaptive Platform – with exactly the new requirements in mind.
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.
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?
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.