13.Adaptive AUTOSAR 架构-更新配置管理(UCM)

13.1 概述目标

Adaptive AUTOSAR声明的一个目标就是通过OTA(无线，over the air)能够自由的更新软件和它的配置. 为了支持Adaptive平台的软件变化，UCM提供了一个Adaptive平台服务，更够处理软件更新请求。

UCM负责Adaptive 平台的软件更新，安装和删除以及保留软件记录。它的角色类似Linux上著名的包管理器dpkg或YUM。另外附加的功能是确保以安全可靠的方式更新或修改自适应平台上的软件。

13.2 更新协议

UCM服务旨在支持诊断通信子软件集群的诊断用例，并支持在安全、可靠和资源高效更新过程中对自适应平台进行更改。为了满足支持多个客户端更新和支持快速下载的需求，UCM必须将软件包(UCM输入)与它们的处理分开传输。

13.2.1 数据传输

U数据传输是通过ara::com上的数据流来完成的。它能够使数据传输到UCM中，而不需要在UCM外设置数据buffer. UCM把包存储在本地仓库，从而使UCM客户端按照请求数据处理。

由于传输阶段和处理阶段是分开的，UCM支持从多个客户端接收数据。并且这样做的时候没有任何限制。

13.3 包

13.3.1 软件包

安装单元对UCM来说输入是软件包。包括一个或几个可执行的（Adaptive)应用程序，操作系统或固件更新，或更新配置和部署在Adaptive平台上的配置数据。这个构成了软件包的可更新部分和Adaptive平台上增加或更改的实际数据。除了应用程序和配置数据，每个软件包包含一个软件manifest. 这个清单中提供包名称，版本，依赖和一些可能的生产厂商特定消息。这些消息用来处理软件包。

软件包的格式并没有指定，对UCM的实现来说，能够使用不同的解决方案。软件包由要在软件和元数据中执行的更新组成。这些内容通过供应商工具来生成将由目标中的UCM处理的软件包。为了部署软件到目标，OEM可以将软件包打包到OEM部署的container中。在目标机器中，特定于OEM的应用程序将接收OEM包，并在将包传递给UCM之前执行可能的解压缩和解密。

UCM根据提供的元数据处理生产商特定的软件包。

13.3.2 后端包

软件包的格式是厂商特定的。但是，尽管后端包是厂商独立的，但是软件包的清单（图13-2中红色部分）必须是ARXML格式。

你可以在以下找到必须包含在软件包清单中的字段的描述，以供参考:

通用信息

* Package name：完全合格的简写

*  Version：软件簇的版本必须遵循https://semver.org 的语义版本规范。在这个规范中异常构建号对于调试/跟踪是必需的。StrongRevisionLabelString primitive

* isDeltaPackage: boolean, 如果内容是按照增量包处理的，该字段激活

* Dependencies: 清单模型包含了描述软件包更新或安装后的依赖性模型。如果是增量更新，这个依赖模型会描述当前软件簇版本对比之前版本的依赖性。下面是模型例子：

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

* uncompressedSoftwareClusterSize: 目标平台的软件簇大小

* compressedSoftwareClusterSize：软件包大小

用于信息和跟踪目的

* Vendor: vendor id

* Vendor signature

* Packager: vendor id

* Package signature:  为了包的一致性检查和安全目的。这可以用来对后端包中的软件包进行签名，也可以用来对软件包清单ARXML中包含的数据、可执行文件等进行签名。

* Type approval: 可选的，homologation information

* Release notes: 描述本次发布变化

* License: 比如MIT， GPL，BSD，专有的

为了在车内将包分发给正确的UCM

* Diagnostic address: 比如以防包通过UDS来自tester

* UCM identifier: 车辆架构中的唯一标识符

* Activation action: 可以重新启动，重新启动应用程序还是什么都不做

* Action type: 更新，安装或删除

13.3 汽车包清单

车辆包通常由OEM后端组装。它包含了软件包清单的集合。这些清单是从存储在后端数据库的后端包中提取的。它还包含一个汽车包清单。这个清单包括活动编排和车辆内包分发所需的其他字段。（图13-4）

下面信息描述在汽车包清单中必须包含的字段。

 List of backend packages: SWCL names 列表

 Dependencies: 软件簇之间的依赖性会否决已经在软件包中定义的依赖性。通常由车辆系统集成商用于添加后端包供应商不知道的与车辆系统相关的依赖项。

 Origin: uri, 存储库或诊断地址，用于历史记录、跟踪和安全目的

 Version

 Vehicle target: 版本描述

 Campaign orchestration: 下面是模型例子

比如汽车包可以被车库用来修复下载更新时的问题。因此，类似后端包一样，为了互操作性的目的，汽车包的清单应该时ARXML文件格式。

