一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(9)FMEA & FMEA-MSR 实操技巧篇(Hermes&Open Claw全兼容)-夜雨聆风

一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(9)FMEA & FMEA-MSR 实操技巧篇(Hermes&Open Claw全兼容)

FM 识别 · Cause 定义 · Effect 推导 · 上下文管理 · B.1a 本质 · 活动卡体系

前两章讲完了方法论和打分，又用真实数据走完了执行层。这一章换个角度——不讲”怎么做”，讲”怎么做对”。

这些技巧不是某个项目的专属经验，是从多轮 FMEA 执行、几十次 VR 翻车、几百条 Cause 修正中提炼出来的——换一个项目、换一个架构，它们一样适用。

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

一、技巧一：怎么正确识别失效模式（FM）

FMEA 的质量从 FM 定下来的那一刻就基本确定。FM 定错了——后面 Cause 白写、Effect 白推、AP 白算。

1.1 FM 来源三阶梯，不要自己编

FM 只有一个合法入口：标准。任何”我觉得这个接口可能会 xxxx”都是错误的。

三阶梯从权威到工程：

第一阶梯——IC 安全手册（P1 元件专用）。如果你分析的是 MCU、OSD IC、TDDI IC 等有安全手册的元件，FM 从手册里取。手册里说 GPIO 有哪些 FM 就用哪些，不要自己加。如果手册只描述检测机制没列 FM（比如 MCU I/O Port Diagnosis 管所有 GPIO），就从接口功能推导 FM，但 Detection 列引用手册中的机制。

第二阶梯——ISO 26262-11 Table 30/36（P2 元件主力）。通信外设看 Table 30，模拟/电源/振荡器看 Table 36。这两张表是 FM 的”官方字典”——不在表里的 FM，要么你理解错了接口类型，要么这个失效场景不存在。

第三阶梯——HAZOP guide words（GPIO/PWM 等通用数字接口的 P2 兜底）。丧失、多于预期、少于预期、方向相反、非预期激活、卡滞。六个词覆盖所有数字 I/O 失效形态。

1.2 同类别同 FM 集，一个都不能少

有一条铁律：同类别所有 P2 接口必须用完全相同的 FM 集。Cat 2 的 A 接口用了 6 个 HAZOP guide words，B 接口就也得是 6 个——不能说 B 接口”那俩 FM 用不上”就删掉。不适用就显式标注”N/A — 原因”。

这个规则不是追求形式整齐——VR 会逐类检查。Cat 2 有 18 个 GPIO 接口，只要有一个少了一个 FM，Manager 直接判 R3 违规。真实案例：Des_LOCK 用了 5 个 HAZOP words，Des_PASS 只用了 3 个——VR 抓出来了。

1.3 Cat 4 通信接口记住两条：双向 + Table 30 四组 FM

通信接口（I2C/SPI/CAN 等）是 FMEA 里最容易漏分析的一类，因为大部分人下意识只分析输出方向。但标准要求双向——TX 和 RX 两端各一行，各自独立分析。

Table 30 定义了四组 FM：COM_TX_FM1～FM4 用于发送端，COM_RX_FM1～FM4 用于接收端。SPI TX 行用 TX 组，SPI RX 行用 RX 组——两组 FM 描述不同，不能混用。

一条实用的自检：B.1a 提交前，grep Cat 4 的 TX 和 RX 条目数，必须相等。每条总线的 TX 和 RX 必须配对。

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

二、技巧二：怎么正确定义失效原因（Cause）

FM 回答”什么会坏”，Cause 回答”为什么会坏”。Cause 写不好有三个常见病：太细（越级到 IC 内部）、太散（同 FM 不同 Cause）、太快（传递链路跟 FM 对不上）。

2.1 三段式编号——Cause 列就这一个格式

1. 输出端IC 故障：[元件名] 故障 — [功能表现] 2. 传递链路：[链路类型] 异常 — [功能表现] 3. 接收端IC 故障：[元件名] 故障 — [功能表现]

三段涵盖了从源到目的地的完整故障传播路径。具体写法示例：

