FSM — Functional Safety Management 实务

Safety Plan 不是启动时一次性文件,而是 living document——以下是 Part 2 Clause 6.5.3 要求的 7 类必含信息的实际填写示例。

① 组织/角色(委派精确到人):

关键约束:I3 Reviewer 必须来自 OEM 侧或第三方(与 Tier-1 无合同关系),共 5 人,非 Tier-1 内部人员(ISO 26262-2:2018 Clause 6.4.9 + Table 1 独立性要求:ASIL D 的 confirmation measure 要求 I3 = 独立于负责部门的人员 / 独立部门 / 独立组织 —— 独立性级别 I0-I3 中最高一级)。

② Lifecycle 活动(Work Product 清单,节选 10 条):

注:ASIL D work product(WP-05/06/07/08/09/10)必须 I3 Confirmation;WP-01/02/03/04 I2 已足够。

③ 时间表/里程碑(精确日期):

关键约束:Final Assessment 必须 M14-15 启动(ISO 26262 Assessment 普遍 12–16 周),SoP 前 4 周才启动则 TÜV 一旦标 Major NC 必推 SoP(已在 topic-safety-assessment-audit 验证,见该页进度)。

⑤ Tailoring 清单(节选):

RACI 矩阵的核心工程约束是:Accountable 唯一 / 每行不能为空 / I3 Reviewer 在 ASIL D WP 上占多数 A。下面给出节选 5 行(第三方 Assessor 在这 5 个 WP 上均为 C — Consulted,故并入下段说明,不单列一列)。

FMEDA 和 SW Safety Arch 的 A 落在 I3 Reviewer——这是 Confirmation 独立性的核心,意味着 "I3 Reviewer 不签字 = WP 未关闭",不能靠 Safety Mgr 自签绕过。第三方 Assessor 对上述 5 个 WP 均为 Consulted(C):不承担 A/R,但在 Interim/Final Assessment 时对其证据链发表判定意见。

NC 跟踪 KPI(本项目设定):

DIA 是 OEM-Tier1 责任合同,规范出处是 ISO 26262-8:2018 Clause 5(要求见 5.4.3),无 DIA 等同不合规。以下 8 类关键条款给出具体语言示例。

1. HARA 责任:"HARA 由 Tier-1 Safety Eng 主导执行;OEM 确认 HARA C 参数(Controllability)评估 —— OEM 需在 M3 前提供 OEM 车辆动力学规格 + ODD 边界;双方不签字则 HARA 不关闭。"
2. Sa.Val 责任:"PG Sa.Val 由 OEM 主导场地 + 车辆 + 驾驶员招募;HiL + Bench Sa.Val 由 Tier-1 执行;I3 Reviewer 来自 OEM 独立安全部门(≥ I3 级,非该项目参与方);Final Sa.Val Report 由 I3 Reviewer 签字。"
3. FMEDA 数据:"Tier-1 提供元件级 FIT;OEM 提供系统级失效率分配表(整车 PMHF 预算);两者缺一不可——Tier-1 不得自行假设系统级分配。"
4. Field 反馈:"量产后 OEM 侧收到与 SG 相关客诉 → 5 工作日内通知 Tier-1 Safety Mgr → Tier-1 Safety Eng 10 工作日内完成 Safety Impact Assessment → 若判定 SG 影响则触发 Safety Change Request。"
5. I3 Reviewer 来源:"ASIL D WP 的 I3 Confirmation 由 OEM 侧安全部门池(5 人)担任;Tier-1 内部工程师不得担任同项目 I3 Reviewer。"
6. Assessor 连续性:"项目全程使用同一 Assessor(TÜV Süd);任何 Assessor 变更须 30 天前书面通知双方,并评估 Interim Assessment 结论延续性。"
7. Data Access:"Sa.Val Fleet 数据(CAN log + 事件记录)Tier-1 与 OEM 双向可访问;数据格式 MDF4;存储服务由 OEM 提供,Tier-1 有只读账户;商业保密信息用字段屏蔽,不影响 Safety 数据访问。"
8. SM 版本升级:"供应商推 Safety Manual 版本升级(如 TC397 SM Rev.X → Rev.X+1) → Tier-1 30 天内完成 AoU 影响评估 → 若有 AoU 变更则触发 DIA 变更管理 CCB。"

Part 2 Clause 6.5.3 明确每条 Tailoring 偏离须有 ALARP 论证 + Safety Mgr + Quality Manager 联签。工程实践中"Tailoring 无理由"是 Audit NC 最高频来源之一。典型事故链:项目组为节省工时,把 7 条 Part 5 要求写成 "本项目特殊,不适用" 而无 ALARP 论证 → M12 Audit 审计员发现 15 条无理由 Tailoring → 全部要求补 ALARP 论证 + 追溯 HARA 重审(因部分 Tailoring 影响 DC 目标) → NC 关闭 +8 周 → SoP 推延。

