4. SUMS体系架构

SUMS（Software Update Management System，软件更新管理体系）不是一张流程图，也不是一份更新说明文档，而是一套把法规要求、工程活动、组织职责、技术工具和证据记录编织在一起的体系。理解SUMS架构，关键要回答五个问题：体系分几层、过程怎么流转、谁来负责、靠什么技术支撑、用什么文档留痕。本节从这五个视角给出整体概览，帮助后续章节逐层展开。

一、体系分层：从法规到证据的五层结构

SUMS通常可划分为五层，自顶向下依次是法规与标准层、管理过程层、工程过程层、技术支撑层和证据记录层。上层提出“必须做什么”，下层回答“具体怎么做、由谁做、留下什么”。分层的目的不是增加文档，而是让每一层的要求都能被追溯：任何一条更新记录，都应能向上追溯到法规条款，向下追溯到具体工具、测试用例和审批人。

二、过程模型：更新全生命周期的闭环

SUMS的核心过程模型是一个闭环：需求与影响分析 → 更新方案设计 → 开发与集成 → 验证与确认 → 发布与部署 → 监控与反馈 → 变更与再评估。与普通软件开发流程不同，SUMS强调“更新前评估”和“更新后监控”两端：更新前必须判断是否影响型式认证、功能安全或网络安全；更新后必须收集现场数据，验证更新效果并识别次生风险。

过程模型中还包含三条贯穿线：配置管理、变更管理和风险管理。它们不单独占据某个阶段，而是横跨所有阶段，确保每次更新都有基线、有审批、有风险评估。

三、组织架构：三层职责与接口

组织架构通常分为决策层、管理层和执行层。决策层由管理者代表和跨部门委员会组成，负责批准更新策略、重大变更和资源投入；管理层由SUMS经理、质量、安全、网络安全和法规接口人组成，负责过程定义、审核和对外沟通；执行层由开发、测试、运维、现场服务和供应商接口人组成，负责具体实施。三层之间通过明确的接口和升级路径衔接，避免“更新出问题找不到责任人”。

四、技术架构：工具链与数据流

技术架构支撑过程落地，典型包括需求管理工具、版本控制与构建系统、测试管理平台、OTA发布平台、车辆端更新代理、日志与监控系统。数据流从车辆端上报更新状态和故障码，进入监控平台，再反馈到变更管理，形成技术闭环。技术架构的关键不是工具数量，而是工具之间的数据贯通：需求ID、变更单、测试用例、发布包和车辆VIN必须能关联。

五、文档体系：证据链的载体

文档体系是SUMS的“记忆”。它至少包括体系级文档（方针、手册、程序文件）、项目级文档（更新计划、影响分析报告、测试报告、发布说明）和记录级文档（审批记录、日志、监控报告）。文档不是越多越好，而是要形成可审计的证据链：每份文档有编号、版本、审批和保存期限。

六、场景案例：一次OTA更新的体系穿行

假设某车型需要修复电池管理软件的估算偏差。法规层确认该更新涉及型式认证参数；管理过程层启动变更评审，判定为重大更新；工程过程层完成影响分析、代码修改和HIL测试；技术支撑层生成签名发布包，通过OTA平台分批推送；证据记录层保存审批单、测试报告、推送日志和车辆回传数据。整个过程在SUMS中形成一条完整追溯链，任何一个环节缺失，审计时都会暴露。

七、常见误区与复盘

• 误区一：把SUMS当成文档堆。文档只是证据载体，真正运行的是过程和职责。
• 误区二：过程模型只画开发阶段。忽略更新前评估和更新后监控，会导致合规风险。
• 误区三：组织架构只有执行层。缺少决策层和管理层，重大更新无法及时决策。
• 误区四：技术工具各自为政。需求、测试、发布数据不贯通，追溯成本极高。
• 误区五：文档版本失控。旧版本测试报告被误用，是审计中最常见的硬伤。

SUMS追溯链示例：
法规条款：UN R156 / GB 44496
  └─ 管理程序：SUMS-P-03 软件更新影响分析
       └─ 工程活动：变更单 CR-2024-0187
            ├─ 影响分析报告：IA-0187
            ├─ 测试报告：TR-0187-HIL
            ├─ 发布包：PKG-0187-v2.1.0
            └─ 车辆记录：VIN... 更新成功 / 回传日志

综上，SUMS体系架构可以概括为“五层结构、一个闭环、三层组织、一条工具链、一套证据”。五层结构保证要求可追溯，闭环过程保证更新可控，三层组织保证责任可落实，工具链保证数据可贯通，文档体系保证证据可审计。后续章节将分别深入过程模型、组织职责、技术平台和文档模板，本节先建立整体地图。