AP AUTOSAR 平台设计总体框架全解

AUTOSAR 经典平台（CP）标准解决了深嵌式 ECU 的难题，而上述 ECU 的需求无法满足。因此，AUTOSAR 指定了第二个软件平台，即 AUTOSAR 自适应平台（AP）。AP主要提供高性能计算和通信机制，并提供灵活的软件配置，例如支持无线软件更新。专门为 CP 定义的功能（例如访问电信号和汽车专用总线系统）可集成到 AP 中，但不作为标准化的重点关注。

2.2技术驱动因素

背后有两大类技术驱动因素。一个是以太网，另一个是处理器。

车载网络不断增长的带宽需求导致了Ethernet的引入，Ethernet提供更高的带宽和交换网络，与传统的车载通信技术（如CAN）相比，可以更有效地传输长消息，点对点通信等。CP虽然支持以太网，但主要是为传统通信技术设计的，并且已经针对传统通信技术进行了优化，很难充分利用基于以太网的通信功能并从中受益。

同样，近年来，随着车辆变得越来越智能，对处理器的性能要求也大幅增长。多核处理器已经与 CP 一起使用，但对处理能力的需求需要的不仅仅是多核。具有数十到数百个内核的多核处理器、GPGPU（通用GPU）、FPGA和专用加速器正在兴起，因为它们提供的性能比传统MCU高出几个数量级。越来越多的内核压倒了CP的设计，CP 最初是为单核MCU设计的，尽管它可以支持多核。此外，随着计算能力的膨胀，即使在数据中心，电源效率也已经成为一个问题，实际上对于这些智能ECU来说，这一点更为重要。从半导体和处理器技术的角度来看，受波拉克规则的约束，物理上不可能无休止地增加处理器频率，扩展性能的唯一方法是使用多个内核并行执行。此外，众所周知，最佳的每瓦性能是通过混合使用不同的计算资源（如多核、协处理器、GPU、FPGA 和加速器）实现的。这被称为异构计算 - 现在正在HPC（高性能计算）中利用，这些内容无疑远远超出了CP的范围。

还值得一提的是，处理器和更快的通信具有综合效应。随着越来越多的处理元件像多核处理器一样被组合在单个芯片中，这些处理元件之间的通信正变得比传统的ECU间通信更快、更高效。这是通过新型处理器互连技术（如片上网络（NoC））实现的。芯片内更高处理能力和更快通信的这种综合效应也促使人们需要一个可以扩展不断增长的系统要求的新平台。

2.3平台适应性 -特性

AP的特征是由第3.1节和第3.2节中概述的因素决定的。这种格局不可避免地需要更多的计算能力，而技术趋势为满足这些需求提供了基准。然而，HPC在安全相关字段的空间，虽然功率和成本效益也很重要，但本身就带来了各种新的技术挑战。

为了解决这些问题，AP采用了传统上ECU无法充分利用的各种成熟技术，同时允许AP实现的最大自由度来利用创新技术。

2.3.1 C++

从上到下，应用可以C++编程。它现在是在软件行业和学术界的性能关键型复杂应用中开发新算法和应用软件的首选语言。如果正确使用，应该可以更快地适应新算法，并提高应用开发生产力。

2.3.2 SOA

为了支持复杂的应用，同时在处理分发和计算资源分配时允许最大的灵活性和可扩展性，AP 遵循面向服务的架构（SOA）。SOA 基于这样一个概念，即系统由一组服务（其中一个服务可以依次使用另一个服务）以及根据其需要使用一个或多个服务的应用组成。通常，SOA表现出系统化系统的特征，AP也具有这些特性。例如，服务可能驻留在应用同时运行的本地ECU上，也可以驻留在远程ECU上，该ECU也正在运行AP的另一个实例。在这两种情况下，应用代码是相同的，通信基础结构将处理提供透明通信的差异。看待这种架构的另一种方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表了同一个概念。这种消息传递、基于通信的架构还可以受益于快速和高带宽通信（如以太网）的兴起。

2.3.3并行处理

分布式计算本质上是并行的。由于不同的应用使用一组不同的服务，SOA 具有这一特征。提供并行处理能力的进步或多核处理器和异构计算提供了利用计算能力来匹配固有并行性的技术机会。因此，随着多核异构计算技术的进步，AP具有扩展其功能和性能的架构能力。事实上，硬件和平台接口规范只是等式的一部分，操作系统/虚拟机管理程序技术和开发工具（如自动并行化工具）的进步也至关重要，这将由AP提供商和行业/学术生态系统来实现。AP也旨在适应这些技术。

2.3.4 利用现有标准

重新发明轮子是没有意义的，特别是在涉及规格而不是实现时。与第3.3.1节中所述，AP采取重用和调整现有开放标准的策略，以促进AP本身的更快发展，并从现有标准的生态系统中受益。因此，在开发AP规范时，一个关键的重点不是随便引入现有标准已经提供的新替换功能。例如，这意味着不会因为现有标准提供了所需的功能而随意引入新接口，但接口表面上不容易理解。

2.3.5安全

AP目标系统通常需要一定程度的安全性和安全性，可能处于最高水平。引入新概念和技术不应破坏这些要求，尽管实现这些要求并非易事。为了应对这一挑战，AP 结合了架构、功能和过程方法。该架构基于SOA的分布式计算，其本质上使每个组件更加独立且不受意外干扰，专用功能有助于实现功能安全性和信息安全性，以及诸如C++编码指南之类的指南，这有助于安全可靠地使用C++等复杂语言。

2.3.6动态规划

AP支持应用的增量部署，其中资源和通信是动态管理的，以减少软件开发和集成的脆弱性，从而实现较短的迭代周期。增量部署还支持探索性软件开发阶段。

对于产品交付，AP 允许系统集成商精细限制动态行为，以消除不必要的或不良影响的风险，从而实现安全鉴定。应用的动态行为将受到执行清单中所述的约束的限制（请参见第 4.6 节）。多个应用的清单的相互作用可能在设计时就已经导致了这种情况。然而，在执行时资源和通信路径的动态分配只能以定义的方式实现，如在配置范围内。

AP 的实现可能会进一步从软件配置中删除动态功能以供生产使用。动态规划的示例可以是：

服务发现过程的预先确定
仅将动态内存分配限制为启动阶段
除基于优先级的调度外，还具有公平的调度策略
固定进程分配到 CPU 内核
仅访问文件系统中预先存在的文件
应用对 AP API 使用的约束
仅执行经过身份验证的代码

2.3.7敏捷开发

虽然没有直接反映在平台功能中，但AP旨在适应不同的产品开发流程，特别是基于敏捷的流程。对于基于敏捷的开发，至关重要的是，系统的底层架构是可增量扩展的，并且可在部署后更新系统。AP 的架构应该允许这样做。作为概念证明，AP规范和演示（AP的演示实现）都是用Scrum开发的。

2.4集成经典、自适应和非AUTOSAR ECU

如前几节所述，AP 不会取代 IVI/COTS 中的 CP 或非 AUTOSAR 平台。相反，它将与这些平台和外部后端系统（如路边基础设施）进行交互，以形成一个集成系统（参见图 2.1 和 2.2）。例如，CP已经包含了AP支持的某些/ IP以及其他原生协议。

图 2.1：不同平台的示例性部署

图 2 . 2 ：AP 和 CP 的示例性交互

2.5规范范围

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

03. 架构

3.1逻辑架构

3.1.1环境

图 3.1 显示了 AP 的架构。自适应应用（AA）运行在 ARA（自适应应用的 AUTOSAR 运行时）之上。ARA由功能集群提供的应用接口组成，这些接口属于自适应平台基础或自适应平台服务。自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。任何AA也可以向其他AA提供服务，如图中所示为非平台服务。

功能集群的接口，无论是自适应平台基础还是自适应平台服务，从AA的角度来看都是无所谓的 - 它们只提供指定的C++接口或AP将来可能支持绑定的任何其他语言的接口。在接口下层确实存在差异。另外请注意，在 ARA 接口下，包括在 AA 上下文中调用的 ARA 库，可以使用 ARA 以外的其他接口来实现 AP 规范，这取决于 AP 实现的设计。

图 3.1：AP 架构逻辑视图

请注意，图 3.1 包含不属于当前 AP 版本的功能集群，以便更好地了解整体结构。此处未显示的其他新功能集群很可能在 AP 的未来版本中添加。

3.1.2语言绑定、C++标准库和 POSIX API

这些 API 的语言绑定基于C++，C++标准库也可作为 ARA 的一部分提供。关于OS API只有PSE51接口，POSIX标准的singleprocess配置文件作为ARA的一部分提供。选择 PSE51 是为了为现有的 POSIX 应用提供可移植性，并实现应用之间的免干扰性。

请注意，C++标准库包含许多基于 POSIX 的接口，包括多线程 API。建议不要将C++标准库线程接口与本机 PSE51 线程接口混合使用，以避免复杂情况。遗憾的是，C++标准库并未涵盖所有 PSE51 功能，例如设置线程调度策略。在这种情况下，可能需要结合使用这两个接口。

3.1.3应用启动和关闭

应用的生命周期由执行管理（EM）管理。应用的加载/启动是使用 EM 的功能进行管理的，并且需要在系统集成时或运行时进行适当的配置才能启动应用。事实上，从EM的角度来看，除了EM本身之外，所有功能集群都是应用，它们也以相同的方式启动。图 3.2 说明了 AP 内部和 AP 上不同类型的应用。

图 3.2：应用

请注意，EM 不会决定应用启动或终止的时间和时间。一种特殊的 FC，称为状态管理（SM）控制器，根据系统的设计命令 EM，仲裁不同的状态，从而控制整体系统行为。由于这里的系统是指整个机器AP及其应用正在运行，因此实现的内部行为是特定于项目的。SM 还与其他 FC 交互，以协调整体机器行为。SM 应仅使用标准 ARA 接口，以保持不同 AP 堆栈实现之间的可移植性。

3.1.4应用交互

关于AA之间的交互，PSE51不包括IPC（进程间通信），因此AA之间没有直接的接口进行交互。通信管理（CM）是唯一的显式接口。CM 还为机器内部通信和机器间通信提供面向服务的通信机制，这对应用是透明的。CM 处理服务请求/响应的路由，而不管服务和客户端应用的拓扑部署如何。请注意，其他ARA接口可能会在内部触发AA之间的交互，但是这不是一个显式通信接口，而只是各个ARA接口提供的附件的副产品。

3.1.5非标准接口

AA 和功能群集可以使用任何非标准接口，前提是它们不与标准 AP 功能冲突，并且符合项目的安全/安保要求。除非它们是纯应用本地运行时库，否则应注意此类应用方式保持在最低限度，因为这将影响软件对其他AP实现的可移植性。

3.2 物理架构

[1] 这里讨论了AP的物理架构。请注意，本节中的大多数内容仅用于说明目的，并不构成 AP 的正式需求规范，因为 AP 的内部结构是由具体实现定义的。对 AP 实现的任何正式要求都已明确说明。作为附加信息来源请参阅 [4]，其中更详细地描述了 AP 内部架构。

3.2.1 OS、进程和线程