修复:Safety Plan Tailoring 章节建立模板行:"[偏离条款 ID] / [偏离内容] / [ALARP 论证:为什么偏离不降低安全水平,替代措施是什么] / [联签:Safety Mgr + Quality Dir. + 日期]"。每条均需双签,TBD 不允许出现在 Tailoring 清单。

实战中团队常写 "Safety Plan Accountable = Safety Mgr + 项目总监(联合负责)" 以示重视。审计员追问 "Safety Plan v1.4 关闭这个动作谁拍板?" 若两人都可答 "我" / 两人都说 "对方" → RACI 失效。ISO 26262 安全活动的 Accountable 本质是 "单点问责"(Single Point of Accountability)—— 多人联合 A 使问责链断裂。

修复:RACI 矩阵铁律写入 Safety Plan 注释:"每行 Accountable 必须唯一(姓名+工号),联合签字的 work product 仅在 R 列加人,A 仍为 Safety Mgr 一人;RACI 版本控制每次人员变动必须更新。"

Safety Plan v1.0 于 M0 签发,之后 FMEDA 从 v1.0 迭代到 v3.1(修复了 3 个 SPFM 不达标问题),SW Safety Arch 从 v1.0 升到 v1.2(新增 ASIL 分解接口),但 Safety Plan 仍引用旧版本号。M15 Final Assessment 时 TÜV 发现 Safety Plan 与实际工作产品版本矛盾 → "FSM 不可信" → Major NC。补签 Plan v2.x + 追溯对齐所有 WP 版本 → +6 周。

修复:Safety Plan Lifecycle 活动表设立"版本追踪"列,每次 WP major 版本更新 → Safety Eng 在 5 工作日内触发 Safety Plan v.minor bump + Safety Mgr 签字;Safety Plan 每月轻量回顾(月会议事项之一,30 分钟,对比 WP 版本表与实际)。

DIA 写"Sa.Val 数据由 OEM 负责采集",但漏掉 Tier-1 能否访问原始 CAN log。SoP + 6 月 Fleet 测试中某台车发生 3 次 DESAT 误触发事件,Tier-1 要求调取 CAN log → OEM 以"商业保密"拒绝(含 OEM 内部控制器 raw 数据) → Tier-1 无法 root cause → Safety Impact Assessment 无法完成 → 违反 DIA Field 反馈条款 → OEM 提起合同索赔风险。

修复:DIA Sa.Val 数据章节明确:"所有 Safety Goal 相关事件的 CAN log,Tier-1 安全团队有只读访问权;商业敏感字段由 OEM 字段屏蔽处理,不影响 Safety 数据字段;数据格式 MDF4,访问账户由 OEM 在 Sa.Val 启动前 M6 开通。"

ASIL D 的 FMEDA 和 Safety Arch 需要 I3 独立 Confirmation(ISO 26262-2:2018 Clause 6.4.9 + Table 1)。项目组为省 I3 评审排期,把 FMEDA I3 降成 I2(Tier-1 内部有 I2 能力)。M12 Interim Assessment 时 TÜV 把该 Confirmation 判"无效" → 要求补 I3 Review → I3 Reviewer 池排期 4-6 周 → SoP 推延。

修复:Safety Plan Confirmation 章节建立 "ASIL → I 等级映射表":ASIL D WP → I3(第三方 / OEM 独立);ASIL C WP → I2(项目外内部);ASIL B WP → I1(项目内独立)。每个 WP 的 I 等级在 Lifecycle 表中锁定,不允许降级。

Safety Plan 仅覆盖到 RFP,Production-level FSM 是空段落。SoP 后 12 月 OEM 上报 5 例 SG-01 相关客诉(驾驶员感知"扭矩抖动"),Tier-1 走普通产品 8D 流程,无 Safety Impact Assessment → 12 月后 OEM 内部安全部门抽查发现 8D 未走 Safety 通道 → 触发 Recall Risk Assessment → Tier-1 被要求出具 Safety Impact Analysis(2 个月) + 潜在整改方案 → 损失远超在 Safety Plan 中建立 Field 机制的成本。

修复:Safety Plan Production-level FSM 必须包含:① "Field 投诉 → Safety Eng 5 工作日 Safety Impact Assessment → 判断 SG 相关? → 是则开 Safety Change Request(SCR)" 的完整流程;② 每年 Internal FSM Audit 包含"Field 反馈机制是否有效运转"检查项;③ SCR 追踪台账由 Safety Mgr 维护。

