背 景

随着汽车电子电气架构向集中式、服务化方向演进，软件更新与配置管理成为确保车辆功能安全、提升用户体验的重要环节。UCM（Update and Configuration Management，更新与配置管理） 是 Adaptive AUTOSAR 平台的核心服务模块之一，旨在为车辆电子控制单元（ECU）提供灵活、安全的软件更新和配置管理功能。为现代智能网联汽车提供强大的软件生命周期管理能力——从开发、测试到部署与维护。

#01UCM逻辑架构概述

UCM功能集群：主要负责在自适应AUTOSAR平台上进行软件集群的安装、更新或移除操作。软件集群由一组自适应应用程序进程及相关数据元素组成，能够在运行时独立地被修改。

图 1. UCM Logical Architecture

1.1 核心概念

软件包：是包含构件（如可执行文件、库等）和更新指令的容器，用于执行对软件集群的变更。

UCM Client：这是一个特定于项目的自适应应用程序，它作为UCM与外界沟通的桥梁。

通信接口：UCM Client使用ARA::COM API与UCM PackageManagement服务交互，确保软件包能被正确传递和处理。

UCM Subordinate：这个进程直接在目标机器上执行实际的更新操作，根据接收到的软件包中的指令来实施具体的变更。

1.2 UCM 的核心作用

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 模块通过分层架构和标准化流程，实现了车辆软件的高效、安全更新。其核心价值在于：

灵活性：支持流式传输、并行处理，减少停机时间。

可靠性：依赖验证、回滚机制和状态管理确保系统稳定性。

扩展性：通过插件机制（如镜像更新适配器）支持不同硬件和项目需求。

#02 UCM 模块的组成部分

在Adaptive AUTOSAR中，UCM 模块由以下核心部分构成：

图 3. UCM Master Architecture

UCM Master作为中央协调者，管理多个UCM Subordinate实例，每个Subordinate可能对应不同的ECU或软件组件。

2.1 UCM Master

核心职责：作为更新和配置管理的中央协调者，负责全局控制。

发起软件更新（例如OTA）、配置变更请求。

管理多个UCM Subordinate的生命周期。

监控所有Subordinate的状态，处理错误和回滚。

应用场景：云端OTA服务器、车载中央网关或高性能计算单元（HPC）。

UCM Master通过使用PackageManagement服务和通信管理功能集群可以与不同机器上的UCM Subordinate进行通信。主要是负责检索有关机器上软件包当前状态的信息，并将合适的软件包传输给UCM Subordinate。

2.2 UCM Subordinate

核心职责：作为执行单元，负责本地操作。

接收Master的指令，执行软件包操作（安装、更新、移除）。

上报本地资源状态（如存储空间、当前软件版本）。

实现原子化操作（例如事务性更新，失败时回滚）。

与状态管理（STM）、加密（Cryptography）、持久性（Persistency）等功能集群交互，确保更新过程的安全性。

管理本地软件集群数据库（SWC Database），记录已安装软件的状态和文件信息。

应用场景：单个ECU或功能域控制器。

UCM Subordinate是一个守护进程（ara-pkgmanagerd），负责执行更新。车辆中的每个Machine都将有一个UCM Subordinate实例，该实例由中央UCM Master实例通过通信管理功能集群使用PackageManagement服务控制。

2.3 UCM Master 和 Subordinate 的交互流程

2.3.1 内部状态

在应用程序更新期间，UCM Subordinate将经历内部状态的转变。UCM Master用于使用PackageManagement服务发起状态转变。状态转变的图表可以在图中看到。

图 4. UCM Internal State Machine

2.3.2 交互流程

交互基于Adaptive AUTOSAR的 服务导向架构（SOA），通过标准化的API和SOME/IP通信协议实现。

(1) 初始化与状态同步

Master→Subordinate：

通过GetInstalledPackages 或GetSwClusterState方法获取Subordinate的当前软件/配置状态。

Subordinate → Master：

返回状态信息（如软件包版本、校验和、依赖关系）。

(2) 更新/配置操作流程

1. 操作请求：

