Safety Assessment / Audit / Confirmation — 三层独立检查

ISO 26262-2:2018 Clause 6.4.9(Confirmation measures)+ Table 1 定义 3 种确认措施(confirmation measures),三者并行,不能互替。Confirmation Review 查"工作产品本身合规否",Audit 查"做事情按 Plan 没",Assessment 查"达成的功能安全整体合规否"。Functional Safety Assessment 对 ASIL (C) 和 D 强制(评估已达成的功能安全),ASIL A/B 通常不要求。

独立性 I1/I2/I3 三档(ISO 26262-2:2018 Clause 6.4.9,I3 = 组织/部门独立,ASIL D 关键工作产品必须):

• I1:不同人,同 team 同上司 — ASIL A 接受
• I2:不同 team,不同上司,同部门 — ASIL B/C 接受
• I3:不同部门 / 第三方 — ASIL D 必须

ISO 26262 Part 2 Table 1 给出 work product × ASIL 等级 → 独立性要求的速查表。下面是常用 11 个 work product 的摘录:

ASIL D 项目 ~ 50+ Reviews,其中 ~ 30 % 必 I3。典型 Tier-1 配 2-3 个 dedicated Safety Engineer 专做 Confirmation(独立于设计 team)。

ASIL D 项目 18 个月典型,Safety 检查贯穿全周期。

按阶段:

最关键的预算:Final Assessment(TÜV 12-16 周)必须 M14-M15 启动,留 M16-M18 修复 NC 和 Sign-off。绝不能拖到 SoP 前 1 个月——TÜV 一旦标 "Major NC" SoP 必推 3-6 月。

第三方 Assessor(TÜV / exida / SGS-TÜV Saar)的提问方式高度结构化——从顶层指标一路追到证据链根部。

典型 5 层追问:

• Q1:这个 ASIL D 主驱 SPFM 多少?— 99.2 %
• Q2:每个元件 DC 怎么定的?— 套 Annex D + 部分 Fault Injection
• Q3:Fault Injection campaign 报告呢?— 打开 Yogitech 报告
• Q4:FI 工具 ISO 26262 qualified 吗?— TCL1,有 qualification kit
• Q5:DFA 表 sensor 路径独立吗?— Sin/Cos 双路独立 ADC + Plausibility

任何一层答不出来或证据不足 → 一直问到 root cause,常被追到 Tool Qualification 或 DFA 漏共因。Tier-1 准备 12 周前提交 Pre-Assessment 包,assessor 提前看完才进现场。

SoP 前 12 周向 TÜV 提交的标准包:

• Safety Plan v 终(项目章程)
• Safety Case 草稿(Argument + Evidence)
• HARA + FSC + TSC 全套
• FMEDA workbook(电子表格 + 数据来源)
• DFA Report(共享资源清单 + 隔离证据)
• Confirmation Reports 汇总
• Audit Reports 汇总
• Fault Injection campaign 报告(每个 ASIL D 元件)
• Tool Qualification Records(每个 ISO 26262 工具)
• Production Plan + ICT/EOL 覆盖率(Part 7)
• Field Monitoring Plan(PRD / 8D 流程)
• Cybersec(ISO 21434)证据(L3+ 必须)

历史案例统计,导致 "Conditional Pass" 或 "Fail" 的 Top 5:

轻 NC 2-4 周修复后 Sign-off;重 NC 涉及架构改动则 SoP 延 3-6 月——这是车规最贵的失误之一。

Audit 不查"做对了",查"按 Plan 做了"。典型 5 类检查:

• Safety Plan 执行 — 计划里写的 Reviews / Audits / Trainings 都做了吗
• 培训记录 — 工程师有 ISO 26262 培训证书吗
• Tool 管理 — 用的 compiler / debugger / static analyzer 都 qualified 吗
• Change Management — 设计变更走 Safety Impact Analysis 了吗
• 配置管理 — Source code / FMEDA / 文档版本受控吗

Audit 通常 1-2 周/次,出 NC 清单 + CAPA(Corrective And Preventive Action)跟踪。

Assessment 通过不是终点——量产后 Field 反馈持续影响 Safety Case:

• 客诉 / 8D 报告必须按 Safety Goal 重判 — 涉及 SG 失效 → 触发 Field Action
• SOTIF / Cybersec 事件回溯 Safety Case
• OTA 升级触发 Re-Assessment(若影响 Safety Function)
• 召回 / Recall 必须有 Safety Case 支持

Safety Case 是 living document,SoP 后还要持续维护。

实战中 Assessment 失败常出于"以为 Confirmation 数量够就够",忽略 Audit 和 Assessment 的不同作用。下面 5 条是 TÜV 最常打回的点。

