AUTOSAR两个主要架构简介

Posted 2023-04-05 ソフト開発王さん

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 功能。

汽车开放系统架构AUTOSAR

参考技术A 汽车开放系统架构AUTOSAR

AUTOSAR简介：

AUTOSAR(汽车开放系统架构)，汽车开放系统架构联盟是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外，AUTOSAR在确保产品及服务质量的同时，提高了成本效率。

AUTOSAR应用：

宝马集团自2001年即开始在称为BMW Standard Core的架构下，在ECU电子控制单元中运用标准化基础软件。该软件覆盖车辆管理系统各个层面的功能，包括执行(如车辆能量流管理系统、停车准备功能)，系统管理(如系统的编码与诊断)，到系统定制(如个性化定制功能，可设定特殊条件的服务定制功能)。

现在，应用于全新7系的BMW Standard Core软件系统通过AUTOSAR架构实现对车载网络、系统内存管理以及大部分的系统诊断功能。此外，全新BMW 7系所采用的多个ECU的运行系统与AUTOSAR架构相匹配，允许各应用程序独立运行。例如中央网关，该ECU确保了外部I/O系统(以太网和CAN总线)与内部I/O系统总线(CAN，MOST，FlexRay)间高速宽带连接。同时它还可以调节一些内核功能，如车况监测、系统编码和能量消耗检测等。

关于ECU电子控制单元未来的发展，宝马集团坚定地支持应用、推广AUTOSAR架构。一个精心制定的计划已经开始实施，相关的供应商也被纳入相关规划。针对驱动系统、底盘、安全系统、内部和车身的研发应用已经全面展开。

在Elmar Frickenstein看来，AUTOSAR架构的优势显而易见：“未来的车型将普遍受益于全行业统一的标准化程序，以及通用性、互换性更强的软件。AUTOSAR界面的标准化以及供应商通用工具软件的应用将促进该领域的进一步发展。

AUTOSAR在中国：

国内的各大汽车厂商、科研院校也越来越关注AUTOSAR带来的标准化的设计、开发、验证，从而大幅提高汽车电子的研发效率和研发质量。

一汽、长安等整车厂技术研究院也于2009年开始利用AUTOSAR标准的工具进行ECU的设计、开发、验证。

值得注意的是，普华基础软件股份有限公司（iSOFT），作为Autosar的成员，已经在中国联合上汽、一汽、长安、奇瑞等主要OEM和部分院校成立了CASA联盟，旨在中国推广和发展Autosar架构。普华已具备一些列基于Autosar的工具链，如OrientaisStudio，BSW配置工具。

汽车开放系统架构AUTOSAR @2019