系统安全保障

自动驾驶系统的安全性远比普通软件系统复杂——一旦失效可能直接危及生命。与此同时，自动驾驶系统高度依赖人工智能，其行为难以用传统方法完全验证。本节介绍自动驾驶领域的功能安全标准、SOTIF 流程、AI 特有的安全工程方法，以及如何把上述要素融入一个完整的安全案例（Safety Case）。

真实事故是所有安全工作的试金石——本节涉及的许多方法论都经过 §2.8 典型事故与经验教训中具体事件的"反向校准"。读者学完本节后，可以再回看那些事件，用更严格的视角诊断每一层失效。

安全标准体系

自动驾驶安全由多个互补标准从不同维度覆盖：

标准	制定组织	关注维度	核心方法
ISO 26262	ISO	功能安全（系统性和随机性硬件故障）	ASIL 等级、V字开发、FMEA/FTA
ISO 21448 (SOTIF)	ISO	预期功能安全（感知和AI的性能局限）	场景分类、覆盖度测试
ISO/SAE 21434	ISO/SAE	汽车网络安全（Cybersecurity）	TARA 威胁分析、纵深防御
UN R155 / R156	UNECE	网络安全 / 软件升级型式认证	国家级强制法规（2024 全面生效）
UL 4600	UL	自动驾驶系统整体安全评估框架	安全案例（Safety Case）
ISO/PAS 8800	ISO	AI 安全（机器学习组件的安全生命周期）	AI-specific 流程补充 ISO 26262 / 21448
ISO 8548	ISO	行为能力（Behavioral Competency）	L3+ 系统行为边界描述
ISO 24089	ISO	软件 OTA 更新安全流程	与 UN R156 对应
RSS	Mobileye	责任敏感安全（数学化安全保证）	安全距离公式、责任归属
E/C-NCAP	NCAP 联盟	新车碰撞安全评估	实车测试、评星

这些标准不是互斥的——一款 L4 Robotaxi 的量产交付通常要同时满足 ISO 26262 + ISO 21448 + ISO/SAE 21434 + ISO/PAS 8800 + UL 4600 + UN R155/R156。每个标准处理不同层面的风险，合起来才构成完整的"安全网"。

ISO 26262：功能安全

ISO 26262 是汽车行业最核心的功能安全标准，要求系统在存在故障的情况下仍能安全运行或安全停机。

ASIL 汽车安全完整性等级

汽车安全完整性等级（ASIL，Automotive Safety Integrity Level）分为 QM/A/B/C/D 五档，D 级为最高要求：

等级	故障后果	设计要求	典型应用
QM（质量管理）	无安全风险	常规质量流程	车载娱乐、空调控制
ASIL-A	轻微伤害风险	基础安全措施	雨刷、车窗升降
ASIL-B	中等伤害风险	故障检测与响应	辅助照明、泊车传感器
ASIL-C	严重伤害风险	冗余设计	电子稳定控制（ESC）
ASIL-D	危及生命	最高冗余 + 形式验证	线控制动、安全气囊、线控转向

ASIL 等级确定

ASIL 等级由三个因素的组合决定：

严重度（Severity, S0–S3）：S0 无伤害 → S3 危及生命
暴露率（Exposure, E0–E4）：E0 不可能 → E4 连续暴露（如行驶中的制动）
可控性（Controllability, C0–C3）：C0 完全可控 → C3 几乎不可控

高严重度 × 高暴露率 × 低可控性 → 高 ASIL 等级。

V 字形开发模型

ISO 26262 要求贯穿整个产品生命周期的 V 字形开发，左边为设计分解，右边为集成验证：

系统需求分析 ─────────────────────────────► 系统验证测试
      │                                           ▲
      ▼                                           │
系统功能设计 ──────────────────────────► 系统集成测试
      │                                           ▲
      ▼                                           │
硬件/软件设计 ──────────────────────► 硬件/软件集成
      │                                           ▲
      ▼                                           │
软件详细设计 ──────────────────────────► 软件单元测试