Master通过 TransferStart发起传输请求，推送更新包（例如差分更新文件）或配置数据。

使用 TransferData 分段传输数据，确保大文件的分块可靠性。

TransferExit 方法接收软件包。

2. 验证与准备：

Subordinate调用 Verify 方法校验数据完整性（例如数字签名、哈希值）

检查资源（如存储空间、依赖版本）是否满足条件。

解析清单文件（Manifest），提取制品（Artifacts）。

3. 执行操作：

Master通过PrepareUpdate和StartUpdate触发安装或配置变更。

调用 Activate 执行操作，并通知状态管理关闭或重启相关应用程序。

Subordinate在事务性上下文中执行操作，确保原子性。

4. 状态反馈与提交：

Subordinate通过 GetUpdateStatus 上报进度（例如 UPLOADING、VERIFYING、INSTALLING）。

通过 VerifyUpdate 检查更新完整性，操作成功后，Master发送 Commit命令使变更生效；失败时触发回滚（Rollback）。

(3) 错误处理与恢复

Subordinate主动上报：通过 NotifyEvent 发送错误码（例如 INSUFFICIENT_STORAGE）。

Master协调恢复：根据错误类型重试、回滚或触发诊断服务（例如DTC记录）。

UCM Master和Subordinate通过标准化的服务接口和事务性操作，实现了分布式车载系统的安全、可靠更新。

2.4 UCM Client

UCM客户端是一种针对特定项目的自适应应用程序，主要职责是作为外界与UCM之间的桥梁。它不仅能够接收来自不同来源（如云端服务、诊断测试仪等）的OTA（Over-The-Air，空中下载）软件包，还能够根据项目需求决定最佳的更新时机和内容。

主要功能如下：

软件包接收：UCM客户端可以从本地文件系统或通过远程OTA方式接收软件包。需要注意的是，AUTOSAR标准并未规定用于与基于云的软件包仓库通信的具体OTA协议。

更新决策：依据内部逻辑或外部输入，UCM客户端可以智能地选择何时以及如何处理接收到的软件包。

与UCM交互：UCM客户端直接使用ARA::COM和服务接口PackageManagement与UCM进行交互。ARA::COM提供了一种基于服务导向的通信接口，而PackageManagement则是由UCM提供的服务接口，用于管理和执行软件包的更新流程。

根据具体项目的需求，UCM客户端的功能可以进一步扩展，例如增加对特定更新策略的支持，或是增强与其他系统组件的集成能力。

2.5 软件包（Software Package）

2.5.1 软件包与车辆包的概念

软件包：作为UCM（Update and Configuration Management）的基本操作单元，每个软件包封装了针对UCM的操作（安装、更新、移除）。一个典型的软件包包括：

应用程序（Executables）和配置数据（Data）：实际需要部署到车辆上的可执行文件和配置信息。

Manifest文件：这是一个ARXML格式的元数据文件，包含了软件包的关键信息如名称、版本号、依赖关系等。此外，Manifest还支持身份验证和完整性验证，确保软件包来自可信来源且未被篡改。

车辆包：由原始设备制造商（OEM）在后端系统中组装完成，车辆包整合了针对具体车辆所需的所有软件包。它同样包含一个Manifest文件，这个文件不仅记录了各软件包的信息，还包括活动编排（即更新操作的顺序和条件）和车辆内部软件包分发所需的其他字段。这种结构使得车辆包可以作为一个整体被发送到车辆，并确保所有组件能按照预定计划进行更新。

2.5.2 打包与组装流程

1.查询与合并：当需要对车辆进行软件更新时，服务器会从后端数据库中查询相关的软件包。然后，这些软件包的清单（Manifests）会被合并到车辆包的主清单中，确保所有必要的更新都被包括进来，并且符合车辆的具体需求。

2.组装车辆包：在合并完成后，组装过程将开始创建最终的车辆包。这一步骤不仅仅是简单地将各个软件包组合在一起，还需要根据车辆的具体情况调整更新策略，比如确定哪些软件包应优先安装，如何处理依赖关系等。

