AP Autosar平台设计 13 更新和配置管理 Update and Config Management

目录

13.1概述

13.2更新协议

13.2.1数据传输

13.3包 Packages

13.3.1软件包

13.3.2后端包Backend package

13.3.3车辆包

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

13.4UCM处理和激活软件包

13.5UCM Master更新活动协调campaign coordination

13.5.1与UCM主机交互的自适应应用程序

13.5.2OTA客户端

13.5.3车辆驾驶员

13.5.4车辆状态管理器

13.6软件信息报告

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

13.8保护更新过程

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

---

13.1概述

AUTOSAR自适应平台的一个目标是能够通过OTA灵活地更新软件及其配置。为了支持AP平台上的软件更改，更新和配置管理（UCM）提供了一种自适应平台服务，用于处理软件更新请求。

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

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

13.2更新协议

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

13.2.1数据传输

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

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

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

13.3包 Packages

13.3.1软件包

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

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

未指定软件包的格式，这允许使用不同类型的解决方案来实现UCM。软件包包括在软件和元数据中执行的更新。此内容由UCM供应商工具打包，以生成一个软件包，该软件包将由目标UCM处理。

图13-1软件包概述

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

• 通用信息：
• 包名称：完全限定的短名称。
• 版本：必须遵循的软件群集模型的版本https://semver.org语义版本控制规范，但内部版本号是调试/跟踪所必需的除外。使用的原语名称为StrongRevisionLabelString
• deltaPackageApplicatableVersion：可应用此增量包的软件群集的版本
• 支持的最小和最大UCM版本：确保UCM可以正确解析软件包。
• 依赖关系：清单规范文档包含一个模型，必须遵循该模型描述软件集群在更新或安装后的依赖关系。

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

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

用于信息和跟踪目的（For information and tracking purpose）：

•供应商：供应商id

•供应商认证标签

•包装商：供应商id

•软件包身份验证标签：用于包一致性检查和安全目的（用于UCM检查软件包是否可信）

•型式认证：可选，认证信息。例如，可能是联合国欧洲经委会WP.29的RXSWIN

•发行说明：本发行变更的说明

•许可证：例如，MIT、GPL、BSD、proprietary。

要将包装分发到车辆内的正确UCM：

•诊断地址：来自软件集群模型，用于来自测试的package通过UDS过来的情况

•操作类型：可以是更新、安装或删除

13.3.2后端包Backend package

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

图13-2后端包概述

软件包格式是特定于供应商的。然而，由于后端包是独立于供应商的，软件包清单（红色，图13-2）必须使用ARXML文件格式。

13.3.3车辆包

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

图13-3车辆软件包概述

可以在下面找到车辆包装清单中必须包含的字段说明，以供参考：

•存储库：uri、存储库或诊断地址，用于历史记录、跟踪和安全

•车辆说明

•对于更新活动编排：

UCM标识符：车辆架构内的唯一标识符，允许UCM主机识别车辆中的UCM

软件包关联，以描述传输、处理和激活顺序

车辆驾驶员通知：与车辆驾驶员互动，请求其同意或在车辆更新的几个步骤中通知他

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

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

为了创建后端包，集成商必须使用与目标UCM兼容的打包机。该包可由自适应平台堆栈供应商提供，包括目标UCM。在集成人员组装可执行文件、清单、persistency等之后，他使用打包程序使用UCM供应商特定的格式创建软件包。该软件包随后与ARXML软件包清单一起嵌入到后端包中。软件包可由包装商或集成商签署，并在软件包清单中包含认证标签。由于后端软件包可能通过互联网在集成商和OEM后端之间传输，因此软件包和软件包清单应与其身份验证标签一起签名到容器container中，以避免任何软件包清单修改。

图13-4包装步骤

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

 

图13-5软件包分配至车辆

13.4UCM处理和激活软件包

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

UCM序列设计用于支持例如A/B更新场景或“in-place”场景，其中package manager提供了在需要时回滚到以前版本的可能性。

图13-6软件包处理和激活概述

