车载软件架构 —— Adaptive AUTOSAR软件架构中时间同步、网络管理和软件更新策略

车载软件架构 —— Adaptive AUTOSAR软件架构中时间同步、网络管理和软件更新策略

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师（Wechat：gongkenan2013）。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

本就是小人物，输了就是输了，不要在意别人怎么看自己。江湖一碗茶，喝完再挣扎，出门靠自己，四海皆为家。人生的面吃一碗少一碗，人生的面见一面少一面。人生就是一次次减法，来日并不方长。自己的状态就是自己最好的风水，自己的人品就是自己最好的运气。简单点，善良点，努力点，努力使每一天都开心，不为别人，只为自己。

本文大体如下：

1、时间同步

2、网络管理

3、更新和配置管理

一、时间同步

1.1、时间同步概述

当需要对分布式系统中的不同事件进行关联时，不同应用程序和/或 ECUs 之间的时间同步(TS)至关重要，这样可以及时跟踪这些事件或在准确的时间点触发这些事件。为此，我们向应用程序提供了时间同步 API，使其能够检索与其他实体/ECUs同步的时间信息。

时间同步功能通过不同的"时基资源"(现称为 TBR)提供，这些时基资源通过预构建配置存在于系统中。

1.2、设计

自适应平台采用了以下三种不同的技术，以满足所有必要的时间同步要求:

-> 经典平台的 StbM;

-> chrono库–std::chrono(C++11)或 boost::chrono;

-> 时间 POSIX 接口。

在对这些模块的接口及其涵盖的时间同步功能进行分析后，我们的动机是设计一个时间同步 API，该 API 可提供与经典平台 StbM 模块类似的功能，但具有类似 std::chrono的味道。

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

-> 启动行为

-> 关闭行为

-> 构造函数行为(初始化)

-> 正常运行

-> 错误处理

未来版本将考虑以下功能方面:

-> 错误分类

-> 版本检查

1.3、架构

应用程序可针对每个 TBR 使用不同的专用类实现，TBRS 分为不同类型。这些类型的设计与同步时基管理规范[9]中提供的时基类型相当。

分类如下:

-> 同步主时基；

-> 偏移主时基；

-> 同步 Slave 时基；

-> 偏移 Slave 时基。

与 StbM 一样，时间同步模块(从现在起为 TS)提供的 TBRs也与分布式系统其他节点上的其他时基同步。

通过该句柄，应用程序可以查询所提供的时间基地类型(应为上述四种类型之一)从而获得该类型时间基地的专用类实现。此外，应用程序还可以直接创建定时器。

TS 模块本身不提供将 TBRS 与其他节点上的时间基地和/或 ECUs(如网络时间协议或时间协议)同步的方法。

TBRS的实现可能有专门的循环功能，可从时间同步以太网模块或类似模块检索时间信息，以同步 TBRS。

应用程序使用 TBRS 提供和管理的时间信息。因此，TBRS 可充当时基代理，提供对同步时基的访问。这样，TS模块就从"真正的"时基提供者那里抽象出来。

二、网络管理

2.1 网络管理算法概述

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

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

NM消息的接收表明发送节点希望NM集群保持清醒。如果任何节点准备好进入睡眠模式，它就会停止发送 NM 信息，但只要收到其他节点的 NM 信息，它就会推迟向睡眠模式的过渡。最后，如果由于不再收到 NM 报文而导致专用定时器失效，则每个节点都会执行睡眠模式转换。

如果 NM 集群中的任何节点需要总线通信，它可以通过开始传输 NM 信息使 NM 集群保持清醒。

2.2 架构

自适应平台规范描述了 AUTOSAR 自适应平台的功能、API 设计和网络管理配置，与所使用的底层通信介质无关。目前只考虑了以太网，但架构与总线无关。

网络管理(NM)将通过状态管理进行控制，因为部分网络的控制需要通过 SM 控制的EM 功能组状态与相关应用程序集进行协调。本章内容尚未反映设计。

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