3.下发至车辆：一旦车辆包组装完成，它将通过安全可靠的传输机制（例如OTA技术）下发到目标车辆。在此过程中，使用适当的通信协议以保证数据的安全性和完整性。

4.安装与验证：车辆接收到车辆包后，将按照预设的规则执行安装程序，并通过一系列验证步骤确保更新的成功实施。这通常涉及到与UCM模块的紧密合作，利用其提供的功能来管理整个更新过程。

2.5.3 软件包的组成

图 5. Software Package Structure

软件包结构：

Manifest文件：描述操作类型（安装/更新/移除）、依赖关系、版本信息、加密证书等关键信息。

Artifacts：包含可执行文件、配置文件等，支持TAR归档或镜像格式。此外，还包括数据文件，即应用程序所需的配置或资源文件。

身份验证块：采用链式签名（RSA 2048、SECP256R1）和哈希（SHA256）确保软件包的安全性，防止未经授权的修改或损坏。

版本管理：遵循语义版本（Semantic Versioning），拒绝降级操作，确保系统的稳定性和兼容性。

二进制包特性：

支持包级别的完整性和真实性检查。

兼容直接（流式）或间接（存储）更新方式。

提供通用格式用于图像、应用程序和设备更新。

支持不同包格式版本的处理。

根据底层ara::com限制支持不同的片段或块大小。

易于扩展以适应不同的或新的格式。

图 6. 签名身份验证块

块索引表（BIT）和签名身份验证块共同作用，下图是通过链式身份验证方法保障软件包的安全性，具体包括签名和哈希存储机制。

图 7. 链式身份验证与存储

#03UCM的依赖与相关模块的交互

3.1 UCM依赖的功能集群

UCM Client是一种与UCM协作的应用程序，它将软件包传输给UCM，并支持（项目特定的）OTA协议。

状态管理（State Management, STM）：

在更新前关闭应用程序，更新后重启，并管理功能组（如 Off、Verify 状态）。

加密（Cryptography）：

验证软件包签名和证书链，确保来源合法性和完整性。

持久性（Persistency）：

存储诊断会话信息，支持回滚操作（由应用程序自行管理）。

执行管理（Execution Management, EXM）：

管理自适应应用程序的生命周期，确保更新后配置重新加载。

3.2 UCM与相关模块的交互

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 的核心守护进程，处理本地更新操作。

#04 UCM的核心功能

1. 软件包管理

UCM处理软件包的传输、解析及执行。每个软件包都包含一个或多个<SoftwareCluster>元素，这些元素描述了需要执行的操作及其相关制品。UCM 以 软件包（Software Package） 为最小管理单元，涵盖以下功能：

传输：支持流式传输（Streaming）与分块传输（Chunked Transfer），优化带宽与内存占用。

验证：基于 X.509 证书链 验证软件包来源，通过 SHA256/RSA 2048 确保内容完整性。

安装与更新：按需执行安装（Install）、更新（Update）或移除（Remove）操作。

依赖解析：检查软件包间的版本依赖（如 dependsOn），拒绝冲突版本（如主版本不兼容）。

2. 状态管理

UCM依赖于状态管理器（State Manager, STM）来确保在更新前后的系统状态正确转换。例如，在更新之前停止应用程序，并在更新后重启它们。管理以下状态转换：

空闲（Idle）：无更新任务，系统正常运行。

处理中（Processing）：软件包传输与解析阶段。

激活（Activating）：执行安装或更新操作。

回滚（Rollback）：更新失败时恢复至上一稳定状态。

3. 资源管理

UCM在更新过程中检查所需的存储空间、内存和其他计算资源是否充足，避免因资源不足导致的更新失败。

存储空间：动态检查目标 ECU 的存储容量，拒绝超限操作。

内存分配：为并行传输与处理预留资源，避免资源耗尽。

计算资源：在激活阶段协调 CPU 占用，确保实时性任务不受影响。

4. 版本报告与历史记录

软件版本追踪：记录每个软件集群的版本号、供应商与更新时间。

操作日志：存储更新成功/失败记录，支持故障诊断。