# GPIO 输出常高 1. 输出端IC 故障：MCU GPIO 故障 — 持续输出高电平 2. 传递链路：引脚对 VDD 短路 — 强制拉高 3. 接收端IC 故障：接收端 IC 收到不应有的高电平 — 误判为有效信号 # SPI TX 消息丢失 1. 输出端IC 故障：发送端 IC 故障 — 消息未发出 2. 传递链路：SPI 总线信号中断 — 数据未到达 3. 接收端IC 故障：接收端 IC 故障 — 未收到预期消息

不涉及的段标 `—`。比如电源输出接口没有”接收端 IC 故障”的概念——第三段写 `—`。

2.2 系统级锁死——别跨过硬件安全分析的边界

FMEA 是系统级活动。IC 内部的故障机理——电容短路、晶体管开路、寄存器翻转——这些留给硬件 FMEDA。FMEA 的 Cause 只描述到元件功能失效层面。

❌ 越级（留给 FMEDA 的）	✅ 系统级
MCU GPIO 输出驱动管开路	MCU GPIO 故障 — 无输出信号
电压调节器反馈电阻网络开路	电压调节器 IC 故障 — 输出电压升高
发送端 TX FIFO 溢出	发送端 IC 故障 — 消息未发出
时钟源晶振断裂	时钟源 IC 故障 — 无时钟输出

一条经验规则：只要你的 Cause 里出现了电容、电阻、晶体管、寄存器、SEU、FIFO、PLL 这些词——判断越级了，往上提一层。

2.3 传递链路必须跟 FM 物理一致

这是最容易犯的错——从模板里复制了 Cause 描述，但传递链路跟 FM 互斥。典型案例：

FM = 输出常高→ 传递链路：”开路” ❌开路导致丧失，不是拉高 FM = 输出常高→ 传递链路：”对 VDD 短路” ✅FM = 输出丧失→ 传递链路：”对 VDD 短路” ❌FM = 输出丧失→ 传递链路：”开路” ✅

一条自检：读完 FM 名字后问自己”这个失效在物理上是怎么发生的”，然后看传递链路那一段是否跟这个物理图景一致。不一致就改——不要因为模板里写的是”开路”就照搬。

2.4 同 FM 必须同 Cause——不要逐行”重新思考”

同一条 FM（比如”COM_RX_FM4: message masquerading”）在不同接口上出现时，Cause 必须完全一致。Agent 逐行生成会产生一个现象：F302 和 F326 同为 COM_RX_FM4，Cause 却写成两套不相关的故障描述。

这不是 Agent 的错——是约束没给到。对策：建立 Cause Lookup Table，每个 FM 对应一条标准 Cause 模板。P2 接口全部从表中取，P1 接口用安全手册覆盖对应段。VR 检查时逐 FM 核对 Consistency。

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

三、技巧三：怎么正确推导失效影响（Effect）

Effect 是 FMEA 表里最长的一列——它要回答”这个失效最终对驾驶员意味着什么”。Effect 写浅了等于没分析，写错了会误导 AP 判定。

3.1 四级链——Effect 不是一个结果，是一个因果链条

L1: [FM 表现] → L2: [局部失效影响] → L3: [系统级功能影响] → L4: [驾驶员/车辆影响] → L5: [SG 判定] 每一层一个 `→`。有效链长 3～5 次跳转。太短（2 跳）说明你没追到终点，太长（6+ 跳）说明你掺了不必要中间状态。

实例：

# 不跳层、追踪到 SG 3V3 输出过压 → 下游 IC 承受过压永久损坏 → 全系统功能丧失 → 无安全图标显示 → [SG: OTA_SG01 violated] # 跳层了——中间元件被跳过 3V3 输出过压 → 无安全图标显示 ❌

3.2 起点固定 + 终点三态判定

Effect 的起点（这个 FM 发生在哪个接口、接口的源端和目标端是谁）由 B.1a 锁定，B.2 不推翻。终点必须是 SG 判定——且是三态之一，不是模糊的”有安全影响”：

·`[SG: xxx violated]` — 确认违背安全目标

·`[SG: xxx not violated]` — 确认不违背（需要因果链证明为什么不违背）

·`[SG: xxx 待确认]` — 信息不足无法判定（列在 Open Items）

“无影响”也需要完整因果链。不能简写成”无影响”三个字——必须给出推导过程证明它真的无影响。

3.3 元件名具体化，不写”下游 IC”

