从零搭建基于 OpenClaw 的功能安全 Agent(7)系统安全分析 — FMEA & FMEA-MSR(上)

活动卡体系 · 规范全景 · 打分机制 

TSC 跑通之后，下一个自然的问题是：怎么证明这套技术方案已经将所有的失效场景都覆盖在内？当前所提出的安全需求已经足够了吗？是否有不必要的需求也被提在了TSC中？

想获得这些问题的唯一答案，就是执行系统安全分析。跟 TSC 不一样的是——TSC 是从需求到实现，方向确定，难在完整性。系统安全分析是反过来的：你不知道哪个接口会挂掉，不知道哪条失效链能穿透所有安全机制。需要逐接口穷举”什么会坏、坏了会怎样、能检测到吗”。

这一章（上）讲活动卡和打分。下一章（下）讲执行层——接口怎么分、结果怎么出、VR 翻车怎么修。

──────────────────────────────────────

一、FMEA & FMEA-MSR 要跑通哪些活动卡

跟 TSC 一样，FMEA 也是四张卡覆盖全链路。角色分工也相同——Manager VR、Head CR、Engineer 产出。

不同的是，FMEA 活动卡比 TSC 多了六条强制规则 R1–R6，直接写在活动卡里。不是”建议参考”，是”违反就 Fail”：

这六条规则是怎么来的？不是拍脑袋——每条背后都是一次翻车。

1.1 B.1a — 为什么专门设一个确认点 

活动卡 B.1a 写得很死：接口分类提交后必须暂停，等用户确认才能继续。B.1a 阶段甚至不做 VR——Manager 直接转发给 Head，Head 交给用户。

原因是接口分类一旦出错，整个 FMEA 就没法看了。接口类别决定了 FM 来源（P1/P2），FM 来源决定了后面所有分析的每一条怎么写。几十条写完了发现类别分错？全部重来。

分类阶段的产出格式也很固定——按要素分组，每接口一条：

1.2 全链路流程一图看清

五个阶段：B.1a 分类（用户确认）→ B.2–B.7 分析（Engineer 产出）→ VR 技术审查（Manager）→ CR 认可评审（Head）→ Excel 生成。中间任何一步都可以被用户打断纠偏。

──────────────────────────────────────

二、参考规范 —— FMEA 的”知识来源”

TSC 主要引 ISO 26262-4/5/8/9。FMEA 要多一层——它不光要 ISO，还要方法论手册和失效模式来源表。

2.1 三个层级的标准

2.2 每本规范干什么

2.3 Table 30 和 Table 36 — 最核心的两张表

这两个表决定了你的失效模式是完整的还是拍脑袋的。

Table 30 — 通信外设失效模式（SPI / CAN / I2C 全部适用）。

每类通信接口的同类别所有接口用完全相同的 FM 集。不能说 SPI 只取 FM1/FM4，I2C 加一个 FM3——同类别必须一致。

Table 36 — 关键子部分：

不是每个子部分的所有 FM 都要用——只取跟你接口类型匹配的子部分。

2.4 Table 30/36 不可读：interface-failure-mode-sources.md 补偿方案

前面和小伙伴们了分享使用MinerU来将PDF转换为maekdown，也分享了使用Qwen 3.7 Plus来进行图片识别的工作方法。

顺利部署并使用这两个工具并不容易：

1. MinerU本地部署需要运行在cuda环境下，且对于50系显卡的支持目前还有一些适配问题；

2. Qwen 3.7 Plus并不是免费的，价格也没有deepseek这么“实惠”，使用起来难免有一些心理负担。

在这个前提下，我建立了一个补偿机制——interface-failure-mode-sources.md：把 7 类接口的标准失效模式手动整理成一个 Markdown 文件，作为唯一的失效模式基线：

Cat 1 (Power Supply): Voltage Regulator 4 FM — OV/UV/振荡/漂移

Cat 2 (GPIO): HAZOP guide words — Stuck at/Open/Floating/Drift/Oscillation

Cat 3 (Analog): N-bit ADC 4 FM — Stuck high/Stuck low/Accuracy error/Noise

Cat 4 (Communication): Table 30 完整集 — COM_TX_FM1-4 + COM_RX_FM1-4

Cat 5 (PWM): HAZOP guide words

