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:2018 Clause 5 分解 / Clause 7 DFA):
- 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:2018 Clause 5 分解 / Clause 7 DFA) |
| ② 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 影响章节。
14. Worked Design — EV 主驱关断路径安全案例骨架(400V/100kW)
Safety Case 不是一份综述,是"证明"链。本节以 EV 400V/100kW 牵引逆变器为样本,展示从 Item Definition 到 evidence 挂接的完整 SC 骨架。所有文档编号 / 数值均为说明性 worked example(自洽可复核),不是某具体量产项目的真实归档号。
14.1 Item Definition(IDD-TI-2026-A)
Safety Case 的起点是明确系统边界,否则"可接受安全性"无从定义。
14.2 HARA → Safety Goal → FTTI 映射
HARA 按 ISO 26262-3:2018 Clause 6 运行,三条代表性危险场景导出两个 Safety Goal。
| 危险 ID | 危险描述 | S × E × C | ASIL | Safety Goal | FTTI |
|---|---|---|---|---|---|
| H-01 | 扭矩失控(过大 / 意外加速) | S3 × E4 × C3 | D | SG-01:在 200 ms 内安全关断驱动(切换至 STO / 受控减速) | 200 ms |
| H-02 | 扭矩完全丢失(高速无扭矩) | S2 × E4 × C3 | C | SG-02:在 500 ms 内发出故障指示并切换至 LO 模式 | 500 ms |
| H-03 | SiC 短路 / 接地故障 | S3 × E4 × C3 | D | SG-01(共用:同一物理故障,两路 FTTI 取严者) | ≤ 3 μs(器件短路耐受) |
SG-01 FTTI 两段:H-01 高层 200 ms 由 VCU 协调完成;H-03 器件层短路耐受 ≤ 3 μs 由栅极驱动硬件 SM 完成。3 μs 是 650V-class SiC MOSFET 的典型短路耐受时间量级(2–4 μs,与器件面积 / 栅压相关,非某 datasheet 明列参数)——硬件 DESAT 必须在此窗口内拉低栅极。两段 FTTI 属不同物理层,不能相加——安全案例必须各自论证。
14.3 Top Claim(ISO 26262-2:2018 §6.4.8 安全案例)
Safety Case 的 Top Claim 通常须交代四要素:ASIL 等级、FTTI 上界、工作场景边界、已覆盖危险集合(此四要素框架属 GSN / Adelard 论证实践,ISO 26262 未逐字规定,但 §6.4.8.2 要求 SC 逐步汇聚安全生命周期产出的全部合规工作产品)。
TC-01(ASIL D):"EV 牵引逆变器项目 TI-2026-A 在 IDD-TI-2026-A 所定义的全部运行场景下,以 ASIL D 完整性等级达到可接受安全性;危险集合 {H-01, H-02, H-03} 已由 SG-01、SG-02 覆盖,残余风险在 ISO 26262-1 定义的可接受阈值内。"
四要素核验:① ASIL D — 已列;② FTTI — SG-01: 200 ms / H-03: ≤ 3 μs;③ 场景边界 — IDD-TI-2026-A;④ 危险集合 — {H-01, H-02, H-03} 闭合。
14.4 中层论证 — ASIL D 分解路径(ISO 26262-9:2018 Clause 5)
ASIL 分解在 ISO 26262-9:2018 Clause 5 定义,允许把 ASIL D 拆为两个充分独立的 ASIL B(D) 子路径(合法分解 schema 之一:D → B(D) + B(D));每路仅需满足 ASIL B 的 SPFM ≥ 90%、LFM ≥ 60%(硬件度量目标见 ISO 26262-5:2018 Clause 8)。本项目采用双路分解:
| 子路径 | 主 MCU 资源 | 主要 SM | ASIL 分配 | 独立性基础 |
|---|---|---|---|---|
| Path-A | TC397 CPU0/CPU1 Lockstep + TLF35584 路径 1 | DESAT + Q&A WD + UVLO | ASIL B(D) | 独立供电轨 + 独立信号路径 |
| Path-B | TC397 CPU2 + 独立过流硬件比较器 | HW OCP + 独立 CAN 输出 | ASIL B(D) | 与 Path-A 无共享 SM 逻辑 |
各路需满足 ASIL B 硬件度量目标(ISO 26262-5:2018 Table 4/5/6):SPFM ≥ 90%、LFM ≥ 60%、PMHF ≤ 100 FIT。注意:PMHF ≤ 100 FIT 是每条子路径的个体目标;整体 item 的 ASIL D PMHF ≤ 10 FIT 目标仍须在 SC 主论证层级通过 Annex F.2 双点失效公式验证——两路独立时系统级 PMHF 由双点失效公式计算,通常远低于 10 FIT;但若两路有 CCF(共因),β > 2% 会使这项计算失效。
独立性不能只靠声明,须由 DFA(ISO 26262-9:2018 Clause 7 相关失效分析)论证:识别共因/级联失效并给缓解,目标共因 β ≤ 2%。两路分别出具子安全案例(Sub-SC-A / Sub-SC-B),各含独立 FMEDA 截面。
14.5 Evidence Index(证据挂接表)
每条证据须标版本号;SC 引用的版本必须与 V&V / 审计提交的版本一致(下表数值为说明性)。
| 文档 ID | 版本 | 类型 | 关键数字 | 独立核验状态 |
|---|---|---|---|---|
| FMEDA-TI-2026 | v3.1 | 硬件评估 | SPFM(Path-A) = 92.3%,SPFM(Path-B) = 91.8% | TÜV §5.6 盖章 |
| DFA-TI-2026 | v2.0 | 相关性分析 | β ≤ 2%;CCF 识别 8 处,全部缓解 | I3 独立审 |
| VV-TI-2026 | v2.0 | 验证报告 | MC/DC 覆盖率 91.3%;HIL 回归 1024 用例 0 fail | I3 见证 |
| SM-TC397-Rev4 | Rev4 | 芯片安全手册 | Lockstep DC_SPF = 99%,λD = 3.0 FIT | 芯片厂 TÜV 认证号 |
| SM-TLF35584-Rev3 | Rev3 | 芯片安全手册 | DC_SPF ≥ 96%,λD = 0.8 FIT | 芯片厂 TÜV 认证号 |
14.6 Residual Risk(残余风险)
Safety Case 须显式列举已识别但在可接受范围内的残余风险;遗漏等于论证缺口。
| 残余风险 ID | 描述 | 接受理由 |
|---|---|---|
| RR-01 | Path-A / Path-B 共用 12 V 辅助供电主轨 | TLF35584 PMIC 双独立调节器 + 100 μF 低 ESR 去耦满足 CCF 缓解要求 |
| RR-02 | SiC 老化(BTI / 阈值漂移)导致 EOL 危险失效率高于 BOL | FMEDA 已用保守 EOL FIT(相对 BOL 上修)核算,SPFM 仍在接受范围 |
| RR-03 | OTA 升级窗口期 AoU 握手缺失 | 已在 SC Assumptions 列明"OTA 期间系统进入 Degraded-Safe-Mode",在 DIA 合同中约定 |
14.7 Confidence Argument(元论证)
Confidence Argument 证"SC 本身可信",ACWG(Assurance Case Working Group)推荐但 ISO 26262 未强制;TÜV 审核常询问。
五节点结构:C1 假设可信度(Assumption Justification)→ C2 证据新鲜度(Evidence Currency)→ C3 方法适配性(Methodology Fitness)→ C4 独立性论证(Independence of Argument Authors)→ C5 全周期覆盖(Lifecycle Completeness)。
本项目 Confidence Argument 关键节点:C2 Evidence Currency = 所有文档版本与提交版本一致(见上表 Evidence Index);C4 独立性 = FMEDA 由 Tier-1 内部安全团队出,DFA 由 I3(TÜV)独立审。
15. Gotcha 链 — Safety Case 7 类高频工程陷阱
Safety Case 是论证结构,错误不发生在计算层,而是在论证逻辑层。以下 7 条是实际 TÜV / ACEA 审核中最常见的发现。
G1(最高危):FTTI 语义错层。 SC 中 Top Claim 引用的 FTTI(200 ms)是系统层指标,源自 HARA。但 FMEDA 的 SM 效用论证使用了器件层短路耐受(≤ 3 μs)。两者无直接可加性——SC 必须显式分两层论证(系统层:200 ms VCU 协调路径;器件层:≤ 3 μs 硬件 DESAT 路径),并说明两路如何共同满足 SG-01。混用导致论证缺口,审核员直接提 safety finding。
G2:FMEDA 版本漂移。 SC 证据表指向 FMEDA-TI-2026 v2.0,但工程团队在设计冻结后因封装 / 贴装变更(RthJC 实测修正到 datasheet 值 0.86 K/W typ、1.12 max)重算 SPFM 出了 v3.1。若未更新 SC 的证据引用,SC 与实际 V&V 基础脱钩——TÜV 审核会逐条核版本号。教训:热阻这类底层参数一变,FMEDA 结论级联,SC 引用必须同步。
G3:隐藏假设未列入 Assumptions。 SC Assumptions 章遗漏"VEE2 负压轨 UVLO 方向正确"这类实现级假设(实际 1EDI3035AS UVLO 在 |VEE2| < 5 V 时触发,而非 VEE2 < −5 V)。漏列意味着该假设不受 SC 生命周期管理,变更触发时不会自动标"受影响"。参见 栅极驱动保护链 G1。
G4:独立性标签与 DFA 不对齐。 SC 声称 Path-A / Path-B 的 D→B(D)+B(D) 分解已论证独立性,但 DFA 报告中两路共用 TLF35584 单芯片(双调节器架构),CCF 缓解论证缺失或仅用"电源管理"一句带过。TÜV 审核 DFA 独立性时会追问具体 CCF 缓解措施,SC 引用一个缺细节的 DFA 版本会被 flag。
G5:V&V 报告版本错配。 SC Evidence Index 列的是 VV-TI-2026 v1.0(开发测试报告),但系统集成后 I3 出具了 v2.0(含额外 EMC 测试 + 增量回归);型式认证实际提交 v2.0。SC 仍引 v1.0,与监管机构接受版本不一致——法规角度 SC 不能作为合规证据。
G6:缺失 Confidence Argument。 SC 提交了 Safety Argument 但无 Confidence Argument 附件;Confirmation Review(ISO 26262-2:2018 §6.4.9 确认措施 / Table 1)I3 审核时提"方法可信度未论证",SC 要重新补充——发生在开发末期,影响交付时序。Confidence Argument 应从概念阶段开始维护,不是收口前补充的文件。
G7:SC 生命周期断链。 概念阶段 SC v0.1 通过了 Confirmation Review,但设计阶段 FMEDA / DFA / STL 完成后未更新 SC 至"设计阶段收口"状态。系统集成前 SC 仍停留在概念状态——意味着设计层证据未被 SC 接收,SC 与实际工程活动脱钩,任何变更管理工具也无法基于 SC 触发联动更新。SC 必须是 living document:每个 phase gate 都要有 SC 更新记录。
16. Corner 分析 — 3 个边界场景
Safety Case 的论证边界一旦被系统级需求推移,原论证可能整段失效。以下 3 个边界场景说明何时必须重开论证。
C1:L4 自动驾驶 FTTI 压缩。 L4 快速扭矩控制若把 SG-01 FTTI 从 200 ms 缩短(具体值以 OEM 系统规范为准,常见量级 50–100 ms),SC Top Claim 随之重定义。FMEDA 必须重算 SM 诊断延迟——当前架构中 TCM/VCU 协调路径占用 100–150 ms,无法满足更紧的预算;SC 须新增"独立硬件快速关断路径"论证,否则原 SC 论证在 L4 场景下无效。
C2:SEooC SM 版本升级触发 SC 子分支重新论证。 栅极驱动 IC 从 1EDI3035AS Rev.3 升级至 Rev.4(短路检测时序参数变更),DIA 中 AoU 版本随之变。SC Sub-SC-A 中"gate driver DESAT protection"子分支的 evidence 引用(SM-1EDI3035AS)必须更新到 Rev.4,对应 FMEDA 截面重新论证 DC_SPF 是否仍满足分解后的 ASIL B(D) 目标。SM 版本升级从来不是"换个引用号",而是触发一整条证据链复核。
C3:双路 Sub-SC 主 SC 合并独立性论证缺失。 OEM 主 SC 引用 Tier-1 Sub-SC-A + Sub-SC-B,但主 SC 中必须有一节专门论证两路的独立性(物理隔离 + 电气隔离 + 软件空间隔离 + 独立 V&V),否则分解后的 ASIL D 目标不能在 OEM SC 层面闭合。独立性要求源自 ISO 26262-9:2018 Clause 5(分解要求充分独立)+ Clause 7(DFA 论证)。常见失误是认为"分解已在 Sub-SC 中论证",但主 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