它为状态管理提供了一个服务接口，用于请求和释放网络以及查询网络的实际状态它协调不同实例(网络处理)的请求，并通过网络提供汇总的 Machine 请求。

如果使用了部分网络功能，Nm 报文就会包含部分网络(PN)请求，从而使 ECU 可以忽略未请求任何与 ECU 相关的 PN 的 Nm 报文。这样就可以关闭 ECU(或其部分)，尽管其他部分网络中的通信仍在进行。

三、更新和配置管理

3.1 概述

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

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

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

3.2 更新协议

UCM 和 UCM Master 服务旨在支持通过车辆诊断进行软件配置管理，并支持在自适应平台中以Safe、Secure 和节省资源的更新 Process 执行更改。为满足支持来自多个客户端的更新并实现快速下载的要求，UCM 需要能够将软件包(UCM 输入)的传输与处理分开。

数据传输

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

传输阶段可与处理阶段分离，CM 支持从多个客户端接收数据，不受任何限制。UCM Master 依靠与 UCM 相同的传输 API，但可通过自己的专用服务接口访问。它具有与 UCM 相同的功能，如暂停或恢复并行传输。

3.3 软件包

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

例如，软件包包括(自适应)应用程序的一个或多个可执行文件、操作系统或固件更新，或应部署在自适应平台上的更新配置和校准数据。这就构成了软件包中的可更新包部分，包含要添加到自适应平台或在自适应平台中进行更改的实际数据。除应用和配置数据外，每个软件包还包含一个软件包清单(Software Package Manifest)， 该清单提供软件包名称、版本、依赖性等元数据，并可能包含一些用于处理软件包的特定供应商信息。

软件包的格式未作规定，因此可以使用不同的解决方案来实施 UCM。软件包包括要在软件中执行的更新和元数据。这些内容由 UCM 供应商工具打包，生成软件包，由目标UCM 处理。

UCM 根据提供的元数据处理特定于供应商的软件包。以下是软件包清单必须包含的字段说明，供参考:

一般概述性信息

-> 1、软件包名称:完全限定的简称。

-> 2、版本:软件集群模型中的版本，必须遵循 https://semver.org 语义版本规范，但为调试/跟踪目的，版本号是必须的。使用的原始名称是StrongRevisionLabelStringdeltaPackageApplicableVersion:可应用此 delta 软件包的软件集群版本

-> 3、最低支持的 UCM 版本:确保软件包能被 UCM 正确解析。

-> 4、软件集群之间的依赖关系:TPS Manifest Specification 文档包含一个模型，描述软件集群更新或安装后的依赖关系。

内存大小:TPS Manifest Specification 文件包含一个模型，描述软件集群更新或安装后各软件集群之间的依赖关系:

-> uncompressedSoftwareClusterSize:目标平台中软件集群的大小；

-> compressedSoftwareClusterSize:软件包大小用于信息和跟踪目的；

-> 供应商:供应商 ID

-> 供应商验证标签

-> 包装商:供应商 ID

-> 包装商认证标签:用于软件包一致性检查和安全目的(用于UCM 检查软件包是否可信任)

-> 类型批准:可选，同源信息。例如，可以是RXSWIN fom UN ECE WP.29

-> 版本说明:说明此版本的更改

-> 许可证:例如，MIT、GPL、BSD，专有许可证。

-> 预计运行时间:预计运行时间包括传输、处理和验证。

将软件包分发到车内正确的 UCM:

-> 诊断地址:来自软件集群模型，用于软件包通过 UDS 从测试仪发送的情况。

-> 操作类型:可以是更新、安装或删除

-> 激活操作:可以是无操作、重启(Machine)和restartApplication

后台软件包

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

软件包格式取决于具体供应商。不过，由于后端软件包与供应商无关，因此软件包清单(图 13.3 中红色部分)必须使用 ARXMI 文件格式。

车辆软件包

车辆软件包通常由 OEM 后端组装。它包含从存储在后端数据库中的后端软件包中提取的软件包清单集合。它还包含车辆软件包清单，其中包括活动协调和 UCM 主控程序在车辆内分发软件包所需的其他字段：