每个阶段需要完成相应的安全分析，并输出安全案例（Safety Case）文档证明设计满足安全目标。

FMEA 与 FTA

FMEA（失效模式与影响分析）：自底向上，逐一分析每个组件的失效模式（断路、短路、输出错误等）及其对系统的影响，评估风险优先级（RPN = 严重度 × 频率 × 可检测性）
FTA（故障树分析）：自顶向下，从系统级危害（如"车辆无法制动"）追溯到底层原因，建立布尔逻辑树，计算顶事件的发生概率

ASIL 分解

有时候一个 ASIL-D 级需求（例如"制动不得自发激活"）难以由单一子系统满足。ISO 26262 允许通过 ASIL 分解（Decomposition） 将其分配给两个充分独立的子系统：

\[ \text{ASIL-D} \;\Rightarrow\; \text{ASIL-B(D)} \;+\; \text{ASIL-B(D)} \quad\text{或}\quad \text{ASIL-C(D)} \;+\; \text{ASIL-A(D)} \]

关键前提：两条路径对共因故障（CCF） 必须充分隔离（独立电源、独立时钟、独立代码库）。典型应用：线控转向由主控 SoC（ASIL-B）+ 安全岛 MCU（ASIL-B）联合满足 ASIL-D 要求。

FTTI 时序预算

故障容忍时间间隔（FTTI，Fault Tolerant Time Interval） 是"故障发生 → 触发危害"之间可接受的最大时间窗口。每一项安全功能都需要推导 FTTI，并把它切分为检测时间 + 响应时间 + 执行时间：

FTTI = T_detect + T_decide + T_react

例如 ASIL-D 级制动系统常见 FTTI = 100 ms，其中 T_detect ≤ 30 ms，T_decide ≤ 30 ms，T_react ≤ 40 ms。设计时必须把这些预算落到具体硬件与软件环节（中断延迟、总线带宽、执行器响应）。

ISO 21448：SOTIF（预期功能安全）

传统功能安全假设"功能正确即安全"。但 AI 感知存在性能局限（如雾天摄像头失效、LiDAR 遇到反光路面），这不是"故障"而是"预期功能的局限"，ISO 21448 补充了这一空白。

SOTIF 四象限场景分类：

              已知（Known）    未知（Unknown）
安全（Safe）  ┌──────────────┬──────────────┐
              │   K₁：已知   │   U₁：未知   │
              │   安全场景   │   安全场景   │ ← 可接受（概率低）
              │ （目标：最大化）│              │
不安全（Unsafe├──────────────┼──────────────┤
              │   K₂：已知   │   U₂：未知   │
              │  不安全场景   │  不安全场景   │ ← 目标：最小化
              │ （通过设计消除）│              │
              └──────────────┴──────────────┘

验证目标：将 U₂ 场景充分暴露（使其转变为 K₂），再通过系统设计消除 K₂。仿真平台是暴露 U₂ 场景的关键手段。

ISO 26262 × SOTIF 联合流程

在 L3 以上系统的实践中，ISO 26262 与 ISO 21448 必须联合运行——两者处理不同类型的风险，任何一者缺席都会留下盲区：

┌─────────────────────── ISO 26262 ─────────────────────┐
│  关注故障：硬件随机故障、软件系统性故障                     │
│  输出：ASIL-D 等级的硬件冗余、V 字开发流程、FMEA/FTA        │
└───────────────────────────┬────────────────────────────┘
                            │  共享：HARA、Safety Case
┌─────────────────────── ISO 21448 ─────────────────────┐
│  关注性能：感知/预测/规划在预期 ODD 内的性能局限             │
│  输出：场景库、K₂/U₂ 缩减计划、可接受残余风险证据            │
└────────────────────────────────────────────────────────┘

典型流程编织节点：

