作者：刘向
出品：汽车电子与软件
背 景
随着汽车电子电气架构向集中式、服务化方向演进，软件更新与配置管理成为确保车辆功能安全、提升用户体验的重要环节。UCM（Update and Configuration Management，更新与配置管理） 是 Adaptive AUTOSAR 平台的核心服务模块之一，旨在为车辆电子控制单元（ECU）提供灵活、安全的软件更新和配置管理功能。为现代智能网联汽车提供强大的软件生命周期管理能力——从开发、测试到部署与维护。
#01
UCM逻辑架构概述
UCM功能集群：主要负责在自适应AUTOSAR平台上进行软件集群的安装、更新或移除操作。软件集群由一组自适应应用程序进程及相关数据元素组成，能够在运行时独立地被修改。
图 1. UCM Logical Architecture
UCM主要负责软件包的管理，包括传输、验证、安装、更新与移除等操作。此外，它还与状态管理（STM）、加密等多个自适应平台功能集群进行交互。UCM是AP平台实现 OTA（Over-The-Air）更新的技术基石，更是保障车辆功能安全（ISO 26262）与网络安全（ISO 21434）的关键。
图 2. UCM Overview
通过标准化流程，UCM 解决了以下问题：
1.支持动态更新：支持在机器（Machine）运行时安装、更新或移除自适应应用程序（Adaptive Applications），无需完全重启系统。
2.确保安全性：通过加密验证（如 RSA、ECC）和完整性检查（如 SHA256）确保软件包的来源可信且未被篡改，防止恶意代码注入。
3.跨 ECU 协同：通过 UCM Master 和 UCM Subordinate 的协作，协调多节点更新，避免功能冲突。实现车辆内多 ECU 的集中式更新管理。
4.依赖管理和版本控制：验证软件包的运行时依赖关系，确保更新前后软件集群（Software Cluster）的版本兼容性和稳定性。
UCM模块的架构可分为 服务层、通信层、执行层 和 持久化层，各层协同工作以实现端到端的更新管理。
Adaptive AUTOSAR UCM 模块通过分层架构和标准化流程，实现了车辆软件的高效、安全更新。其核心价值在于：
灵活性：支持流式传输、并行处理，减少停机时间。
可靠性：依赖验证、回滚机制和状态管理确保系统稳定性。
扩展性：通过插件机制（如镜像更新适配器）支持不同硬件和项目需求。
UCM 模块的组成部分
在Adaptive AUTOSAR中，UCM 模块由以下核心部分构成：
图 3. UCM Master Architecture
UCM Master作为中央协调者，管理多个UCM Subordinate实例，每个Subordinate可能对应不同的ECU或软件组件。
核心职责：作为更新和配置管理的中央协调者，负责全局控制。
发起软件更新（例如OTA）、配置变更请求。
管理多个UCM Subordinate的生命周期。
监控所有Subordinate的状态，处理错误和回滚。
应用场景：云端OTA服务器、车载中央网关或高性能计算单元（HPC）。
UCM Master通过使用PackageManagement服务和通信管理功能集群可以与不同机器上的UCM Subordinate进行通信。主要是负责检索有关机器上软件包当前状态的信息，并将合适的软件包传输给UCM Subordinate。
核心职责：作为执行单元，负责本地操作。
接收Master的指令，执行软件包操作（安装、更新、移除）。
上报本地资源状态（如存储空间、当前软件版本）。
实现原子化操作（例如事务性更新，失败时回滚）。
与状态管理（STM）、加密（Cryptography）、持久性（Persistency）等功能集群交互，确保更新过程的安全性。
管理本地软件集群数据库（SWC Database），记录已安装软件的状态和文件信息。
应用场景：单个ECU或功能域控制器。
UCM Subordinate是一个守护进程（ara-pkgmanagerd），负责执行更新。车辆中的每个Machine都将有一个UCM Subordinate实例，该实例由中央UCM Master实例通过通信管理功能集群使用PackageManagement服务控制。
在应用程序更新期间，UCM Subordinate将经历内部状态的转变。UCM Master用于使用PackageManagement服务发起状态转变。状态转变的图表可以在图中看到。
图 4. UCM Internal State Machine
交互基于Adaptive AUTOSAR的 服务导向架构（SOA），通过标准化的API和SOME/IP通信协议实现。
UCM Master和Subordinate通过标准化的服务接口和事务性操作，实现了分布式车载系统的安全、可靠更新。
UCM客户端是一种针对特定项目的自适应应用程序，主要职责是作为外界与UCM之间的桥梁。它不仅能够接收来自不同来源（如云端服务、诊断测试仪等）的OTA（Over-The-Air，空中下载）软件包，还能够根据项目需求决定最佳的更新时机和内容。
主要功能如下：
软件包接收：UCM客户端可以从本地文件系统或通过远程OTA方式接收软件包。需要注意的是，AUTOSAR标准并未规定用于与基于云的软件包仓库通信的具体OTA协议。
更新决策：依据内部逻辑或外部输入，UCM客户端可以智能地选择何时以及如何处理接收到的软件包。
与UCM交互：UCM客户端直接使用ARA::COM和服务接口PackageManagement与UCM进行交互。ARA::COM提供了一种基于服务导向的通信接口，而PackageManagement则是由UCM提供的服务接口，用于管理和执行软件包的更新流程。
根据具体项目的需求，UCM客户端的功能可以进一步扩展，例如增加对特定更新策略的支持，或是增强与其他系统组件的集成能力。
软件包：作为UCM（Update and Configuration Management）的基本操作单元，每个软件包封装了针对UCM的操作（安装、更新、移除）。一个典型的软件包包括：
应用程序（Executables）和配置数据（Data）：实际需要部署到车辆上的可执行文件和配置信息。
Manifest文件：这是一个ARXML格式的元数据文件，包含了软件包的关键信息如名称、版本号、依赖关系等。此外，Manifest还支持身份验证和完整性验证，确保软件包来自可信来源且未被篡改。
车辆包：由原始设备制造商（OEM）在后端系统中组装完成，车辆包整合了针对具体车辆所需的所有软件包。它同样包含一个Manifest文件，这个文件不仅记录了各软件包的信息，还包括活动编排（即更新操作的顺序和条件）和车辆内部软件包分发所需的其他字段。这种结构使得车辆包可以作为一个整体被发送到车辆，并确保所有组件能按照预定计划进行更新。
图 5. Software Package Structure
软件包结构：
Manifest文件：描述操作类型（安装/更新/移除）、依赖关系、版本信息、加密证书等关键信息。
Artifacts：包含可执行文件、配置文件等，支持TAR归档或镜像格式。此外，还包括数据文件，即应用程序所需的配置或资源文件。
身份验证块：采用链式签名（RSA 2048、SECP256R1）和哈希（SHA256）确保软件包的安全性，防止未经授权的修改或损坏。
版本管理：遵循语义版本（Semantic Versioning），拒绝降级操作，确保系统的稳定性和兼容性。
二进制包特性：
支持包级别的完整性和真实性检查。
兼容直接（流式）或间接（存储）更新方式。
提供通用格式用于图像、应用程序和设备更新。
支持不同包格式版本的处理。
根据底层ara::com限制支持不同的片段或块大小。
易于扩展以适应不同的或新的格式。
图 6. 签名身份验证块
块索引表（BIT）和签名身份验证块共同作用，下图是通过链式身份验证方法保障软件包的安全性，具体包括签名和哈希存储机制。
图 7. 链式身份验证与存储
#03
UCM的依赖与相关模块的交互
UCM Client是一种与UCM协作的应用程序，它将软件包传输给UCM，并支持（项目特定的）OTA协议。
状态管理（State Management, STM）：
在更新前关闭应用程序，更新后重启，并管理功能组（如 Off、Verify 状态）。
加密（Cryptography）：
验证软件包签名和证书链，确保来源合法性和完整性。
持久性（Persistency）：
存储诊断会话信息，支持回滚操作（由应用程序自行管理）。
执行管理（Execution Management, EXM）：
管理自适应应用程序的生命周期，确保更新后配置重新加载。
UCM（更新和配置管理）在自适应AUTOSAR平台中与其他多个功能集群有着紧密的交互关系，这些交互对于确保软件包的安全、有效更新至关重要。以下是UCM与几个关键功能集群的具体交互方式：
1) 与 EXM（执行管理）的通信
隐式 IPC：UCM通过共享内存（如 UCMS_IPC_EXM_SOCKET）通知 EXM 启动或停止自适应应用。
生命周期管理：在激活阶段，EXM 负责加载新软件集群的配置（如 exm_flatcfg.bin）。
2) 与 STM（状态管理器）的交互
交互目的：确保在执行更新前后的系统状态正确转换。
具体操作：
在更新之前，UCM需要通过调用UpdateRequest::PrepareUpdate方法请求状态管理器将相关功能组切换到关闭状态，以便安全地终止并更新自适应应用程序。（如关闭车载摄像头模块）。
更新完成后，UCM会通知状态管理器重新启动这些应用程序，并通过UpdateRequest::VerifyUpdate方法检查它们是否正常运行。
安全恢复：若更新失败，STM 确保系统返回安全状态（如禁用部分自动驾驶功能）。
3) 加密功能集群的交互
交互目的：验证软件包的真实性与完整性，防止未经授权的修改。
具体操作： UCM依赖加密功能集群来对传入的软件包进行身份验证和签名验证。这包括使用特定算法（如SHA256用于摘要计算，RSA 2048或椭圆曲线密码学SECP256R1用于真实性检查）来确保只有授权来源发布的包才能被接受。
4) 持久性功能集群交互
交互目的1：执行文件系统的读写操作，以及通知其他受影响的功能集群其配置已更改。
具体操作： 在应用程序更新过程中，UCM直接与文件系统交互，执行文件的复制、删除和添加等操作。此外，当内容发生变更时，UCM还需与其他功能集群（如执行管理和加密）沟通，告知它们配置已经发生变化，要求重新解析相关配置。
交互目的2：存储诊断会话的信息。
具体操作： 尽管UCM本身不直接处理持久性数据的更新和回滚，但它依赖于持久性API来管理某些类型的数据（例如诊断会话信息）。在VRTE中，UCM有一个内部数据库用于跟踪软件包的状态变化。
5) 诊断
交互目的：支持通过统一诊断服务(UDS)传输软件包。
具体操作： 当车库测试仪需要与ECU通信并执行更新时，UCM使用ISO 14229-1:2013规定的UDS协议来进行数据交换。这意味着UCM可以接收来自外部诊断工具的指令，并根据这些指令执行相应的更新操作。
6) 包管理
交互目的：协调软件包的接收和安装。
具体操作：UCM需要从被称为“UCM Master”的包管理自适应应用程序接收信号。UCM Master负责收集关于机器上当前软件包状态的信息，并决定何时何物进行更新。它还负责将合适的软件包传递给UCM下属实例以完成具体的更新任务。
7) 其他功能集群
HSM（硬件安全模块）：存储根证书与私钥，防止物理攻击。
端到端加密：软件包从云端到 ECU 的传输全程加密（如 TLS 1.3）。
UCM不仅是一个独立的服务，而且是整个自适应AUTOSAR生态系统中的重要组成部分，它通过与多种功能集群的有效协作，实现了复杂但有序的软件更新流程。这种设计保证了即使是在高度动态和分布式的环境中，也能实现高效且安全的软件管理。
8) 工具链支持（以RTA-VRTE为例）
ISOLAR-VRTE xAAP 编辑器：配置SoftwareCluster 和SoftwarePackage。
ucms-swp-generator：生成二进制软件包，支持单步或三步签名流程。
ara-pkgmanagerd：UCM Subordinate 的核心守护进程，处理本地更新操作。
UCM的核心功能
UCM处理软件包的传输、解析及执行。每个软件包都包含一个或多个
传输：支持流式传输（Streaming）与分块传输（Chunked Transfer），优化带宽与内存占用。
验证：基于 X.509 证书链 验证软件包来源，通过 SHA256/RSA 2048 确保内容完整性。
安装与更新：按需执行安装（Install）、更新（Update）或移除（Remove）操作。
依赖解析：检查软件包间的版本依赖（如 dependsOn），拒绝冲突版本（如主版本不兼容）。
UCM依赖于状态管理器（State Manager, STM）来确保在更新前后的系统状态正确转换。例如，在更新之前停止应用程序，并在更新后重启它们。管理以下状态转换：
空闲（Idle）：无更新任务，系统正常运行。
处理中（Processing）：软件包传输与解析阶段。
激活（Activating）：执行安装或更新操作。
回滚（Rollback）：更新失败时恢复至上一稳定状态。
UCM在更新过程中检查所需的存储空间、内存和其他计算资源是否充足，避免因资源不足导致的更新失败。
存储空间：动态检查目标 ECU 的存储容量，拒绝超限操作。
内存分配：为并行传输与处理预留资源，避免资源耗尽。
计算资源：在激活阶段协调 CPU 占用，确保实时性任务不受影响。
准备阶段：首先需要创建一个包含所需更新信息的软件包。
使用AP工具链配置SoftwareCluster和SoftwarePackage。
创建制品归档（例如TAR文件），这些文件包含了要更新的应用程序、配置文件等。将制品归档与清单文件一起打包成最终的软件包。
确保目标ECU上已正确配置并运行了必要的服务，如ara-pkgmanagerd（UCM的核心服务）。
UCM 的配置需通过AP工具链完成，具体步骤如下：
生成一个软件包通常涉及三个步骤：
1. 使用UCM Manifest编辑器创建一个包Manifest
2. 创建包含要修改的可执行文件和配置数据的工件存档
3. 将工件存档和manifest打包在一起形成一个软件包
文件要求：制品需命名为 artefact_
UCM 的更新操作分为 传输、处理、激活、验证、完成事务 五个阶段：
图 8. Software Package State Machine
使用UCM Master或OTA客户端将软件包安全地传输到目标ECU上的UCM Subordinate实例。这可以通过调用TransferStart()方法开始，并通过TransferData()发送数据块，最后通过TransferExit()完成传输。
图 9. Transferring a Software Package
步骤：
1. TransferStart：初始化传输，指定软件包大小和块大小。
2. TransferData：分块传输软件包数据（支持流式传输）。
3. TransferExit：结束传输，缓存至临时目录。
图 10. Streaming a Software Package
流式传输：
在传输过程中调用 ProcessSwPackage，实现并行处理（支持镜像更新）。
(2) 处理阶段
提取与解析：UCM下属接收并缓存传入的软件包，然后开始提取其内容并对清单文件进行解析。这一阶段会检查所有依赖关系，并为后续安装做准备。
图 11.
Processing a Software Package
12.
Activating a Software Package
图13. Verifying Software Package
VerifyUpdate：
状态管理将功能组切换至 Verify 状态，启动更新后的应用程序自检。
图 14. Failure During Verifying Software Package
若验证失败，触发回滚（Rollback）并恢复至旧版本。
(5) 完成事务
清理工作：调用Finish()方法后，UCM进入清理状态，删除任何备份数据，并通知状态管理器操作已完成，使系统返回空闲状态。
图 15. Ending a Transaction
Finish：
清理缓存文件和备份数据。
调用 UpdateRequest::StopUpdateSession 结束更新会话，返回空闲状态。
软件包生命周期状态
图 16. Software Cluster State Machine
1) 已添加(Added) - UCM完成了对首次安装传输的软件包的安装操作（kInstall）。激活后，添加的软件包将进入Present状态。
2) 已更新(Updated) - UCM完成了对传输的软件包的更新操作（kUpdate）。处理后的软件包需要激活才能进入Present状态。
3) 已移除(Removed) - UCM完成了对软件包的移除操作（kRemove）。激活后，该软件包将从UCM中完全移除。
4) 当前存在(Present) - 处理后的软件包（无论是新安装还是更新的包）已经成功完成激活。在此生命周期状态下，软件包的<软件集群>已准备好运行。