为了使实现更简单、更健壮，一次只有一个客户机可以使用ProcessSwPackage方法请求处理软件包，将UCM状态切换为PROCESSING。多个客户端可以请求按顺序处理传输的包。在A/B分区更新场景中，多个客户端可以处理正在更新的非活动B分区；在软件集群交叉依赖的情况下，每个客户机必须按顺序更新到“B分区”。一旦处理完成，UCM状态将切换到准备激活或其他处理。

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

当更新被激活时，UCM通过ara::com在SM打开更新会话。对于每个受影响的软件群集中的每个功能组，将调用PrepareUpdate方法。它执行特定于功能组的准备步骤。成功后，状态变为“验证VERIFYING”。然后，UCM通过SM接口根据更新类型请求机器重置或功能组重启。例如，如果更新包括操作系统或功能群集更新，UCM可能希望重置计算机。但是，如果更新仅涉及低关键性功能，则仅重新启动功能组就足够了，从而减少了驾驶员的烦恼。在此阶段，UCM请求SM验证目标功能组是否正常运行。一旦这些重启成功完成，UCM将切换到激活ACTIVATED状态。

激活ACTIVATED更新后，其他处理请求将被拒绝，直到激活问题得到解决。在此阶段，UCM客户端或UCM主机可以调用Finish来确认更改，也可以调用Rollback来忽略更改并返回到软件的早期版本。例如，如果此类更新是UCMMaster协调的全局更新活动的一部分，在该活动期间，另一个ECU的更新失败，则需要进行此操作。调用Finish后，UCM将清除所有不需要的资源并返回空闲状态。

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

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

UCM设计支持边传输边处理，以避免将软件包存储在AP中，从而减少成本和更新时间。例如，对于只包含自适应应用程序的软件集群，UCM可以解压缩接收到的块，将文件放置到其目标位置，最后验证和检查软件包的完整性。

13.5UCM Master更新活动协调campaign coordination

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

图13-7UCM主状态机

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

13.5.1与UCM主机交互的自适应应用程序

车辆更新涉及原始设备制造商的特殊性，因此原始设备制造商的特定方面由设计推送到自适应应用端。为了使这些应用程序与多个供应商平台具有互操作性和可交换性，UCM主界面被标准化为平台服务，如UCM.UCM Master假设有三个应用程序与自身交互，如下所述。

13.5.2OTA客户端

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

如果UCM主机出现故障，可以用车辆中的另一个主机进行更换。然后，OTA客户端应包括决策机制，以选择与哪个UCM主机交互。

13.5.3车辆驾驶员

在更新过程中，可能需要与车辆驾驶员交互，以：

•同意下载（影响数据传输成本）、处理或激活软件（安全措施确认）

•将车辆置于特定状态（为了保证关键更新期间的安全，可能会要求其停止车辆并关闭发动机）

13.5.4车辆状态管理器

车辆状态管理器从所有车辆ECU收集状态并提供UCM

掌握要订阅的字段，以及对车辆包中提及的安全政策的判断。如果不符合安全策略，UCM主机可以决定推迟、暂停或取消更新。

13.6软件信息报告

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

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

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

UCM和UCM Master应按照图13-1和图13-3所述，使用覆盖整个包装的认证标签对其各自的包装进行认证。自适应平台应提供必要的校验和算法、加密签名或其他供应商或OEM特定机制，以验证软件包，否则，UCM或UCM Master将返回错误。实际上，软件包应该由开发目标UCM或UCM主机的同一供应商提供的工具进行打包，以便具有身份验证算法兼容性。

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

13.8保护更新过程

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

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

OEM负责定义与系统设置相关的可更新状态。根据系统设置和应用程序，系统可能需要切换到“更新状态”，以便在更新过程中忽略丢失或错误的消息。

此外，更新后还必须对系统进行最低限度的检查。为此，OEM特定诊断应用程序将使机器进入“验证状态”，并检查所有相关过程是否已达到运行状态。如果某些进程无法达到runningState，这将提供执行回滚的机会。图13-9提供了该概念的概述。

图13-9更新过程中的状态管理