以下是车辆软件包清单中应包含的字段说明，以供参考:

（1）、存储库:uri、存储库或诊断地址，用于历史、跟踪和安全目的

（2）、最低支持的 UCM Master 版本:确保 UCM Master 可以正确解析车辆软件包。

（3）、用于更新活动协调:

-> UCM 标识符:车辆架构中的唯一标识符，以便 UCM Master 识别车辆中的UCM 下级

-> 软件包关联，用于描述传输、处理和激活的顺序

-> 车辆驾驶员通知:与车辆驾驶员互动，征求其同意或在车辆更新的几个步骤中通知其在更新过程中采取的可选安全措施。

例如，汽车修理厂可以使用车辆软件包来修复在下载更新时出现问题的汽车。因此与后端软件包一样，车辆软件包清单也应采用 ARXML 文件格式，以实现互操作性。

软件发布和打包工作流程

为了创建后台软件包，集成商必须使用与目标 UCM 兼容的打包器。该软件包可由自适应平台堆栈供应商提供，包括目标 UCM。集成商组装好可执行文件、任务说明、持久性等后，使用打包器使用 UCM 供应商特定的格式创建软件包。然后将该软件包与ARXML,软件包清单一起嵌入到后端软件包中。软件包可由打包者或集成者签名，并在软件包中包含验证标签。由于后端软件包可能会通过互联网在集成商和 OEM 后端之间传输，因此软件包和软件包清单都应连同认证标签一起签署到容器中，以避免软件包清单被修改：

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

UCM 处理和激活软件包

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

UCM 序列的设计支持 A/B 更新方案或"in-place"方案，软件包管理可在需要时回滚到以前的版本。

为使实施更简单、更稳健，一次只能有一个客户请求使用 ProcessSwPackage 方法处理一个软件包，并将 UCM 状态切换到 PROCESSING。多个客户端可以依次请求处理已传输的软件包。在 AB 分区更新的情况下，多个客户端可以处理正在更新的非活动 /B分区;在软件集群交叉依赖的情况下，每个客户端必须依次更新到"B分区"。处理完成后，UCM 状态切换到 READY，以便激活或进行其他处理。

使用 Activate 方法激活更改是针对所有已处理的软件包，与请求客户端无关。UCMMaster 负责协调这种多客户端场景。UCM 可能不知道是否所有目标软件包都已处理，但它应执行依赖性检查，查看系统是否符合"B 分区"中已安装软件的要求。如果不符合相关要求，UCM 将拒绝激活并切换回 READY 状态。

激活更新时，UCM 通过 ara::com 在 SM 上打开 UpdateSession。对于每个受影响软件集群中的每个功能组，都会调用 PrepareUpdate 方法。它执行功能组特定的准备步骤。成功后，状态将变为 VERIFYING。然后，UCM 会根据通过 SM 接口更新的类型，请求重置 Machine 或重启功能组。例如，如果更新包括操作系统或功能组更新，UCM 可能需要重置 Machine 。

但如果更新只涉及低关键性功能，则只需重启功能组即可，从而减少对驾驶员的干扰。在此阶段，UCM 会请求 SM 验证目标功能组是否正常运行。一旦这些重启成功完成，UCM 就会切换到 ACTIVATED 状态更新进入 ACTIVATED 状态后，其他处理请求将被拒绝，直到激活问题得到解决。在此阶段，UCM 客户端或 UCM Master 可以调用"完成"确认更改，或调用"回滚"忽略更改并返回软件的上一版本。例如，如果该更新是UCM Master 协调的全局更新活动的一部分，而在此期间另一个 ECU 的更新失败，则可使用此方法。调用完成后，UCM会清除所有不需要的资源并返回 IDLE。

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

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

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

UCM Master 更新活动协调

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

UCM Master 状态机与 UCM 状态机并不完全匹配，因为还需要考虑特定车辆方面的问题。例如，车辆软件包传输、车辆可用软件同步以及更新后的后台或车辆完整性检查都是 UCM Master 所特有的。

与 UCM Master 交互的自适应应用程序