项目启动：联合定义车辆级 Safety Goal 与 ODD；
危害分析：ISO 26262 HARA 与 ISO 21448 Hazardous Behavior Analysis 合并为一本 Hazard Library；
设计分解：故障类风险进 ISO 26262 V 字，性能类风险进 SOTIF 分析；
验证闭环：真实路测 + 仿真 + 场景库作为两个标准的共同证据；
残余风险评估：输出供监管审核的 Safety Case。

Hazard Library 与维护

Hazard Library 是整个安全工程的"活字典"，应满足：

每条记录包含：场景 ID、ODD 覆盖、触发条件、ASIL / 风险等级、关联安全目标、验证状态、责任人；
被自动化测试系统消费：每次发版时所有 Hazard 需重新回归；
与事故库联动：§2.8 中每起行业事件都应触发 Hazard Library 的更新评估；
版本化存储：Safety Case 审核人有权追溯某个条目在某个发版时的状态。

冗余设计原则

自动驾驶采用多层次冗余，确保任何单点失效不导致系统级危害：

传感器冗余

多种传感器（LiDAR + Camera + Radar）互相备份，任一失效系统仍可感知
同类型多个传感器（前向双摄、多角度毫米波雷达）提供一致性校验，检测单传感器异常

计算冗余

双主控 SoC（如 Tesla FSD HW3 双 NPU）：主计算失效，备份立即接管
Lockstep MCU：双核同步执行并实时比较输出，检测计算错误，适用于 ASIL-D 功能

通信冗余

双 CAN 总线 / 双车载以太网链路
关键控制信号多路传输，防止单线故障

电源冗余

主 12 V 电池 + 独立后备超级电容/蓄电池
制动系统配备独立 48 V 或双 12 V 供电回路，确保 ASIL-D 制动功能不受主电源影响

Fail-Safe vs Fail-Operational

策略	描述	适用自动驾驶级别
Fail-Safe	故障后立即执行最小风险机动（MRM）：减速靠边停车	L2 / L3
Fail-Degraded	降级功能运行，限速行驶至安全区域	L3 / L4 过渡
Fail-Operational	故障后完整保留足够功能，自主完成当前任务	L4 / L5

L4 无人驾驶（无驾驶员备份）必须实现 Fail-Operational：即便某传感器或计算单元失效，系统仍能安全地完成最小风险机动，将车辆停至安全位置。

RSS 责任敏感安全模型

Mobileye 提出的 RSS（Responsibility-Sensitive Safety）提供了数学化的安全距离定义，使自动驾驶系统在可归责事故中不承担责任。

纵向安全距离公式：

\[d_{\min,\text{lon}} = \left[ v_r \rho + \frac{v_r^2}{2 a_{r,\text{brake,min}}} - \frac{v_f^2}{2 a_{f,\text{brake,max}}} \right]^+\]

其中： - \(v_r, v_f\)：后车和前车速度 - \(\rho\)：反应时间（通常取 1–2 s） - \(a_{r,\text{brake,min}}\)：后车最弱制动能力（保守估计） - \(a_{f,\text{brake,max}}\)：前车最强制动能力（保守估计） - \([\cdot]^+\)：取正值

如果当前车间距 \(d > d_{\min}\)，自车在任何后续碰撞中不承担责任。

RSS 核心原则： 1. 不主动造成危险情景（不切入不安全间距） 2. 危险出现时必须正确响应（及时制动） 3. 响应时优先保证其他交通参与者的安全

Safety Case 与 GSN 论证

安全标准要求交付物不是"测试通过"的二元结论，而是结构化的论证（Assurance Argument），说明为什么读者（监管、客户、保险公司）有理由相信系统足够安全。Goal Structuring Notation（GSN） 是业界最常用的记法：

G1: 车辆在 ODD 内以可接受风险运营
 │
 ├── Strategy S1: 拆分为三类风险
 │    ├── G2: 随机硬件故障造成的风险可接受（ISO 26262）
 │    ├── G3: 性能局限造成的风险可接受（ISO 21448）
 │    └── G4: 恶意攻击造成的风险可接受（ISO/SAE 21434）
 │
 ├── Solution Sn1: FTA + FMEDA 报告
 ├── Solution Sn2: 场景库覆盖度报告 + 仿真结果
 └── Solution Sn3: TARA 报告 + 渗透测试记录