Cat 6 (Image Stream): 8 项专用 FM（非 Table 30 的 16 项通信 FM。图像流是连续像素数据流，不适用消息级失效模式。）

Cat 7 (Oscillator): Stuck/Frequency drift/Jitter

这个文件在 Agent 流水线中的角色：FMEA/FTA/DFA 活动触发时，Head 在预检阶段自动将其复制到项目的 reference/ 目录。Engineer 执行 B.2 时读取此文件确定每个接口的 FM 集，Manager VR 审查时也以此文件为基线核查 FM 完整性。

用户可以针对不同项目在项目级副本中修改 FM 集——但基线源文件不直接改动，既满足了根据不同项目的灵活适配，也保留了基线文件供新项目引用。

如果你在自己的项目中遇到类似问题（ISO 标准图片不可读或MinerU本地无法部署），建议也建立这样一个基线文件。

──────────────────────────────────────

三、FMEA + MSR 的表长什么样

先看图——这是 R4 强制要求的合并表结构，不是两张独立表：

一段拆两半：前半是 FMEA（列 1–12），回答”什么会坏、坏了会怎样、我们能检测到吗”。后半是 MSR（列 13–19），回答”我们加了什么监控、监控到了怎么反应、加了监控之后状态是什么”。

FMEA# 和 MSR# 编号相同，一一对应。前面翻车记录里最常见的 5 个翻车项之一就是 MSR 被写成独立章节——Manager VR 看到这个直接判断 R4 违规。

3.1 三列推理链：Effect → Mode → Cause

FMEA 表的核心推理链就三列：

Effect 自底向上看，Cause 自顶向下看，交汇在 Mode。这三列的关系如果写反了（比如把 Effect 写成 Cause），Manager VR会直接判定Fail——R3 规定了 FM 必须来自权威来源，不能是自己推导的。

──────────────────────────────────────

四、七步怎么走——AIAG & VDA 方法论

Engineer 活动卡 B.2 不是”建议按 7-Step 执行”，而是直接把 7-Step 写进了执行流程：

七步里最容易翻的是 Step 1 的 5T。5T 不是走形式——它定义了本次 FMEA 的边界和目的：

Step 4 和 5 是核心——失效分析和风险评分，也最容易出问题。

──────────────────────────────────────

五、打分怎么打

FMEA 有两套打分体系。DFMEA 用 S/O/D，FMEA-MSR 用 S/F/M。两套体系维度不同，但最终都汇成 Action Priority（AP）。

5.1 DFMEA — S 打分策略

Severity (S)：失效有多严重？

R5 是硬规则：任何可能违背安全目标的 FM，S=10。没商量。

S=10 不代表”灾难”，只代表”这个 FM 瞄准了安全目标”。即使检测覆盖率 99.9%，S 不变——检测有效性通过 D 来体现。

5.2 FMEA-MSR — S / F / M 三维

MSR 的打分逻辑跟 DFMEA 不同——它问的是”加了监控之后的状态”：

同一个失效，DFMEA 里 S=10，MSR 里如果监控做得好，S 可以降到 8。

5.3 AP 怎么定

AP 不是 S×O×D 乘积。AIAG & VDA 用的是三维优先级矩阵：

S=10 + O>=3 + D>=3→ AP = H（必须行动）

S=10 + O=2 + D=1~2** → AP = M（应该行动）

S=2 → AP = L（QM 功能，记录即可）

H 和 M 项要定优化措施——具体动作、负责人、截止日期。L 项不强制。

──────────────────────────────────────

六、总结

方法论层面的东西都在这里了——四张卡的分工、六条强制规则怎么来的、三本标准体系的分工、Table 30/36 怎么用、AIAG & VDA 七步怎么走、DFMEA 和 MSR 两套打分体系怎么区分。

下一章（下）进入执行层：接口怎么分类、P1 和 P2 怎么判断、FMEA+MSR 怎么产出、Excel 怎么生成、VR 中 Top 6 翻车项以及修复策略。

──────────────────────────────────────

Next: Part 8 — 系统安全分析：FMEA & FMEA-MSR（下）

────────────────────────────────────────

© 2026 本文档内容受知识产权保护，未经作者许可，严禁以任何形式转载、复制或用于商业用途。