Effect 链里不能用”下游 IC”这种模糊表述。架构里有具体元件名——MCU、OSD IC、TDDI IC、Deserializer——就用它们。换个项目、换个架构，元件名换了，Effect 链跟着换。这条也适用于 Cause——三段式里的”输出端 IC”要替换为具体元件名。

3.4 Effect 推导最常踩的坑

第一坑：把检测机制的缓解效果写到 Effect 里。Effect 问的是”如果没有任何检测，这个失效会导致什么”——跟有没有 E2E、有没有看门狗没关系。检测有效性通过 D &M列体现。

第二坑：在一个无安全影响的接口上推导出了 SG 违背。比如背光亮度 PWM 上了 110% 占空比——驾驶员看到屏幕更亮了，但没有安全图标丢失。这时候 Effect 链追到 L4（驾驶员感知到亮度异常）后，L5 应该判 `[SG: xxx not violated]`。

第三坑：Effect 停在中间元件不再往下追。通信接口最常见——Effect 写到”OSD IC 收到错误配置数据”就停了。它收到错误数据之后呢？配置错了会导致什么？图标不更新？安全图标丢了？继续追。

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

四、技巧四：怎么在查文档的同时避免上下文溢出

FMEA 需要参考的文档量很大——ISO 26262-4/5/9/11、AIAG & VDA Handbook、FMEA Cause Lookup Table、Effect Charter、接口失效模式基线、项目架构图、FSR 表、TSR 表……单是 ISO 26262-11 一个文件就轻松超过 100KB。

如果把这些全部灌入 Agent 的上下文，只有一个结果：超时。deepseek-v4-pro 子 Agent 处理 50KB+ 的单文件就进入超时风险区——已验证数据：10～13 接口 FMEA 行耗时 320～452s，600s 硬超时近在咫尺。

以下是在不牺牲分析质量的前提下控制上下文大小的四个技巧——每个都来自真实执行教训。

4.1 P1/P2 预判定——不把整个安全手册灌给 Agent

P1（有安全手册的 IC）和 P2（无安全手册的元件）的判定不需要 Agent 读安全手册来做——调度者（Head）提前判好，用短列表传入：

P1: MCU, OSD IC, TDDI IC P2: Host System, Deserializer, ROM Flash, Backlight Driver, PMIC

Agent 收到这个列表后，P1 接口就知道要按安全手册路径处理，P2 接口走标准化 FM 集。不需要掏几十 KB 的安全手册全文。

4.2 规则预注入——不让 Agent 自己去发现规则

FMEA 活动卡里有 R1～R11 共十一条强制规则。如果只给 Agent 一个活动卡路径让它”自己读”——它能读，但读完生成时不会逐条遵守。因为在逐行生成 Cause 和 Effect 时，上下文里的规则会被生成压力挤掉。

对策：分派 Agent 时，在 context 里直接注入规则的压缩版（不是全文，是速查清单）：

R5: S 值依据 FSR→违背类型→Table D1 五级映射 (10/8/6/5/4)。禁止二值化”违背SG→S=10″ R7: Effect 追踪到 SG 终点 + [SG:xxx] 标注 R8: Cause 三段式，系统级锁死，同 FM 同 Cause R9: Effect 四级链 L1→L5，不跳层，元件名具体化 R10: MSR 仅用 TSR 已声明机制；无 TSR→DC=N/A, D=10, M=10

十条规则压缩后不到 1KB 上下文开销，但能避免大量格式违规。

4.3 大文件预消化——两级压缩法（97% 压缩比验证有效）

当输入文件超过 100KB 时，不要直接把原文灌给 Agent。用两级压缩：

第一级——方法论文档→模板映射：把指南/Handbook 等长文档按模板页逐页提取方法核心，输出每个模板页”做什么、参考哪条标准”的精简版。99KB 的指南可以压缩到 ~4.5KB。

第二级——架构文档→结构化提取：按子功能拆解架构，逐路径提取触发信号、数据流、安全机制。209KB 的架构可以压缩到 ~5.4KB。

Agent 用摘要工作，只在需要核验某个具体接口的时序或信号名时，才用 read_file(offset, limit) 回读原始文件的具体小节。

4.4 大任务分批 delegate——不要一次喂太多

