Safety Case — 安全案例 / 安全论证
本质 Safety Case 不是一份文档,是一组结构化论证——证明"系统在指定运行场景下达到 acceptable safe"。ISO 26262 强制要求每个 ASIL 项目最终交付 Safety Case,但很多团队把它当成最后才补的形式文档——结果安全审计前夜熬夜拼凑,内容矛盾、证据不全。正确做法是 Safety Case 从概念阶段就开始建,边开发边累积:HARA 输出 Safety Goal 时就开始写 Safety Argument 大纲,FSC/TSR 完成时论证 mid-level 需求覆盖,V&V 结束时填实测证据。本页拆 Safety Case 的3 层论证结构(SG → 需求 → 实施 + 证据) + GSN 标记法 + 标准模板 + 主驱实例 + 5 反模式。
学习目标
读完本页后,你应该能够:
- 说出 Safety Case 的定义:不是文档,是 argument + evidence 的结构化集合
- 区分 Safety Case 与普通安全文档(FMEDA、Test Report 等)的关系——Safety Case 引用它们作 evidence
- 走通 Safety Case 3 层论证结构:Top-level claim → middle-level argument → leaf-level evidence
- 看懂 **GSN(Goal Structuring Notation)**基本符号(Goal / Strategy / Solution / Context / Assumption)
- 写出 Safety Case 标准章节模板(覆盖范围 / SG 论证 / 实施论证 / V&V 证据 / 残余风险)
- 在主驱 / EPS 实例上追溯一个 Safety Goal 到具体 evidence
- 识别 5 个 Safety Case 反模式(临阵抱佛脚 / 论证缺口 / 证据不全 / 假设隐藏 / 不更新)
1. 为什么需要 Safety Case
ISO 26262 认为"做了 ASIL 流程"不等于"系统是安全的"——必须论证。Safety Case 就是这个论证的载体,把分散的 FMEDA / DFA / FTA / Test Report / Code Review 串成一条从 Safety Goal 到 evidence 的可追溯链。
没有 Safety Case 时:审计员要看 ASIL D EPS 项目的安全状况,要翻 FMEDA(数十张表)+ DFA report + V&V test reports + design docs ≈ 几百页文档,没有"哪段证据 prove 哪条需求"的导航。
有 Safety Case 时:审计员从 Top claim 沿 argument 向下,每个 mid-level claim 都明确指向哪份 evidence。几分钟即可定位质疑的论证段。
2. Safety Case 与其他文档的关系
Safety Case 不是孤立文档,是论证骨架——其他文档(FMEDA / DFA / Test Report / Code Review)是 evidence,Safety Case 通过引用把它们组织成一条逻辑链。
| 文档 | 角色 |
|---|---|
| Safety Case | 论证骨架(本页主题) |
| HARA Report | 论证起点(SG 来自这) |
| FMEDA Report | 论证 SPFM/LFM/PMHF 达标 |
| DFA Report | 论证独立性假设成立 |
| FTA Report | 论证 hazard 路径已 cover |
| V&V Test Reports | 论证设计 / 软件正确实施 |
| Code / Design Review | 论证 systematic 错误已避免 |
3. 3 层论证结构
Safety Case 按"top-down 拆解"组织——从 system-level safety claim 拆到具体 evidence。
| 层 | 内容 | 例 |
|---|---|---|
| Top Claim | 系统级安全主张 | "EPS system is safe for ASIL D operation per HARA scope" |
| Middle | 每个 SG 的论证 | "SG-1 (no unintended steering) is met because..." |
| Leaf | 具体 evidence | "FMEDA SPFM = 99.2%, DFA passed, code review 100% coverage" |
3.1 Top Claim
Top Claim 必须明确 4 件事——很多 Safety Case 失败在 Top Claim 太笼统或太具体。
| 元素 | 说明 |
|---|---|
| What is safe | 哪个 item / 系统(EPS / 主驱 / BMS) |
| For what scope | 在什么操作 scope 下(driving conditions) |
| To what level | 多大程度 safe(ASIL 等级、可接受风险水平) |
| Per what authority | 按什么标准(ISO 26262 / 哪个 OEM 规范) |
例:
"The Power Steering System (item ID: EPS-2026-A) is acceptably safe for use in passenger vehicles operating on public roads, in accordance with ISO 26262-3 ASIL D requirements, within the operational scope defined in the Item Definition document(IDD-EPS-2026-A-v1.2)."
3.2 Middle Layer Argument
每个 SG 对应一个 middle-level argument —— 解释"这个 SG 为什么被满足"。
例(EPS SG-1):
Claim: SG-1 (No unintended steering torque > 0.5 Nm) is met.
Strategy: Decomposed argument by failure category:
- Random hardware failures → addressed by FMEDA + SM catalog
- Systematic failures → addressed by ISO 26262 process compliance
- Common cause failures → addressed by DFA on dual-MCU architecture
Evidence:
- FMEDA report (SPFM = 99.2% > 99% threshold)
- DFA report (independence verified across HW/SW/Data/Spec)
- V&V report (FTTI < 100 ms verified by HIL fault injection, 1247 test cases passed)
3.3 Leaf Evidence
Evidence 必须是可审计的——document ID、version、date、author 都要明确。
例:
| Evidence | Document | Version | Date | Confidence |
|---|---|---|---|---|
| SPFM = 99.2% | FMEDA-EPS-2026-A.xlsx | 2.3 | 2026-09-15 | High(third-party verified) |
| FTTI < 100 ms | HIL-Test-Report-EPS-FI.pdf | 1.4 | 2026-10-02 | High(1247 fault injections) |
| Independence verified | DFA-EPS-2026-A.docx | 2.1 | 2026-09-20 | Medium(规范独立性 partial) |
4. GSN — Goal Structuring Notation
GSN 是 safety case 论证的标准图形化表示法——Tim Kelly(University of York)发明,被 Adelard ASCAD methodology 和 ISO 26262-2 Annex A 推荐使用。
4.1 GSN 5 个核心符号
GSN 5 个符号各对应论证一个角色——Goal 是要证的、Strategy 是怎么拆、Solution 是直接证据、Context / Assumption 是支撑论证的前提条件。
| 符号 | 含义 | 形状 |
|---|---|---|
| Goal(G) | 待论证的 claim | 矩形 |
| Strategy(S) | 拆解 Goal 的方法 | 平行四边形 |
| Solution / Evidence(Sn) | 直接 evidence | 圆形 |
| Context(C) | 解释 Goal 的背景 | 平角矩形 |
| Assumption(A) | 论证依赖的假设 | 椭圆 |
4.2 GSN vs 文字描述
GSN 图形化让审计员 5 秒看懂论证拓扑——文字描述要读 5 段才能搞清结构。实务里:核心论证用 GSN(顶 + 主要分支),细节填文字 + 引用 evidence。
5. 标准章节模板
Safety Case 章节结构有事实标准——下面这个 7 章模板覆盖 ISO 26262 / IEC 61508 / DO-178C 的共同要求。
| 章 | 内容 | 长度 |
|---|---|---|
| 1. Introduction | 范围、对象、版本、范围 boundary | 2-5 页 |
| 2. Item Definition Reference | 引用 IDD 文档 | 1-2 页 |
| 3. Safety Goals & ASIL | HARA 输出的 SG 列表 + ASIL | 5-15 页 |
| 4. Safety Argumentation | GSN 主图 + 每个 SG 的子论证 | 30-100 页 |
| 5. Evidence Index | 所有 evidence 文档的引用 + version | 5-10 页 |
| 6. Assumptions & Limitations | 显式列出 SC 依赖的所有假设 | 5-10 页 |
| 7. Residual Risk | 已知未解决的风险 + 风险接受论证 | 5-10 页 |
5.1 章节顺序的重要性
按这个顺序读 Safety Case 能从抽象到具体逐层下钻——审计员先看 1-3 章 setup,再看 4 章主论证(深读),5-7 章作 reference 时翻。章节顺序错 会让审计员迷路。
5.2 Assumptions & Limitations 的关键性
第 6 章最容易被忽视但最重要——Safety Case 的所有论证都建立在 assumption 上,assumption 一旦不成立 SC 整体失效。显式列出让 OEM / 审计员知道在什么前提下 SC 有效。
例:
"This Safety Case assumes:
- Vehicle is operated within speed range -50 km/h to +200 km/h
- Operating temperature in cabin between -40 °C and +85 °C
- 12 V battery system with backup BMS providing > 9 V during faults
- Driver is licensed and physically capable of taking over control within 1 second"
6. 主驱实例(节选)
6.1 Top Claim
"The Traction Inverter (item ID: TI-2026-A) for 800 V battery EV powertrain is acceptably safe per ISO 26262-3 ASIL D, within the operational scope defined in IDD-TI-2026-A-v1.0."
6.2 Mid-level argument 例(SG-1: No unintended torque)
Claim: Inverter shall not produce unintended torque > ±20 Nm at the wheels.
Strategy: Decompose argument by 3 failure categories(per ISO 26262-9 Clause 9):
- Random HW failures → FMEDA-based quantitative argument
- Systematic HW/SW failures → process compliance argument(V model + DV/PV)
- Common cause failures → DFA-based independence argument
Sub-claim 1.1 (Random HW): SPFM ≥ 99%, LFM ≥ 90%, PMHF ≤ 10 FIT
- Evidence: FMEDA-TI-2026-A.xlsx v3.1 — actual SPFM = 99.4%, LFM = 92.1%, PMHF = 7.3 FIT
Sub-claim 1.2 (Systematic): ISO 26262 V model fully followed, all DV/PV passed
- Evidence: V-Model-Compliance-TI-2026-A.docx, DV-Test-Report.pdf, PV-Test-Report.pdf
Sub-claim 1.3 (CCF): Lockstep MCU + independent ASC controller architecturally independent
- Evidence: DFA-TI-2026-A.docx — verified independence across HW/SW/Data/Spec(规范独立 partial,risk accepted)
6.3 Residual Risk 例
"Identified residual risks:
- 规范独立 partial: 主控算法与监控算法均由本公司 software team 实施,虽两个独立 sub-team,但同一份 OEM 需求规范。Risk: low (跨 team review + OEM 规范 v3.2 已 freeze).
- 超出温度区间: SC 范围内 -40~+85°C,实际边缘 corner cases 在 +90°C 时 PMHF 升至 11 FIT(超 10 FIT 阈值)。Risk: low (vehicle thermal management 保证 cabin -40~+85°C is met).
- OEM TSR v3.2 vs SC v2.1 mismatch in section 4.7: Tracking issue #234, fix planned for SC v2.2 by 2026-12-15."
7. Safety Case 的生命周期
Safety Case 不是一次性产出,是 living document——伴随项目生命周期持续更新。任何设计变更 / 测试发现 / 残余风险评估都要回 Safety Case 更新。
| 阶段 | SC 状态 |
|---|---|
| Concept | 骨架 + Top Claim + 主要 SG |
| Design + V&V | 填具体 evidence |
| Pre-SOP | 完整 + 通过审计 |
| Operation | 现场 issue / 召回 / OTA 更新触发 SC update |
8. 5 个 Safety Case 反模式
Safety Case 失效集中在 5 个反模式——这 5 个是审计员最常 reject 的原因。
| 反模式 | 表现 | 修法 |
|---|---|---|
| 临阵抱佛脚 | 概念阶段不写,SOP 前 1 个月集中拼凑 | 概念阶段就开始,边做边累积 |
| 论证有缺口(argument gap) | 从 SG 直接跳到 evidence,缺 mid-level argument | 用 GSN 强制画完整树 |
| 证据不全(missing evidence) | 引用文档但 doc 不存在 / 版本错 / 没归档 | Evidence Index 章 + 版本控制 |
| 假设隐藏(hidden assumptions) | 论证默认依赖某假设但没写出来 | 第 6 章 Assumptions 全文列出 |
| 不更新(stale SC) | 设计变更后 SC 没改,SOP 时与实际不一致 | Living document,变更触发 SC review |
8.1 临阵抱佛脚的隐蔽危险
最常见也最致命的反模式:Safety Case 被当成"最后凑数"的形式文档。结果 SOP 前 1 个月发现 evidence 不全 / 论证缺口大 / assumption 不成立——项目延期 3-6 个月是常态。修法:Safety Case 从概念阶段就开骨架,HARA 一出 SG 就建对应的 mid-level claim,后续每个里程碑填 evidence。
8.2 论证缺口的隐蔽危险
最容易被审计员发现的问题:SG → evidence 之间缺 strategy / sub-claim。例:SG-1 直接附 FMEDA 数字,但没解释为什么 FMEDA 数字 = 99.2% 就 prove 了 SG-1(需要论证 SPFM 阈值就是 ASIL D 的判据)。修法:用 GSN 强制每个 Goal 都先有 Strategy 才接 Solution。
核心要点
- Safety Case 不是一份文档,是 argument + evidence 的结构化集合 —— ISO 26262 强制要求
- 与其他安全文档(FMEDA / DFA / FTA / Test Report)的关系:SC 是骨架,引用它们作 evidence
- 走 3 层论证结构:Top Claim → Middle Strategy + Sub-claims → Leaf Evidence
- GSN(Goal Structuring Notation):Goal / Strategy / Solution / Context / Assumption 5 个符号
- 7 章标准模板:Introduction / IDD ref / SG&ASIL / Argumentation / Evidence Index / Assumptions / Residual Risk
- 第 6 章 Assumptions & Limitations 最易被忽视但最重要 —— SC 整体建立在 assumption 上
- Safety Case 是 living document:概念阶段开骨架,设计 / V&V 填 evidence,变更触发更新
- 5 反模式戒除:临阵抱佛脚 / 论证缺口 / 证据不全 / 假设隐藏 / 不更新
Cross-references
- ← 索引
- 功能安全
- HARA 危害分析与风险评估 — Safety Case 的论证起点
- ASIL 分解(Decomposition) — 分解后两路各自需要 Safety Case 子分支
- DFA / FMEDA / FTA 三种核心分析方法 — 这三个的 report 是 SC evidence
- SEooC — SEooC Safety Manual 是芯片厂的"小 Safety Case"
- 安全机制目录
- ISO 26262 硬件要素三类分类
- 失效模式速查
- PEU 开发流程 — Safety Case 在 PEU 项目时间线上的位置
- Automotive SPICE — ASPICE SUP.10(Change Mgmt)触发 SC 更新