AP 操作系统需要提供多进程 POSIX 操作系统功能。每个 AA 都实现为一个独立的进程，具有自己的逻辑内存空间和命名空间。请注意，单个 AA 可能包含多个进程，这可以部署到单个 AP 实例上，也可以分布在多个 AP 实例上。从模块组织的角度来看，每个进程都是由操作系统从可执行文件中实例化的。可从单个可执行文件实例化多个进程。此外，AA 可能构成多个可执行文件。

功能群集通常也作为进程实现。功能集群也可以通过单个进程或多个（子）进程实现。自适应平台服务和非平台服务也作为流程实现。

所有这些进程都可以是单线程进程或多线程进程。但是，它们可以使用的 OS API 会有所不同，具体取决于进程所属的逻辑层。如果他们是在ARA上运行的AA，那么他们应该只使用PSE51。如果进程是功能群集之一，则可以自由使用任何可用的操作系统接口。

总之，从操作系统的角度来看，AP和AA只是一组进程，每个进程包含一个或多个线程 - 这些进程之间没有区别，尽管AP的实现可以提供任何类型的分区。这些进程确实通过 IPC 或任何其他可用的操作系统功能相互交互。请注意，AA 进程不能直接使用 IPC，只能通过 ARA 进行通信。

3.2.2 基于库或基于服务的功能集群实现

如图 3.1 所示，功能群集可以是自适应平台基础或自适应平台服务。如前所述，这些通常都是过程。为了让他们与AA（也是进程）进行交互，他们需要使用IPC。有两种替代设计来实现这一点。一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。另一种是“基于服务”的设计，其中进程使用通信管理功能并具有链接到AA的代理库调用。通信管理接口在AA进程和服务器进程之间协调IPC。请注意，它是 AA 仅通过通信管理直接执行 IPC，还是通过代理库与服务器直接 IPC 混合使用，这是实现定义的。

为功能集群选择设计的一般准则是，如果仅在AP实例中本地使用，则基于库的设计更合适，因为它更简单有效。如果以分布式方式从其他AP实例使用它，建议采用基于服务的设计，因为无论客户端AA和服务的位置如何，通信管理都能提供透明的通信。属于 Adaptive Platform Foundation 的功能集群是“基于库的”，自适应平台服务是“基于 Service 的”，顾名思义是正确的。

最后，请注意, 只要FC的实现满足FC定义的RS和SWS，FC实现允许不具有进程而是以库的形式实现在AA进程的上下文中运行，在这种情况下，AA 和 FC 之间的交互将是常规过程调用，而不是如前所述基于 IPC 的交互。

3.2.3功能集群之间的交互

通常，功能集群可以以特定于AP实现的方式相互交互，因为它们不绑定到ARA接口，例如PSE51限制了IPC的使用。它确实可能使用其他功能集群的ARA接口，这些接口是公共接口。功能群集的一个典型交互模型是使用功能群集的受保护接口来提供实现功能群集的特殊功能所需的特权访问。

此外，从AP18-03开始，引入功能间集群（IFC）接口的新概念。它描述了 FC 提供给其他 FC 的接口。请注意，它不是 ARA 的一部分，也不构成 AP 实现的正式规范要求。提供这些是为了通过阐明FC之间的交互来促进AP规范的开发，并且它们还可以为AP规范的用户提供更好的AP架构视图。这些接口在相应的FC SWS的附件中进行了描述。

3.2.4机器/硬件

AP 将运行它的硬件视为机器。基本原理是实现一致的平台视图，而不管可能使用的任何虚拟化技术。机器可以是真实的物理机、完全虚拟化的机器、半虚拟化的操作系统、操作系统级虚拟化容器或任何虚拟化环境。

在硬件上，可以有一台或多台机器，并且只有一台 AP 实例在一台机器上运行。通常认为，这种“硬件”包括单个芯片，托管一台或多台机器。但是，如果AP实现允许，则多个芯片形成一台机器也是可能的。

3.3方法论和清单

支持功能应用的分布式、独立和敏捷开发需要对开发方法采用标准化的方法。AUTOSAR自适应方法涉及工作产品的标准化，用于描述服务，应用，机器及其配置等结构；以及定义这些工作产品如何交互以实现设计信息交换的相应任务，实现为自适应平台开发产品所需的各种活动的设计信息交换。

图 3.3 说明了如何实施适应性方法的概述草案。有关这些步骤的详细信息，请参阅 [3]。

图 3.3：AP 开发工作流

3.4清单

清单表示一段 AUTOSAR 模态描述，该描述是为支持 AUTOSAR AP 产品的配置而创建的，该描述将上载到 AUTOSAR AP 产品，可能与包含清单适用的可执行代码的其他项目（如二进制文件）结合使用。

清单的使用仅限于 AUTOSAR AP。但是，这并不意味着在面向 AUTOSAR AP 的开发项目中生成的所有 ARXML 都将自动被视为清单。事实上，AUTOSAR AP通常不专门用于车辆项目。

一辆典型的车辆很可能还配备了许多在AUTOSAR CP上开发的ECU，因此，整个车辆的系统设计必须涵盖两者 - 基于AUTOSAR CP构建的ECU和在AUTOSAR AP之上创建的ECU。

原则上，可以将术语“清单”定义为在概念上只有一个“清单”，并且每个部署方面都将在此上下文中处理。这似乎不合适，因为很明显，与清单相关的模型元素存在于典型开发项目的完全不同的阶段中。

出于这方面的主要动机，即在应用设计旁边，有必要将术语清单的定义细分为三个不同的分区：

应用设计这种描述指定了适用于为 AUTOSAR AP 创建应用软件的所有与设计相关的方面。不一定需要部署到 adaptive 平台机器，但应用设计有助于在执行清单和服务实例清单中定义应用软件的部署。
执行清单他的清单类型用于指定在 AUTOSAR AP 上运行的应用的部署相关信息。执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码集成到机器上。
服务实例清单此类清单用于指定如何根据基础传输协议的要求配置面向服务的通信。服务实例清单与实际的可执行代码捆绑在一起，该代码实现面向服务的通信的相应用法。
机器清单这种清单应该描述与部署相关的内容，这些内容仅适用于运行 AUTOSAR AP 的基础机器（即机器上没有任何运行应用）的配置。机器清单与用于建立 AUTOSAR AP 实例的软件捆绑在一起。

不同种类的清单的定义（和用法）之间的时间划分导致的结论是，在大多数情况下使用不同的物理文件来存储三种清单。

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

3.5应用设计

应用设计描述了适用于为 AUTOSAR AP 创建应用软件的所有与设计相关的建模。

应用设计侧重于以下几个方面：

用于对软件设计和实现的信息进行分类的数据类型
服务接口是面向服务通信的关键元素
定义应用如何访问面向服务的通信
持久性接口是访问持久性数据和文件的关键元素
定义应用如何访问持久性存储
定义应用如何访问文件
定义应用如何访问加密软件
定义应用如何访问平台运行状况管理
定义应用如何访问时基
序列化属性，用于定义如何为网络上的传输序列化数据的特征
客户端和服务器功能的说明
对应用进行分组，以便于软件的部署。

应用设计中定义的工件独立于应用软件的特定部署，因此便于在不同的部署方案中重用应用实现。

3.6执行清单

执行清单的目的是提供将应用实际部署到 AUTOSAR AP 上所需的信息。

一般的想法是使应用软件代码尽可能独立于部署方案，以增加应用软件可以在不同部署方案中重用的几率。

通过执行清单，应用的实例化受到控制，因此可以

在同一台机器上多次实例化同一应用软件，或
将应用软件部署到多台机器，并为每台机器实例化应用软件。

执行清单侧重于以下几个方面：

用于定义如何启动应用实例的启动配置。启动包括启动选项和访问角色的定义。每个启动可能依赖于机器状态和/或功能组状态。
资源管理，特别是资源组分配。

3.7服务实例清单

在网络上实现面向服务的通信需要特定于所用通信技术（例如 SOME/IP）的配置。由于通信基础结构在服务提供者和服务请求者上的行为应相同，因此服务的实现必须在两端兼容。

服务实例清单侧重于以下几个方面：

服务接口部署，用于定义服务在特定通信技术上的表示方式。
服务实例部署，用于为特定提供和必需的服务实例定义通信技术所需的凭据。
端到端保护的配置
安全防护的配置
日志和跟踪的配置

3.8机器清单

机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例。

机器清单侧重于以下几个方面：

网络连接的配置和网络技术的基本凭据的定义（例如，对于以太网，这涉及静态IP地址的设置或DHCP的定义）。
服务发现技术的配置（例如，对于 SOME/IP，涉及要使用的 IP 端口和 IP 多播地址的定义）。
已用机器状态的定义
所用功能组的定义
自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
加密平台模块的配置
平台运行状况管理的配置
时间同步的配置
文档化可用的硬件资源（例如，有多少 RAM 可用;有多少个处理器内核可用）

04. 操作系统

4.1概述

操作系统（OS）负责自适应平台上所有应用的运行时调度、资源管理（包括监管内存和时间限制）和进程间通信。该操作系统与执行管理结合使用，执行管理负责平台初始化，并使用操作系统执行应用的启动和关闭。

自适应平台不会为高性能处理器指定新的操作系统。相反，它定义了供自适应应用使用的执行上下文和操作系统接口（OSI）。

OSI 规范包含作为 ARA（自适应应用的标准应用接口）一部分的应用接口。操作系统本身很可能提供执行管理启动应用所需的其他接口，例如创建进程。但是，提供此类功能的接口等不能作为ARA的一部分使用，并且它被定义为依赖于平台实现。

OSI 提供 C 和 C++ 接口。对于 C 程序，应用的主要源代码业务逻辑包括 POSIX 标准中定义的 C 函数调用，即 IEEE1003.13 [1] 中定义的 PSE51。在编译过程中，编译器确定平台操作系统中的哪个C库提供这些C函数，并且应用可执行文件应在运行时链接。对于C++程序，应用软件组件的源代码包括C++标准及其标准C++库中定义的函数调用。

4.2 POSIX

市场上有几种操作系统，例如 Linux，提供符合POSIX标准的接口。但是，与平台服务和基础相比，应用需要对操作系统使用更受限制的 API。

一般假设是用户应用应使用PSE51作为操作系统接口，而平台应用可以使用完整的POSIX。如果在应用级上需要更多功能，则它们将从 POSIX 标准中获取，并且尽可能不新指定。

自适应平台基础和自适应平台服务功能的实现可能会使用进一步的 POSIX 调用。特定调用将留给实现者，而不是标准化的。

4.3调度

操作系统提供多线程和多进程支持。标准调度策略由 POSIX 标准定义，SCHED_FIFO和 SCHED_RR。允许使用其他调度策略（如SCHED_DEADLINE或任何其他操作系统特定策略），但限制是这些策略可能无法跨不同的 AP 实现进行移植。

4.4内存管理

多进程支持背后的原因之一是实现不同功能集群和AA之间的“免干扰性”。操作系统的多进程支持强制每个进程位于独立的地址空间中，与其他进程分开并受到保护。同一可执行文件的两个实例在不同的地址空间中运行，以便它们可以在启动时共享同一入口点地址和代码以及数据值，但是，数据将位于内存中的不同物理页中。

4.5设备管理

设备管理在很大程度上是特定于操作系统的。有意为之，自适应平台基础倾向于创建服务以公开主要系统功能。

虽然目前没有计划标准化设备驾驶员本身的具体 API，但此类驾驶员实现的更高级功能可以通过自适应平台服务实现标准化。

