标签：AA AUTOSAR 架构 ara 简介 AP ECU Adaptive CP

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。