FSM — Functional Safety Management 实务
本质与导读
本质:Part 2 告诉你"标准要求 FSM 做什么",这页告诉你"实际项目里怎么落地"。FSM 是把分散在 Part 3-8 的技术活动用一份 Safety Plan(项目章程)、一个 Safety Manager(单点问责人)、一套 RACI 矩阵(角色映射)和五大 FSM 触点(贯穿 V-cycle)串成可执行体系。FSM 失败的项目不是 HARA / FMEDA 算错,而是组织失灵——Safety Plan 不 living、角色未签字、Tailoring 没理由、变更绕 CCB、Field 反馈无机制。本页用 RACI + 时间表 + 成熟度模型把"如何 run 一个 ASIL D 项目的 FSM"写明白。
1. 三层 FSM 体系
ISO 26262 Part 2 Clause 5-7 把 FSM 分三层,三者并行,职责不可互替。Org-level 是公司级常态制度(Safety Culture / Tool Qualification 框架),Project-level 是单个项目的章程(Safety Plan + Mgr + Reviews),Production-level 是 SoP 后的持续维护(Field 反馈 / 8D / OTA)。
实战判断:Audit / Assessment 不通过的常见根因有 30% 落在 Org-level(公司没建 Safety Culture 制度 / 没有跨项目 Tool Qualification 框架),被审计员判 "FSM 体系不完整"。项目级 FSM 做得再好,公司级缺失也救不回来。
2. Safety Plan 是项目章程
Safety Plan 不是一份"启动文档",而是 living document,贯穿项目全周期。Part 2 Clause 6.5.3 列出 7 类必含信息——审计员开口问 "Plan v 几?上次更新什么?"
7 类速览:
| 节 | 内容 | 实战要点 |
|---|---|---|
| ① 组织 / 角色 | Safety Mgr / Eng / Reviewer 委派 + RACI | 每个角色名字 + 邮箱,不能写"TBD" |
| ② Lifecycle 活动 | Part 3-8 各阶段 work product 清单 + I/O 关系 | 推荐用表格,每行 work product + 输入 + 输出 + 责任人 |
| ③ 时间表 / 里程碑 | M3 / M6 / M9 ...,Confirmation + Audit + Assessment 节点 | 必须对齐项目管理 Gantt,否则审计员视为虚 |
| ④ 资源 | 人头 / 工具 / 预算(DOORS / Polarion / FI 工具 / FMEDA 表) | 每条 line item 必须有 budget owner |
| ⑤ Tailoring | 偏离标准条款必须逐条给理由 + Safety Mgr + Quality 联签 | Top NC 来源,绝不允许"打折省功" |
| ⑥ Confirmation | I1/I2/I3 Review 数量预估 + Audit / Assessment 时间窗 | ASIL D 项目 50+ Reviews,5-10 Audits,1 Assessment |
| ⑦ Reuse | SEooC / 上代项目 / Safety Manual 引用 + DIA 约束 | 复用必须有 reuse rationale,不能"贴文件名" |
living update 节奏:每月轻量回顾 + 任何 work product 重大变更 + Assessment 前 12 周冻结。
3. 角色 RACI
FSM 团队不只是"Safety Mgr 一个人",而是 7 类角色的协作:Safety Manager(单点问责)、Safety Engineer(执行)、Sys / HW / SW Lead(领域负责)、I3 Reviewer(独立性 ASIL D 必需)、Assessor(第三方 TÜV / exida)。
RACI 三条铁律:
- 每行 Accountable 只能 1 人(单点问责)。"两人联合 A" 是错误用法——审计员问 "Plan v1.4 关掉的人是谁?" 必须答得出来。
- R 可以多人(并行执行),A 必须唯一。
- I3 Reviewer 在 ASIL D 项目里占多数 A——他签字才算 work product 关闭,这是 Confirmation 独立性的核心。
典型组织规模(ASIL D 项目):Safety Mgr × 1 全职 + Safety Engineer × 2-3 + 每个领域 Lead 兼 25% 工时 + I3 Reviewer 池 5-8 人(从 OEM / 集团兄弟部门借)+ Assessor 第三方(TÜV / exida)合同制。
4. V-cycle 上 5 类 FSM 触点
FSM 不是"项目开始时签个 Plan 就完事",而是贯穿 V-cycle 全程。5 类触点缺一不可:
按时间:
| 触点 | 时机 | 关键决策 |
|---|---|---|
| ① Safety Plan 签发 | M0 | Safety Mgr + 项目总监联签 |
| ② Confirmation Review | 每 work product 完成后 | I1/I2/I3 等级匹配 ASIL |
| ③ Audit | M3 / M6 / M9 / M12 / M15 | 流程执行 NC 清单 + CAPA 跟踪 |
| ④ Interim + Final Assessment | M14-15 / SoP-3 | 第三方 TÜV / exida 判定合规 |
| ⑤ Release for Production(RFP) | SoP-1 | Safety Mgr 签发,缺一项不放 |
最贵的失误:Final Assessment 拖到 SoP 前 4 周启动 → TÜV 一旦标 Major NC,SoP 必推 3-6 月。M14-15 启动 Interim Assessment + 留 buffer 修复 是车规常识。
5. OEM-Tier1 DIA
Development Interface Agreement(DIA)是 OEM 和 Tier-1 之间的 functional safety 责任分割合同。Part 2 Annex C 给出必含条款,没有 DIA 的项目审计员直接判定不合规——分不清谁对哪个 work product 负责。
DIA 关键章节(简化版):
- 角色分配:谁做 HARA / FSC / TSC / 安全验证 / Assessment
- 接口与工件交付:HSI / 安全需求 / FMEDA / Safety Case 提交时间 + 格式
- 独立性安排:I3 Reviewer 谁出(OEM / Tier-1 / 第三方)
- 变更管理:谁批 Change Request,RFC cycle 时间
- Tool Qualification:谁负责 compiler / debugger / FI 工具的 TCL 评估
- Cybersec 协同:ISO 26262 vs ISO 21434 工件如何共享
- Field 反馈:量产后客诉 / 8D 走谁
- Safety Case 维护:SoP 后由谁更新
典型条款 trap:DIA 写"FMEDA 由 Tier-1 做",但漏了"OEM 提供整车级失效率数据"——结果 Tier-1 卡在 FIT 估算上,SoP 前 3 个月才发现需要 OEM 数据。
6. FSM 成熟度模型 5 级
按 TÜV / exida 成熟度审计的常见分级:
| 级 | 表现 | 典型规模 |
|---|---|---|
| Lv 1 — Ad-hoc | 有 Safety Engineer,无 Safety Plan,review 没固定 | 小公司 / first-project |
| Lv 2 — Defined | Safety Plan 有,但不 living;角色挂名;Confirmation 数量不达 ASIL 要求 | 中型 Tier-2 |
| Lv 3 — Managed | RACI 全签,Reviews 按 ASIL 匹配 I 等级,Audit 按里程碑跑 | 中型 Tier-1 |
| Lv 4 — Measured | KPI 跟踪(NC 关闭时间 / Review pass rate),Tailoring 逐条记录 | 头部 Tier-1 |
| Lv 5 — Optimizing | Safety Plan 跨项目模板化,Tool 自动化 RACI 检查,Field 反馈 → Safety Case 闭环 | OEM / 顶级 Tier-1 |
实战路径:从 Lv 1 升 Lv 3 通常需 12-18 个月 + 1-2 个完整项目的迭代。直接跳 Lv 4 几乎不可能——KPI 系统需要至少一个项目周期产生数据。
7. 5 类 FSM 失效模式
ASIL D 项目 Audit / Assessment 失败,最常见的 FSM 根因 Top 5:
- Safety Plan 不 living。M0 签了 v1.0 之后整个项目没更新,Final Assessment 阶段才发现 Plan 跟实际差几条 milestone——审计员判 "Plan 失控,FSM 不可信"。
- Tailoring 无理由。偏离 Part 5 某条要求,但 Plan 里只写"项目特殊,不适用",没给 ALARP 论证——Top 单一 NC 来源。
- RACI Accountable 多人。"Safety Plan A = Safety Mgr + 项目总监" 双签——审计员逼问"出问题找谁?"卡壳。
- DIA 模糊。"安全验证由 OEM 主导,Tier-1 配合"——边界没切清,Sa.Val 阶段双方都觉得对方做,最后没人做。
- Field 反馈机制为空。Plan 里没写量产后客诉怎么回 Safety Case——SoP 后 6 个月 OEM 抽查发现机制空转,触发 Recall 风险评估。
8. FSM 节奏 — 日 / 周 / 月
ASIL D 项目稳定运行后的典型 FSM 节奏:
| 频率 | 活动 | 持续 |
|---|---|---|
| 每日 | Safety Engineer 处理 work product / Review 排期 / NC 跟踪 | 全职 |
| 每周 | Safety Mgr 周会(Plan 状态 + NC 燃尽 + 风险登记) | 1 小时 |
| 每月 | Safety Plan v.minor 回顾 + Audit 准备 | 半天 |
| 每季 | Internal Audit(Org-level) + Tooling 复审 | 1-2 天 |
| 里程碑 | Confirmation 批次 + 阶段 Audit | 1-2 周 |
| SoP-3 | Final Assessment + RFP 准备 | 12-16 周 |
核心要点
- FSM = 三层管理:Org / Project / Production,缺一项审计员判不完整。
- Safety Plan 是项目章程,7 类必含,living document。
- RACI 三铁律:每行 A 唯一,R 可以多人,I3 Reviewer 在 ASIL D 项目占多数 A。
- V-cycle 5 类触点:Plan / Confirmation / Audit / Interim+Final Assessment / RFP。
- DIA 是 OEM-Tier1 责任合同,无 DIA 等同不合规;Annex C 必含 8 类条款。
- 成熟度 5 级,Lv1→Lv3 通常 12-18 月 + 1-2 个完整项目迭代。
- Final Assessment 必须 M14-15 启动,留 12-16 周 buffer 修复 NC。
- 5 类失效模式:Plan 不 living / Tailoring 无理由 / RACI A 多人 / DIA 模糊 / Field 反馈为空。
- FSM 节奏:日级跟踪 + 周会 + 月回顾 + 季 audit + 里程碑批量。
Cross-references
- ← 索引
- topic-iso26262-part2-management — Part 2 标准条款
- Safety Plan 写作工程化深度 — Safety Manager day-1 work 的 10 章模板 + Milestone + RACI + Tool list 写作 SOP(本页 §2 Safety Plan 的工程化展开)
- topic-functional-safety — 功能安全 hub
- topic-safety-assessment-audit — Confirmation / Audit / Assessment 三层独立检查
- topic-safety-case — Argument + Evidence,FSM 输出之一
- topic-safety-manual — Safety Mgr 签发的交付物
- topic-hsi-document — Plan 锁的 work product 之一
- topic-iso26262-part8-supporting-processes — Tool Qualification / TCL
- topic-iso26262-part10-guidelines — Application Guidelines