4.6网络

多台机器之间以及与其他传感器之间的主要互连机制预计将基于以太网。因此，清楚地描述了基于 TCP/IP 和 UDP/IP 的协议的使用。因此，预计操作系统将提供这样的网络堆栈。

通过使用通信管理，应用将透明地受益于网络支持。作为自适应平台基础的一部分， VLAN、IPSEC 等其他功能正在实现系统内部和系统之间的安全通信。

05. 执行管理

5.1概述

执行管理负责系统执行管理的各个方面，包括自适应平台的初始化和进程的启动/关闭。执行管理与操作系统结合使用，以配置进程的运行时规划。

5.2系统启动

当机器启动时，操作系统将被初始化，随后执行管理将作为平台的初始过程启动。然后，自适应平台基础的其他平台级流程（代表功能集群）由执行管理启动。在自适应平台基础启动并运行后，执行管理将继续启动自适应应用的流程。平台级和应用级进程的启动顺序由执行管理根据机器清单和执行清单中指定的依赖项确定。

图 5.1：AP 启动顺序

自适应应用可以由多个可执行文件元素组成，这些元素通常对应于文件系统上的可执行文件。每个可执行文件可以有多个进程配置（以及启动配置），具体取决于可执行文件处于活动状态的功能组状态。

执行管理可选地支持经过身份验证的启动，其中从信任锚启动自适应平台，同时保持信任链。在经过身份验证的启动期间，执行管理将验证应用的真实性和完整性，并在检测到违规时（可选）阻止其执行。通过这些机制建立一个受信任的平台。

5.3执行管理职责

执行管理负责自适应平台执行管理和应用执行管理的各个方面，包括：

平台生命周期管理执行管理作为自适应平台启动阶段的一部分启动，负责自适应平台和已部署应用的初始化。
应用生命周期管理执行管理负责已部署应用的有序启动和关闭。执行管理根据机器清单和执行清单中的信息确定已部署的应用集，并根据声明的执行依赖关系派生启动/关闭顺序。根据机器状态和功能组状态，已部署应用的进程在自适应平台启动期间或之后启动，但是，并非所有应用都将立即开始活动工作，因为许多应用将向其他应用提供服务，因此等待并“侦听”传入的服务请求。

执行管理不负责应用的运行时调度，因为这是操作系统的责任。但是，执行管理负责配置 OS，以使 OS 能够根据执行管理从机器清单和执行清单中提取的信息执行必要的运行时规划。

5.4确定性执行

确定性执行提供了一种机制，使得使用给定输入数据集的计算始终产生一致的输出，而不考虑干扰。执行管理区分时间和数据确定性。前者声明输出始终在截止时间之前生成，而后者是指从相同的输入数据集和内部状态生成相同的输出。

执行管理提供的支持侧重于数据确定性，因为时间确定性是通过提供足够的资源来处理的。对于数据确定性，执行管理提供了确定性客户端 API，以支持对过程内部周期、确定性工作线程池、激活时间戳和随机数的控制。确定性客户端与通信管理交互，以将数据处理与周期激活同步。确定性客户端支持的 API 及其与应用的关联如图 5.2 所示。

图 5.2：确定性客户端

除了进程本地确定性客户端之外，执行管理还支持确定性SyncMaster，该管理器提供多个确定性客户端实例之间的协调，以确保其确定性执行是同步的。

5.5资源限制

自适应平台允许在同一台机器上执行多个自适应应用，因此确保不受干扰是系统属性。因此，行为不正确的自适应应用应受到它影响的其他应用的能力的限制，例如，应防止应用进程消耗比指定更多的CPU时间，因它会对其他应用的正常运行产生后续影响。

执行管理通过配置一个或多个将应用进程分配到的资源组来支持不受干扰。然后，为每个资源组分配一个 CPU 时间或内存限制，以允许限制应用的可用资源。

5.6应用恢复

执行管理负责进程启动/停止的状态相关管理，因此它必须具有启动和停止进程的特殊权限。平台运行状况管理监视进程，如果任何进程的行为不在指定参数范围内，则可能会触发恢复操作。恢复操作由集成商根据平台运行状况管理的软件架构要求定义，并在执行清单中进行配置。

5.7可信平台

为了保证系统的正确功能，确保在平台上执行的代码具有合法来源至关重要。保留此属性允许集成商构建受信的平台。

实现可信平台的系统的关键属性是信任锚（也称为信任根）。信任锚通常被实现为存储在安全环境中的公钥，例如在不可修改的持久内存或 HSM 中。

系统设计人员负责确保至少系统从信任锚开始，并且信任一直保持到执行管理启动。根据系统设计人员为建立信任链而选择的机制，在系统启动的此时，可能已经检查了整个系统的完整性和真实性。但是，如果系统设计人员仅确保已执行的软件已检查完整性和真实性，则执行管理在接管系统控制权时将接管继续信任链的责任。在这种情况下，系统集成商负责确保正确配置执行管理。

将信任从信任锚传递到操作系统和自适应平台（即建立信任链）的一个示例可能如下所示：信任锚 - 根据定义，作为一个真实的实体 - 在启动引导加载程序之前对引导加载程序进行身份验证。在引导过程的每个后续步骤中，应首先对要启动的可执行文件进行身份验证。这种真实性检查应由已经过身份验证的实体完成，即真实性检查可以由先前启动的可执行文件或由某些外部实体（如HSM）完成，例如示例。

操作系统真实启动后，它将启动执行管理作为其首批进程之一。在启动执行管理之前，操作系统应确保执行管理的真实性已经过验证，并且是经过身份验证的，因此是值得信赖的实体。

注意：如果信任锚本身的功能（根据定义是真实的）未检查身份验证，则在应用可执行文件之前，必须对应用于验证可执行文件真实性的软件进行身份验证。例如，如果加密 API 用于验证可执行文件的身份验证，则加密 API 本身在使用之前应由某个受信任的实体进行身份验证。

执行管理现在接管了在启动自适应应用之前对其进行身份验证的责任。但是，验证可执行代码的完整性和真实性的可能性不止一种。在 [6] 中，提供了完成此任务的可能机制列表。

06.状态管理

状态管理是一个独特的功能集群，主要用于特定于ECU开发项目，通常，最终实现将由系统集成商执行。它负责 AUTOSAR 自适应平台操作状态的所有方面，包括处理传入事件、确定这些事件/请求的优先级以设置相应的内部状态。状态管理可能由一个或多个状态机组成，具体取决于项目需求。

状态管理通过特定于项目的 ara::com 服务接口与自适应应用进行交互，该接口由“字段”组成，如下所述。状态管理与其他功能集群之间的交互应通过每个功能集群定义的标准化接口来完成。

图 6.1：状态管理交互

状态管理可以请求以下效果：

可以请求将功能组设置为专用状态
（部分）可以请求取消/激活网络
可以请求关闭或重新启动机器
其他自适应（平台）应用的行为可能会受到影响
可以执行特定于项目的操作
从平台运行状况管理或执行管理通知（监督）错误中恢复
根据诊断请求，根据诊断地址执行项目特定的重置
准备和验证软件集群，以便根据更新和配置管理中的请求进行安装、更新或删除
影响正在运行的进程的行为，以实现机器（部件）内的同步行为（例如电源模式）

为了实现同步行为，状态管理通过通信管理的通信组的范围生成ara::com 方法和字段，提供定义的消息和回复的消息。

状态管理通过 ara::com 提供一组“触发器”和“通知程序”字段。SM 实质上侦听“触发器”，并在内部执行特定于实现的统计处理，并为“通知程序”字段（如果有）提供结果。

由于状态管理功能至关重要，因此必须通过 IAM（身份和访问管理）来保护来自其他功能集群或应用的访问。状态管理由平台运行状况管理监视和监督。

状态管理功能是高度特定于项目的，AUTOSAR 决定暂时不为自适应平台指定经典平台 BswM 等功能。计划仅指定一组基本服务接口，并将行为仲裁逻辑封装到特定项目的代码中。

仲裁逻辑代码可以单独开发，也可以（部分）基于标准化的配置参数生成。

07. 通信管理

7.1概述

通信管理适用于分布式实时嵌入式环境中应用之间通信的各个方面。

背后的概念是从实际机制中抽象出来，以查找和连接通信伙伴，以便应用软件的实施者可以专注于其应用的特定目的。

7.2 面向服务的通信

服务的概念是指向应用提供的功能超出了基本操作软件已经提供的功能。通信管理软件提供了为机器内通信以及机器间通信提供或使用此类服务的机制。

服务由以下各项组合组成：

事件
方法
字段

通信参与者之间的通信路径在设计、启动或运行时建立。该机制的一个重要组成部分是充当代理实例的服务注册表，也是通信管理软件的一部分。

图 7.1：面向服务的通信

提供服务的每个应用都在服务注册表中注册这些服务。若要使用服务，应用需要通过查询服务注册表来查找请求的服务，此过程称为服务发现。

7.3语言绑定和网络绑定

通信管理提供了标准化的方法，即向应用实现者提供定义的服务（上层，语言绑定）以及服务在网络上的相应表示形式（下层，网络绑定）。这确保了源代码的可移植性和跨平台不同实现的编译服务的可比较性。

语言绑定定义如何使用目标编程语言的便捷功能将服务的方法、事件和字段转换为可直接访问的标识符。性能和类型安全（只要目标语言支持）是主要目标。因此，语言绑定通常由服务接口定义馈送的源代码生成器实现。

Figure 8.2：示例语言和网络绑定

网络绑定定义如何序列化已配置服务的实际数据并将其绑定到特定网络。它可以基于通信管理配置（AUTOSAR 元模型的接口定义）实现，方法是解释生成的特定于服务的配方或直接生成序列化代码本身。目前，通信管理支持 SOME/IP、DDS、IPC（进程间通信或任何其他自定义绑定）、信号 PDU（基于信号的网络绑定）和基于信号的静态网络绑定。

本地服务注册表也是网络绑定的一部分。

请注意：语言绑定和网络绑定之间的接口被视为通信管理软件中的专用接口。因此，定义此接口的规范目前超出了范围。尽管如此，鼓励平台供应商为其软件独立定义这样的接口，以便轻松实现其他语言绑定，而不是在其平台实现中与其他网络绑定一起C++。

7.4 C++语言绑定的生成代理和骨架

C++语言绑定的上层接口提供 AUTOSAR 元模型的接口说明中定义的服务的面向对象映射。

生成器是通信管理软件开发工具的一部分，可生成C++类，这些类包含每个相应服务的字段、事件和方法的类型安全表示。

在服务实现端，这些生成的类被命名为“服务提供框架”。在客户端，它们称为服务请求代理。

对于服务方法，服务请求代理提供同步（在服务器返回结果之前阻止调用方）和异步调用（被调用的函数立即返回）的机制。调用方可以并行启动其他活动，并在服务器的返回值通过 Core Type ara::core::Future 的特殊功能可用时接收结果（请参见第 16.1.4 节）。

可以配置平台实现，以便生成器创建模型类，以便在相应的服务器尚不可用时轻松开发客户端功能。相同的机制也可用于对客户端进行单元测试。

虽然代理类可以由客户端直接使用，但C++绑定的服务提供框架只是抽象基类。服务实现应派生自生成的基类并实现相应的功能。

