4. 相关标准与法规
自动驾驶安全论证不是“自说自话”的工程活动，它必须落在可被第三方审查、可被监管接受的标准与法规框架内。本节把与自动驾驶安全案例最相关的五类文件放在同一张“约束地图”上：ISO 26262 管功能安全，ISO 21448 管预期功能安全，UL 4600 管全生命周期安全论证，ISO 21434 管网络安全，UN R157 管自动车道保持系统的型式批准。理解它们的边界与接口，是构建安全案例（Safety Case）的前提。
一、核心原理：五类文件的分工与接口
这五类文件并非互相替代，而是从不同“失效来源”切入，共同覆盖自动驾驶的风险空间。ISO 26262 关注 E/E 系统故障导致的危害，核心是 ASIL 等级、安全目标、功能安全概念与技术安全概念；ISO 21448 关注在没有系统故障时，因性能局限、场景理解不足导致的危害，核心是 SOTIF 相关危害行为与触发条件；UL 4600 不规定具体技术指标，而是规定“如何论证”自动驾驶产品在全生命周期内是安全的，强调论证结构、证据与假设管理；ISO 21434 关注恶意攻击导致的危害，核心是 TARA（威胁分析与风险评估）与网络安全目标；UN R157 则是具有法律约束力的型式批准法规，规定 ALKS 在特定速度与道路条件下的性能要求与驾驶员监控要求。
关键接口：ISO 26262 的安全目标与 ISO 21448 的 SOTIF 目标需要合并进入 UL 4600 的安全论证；ISO 21434 的网络安全目标又可能反向影响 26262 的安全目标（例如被攻击后仍须维持安全状态）；UN R157 则把部分目标转化为可测试的法规条款。
二、方法流程：从标准条款到安全案例条目
把标准要求转化为安全案例，通常遵循“识别适用条款—建立目标—设计活动—生成证据—映射论证”的流程。以 ISO 26262 为例，先做 HARA 得到安全目标与 ASIL，再推导功能安全概念与技术安全概念，最后通过验证与确认活动产生证据。ISO 21448 则从“预期功能”出发，识别危害行为，分析触发条件，通过场景测试与改进降低残余风险。ISO 21434 从资产识别开始，做 TARA，定义网络安全目标，再设计缓解措施并验证。UL 4600 要求把上述证据组织成可审查的论证结构，并明确假设、运维限制与退役策略。UN R157 则把 ALKS 的法规要求拆成可测试条款，直接进入型式批准测试。
安全案例条目示例（YAML 片段）
claim: "ALKS 在 60 km/h 以下可避免追尾"
standard_ref:
- "UN R157 §5.1.1"
- "ISO 26262 ASIL-B 安全目标 SG-03"
- "ISO 21448 危害行为 HB-07"
evidence:
- "HARA 报告 HARA-2024-011"
- "SOTIF 场景测试报告 SOTIF-2024-027"
- "TARA 报告 TARA-2024-005"
assumption: "驾驶员在 10 秒内可接管"
status: "已验证"
三、案例/场景：一次“多标准联合审查”
假设某 L3 拥堵领航功能在高速公路上以 60 km/h 运行。ISO 26262 关注的是：如果制动执行器失效，系统能否进入安全状态？对应安全目标可能是“避免非预期制动”，ASIL 等级由严重度、暴露率与可控性决定。ISO 21448 关注的是：如果前方出现异形车辆，感知算法没有识别，系统是否会做出危险行为？对应的是危害行为与触发条件，需要通过场景库与实车测试降低残余风险。ISO 21434 关注的是：如果 CAN 总线被注入恶意报文，是否会导致非预期加速？对应 TARA 与网络安全目标。UL 4600 则要求把上述三类证据组织成统一论证，并说明“驾驶员 10 秒接管”这一假设在运维中如何被监控。UN R157 则直接规定 ALKS 在 60 km/h 以下的车道保持、跟车距离与驾驶员监控要求，并给出型式批准测试方法。
场景启示：同一个功能，五类文件会问出五个不同的问题。安全案例的价值，正是把五个答案组织成一条可追溯的论证链，而不是各自为政。
四、误区/复盘：常见理解偏差
- 误区一：有了 ISO 26262 就等于安全。26262 只覆盖系统故障，不覆盖性能局限与恶意攻击，必须与 21448、21434 联合使用。
- 误区二：UL 4600 是“技术标准”。它更像“论证标准”，规定如何组织证据与假设，不直接规定雷达探测距离等指标。
- 误区三：UN R157 只适用于 ALKS。它是法规基线，其测试方法与监控要求常被其他自动驾驶法规借鉴。
- 误区四：标准之间可以互相替代。它们覆盖不同失效来源，替代会导致论证出现空洞。
| 标准/法规 | 核心关注 | 关键输出 | 在安全案例中的角色 |
|---|---|---|---|
| ISO 26262 | E/E 系统故障 | 安全目标、ASIL、技术安全概念 | 提供功能安全证据 |
| ISO 21448 | 性能局限与场景理解不足 | 危害行为、触发条件、残余风险 | 提供 SOTIF 证据 |
| UL 4600 | 全生命周期安全论证 | 论证结构、假设、运维限制 | 组织并审查整体论证 |
| ISO 21434 | 恶意攻击 | TARA、网络安全目标、缓解措施 | 提供网络安全证据 |
| UN R157 | ALKS 型式批准 | 法规条款、测试要求、监控要求 | 提供法规符合性证据 |
复盘要点：在项目早期就应建立“标准—目标—证据”的映射表，避免后期补证据时发现条款遗漏。尤其注意 ISO 21434 与 ISO 26262 的交互：网络安全事件可能触发功能安全目标，二者需要在架构设计阶段就协同考虑。
综上，ISO 26262、ISO 21448、UL 4600、ISO 21434 与 UN R157 共同构成自动驾驶安全论证的“约束地图”。理解它们各自覆盖的失效来源、关键输出与接口关系，才能把分散的工程活动组织成一条可审查、可追溯、可接受的安全案例。