4. SUMS体系

在 UN R156 的合规框架中，SUMS（Software Update Management System，软件更新管理系统）不是一套可购买的软件工具，而是整车企业为管理软件更新活动所建立的一套组织、流程、技术与证据相互咬合的管理体系。法规关注的不是“你有没有升级工具”，而是“你能否证明每一次软件更新都受控、可追溯、可评估、可审计”。因此，SUMS 的认证本质上是体系审核，而非产品功能测试。

一、SUMS 的定义与法规定位

UN R156 将 SUMS 定义为：制造商用于规划、执行、验证和记录软件更新的一套正式流程与组织安排。它覆盖从软件版本识别、更新包生成、传输、安装、激活，到更新后验证与回滚的完整生命周期。法规要求制造商在申请车辆型式认证前，先证明其 SUMS 符合 R156 附录要求，再对具体车型的软件更新能力进行认证。

SUMS 的适用对象包括：乘用车、商用车、摩托车等具备软件更新能力的车辆。只要车辆支持 OTA 或通过诊断接口进行软件刷写，且更新可能影响型式认证相关参数，就必须纳入 SUMS 管理。值得注意的是，SUMS 并不要求所有更新都走 OTA，但要求所有影响认证的软件更新都必须经过体系化评估。

二、SUMS 的组成要素

从审核视角看，SUMS 由六个相互关联的要素构成，缺一不可：

• 组织与职责：明确软件更新管理负责人、跨部门接口（研发、质量、法务、售后、网络安全）及供应商协同责任。
• 流程与程序：覆盖更新需求、风险评估、开发验证、发布审批、部署执行、监控回滚的书面程序。
• 技术基础设施：OTA 云平台、车辆端更新代理、版本管理库、签名与加密机制、诊断刷写工具。
• 记录与追溯：每次更新的配置项、影响范围、测试报告、审批记录、车辆执行日志必须可关联。
• 风险评估机制：判断更新是否影响安全、环保、防盗、自动驾驶等认证相关参数。
• 持续改进与审计：内部审核、管理评审、不符合项纠正与预防措施。

这六个要素不是并列清单，而是以“更新活动”为轴心串联。例如，一次影响制动控制的软件更新，会同时触发组织职责中的安全负责人审批、流程中的风险评估、技术设施中的签名验证、记录中的测试证据，以及审计中的变更追溯。

三、过程模型：从需求到闭环

SUMS 的过程模型可以概括为“五阶段闭环”，每个阶段都有明确的输入、输出和审核证据。下图展示了该过程模型及其关键控制点：

该模型的关键在于：阶段之间不是简单串行，而是存在反馈回路。监控阶段发现的异常或不符合项，必须回流到需求与风险评估阶段，触发更新分类的重新判定。审核员通常会抽取一次真实更新，验证这条闭环是否完整。

四、认证要求与审核要点

SUMS 认证由型式认证机构执行，通常包括文件审核和现场审核两部分。文件审核关注体系文件的完整性与一致性；现场审核关注流程执行的真实性与可追溯性。下表列出了主要认证要求与常见审核证据：

五、案例场景：一次影响制动参数的 OTA 更新

假设某车型通过 OTA 更新电子稳定控制（ESC）软件，调整了制动压力控制逻辑。该更新直接影响型式认证中的制动性能参数，因此必须走完整 SUMS 流程：

1. 需求阶段判定为“影响认证参数”，标记为高风险更新。
2. 风险评估确认需重新进行制动性能测试，并评估网络安全影响。
3. 开发阶段生成带签名的更新包，在台架和实车上完成验证。
4. 发布阶段由安全负责人和质量负责人双签审批，先灰度推送 100 台。
5. 监控阶段收集执行日志，确认无异常后全量推送，并归档全部证据。

六、常见误区与复盘

在 SUMS 建设与认证过程中，企业常陷入以下误区：

• 把 SUMS 当成 IT 项目：只关注 OTA 平台功能，忽视流程、职责和记录，导致审核时无法提供完整证据链。
• 风险评估流于形式：所有更新都填“无影响”，无法解释判定依据，审核员会直接质疑体系有效性。
• 版本追溯断裂：车辆端版本与云端版本库不一致，或供应商软件版本未纳入管理。
• 回滚机制未验证：只在文档中写了回滚流程，但没有实际测试记录。
• 记录保存不完整：更新日志分散在多个系统，无法按 VIN 或更新批次快速检索。

总结来看，SUMS 是 R156 合规的基石。它要求企业把软件更新从“技术操作”提升为“受控管理过程”，通过组织、流程、技术和记录的协同，证明每一次软件更新都经过评估、验证和追溯。只有体系真正运行并留下完整证据，认证才能顺利通过，后续的车型软件更新认证才有稳固基础。