ara::com的接口还可以为安全相关的E2E保护通信提供代理和骨架。这些接口的设计旨在确保与应用的兼容性，无论 E2E 保护是打开还是关闭。

7.5静态和动态配置

通信路径的配置可以在设计时、启动时或运行时进行，因此被视为静态或动态：

全静态配置根本不需要服务发现，因为服务器会知道所有客户端且客户端都知道服务器。
应用代码无发现客户端知道服务器，但服务器不知道客户端。事件订阅是应用中唯一的动态通信模式。
应用全服务发现在配置时没有已知的通信路径。用于服务发现的 API 允许应用代码在运行时选择服务实例。

7.6服务协定版本控制

在 SOA 环境中，服务的客户端和提供者依赖于涵盖服务接口和行为的契约。在服务开发过程中，服务接口或行为可能会随时间而变化。因此，引入了服务协定版本来区分服务的不同版本。AUTOSAR Adaptive 平台支持服务的设计和部署阶段的协定版本控制。此外，客户端的“服务发现”应配置为支持版本向后兼容性。这意味着，如果客户端服务版本与客户端所需的服务版本向后兼容，则这些服务可以连接到不同版本的服务提供者。

7.7 原始数据流接口

除了面向服务的通信外，通信管理还提供了一个独立的API，用于处理指向外部ECU的原始二进制数据流，例如ADAS系统中的传感器。该 API 是静态的，它为客户端应用实现功能建立与服务器的通信通道，并为服务器应用实现等待来自客户端的传入连接的功能。该 API 为客户端和服务器提供用于关闭通信通道，以及通过通信通道读取和写入原始数据（字节流）的功能。原始数据流通道可由集成商通过应用部署信息进行配置，例如包含网络端点信息和所选协议。目前，TCP/ IP socket用作传输层，将来可添加其他替代方案。原始数据流接口在命名空间 ara::com::raw 中可用。

08. 诊断

8.1概述

诊断管理（DM）实现了基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）的ISO 14229-5（UDSonIP）。

诊断管理表示基础层上自适应平台的功能群集。

该配置基于经典AUTOSAR平台的诊断提取模板（DEXT）。

支持的传输层是 DoIP。DoIP 是一种虚拟发现协议，设计用于与诊断基础结构（诊断客户端、生产/车库测试人员）进行板外通信。

车载或远程诊断通常使用其他传输协议，因此提供了一个API来扩展具有自定义传输层的平台。

UDS通常用于车辆的生产和车库内，以便能够修理车辆。

8.2软件集群

原子可更新/可扩展部件由软件集群s （SWCL）管理。软件集群涵盖与更新已安装或部署一组特定新功能/应用相关的所有内容。因此，自适应诊断管理器支持为每个已安装的软件集群提供自己的诊断地址。但它也支持整个机器的单个诊断地址或两者之间的任何诊断部署。因此，自己的诊断地址始终具有自己的诊断服务实例。每个软件集群自己的诊断服务实例也为诊断提供了独立的开发文件，例如自己的独立ODX文件。请注意，此软件集群还与 UCM 的软件包相结合，以便软件集群可以更新或引入新机器。

8.3诊断通信子集群

诊断通信子集群实现诊断服务（如经典平台的 DCM）。目前，支持的服务有限，但对更多 UDS 服务的支持将在将来的版本中扩展。

DM 支持根据 ISO 14229-1 处理多客户端。可满足现代车辆架构的需求，包括用于数据收集的多个诊断客户端（测试仪），从后端访问以及最后的一些经典车库和生产用例。

8.4自适应应用中的诊断（AA）

DM分发器作为诊断服务接收诊断请求（如例程控制或DID服务）到相应AA的映射提供端口。

为了实现这一点，AA需要提供专门的诊断端口接口。

8.5类型接口与通用接口

诊断端口接口有不同的抽象级可用：

例程控件消息可用作
- 类型化接口 API 签名包括所有请求和响应消息参数及其基元类型。DM 负责序列化。此 API 特定于特定的例程控件消息。
- 通用接口 API 签名仅包含请求和响应消息的字节向量。应用负责请求和响应消息序列化。同一 API 可用于多个例程控制消息。

数据标识符消息可用作
- 类型化接口 API 签名包括所有请求-（用于写入）和响应消息（用于读取）参数及其基元类型。DM 负责序列化。
- 通用接口 API 签名仅包含请求和响应消息的字节向量。应用负责请求和响应消息序列化。
- 单独数据元素的每个请求和响应消息参数都有自己的接口。这是诊断通讯接口抽象的最高级，即请求和响应消息结构中的任何更改都不会对API产生影响。此外，同一诊断消息的参数可能位于不同的进程中。

8.6诊断对话

由于 DM 需要如上所述的伪并行处理，因此它支持诊断对话，以反映诊断客户端和诊断服务之间的不同对话。诊断服务由相应 UDS 请求的目标地址标识，并在自适应平台的运行时动态分配。

8.7事件内存子集群

事件内存子集群负责诊断故障代码（DTC）管理（类似于经典平台的 DEM）。

活动 DTC 表示车辆中肯定检测到的问题（通常对生产或车库很重要）。DM 管理 DTC 及其配置的快照记录（关于 DTC 发生事件的一组已配置环境数据）和/或扩展数据记录（属于 DTC 的统计数据，如重复发生的次数）的存储。

DTC 的检测逻辑称为诊断监视器。此类监视器将其最近的测试结果报告给 DM 中的诊断事件。UDS DTC 状态派生自一个或多个诊断事件。

DTC 可以分配给主存（可通过 2006 年 4 月 19 日访问）或可配置的用户存储（可通过 0x19 17/18/19 访问）。

支持计数器和时基反跳。此外，DM 还提供有关内部转换的通知：相关方将收到有关 DTC 状态字节更改、监视诊断事件重新初始化的需要以及快照器扩展数据记录是否已更改的通知。

如果 DTC 在配置的操作周期数内未处于活动状态，则 DTC 可能会从 DTC 内存中消失。

DM 支持对启用条件进行通用处理。启用条件可用于在特殊条件下控制 DTC 的更新，例如在欠压条件下禁用所有网络负载 DTC。

09. 持久性

9.1概述

持久性为自适应平台的应用和其他功能集群提供了将信息存储在自适应机器的非易失性内存中的机制。数据可在启动和点火循环期间获得。持久性提供标准接口来访问非易失性内存。

持久性 API 将存储位置标识符作为应用中的参数，以寻址不同的存储位置。可用存储位置分为两类：

键值存储
文件存储

每个应用都可以使用多个这些存储类型的组合。

图 9.1：自适应应用中持久性的典型用法

持久性数据始终专用于单一应用的单一进程。没有可用于使用持久性在不同进程之间共享数据的机制。此决定是为了防止在通信管理所提供的功能下出现第二条通信路径。

持久性已准备好处理来自同一应用的多个线程的并发访问，这些线程在同一进程的上下文中运行。要创建对键值存储或文件存储的共享访问，OpenKeyValueStorage 和 OpenFileStorage 返回的 SharedHandle 可以传递（即复制）到另一个线程，或者 OpenKeyValueStorage 和 OpenFileStorage 可以分别在相同的键值存储或文件存储的独立线程中调用。

持久性能够处理存储数据的完整性。它使用冗余信息来检测数据损坏。冗余信息由 CRC 代码、哈希值和“M out of N”架构组成。这些机制既可以共用，也可以单独使用。

持久性也提供安全的存储。这基本上是使用冗余实现的，但具有额外的功能，即让应用知道存储的数据是否存在任何问题，使它可以使用冗余数据进行恢复。

持久性提供有关已用资源数的应用统计信息。

持久性为存储的数据提供加密，以确保敏感数据在存储在物理设备上之前进行加密。

9.2键值存储

键值存储提供了一种机制，用于在一个存储位置存储和检索多个键值对。键值存储直接支持以下三种数据类型：

SWS_AdaptivePlatformTypes [7] 中定义的数据类型。
由应用中复杂类型的流式处理生成的简单字节数组。
通过 dataType引用的所有实现数据类型由

PersistencyKeyValueStorage在应用设计中接口或专用于该接口的持久性数据元素。

对于每个键值存储，这些键必须是唯一的，并且由应用使用持久性提供的方法进行定义。

9.3文件存储

并非所有与持久性存储相关的数据都以键值存储这样一种存储机制方式构建。

对于此类数据，引入文件存储机制。文件存储端口允许应用访问存储位置并在其中创建一个或多个访问器。这些访问器再由字符串格式的唯一键标识。

与文件系统的比较会对理解有所帮助：文件存储端口可以理解为允许应用创建多个文件（访问器）的文件系统目录。

9.4使用案例处理 UCM 的持久性数据

通常，UCM 中支持三个主要用例，用于在 ECU 或自适应机器的生命周期内处理自适应应用。

将新的应用软件安装到自适应机器
将现有应用软件更新到自适应机器
从自适应机器卸载现有应用软件

在前两种情况下，UCM 通过 EM 触发应用以验证安装/更新，然后触发持久性以根据清单中持久性的配置部署/更新应用的持久性数据。

在第三种情况下，UCM 使用持久性配置中的 URI 删除剩余的持久性数据。

持久性支持以下方案，用于将持久性数据部署到键值存储和文件存储。

持久性应能够部署在自适应应用安装期间由应用 designer 定义的持久性数据。
持久性应能够部署由集成商更改的持久性数据。
持久性应能够部署由集成商定义的持久性数据。
持久性应能够在安装新版本的应用时，根据为键值存储或文件存储配置的更新策略覆盖或保留持久性数据。

通常，持久性层是在应用设计和部署期间配置的。持久性应能够使用部署阶段配置来覆盖应用设计配置。如果缺少部署阶段配置，则将考虑应用设计中的配置以部署持久性数据。

10. 时间同步

10.1概述

当需要跨分布式系统关联不同事件时，不同应用和/或ECU之间的时间同步（TS）至关重要，以便能够及时跟踪此类事件或在准确的时间点触发它们。

因此，向应用提供了时间同步 API，以便它可以检索与其他实体/ECU 同步的时间信息。

然后，通过不同的“时基资源”（从现在开始称为TBR）提供时间同步功能，这些资源通过预构建配置存在于系统中。

10.2设计

对于自适应平台，考虑以下三种不同的技术来满足所有必要的时间同步要求：

经典平台的 StbM
库 chrono - std::chrono （C++11）或 boost::chrono
时间 POSIX 接口

在分析了这些模块的接口及其涵盖的时间同步功能之后，动机是设计一个时间同步API，该API提供围绕经典平台的StbM模块的功能，但具有类似std::chrono的风格。

时间同步模块考虑以下功能方面：

启动行为
关机行为
构造函数行为（初始化）
正常运行
错误处理

在后续版本中将考虑以下功能方面：

错误分类
版本检查

10.3架构

应用将有权访问每个 TBR 的不同专用类实现。

TBR分为不同的类型。这些类具有与同步时基管理器规范 [8] 中提供的时基类型的等效设计。分类如下：

同步主时基
偏移主时基
同步从时基
偏移从时基

与 StbM 一样，时间同步模块（从现在开始，TS）提供的 TBR 也与分布式系统其他节点上的其他时基同步。

通过此句柄，应用将能够查询所提供的时基类型（应为上面介绍的四种类型之一），然后获得该类型时基的专用类实现。此外，该应用还可以直接创建计时器。

