Confirmation Measures (CM) — I0-I3 + DIA + FSAR

ISO 26262-2:2018 §6.4.9(Table 1)把"谁来 confirm"拆成两个互相垂直的维度:类型——三种 confirmation measure(Confirmation Review 审 work product 内容,§6.4.10;Functional Safety Audit 审 process,§6.4.11;Functional Safety Assessment 审整体功能安全达成,§6.4.12);独立性——四个等级 I0-I3(加"—"共五档记号,见第 3 节)。常见误区是把 I0-I3 当成 CR / Audit / Assessment 三件套的代号——它们不是同一回事:同一个 CR 在不同 ASIL 下要求不同独立性,同一独立性等级也可以套在任一 measure 上。ASIL 等级直接决定每个 measure 要达到的最低独立性,不是"做完 I0 再做 I1":

Confirmation measure 与 verification(验证)是并行的两套活动:verification 查 work product 是否满足技术需求(对应各 part 的验证要求),CM 查 work product 对功能安全达成的贡献证据是否充分(§6.2)。三种 measure 的报告 + safety case 一起,支撑最终的 release for production 决定(§6.4.13)。

作用:第一种 confirmation measure,判断 Table 1 所列关键 work product 是否为其功能安全贡献提供了"充分且令人信服的证据"(§6.4.9.1 a)。reviewer 检查 work product 的正确性、完整性、一致性、充分性(§6.4.10.3 NOTE),按 Annex C 的 informative 指南逐项过——例如 HARA CR 要评估 E/C/S 参数的 rationale(含评成 E0/C0/S0 与 QM 的)、假设是否显式记录、同组织内可比 hazardous event 的 ASIL 是否一致(C.3)。

CR 只针对 Table 1 列出的、且 safety plan 要求的 work product(§6.4.9.1 NOTE 1)。Table 1 实际清单(2018 版):

• item 级 impact analysis(§6.4.3 的输出)
• HARA(ISO 26262-3:2018 Clause 6)
• safety plan(含 element 级复用 impact analysis、proven-in-use 论证、工具裁剪)
• FSC(Part 3 Clause 7,由安全分析 + 依赖失效分析结果支撑)
• TSC(Part 4 Clause 6,同上支撑)
• integration and test strategy(Part 4 Clause 7)
• safety validation specification(Part 4 Clause 8)
• safety analyses + dependent failure analyses(Part 9 Clause 8 / Clause 7——FMEDA 属此)
• safety case

注意:"测试报告"不在 Table 1 里——测试结果属 verification 链,进 safety case 由 assessment 综合评判,不单独走 CR。

评审形式(实务):看文档逻辑、术语、计算,1-2h 会议,出 review minutes 记录 issue + 关闭状态。CR 可指派 assistant 协助,assistant 独立性可低于 reviewer 但至少 I1,且 reviewer 须对其输入做无偏鉴别(§6.4.10.4)。CR 与 verification review 可以合并做,但合并后的评审必须满足 Table 1 的独立性(§6.4.10.5)。全部 CR 必须在 release for production 之前完成(§6.4.10.2)。

独立性随 ASIL 升级(按 Table 1 实际值):大多数关键 work product 的 CR 是 A→I1、B→I1、C→I2、D→I3;integration & test strategy 与 safety validation spec 两行更松(A→I0、B→I1、C→I2、D→I2);而 impact analysis 与 HARA 的 CR 在任何等级(含 QM)都是 I3——因为 ASIL 定级本身必须被独立确认。

风险:独立性不够易出现"集体盲区"(大家共享同一个错误前提),所以 ASIL 越高、要求评审者越远离作者所在组织单元。

I0-I3 不是 measure 类型,而是某个 confirmation measure(CR / Audit / Assessment)由"多独立"的人执行。Table 1 脚注给出五档记号(ISO 26262-2:2018 Table 1 注 a,按原文):

• "—" — 对该 confirmation measure 无要求、也无建议(不是"禁止做")。
• I0 — 该 measure 应当(should)做——是建议而非强制;一旦做,必须由不同于 work product 创建者的人执行。I0 不等于"可以作者自审"。
• I1 — 必须做,由与创建者不同的人执行(可同 team)。
• I2 — 必须做,由独立于创建该 work product 的 team 的人执行,原文判据:不向同一 direct superior 汇报。
• I3 — 必须做,由在管理、资源、发布权限(management, resources and release authority)三方面独立于创建部门的人执行。注意:I3 只要求部门级三重独立,完全可以是公司内部另一部门的人;不等于"必须第三方"。

"独立"实操判据:

• 与作者不汇报同一 direct superior(I2 的字面判据;I3 还需跨部门 + 三重独立)
• 没参与该 work product 创作
• Table 1 各行的 scope 原文还明确要求独立于 project management(audit / assessment 及多数 CR 行)——所以项目经理本人不能兼任
• 有相应技术能力(否则审不出问题);标准注明独立性的目的就是客观无偏视角、避免利益冲突(§6.4.9.1 NOTE 3)