如果 FMEA 全量有 40+ 接口 300+ 行，不要一次 delegate。按元件/子系统拆成 3～4 批，每批 10～13 接口。每批给 Agent 只发它负责的那段——不给全量 FM 列表，不灌全量架构。

真实验证数据：46 接口 350 行拆 4 批，每批耗时 319～452s，全部在 600s 超时内完成。如果一次 delegate 全部 46 接口，必超时。

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

五、B.1a 活动——FMEA 里最被低估的一步

B.1a 在活动卡里就一段话，但它决定了整个 FMEA 的分析边界。它的本质不是”做分析”，而是”锁基础”。

5.1 B.1a 到底在干什么

一句话：把架构里每个输出和通信接口找出来，逐条确定——这个接口是什么类型（Cat 1～7）、信号从哪来到哪去、功能是什么。

产出就一张表。每行一个接口：

IF#	接口名称	Cat	方向	源端 → 目标端	功能描述
IF01	3V3_OUT	1 (Power)	输出	PMIC → MCU/OSD	3.3V 主供电，额定 500mA
IF02	SPI_CSIH	4 (Comm)	TX	MCU → OSD IC	图标位图数据和寄存器配置命令
IF08	LVDS_A	6 (Image)	输出	TDDI IC → TFT_LCD	四通道 LVDS 仪表显示画面

5.2 B.1a 为什么必须设一个确认点——不设会出什么后果

B.1a 之后用户必须确认才能进 B.2。这不是流程繁琐——是代价计算。接口分类如果出错，后面 300+ 条 FMEA 行的每一条都会歪。

真实教训：TFT_Fail 归属归错了——归给了 TFT_LCD 而不是 TDDI IC。这个错误如果带到 B.2，所有 TFT_Fail 相关的 16 条 FMEA 行的 Cause 和 Effect 全部要返工。

B.1a 阶段改一行分类表只要 30 秒。B.2 阶段改同样一个错误要重写 16 行。

5.3 B.1a 不做什么

有一个误区是把 B.1a 当成”预先分析”步骤——给它加上 Downstream Impact 列、预判 Effect 链、预分配 S 值。

B.1a 只做三件事：

·接口分类（Cat 1～7）

·接口方向锁定（源端 → 目标端）

·功能描述

不做 Effect 推导，不做 S 值分配，不做影响链路预判。这些是 B.2 的工作。

理由很直接——B.1a 的数据基础只是架构图。你需要看到完整的失效模式和 Cause 才能准确判断 Effect。就跟你不可能只看医院平面图就诊断病情一样——你还需要检验报告。

5.4 不确定怎么办——列出并逐个向用户询问，绝不瞎猜

B.1a 分类时对接口属性不确定的——方向、Cat 编号、信号归属、源端目标端——逐条列出提交用户确认。不要猜。猜错一个信号归属就是 16 行返工。猜对是侥幸，猜错是常态。

常见的需要确认项：信号名相同但出现在多个元件上的接口（LVDS 出现在 TDDI 和 TFT 两端——源端是谁？）、信号名暗示方向但实际方向相反（DSI_INT 看起来是 Des 中断输出，实际可能是 MCU 触发的输入）、通信总线是同一条物理链路的透传还是两条独立总线。

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

六、活动卡体系——三角色怎么分工

FMEA & FMEA-MSR 流水线由三个角色、四张活动卡覆盖全链路。下面的描述不绑定具体项目，任何 ISO 26262 系统级安全分析活动都适用这套分工。

6.1 Engineer 活动卡——产出分析

Engineer 是唯一产出分析内容的角色。它的活动卡直接定义了 B.1a（接口分类）和 B.2（FMEA 分析）的执行流程。

B.1a 段规定了：

·扫描架构所有要素的输出和通信接口

·逐接口判定类型（Cat 1 Power / Cat 2 GPIO / Cat 3 Analog / Cat 4 Communication / Cat 5 PWM / Cat 6 Image Stream / Cat 7 Oscillator）

·确定 P1/P2 归属（P1 = 有安全手册的 IC，P2 = 无安全手册的元件）

·为每个接口补充功能描述（信号名自描述的简写，有歧义的必须完整描述）

·对 Cat 4 通信接口执行双向分类（TX + RX 各一行）

·暂停，提交确认——不继续 B.2