TS 模块本身不提供将 TBR 同步到其他节点和/或 ECU 上的时基的方法，如网络时间协议或时间同步协议。

TBR的实现具有专用的周期功能，该功能从时间同步以太网模块或类似模块中检索时间信息以同步TBR。

应用使用 TBR 提供和管理的时间信息。

因此，TBR 充当时基代理，提供对同步时基的访问。通过执行此过程，TS 模块从“真实”时基提供程序中抽象出来。

11. 网络管理

11.1网络管理算法概述

AUTOSAR NM 基于分散的网络管理策略，这意味着每个网络节点独立执行活动，仅取决于通信系统内接收和/或传输的 NM 消息。

AUTOSAR NM 算法基于周期性 NM 消息，群集中的所有节点都通过多播消息接收这些消息。

接收 NM 消息表示发送节点希望使 NM 群集保持唤醒状态。如果所有节点已准备好进入休眠模式，它将停止发送 NM 消息，但只要收到来自其他节点的 NM 消息，它就会推迟到休眠模式的转换。最后，如果专用计时器由于不再接收 NM 消息而过期，则所有节点都会执行到休眠模式的转换。

如果 NM 群集中的任何节点需要总线通信，它可以通过启动传输 NM 消息来使 NM 群集保持唤醒状态。

11.2架构

自适应平台规范独立于所使用的底层通信媒介，描述 AUTOSAR 自适应平台的功能、API 设计和配置以及网络管理。目前只考虑以太网，但架构保持总线独立。

网络管理（NM）旨在通过状态管理进行控制，因为部分网络的控制需要通过 SM 控制的 EM 功能组状态与相关应用集进行协调。本章中的内容尚未反映设计方面。

图 11.1：NM概览

其主要目的是在内部协调状态机中协调底层网络（部分网络、VLAN 或物理信道）的正常运行和总线休眠模式之间的转换。

它为状态管理提供了一个服务接口，用于请求和释放网络以及查询其实际状态。它协调不同实例（网络句柄）的请求，并通过网络提供聚合的机器请求。

如果使用部分网络功能，则 Nm 消息可以包含部分网络（PN）请求，从而使 ECU 可以忽略请求与 ECU 不相关的任何 PN 的 Nm 消息。这提供了关闭ECU（或其部分）的可能性，尽管其他部分网络中的通信仍在进行。

12. 更新和配置管理

12.1概述

AUTOSAR自适应平台的公开目标之一是通过无线更新（OTA）灵活更新软件及其配置的能力。为了支持自适应平台上的软件更改，更新和配置管理（UCM）提供了处理软件更新请求的自适应平台服务。

UCM 负责在自适应平台上更新、安装、删除和保留软件的重新记录。它的作用类似于 Linux 中的 dpkg 或 YUM 等已知包管理系统，具有额外的功能，可确保以安全可靠的方式更新或修改自适应平台上的软件。

UCM Master提供标准的自适应平台解决方案，以无线方式或通过诊断测试仪更新车辆软件。它在车辆内协调和分发多个UCM之间的包。因此，可以将 UCM Master视为 AUTOSAR 标准 UCM 客户端。

图 12.1：车辆更新架构

12.2更新协议

UCM 和 UCM Master 服务旨在支持车辆诊断的软件配置管理，并支持在安全、可靠和资源高效的更新过程中在自适应平台中执行更改。为了满足支持来自多个客户端的更新并启用快速下载的要求，UCM 需要能够将软件包处理（UCM 输入）与软件包数据传输分开处理。

12.2.1数据传输

数据传输是通过 ara::com 完成的。这样就可以将数据传输到 UCM 或 UCM Master，而无需在从后端或诊断测试仪传输数据的过程中缓冲数据。UCM 可以将包存储到本地存储库中，在该存储库中，可以按照 UCM 客户端或 UCM Master请求的顺序处理包。

传输阶段可以与处理阶段分开，UCM支持从多个客户端接收数据，没有限制。

UCM Master 依赖于与 UCM 相同的传输 API，但可通过其自己的专用服务接口进行访问。它允许UCM功能操作，如暂停或恢复并行传输。

12.3程序包

12.3.1软件包

作为 UCM 输入的安装单元是软件包。

例如，软件包包括一个或多个（自适应）应用的可执行文件、操作系统或固件更新，或应部署在自适应平台上的更新配置和校准数据。这构成了软件包中的可更新软件包内容，并包含要在自适应平台中添加或更改的实际数据。除了应用和配置数据外，每个软件包还包含一个软件包清单，提供软件包名称、版本、依赖项等元数据，以及处理软件包时可能出现的一些特定供应商的信息。

规范未指定软件包的格式，这使得可以使用不同类型的解决方案来实现UCM。软件包包括要在软件和元数据中执行的更新。此内容由 UCM 供应商工具进行压缩，生成可由目标 UCM 处理的软件包。

图 13.2.. 概述软件包

UCM 根据提供的元数据处理特定供应商的软件包。您可以在下面找到软件包清单中必须包含的字段的说明，以供参考：

通用信息

包名称：完全符合条件的短名称。
版本：软件群集模型中的版本，必须遵循 https://semver.org 语义版本控制规范，但内部版本号对于调试/跟踪是必需的。使用的原始名称是 StrongRevisionLabelString
deltaPackageApplicableVersion：可以应用此增量包的软件群集版本
支持的最低 UCM 版本：确保 UCM 可以正确解析软件包。
软件群集之间的依赖关系：TPS 清单规范文档包含一个模型，该模型描述了软件群集在更新或安装后之间的依赖关系。

允许检查是否有足够的可用内存的大小：

未压缩软件集群大小：目标平台中软件的大小
压缩软件集群大小：软件包的大小

用于信息和跟踪目的

供应商：供应商 ID
供应商身份验证标记
打包程序：供应商 ID
打包程序身份验证标记：用于包一致性检查和安全目的（用于 UCM 检查软件包是否可信）
型号批准：可选认证信息。如联合国欧洲经委会WP.29的RXSWIN。
发行说明：此版本更改的说明
许可证：例如，MIT，GPL，BSD，专有。
估计的操作持续时间：估计的持续时间，包括，传输，处理和验证。

要将程序包分发到车辆内的正确 UCM，请执行以下操作：

诊断地址：来自软件集群模型，用于包通过UDS检查来自测试人员的情况
操作类型：更新、安装或删除
激活操作：可以不执行任何操作，重启（机器）并重启应用

12.3.2后端包

为了让 OEM 后端了解来自多个包供应商的包内容，建议使用后端包格式，如图 12.3 所示。

图 12.3.后端包概述

软件包格式是特定于供应商的。但是，由于后端包是独立于供应商的，因此软件包清单（图 12.3 中的红色）必须使用 ARXML 文件 format。

12.3.3车辆包

车辆套件通常由 OEM 后端组装。它包含从存储在后端数据库中的后端包中提取的软件包清单的集合。它还包含一个车辆包清单，其中包括一个活动编排以及UCM Master在车辆内分发包所需的其他字段。

车辆程序包清单中应包含的字段的描述参考：

存储库：uri、存储库或诊断地址，用于历史记录、跟踪和安全目的
支持的最低 UCM Master 版本：确保 UCM Master可以正确解析车辆包。
对于更新活动编排：
- UCM标识符：车辆架构中的唯一标识符，允许UCM Master识别车辆中的UCM下属
- 软件包的关联，用于描述传输、处理和激活的顺序
- 车辆驾驶员通知：与车辆驾驶员互动，征求他的同意或在车辆更新的几个步骤中通知他更新期间要采取的可选安全措施。

例如，车辆包可以被车库用于修复在下载和更新时遇到问题的汽车。因此，与后端包一样，车辆包清单应为 ARXML 文件格式，以实现互操作性。

12.3.4软件发布和打包工作流程

为了创建后端包，集成商必须使用与目标 UCM 兼容的打包程序。此程序包可由自适应平台供应商（包括目标 UCM）提供。集成商在组装可执行文件、清单、持久性等之后，使用打包程序使用 UCM 供应商特定的格式创建软件包。然后将相同的软件包与 ARXML 软件包清单一起嵌入到后端软件包中。软件包可以由软件包集成商或集成商签名，并且软件包中包含身份验证标记。由于后端包可能通过互联网在集成商和 OEM 后端之间传输，因此软件包和软件包清单都应与其身份验证标记一起注册到容器中，以避免修改软件包清单。

图 12.5：打包步骤

然后，集成商组装的后端包可以放在后端数据库或存储库中。当车辆需要更新或新安装时，后端服务器将从后端软件包数据库中查询软件包，并将相关的软件包清单关联到车辆软件包中。在此软件包中，后端服务器嵌入了根据车辆特定电子架构选择的活动编排，例如从车辆识别码中扣除。

图12.6：向车辆分发的程序包

图 12.7：向车辆分发的程序包

12.4 UCM 处理和激活软件包

安装、更新和卸载操作通过 ProcessSwPackage 接口执行，UCM 从元数据中分析需要执行的操作。

UCM 序列旨在支持例如 A/B 更新方案或“就地”方案，其中包管理器提供了在需要时回滚到以前版本的可能性。

图 12.8. 软件包的处理和激活概述

为了使实现更简单、更可靠，一次只有一个客户端可以请求使用 ProcessSwPackage 方法处理软件包，将 UCM 状态切换到 PROCESSING。多个客户端可以请求按顺序处理传输的包。在 A/B 分区更新方案的情况下，多个客户端可以处理正在更新的非活动 /B 分区；在软件集叉依赖关系的情况下，每个客户端必须按顺序更新为“ B 分区”。进程完成后，UCM 状态将切换到 READY 以进行激活或其他处理。

使用 Activate 方法对所有已处理的包执行更改激活，而不考虑请求客户端。UCM Master协调此多客户端方案。UCM 可能不知道是否已处理所有目标软件包，但它应执行依赖关系检查，以查看系统是否符合“B 分区”中已安装软件的要求。如果未满足依赖关系，UCM 应拒绝激活并切换回就绪状态。

激活更新时，UCM 会通过 ara::com 在 SM 打开更新会话。对于每个受影响的软件群集中的每个功能组，将调用 PrepareUpdate 方法。它执行 Function Group 特定的准备步骤。成功后，状态将更改为“正在验证”。然后，UCM 通过 SM 接口请求机器重置或功能组重新启动，具体取决于更新类型。例如，如果更新包括正在运行的系统或功能群集更新，则 UCM 可能希望重置机器。但是，如果更新仅涉及低关键度功能，则只需重新启动功能组即可，从而减少对驾驶员的打扰。在此阶段，来自 SM 的 UCM 请求验证目标功能组是否正常运行。成功完成这些重新启动后，UCM 将切换到“已激活”状态。

激活更新后，其他处理请求将被拒绝，直到激活得到解决。在此阶段，UCM 客户端或 UCM Master可以调用 Finish 来确认更改，也可以调用回滚以忽略更改并返回到以前版本的软件。例如，如果此类更新是由 UCM Master 协调的全局更新活动的一部分，在此期间，另如ECU 更新失败，则是出现这样的情况：调用 Finish 后，UCM 将清除所有不需要的资源并返回到 IDLE。

