1. 课程导入

自动驾驶从技术演示走向大规模量产,真正的门槛并不在于“能不能跑起来”,而在于“能不能安全地、可证明地、可持续地跑在几十万辆车上”。安全量产验证工程,正是连接算法研发与整车交付之间的那座桥。它要回答三个问题:系统在什么条件下是安全的?我们凭什么相信它是安全的?这种相信如何被工程化地复现、审计与追溯?

一、学习目标:从“会做功能”到“能证明安全”

本课程面向自动驾驶系统工程师、测试验证工程师、功能安全与预期功能安全(SOTIF)从业者、质量与合规人员。完成学习后,你应当具备以下能力:

  • 理解安全量产验证的整体框架,能说清 V 模型、安全生命周期与量产放行之间的关系;
  • 掌握危害分析、安全目标分解、安全需求逐级落地的核心方法;
  • 能够设计覆盖场景、里程、边界与故障注入的验证方案;
  • 理解仿真、封闭场地、公开道路、影子模式等验证手段的定位与组合逻辑;
  • 能够读懂并构建安全论证(Safety Case)与证据链,支撑量产放行评审。
核心判断:安全不是一次测试的结论,而是一条从危害识别到证据闭环的工程链路。任何一环缺失,量产放行都只是概率赌博。

二、核心概念:五个必须分清的关键词

初学者最容易把“功能安全”“预期功能安全”“信息安全”“测试通过”“量产放行”混为一谈。它们各自回答不同问题,也对应不同的标准与方法。

概念回答的问题典型标准/方法常见误区
功能安全(FuSa)系统故障时是否安全ISO 26262、ASIL 分解把随机硬件失效当成唯一风险
预期功能安全(SOTIF)无故障但性能不足时是否安全ISO 21448、场景覆盖认为“没报错就等于安全”
信息安全(Cybersecurity)被攻击时是否安全ISO/SAE 21434与功能安全割裂处理
验证与确认(V&V)做对了没有、做的是不是对的东西仿真+场地+道路+影子用单一手段替代组合证据
安全论证(Safety Case)凭什么相信整体是安全的GSN、证据链只堆报告,不建论证结构

其中,SOTIF 是自动驾驶区别于传统汽车电子的关键增量。传统功能安全假设“需求本身正确”,而 SOTIF 恰恰要处理“需求没覆盖到的长尾场景”。例如,白色货车横穿、隧道出口强逆光、施工区锥桶临时改道,这些都不是故障,却足以让系统失效。

三、整体框架:从危害到放行的验证链路

安全量产验证工程可以抽象为一条“危害驱动、证据闭环”的主链路:先识别危害,再定义安全目标,然后逐级分解为系统、软件、硬件与场景需求,最后通过多手段验证收集证据,形成安全论证,支撑量产放行。下图展示了这一主链路及其关键输入输出。

安全量产验证工程主链路:危害驱动 · 证据闭环 危害识别 HARA / 场景风险 安全目标 ASIL / 安全状态 需求分解 系统/软件/硬件/场景 验证执行 仿真/场地/道路 多手段验证证据池 仿真验证 百万级场景回放 封闭场地 边界/故障注入 公开道路 真实里程与接管 影子模式 / 数据回灌 量产车队持续验证 安全论证 Safety Case 目标 → 策略 → 证据 → 结论 GSN 结构 · 可追溯 · 可审计 残余风险显式声明 量产放行评审 安全目标达成度 · 证据完整性 遗留风险接受 · 版本冻结 OTA 持续监控与回滚 持续迭代

这条链路有两个重要特征。第一,它是双向的:验证中发现的新危害会反向更新危害分析与安全目标,形成迭代闭环。第二,它是证据驱动的:每一个安全目标都必须能追溯到具体证据,而不是停留在“我们测了很多”。

四、方法流程:一次典型的安全验证迭代

下面给出一个可落地的流程骨架,适用于 L2+ 到 L4 的量产项目。不同项目可裁剪,但顺序与依赖关系不宜颠倒。

1. 定义 ODD(运行设计域)
   - 道路类型、天气、光照、车速、地理围栏
2. 危害分析与风险评估(HARA)
   - 识别危害事件 → 评估 S/E/C → 确定 ASIL
3. 制定安全目标与安全状态
   - 如:高速场景下避免非预期转向
4. 需求分解与分配
   - 系统需求 → 软件需求 → 硬件需求 → 场景需求
5. 验证方案设计
   - 仿真场景集、场地测试用例、道路里程、故障注入
6. 执行与数据采集
   - 记录触发条件、接管、误报、漏报、边界表现
7. 证据整理与安全论证
   - 建立 GSN,关联测试报告与覆盖率数据
8. 放行评审与持续监控
   - 版本冻结、OTA 监控、问题回灌

五、案例场景:一次“逆光误刹”如何走完链路

某量产项目在隧道出口遭遇强逆光,前车阴影被误识别为障碍物,触发非预期制动。按传统测试思路,这只是一条 bug。但在安全量产验证工程中,它会被放大为一条完整链路:

  • 危害识别:非预期制动可能导致后车追尾,严重度 S3、暴露度 E3、可控性 C2,评定为 ASIL B;
  • 安全目标:在逆光条件下,系统不得对非真实障碍物触发制动;
  • 需求分解:感知模块需在 HDR 场景下保持误检率低于阈值,融合模块需引入时序一致性校验;
  • 验证执行:仿真注入逆光场景 5000 例,场地复现 30 例,道路采集 200 段真实逆光数据回灌;
  • 证据闭环:误检率从 0.8% 降至 0.02%,残余风险在安全论证中显式声明并接受。
这个案例说明:安全验证不是“找到问题就结束”,而是要把问题转化为需求、验证与证据,最终进入安全论证。否则同类问题会在不同场景反复出现。

六、常见误区与复盘

在导入阶段,先建立正确的“反模式”意识,比记住标准条款更重要。

  1. 误区一:把里程当安全。百万公里无事故不等于安全,因为长尾场景可能从未被触发。里程是证据之一,不是充分条件。
  2. 误区二:仿真与实车割裂。仿真场景若未与真实数据校准,覆盖率再高也只是自娱自乐。
  3. 误区三:只做功能安全,忽略 SOTIF。大量自动驾驶事故源于性能不足而非硬件故障。
  4. 误区四:安全论证变成报告堆砌。没有 GSN 结构的证据,无法回答“为什么这些证据足以支撑结论”。
  5. 误区五:放行即终点。量产放行只是持续安全监控的起点,OTA 与影子模式才是长期保障。
复盘要点:安全量产验证工程的核心不是“测得多”,而是“证得清”。每一个安全结论都必须能回答三个问题——依据什么目标、用了什么证据、残余风险是什么。