在我的上一篇文章中，我讨论了虚拟 ECU，并且我非常强调 AUTOSAR 作为轻松交换软件功能的基础。然而，这一切都是关于经典的 AUTOSAR，或者更准确地说，是 AUTOSAR 经典平台。但是在自动驾驶的背景下，大家都在谈论自适应AUTOSAR，或者说AUTOSAR Adaptive Platform。
当自适应平台第一次与客户讨论时，它基本上是这样的：
客户：“我们需要软件架构的灵活性来进行无线更新。”
我：“你打算怎么做？”
客户：“我们还不知道，但自适应 AUTOSAR 会。”
那是自适应平台首次发布的几个月前。因此，我们的期望很高，它们完全符合我的 dSPACE 同事已经在努力支持我们的软件在环工具链中的“自适应”的渴望。
当然，每个人都应该知道一个基本事实：自适应 AUTOSAR 不是经典 AUTOSAR 的继承者；它不会取代它。相反，它是定义 ECU 软件以及它如何在 ECU 硬件或虚拟机上运行的另一种方法。
为什么选择自适应 AUTOSAR平台？
发明新平台的原因是什么？AUTOSAR 的第一次启动是在 2002 年，到今天为止，AUTOSAR Classic Platform 已经有一个成熟的版本 4。如果您正在寻找一个模块化标准来编码和交换汽车领域的嵌入式软件，建议您用它。
但汽车行业正在重塑自我。随着自动驾驶，对软件架构的要求发生了根本性的变化。
请记住，我们的自动驾驶汽车必须：
- 与他们的环境交流。
- 使用大量传感器观察他们的环境。
- 使用这些数据来做出许多驾驶决定，其中大多数对我们的健康，有时甚至对生命至关重要。
让我们把它翻译成更专业的术语：
- 我们的汽车只是另一个设备，连接到一切。这可能包括您的智能家居，但它首先包括与数据后端、其他汽车和拐角处的交通信号灯的通信。
- 它使用媒体流。不是为您的孩子在后面，而是为不断扫描环境并生成大量数据以确保您的高速公路飞行员或紧急休息工作的传感器。
- 它需要足够的计算能力来运行经过全面训练的最先进的神经网络来解释传感器数据并做出正确的决定。
- 购买后必须定期使用最新软件进行更新，并且我们不希望在商店中闪烁 ECU 的麻烦。
这些项目只是部分自动驾驶和自动驾驶的注意事项示例。
它们对软件的开发方式有着巨大的影响。
当您决定如何开发软件时，您还必须决定特定的软件架构，并且您不会轻易做出决定。每个软件架构都有一个目的。
使用 AUTOSAR 经典平台，您可以设计具有特定目标的软件架构。这都是关于“深度嵌入”的软件：
- 它在小型专用硬件上运行（就计算能力而言）。
- 它是为 ECU 设计、创建和闪存的，然后它就可以工作——无需修改它。
- 它的通信（主要）针对使用传统汽车总线网络（如 CAN）的相对较小数据包的循环广播。
这些都不符合我们对上述自动驾驶的期望。仅从三个示例中，我们已经可以看到必须满足新的要求：
- 必须在两个或三个功能之间交换连续的传感器数据流，而不是向整个网络广播的小数据包。
- 即使在图形处理单元 (GPU) 的支持下，也有更多的计算能力可以真正快速地处理数字。
- 灵活的软件，可以在运行时更换，也可以连接到最先进的网络系统（不关心汽车使用哪种通信协议）。
AUTOSAR Classic 平台并非专为自动驾驶而设计。因此，AUTOSAR 创建了自适应平台——正是考虑到了新的要求。
灵活性是关键
借助自适应平台，软件功能之间的通信不再以循环突发的方式进行，而是面向服务的。一个“自适应应用程序”（在经典平台中称为“软件组件”）宣布它能够提供哪些数据，以及它需要哪些数据。代理服务找到正确的匹配项，两个应用程序直接通信。
更重要的是，底层通信不再基于CAN或其他使用专用协议的经典汽车总线系统，而是基于以太网。除了以太网通信之外，SOME/IP [http://some-ip.com] 目前正获得更多关注。作为面向服务的中间件层，它定义了应用程序通信的实际方式。例如，您不再需要直接在代码行为中定义循环触发时间。
作为来自经典平台世界的人，我在非嵌入式环境中理解在运行时替换软件，但在 AUTOSAR 环境中则不然。原因很简单：使用经典平台，软件组件之间的通信是硬连线的，并由 AUTOSAR 运行时环境 (RTE) 实现，它将通信从架构级别转换到 ECU 级别。它通过解析静态宏并将它们转换为适当的基本软件调用来做到这一点，例如，将它们包装到总线消息中。
如果您想拥有可以在运行时更换的软件，这是行不通的。自适应平台通过实现面向服务的通信架构克服了硬连线通信的缺点。
因此，AUTOSAR 运行时环境的自适应版本（ARA，AUTOSAR Runtime for Adaptive Applications）独立于实际应用程序工作。它只是提供代理服务。在任何需要它的应用程序之间建立通信。
最后的结果？您可以在运行时添加或替换软件，因为只有在您启动软件后才会自动建立通信——这不是在设计阶段确定的，不像在经典平台中那样。
关于灵活性的最后一点说明：我们都知道最先进的自动驾驶系统，尤其是在传感器数据处理方面，是在 Linux 系统上开发的。我们需要操作系统提供的所有灵活性，包括灵活的内存分配、线程处理等等。我们不想——也可能不能——仅仅因为我们必须为专门的 ECU 操作系统编译代码而放弃这种灵活性。
因此，自适应平台基于 POSIX 接口。通过将他们的应用程序部署到自适应平台，开发人员现在可以利用他们钟爱的 Linux 的所有优势。那是一回事，不是吗？
概括
我个人的结论是自适应平台是经典平台的姐妹。两个平台有相同的祖先，相同的总体意图：提供开发高质量汽车软件的方法和标准。
它们是互补的：经典平台专门用于经典汽车领域的高效、深度嵌入功能，而自适应平台则针对自动驾驶不断发展的领域，具有该领域所需的所有灵活性，我们可以在软件方面实现这一点架构、通信方式和处理能力。
因此，我们两者都需要。