形式(实务):评审委员会 3-5 人,按所需独立性跨 team / 跨部门拼;提交 evidence + 答辩 + 改 issue + 重审。执行 CM 的人有权访问相关信息与工具,开发组织有义务支持(§6.4.9.2 / §6.4.9.3)。

审 process 是否落地,不是审 work product 内容。这是与 CR 并列的第二种 measure 类型。适用性按 §6.4.11.1:安全需求最高 ASIL 为 (B)、C、D 的 item / element 要做——对应 Table 1 的 B→I0(建议)、C→I2(强制)、D→I3(强制),A 与 QM 无要求;且必须在 release for production 前完成。

Audit 报告的评判基础(§6.4.11.4,原文五项 + 改进建议):

• 对照 safety plan 里定义/引用的活动,评估 process 的实际实施
• 对照组织级安全规则与流程(§5.5.1)评估 safety plan 的产物
• 评估"process 目标已达成"的论证(若提供)
• 评估 safety plan 要求的 work product 是否齐全
• 评估 work product 是否符合 ISO 26262-8:2018 §10.4.3(文档要求)且相互一致
• 给出改进建议(如有不合规)

主审(实务):中央质量 / 功能安全部门的专职 auditor(通常有 TÜV 培训 + 多年项目经验)。不能由本项目 safety manager 自审——safety plan 及其执行正是被审对象,且 Table 1 要求 auditor 独立于 item 开发者与 project management。两个有用的原文注:audit 可与 Automotive SPICE assessment 同步/合并做,但 ASPICE assessment 不足以替代 FS assessment(§6.4.11.4 NOTE 3);项目早期做 audit 有利于尽早暴露流程弱点(NOTE 5),别攒到 SOP 前。

判整体功能安全是否达成:assessment 评判 item 达成的功能安全,或 element 对功能安全达成的贡献(§6.4.12.1)。适用性与 audit 同一档:最高 ASIL 为 (B)、C、D 要做——B→I0(建议)、C→I2(强制)、D→I3(强制)。ISO 只要求独立性,不要求第三方——内部独立部门即可满足 I3;实务中 OEM 出于商业 / 准入考虑常指定独立第三方机构(TÜV / SGS / DEKRA)来做,这是合同选择,不是 ISO 对 assessment 的定义。

Assessment 的范围(§6.4.12.7):safety plan + 其要求的全部 work product(Table 1 所列重点关注)、功能安全所需的 process(可基于 audit 结果)、已实施安全措施的适当性与有效性、safety case 的论证、safety anomaly 关闭理由;并要考虑其他 CM 的结果、上一轮 assessment 的整改、以及 supplier 按 DIA 交付的 assessment 报告(§6.4.12.8)。assessor 可指派 assistant(独立性至少 I1,§6.4.12.6),并被授权自行决定评估的广度与深度(§6.4.12.5)。

时序要求(§6.4.12.3):最迟在系统级产品开发启动时就规划(should),渐进式执行(progressively performed),release for production 前收尾——不是 SOP 前一次性突击。Annex D 给了 ASIL D item 的 assessment agenda 示例。

实务常用第三方(2026,OEM 商业选择而非标准强制):

• TÜV Süd — 德国,EV 主驱主流(比亚迪 / 蔚来 / 小鹏都跑)
• TÜV Rheinland — 德国,商用车 + 经济款 EV
• SGS — 瑞士,全球化
• DEKRA — 德国
• 中汽研 / 中国软件评测中心 — 中国本土,部分 OEM 接受

典型 assessment 周期(实务):pre-assessment 1-2 个月(看 OEM/Tier-1 准备情况)→ main assessment 3-6 个月(读评 work products + 现场审 + 答辩)→ 整改 + re-assessment 1-3 个月 → 出 FSAR (Functional Safety Assessment Report) 100-300 页。成本:100-300 万人民币(EV 主驱 ASIL D 项目典型,第三方 assessment 报价)。

下表按 ISO 26262-2:2018 Table 1 原文完整转录(行 = confirmation measure,格 = 所需最低独立性)。三个最容易记错的点:① impact analysis 与 HARA 的 CR 在 QM 也要 I3;② ASIL D 并非全部 I3——integration & test strategy 与 safety validation spec 的 CR 只要 I2;③ audit / assessment 在 ASIL B 是 I0(建议做),不是"无要求"。

记号(Table 1 注 a):"—" = 无要求无建议;I0 = 建议做,做则须不同人;I1/I2/I3 = 强制,独立性递增(人 / team / 部门三重独立)。除 impact analysis 与 HARA 两行外,各行按"安全需求中最高 ASIL"取列。

把 Table 1 套到一个真实项目上,才能看清"哪些审查可以留在 BU 内、哪些必须出部门"。设定:Tier-1 的逆变器 BU 下设系统 / HW / SW / 测试四个 team(各自 team lead,统一汇报 BU head);同公司另有中央质量与功能安全部(另一条 VP 线,管理 / 资源 / 发布权限均独立于逆变器 BU);安全目标 SG1"防止非预期扭矩"ASIL D。逐项配置(下表把 FSC 与 TSC 的 CR 合并为一行,共 10 行;第 6 节 Table 1 原文分列为 11 行):