在调用回滚的情况下，UCM 将切换到“回滚”状态，以便通过为所有受影响的软件群集中的每个功能组调用 PrepareRollback 方法来重新激活旧版本的软件群集。例如，在此状态下，如果出现 A/B 分区方案，UCM 将准备在下次重新启动时重新激活/执行的“A 分区”。然后，当通过调用 SM 接口重新启动并重新激活“A 分区”时，UCM 将切换到“已回滚”状态。

在这两种情况下，回滚和成功激活，UCM 都必须在 SM 完成更新会话。

UCM 设计支持传输时的处理，以避免在自适应平台中存储软件包，从而降低成本和更新时间。例如，在软件集群仅包含自适应应用的情况下，UCM可以解压缩收到的软件模块，将文件放置到其目标位置，最终验证并检查软件包的完整性。

12.5 UCM Master更新活动协调

由于UCM Master正在协调车辆中的多个元素，因此可以从CampaignState或TransferState字段访问其状态机，从而可以降低UCM Master的API复杂性。UCM Master 使用 ara::com 中的服务发现不断发现车辆中的 UCM 服务实例。

图 12.9：UCM Master状态机

UCM Master状态机与 UCM 状态机不完全匹配，因为必须考虑特定的车辆方面。例如，车辆包传输，车辆和后端中可用软件的同步或更新后的车辆完整性检查，是特定于UCM Master的。

12.5.1与 UCM Master节点交互的适用应用

由于车辆更新涉及 OEM 特性，因此 OEM 特定内容通过设计推送到自适应应用端。为了使这些应用与多个供应商平台具有互操作性和可交换性，UCM Master 接口被标准化为平台服务（如 UCM）。UCM Master 假定与以下三方面应用进行交互，如下所述。

12.5.1.1 OTA 客户端

OTA 客户端设置后端和 UCM Master之间的通信通道。后端和 OTA 客户端之间未指定通信协议。OTA客户端包括一个调度程序，定期触发数据库同步（由后端或UCM Master管理），其中包含来自后端的可用软件和车辆中的现有软件。可更新、可安装或可卸载的软件是根据后端或 UCM Master 中这两者之间的差异计算得出的。

如果 UCM Master出现故障，则可以将其替换为车辆中存在的另一个 Master。然后，OTA 客户端应包括决策机制，以选择要与哪个 UCM Master节点进行交互。

12.5.1.2车辆驾驶员

在更新期间，可能需要与车辆人类驾驶员进行交互，以便：

获得下载同意（影响数据传输成本），处理或激活软件（安全措施确认）
将车辆置于特定状态（为了在关键更新期间保证安全，可要求停止车辆并关闭发动机）

12.5.1.3车辆状态管理器

车辆状态管理器正在从所有车辆ECU或机器中收集状态。根据收集的状态，车辆状态管理器根据 UCM Master 公开的安全条件字段计算车辆状态，该字段包含在车辆包中。如果计算的车辆状态正在更改，则车辆状态管理器必须调用 UCM Master 的方法安全状态。如果不满足更新的安全性，UCM Master可以决定推迟、暂停或取消更新。

12.5.1.4刷写适配器

刷写适配器是一个自适应应用，与从属于 UCM Master的 UCM 有相同的接口，还包括与通过诊断进行OEM刷写相关的特定序列。它使用诊断协议数据单元应用编程接口（遵循ISO22900的D-PDU API）的实现与经典ECU进行通信。

12.6软件信息报告

UCM 提供服务接口，这些接口公开用于检索自适应平台软件信息的功能，例如已处理但未提交的软件和上次提交的软件的传送的软件包的名称和版本。由于 UCM 更新过程具有明确的状态，因此 UCM 可提供每个软件包的处理状态的信息。

UCM Master 还提供服务接口来公开软件信息，在车辆级聚合来自多个 UCM 的信息。然后通过OTA客户端与后端交换此信息，例如决定车辆中可以更新哪些软件。而且 UCM Master 提供了一种访问其操作历史记录的方法，例如激活时间和包处理的结果。后端可以使用此历史记录从车队中收集更新活动统计信息，或使用诊断测试仪解决车库中的问题。

12.7软件更新一致性和身份验证

UCM 和 UCM Master应使用覆盖整个程序包的认证标记对各自的软件包进行认证，如图 12.2 所述。自适应平台应提供必要的校验和算法、加密签名或其他供应商和/或 OEM 特定机制来验证软件包，否则，UCM 或 UCM Master 将返回错误。实际上，软件包应由与开发目标UCM或UCM Master的工具来自同一供应商的工具进行压缩，以便具有身份验证算法兼容性。

由于身份验证算法使用哈希，因此在对程序包进行身份验证时也会检查一致性。可以在 TransferData、TransferExit 和 ProcessSwPackages 调用中检查程序包身份验证和一致性，以涵盖许多可能的用例和场景，但应在 UCM 或 UCM Master 处理任何包之前执行，以获得最大的安全性。

12.8更新过程安全

UCM 和 UCM Master 通过 ara::com 提供服务。在 UCM 和 UCM Master更新协议中都没有客户端的身份验证步骤。相反，由身份和访问管理来确保通过ara::com请求服务的客户端是合法的。

12.9更新过程中的专有状态管理

UCM 使用状态管理中的 UpdateRequest 服务接口来请求可能由于状态冲突或安全考虑而被拒绝的更新会话。还可以使用 PrepareUpdate 方法为激活准备功能组，并使用 VerifyUpdate 方法验证更新、安装或删除。如果验证失败，UCM 可请求使用回滚方法更改功能组状态。如果需要，UCM 还可以向 SM 请求重置机器，否则在激活后需要重新分析清单以保持平台的配置一致。

图 12.10 更新过程中的状态管理

13. 身份和访问管理

身份和访问管理（IAM）的概念是由日益增长的安全性需求驱动的，因为 AUTOSAR 自适应平台需要与其应用建立强大且定义明确的信任关系。IAM 为自适应应用引入了权限分离，并在发生攻击时防止权限提升。此外，IAM 使集成商能够在部署期间提前验证自适应应用请求的资源的访问权限。身份和访问管理为来自服务接口上的自适应应用、自适应平台基础的功能集群和相关资源模式的请求提供了一个访问控制框架。

13.1术语

要了解框架的工作原理，必须提前定义一些重要概念。作为参考，另请参阅中“基于策略的管理术语”

RFC3198 （https://tools.ietf.org/html/rfc3198）.

访问控制决策：访问控制决策是一个布尔值，指示是否允许请求的操作。它基于调用方的身份和访问控制策略。
访问控制策略：访问控制策略用于定义访问特定对象（例如服务接口）必须满足的约束。
策略决策点（PDP）：PDP 做出访问控制决策。它通过检查访问控制策略来确定是否允许自适应应用执行请求的任务。
策略实施点（PEP）：PEP 通过从 PDP 请求访问控制决策，在自适应应用发出请求期间中断控制流，并强制执行此决策。
意图：意图是自适应应用标识的属性。仅当请求 AA 拥有该特定资源必需的所有已确认意图时，才会授予对 AUTOSAR 资源（例如服务接口）的访问权限。意图在其应用清单中分配给 AA。
授予：在部署自适应应用期间，应确认在设计阶段请求的每个意图。授予元素在元模型中可用。赠款将支持集成商审查意图，但并非旨在允许部分接受意图。
中间标识符（IntID）：一个用于识别正在运行的 POSIX 进程并映射到建模的 AUTOSAR 进程的标识符。IntID 的具体性质取决于用于对正在运行的 POSIX 进程进行身份验证的机制。
自适应应用标识（AAID）：自适应应用的标识模型由 AUTOSAR 进程表示。
自适应应用标识符：AAID 的引荐来源，即 AUTOSAR 进程，仅指向一个 AAID。

13.2 IAM 框架的范围和重点：

IAM 框架为 AUTOSAR 自适应平台栈和自适应应用的开发人员提供了一种机制，以对每个应用的意图进行建模，在访问请求时提供访问控制决策，并强制实施访问控制。IAM 专注于提供限制从自适应应用到自适应平台基础的接口、服务接口以及与功能集群相关的明确定义的资源（例如 KeySlots）的访问的方法。特别注意IAM不涉及对 CPU 或 RAM 等系统资源强制实施配额的保护问题。

在运行时，IAM 的进程对自适应应用是透明的，除非请求被拒绝并引发通知。

此框架旨在在运行时强制访问 AUTOSAR 资源。假定自适应应用将在启动期间进行身份验证，并且现有的受保护运行时环境可确保自适应应用得到适当隔离并防止其权限升级（即绕过访问控制）。

13.3 AUTOSAR 规范的保留

下表表示 IAM 框架的哪些部分将由 AUTOSAR 定义，哪些部分由开发人员在实现方面决定。

表 13.1：IAM 框架部件概述

13.4 IAM 框架的架构

13.4.1整体框架

IAM 架构在逻辑上将授权实体分为一个实体负责决定是否允许自适应应用访问资源（PDP）和另一个实体负责强制实施访问控制决策（PEP）。需要限制对其应用接口的访问的功能群集需要强制执行 PDP 提供的访问控制决策的 PEP。为此，如果自适应应用请求访问此类接口，则 PEP 将与 PDP 进行通信。访问控制决策将根据要求和应用的意图发送回 PEP。访问控制决策的必要信息基于在启动请求的自适应应用的应用清单中找到的意图以及策略。策略表示适用于接口的规则，即自适应应用为了收集访问权限而必须满足的先决条件。对于访问控制下的所有资源，策略在功能集群的规范中定义。

初步假设

应用被设计/配置为具有意图（允许它们访问某些资源的属性）。
在部署期间将确认每个意图。
部署的应用将进行加密签名，以便验证真实性。
应用与包含意图的应用清单一起部署。
受 IAM 约束的自适应应用必须按顺序真实启动，并且其清单必须在部署期间经过身份验证。PEP解释请求并要求PDP做出策略决定（可能在同一过程中实施）。

13.4.2自适应应用的识别

为了向 PDP 请求策略决策，PEP 必须确定调用自适应应用的标识。由于每次调用都通过进程间通信进行中介，因此中间件应支持此标识。

标识本身是对建模 AA 的引用。意图绑定到 PortPrototypes ，然后绑定到 SWComponentType （请参见清单规范）。

IAM 框架未完全指定 AA 的标识。最合适的解决方案在很大程度上取决于栈供应商选择的操作系统和平台。许多现代操作系统确实支持识别通信端点上的对等体（请参阅 Linux 中的 SO_PEERCRED、 getpeerid（）或 QNX 中的 Message Pass）。在不提供此类机制的平台上，在消息级实现协议可能是合适的。

由于执行管理通过AUTOSAR进程模型创建自适应应用的运行实例，因此它负责跟踪正在运行的进程的属性（即运行自适应应用的 PID）或分配属性，例如设置专用 UID 或为消息级实现分配键或 UUID。执行管理应使 PEP 能够为向 PEP 发出的每个有效请求找到自适应应用模型。

PEP应在自适应基础中实现，并应与调用自适应应用适当隔离。PDP 不得由自适应应用提供，而自适应应用本身受请求操作的访问控制的约束。

13.4.3 IAM 时序

自适应应用（AA）发起对资源（例如服务接口）的请求。
PEP 中断控制流。
PEP 通过 EM 解析请求进程的身份。
PEP 将调用方的标识和请求参数传递给 PDP。
PDP 检查 AA 的意图是否足够，并将访问控制决策返回给 PEP。
PEP 通过阻止或允许请求来强制执行访问控制决策。

