近年来，随着汽车的智能化程度越来越高，处理器的性能要求也大大提高。通常是在CP Autosar端采用多核处理器移植相应的软件算法，对于高阶自动驾驶来说其对处理能力的需求远超多核。许多具有数十到数百个内核的众核处理器、GPGPU（GPU的通用用途）、FPGA和专用加速器正在出现，因为这些处理器提供的性能比传统 MCU高出一个数量级。

AP Autosar的架构部署原理

随着内核数量的不断增加，原本为单核 MCU 设计的 CP 虽然可以支持多核，但是效率却极度降低。主要体现在随着内核数量增加，单核MCU所布局的CP计算能力已经远超其本身负荷。并且，随着计算能力的不断增长，在诸如数据中心、功耗效率、主频率也已经成为一个问题，对于如何布局各个ECU软件模块到各个性能核上就显得尤为重要。同时，对于功率利用率来讲，最佳性能指标是通过异构计算来实现，也即混合不同的计算资源（如Many Core、协处理器、GPU、FPGA、加速器等），强大的处理能力和快速的芯片内通信速度，也促使开发者建立一种新的平台，以适应不断增长的系统要求。

01. AP与CP之间的关系

首先我们需要从根源上讲讲AP和CP的关系实际上，AP Autosar是集成了CP Autosar和非Autosar ECU，AP 不会取代显示端 IVI / COTS 中的 CP 平台或 非AUTOSAR 平台。而是与这些平台和外部后端系统进行交互，形成集成系统。同时，除了基础的以太网协议外，CP和AP都可以支持了SOA中的基础服务协议Some/IP。

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

02.AP Autosar的几大关键模块典型应用原理

1）AP Autosar架构方案

AP Autosar的逻辑视图体现了其相应的体系结构，自适应应用程序（Adaptive Application，AA）通常运行在ARA（AUTOSAR Runtime for Adaptiveapplications，自适应应用程序的运行平台）上，ARA由功能群集（FCs）提供的应用程序接口组成，这些集群属于Adaptive Platform Foundation或 Adaptive Platform Services，分别提供 AP 的基本功能和服务。属于 Adaptive Platform Foundation的功能集群是“基于库的”，而 AdaptivePlatform Services 是“基于服务的”。ARA通过隐形接口确保自适应应用程序之间可以有效进行交互。状态管理使用标准ARA接口来维护不同AP堆栈实现之间的可移植性。应用程序通信管理（CM，Communication Management）可以为机器内提供面向服务的通信，并处理Service请求与应答之间的路由，不必关系他们之间的拓扑部署。

同时，AA和FC之间的调用不是通过IPC的进程间通信进行，而是常规的库函数调用进行的。在ARA接口下，包括在 AA上下文中调用的ARA 库，可以使用 ARA以外的其他接口来实现 AP 规范，这取决于 AP 实现的设计。

从操作系统的角度来看，AP 和 AA只是形成一组进程，每个进程包含一个或多个线程。尽管这些进程的实现取决于 AP 的实现方式，但它们之间没有区别。这些进程通过进程间通信IPC 或任何其他可用的 OS 功能相互交互。这里需要注意，自适应应用程序进程可能不会直接使用 IPC，而只能通过 ARA进行通信。

ara :: com 和 ara :: rest 这两个通信堆栈都可以在自适应应用程序之间建立通信路径。ara:: rest 是一个 framework，用于在此类 API之上构建 RESTful API以及特定服务。整个框架设计严格针对最大的资源控制。可以严格控制和定制所有计算和分配，以适合应用程序（部署）的确切需求。

2）应用程序执行控制管理

应用程序的生命周期管理由执行管理（EM，Execution Management）模块进行程序加载/启动的。但该模块不决定应用程序的启动和终止时间，该启动和终止时间由状态管理SM进行特殊控制的，并且需要在系统集成/运行时进行适当的配置才能启动程序。