B.2 段规定了：

·按 AIAG & VDA 7-Step 方法论执行完整分析

·读取 B.1a 确认表，锁定接口分类和功能描述

·P1 接口从安全手册取 FM，P2 接口从标准源取 FM

·逐接口生成 FMEA + MSR 合并行（FMEA 段在前，MSR 段在后）

·遵守 R1～R11 全部强制规则

6.2 Manager 活动卡——VR 技术审查

Manager 不产出内容，只审查 Engineer 的交付物。VR 活动卡的核心是检查清单——逐项对照标准要求和活动卡规则。

FMEA 的 VR 检查项包括但不限于：

·范围完整性——架构中所有要素是否全部覆盖（R1）

·接口方向——是否排除了输入接口（R2）

·FM 来源合法性——P1 是否引用了安全手册、P2 是否使用了标准源（R3）

·表格结构——FMEA 和 MSR 是否在同一行、DC 是否在 MSR 段（R4）

·S 值判定——是否按 FSR→违背类型→Table D1 五级映射、是否存在二值化（R5）

·DC 值来源——是否标注了 Annex D 依据或安全手册章节（R6）

·Effect 完整性——是否追踪到 SG 终点并标注 [SG:xxx]（R7）

·Cause 一致性——同 FM 是否同 Cause、三段式是否完整、系统级锁死是否遵守、传递链路与 FM 物理逻辑是否一致（R8）

·Effect 四级链——是否逐级推导不跳层、元件名是否具体化（R9）

·MSR 机制来源——是否全部来自 TSR 已声明机制、无 TSR 是否标记（R10）

Manager 返回 VR 报告：✅（通过）/ ⚠️（Flag）/ ❌（不通过）。不通过项必须修复后重新 VR。

6.3 Head 活动卡——CR 认可评审与调度

Head 是总控。它做三件事：

·调度——将任务分派给 Engineer 和 Manager

·汇总——将 VR 结果上报用户

·CR 认可评审——在 VR 通过后、交付前，做最后一道技术审查

Head 的 CR 检查项侧重在交付物的完整性和自洽性：

·文件结构是否完整（Planning → Structure → Function → Per-Element → Summary 五段齐全）

·Summary 自检计数是否与实际一致（FMEA 条目数 = MSR 条目数 = grep 出来的行数）

·上下游一致性——输入需求到输出满足没有矛盾

·假设是否明确陈述

·AP 分布和 SG 覆盖矩阵是否合理

Head 不亲自修改任何产出文件。CR 发现的问题列成”不符合项清单”→ 派回 Engineer 修改 → Manager VR 复查 → 循环到通过。

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

七、这些技巧的通用性边界

七个技巧全部设计为项目无关——但有一条前提：你走的是 ISO 26262 系统级 FMEA（AIAG & VDA 7-Step 方法论），且你的分析对象是嵌入式系统的硬件-软件接口边界。

如果你的分析不涉及通信接口（全部是纯机械结构），Cat 4 双向技巧不适用——但 Cat 4 本身就不在你的分类表里。如果你的元件全有安全手册（全是 P1），P1/P2 分级技巧退化为”P1 全覆盖”，其他技巧完整保留。如果你的 FMEA 规模很小（10 个以内接口），分批技巧不触发——不需要分。

这些技巧不是”必须全部照做”的绝对规则——是在你遇到对应问题时可以立刻用的解法。每一条背后都有一到两次翻车记录，翻车的项目不同、架构不同、问题本质相同。

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

八、总结

六个实操技巧——FM 怎么识别（三阶梯 + 同类别一致性 + Cat 4 双向）、Cause 怎么写（三段式 + 系统级锁死 + 物理一致性 + 查表去重）、Effect 怎么推（四级链 + SG 三态 + 元件具体化）、上下文怎么控（P1/P2 预判定 + 规则预注入 + 两级预消化 + 分批 delegate）、B.1a 的本质（锁基础不锁分析 + 不确定就问 + 不过度复杂化）、三角色活动卡体系（Engineer 产出 → Manager VR → Head CR 全链条）。

这些技巧不依赖具体项目架构——7 类接口、P1/P2 分级、三段式 Cause、四级 Effect 链、四卡流程，换了项目这些结构不变。

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