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

ISO 26262 Part 2-6.4.7 定义 3 种独立检查,三者并行,不能互替。Confirmation 查"工作产品本身合规否",Audit 查"做事情按 Plan 没",Assessment 查"整体合规否"。

独立性 I1/I2/I3 三档(Part 2-6.4.7):

• 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 证据,两套必须串通。