Goal (G)：希望证明的安全主张；
Strategy (S)：如何把大 Goal 拆成子 Goal；
Solution (Sn)：最终证据（测试报告、形式化证明、专家意见）；
Context (C) / Assumption (A)：论证依赖的前提条件。

UL 4600 与中国即将发布的 GB/T《自动驾驶安全案例指南》都采纳 GSN 方法论。

实战提示

真正难写的是 Assumptions——"我们假设 ODD 内雨势不超过 X mm/h"这样的条件如果不显式记录，未来运营时无法判断是否处于合规范围。

AI 特有的安全工程：ISO/PAS 8800

传统 ISO 26262 假设功能行为可以被完全规格化，但深度学习组件的行为只能被数据驱动地刻画。ISO/PAS 8800（2024 发布）首次给出了 AI 组件在汽车安全生命周期中的流程要求：

阶段	AI-specific 要求
数据采集	标注质量、代表性、分布平衡、标注一致性评估
训练	数据集版本管理、训练复现、模型卡（Model Card）登记
评估	按 ODD / 子群体（人种、天气、照明）分项报告性能
集成	异常输入检测（OOD）、置信度阈值、退出条件
运行时	模型漂移监测、影子模式评估、快速回滚机制

与 SOTIF 的关系：ISO/PAS 8800 补充了 SOTIF "如何在 AI 主导的子系统上做减风险"的操作层，避免 SOTIF 流程落在"写了一大堆场景但与训练数据无关联"的尴尬处境。

汽车网络安全（Cybersecurity）

现代自动驾驶车辆是"四轮移动计算机"，拥有大量无线接口，面临严峻网络攻击风险。ISO/SAE 21434 要求：

TARA（威胁分析与风险评估） — 识别主要攻击面：

接口	攻击向量	潜在影响
V2X/C-V2X	虚假交通信息注入	错误驾驶决策
OTA 更新	恶意固件	控制权劫持
蓝牙/Wi-Fi	近场攻击	数据窃取
OBD-II 端口	CAN 总线注入	刹车/转向控制
摄像头输入	对抗样本贴纸	感知失效

纵深防御策略： - 加密通信（TLS 1.3，证书管理） - 固件签名验证（防恶意 OTA） - 车内入侵检测系统（IDS） - 安全启动（Secure Boot）

UN R155 / R156 强制合规（2024 年起）：

UN R155 要求所有 OEM 建立 CSMS（Cybersecurity Management System），覆盖从研发到报废的全生命周期；
UN R156 要求建立 SUMS（Software Update Management System），每次 OTA 必须有可追溯的授权链；
未通过 CSMS/SUMS 的车型将不得在欧洲、日本、韩国销售，这是网络安全第一次获得事实上的"全球准入权"。

运营安全：Safety of Design vs Safety of Operation

"把车开发出来是安全的"与"每天运营这些车依然是安全的"是两件事。Robotaxi 行业把后者抽象为 Safety of Operation：

维度	Safety of Design	Safety of Operation
范畴	软件 + 硬件 + 数据	车队管理 + 远程协助 + 现场处置
典型输入	Hazard Library、ODD 定义、AI 评估	事件日志、乘客反馈、天气/路况预警
典型输出	软件版本 + Safety Case	运营 SOP + 应急 runbook
核心工具	仿真、形式化验证	远程运营中心（ROC）、远程协助系统（RAS）
相关标准	ISO 26262 / 21448 / 8800	SAE J3237（post-crash）、UL 4600 运营篇

关键接口：

运营中发现的异常（例如 Muni 新增公交车道、建筑区 Geofence）必须回流到 Hazard Library；
ROC/RAS 人员指令也必须被安全审计——他们在系统中拥有"超级用户"权限，滥用或误操作本身就是危害源（§2.8 Cruise 事件）；
关键 KPI：MPKD（Miles Per Kilometre Disengagement）、RAS 响应时间、Post-Crash Behavior 合规率。