图 1431：IAM 序列

传输库与 EM 用于识别 AA 的机制并保持一致性。

使用 POSIX-Process-ID 提供示例 EM 跟踪在调用 fork（）期间从操作系统检索到的 PID。EM 通过受保护的功能群集接口向 PEP 提供此信息。使用 UID 时，EM 应主动设置新 POSIX 进程的 UID。

14. 密码学

AUTOSAR 自适应平台支持用于常见加密操作和安全密钥管理的 API。该 API 支持在运行时动态生成密钥和加密任务，以及操作数据流。为降低存储要求，密钥可以存储在加密后端的内部，也可以存储在外部并按需导入。

该 API 旨在支持将安全敏感操作和决策封装在单独的组件中，例如硬件安全模块（HSM）。通过按照 IAM 的报告，将密钥限制为特定用途（如仅解密）或限制密钥对单个应用的可用性，可以对密钥和密钥用途提供额外的保护。

该 API 依赖于应用支持，还可用于在处理加密协议（如 TLS 和 SecOC）时保护会话密钥和中间机密。

FC Crypto提供应用和其他自适应AUTOSAR功能集群标准化接口，为加密和相关计算提供操作。这些操作包括加密操作、密钥管理和证书处理。FC Crypto处理所有操作的实际实现，包括请求应用和堆栈提供的实现之间的所有必要配置和操作代理。标准化接口由CryptoAPI公开。

X.509 证书管理提供程序（Certificate Management Provider,CMP）命名空间 ara::crypto::x509负责 X.509 证书解析、验证、真实存储和按不同属性进行本地搜索。此外，CMP 还负责存储、管理和处理证书吊销列表（CRL）和增量 CRL。CMP 支持在线证书状态协议（On-line Certificate Status Protocol,OCSP）的请求准备和响应解析。

14.1安全架构

虽然 AUTOSAR AP 仅定义了向应用公开的高级加密栈 API，但此 API 在定义时考虑了安全架构，旨在满足上述安全性和功能要求。

通用架构在图 14-1中描绘。在最高层，AUTOSAR AP 以及本机和混合应用都与 AUTOSAR AP Crypto Stack API 链接。API 实现可能是指一个中央单元（加密服务管理器），用于跨应用一致地实现平台级任务，例如访问控制和证书存储。实现还可以使用加密服务管理器来协调将功能分流到加密驱动程序，例如硬件安全模块（HSM）。实际上，以这种方式分流 Crypto Stack API 的功能有望成为一种典型的实现策略：加密驱动程序可以实现完整的密钥管理和加密功能集，以加速加密操作并保护托管密钥免受恶意应用的侵害。

图 14.1：加密栈 - 参考架构

为了实现这种分层的安全架构，Crypto Stack API 不仅执行典型的加密操作（如加密和解密），而且还提供对以下方面的本机支持：

使用加密密钥或密钥句柄进行操作
尽管可能存在应用危害，但仍可安全地管理密钥
限制应用对密钥的访问和允许对密钥的操作

14.2密钥管理架构

尽管可能存在应用危害，为了支持密钥的安全远程管理， Crypto Stack 集成了密钥管理架构，其中密钥和相关数据以端到端受保护的形式进行管理。密钥可以基于现有预配密钥以受信任的方式引入系统，也可以通过本地密钥生成以不受信任的方式引入系统。假设有适当安全的加密后端/加密驱动程序，应用无法修改密钥，除非通过明确定义的授权请求（如密钥更新或吊销）。

图 14.2：CKI 密钥管理交互

14.3 API 扩展备注

需要引入新的或修改的权限/策略验证逻辑的重要新用法和交互应绑定到相应的新密钥用法策略标志。例如，通过添加相应的新密钥使用策略并在涉及这些新密钥的所有密钥管理操作中强制实施新逻辑，可引入具有不同所有权/许可检查的备用预配密钥。

15. 日志和跟踪

15.1概述

日志和跟踪功能集群负责管理和检测 AUTOSAR 自适应平台的日志记录功能。平台可以在开发期间以及在生产过程中和生产后使用日志记录和跟踪功能。这两个用例不同，日志和跟踪组件允许灵活的日志记录检测和配置，以便涵盖全部范围。日志记录信息可以转发到多个接收器，具体取决于配置，例如通信总线、系统上的文件和串行坐标。提供的日志记录信息用严重性级进行标记，并且可以检测日志和跟踪组件以仅记录高于特定严重性级的信息，从而在日志记录客户端上实现复杂的筛选和直接的错误检测。对于每个严重性级，都提供一个单独的方法供自适应应用或功能群集使用。

AUTOSAR 自适应平台和日志记录功能集群负责维护平台稳定性，以免系统资源过载。

日志和跟踪依赖于 AUTOSAR 联盟中标准化的 LT 协议。该协议确保将日志记录信息打包成标准化的交付和呈现格式。此外，LT协议可以向日志消息添加其他信息，例如ECU ID。日志记录客户端可以使用此信息来关联、排序或筛选收到的日志记录帧。

此外，还提供了实用方法，例如将十进制值转换为十六进制数字系统或二进制数字系统。这些是使应用能够向日志和跟踪提供符合 LT 协议标准化序列化格式的数据所必需的。

日志和跟踪功能集群还提供日志消息的两个主要“类”：模型化消息和非模型化消息。这两者都支持向日志消息添加一个或多个“参数”。没有任何参数的日志消息没有任何用处，将被丢弃。

非模型化消息是编写日志消息的传统方式：消息的所有参数都添加到内部消息缓冲区，然后最终序列化以输出到控制台/文件或将消息的所有内容都将通过网络发送。在 DLT 协议中，这些消息称为“详细”消息。

模型化消息旨在通过省略来自网络的消息的某些静态（即不变）部分来减少网络上的流量。顾名思义，这部分内容被添加到应用 ARXML 模型中。在 DLT 协议中，这些消息称为“非详细”消息。日志消息查看器应用能够通过将模型中的静态部分与接收消息中的动态部分组合在一起来显示完整消息。

非模型化消息主要在开发过程中使用，因为模型化消息所需的信息当时可能不可用。但是，非建模消息可能会对网络施加高负载，因此模型化消息通常是生产系统中的首选。

15.2架构

命名空间 ara::log 中提供了 Log 和 Trace 接口，供应用将日志记录转发到上述日志记录接收器之一。

日志和跟踪接口依赖于作为日志记录框架一部分的后端实现。日志记录框架可以使用其他功能群集来实现某些功能，例如时间同步或通信管理。

图 15.1日志和跟踪概述

ara::log Functional Cluster 定义了一组受“生成器”模式启发的 API，用于构造非模型化消息，以及一个用于发送模型化消息的单个成员函数 ara::log::Log。

与非模型化的消息 API 不同，它表示单调用接口，即单个函数调用将所有参数传递到 Logger 实例，并执行所有必要的操作来生成和发送消息。这样做的好处是，最终未输出的模型化消息（因为消息日志级未达到配置的日志级阈值）的运行时开销可以变得非常小：在参数传递和函数调用之后，单个 if 子句检查日志级阈值，如果未达到阈值并立即返回。这与非模型化消息 API 形成鲜明对比，在非模型化消息 API 中，执行多个函数调用来构造消息对象，即使该对象最终被丢弃。

16.功能安全

16.1功能安全架构

AUTOSAR为自适应平台提供安全概述和安全需求，以支持自适应平台在安全项目中的集成。对于此版本，安全概述以解释性文档（A UTOSAR_EXP_SafetyOverview [12]）的形式呈现，安全需求以要求文档的形式呈现（RS_Safety [13]）。

这些文件应帮助功能安全工程师在 AUTOSAR 自适应平台中识别与功能安全相关的主题。该列表提供了有关如何将RS_Safety [13] 和 AUTOSAR_EXP_SafetyOverview [12] 中的内容映射到 ISO 26262 [14] 中的内容和结构的通用指导：

AUTOSAR自适应平台的假设、目标、场景和用例（AUTOSAR_EXP_Sa fetyOverview [12]）
系统定义、系统上下文和故障注意事项（AUTOSAR_EXP_SafetyOverview [12]）
危害分析（AUTOSAR_EXP_SafetyOverview [12]）
安全目标（AUTOSAR_EXP_SafetyOverview [12]）
功能安全概念和功能安全需求（RS_Safety [13]）
技术安全需求（RS_Safety [13]）

安全概述文档（AUTOSAR_EXP_SafetyOverview [12]）的目标是陈述顶级安全目标和假设的用例或场景。解释性文件包含假设、示例性项目（如参考模型）和/或对示例性技术解决方案、设备、过程或软件的引用。本文档中包含的任何此类假设或示例性项目仅用于说明目的。这些假设不是AUTOSAR标准的一部分。

需求规范（RS_Safety[13]）详细阐述了RS_Main[2]中编写的高级安全需求。它基于本文档中描述的预期功能。功能安全需求源自EXP_SafetyOverview中提到的安全目标和危害 [12]。AUTOSAR功能集群的技术安全需求和安全相关应用均来自功能安全需求。

以下内容计划在以后发布：

技术安全概念和技术安全需求
安全需求验证、安全分析和典型用例

最后，使用AUTOSAR自适应平台并不意味着符合 ISO26262 [14] 标准。使用AUTOSAR自适应平台安全措施和机制构建不安全的系统仍然是可能的。在最好的情况下，AUTOSAR自适应平台的架构只能被视为脱离上下文的安全元件（SEooC）。

16.2信息交换保护（E2E保护）

将支持 AUTOSAR 中的 E2E 分析，以允许 AUTOSAR AP 和 CP 实例的所有组合之间的安全通信，无论它们是位于相同还是不同的 ECU 中。在有必要的情况下提供机制以便在自适应平台中使用面向服务的方法的更多能力来允许安全通信。通过提供的功能验证从发布者发送并由订阅者接收的信息在传输过程中是否未发生更改。根据 AUTOSAR CP 中的 E2E 机制，在 E2E 上下文中不提供确认和传输安全性。

E2E 处理通信故障，如文档 AUTOSAR_PRS_E2EProtocol [15] 中的 ISO 26262 [14] 所述。

在发布者和订阅者之间的通信中使用 E2E 保护时，将在发布者的过程中同步调用 E2E 保护。在订阅端，E2E检查在接收订阅者进程内的数据时调用。E2E检查通信故障并提供检查结果，但不触发对通信故障的进一步反应。

对于此版本，E2E 支持：

轮询模式下的定期和混合周期事件
方法（有关限制，请参阅 AP SWS 通信管理）
事件（有关限制，请参阅 AP SWS 通信管理）
字段（有关限制，请参阅 AP SWS 通信管理）

E2E 保护周期事件的原理是事件的发布者序列化事件数据并添加 E2E 标头。收到事件时，订阅者将运行 E2ECheck返回一个结果，结果显示传输过程中是否发生了任何可检测到的故障（由 E2E 配置文件定义）。完成此检查后，可以反序列化消息。

尚不支持以下操作：

标注模式下的事件
非周期性事件
方法（无约束）

可用于端到端保护的配置文件和消息流的图表在（AUTOSAR_PRS_E2EProtocol [15] 和 AUTOSAR_SWS_通信管理器[16]）中进行描述。

16.3平台健康管理

