#百人创作先锋团#AP AUTOSAR 平台设计总体框架全解（下）

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 不仅执行典型的加密操作（如加密和解密），而且还提供对以下方面的本机支持：

1. 1. 使用加密密钥或密钥句柄进行操作

2. 2. 尽管可能存在应用危害，但仍可安全地管理密钥

3. 3. 限制应用对密钥的访问和允许对密钥的操作

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 是一个包含值或错误。可以通过两种方式提取此内容：

1. 
   
2. 1. 通过调用 ara::core::Future::get，它返回包含的值（如果存在），否则会引发异常
3. 
   
4. 2. 通过调用 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 架构

文章转载自公众号：汽车电子与软件