2. 法规基础
UN R156 是联合国欧洲经济委员会（UNECE）在世界车辆法规协调论坛（WP.29）框架下推出的关于软件更新与软件更新管理系统（SUMS）的法规。它并不是一项“只针对 OTA 功能”的推荐性指南，而是面向整车型式批准（Type Approval）的强制性法规文本。理解 R156，必须从它为何出现、管什么、要求什么、以及不同市场如何落地四个层面展开。
一、出台背景：软件定义汽车带来的监管真空
传统汽车的型式批准建立在“硬件冻结”假设之上：车辆在出厂时状态固定，后续变更主要通过召回或线下维修完成。但随着智能网联汽车普及，整车软件规模迅速膨胀，OTA 可以在用户不知情的情况下改变动力、制动、辅助驾驶、座舱甚至安全相关功能。这带来三类监管风险：
- 安全风险：一次错误刷写可能导致车辆不可控，或使已批准的安全功能失效。
- 合规风险：车辆软件版本与型式批准时的状态不一致，导致“批准状态漂移”。
- 责任风险：事故发生后，无法证明升级内容、升级时间、升级结果和用户告知情况。
在此背景下，WP.29 于 2021 年正式发布 UN R156，并与 UN R155（网络安全）形成“双法规”组合：R155 管“不被攻击”，R156 管“变更可控、可追溯、可审计”。其核心思路是把软件更新从“事后补救”前移为“体系化管理”，要求制造商建立 SUMS，并证明每一次软件更新都在受控流程内完成。
关键理解：R156 管的不是“能不能 OTA”，而是“软件更新是否在可审计、可追溯、可验证的管理体系下发生”。
二、适用范围：管什么车、什么软件、什么更新
R156 适用于 M、N、O 类车辆，以及其软件更新相关过程。它覆盖的软件范围包括：影响型式批准的软件、与安全相关的软件、以及可能影响车辆持续合规性的软件。更新方式既包括 OTA 远程升级，也包括线下刷写、诊断接口升级和产线刷写。
需要特别区分三个概念：
| 概念 | 含义 | R156 关注点 |
|---|---|---|
| 软件更新 | 替换或修改车辆软件的行为 | 更新前评估、更新中控制、更新后记录 |
| SUMS | 软件更新管理系统 | 组织、流程、职责、证据链 |
| RXSWIN | 与型式批准相关的软件识别号 | 软件版本与批准状态的对应关系 |
其中 RXSWIN 是审计中的高频对象。它用于标识“与法规相关的软件集合”，当该集合发生变化时，制造商必须判断是否需要重新批准、扩展批准或仅做记录。没有 RXSWIN 管理，就无法证明车辆当前软件状态与批准状态一致。
三、核心要求：SUMS 的六项能力
R156 对 SUMS 提出了一套可审核的能力要求，可归纳为六个方面：
- 配置管理：识别车辆软件基线、版本、依赖关系和目标车辆范围。
- 更新影响评估：判断更新是否影响安全、型式批准、网络安全和法规符合性。
- 更新过程控制：包括下载、校验、安装、回滚、失败处理和电源/网络条件判断。
- 用户告知：向车主说明更新目的、影响、时间、注意事项和失败后果。
- 记录与追溯：保存更新日志、版本记录、批准记录、执行结果和异常信息。
- 持续合规：确保更新后车辆仍满足原批准要求，必要时触发重新批准。
在工程落地中，这些要求通常映射为一条可审计的数据链：
车辆VIN → 当前软件版本 → RXSWIN → 更新包ID → 影响评估结论
→ 批准记录 → 下发任务 → 安装结果 → 回滚记录 → 审计日志审计时，审核员不会只看“有没有 OTA 平台”，而会沿着这条链检查：版本是否可识别、评估是否有依据、批准是否可追溯、执行是否可证明、异常是否闭环。
四、全球主要市场落地差异
R156 是 UNECE 法规，但不同市场通过“采纳、等效、转化”形成不同落地节奏。对出海车企而言，差异直接影响认证策略和审计准备。
| 市场 | 落地方式 | 对企业的实际影响 |
|---|---|---|
| 欧盟 | 作为型式批准强制要求，与 R155 同步实施 | 新车型必须提交 SUMS 符合性证据，审计深度高 |
| 日本、韩国 | 采纳 UNECE 法规并转化为本国要求 | 需按本地认证流程提交 SUMS 和软件更新记录 |
| 中国 | 以《汽车软件在线升级管理通知》等形成等效监管 | 强调备案、安全评估、用户告知和召回衔接 |
| 美国 | 以 NHTSA 安全召回和网络安全指南为主，非直接采用 R156 | 更关注安全缺陷报告和 OTA 对召回的影响 |
差异的核心不在“要不要管”，而在“用什么证据证明合规”。欧盟偏型式批准证据链，中国偏备案与安全评估，美国偏安全缺陷与召回责任。企业若用一套审计材料应对所有市场，往往会在用户告知、批准触发条件和记录粒度上出现缺口。
五、案例与误区复盘
某车企在欧洲推送一次座舱娱乐软件 OTA，认为“不影响安全，不需要走 SUMS”。但该更新同时修改了蓝牙协议栈，而蓝牙模块属于型式批准相关软件的一部分。审核时，因未更新 RXSWIN、未做影响评估、未保留批准记录，被判定 SUMS 运行无效。问题不在技术，而在变更影响判断缺失。
常见误区：把 R156 当成“OTA 平台功能清单”；只记录成功升级，不记录失败与回滚；认为非安全软件可以绕过 SUMS；认为中国备案与欧盟 SUMS 可以互相替代。这些都会导致审计证据链断裂。
正确的做法是：先建立软件基线与 RXSWIN 映射，再对每次更新执行影响评估，按评估结论触发相应批准或记录流程，最后把用户告知、执行结果、异常处理和回滚全部纳入审计日志。R156 的本质，是让“软件变更”像“硬件变更”一样，有批准、有记录、有责任、有追溯。