结论:按第 6 节 Table 1 的 11 行计,ASIL D 下 9 项必须出部门(I3)、2 项 BU 内跨 team 即可(I2);按本节 FSC/TSC 合并后的 10 行计则是 8 项 I3 + 2 项 I2,口径不同、内容一致。中央 FS 部在项目全程的 loading 要提前进资源计划(§6.4.6 safety plan 就要把 CM 的规划写进去);assessment 报告最终给 OEM 的 FSA 汇总用(§6.4.12.8 d)。

DIA 是 Tier-1 与 OEM 之间的功能安全责任分工书(ISO 26262-8:2018 Clause 5"分布式开发接口")——没 DIA = 评审拒。

DIA 内容:

• 每个 work product 谁出(OEM / Tier-1 / 哪个团队)
• 每个 work product 谁 review(I0-I3)
• 接口数据格式 / 时间表 / 验收标准
• Tool qualification 责任分工
• supplier 的 FS assessment 报告在哪些 milestone、以什么形式交付(§5.4.5,Part 2 §6.4.12.7 NOTE 8 引用)
• DTC / FI / FSAR 各自负责范围

EV 主驱典型 DIA 约 50-150 页,签字时间 2-4 个月(实务)。没签 DIA 直接进开发 = 后期评审推倒重来。

链接:ASIL 分解深度 — DIA 也定义分解 channel 边界

FSAR (Functional Safety Assessment Report) 是 Functional Safety Assessment 的最终输出,标准要求它必须包含对 item 功能安全(或 element 贡献)的推荐结论:acceptance / conditional acceptance / rejection(接受 / 有条件接受 / 拒绝,§6.4.12.9)。conditional acceptance 必须列明接受条件,且对应整改必须执行(§6.4.12.11 / .12);rejection 则要整改后重做 assessment(§6.4.12.13)。OEM 凭 FSAR + safety case 走 release for production(§6.4.13:负责人签字、版本与配置固化、软硬件基线含标定数据归档)。

FSAR 内容(实务典型 100-300 页):

1. 执行摘要 — 推荐结论(acceptance / conditional acceptance / rejection)
2. HARA + FSC + TSC review — 完整性 + 合规性
3. FMEDA 复核 — SPFM/LFM/PMHF 数值合理
4. FI test review — 100+ scenario 覆盖审查
5. DIA 审查 — 责任分工是否清晰
6. Open issues — 必须整改的清单
7. 附录: 工具资质 / Confirmation reviews / 流程文档

Open issue 等级(实务分级,TÜV 报告习惯,标准原文只区分"接受条件"必改):

• Major (整改前不允许量产)
• Minor (整改方案确认即可)
• Observation (建议改进)

EV 主驱 ASIL D 项目典型出 5-15 Major + 30-60 Minor + 100+ Observation(实务),整改后 re-assessment 通过 → acceptance 结论 → release for production + 量产 PPAP 通过。

CM 在 OEM 评审会拒最常见的不是技术错,而是条款理解 / 独立性 / 证据三类问题。下表 7 个反复出现的坑:

三个边界工况,都是 Table 1 表格本身读不出来、要靠条款细则的:

Corner 1 — 分布式开发:supplier 也要做自己的 assessment。 FSA 活动在 customer 和 supplier 两侧都执行(§6.4.12.7 NOTE 8):supplier 的 assessment 判"是否满足客户安全需求 + element 贡献",按 DIA 约定的 milestone / 形式交报告;OEM 侧 assessment 必须考虑 supplier 报告(§6.4.12.8 d),最终"item 集成进整车后的功能安全"judgement 归整车厂。Tier-1 不能以"OEM 会做总 assessment"为由跳过自己的。

Corner 2 — 组织太小,没有第二个部门。 I3 要求管理、资源、发布权限三重独立于创建部门——初创公司整个工程就一个部门时,内部无人满足 I3,事实上只能外聘独立机构。这是"I3 在小组织收敛成第三方"的机制:变的是能满足定义的组织选项,不是 ISO 定义本身。

Corner 3 — item 变更后 CM 不自动有效。 CM 完成后 item 再改动,相关 CM 要重做或补充(§6.4.9.1 NOTE 6,变更管理走 Part 8 §8.4.5.2)——SOP 后的软件 OTA / 硬件改版同样触发。另一个相邻细则:ASIL decomposition 只影响 TSC 那一行 CR 的独立性取值(Table 1 注),audit / assessment 仍按"安全需求最高 ASIL"走,分解救不了 I3。

把三种 measure(CR / FS Audit / FS Assessment)+ DIA + FSAR 拼成一个 18-24 个月的真实项目时间表,可以看到 FS Assessment + 整改占了 SOP 前(项目末段)的 6-9 个月——正因如此,§6.4.12.3 要求 assessment 渐进执行,表中 pre-assessment 就是渐进的第一段。新主管 onboard 时必须按这条 timeline 倒推什么时候必须出 DIA / 什么时候启动 TÜV pre-assessment:

典型 18-24 个月,FS Assessment 占 6-9 个月(实务)。