Hello！大家好！
本篇是AP AUTOSAR平台设计(12)——UCM
AP和CP相关资料获取和工具咨询、更多精彩内容欢迎订阅微信公众号“搞一下汽车电子”
整理不易，如果觉得不错，点赞分享支持一下吧~
微信：shactiontech
1.概述
AUTOSAR自适应平台宣称的目标之一是能够通过空中更新（OTA）灵活地更新软件及其配置的能力。为了支持Adaptive Platform上软件的更改，更新和配置管理器（UCM）提供了处理软件更新请求的Adaptive Platform服务。
UCM负责在自适应平台上更新，安装，删除和保留软件记录。它的作用类似于Linux中的dpkg或YUM等已知的软件包管理系统，其附加功能可确保以安全可靠的方式更新或修改Adaptive Platform上的软件。
UCM Master正在提供标准的自适应平台解决方案，以通过空中或通过诊断测试仪来更新车辆软件。它正在多个UCM之间协调和分配车辆内的包。因此，可以将UCM Master视为AUTOSAR标准UCM Client。
2.更新协议
UCM和UCM Master Service旨在支持车辆诊断的软件配置管理，并支持以安全，可靠和资源高效的更新过程在Adaptive Platform中执行更改。为了满足支持多个客户端更新并实现快速下载的要求，UCM需要能够独立于其处理过程传输软件包（UCM输入）。
数据传输
1) 数据传输是通过在ara：：com上传输数据来完成的。这样就可以将数据传输到UCM或UCM Master中，而无需从后端或诊断测试器途中缓冲数据。UCM可以将软件包存储到本地存储库中，在此处可以按照UCM Client 或UCM主Server请求的顺序处理软件包。
2) 传输阶段可以与处理阶段分离，UCM支持不受限制地从多个Client接收数据。
3) UCM Master依赖于与UCM相同的传输API，但可通过其自己的专用服务接口进行访问。它允许与UCM相同的流功能，例如暂停，恢复并行传输。
3.包
①软件包
UCM输入的安装单位是软件包。该程序包包含（Adaptive）的一个或多个可执行文件。应在Adaptive Platform上部署的应用程序，操作系统或固件更新或更新的配置和校准数据。这构成了软件包中的“可更新软件包”部分，并包含要在Adaptive Platform中添加或更改的实际数据。除了应用程序和配置数据外，每个软件包都包含一个软件包Manifest，该Manifest提供元数据，例如软件包名称，版本，依赖关系以及可能的一些特定于供应商的信息，以处理该软件包。
软件包的格式没有指定，这使得可以使用不同类型的解决方案来实现UCM。软件包包括要在软件和元数据中执行的更新。此内容通过供应商工具推送以生成软件包，该软件包将由目标中的UCM处理，该软件包也由同一供应商提供。
UCM根据提供的元数据处理特定于供应商的软件包。您可以在下面找到有关软件包manifest中必须包含的Field的信息，以供参考：
一般信息
1) 软件包名称：完全限定的简称。
2) 版本：来自软件集群模型的版本必须遵循https://semver.org语义版本控制规范，但内部版本号例外，对于调试/跟踪目的是必需的。使用的原始名称为StrongRevisionLabelString
3) isDeltaPackage：布尔值，如果必须为增量包处理内容，则**。
4) 支持的最低和最高UCM版本：确保UCM可以正确解析该软件包。
5) 依赖性：Manifest规范文档包含一个模型，在更新或安装软件集群后，必须遵循该模型来描述其依赖性。在增量更新的情况下，应使用此依赖关系模型来描述此软件集群版本与其先前版本的依赖关系。下面是一个模型示例：
允许检查是否有足够的可用内存的大小：
1) uncompressedSoftwareClusterSize：目标平台中软件集群的大小
2) compressionSoftwareClusterSize：软件包的大小
出于信息和跟踪目的：
1) 供应商：供应商ID
2) 供应商认证标签
3) 打包者：供应商ID
4) Packager身份验证标签：用于软件包一致性检查和安全性目的（供UCM检查软件包是否可信）
5) 型式认可：可选的认证信息。例如，可以是UN ECE WP.29中的RXSWIN
6) 发布说明：此版本更改的说明
7) 许可证：例如MIT，GPL，BSD专有。
要将包分发到车辆中正确的UCM：
1) 诊断地址：来自软件集群模型，例如，当软件包通过UDS来自测试仪时使用
2) 操作类型：可以更新，安装或删除
② 后端包
为了使OEM后端了解来自多个软件包供应商的软件包内容，请指定一个后端软件包格式，如下图所示：
软件包格式是特定于供应商的。但是，由于后端软件包是独立于供应商的，因此软件包清单（图3中红色）必须使用ARXML文件格式。
③车辆包
车辆包装通常由OEM后端组装。它包含从清单存储在后端数据库中提取的软件包清单的集合。它还包含“车辆包清单”，其中包括活动编排以及UCM管理员在车辆内分发包所需的其他字段（图4）。
为了提供信息，您可以在下面找到必须在“车辆包Manifest”中包含的Field的描述：
1) 依赖关系：通过SoftwareActivationDependency继承，软件群集之间的依赖关系将取代软件包清单中已定义的依赖关系。通常由车辆系统集成商用来添加与后端包装供应商不知道的车辆系统相关的依赖项。
2) 存储库：uri，存储库或诊断地址，用于历史记录，跟踪和安全性目的
3) 车辆描述
4) 活动编排：下图是一个模型示例。它包含了：
o UCM标识符：车辆架构中的唯一标识符，以允许UCM主识别车辆中的UCM
o 软件包关联，用于描述传输，处理和**的顺序
o 车辆驾驶员通知：与车辆驾驶员互动，征求其同意或在车辆更新的多个步骤中通知他
车库可以使用车辆包装来修复例如在下载更新时出现问题的汽车。因此，与后端程序包一样，车辆程序包清单应为可互操作性的ARXML文件格式。
④软件发布和打包工作流程
为了创建后端程序包，集成商必须使用与目标UCM兼容的程序包。该软件包可以由包括目标UCM在内的Adaptive Platform堆栈供应商提供。集成人员组装可执行文件，Manifest，持久性等之后，他使用打包程序使用UCM供应商特定的格式创建软件包。
然后，将同一软件包与ARXML软件包清单一起嵌入到后端软件包中。软件包可以由打包者或集成者签名，并且可以在软件包清单中包含身份验证标签。
由于后端软件包可能会在集成商和OEM后端之间通过Internet传输，因此软件包和软件包清单都应连同其身份验证标签一起签名到容器中，以避免对软件包清单进行任何修改。
然后，可以将集成商组装的后端软件包放入后端数据库。当车辆需要更新或重新安装时，后端服务器将从后端软件包数据库中查询软件包，并将相关的软件包清单合并到车辆软件包中。在此程序包中，后端服务器嵌入了基于特定车辆电子体系结构选择的活动编排，例如从“车辆识别号”中扣除。
4.UCM处理和**软件包
安装，更新和卸载操作通过ProcessSwPackage接口执行，在该接口上，UCM可以从需要执行操作的元数据中进行解析。
UCM序列已设计为支持A / B更新方案或“就地”方案（例如，使用OSTree），其中程序包管理器提供了在需要时回滚到以前版本的可能性。
为了使实现更简单，更可靠，一次仅一个客户端可以请求使用ProcessSwPackage方法处理软件包，并将UCM状态切换为PROCESSING。多个客户端可以请求按顺序处理已传输的程序包。在A / B分区更新的情况下，几个客户端可以处理正在更新的非活动/ B分区；如果存在软件群集交叉依赖性，则每个客户端必须按顺序更新到“ B分区”中。处理完成后，UCM状态将切换到“就绪”以进行**或其他处理。
无论请求的Client如何，都对所有已处理的软件包使用Activate方法**更改。UCM Master正在协调此多客户端方案。UCM可能不知道是否已经处理了所有目标软件包，但是它应该执行依赖性检查，以确保系统与“ B分区”中已安装软件的要求一致。如果不满足依赖关系，UCM将拒绝**并切换回READY状态。
**更新后，UCM状态将变为VERIFYING。然后，UCM将根据更新类型执行计算机重置或功能组重新启动。例如，如果更新包括功能集群更新的操作系统，则UCM可能希望重置计算机。但是，如果更新仅与低关键性功能有关，则仅重新启动功能组就足够了，从而减少了对驱动程序的烦恼。在此阶段，UCM可以从EM验证目标软件集群是否正常运行。一旦这些重启成功完成，UCM就会切换到ACTIVATED状态。
**更新后，其他处理请求将被拒绝，直到解决**为止。在此阶段，UCM客户端或UCM管理员可以致电Finish确认更改，也可以回滚以忽略更改并返回到软件的先前版本（例如，如果此类更新是UCM协调的全局更新活动的一部分，主站，在此期间另一个ECU的更新失败。调用Finish之后，UCM清除所有不需要的资源并返回IDLE。
在调用回滚的情况下，UCM切换到“回滚”状态以重新**软件的旧版本。例如，在这种状态下，在A / B分区的情况下，UCM将准备在下一次重新启动时重新**/执行的“ A分区”。然后，当重新启动发生并且“ A分区”被重新**时，UCM切换到ROLLED-BACK状态。
UCM设计支持在传输时进行处理，以避免将软件包存储在Adaptive Platform中，从而降低了成本并缩短了更新时间。例如，在仅包含自适应应用程序的软件集群的情况下（对于带有UDS固件更新的Classic平台更新而言，它的好处不大），UCM可以解压缩收到的块，将文件放置到其目标位置，最后进行身份验证并检查软件包的完整性。
5.UCM Master更新活动协调
当UCM Master协调车辆中的多个元素时，可以从CampaignState字段访问其状态机，从而降低UCM Master的API复杂性。UCM Master使用来自ara：com的服务发现不断发现车辆中的UCM Service Instance。
UCM主状态机与UCM状态机不完全匹配，因为必须考虑特定的车辆方面。例如，车辆包传输，车辆和后端中可用软件的同步或更新后的车辆完整性检查特定于UCM Master。
自适应应用程序与UCM Master交互
车辆更新涉及OEM特殊性，因此OEM特定方面通过设计被推送到自适应应用程序一侧。为了使这些应用程序与多个供应商平台具有互操作性和可交换性，UCM主接口被标准化为平台服务，例如UCM。UCM Master假定有三个应用程序可以与其自身进行交互，如下所述。
OTA客户端
1) OTA客户端设置后端和UCM主设备之间的通信通道。未指定后端和OTA客户端之间的通信协议。OTA Client可以包括一个调度程序，该调度程序定期触发数据库同步（由Backend或UCM Master管理），该数据库包含Backend的可用软件和车辆中的当前软件。可更新的，可安装的或可移动的软件是通过Backend或UCM Master中这两者之间的差异来计算的。
2) 如果UCM主机发生故障，则可以用车辆中的另一个替换。OTA客户程序应包括决策机制，以选择与哪个UCM主机进行交互。
车辆驾驶员
在更新期间，可能需要与车辆驾驶员互动以：
1) 获得下载（影响数据传输成本），处理或**软件（安全措施确认）的同意
2) 将车辆置于特定状态（为了确保在关键更新期间的安全性，可能会要求停止车辆并关闭发动机）
车辆状态管理器
车辆状态管理器从多个车辆ecu收集状态，并向UCM Master提供一个要订阅的字段，以及对车辆包中提到的安全策略的判断。如果不符合安全策略，UCM主控可以决定推迟、暂停、取消更新。
6.软件信息报告
UCM提供Service Interface，这些接口公开了检索自适应平台软件信息的功能，例如已处理但未提交的软件和上次提交的软件的名称和版本。由于UCM更新过程有明确的状态，UCM提供了每个软件包处理的状态信息。
UCM Master还提供Service Interface，以公开软件信息，但在车辆级别，聚合来自多个UCM的信息。然后，这些信息通过OTA客户端与后端进行交换，例如，以解决车辆中可能更新的软件。UCM Master还提供了一种访问其操作历史（如**时间和处理包的结果）的方法。后端可以使用此历史记录从车队中收集更新活动统计信息，或使用诊断测试仪在车库排除问题。
7.软件更新的一致性和认证
UCM和UCM主控方应使用覆盖整个包装的身份验证标签对各自的包装进行身份验证，如图1和图4中所述。自适应平台应提供必要的校验和算法，密码签名或其他供应商和/或OEM特定机制来验证软件包，否则，UCM或UCM主设备将返回错误。
实际上，应该使用与开发目标UCM或UCM Master的厂商相同的供应商的工具来打包软件包，以使认证算法兼容。
由于身份验证算法使用哈希，因此在对软件包进行身份验证时也会检查一致性。可以在TransferData，TransferExit和ProcessSwPackages调用中检查软件包的身份验证和一致性，以涵盖许多可能的用例和方案，但应在UCM或UCM Master实际处理任何软件包之前执行以确保最大的安全性。
8.确保更新过程
UCM和UCM Master通过ara :: com提供服务。UCM和UCM主更新协议中都没有客户端的身份验证步骤。相反，由身份和访问管理来确保通过ara :: com请求服务的Client是合法的。
UCM不允许更新的软件集群版本比Adaptive Platform在处理时提供的软件集群版本要旧（否则，攻击者可以将其更新为具有已知安全漏洞的旧软件包）。
9.更新过程中的安全状态管理
关于系统设置的安全状态的定义是OEM的责任。根据系统设置和应用程序，可能需要将系统切换到“更新状态”，以便他们在更新过程中忽略丢失或错误的消息。
此外，更新后还必须对系统进行最少的检查。为此，特定于OEM的诊断应用程序将使计算机进入“验证状态”，并检查所有相关进程是否均已达到runningState。如果某些进程无法达到runningingState，这将提供执行回滚的机会。图9对此概念进行了概述。