TC397 Safety Manual 从 Rev. 4 升级到 Rev. 5(2026-04 发布),新增一个 AoU 约束(LBIST 在 −40°C 完成时间延长,需调整 WDT 窗口)。Tier-1 HW 团队更新了 PCB 但未走 Safety Change Request → Safety Plan 仍引用 Rev. 4 的 AoU → M15 Final Assessment TÜV 发现 SM 版本漂移 → Major NC。补全 AoU 重新核对 → 可能影响 FMEDA λD → FMEDA v3.2 → 重做 I3 Review → +8 周。

修复:DIA "SM 版本升级管理" 条款:供应商发布新 SM → 30 天内 Tier-1 Safety 完成 AoU delta 评估;若 AoU 有 safety 相关变化 → 触发 Safety Change Request → FMEDA + Safety Plan 版本更新。建立供应商 SM 订阅机制(直邮 Safety Mgr),不靠 HW 工程师自查。

如果 OEM 要求 Tier-1 在 SoP + 6 月把电驱 ECU 集成进 Domain Controller(DC),与 ADAS 域共用 TC397。Item Definition 边界须重画 → 原 Safety Plan 的 RACI / I3 Reviewer 安排 / FMEDA λD 分配全部失效。实战中两域 Safety Plan 可能打架:电驱 Tier-1 认为 "ASIL D 分解接口由 OEM DC 层负责";ADAS Tier-1 认为 "接口由电驱侧提供";双方都觉得对方做 → DIA 无仲裁条款 → 接口未定义 → Assessment 时发现。

Sa.Val 影响:整车 Sa.Val Plan 须新增"两域协同失效场景"(如 ADAS 发出与电驱 SG-01 冲突的扭矩请求)。原有单域 Sa.Val 覆盖矩阵不足。

修复:DIA 明确"Domain Controller 集成触发 Item Definition 重开 + Safety Plan 联合评审(电驱 + ADAS 两个 Tier-1 + OEM 安全架构);接口 ASIL 等级由 OEM 仲裁"。Safety Plan Lifecycle 增加 "Domain 集成 Change Gate"。

M12 Interim Assessment 由 TÜV Süd 做完,M15 OEM 决定改用 SGS(成本考虑)。SGS 不承认 TÜV Süd 的 Interim Assessment 结论(不同 Notified Body 做法不同),要求重跑 5 个 ASIL D WP 的 Confirmation Review。如果 DIA 无 Assessor 连续性条款 → 意外 6–8 周 re-review 工作量 + SoP 推延。

修复:DIA Assessor 条款:"项目全程使用同一 Assessor 机构;变更须 60 天提前书面通知并经 Safety Mgr + OEM 安全负责人联签批准;新 Assessor 须书面确认承认前期 Interim Assessment 结论,否则视为 Full Assessment 重新开始,费用和时间由提出变更方承担。" 这把 Assessor 变更的商业风险显式化。

TC397 上电 STL + March-C BIST 在 −40°C 延迟增 2–4×(低温下载流子迁移率下降,BIST 自检时间随之拉长;具体规格以 Infineon SafeTlib / 应用手册为准)。若 SW FSM 在 BIST 未完成前不激活 WdgM / SafeState 机制 → 冷启动期间 SG-01 的 SW 诊断路径不可用(注:SG-01 的 FTTI 是单值 = 200ms;这条 SW 路径承担的是其中约 10 ms 的 FDTI 诊断子预算,不是第二个 FTTI)→ 仅 HW DESAT 路径(约 1.22 μs)兜底。若 BIST 延迟达 25 ms → WdgM 激活延迟 25 ms:因 25 ms ≪ 200 ms 的 SG-01 FTTI,并不直接击穿整链实时预算,但在这 25 ms 窗口内 SW 诊断覆盖率 = 0 → SW 层故障(相电流 ADC 异常)只能靠 HW 路径,构成 latent 故障窗口(LFM 问题,而非 FTTI 击穿)。

FSM 角度:Safety Plan 时间表须包含 "冷启动 Sa.Val 条目":HiL −40°C 冷启动 FI 测试(Phase M9 Bench Sa.Val)。Safety Mgr 须与 TC397 供应商确认 cold-start BIST spec;若 BIST 延迟不可接受,SW Safety Arch 须把 BIST 拆为后台任务(SM 先激活,BIST 后完成)。FMEDA 须把 "BIST 期间 SW DC = 0%"的时间段显式计入 latent 故障分析(LFM 影响)。