📚 课程目录第3章安全案例与论证工程概述

3. 安全案例与论证工程概述

在自动驾驶系统中，安全不能仅靠“测试通过”或“没有事故”来证明。由于运行环境开放、场景组合近乎无限，行业必须转向一种可审查、可追溯、可维护的论证方式——安全案例（Safety Case）与论证工程（Argumentation Engineering）。本节将厘清安全案例的定义、论证工程的目标，以及它与系统安全生命周期之间的结构关系。

3.1 安全案例的定义

安全案例是一份结构化、有证据支撑的论证文档，用于说明某个系统在其规定的运行设计域（ODD）内，已经达到可接受的安全水平。它不是简单的测试报告，也不是合规检查清单，而是一个“主张—论证—证据”的完整链条。

一个典型的安全案例至少包含四个要素：

安全主张（Claim）：需要被证明的顶层结论，例如“自动驾驶系统在高速公路场景下满足可接受安全水平”。
论证结构（Argument）：将顶层主张分解为若干子主张，并说明它们如何共同支撑结论。
证据（Evidence）：测试数据、仿真结果、形式化验证、现场运行记录、失效分析报告等。
假设与上下文（Context & Assumption）：ODD 边界、法规依据、传感器配置、外部交通参与者行为假设等。

安全案例的核心逻辑是：主张必须由论证支撑，论证必须由证据落地，证据必须可追溯、可复核。

3.2 论证工程的目标

论证工程是把安全案例从“一次性文档”变成“可工程化管理的活动”的方法体系。它的目标不是写出一份漂亮的报告，而是让安全论证在整个研发与运营过程中持续有效。

具体目标可以归纳为以下五个方面：

可追溯性：从安全目标到需求、设计、测试、运行数据，形成双向追溯链。
可分解性：把顶层安全主张分解为可验证、可分配的子系统与组件级主张。
可验证性：每一条证据都能对应到明确的验证方法，如仿真、封闭场地测试、实车路测、形式化分析。
可维护性：当 ODD 扩展、软件版本更新或法规变化时，能够快速定位受影响的论证分支并更新。
可沟通性：让安全工程师、系统工程师、测试团队、认证机构和监管方对同一套论证结构达成共识。

在自动驾驶领域，论证工程尤其强调“场景—危害—安全目标—需求—证据”的闭环。例如，当系统新增“自动变道”功能时，论证工程需要回答：新增了哪些危害？对应哪些安全目标？这些目标如何分解到感知、规划、控制模块？每个模块需要提供什么证据？

3.3 与系统安全生命周期的关系

安全案例不是生命周期末尾才编写的“总结材料”，而是贯穿系统安全生命周期的“活文档”。它与 ISO 26262、ISO 21448（SOTIF）以及 UL 4600 等标准所描述的安全活动紧密耦合。

下图展示了安全案例、论证工程与系统安全生命周期之间的结构关系：

从图中可以看出，安全案例位于“论证结果”一侧，论证工程位于“论证活动”一侧，二者共同贯穿系统安全生命周期的各个阶段。生命周期提供时间维度和活动输入，论证工程提供方法和管理机制，安全案例则沉淀为可审查的结论性文档。

3.4 核心方法流程

在实际项目中，安全案例与论证工程通常按以下流程推进：

1. 定义 ODD 与运行场景
2. 开展危害分析与风险评估（HARA）
3. 确定安全目标与安全需求
4. 构建顶层安全主张
5. 分解子主张并分配至系统/子系统/组件
6. 规划验证与确认活动
7. 采集证据并建立追溯关系
8. 评审论证完整性
9. 发布安全案例并纳入变更管理
10. 运行阶段持续监控与更新

这个流程不是线性的，而是迭代的。当 ODD 扩展、传感器升级或算法迭代时，论证工程需要重新评估受影响的主张和证据，必要时更新安全案例。

3.5 案例场景：自动紧急制动（AEB）的安全论证

以 AEB 功能为例，安全案例的顶层主张可以是：“AEB 在 M 类车辆城市工况下，能够将追尾事故风险降低到可接受水平。”论证工程将其分解为：

感知主张：毫米波雷达与摄像头融合能够在 80 ms 内识别前方静止车辆。
决策主张：触发逻辑在 TTC 小于 1.2 s 时发出制动请求。
执行主张：制动系统能够在 150 ms 内建立 0.6 g 减速度。
运行主张：误触发率低于每 10 万公里 1 次。

对应的证据包括：仿真场景库测试报告、封闭场地目标车测试数据、实车路测里程与误触发统计、FMEA 分析报告等。论证工程确保每一条证据都能追溯到具体主张，并在版本变更时快速评估影响范围。

3.6 常见误区与复盘

误区一：把安全案例当成“一次性交付文档”。安全案例必须随系统版本、ODD 和法规变化持续更新，否则会迅速失效。

误区二：只堆证据，不建论证结构。证据再多，如果没有清晰的主张分解和追溯关系，审查方无法判断证据是否充分。

误区三：论证工程只由安全团队负责。论证工程需要系统、软件、测试、运营多方协同，否则主张分解与证据采集会脱节。

复盘时建议重点检查三个问题：第一，顶层主张是否覆盖了所有已识别危害？第二，每条子主张是否有明确的证据责任人和验证方法？第三，当需求或设计变更时，论证结构是否能够快速定位受影响分支？

3.7 关键要素清单

要素	说明	典型输出
安全主张	需要证明的顶层与子级结论	主张树、GSN 图
论证结构	主张之间的支撑与分解关系	论证模式、推理链
证据	支撑主张的测试、分析、运行数据	测试报告、仿真结果、FMEA
上下文与假设	ODD、法规、外部行为假设	ODD 定义、假设清单
追溯关系	主张—需求—证据的双向链接	追溯矩阵、需求管理工具记录
变更管理	版本变更对论证的影响分析	影响分析报告、更新记录

理解安全案例、论证工程与系统安全生命周期的关系，是后续开展危害分析、安全需求分解和证据规划的基础。只有把论证当作工程活动来管理，安全案例才能真正成为自动驾驶系统安全可信的支撑材料。