13.3.4 软件发布和打包流程

为了创建后端包，继承者必须使用和目标UCM 兼容的打包工具。这个打包工具包括目标UCM可以由Adaptive平台栈厂家提供。在集成商装配完可执行程序，清单，持久性等，他可以用这个 打包工具用UCM厂家特定的格式创建一个软件包。接下来软件包会和ARXML软件包清单一起嵌入到后端包中。Adaptive栈厂家打包工具或集成者可以签名这个软件包，签名包含在软件包清单中。由于后端包可以通过以太网在集成者和OEM后端传输，为了避免软件包清单修改，所以软件包和软件包清单以及签名应该被签到一个container中。

被集成者装配的后端包可以放到后端数据库中。当汽车需要更新或新安装文件，后台服务器会从后端数据库查询软件包，然后将软件包清单合并到汽车包的清单中。在这份清单中，后端服务器嵌入根据车辆电子架构选择的活动编排，例如从车辆识别号中扣除。

13.3.5 处理激活软件包

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

UCM 序列设计可以支持A/B更新场景或 “in-place”场景（比如 使用OSTree). 如果需要的化，这种设计让包管理者有回滚到之前版本的可能性。

为了让实现更简单健壮，同一时刻只有一个客户端可以使用方法ProcessSwPackage来处理软件包并将UCM状态切换到BUSY。 几个客户端可以按照顺序请求除了传输的包。如果时A/B分区更新场景，多个客户端可以处理正在更新的非活动/B分区; 如果是跨依赖的软件簇，每个客户端必须按序更新B分区。一旦处理结束，UCM的状态会切换到Ready，为了下一次的激活或另一次处理。

不管哪个客户端请求这个，使用Activate方法激活所有已处理的包。为了正确协调多个客户但的场景，可以使用master客户端。UCM可能不知道是否所有的软件都已经被处理了，但是他会执行一个依赖性检查来查看系统是否和在B 分区已安装软件的需求一直。如果依赖性不能被满足，UCM就会拒绝激活并切换到READY状态。

当更新被激活，UCM状态会切换到VERIFYING。然后UCM会根据更新的类型来重置机器或重启功能组合。比如，如果更新包含功能簇操作系统更新，UCM可能需要重启机器。但是，如果更新仅仅是与低重要性的功能相关，仅仅重启功能组合就足够了，来减少驱动的烦恼。在这个阶段，UCM可以从PHM和EM来验证是否目标软件簇可以正常运行。一旦这些重启成功完成，UCM切换到ACTIVATED状态。

当激活更新的时候，其他处理请求会被拒绝直到激活解决。在这个阶段，UCM可以调用Finish或为了或确认这些变化或忽略这些变化回滚（比如这个更新是全局更新的一部分，而另一个ECU更新失败）

调用Finish后，UCM 会清理所有不需要的资源并返回IDLE。

如果调用Rollback， UCM会切换到ROLLING-BACK状态来重新激活旧版本的软件。比如，在这种状态下，如果是A/B分区场景，UCM将会为下一次重启准备A分区来重新激活/执行。

13.4 软件信息报告

为了已处理但未提交的软件和最后提交的软件，UCM提供了服务接口，它公开了检索自适应平台软件信息的功能，比如已传输包的名称和版本号。由于UCM更新过程清理状态，所以UCM提供了每个软件包处理处在哪个状态的信息。

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

UCM会使用覆盖整个软件包的签名来验证软件包如图13-1描述的那样。Adaptive 平台提供了必要的校验和算法， 加密签名或其他厂家/OEM 特定的机制来验证这个包，否则UCM就会返回错误。实际上，为了保证认证算法的兼容性，软件打包工具应该和目标UCM来自同一个厂家。

由于认证算法使用hash，所以当验证软件包的时候也检查了一致性。通过调用TransferData, TransferExit和ProcessSwPackages来验证软件包和检查一致性可以覆盖大部分可能的用例和场景， 但是应在UCM实际处理任何软件包之前执行，以获得最大的安全性。

13.6 保护更新过程

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

UCM是不允许在处理时间内更新比目前老的版本软件簇（否则攻击者可以更新一个有已知缺陷的老的包）

13.7 更新进程期间的安全状态管理

与系统设置相关的安全状态的定义是OEM的责任。基于系统设置和应用，系统可能需要切换到一个‘更新状态’，以便它们可以在更新过程中忽略丢失或错误的消息。

另外，更新之后必须做一个最小的检查。因此OEM特定的诊断应用程序会将机器设置为‘验证状态’并且检查是否所有相关的进程都是运行状态。如果某些进程没有切到运行状态，有机会可以执行回滚。图13-9 提供了这个概念的概述。