实际上，从EM的角度来看，所有的功能集群都是应用程序，除了EM本身外，他们也以相同的方式启动。自适应应用程序AA和功能集群可以使用任何非标准接口，只要它们不与标准 AP 功能冲突，并且它们符合项目的安全性要求即可。

对于数据确定性，执行管理提供了 DeterministicClient API，以支持对内部流程的控制，确定性工作人员池，激活时间戳和随机数。对于软件锁步，DeterministicClient 与可选的软件锁步框架进行交互，以确保冗余执行的流程具有相同的行为。DeterministicClient 与 CommunicationManagement 进行交互，以使数据处理与周期激活同步。

3）运行机器Machine/Hardware

AP 将运行在其上的硬件视为一台虚拟机Virtual Machine，多台 Machine之间以及与其他传感器之间的主要互连机制预计将基于以太网进行，其背后的原理是获得一致的平台视图，而不考虑可能使用的任何虚拟化技术。对功能应用程序的分布式，独立和敏捷开发的支持需要一种标准化的开发方法。AUTOSAR 自适应方法论涉及工作产品的标准化，用于描述诸如服务，应用程序，Machine及其配置之类的工件。

4）状态管理

状态管理是一个独特的功能集群（FC），主要用于特定于 ECU开发项目，并且通常最终实现由系统集成商执行。它负责 AUTOSAR 自适应平台的运行状态的所有方面，包括处理传入事件，确定这些事件/请求的优先级以设置相应的内部状态。

状态管理可以根据项目需求由一个或多个状态机组成。状态管理通过项目特定的 ara :: com Service Interface（由“Fields”组成）与自适应应用程序进行交互。状态管理和其他功能集群之间的交互应通过每个功能集群定义的标准化接口（IFC）来完成。

为了实现同步行为，在状态管理中可提供已定义的消息和应答消息，这些已定义的消息和应答消息在 ara :: com 方法和字段在“通信管理”的“通信组”范围内生成。同时，网络管理（NM）可以通过状态管理进行控制，因为部分网络的控制需要通过 SM 控制的 EM 的功能组状态与相关应用程序的集合进行协调，状态管理则可通过项目特定的 ARA:: com Service Interface（由“Fields”组成）与自适应应用程序进行交互，执行过程中可以实现包含设置功能组专用状态、激活/取消部分网络功能、关闭/重启Machine等相关的过程状态控制。

5）Manifest模型描述

Manifest仅仅作为AUTOSAR 一种模型描述，平台软件和应用软件的程序分别由执行管理根据 MachineManifest 和 Execution Manifest 信息确定。在开发项目中，大部分的ARXML会被自动视为Manifest。Manifest的描述是为了支持 AUTOSAR AP 产品的配置而创建的，并会搭载到 AUTOSAR AP 产品上，并可能与其他包含 Manifest 文件的可执行代码的工件（如二进制文件）结合使用。存在与Manifest 相关的模型元素，且这些元素在典型开发项目的不同阶段都具有相关性。

总体上Manifest定义细分为如下几个阶段：

其中，执行 Manifest 的目的是提供将应用程序实际部署到 AUTOSAR AP 所需的信息（包括启动配置应用程序实例和资源管理）。总体思路是保持应用程序软件代码与部署方案尽可能独立，以增加应用程序软件可以在不同部署方案中重用的几率。最终，自适应平台实例会运行在特定硬件Machine上。该过程包括配置网络连接并定义网络技术基本凭证、Service 发现技术配置、Machine状态定义等等。

6）通信网络

车载网络不断增长的带宽要求导致引入了以太网，该以太网提供更高的带宽并具有交换网络，与传统的车载通信技术（例如 CAN）相比，它可以更有效地传输长消息、实现点对点通信等。

通信管理负责分布式实时嵌入式环境中应用程序之间的所有通信，对于SOA的整个开发来说主要指面向服务的通信。通信管理软件为机器内通信以及机器间通信提供了使用此类服务的机制。可以在设计时、启动时或运行时建立通信伙伴之间的通信路径。该机制的重要组成部分是 Service Registry 中心，它充当中介实例为每个应用程序注册对应的服务，通过查询Service Registry来找到请求的服务，并且也是通信管理软件的一部分。

