车载软件架构 —— Adaptive AUTOSAR是软件架构的正解吗？

车载软件架构 —— Adaptive AUTOSAR是软件架构的正解吗？

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师（Wechat：gongkenan2013）。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

本就是小人物，输了就是输了，不要在意别人怎么看自己。江湖一碗茶，喝完再挣扎，出门靠自己，四海皆为家。人生的面吃一碗少一碗，人生的面见一面少一面。人生就是一次次减法，来日并不方长。自己的状态就是自己最好的风水，自己的人品就是自己最好的运气。简单点，善良点，努力点，努力使每一天都开心，不为别人，只为自己。

本文大体如下：

1、概述—关于智能ECUs的概况

2、技术驱动程序

3、经典、自适应和Non-AUTOSAR ECUs的整合

4、总结

一、概述—关于智能ECUs的概况

传统的ECUs主要实现替代或增强机电系统的功能。这些深度嵌入的ECUs中的软件根据输入信号和来自连接到车辆网络的其他ECUs的信息控制电气输出信号。大部分控制软件都是为目标车辆设计和实施的，在车辆寿命期间不会有重大变化。

新的车辆功能(如高度自动驾驶）将在车辆中引入高度复杂且需要大量计算资源的软件，并且必须满足严格的完整性和安全性要求。这些软件可实现环境感知和行为规划等功能，并将车辆集成到外部后台和基础设施系统中。在车辆的生命周期内，由于外部系统不断发展或功能不断改进，车辆中的软件需要不断更新。

AUTOSAR 经典平台(CP)标准满足了深度嵌入的ECUs的需求，但无法满足上述ECUs 的需求。因此，AUTOSAR 指定了第二个软件平台，即 AUTOSAR 自适应平台(AP)。AP主要提供高性能计算和通信机制，并提供灵活的软件配置，例如支持软件空中更新。为CP专门定义的功能(如访问电信号和汽车专用总线系统)可集成到 AP中，但不在标准化的重点范围内。

二、技术驱动程序

技术驱动因素主要有两类。

-> 一个是以太网;

->另一个是处理器。

随着车载网络带宽要求的不断提高，以太网应运而生。与CAN等传统车载通信技术相比，以太网可提供更高的带宽，并通过交换网络实现更高效的长信息传输、点对点通信等。CP 虽然支持以太网，但它主要是为传统通信技术设计的，并为此进行了优化,因此很难充分利用和受益于基于以太网的通信能力。

同样，随着车辆智能化程度的不断提高，近年来对处理器性能的要求也在大幅提高。多核处理器已在CP中使用，但对处理能力的需求并不仅仅是多核。拥有几十到几百人内核的多核处理器、GPGPU (GPU 的通用型)、EPGA和专用加速器正在出现，因为这些处理器的性能比传统的MCUs高出几个数量级。CP 最初是为单核 MCU 设计的尽管它可以支持多核。此外，随着计算能力的膨胀，即使在数据中心，能效也已经成为一个问题，而对于这些智能ECUs 来说，能效问题实际上更为重要。从半导体和处理器技术的角度来看，受波拉克法则的限制，物理上不可能无止境地提高处理器频率，唯一能提高性能的方法就是采用多核(和多核) 并行执行。此外，众所周知，每瓦特的最佳性能是通过混合使用不同的计算资源实现的，如多核、协处理器、GPU、EPGA和加速器。这就是所谓的异构计算–HPC (High-Performance 计算)目前正在利用异构计算–这无疑远远超出了CP的范围。

值得一提的是，处理器和更快的通信速度也会产生综合效应。随着越来越多的处理元件被组合到单芯片中，如多核处理器，这些处理元件之间的通信速度和效率也比传统的 inter-ECU 通信快了几个数量级。新型处理器互连技术(如 Network-on-Chip (NoC))使之成为可能。芯片内更强的处理能力和更快的通信速度所产生的综合效应，也促使我们需要一个能满足不断增长的系统要求的新平台。

关于自适应平台的特点

上述概述的因素决定了AP的特性。未来的发展必然要求更高的计算能力，而技术趋势为满足这种需求提供了一个基线。然而，在安全相关领域的HPC中，虽然功率和成本效率也很重要，但其本身也带来了各种新的技术挑战

为应对这些挑战，AP采用了ECUs传统上未充分利用的各种成款技术，同时允许AP的实施有最大的自由度，以充分利用创新技术。

1、SOA

为了支持复杂应用，同时在处理分配和计算资源分配方面实现最大的灵活性和可扩展性，AP 采用了面向服务的体系结构 (SOA)。SOA 所基于的概念是，系统由一系列朋务组成，其中一项服务可能会依次使用另一项服务，而应用程序则根据自身需要使用一项或多项服务。SOA 通常表现出系统的系统特征，AP 也具有这种特征。例如，一项服务可能位于应用程序也运行的本地 ECU 上，也可能位于同时运行另一个 AP 实例的远程 ECU 上。在这两种情况下，应用程序代码都是一样的–通信基础架构将提供透明的通信，以消除差异。另一种看待这种架构的方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表了相同的概念。这种基于消息传递和通信的架构还可以从以太网等快速高带宽通信的兴起中获益。

2、并行处理

分布式计算本身就是并行的。由于不同的应用程序使用不同的服务集，SOA 也具有这一特点。提供并行处理能力的多核处理器和异构计算技术的发展为利用计算能力来匹配内在并行性提供了技术机遇。因此，随着多核异构计算技术的发展，AP 具有扩展其功能和性能的架构能力。事实上，硬件和平台接口规范只是等式的一部分，OS/管理程序技术和开发工具(如自动并行化工具) 的进步也至关重要，AP 提供者和行业/学术生态系统应满足这些要求。AP 的目标也是适应这些技术。

3、利用现有标准

重新发明轮子是没有意义的，尤其是在涉及规范而非实施时。AP采取了重复使用和调整现有开放标准的策略，以促进AP自身的快速发展，并从现有标准的生态系统中获益。因此，开发 AP 规范的一个关键重点是不要随意引入现有标准已提供的新巷代功能。例如，这意味着不能因为现有标准提供了所需功能，但界面表面上不容易理解，就随意引入新的界面

4、安全和Security

AP所针对的系统往往需要一定程度的安全和Security，可能是最高级别的安全和Securitv。新概念和新技术的引入不应损害这些要求，尽管要做到这一点并非易事。为了应对这一挑战，AP结合了架构、功能和程序方法。该架构以基于 SOA 的分布式计算为基础，从本质上使每个组件更加独立，不受意外干扰:专用功能有助于实现安全和Secure; C++ 编码指南等准则有助于安全可靠地使用 C++ 等复杂语言。

5、计划动态

AP支持应用程序的增量部署，对资源和通信进行动态管理，以减少软件开发和集成的工作量，缩短迭代周期。增量部署还支持探索性软件开发阶段。

在产品交付方面，AP 允许系统集成商仔细限制动态行为，以降低不必要或不利影响的风险，从而实现安全鉴定。应用程序的动态行为将受到执行清单(见第 4.6 节)中所述约束的限制。多个应用程序的清单之间的相互作用可能会在设计时就造成这种情况。不过，在执行时，资源和通信路径的动态分配只能以规定的方式进行，例如在配置范围内。

AP的实施可进一步从生产使用的软件配置中移除动态功能。计划中的动态功能举例如：

-> 预先确定服务发现过程

-> 将动态内存分配限制在启动阶段

-> 除基于优先级的调度外，还采用公平调度策略

-> 将Process固定分配给CPU内核

-> 仅访问文件系统中的已有文件

-> 应用程序使用 AP API的限制条件

-> 仅执行经过验证的代码

6、灵活

AP的目标是适应不同的产品开发Process，尤其是基于敏捷的Process，尽管这一点并未直接体现在平台功能中。对于基于敏捷的开发，至关重要的是系统的底层架构可逐步扩展，并可在部署后更新系统。A 的架构应能做到这一点。

三、经典、自适应和Non-AUTOSAR ECUs的整合

如前文所述，AP不会取代IVI/COTS 中的CP或Non-AUTOSAR平台。相反，它将与这些平台和路边基础设施等外部后端系统互动，形成一个集成系统（参看下图）。例如，CP已包含SOME/IP，而AP也支持 SOME/IP 和其他协议。

Exemplary deployment of different platforms

Exemplary interactions of AP and CP

AP定义了运行时系统架构、平台的构成以及平台提供的功能和接口。它还定义了用于开发此类系统的 Machine 可读模型。该规范应提供使用平台开发系统的必要信息，以及实施平台本身需要满足的要求。

四、总结

Adaptive AUTOSAR是一种基于服务的软件平台，它支持高性能、灵活和可更新的汽车应用程序。其软件架构主要包括以下几个部分：

硬件/虚拟机层：这是Adaptive AUTOSAR架构的最底层，包括所需的物理资源，如处理器、内存、网络等。这一层为上层提供硬件抽象和虚拟化功能。

基础层：基础层提供一系列基础服务，如通信管理、执行管理、服务发现等。这些服务为上层应用程序提供必要的支持和运行环境。

服务层：服务层包含一系列可复用的软件组件，这些组件以服务的形式提供给上层应用程序。这些服务可以是车辆功能、传感器数据处理、算法实现等。服务层的设计使得应用程序可以更加灵活和高效地组合和使用这些服务。

应用层：应用层是Adaptive AUTOSAR架构的最上层，包括各种汽车应用程序。这些应用程序基于服务层提供的服务进行构建，实现车辆的各种功能和特性。应用层的应用程序可以是多个独立的进程，它们之间通过基础层提供的通信管理机制进行交互。

在Adaptive AUTOSAR架构中，通信管理是一个重要的组成部分。它负责应用程序之间的函数调用和事件发送。服务请求是双向数据流，即发送请求者会收到服务端的反馈。事件发送则是由客户端发起，单向数据流。这种通信机制使得应用程序可以更加灵活地进行交互和协作。

此外，Adaptive AUTOSAR还支持多执行环境，即不同的应用程序可以在不同的执行环境中运行。这使得应用程序可以根据其特性和需求选择最适合的执行环境，从而提高性能和效率。

总的来说，Adaptive AUTOSAR软件架构是一种基于服务的、分层的软件架构，旨在为汽车应用程序提供高性能、灵活和可更新的运行环境。通过分层设计和模块化组件的使用，它实现了应用程序之间的解耦和高效协作。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！