| 编辑推荐: |
本文主要用3个案例分别分析对Adaptive AUTOSAR 平台的需求，并分析了Classic AUTOSAR 和Adaptive AUTOSAR 的区别，希望对您的学习有所帮助。
本文来自于汽车和物联网博客，由火龙果软件Alice编辑、推荐。 |
|
软件对现代汽车至关重要。 汽车嵌入式电子设备日益复杂，导致需要实时收集和处理大量数据。 Classic AUTOSAR 平台是否为此配备？ 什么是Adaptive AUTOSAR ？ Classic AUTOSAR 和Adaptive AUTOSAR 可以共存吗？ 让我们一探究竟！
新 AUTOSAR 平台的案例：Adaptive AUTOSAR
让我们从漫步在汽车历史的车道开始吧！大约在20世纪80年代，汽车工业迎来了第一个电子控制单元。当时，ECU负责控制空燃比、可变气门正时和其他一些与发动机相关的东西。嵌入在ECU中的软件在规模、复杂性和计算能力方面更简单
快进到 2020 年，我们离完善自动驾驶越来越近了。 今天， 车辆中嵌入了 远程信息处理 、 信息娱乐集群 和一大堆物联网小玩意。
但是如何集成这么多可能来自不同供应商的组件而不面临兼容性问题呢?AUTOSAR就是答案!
AUTOSAR 于 2002 年推出时，其想法是实现汽车软件开发的标准化。 它旨在实现具有深度嵌入其中的软件的 ECU。 假设这些应用程序在其整个生命周期内不需要任何类型的更新。
然而，汽车软件生态系统已经发生了翻天覆地的变化。汽车软件现在需要频繁更新。此外，对灵活性和计算能力的需求是前所未有的。而经典AUTOSAR平台并不是为此而设计的。
这并不意味着AUTOSAR已经过时了;相反，它需要一个可以满足下一代汽车不断变化的需求的兄弟。
让我们分 3 种情况分析对Adaptive AUTOSAR 平台的需求：
案例 1：ADAS： 高级驾驶辅助系统基于一组复杂的传感器，如 LIDAR、RADAR 和高分辨率相机。 需要处理从这些传感器收集的数据，以创建车辆外部环境的模型。 基于此环境模型，ADAS 在制动、停车甚至驾驶（如自动驾驶的情况下）期间为驾驶员提供帮助。
事实上，自动驾驶一直是引入新 AUTOSAR 架构的最大推动力，该架构可以支持动态通信、灵活安全的平台、更快的数据通信和处理等。
自动驾驶汽车生命中的一个时刻：
使用传感器和摄像头非常细致地观察车外环境
与环境交流，如交通信号灯、其他车辆等。
利用从传感器收集的数据做出驾驶决策，例如左/右操纵、减速、紧急制动等。
自动驾驶汽车中的摄像头和雷达捕获的图像必须传输到 ECU 进行实时处理。 要实现如此快速的通信，只有CAN、LIN、Flexray等车载总线系统是不够的。 以太网在这里优先，并得到 SOME/IP 等现代协议的支持。
案例 2：车辆架构： 当我们谈论车辆对 X 通信 (V2X) 或车辆对车辆通信时，我们正在寻找一种完全修改的车辆架构。 与直接连接传感器/摄像头的传统控制单元不同， 域控制器架构 的新概念 正在汽车领域发展。 不是使用单独的控制器，而是为每个域分配一个强大的控制器，例如 车身控制 、 信息娱乐 、动力总成。
在电动汽车的情况下，充电站和车辆之间的通信也是唯一的，并且必须是安全的以用于计费目的。 强大的通勤能力在这里也是必不可少的。 而 Classic AUTOSAR 平台根本就不是为这样的计算需求而设计的。
案例3:无线固件更新(FOTA):大多数嵌入在ECU内的软件从不需要更新。一些确实需要更新的，必须带到车库同样。
Classic AUTOSAR 能够提供 FOTA 服务 ，但它不是最适合它的。 此外，无法更新 ECU 内的单个应用程序。 灵活性问题以及 Classic AUTOSAR 对实时性的严格要求也使其对 FOTA 不太可靠。
Adaptive AUTOSAR 灵活的集成环境增强了软件更新和扩展新功能的能力。
Classic AUTOSAR 和Adaptive AUTOSAR 的比较
| Classic AUTOSAR |
Adaptive AUTOSAR |
| 通信是基于信号的，通过CAN、LIN等通信BUS网络实现。 |
它是基于服务的通信，它利用以太网和 SOME/IP 作为物理介质 |
| 深度嵌入功能的实现 |
高性能和计算密集型功能的实现 |
| 未来系统示例：发动机控制、制动系统、安全气囊控制单元等。 |
未来系统的示例：无线更新 (OTA)、传感器融合数据处理、持久性、在车辆运行期间动态选择应用程序包等。 |
| 无法在运行时更新软件，软件组件之间的通信是硬连线的 |
Adaptive AUTOSAR RTE 独立于应用程序，因此可以进行无线更新 |
| Classic AUTOSAR 平台中的更新意味着替换整个 ECU 代码 |
Adaptive平台提供删除/更新 ECU 中单个应用程序的选项 |
| Classic AUTOSAR 架构的灵活性商数较低 |
灵活性是Adaptive AUTOSAR 的 USP 之一，它提供了一个灵活的集成环境 |
| 它具有严格的实时处理要求（以微秒为单位）并且满足截止日期至关重要 |
有一个软实时要求（以毫秒为单位） |
| 符合Classic AUTOSAR 的应用程序是用 C 语言编写的 |
C++ 是为Adaptive AUTOSAR 架构规定的语言 |
| Classic AUTOSAR 实施不需要操作系统 |
Adaptive AUTOSAR 基于 POSIX 操作系统 |
| 应用程序利用 AUTOSAR RTE 进行软件组件的调度和它们之间的通信 |
应用程序利用操作系统进行调度和通信 |
| 它以静态方式配置，其中每个信号在配置时定义 |
由于应用程序固有的灵活性，Adaptive AUTOSAR 是动态配置的 |
Classic AUTOSAR 与Adaptive AUTOSAR 架构的快照
Classic AUTOSAR 和Adaptive AUTOSAR 能否共存？
正如许多人所想的那样，Adaptive AUTOSAR 并不意味着要取代它的Classic AUTOSAR 对应物。 相反，它们旨在共存于汽车生态系统中。 由于这两个平台都为不同的问题提供了解决方案，因此它们的共存提供了大量的附加值。
即使是配备 ADAS 和远程信息处理功能的现代车辆，也需要功能性 ECU 来处理整个范围的任务（硬实时是强制性的）。 Adaptive AUTOSAR 将支持 OTA 升级的动态通信，而Classic AUTOSAR 将提供深入嵌入 ECU 的高安全性应用程序。
由于两种 AUTOSAR 架构 的基础 几乎相似，因此它们之间提供了互操作性。
上图显示了Classic AUTOSAR 和Adaptive AUTOSAR 如何在车辆中共存
Adaptive AUTOSAR 给车辆架构带来的主要变化是在整个通信网络中使用以太网。 Adaptive ECU 将通过以太网进行通信，而Classic AUTOSAR ECU 仍将通过 CAN 或 LIN 等车辆总线网络进行通信。
那么Classic AUTOSAR 和Adaptive ECU 将如何相互通信？
答案是，通过 网关ECU 。 Classic AUTOSAR ECU 充当网关，并将来自 BUS 系统的信号打包到Adaptive ECU 可以读取的服务中。 但是，在这种情况下，必须转换配置格式。
还有另一种情况，即Classic AUTOSAR ECU 纯粹是基于信号的，无法将信号打包到服务中。 在这里，Classic AUTOSAR ECU 将信号转换为 UDP 帧并通过以太网传输它们。 Adaptive ECU 配备了 “信号到服务” 映射功能，可将 UDP 帧转换为服务。
AUTOSAR 的未来会怎样？
这个故事的寓意是Adaptive和Classic AUTOSAR 相辅相成，可以共存！ Classic 平台专注于软件深度嵌入的功能 ECU（有很多好处），而 Adaptive 平台是可以帮助实现自动驾驶功能的未来主义平台。 汽车行业同样需要这两者。
可能会有一段时间将Adaptive AUTOSAR 平台用作 ECU 软件开发的唯一平台。 但现在预测还为时过早。
目前，有了灵活的网关，汽车工程师只能考虑加入这些世界并充分利用它。
|
