Adaptive Platform（AP）

CP架构是BSW、RTE和应用层的三层架构，但是在AP架构中（上图），AP中的应用Adaptive Application（AA）被放置在AUTOSAR Runtime for Adaptive (ARA)之上。

AP ARA 提供了与 CP RTE 完全不同的接口，因此 CP SW-C 不能在代码级别用作 AA（反之亦然）。

机器可以是真正的处理器，也可以是虚拟机管理程序之类的虚拟机。 目前还没有严格的定义。

ARA相当于CP的RTE和BSW。 ARA 由 16 个功能单元块组成，称为功能集群 (FC)，大致分为以下两组。

Adaptive Platform Foundation：基于库的基本 AP 功能集合。 通过过程调用（无需进程即可实现）或机器中的进程间通信 (IPC) 从 AA 使用

Adaptive Platform Services：在 AP 中基于服务。 通过通信管理 (CM) 从 AA 使用

每个 AA/FC 都被实现为一个独立的进程，具有自己的逻辑内存空间或命名空间，或者它们的集合。 从 AA 中，通过指定的 C++ 格式接口访问上述两组的 FC。

除此之外，还可以使用 AA 中的任何附加服务，但在这种情况下，必须避免干扰功能和安全/安保。

AP 中的标准化方法与 CP 不同。 简单地说，定义了 AA 提供的 ARA 功能/服务，但它们的内部结构并没有定义 CP 的 BSW 层次结构的细节。

部分 FC 功能在当前版本中尚未实现，但会在未来版本中支持。

Adaptive Platform Foundation

首先，我将解释 Adaptive Platform Foundation，它是一组提供 AP 基本功能的库。

当使用 AA 中的这些时，进行过程调用（可以在没有过程的情况下实现）或通过机器中的 IPC（基于库）。

ara::com Communication Management（CM）

• 它是虚拟功能总线（VFB）中接口的主要实现。 AA之间的接口由于PSE51的限制不使用IPC，所以AA之间不能直接有接口。 相反，CM 充当那个接口。
• CM还负责实现进程内通信、进程间通信和机器间通信，还根据需要进行端到端保护(E2E)和安全通信(TLS、DTLS、SecOC和IPSec) ... 作为面向服务的通信，它支持机器本地的IPC，机器之间的SOME / IP（可扩展的面向服务的中间件IP）和DDS（实时系统的数据分发服务）。
• 正如稍后将在 NM 部分中描述的那样，开发正在以以太网支持的最高优先级进行。

ara::rest RESTful

• 启用 Web 服务的 HTTP/JSON 客户端使用的 REST（REpresentational State Transfer）通信。
• 它基于树形结构的消息负载（对象图）、URI 和请求方法（HTTP GET / POST）。

ara::tsync Time Synchronization

• 它控制ECU之间的时间同步（相当于CP中的StbM和EthTSyn）。
• 因此，X-by-Wire 和 Sensor Fusion 中的多个 ECU 之间的操作时间同步、ECU 之间的相互监控（带有时间戳）、安全通信中的新鲜度值（FV）同步以及重放攻击的欺骗对策等等

ara::core Core Types

核心类型定义了多个 FC 公共接口使用的公共类和特性。 主要与各种错误有关

ara::log Log and Trace（L&T）

• 对应CP中的Dlt，日志信息可以使用指定的协议（LT协议，参考文献[4]）在网络上传输，记录为文件，串行输出。
• 例如，这使得可以从外部引用 AP ECU 内部的行为（类似于 CP 中的 RTE VFB Tracing）

Adaptive Platform Services

接下来，我们将解释 Adaptive Platform Services，它是 AP 中的一组基础服务。 从 AA 使用这些时，它是通过通信管理 (CM)（基于服务）。

ara::sm State Management（SM）

• EM负责加载、启动和关闭FC和AA，而SM负责何时加载和启动，以及何时关闭。
• 另外，SM的主要作用是管理Machine中正常运行时的运行模式，类似于CP中ECU的运行模式管理。 AP 中 SM 与 EM 的关系类似于 CP 中 BswM 与 EcuM 的关系。

ara::diag Diagnostics, Diagnostic Management（DM）

• 根据 ISO 14229-1 (UDS) 提供诊断通信服务（相当于 CP 中的 Dcm）和事件存储器（相当于 CP 中的 Dem）。
• 诊断测试仪向ECU发送各种请求，在开发时读取ECU的内部状态，在ECU生产中写入制造日期和序列号，自动化各种测试，然后可以设置ECU变体，维护时读取故障代码（DTC），判断ECU故障或更换必要性，更新软件（如发送和接收更新数据），启用/禁用交通方式。

ara::s2s Signal to Service Mapping

• 为了在同一网络上建立基于CP的ECU和基于AP的ECU之间的通信，需要解决它们之间在通信方式上的差异。 
• 该服务通过将 CP 上基于信号的网络内容与 AP 上面向服务通信 (SoC) 的内容相关联来实现此目的。

ara::nm Network Management（NM）

• NM相当于CP的Nm及其下层总线类型专用的NM模块，配合AP的SM操作控制通信的开始和结束。
• 它涵盖了CP中使用的部分网络（PN），但目前它只兼容以太网（类似于CP的UDP NM和UdpNm）。

ara::ucm Update and Config Management（UCM）

• 关于自动驾驶要记住的一件事是更新。
• 例如，在导航系统中，如果修了一条新路，地图就需要更新。 
• UCM 对此负责。 UCM确认已安装软件的版本，接收软件更新数据，确认有足够的资源用于更新，实际更新处理（包括提供日志和进度信息），验证更新结果，并根据需要进行更新回滚
• 在安装或更新 AA 时，也会用到 UCM 功能。

标签：AA,AUTOSAR,架构,ara,简介,AP,ECU,Adaptive,CP
来源： https://blog.csdn.net/qq_18191333/article/details/123036142