安全测试与验证

里程验证挑战

RAND Corporation 研究指出：要以 95% 置信度证明自动驾驶故障率优于人类驾驶员，需行驶约 275 亿英里——在物理上不可行（以 100 辆车每天行驶 500 英里计算，需要约 1500 年）。

多维度验证策略

方法	说明	优势
仿真验证	虚拟环境中并行执行等效测试（Waymo 每年仿真 > 100 亿英里）	规模化、可重复、安全
场景化测试	系统化场景库，覆盖正常/边角/对抗场景	针对性强
形式化验证	数学证明关键算法的安全属性（如 RSS 模型）	严格保证
影子模式	系统在实车上"看"人类驾驶，记录若自主决策会如何	低风险大规模数据收集
实车路测	在真实道路验证，记录脱离（Disengagement）事件	最接近实际，必不可少

场景覆盖度 vs 里程覆盖度

"里程数"是最原始的覆盖度指标，但它无法区分"在同一条高速来回跑一千万英里"和"在一千个不同路口各跑一次"。现代安全验证因此更看重场景覆盖度：

ODD 分层覆盖：按（道路类型 × 天气 × 时段 × 车速 × 交通密度）笛卡尔积划分单元，记录每个单元下的测试里程；
交互覆盖：以 (自车动作, 他车动作) 对的分布衡量，例如无保护左转与行人的交互组合；
Hazard 覆盖：Hazard Library 中每条危害是否至少有一次阳性触发 + 一次阴性验证；
Residual Risk：未覆盖单元的概率密度 × 潜在后果 → 决定是否可接受。

实战样例：制动失效的 Safety Case 骨架

Hazard H1: 自动驾驶系统下发非预期制动（Spurious Braking）
├── Safety Goal SG1: 非预期制动率 < 1e-8 /h，ASIL-D
│    ├── FSR1: 制动指令需经过双通道一致性校验
│    │    ├── TSR1.1: 主 SoC 输出制动请求与安全岛 MCU 输出一致
│    │    ├── TSR1.2: 不一致时 30 ms 内进入 Safe State（维持当前减速度）
│    │    └── 验证：FMEDA + HIL 测试 + 10^7 km 仿真
│    └── FSR2: 感知输入需满足 SOTIF 场景覆盖
│         ├── 场景库 Scenario-Set-A（静态路面反光）覆盖 > 98%
│         ├── 场景库 Scenario-Set-B（夜间强光）覆盖 > 95%
│         └── AI 组件按 ISO/PAS 8800 评估：FP rate < 0.01%
├── Safety Goal SG2: 故障后保持可控性，ASIL-C
│    └── FSR3: 进入 Fail-Operational 状态，继续完成 MRM
└── Safety Case 输出 → 监管审批 + 公司内部 Safety Committee 签字

这种结构化的论证既便于工程团队协作，也便于外部审计与保险公司评估。

延伸阅读

§2.7 系统测试与验证 — 本节提到的各类测试方法具体怎么做；
§2.8 典型事故与经验教训 — 事故反向驱动 Hazard Library 的活教材；
§2.9 汽车网络安全 — ISO/SAE 21434 + UN R155/R156 的工程实践；
§2.10 法规与监管 — Safety Case 如何对接监管准入。

参考资料

ISO. ISO 26262: Road Vehicles — Functional Safety, 2nd ed., 2018.
ISO. ISO 21448: Road Vehicles — Safety of the Intended Functionality (SOTIF), 2019.
S. Shalev-Shwartz, S. Shammah, A. Shashua. On a Formal Model of Safe and Scalable Self-driving Cars. arXiv:1708.06374, 2017.
RAND Corporation. Autonomous Vehicle Technology: A Guide for Policymakers, 2020.
A. Bhat, S. Aoki, R. Rajkumar. Tools and Methodologies for Autonomous Driving Systems. Proceedings of the IEEE, 2018.