平台运行状况管理监督软件的执行。它提供以下监督功能（所有监督功能都可以独立调用）：

活动的监督
截止时间监督
逻辑监督
健康通道监管

图 16.1：PHM 接口与其他组件

注意：健康通道（健康通道外部状态）已设置为过时。它们预计将在下一个版本中在状态管理中引入。

活动监督检查受监督实体是否运行得太频繁或不够频繁。

截止时间监督检查受监督实体中的步骤在配置的最小和最大限制内执行的时间。

逻辑监督检查执行期间的控制流是否与设计的控制流匹配。

活动、截止时间和逻辑监督是根据应用/非平台服务或功能集群通过 API ReportCheckpoint 报告检查点而执行的。

健康通道监控提供了将外部监控结果（如RAM测试，电压监控等）连接到平台健康管理的可能性。

运行状况通道监督基于通过 API ReportHealthStatus 报告运行状况状态来执行。

平台运行状况管理会在受监督的实体中检测到故障时通知状态管理器。

如果检测到执行管理或状态管理失效，平台运行状况管理可以触发监视程序重置。

此版本的已知限制：

•尚未定义对诊断管理器的依赖性

CP 和 AP 共享的功能在基础文档中进行了描述，并命名为“运行状况监视”（RS_HealthMonitoring [17] 和 ASWS_HealthMonitoring [18]）。AP 文档中仅介绍了 AP 的其他规范，并将其命名为“平台运行状况管理”（RS_PlatformHealthManagement [19]， SWS_PlatformHealthManagement [20]）。

请注意，架构元素EM，SM和PHM与安全高度相关;安全执行管理和安全运行状况监视是自适应应用安全操作的基础。EM、PHM、SM 元件间相互依赖并协调活动，以确保 AUTOSAR 自适应平台内的功能安全。

16.4 系统健康监控

系统健康监控（System Health Monitoring, SHM）引入了与平台无关的运行状况监视。SHM专注于在多个控制器和机器上跨多个平台进行系统范围的错误处理协调。

系统健康监控组件可以实例化为主实例或客户端实例。SHM 客户端负责将平台级的运行状况数据传达给主实例，而 SHM 主节点负责确定运行状况指示器。可以在子系统级、功能级、域级以及最终在车辆级确定运行状况指示器。这些运行状况指示器可用于平台级恢复操作，也可用于使用服务运行状况参数（类似于服务质量）增强服务。

基础文档（RS_HealthMonitoring [17] 中介绍了系统健康监控要求。系统健康监控接口和运行状况指示符格式的抽象规范在 ASWS_HealthMonitoring [18] 中描述。

图 16.2：SHM 概述

17. 核心类型

核心类型定义了多个功能集群使用的公共类和功能作为其公共接口的一部分。定义核心类型的基本原理之一是包括接口定义中经常使用的常见复杂数据类型。

17.1错误处理

17.1.1概述

处理错误是任何软件开发的关键主题。对于安全关键型软件来说，它更为重要，因为生命可以依赖于它。但是，目前开发安全关键型软件的标准对构建工具链施加了重大限制，特别是在C++例外方面。对于 ASIL 应用，由于 ASIL 认证的C++编译器不支持异常，因此通常无法使用C++异常。

自适应平台引入了一个概念，该概念可以在不C++异常的情况下进行错误处理，并定义了许多C++数据类型来帮助实现这一目标。

从应用程序员的角度来看，实现这个概念的中心类型是 ara::core::ErrorCode 和 ara::core::Result。

17.1.2错误代码

ara::core::ErrorCode 的实例表示软件中的特定错误情况。它类似于std::error_code，但在重要方面有所不同。

ErrorCode 始终包含枚举值（类型擦除为整数类型）和对错误域的引用。枚举值描述错误的特定类型，错误域引用定义该错误适用的上下文。其他可选成员是用户定义的消息字符串和供应商定义的补充错误描述值。

在自适应平台中，每个功能集群定义一个或多个错误域。例如，功能集群“核心类型”定义了两个错误域“core”和“Future“，它们包含不同错误条件集的错误代码。

17.1.3结果

类 ara::core::Result 是包含值或错误的包装器类型。由于其模板化的性质，值和错误都可以是任何类型的。但是，错误类型默认为 ara::core::ErrorCode，并且预计此分配将保留在整个 Adaptive 平台中。

由于错误类型具有默认值，因此大多数 ara::core::Result 的声明只需要给出值的类型，例如 ara::core::Result<int>对于包含 int 或 ara::core::ErrorCode 的结果类型。

受控值或错误可以通过成员函数访问Result::Value 或 Result::Error。调用方负责确保仅当 Result 实例分别包含值或错误时才调用这些访问函数。Result 的 content 类型，即值或错误，可以通过 Result::HasValue 查询。这些成员函数都不会引发任何异常，因此可在不支持C++异常的环境中使用。

除了上面描述的无异常工作流之外，类 ara::core::Result 还允许通过调用 ara::core::Result::ValueOrThrow 将包含的 ara::core::ErrorCode 对象转换为C++异常。此调用按原样返回任何包含的值，但通过引发相应的异常类型来处理包含的错误，该异常类型是从包含的 ara::core::ErrorCode 的内容自动派生而来的。

17.1.4 Future与Promise

与 ara::core::Result 用作同步函数调用的广义返回类型类似， ara::core::Future 用作异步函数调用的广义返回类型。

ara::core::Future最大程度地模仿了std::future，但已经扩展到与ara::core::Result互操作。

与 ara::core::Result 类似，ara::core::Future 是一个包含值或错误。可以通过两种方式提取此内容：

通过调用 ara::core::Future::get，它返回包含的值（如果存在），否则会引发异常
通过调用 ara::core::Future::GetResult，它返回一个 ara::core::Result 对象，其中包含来自 Future 的值或错误

这两个调用都将阻塞，直到异步函数调用提供值或错误为止。

17.2高级数据类型

除了上一节中提到的错误处理数据类型之外，自适应平台还包含许多其他数据类型和帮助程序函数。

其中一些类型已经包含在C++11标准中;但是，具有几乎相同行为的类型会在 ara::core 命名空间中重新定义。这样做的原因是 std::类型的内存分配行为通常不适合汽车用途。因此，ara::core 定义了自己的内存分配行为。

此类数据类型的示例包括 Vector、Map 和 String。

在 ara::core 中定义的其他类型已在较新的C++标准中定义或建议使用，自适应平台将它们包含在 ara::core 命名空间中，因为它们对于支持 Manifest 的某些构造是必需的，或者因为它们被认为在 API 中使用非常有用。

此类数据类型的示例包括 StringView、Span、Optional 和 Variant。

17.3主要数据类型

另一个文档 AUTOSAR_SWS_AdaptivePlatformTypes [7]定义了可在 ServiceInterface 描述中使用的基元类型。将来可能会认为此文档将与核心类型文档合并。

17.4全局初始化和关闭函数

以下函数可用于初始化和取消初始化自适应应用的 AUTOSAR 运行时的相应数据结构和线程：

ara::core:: Initialize
ara::core::Deinitialize

ara::core:Initialize 初始化 AUTOSAR AA 运行时的数据结构和线程。在此调用之前，无法与ARA进行交互。此调用必须在 main（）内部进行，即在保证静态内存初始化已完成的地方。根据各个功能集群规范，调用应用必须提供额外的配置数据（例如，为日志记录设置应用 ID）或进行额外的初始化调用（例如，在 ara::com 中启动 FindService），然后才能对功能集群进行其他 API 调用。此类调用必须在调用 Initialize（）之后进行。在静态初始化完成之前对 ARA API 的调用会导致未定义的行为。在静态初始化完成之后但在调用 Initialize（）之前进行的调用将被功能集群实现拒绝并显示错误，或者，如果未定义要报告的错误，则会导致未定义的行为。

ara::core::Deinitialize 会破坏 AUTOSAR Adaptive Runtime for Applications 的所有数据结构和线程。在此调用之后，无法与ARA进行交互。此调用必须在 main（）内部进行，即在保证静态初始化已完成且静态初始化数据销毁尚未开始的地方。在调用 ara::core::Deinitialize（）之后，但在销毁静态初始化的数据之前对 ARA API 的调用将被拒绝并显示错误，或者，如果未定义错误，则会导致未定义的行为。在销毁静态初始化数据后对 ARA API 进行的调用将导致未定义的行为。

18. 检测系统管理器

IdsM是AUTOSAR入侵检测系统（Intrusion Detection System, IDS）的一部分。

功能群集入侵检测系统管理器（IdsM）提供了用于接收安全事件（security events,SEv）通知的标准化接口。SEvs可以通过在其他功能集群和自适应应用中实现的安全感知系统进行报告。此外，可以使用可选的上下文数据（如事件类型和可疑数据）报告 SEv，这些数据对于在后端执行的安全取证非常有用。除了收集之外，IdsM还具有根据可配置规则对SEv进行资格认证的能力。IdsM 筛选报告的 SEv 并将其转换为合格的板载安全事件（QSEv）。QSEv 由 IdsM 进一步处理以进行存储或转发。根据整体安全概念，QSEv 可以在 ECU 上本地持久保留或传播到 Ids 报告器模块（Intrusion Detection System Reporter,IdsR），这可能会将 QSEv 数据传递到后端的安全操作中心（security operation center，SOC）。

注意：IDSR 和 SOC 不是 AUTOSAR 中标准化工作的一部分。SEM将根据IDSM for Classic Platform在下一个版本中描述。

概念文件中的下图演示了 IDS 架构概述。

图 18.1：分布式 IDS 架构

参考文献：

[1] 词汇表

AUTOSAR_TR_Glossary

[2] 主要要求

AUTOSAR_RS_Main

[3] 自适应平台的方法

答UTOSAR_TR_AdaptiveMethodology

[4] 自适应平台软件架构说明

AUTOSAR_EXP_SWArchitecture

[5] 4+1视图架构模型

[6] 执行管理规范

AUTOSAR_SWS_ExecutionManagement

[7] 自适应平台的平台类型规范

AUTOSAR_SWS_AdaptivePlatformTypes

[8] 同步时基管理器规范

AUTOSAR_SWS_SynchronizedTimeBaseManager

[9] 身份和访问管理 AUTOSAR_RS_IdentityAndAccessManagement要求

[10] 身份和访问管理规范

AUTOSAR_SWS_IdentityAndAccessManagement

[11] 清单规范

AUTOSAR_TPS_ManifestSpecification

[12] 安全概述说明

AUTOSAR_EXP_SafetyOverview

[13] AUTOSAR Adaptive Platform 和 AUTOSAR Classic 的安全需求平台

AUTOSAR_RS_Safety

[14] ISO 26262-2018（所有零件）道路车辆.功能安全 http://www.iso.org

[15] E2E 协议规范

AUTOSAR_PRS_E2EProtocol

[16] 通信管理规范

AUTOSAR_SWS_CommunicationManagement

[17] 运行状况监视的要求

AUTOSAR_RS_HealthMonitoring

[18] 运行状况监视规范

AUTOSAR_ASWS_HealthMonitoring

[19] 平台健康管理要求

AUTOSAR_RS_PlatformHealthManagement

[20] 平台健康管理规范

AUTOSAR_SWS_PlatformHealthManagement

免责声明：由AUTOSAR 官方文档转译，仅供学习交流