• 三种检查混用。把 Confirmation 当 Audit,Audit 当 Assessment——三者目的不同,不能互替。
• 独立性偷工。ASIL D 必 I3,有的 Tier-1 用"同部门不同 team"(I2)交付,被 TÜV 砍。
• Assessment 拖到 SoP 前 4 周。TÜV 走完最少 8 周,极限赶工通常翻车;留 16 周 buffer 是常识。
• Field 反馈机制为空。Assessment 一定问"量产后怎么持续监控?"——没机制 = 重 NC。
• Cybersec 独立准备。L3+ 项目 TÜV 同时要 ISO 26262 + ISO 21434 证据,两套必须串通。

本节把 §1-§7 的方法落到完整项目时间线上:400 V / 100 kW EV 主驱逆变器,ASIL D 主安全目标 SG-01「避免意外加速(FTTI = 200 ms)」。安全链 = TC397(主控 MCU)+ TLF35584(SBC)+ 1EDI3035AS(栅极驱动)+ SCT3080AL×6(SiC MOSFET),18 个月开发周期,典型 Tier-1 供应商场景。参数量级取自 ISO 26262-5:2018 Annex E 与本 wiki 同域页;真实项目须以器件当版 Safety Manual 数值替代。

本节列出 Tier-1 进入 Assessment 阶段最高频的 7 类失误(按高危到低危排序),每条附根因与防范动作。

G1 — SPFM 弱证据推迟 FI Campaign(最高危)

FMEDA v1 引用 ISO 26262-5:2018 Annex D 典型值(如 Lockstep DC = 99 %、WD DC = 99 %),不做 Fault Injection 实测,SPFM 看上去 99.2 % 通过,实际被 TÜV 砍值到 96 %。这一条几乎是所有 ASIL D 首次评估的 NC #1 来源。防范:FMEDA v1 完成(M9)立刻对占危险失效率 λD 前三的元件启动 FI campaign;不能等 M14 Pre-Assessment 前。

G2 — 独立性 I2 充 I3(技术合规缺陷)

ASIL D 的 HARA / FSC / TSC 必须 I3(不同组织/部门/第三方)。部分 Tier-1 用"A 部门 Safety Team 审 B 部门设计 Team",汇报同一 Safety Director → 仍是 I2。TÜV 查 org-chart 即暴露,需重做 30 % Reviews,耗时 6–10 周。防范:立项时在 Safety Plan 里锁定 I3 来源(外部顾问 / 兄弟公司独立事业部 / TÜV 自身),不依赖内部 peer review。

G3 — Assessment 启动时间晚(项目进度杀手)

典型错误:M16 才联系 TÜV,留给 Assessment 2 个月。ASIL D 完整 Assessment 的日历周期通常需 12+ 周(行业经验值,非标准规定,取决于评估机构与项目复杂度),极限 8 周已属加班赶工,遇到重 NC 翻修直接推 SoP 3–6 月。防范:M14 提交 Pre-Assessment 包,M15 Interim 出 NC 清单,M15–M17 并行修复(NC#1 关键路径 ~10 周),M17 Final;Assessment 总 buffer = 3 个月,不能砍。

G4 — FMEDA 版本漂移(证据链断裂)

TÜV M14 收到 FMEDA v3,研发团队 M15 内部出了 v4(修了一个不相关 bug),M17 Final 时 Safety Case 引用的还是 v3 数字,与 FMEDA workbook 版本对不上。TÜV 判"Safety Case evidence stale" → Major NC。防范:Safety Case 与 FMEDA 任何版本更新强制联动(工具或手动),评估期间冻结 FMEDA,变更走 Change Impact Assessment。

G5 — 工具升级未重新 Qualify(高频行政 NC)

项目期间 compiler / static analyzer 任何版本升级未重评 TCL 并重做 qualification,版本号与证书对不上 → TÜV 出 NC。修复通常简单(3–4 周),但浪费 Final Assessment 时间窗。防范:工具版本冻结在 Assessment 前,或升级前先核 TCL scope(是否只需 delta qualification)。

G6 — Pre-Assessment 包漏 Field Monitoring Plan(隐蔽坑)

Field Monitoring Plan(量产后 8D + Warrant + PRD 流程)是 §5 清单必含项。很多 Tier-1 以"量产才用到"为由延迟准备,TÜV 在 Pre-Assessment 包审查时一旦发现缺失,直接出 Administrative NC,浪费整个 Interim Assessment 日历期。防范:M12 即完成 PRD 流程初稿,不等 M14。

G7 — Living Safety Case SoP 后断链(长尾风险)

Assessment 通过不是终点。SoP 后首次重大 8D 事件(如批量 DESAT 误触发导致 AEB 意外启动)若无法回溯到 Safety Case 的 Safety Goal 层,Field Action 被迫补做完整 δ-Assessment(1–2 月),还可能触发召回。防范:在 Safety Plan 中明确 Living Safety Case 维护责任人,8D 分类标签中增加 "Safety Goal Impact" 字段,自动触发 Safety 评审。

本节给出三个超出 §10 典型路径的极端场景,说明 Assessment 的边界条件与稳健性。