由于车辆更新涉及 OEM 的特殊性，因此 OEM 的特殊方面将通过设计推送到自适应应用程序端。为了使这些应用程序与多个供应商的平台具有互操作性和交换性，UCMMaster 接口被标准化为平台服务，就像 UCM 一样。如下所述，UCM Master 假定有三个应用程序与自身交互。

OTA 客户端

OTA Client 在后端和 UCM Master 之间设置通信通道。后端与 OTA Client之间的通信协议未作规定。OTA 客户端可包括一个调度程序，定期触发数据库(由后端或 UCMMaster 管理)的同步，其中包含后端的可用软件和车辆中的现有软件。可更新、可安装或可移动软件根据后台或 UCM Master 中这两者之间的差值计算。

如果 UCM Master 出现故障，可以用车辆中的另一个 Master 代替。OTA 客户端应包含决策机制，以选择与哪个 UCM Master 进行交互

车辆驱动程序

在更新过程中，可能需要与车辆的人工驾驶员进行交互，以便：

-> 获得下载同意(影响数据传输成本)、处理或激活软件(安全措施确认)；

-> 将车辆置于特定状态(为确保关键更新期间的安全，可要求车辆停止运行并关闭发动机)

车辆状态管理

车辆状态管理收集所有车辆 ECUs或 Machine 的状态。根据这些收集到的状态，车辆状态管理将根据 UCM Master 公开的 SafetyConditions 字段计算出车辆状态，该字段包含在车辆包中。如果计算出的车辆状态发生变化，车辆状态管理必须调用 UCM Master 的方法 SafetyState。如果更新不安全，UCM Master 可以决定推迟、暂停或取消更新。

Flashing 适配器

Flashing 适配器是一个自适应应用程序，提供与 UCM 下级到 UCM Master 相同的接口但包括与通过诊断 Flashing 有关的 OEM 特定序列。它使用诊断协议数据单元应用编程接口(D-PDU、API和 ISO 22900)与经典ECUs通信。

软件信息报告

UCM 提供服务接口，可公开检索 Adaptive Platform 软件信息的功能，如已处理但未提交的软件和最后提交的软件的传输包名称和版本。由于 UCM 更新 Process 有明确的状态，因此 UCM 可提供每个软件包的处理处于哪种状态的信息。

UCM Master 还提供服务接口，以公开软件信息，但仅限于车辆级别，汇总来自多个UCMs 的信息。然后通过 OTA 客户端与后台交换这些信息，例如，解决车辆中哪些软件可以更新的问题。此外，UCM Master 还提供了访问其操作历史的方法，如激活时间和处理包的结果。后台可利用这些历史记录收集车队的更新活动统计数据，或使用诊断测试仪在车库排除故障。

软件更新一致性和验证

UCM 和 UCM Master 应使用覆盖整个软件包的验证标签对各自的软件包进行验证。自适应平台应提供必要的校验和算法、加密签名或其他供应商和/或 OEM 特定机制来验证软件包，否则 UCM 或 UCM Master 将返回错误信息。实际上，软件包应由开发目标 UCM 或 UCM Master 的同一供应商的工具打包，以保证验证算法的兼容性。

由于验证算法使用哈希值，因此在验证数据包时也要检查一致性。软件包的验证和一致性可在 TransferData、TransferExit 和 ProcessSwPackages 调用时进行检查，以涵盖许多可能的用例和情况，但必须在 UCM 或 UCM Master 处理任何软件包之前进行，以实现最大的安全性，

确保更新过程的安全

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

更新过程中的适当状态管理

UCM 使用状态管理的 UpdateRequest 服务接口来请求更新会话，但由于状态冲突或安全考虑，更新会话可能会被拒绝。它还可以使用PrepareUpdate 方法为激活FunctionGroups 做准备，并使用 VerifyUpdate 方法验证更新、安装或删除。如果验证失败，UCM 可以使用回滚方法请求更改 FunctionGroup 的状态。如果需要，UCM 也可以向 SM 提出重置 Machine 的请求，否则激活后有必要重新搜索清单，以保持平台配置的一致性。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！