审计功能：符合法规要求（如 UNECE R155/R156）的日志可追溯性。

UCM 模块的配置与工作流程详解

准备阶段：首先需要创建一个包含所需更新信息的软件包。

使用AP工具链配置SoftwareCluster和SoftwarePackage。

创建制品归档（例如TAR文件），这些文件包含了要更新的应用程序、配置文件等。将制品归档与清单文件一起打包成最终的软件包。

确保目标ECU上已正确配置并运行了必要的服务，如ara-pkgmanagerd（UCM的核心服务）。

1. 配置流程

UCM 的配置需通过AP工具链完成，具体步骤如下：

(1) 配置 SoftwareCluster

关键属性：

vendorId（必填）：标识供应商。

version（必填）：遵循语义版本（主版本.次版本.修订号）。

category（必填）：分为 APPLICATION_LAYER（可移除）、PLATFORM_CORE（不可移除）、PLATFORM（平台软件）。

update_type（必填）：Application、Image 或 Device（当前仅支持前两者）。

依赖关系：

通过 xAAP 扩展属性定义运行时依赖，确保激活前依赖项已满足。

制品配置：

定义文件路径（root_path）、压缩类型（compression_type）、归档格式（archive_type）等。

(2) 配置 SoftwarePackage

操作类型：install、update 或 remove。

激活动作：nothing（无需操作）、reboot（重启机器）、restartApplication（重启应用）。

加密证书：需配置证书链（X.509 DER/PEM 格式），确保软件包签名可验证。

(3) 生成软件包

生成一个软件包通常涉及三个步骤：

1. 使用UCM Manifest编辑器创建一个包Manifest

2. 创建包含要修改的可执行文件和配置数据的工件存档

3. 将工件存档和manifest打包在一起形成一个软件包

文件要求：制品需命名为 artefact_<ID>.tar，清单文件必须重命名为 manifest。

(4) 目标环境配置

UCM Subordinate 配置：

设置临时目录（scratch_folder）、软件集群数据库路径（swc_db_folder）。

启用与状态管理（fc_stm_enable=true）和执行管理（fc_exm_enable=true）的交互。

加密配置：确保加密守护进程（crypto_daemon）的证书存储中包含根证书。

2. UCM的工作流程

UCM 的更新操作分为 传输、处理、激活、验证、完成事务 五个阶段：

图 8. Software Package State Machine

(1) 传输阶段

使用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

ProcessSwPackage：

解析清单文件，提取制品至临时目录。

验证依赖关系和版本兼容性（拒绝旧版本或冲突包）。

(3) 激活阶段

执行更新操作：根据清单文件中的指示，UCM Subordinate执行相应的操作（安装、更新或移除）。在此过程中，它会与状态管理器交互以确保系统处于安全状态，并适当停止或重启受影响的应用程序。

检查依赖关系：在激活之前，UCM Subordinate会检查所有的依赖关系是否满足，确保新版本能够正常运行。

图 12. Activating a Software Package

Activate：

1. 依赖检查：确保所有依赖项已满足。

2. 状态管理交互：

调用 UpdateRequest::RequestUpdateSession 请求安全状态。

调用 UpdateRequest::PrepareUpdate 关闭受影响功能组（终止应用程序）。

3. 执行操作：根据清单安装/更新/移除文件（直接修改 POSIX 文件系统或镜像）。

(4) 验证阶段

启动并验证应用程序：一旦激活成功，相关功能组会被切换到“验证”状态，允许新的或更新后的应用程序启动并自我验证其完整性。

回滚机制：如果验证失败，UCM会尝试回滚至之前的稳定状态，保证系统的可用性。

如果更新过程中出现错误，UCM能够自动回滚至先前版本，确保系统稳定。

问题：更新失败后，备份文件损坏导致无法回滚。

解决方案：

双重备份：在独立存储分区（如 eMMC 的 A/B 分区）保留两份备份。

事务日志：记录每一步操作，支持断点续滚。

图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) - 处理后的软件包（无论是新安装还是更新的包）已经成功完成激活。在此生命周期状态下，软件包的<软件集群>已准备好运行。