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:
1.Communicate with their environment.
2.Observe their environment using a multitude of sensors.
3.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:

1.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.

2.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.

3.It needs enough computing power to run fully trained state-of-the-art neural networks to interpret sensor data and make correct decisions.
4.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”:

1.It runs on small, specialized hardware (in terms of computing power).
2.It is designed for, created for, and flashed to ECUs, and then it works – no need to modify it.
3.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:

1.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.
2.More computing power to crunch numbers really fast – even with the support of graphics processing units (GPUs).
3.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.

译文

Adaptive AUTOSAR如何实现自动驾驶

在我上一篇文章中我们讨论了虚拟ECU，我强调AUTOSAR作为轻松交换软件功能的基础。然而，它完全是关于Classic AUTOSAR，或者更准确地说，是AUTOSAR经典平台。但在自动驾驶的背景下，每个人都在谈论Adaptive AUTOSAR或AUTOSAR自适应平台。

当Adaptive Platform首次与客户讨论时，它基本上是这样的：
客户：“我们需要灵活的软件架构来进行无线更新。”
我：“你打算怎么做？”
客户：“我们还不知道，但Adaptive AUTOSAR会。”

那是在自适应平台首次发布之前的几个月。所以我们的期望很高，他们完全符合我的dSPACE同事已经在我们的软件在环工具链中支持“适应性”的渴望。

当然，每个人都应该知道一个基本事实：自适应AUTOSAR不是经典AUTOSAR的继承者;它不会取代它。相反，它是一种定义ECU软件的替代方法，以及它如何在ECU硬件上运行 - 或者在虚拟机上运行。

为什么选择另一个AUTOSAR平台（Adaptive AutoSar）？

发明新平台的原因是什么？ AUTOSAR的第一次启动是在2002年，截至今天，AUTOSAR Classic Platform已经成熟版本4.如果您正在寻找模块化标准来编码和交换汽车领域的嵌入式软件，建议您用它。

但汽车行业正在重塑自我。通过自动驾驶，对软件架构的要求从根本上发生了变化。
请记住，我们的自动驾驶汽车必须：
1.与他们的环境沟通。
2.使用多个传感器观察环境。
3.使用这些数据做出许多决定，其中大部分对我们的健康，有时甚至是生命至关重要。

我们将其转化为更多专业上的术语解释就是：

1.我们的汽车只是另一种设备，与一切相连。这可能包括您的智能家居，但它首先包括与数据后端，其他汽车和拐角处的交通信号灯的通信。
2.它使用媒体流。传感器不断扫描环境并生成大量数据，以确保您的高速公路驾驶员或紧急停车工作。
3.它需要足够的计算能力来运行经过全面训练的最先进的神经网络来解释传感器数据并做出正确的决策。

我们购买之后必须定期更新最新的软件，我们不希望在商店中闪存ECU的麻烦。
这些项目只是部分自动驾驶和自动驾驶考虑的例子。
它们对如何开发软件产生巨大影响。

每个开发者都可以自定义自己独有的软件架构

当您决定如何开发软件时，您还必须决定特定的软件架构，而不是轻易做到。每个软件架构都有用。
使用AUTOSAR Classic Platform，您可以设计一个具有专用目标的软件架构。这完全是关于“深度嵌入”的软件：
1.它运行在小型专用硬件上（就计算能力而言）。
2.它专为ECU设计，创建和闪存，然后工作 - 无需修改它。
3.它的通信（主要）是使用传统的汽车总线网络（如CAN）对相对较小的数据包进行循环广播。

当然这些并不能完全地满足我们对上述自动驾驶的期望。从这三个例子中我们已经可以看到一些必须要满足的新的要求：
1.连续的传感器数据流必须在两个或三个功能之间交换，而不是向整个网络广播的小数据包。
2.即使在图形处理单元（GPU）的支持下，更快的计算能力也能快速逼近数字。
3.灵活的软件，可以在运行时更换，也可以连接到最先进的网络系统（不关心汽车使用哪种通信协议）。

AUTOSAR经典平台（Claasic AutoSar）不是专为自动驾驶而设计的。因此，AUTOSAR创建了自适应平台（Adaptive AutoSar） - 完全符合新要求。

最关键的灵活性

使用自适应平台，软件功能之间的通信不再以循环突发方式进行，而是面向服务。 “自适应应用程序”（在经典平台中称为“软件组件”）宣布它能够提供哪些数据，以及它需要哪些数据。代理服务找到正确的匹配，并且两个应用程序直接通信。

更重要的是，低级通信不再基于CAN或其他使用专用协议的经典汽车总线系统，而是基于以太网。除了以太网通信，SOME / IP [http://some-ip.com]目前正受到更多关注。作为面向服务的中间件层，它定义了应用程序通信的实际方式。例如，您不再需要直接在代码行为中定义循环触发时间。

作为来自经典平台世界的人，在运行时更换软件是我在非嵌入式环境中理解的，而不是在AUTOSAR环境中。原因很简单：
使用Classic平台，软件组件之间的通信通过AUTOSAR运行时环境（RTE）进行硬连线并生动，从而将通信从架构级别转换为ECU级别。它通过解析静态宏并将它们转换为适当的基本软件调用来实现，例如，将它们包装成总线消息。

如果您想拥有可在运行时更换的软件，则不起作用。自适应平台通过实现面向服务的通信体系结构克服了硬连线通信的缺点。
因此，AUTOSAR运行时环境的自适应版本（ARA，适用于自适应应用程序的AUTOSAR运行时）独立于实际应用程序而工作。它只提供代理服务。在要求它的任何应用程序之间建立通信。

您可以在运行时添加或替换软件，因为只有在启动软件后才会自动建立通信 - 它不是在设计阶段确定的，不是在经典平台中确定的。

程序AWAY

关于灵活性的最后一点：
我们都知道最先进的自动驾驶系统，特别是在传感器数据处理的背景下，是在Linux系统上开发的。我们需要操作系统提供的所有灵活性，包括灵活的内存分配，线程处理，您的名字。我们不希望也不能放弃这种灵活性,因为我们必须编译专用ECU操作系统的代码。
因此，Adaptive Platform基于POSIX接口。通过将他们的应用程序部署到自适应平台，开发人员现在可以使用Linux来进行开发。

总结

我个人的结论是，自适应平台（AdaptiveAutoSAR）是经典平台（ClassicAutoSar）的姐妹。两个平台都有相同的来源，目的也是一样的：提供开发高质量汽车软件的方法和标准。
它们是互补的：
经典平台专门用于经典汽车领域的高效，深度嵌入式功能，而自适应平台则瞄准不断发展的自动驾驶领域，具有该领域所需的所有灵活性，并且我们可以在软件方面实现这一点架构，通信手段和处理能力。
因此，这两个AutoSar平台都是我们必不可少的。