Safety Case — 安全案例 / 安全论证
本质与导读
本质 Safety Case 不是最后补的文档,而是一组结构化论证:从 Safety Goal 经需求到 evidence,证明系统在指定场景下 acceptable safe。ISO 26262 强制每个 ASIL 项目交付,所以必须从概念阶段边开发边累积——临阵抱佛脚必然证据不全、论证矛盾。
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 Steerin…
"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 un…
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。
从 0 写一棵完整 GSN tree…
从 0 写一棵完整 GSN tree → Safety Case GSN tree 写作工程化深度 — 7 步 SOP + 5 defeater 修法 + Confidence Argument 5 节点模板
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…
"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 Inve…
"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 sh…
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 residu…
"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。
9. Argument Patterns — 4 个可复用论证
实战中 80% 的中层论证(SG → sub-claims)可以拼装 4 个 reusable pattern,不需要每个 SG 从头写。下面 4 个是 ISO 26262 / IEC 61508 / DO-178C 共同推荐的复用片段。
| Pattern | 拆解维度 | 何时用 |
|---|---|---|
| ① Decomposition by Failure Category | 随机 / 系统 / 共因 3 类 | ASIL B+ 主干论证(ISO 26262-9 Clause 9 强制) |
| ② Sufficient Testing | 覆盖率 + pass 率 + 方法充分性 | V&V 阶段证 SR(SW SR / HW SR) |
| ③ Independence(DFA) | HW / SW / Data / Spec 4 维 | ASIL D Lockstep / 2oo3 voting / Fail-Op |
| ④ Process Compliance | 26262 + ASPICE + Tool Qualification | Systematic 失效论证(无法定量必用) |
实战要点:这 4 个 pattern 可以嵌套使用——比如 ① 拆出"随机故障"子论证后,可以用 ② 在叶子层证明"FI 测试覆盖率足够"。剩余 20% 是 item-specific 论证(例:HV 系统特有的 Pyro Fuse 论证、电池热失控的 5 层防护论证),需 case-by-case 写。
10. Modular Safety Case + Contracts
整车 Safety Case 不是把所有 Tier-1 SC 拼成一份巨型文档,而是 OEM 主 SC 通过 contract 引用 Tier-1 子 SC。这是 ISO 26262 Annex A 推荐的 modular 模式,与 DIA(Development Interface Agreement)直接挂钩。
Contract 内容:接口承诺(扭矩 SG / 转向 SG / HV SG)、接口 ASIL、性能边界(响应时间 / FTTI)、假设(供电 / 温度 / 信号完整性)、验证方法(谁验)、change notification 流程。
3 层关系:
- OEM 整车 SC:vehicle-level SG / FSC / Validation,引用 N 个 Tier-1 模块
- Contract:DIA 的接口章节,Tier-1 对外承诺,OEM 对内整合
- Tier-1 Sub-SC:Tier-1 内部完整 GSN,接口契合 contract;内部细节不出现在 OEM SC
实战痛点:Contract 写得模糊 → OEM SC 整合时发现接口不匹配 → 临 SoP 才要 Tier-1 改 SC。修法:DIA 最早阶段就把 contract 写死,SC 直接引用 DIA 章节。
11. Confidence Argument — Meta 论证
ACWG(Assurance Case Working Group)推荐:任何 Safety Case 都需配 Confidence Argument 一份。安全论证回答"系统安全",Confidence Argument 回答"安全论证本身可信"——两棵树并行,缺一面对审计员追问就漏。
Confidence Argument 必含 3 类元证据:
- 假设成立性——SC 中 Assumption(§5.2 第 6 章列出的)实际成立的证据。例:"假设供应商 IP 已 SEooC certified" → 提供 supplier safety manual + certificate ID。
- 数据可信度——SC 引用的失效率 / 测试数据 / FMEDA 结果来源可审计。例:FMEDA 用的失效率数据来自 SN29500 v2.1,版本固定且审计可查。
- 方法熟练度——执行人资质 + 培训记录。例:HARA 主审 5 年经验 + TÜV 培训证书 + 至少 3 个完整 ASIL D 项目经验。
审计员常用追问链:"你的 SC 论证 SG 满足"(主)→ "那你假设传感器 FIT 是 10,这个数据哪来的?"(Confidence)→ 没有 Confidence Argument 兜底就会答得 ad-hoc,被记 NC。
12. 完整 GSN 追溯实例
下图把 §6.2 的主驱 SG-1 例子展开成完整 GSN 树——审计员从 Top Goal 沿树自顶向下追,直到 leaf evidence 报告 ID。
树的关键节点:
- G1(Top Goal):主驱 SG-1 满足,unintended torque < ±20 Nm,ASIL D
- C1(Context):IDD-TI-2026-A v1.0,定义范围 / 工况
- S1(Strategy):ISO 26262-9 3 故障类拆解
- G2 / G3 / G4(Sub-goals):随机 / 系统 / 共因 各一支
- A1(Assumption,挂 G2):失效率数据来自 SN29500 / FIDES,可审计
- S2 / S3 / S4(Sub-strategies):定量 FMEDA / 流程合规 / 独立性验证
- Sn1-Sn6(Solutions / Evidence):每个 evidence 都有具体文档 ID + 版本 + 关键数值
实战要点:这种完整 GSN 树是 SC 第 4 章的核心。每个 SG 都画一棵——ASIL D 项目典型 4-8 个 SG,所以 SC 有 4-8 棵 GSN 树 + 一棵 confidence argument 树。
工程化展开 → Safety Cas…
工程化展开 → Safety Case GSN tree 写作工程化深度 — 7 步 SOP / 5 层 30 节点 worked / 5 defeater before-after / Confidence Argument 5 节点 / review checklist 9 问 / GSN ↔ ISO 26262 双向追溯
13. SC Review 流程 + Defeaters
Safety Case 写完不算完,还要走 review——发现 defeaters(反驳论证)是 review 的核心动作。Defeater 不一定是 bug,可能是论证缺口、假设隐藏、证据弱。
5 类 defeater 模式(review 时按这个 checklist 扫):
| Defeater 类 | 含义 | 例子 |
|---|---|---|
| 论证缺口 | Goal 到 Solution 之间缺 Strategy | SG 直接挂 FMEDA,没说为什么数字 = SG 满足 |
| 假设过强 | Assumption 实际不成立 | 假设供电 > 9V,但故障下可能掉到 7V |
| 证据弱 | Solution 不够 prove Goal | "FMEDA done" 但版本是初稿 v0.3,没第三方 verify |
| 反例存在 | 有 case 违反 Goal | DV 测试某场景 fail 但 SC 没提 |
| 范围窜变 | Context 之外的工况被悄悄包入 | IDD 不覆盖某场景,但 SC 论证扩到该场景 |
review 节奏:
- Self-review(Safety Engineer):每写一段就自查 5 类 defeater
- Peer review(Safety Mgr + 同级 Safety Engineer):M3 / M6 / M9 / M12 里程碑各一次
- Independent review(I3 Reviewer,ASIL D 必有):Final pre-Assessment 一次,2-4 周深度
- External Assessment(TÜV / exida):SoP-12 周开始,12-16 周收官
每发现一个 defeater:记录 → 决定修法(改 Plan / 改设计 / 补 evidence / 接受残余风险)→ 回写 SC 影响章节。
核心要点
- 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 反模式戒除:临阵抱佛脚 / 论证缺口 / 证据不全 / 假设隐藏 / 不更新
- 4 个可复用 Argument Pattern:Decomp by Failure Cat / Sufficient Testing / Independence(DFA)/ Process Compliance,80% 中层论证靠拼装
- Modular SC + Contracts:OEM 主 SC 引用 Tier-1 子 SC,DIA contract 衔接,Tier-1 内部细节不出现在 OEM SC
- Confidence Argument:与 Safety Argument 并行的 meta 论证,证 SC 本身可信(假设 / 数据 / 方法 3 类元证据),ACWG 推荐
- 完整 GSN 追溯:每 SG 一棵树(G→S→sub-G→S→Sn),配 C+A 标注,审计员自顶向下追
- Review 5 类 defeaters:论证缺口 / 假设过强 / 证据弱 / 反例 / 范围窜变;Self → Peer → I3 → TÜV 4 级
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 更新
- EV ECU FMEDA 总集成深度 — 主驱 ASIL D 完整 GSN tree worked + 8 段对标
- Safety Case GSN tree 写作工程化深度 — 本页 § 4 + § 12 的工程化展开,7 步 SOP + 5 defeater 修法 + Confidence Argument