3. 法规与标准
在 L2+ 与 L3 量产验证中，法规与标准不是“文档附件”，而是决定测试边界、放行条件与责任归属的工程输入。L2+ 通常仍要求驾驶员持续监控，而 L3 在特定运行设计域（ODD）内允许驾驶员脱手脱眼，这意味着验证必须同时覆盖功能正确性、功能安全、预期功能安全、网络安全以及法规符合性。本节从国内外法规框架出发，梳理 UN R157、ISO 21448、ISO 26262 以及网络安全要求之间的分工与协同关系。
一、国内外法规框架：从“准入”到“运行”
国内层面，工信部、公安部、交通运输部等部门发布的《智能网联汽车道路测试与示范应用管理规范》构成了道路测试的基础管理框架，要求测试主体具备相应资质、车辆通过封闭场地测试、配备安全员并购买保险。2023 年以来，四部门联合发布的 L3 准入试点通知进一步明确了“产品准入”与“上路通行”的区分，要求企业提交功能安全、预期功能安全、网络安全、数据安全等完整证明材料。此外，GB/T 40429《汽车驾驶自动化分级》为 L0-L5 的定义提供了国标依据，GB 44495、GB 44496 等强制性标准则对整车信息安全与软件升级提出要求。
国际层面，联合国 WP.29 框架下的 UN R157（自动车道保持系统 ALKS）是全球首个针对 L3 的具有约束力的法规，欧盟、日本、韩国等已将其纳入准入体系。ISO 26262 与 ISO 21448 分别从功能安全和预期功能安全两个维度提供方法论，ISO/SAE 21434 则聚焦网络安全工程。美国以 NHTSA 自愿性指南和州级立法为主，联邦层面尚未形成统一强制法规，但 FMVSS 对传统安全项仍有约束。整体来看，法规框架呈现“国际法规定基线、国标细化落地、企业标准补空白”的三层结构。
二、UN R157：L3 ALKS 的法规基线
UN R157 针对 M1 类车辆在高速公路、有物理隔离、无行人与非机动车的场景下，允许系统在 0-60 km/h（后续扩展至 130 km/h）范围内执行纵向与横向控制。其核心要求包括：系统必须识别驾驶员是否处于可接管状态；在触发接管请求后，驾驶员未响应时系统应执行最小风险策略（MRM），如减速停车并开启危险报警灯；系统需具备黑匣子（DSSAD）记录自动驾驶状态、接管请求与退出原因；同时要求制造商提交安全案例，证明系统在 ODD 内不会引发不合理风险。
对验证工程师而言，UN R157 直接转化为测试项：接管请求时序、驾驶员监控有效性、MRM 执行成功率、DSSAD 数据完整性、ODD 边界识别能力。这些测试项必须在封闭场地与真实高速场景中重复验证，并保留可追溯的日志。
三、ISO 26262 与 ISO 21448：功能安全与预期功能安全的分工
ISO 26262 关注由电子电气系统故障引起的危害，通过 ASIL 等级（A-D）确定开发与验证的严格程度。其核心流程包括危害分析与风险评估（HARA）、安全目标制定、功能安全概念、技术安全需求、硬件与软件验证。对于 L3 系统，转向、制动、电源等关键路径通常需达到 ASIL D，验证手段包括故障注入、FMEA、FTA 和硬件在环测试。
ISO 21448（SOTIF）则关注“无故障但性能不足”导致的危害，例如传感器在逆光、雨雾、异形车辆场景下的误识别或漏识别。SOTIF 的核心是识别触发条件、评估已知不安全场景、探索未知不安全场景，并通过场景库、仿真、封闭场地和道路测试逐步收敛。L2+ 与 L3 的许多“幽灵刹车”“误识别”问题，本质上属于 SOTIF 范畴，而非传统功能安全。
关键区分：ISO 26262 问“系统坏了会不会危险”，ISO 21448 问“系统没坏但看不懂会不会危险”。两者在 L3 验证中必须并行推进，缺一不可。
四、网络安全与数据合规要求
随着车辆联网与 OTA 升级普及，网络安全成为量产验证的强制项。ISO/SAE 21434 要求建立网络安全管理系统（CSMS），覆盖概念、开发、生产、运行与报废全生命周期。UN R155 则要求制造商通过 CSMS 认证，并针对车辆类型进行威胁分析与风险评估（TARA）。国内 GB 44495 对整车信息安全提出强制性要求，涵盖外部接口、通信、软件升级、数据存储等维度。
验证层面，网络安全测试包括：CAN 总线报文注入与模糊测试、OTA 升级包签名校验、诊断接口权限验证、蓝牙/WiFi 接口渗透测试、敏感数据加密存储检查。数据合规方面，需关注《汽车数据安全管理若干规定》对地理信息、车外人脸、声音等数据的采集与出境限制。
五、标准协同关系与验证映射
下表梳理了主要标准在 L3 量产验证中的关注点与典型测试输出，便于在项目计划中分配验证资源。
| 标准/法规 | 核心关注 | 典型验证输出 |
|---|---|---|
| UN R157 | ALKS 功能、接管、MRM、DSSAD | 接管时序报告、MRM 测试记录、DSSAD 日志 |
| ISO 26262 | E/E 故障导致的危害 | HARA、安全案例、故障注入报告 |
| ISO 21448 | 性能局限与触发条件 | 场景库、SOTIF 分析、未知场景探索报告 |
| ISO/SAE 21434 | 网络安全全生命周期 | TARA、渗透测试报告、CSMS 认证 |
| GB 44495/44496 | 整车信息安全与软件升级 | 合规测试报告、OTA 安全评估 |
六、案例与误区复盘
某 L3 项目在封闭场地测试中，系统在 60 km/h 下成功识别静止车辆并触发 MRM，但在真实高速场景中，因前车突然变道导致本车传感器短暂遮挡，系统未及时识别相邻车道静止车辆，接管请求延迟约 1.2 秒。复盘发现，该场景属于 SOTIF 中的“传感器遮挡+动态目标”触发条件，而项目初期仅按 ISO 26262 做了故障注入，未充分覆盖性能局限场景。后续补充了遮挡场景库与仿真回归，并在 ODD 定义中增加了“相邻车道静止车辆”的边界约束。
常见误区：把 UN R157 当作“功能清单”而非“安全案例要求”；把 SOTIF 当作“仿真即可覆盖”；把网络安全测试留到量产前最后阶段。三者都会导致验证返工与准入延迟。
综上，L2+ 与 L3 的法规标准验证应建立“法规基线—安全方法论—网络安全—数据合规”的四维矩阵，在项目早期完成标准映射与测试项分解，并在每个验证阶段保留可追溯的证据链。只有将标准要求转化为具体的测试用例、场景库与日志记录，才能真正支撑量产放行与责任界定。