当前，通信管理支持 SOME /IP，DDS，IPC（进程间通信或任何其他自定义绑定）和 Signal PDU（基于信号的网络绑定）。

对于 ServiceMethods，Service Requester Proxies 提供了同步（阻止调用者直到服务器返回结果）和异步调用（被调用函数立即返回）的机制。

网络管理（NM）旨在通过状态管理进行控制，因为部分网络的控制需要通过 SM 控制的 EM 的功能组状态与相关应用程序的集合进行协调。

7）其他方面

• 诊断——管理代表基础层上 AdaptivePlatform 的功能集群。该配置基于经典平台的AUTOSAR 诊断提取模板（DEXT）。DoIP 是一种车辆发现协议，旨在与诊断基础架构（诊断客户端，生产/车间测试仪）进行车外通信。车载或远程诊断通常使用其他传输协议，因此提供了使用自定义传输层扩展平台的API。
• 时间同步­——当需要跨分布式系统的不同事件之间的关联时，不同应用程序和/或 ECU 之间的时间同步（TS）至关重要，以便能够及时跟踪此类事件或在准确的时间点触发它们。因此，为应用程序提供了时间同步 API，因此它可以检索与其他实体/ ECU 同步的时间信息。然后，通过不同的“Time Base Resources”（从现在开始称为 TBR）提供时间同步功能，这些“Time Base Resources”通过预构建配置存在于系统中。时间同步模块包括考虑启动行为、构造函数行为（初始化）、正常操作、错误处理等几个方面。
• 功能安全与信息安全驱动——AP 瞄准的系统通常需要某种级别的安全性，可能是最高级别。新概念和新技术的引入不应破坏这些要求，尽管要实现它并非易事。为了应对挑战，AP 结合了架构，功能和程序方法。该体系结构基于 SOA的分布式计算，从而使每个组件固有地变得更加独立且不受意外干扰；有助于实现 Safety 和 Security 的专用功能。
• 车载软件实时更新——新的车辆功能（例如高度自动驾驶）将在车辆中引入高度复杂且计算量大的软件，并且必须满足严格的完整性和安全性要求。这种软件可实现诸如环境感知和行为计划之类的功能，并将车辆集成到外部后端和基础架构系统中。由于不断发展的外部系统或改进的功能，需要在车辆的生命周期内更新车辆中的软件。

03. Autosar AP 在SOA的开发流程

除了应用程序设计和不同种类的Manifest 外，AUTOSAR 方法论还支持系统设计，它有可能在一个单一模型中描述将在系统中使用的两个 AUTOSAR 平台的软件组件。不同的 AUTOSAR 平台的软件组件可以以面向服务的方式相互通信。但是也有可能描述信号到服务的映射，以在面向服务的通信与基于信号的通信之间建立桥梁。

在SOA环境中， Client 和服务的 provider通过 服务接口和行为连接在一起。在开发服务期间，服务接口或行为可能会随时间而改变。因此，已引入服务合同 Contract Versioning 以区分服务的不同版本。AUTOSAR 自适应平台支持Contract 的 Versioning 设计，以用于服务的设计和部署阶段。

04.总结

在中央计算单元中，使用APAUTOSAR 架构可以满足一些模块化、动态化的需求。使用UCM（升级通信管理）功能集群，可以满足一些OTA的功能要求。 可以使用AP AUTOSAR满足运行时建立动态通信路径的需求。也可以使用PHM（平台健康管理）和Crypto（加密）满足一些Safety和Security的需求。同时，AP Autosar也包含有智能ECU和相应的技术驱动程序，且需要使用更多的计算能力。AP也支持应用程序的增量部署，在其中动态管理资源和通信，以减少软件开发和集成的工作量，从而缩短迭代周期，增量部署还支持探索性软件开发阶段。但是无论国内还是国外，对于这块研究的并不成熟，要真正应用于工程化量产项目的开发还有很长的路要走。