从零搭建基于 OpenClaw 的功能安全 Agent(8)系统安全分析

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

接口分类 · FM 确定 · Excel 导出 · VR 翻车与修复 · 可复用技巧

上一章讲完了活动卡和打分机制。这一章下到执行层——用真实项目数据把每一步拆开。

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

一、接口怎么分类——7 类分组 + P1/P2 两级

1.1 分类决策流程

从架构图到分类表，逐接口走一遍：

每一步都有明确的规则：先看方向（排除输入）、再看类型（7 类选一）、最后查文档（P1 还是 P2）。

1.2 7 类接口对照表

前一章节提到过，先对接口类型做分类，并将活动定义在活动卡B.1a中，活动卡 B.1a 定义的 7 类，每类对应一个标准化 FM 来源：

Cat	类型	典型接口	FM 来源
1	Power Supply	3V3_OUT / 1V5_OUT / 12V Rail	Table 36 Voltage Regulators
2	GPIO	OSD_Fail / TFT_Fail / Des_LOCK	HAZOP guide words（有文档则 P1）
3	Analog	NTC± / 3V3_AD / 1V5_AD	Table 36 N-bit ADC
4	Communication	SPI CSIH / CAN Tx / I2C	Table 30 Communication Peripheral
5	PWM	BL_PWM	HAZOP guide words
6	Image Stream	LVDS_A/B Output	Table 30（类比通信外设）
7	Oscillator	时钟输入	Table 36 Oscillator

真实项目里 xxxx cluster 搞了 42 个接口：7 个电源、18 个 GPIO、6 个模拟、6 个通信、1 个 PWM、4 个图像流。

（若其他项目中有超出本章节介绍的接口类型，可按照同样方式进行添加）

1.3 Cat 4 Communication 双向分析 — 最容易漏的强制规则

Cat 4（Communication — I2C/SPI/CAN）有一个 ISO 26262-11 Table 30 强制要求，但活动卡 B.1a 最容易被忽略：通信接口必须双向分析，TX（发送）和 RX（接收）各占一行、各独立分析 FM。

实战翻车：示例项目中的 B.1a 初始版本只分析了 MCU 端的输出方向（TX），漏掉了所有接收方向（RX）。审查时直接发现 “Communication中TX 和 RX 数量不一致”——TX=5, RX=2，三条总线的接收方全部遗漏。

修复规则很简单：B.1a提交前永远用一条命令做平衡检查——Cat 4 的 TX 条目数必须等于 RX 条目数。每条总线必须 TX+RX 配对（例如 I2C MCU↔Des 1TX+1RX、SPI MCU↔OSD 1TX+1RX、SPI OSD↔ROM 2TX+2RX）。不满足就说明有总线缺失方向，补齐后再提交。

注意：Cat 2（GPIO）和 Cat 6（Image Stream）不需要双向分析。只有通信协议接口（I2C/SPI/CAN/FlexRay 等）适用此规则。

1.4 信号透传

架构描述中，同一条 I2C/SPI 总线可能穿越多个元件。比如 Deserializer 架构中同时出现了 “Des_I2C ↔ MCU” 和 “Data transmission & I2C ↔ HOST”——看起来是两条 I2C，实际上是同一条物理链路：HOST→Des→MCU，Des 在中间只做透传。

如果把它们当成两条独立总线分别建 IF 分析 FM，相当于把一条链路的失效重复分析了两遍，而且分析出来的 Effect 会错位——Des 侧的分析会误判信号归属。

正确的做法：逐条确认 “此 I2C/SPI 是独立总线还是上游链路的透传？” 透传链路不单独建 IF——整个链路的 FM 分析在一对 TX+RX 中完成。

但这方案不一定适配所有的通讯链路，最好的解决方案是，将分析意图向用户直接汇报，并由用户直接确认。

1.5 Cat 4 B.1a 信号归属确认

实战案例中我曾经遇到过几次信号归属判定的错误，仅仅依据架构图AI无法准确的识别每个信号的归属接口，如果在分析前期无法准确识别，很有可能会导致整个分析结果的错位。

这里展开说一下怎么系统性地避免。

信号归属问题的根源是：架构中同一个信号名可能出现在 3-4 个不同元件中——谁是源端？谁是目标端？哪个元件负责生成这个信号？哪个元件只做转发？

B.1a 分类阶段，每个接口必须确认三个属性后才能列入分类表：（1）源端元件是谁？（2）目标端元件是谁？（3）信号性质（电源/GPIO/模拟/通信/PWM/图像/振荡）？

不确定的接口属性逐条列出提交用户裁定——不要猜。猜错一个归属，B.2 中 100+ 条分析的 Effect 列就全偏了。

1.6 P1 vs P2 —— FM 从哪来

P1（有文档 IC）：MCU、OSD IC。FM 从安全手册里取。但不是每个 P1 接口的安全手册都直接把 FM 列出来——有的只描述检测机制。比如 MCU 的 I/O Port Diagnosis 管所有 GPIO，但不列每个 pin 的 FM。这种情况下，FM 从接口功能推导，但 Detection 列引用 MCU 的检测机制。

P2（无文档）：Host System、Deserializer、ROM Flash、Backlight Driver 等没有安全手册的要素。P2 的铁律是：同类别所有接口用完全相同的 FM 集。不能说 Cat 2 的 A 接口用了 5 个 HAZOP guide words，B 接口只用了 3 个——VR审查时会直接判定为Fail。

1.6 一个典型 P2 接口的 FM 展开

以 Cat 3 Analog 的 NTC± 为例，Table 36 N-bit ADC 标准 FM 集是 4 个：

FM	含义	在这个接口上的表现
Output stuck high	ADC 卡死在高位 → 开路	MCU 读到温度上限 → 假过热 → 安全状态
Output stuck low	ADC 卡死在低位 → 短路	MCU 读到温度下限 → 过热未检测
Accuracy error	读数整体偏移	温度系统偏差 → 阈值判断错误
Spikes / noise	读数震荡	温度噪声 → 假过热触发

同一个 4-FM 集对所有供电AD采样接口全部复用。差异在 Effect 列——同一个 FM 在不同接口上的系统影响不同。

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

二、分析结果怎么出

2.1 MD 报告结构

FMEA & FMEA-MSR 的 MD 报告按 7-Step 组织，约 1000 行。完整结构：

Per-Element 分析表是核心——根据架构中的每一个要素，逐个展开。每个要素一节，所有接口的 FMEA+MSR 全部跟在后面。

2.2 安全功能链一张图

这个图不光好看——它在 FMEA 执行中有实际用途。看这条链，你能直观判断：哪个节点断了会影响哪些下游、哪个节点的检测依赖哪个上游、MCU 和 OSD IC 之间有多少条交叉检测路径。

实战中 FMEA 发现的两个关键设计问题都来自这张图的推理：

Des_LOCK 如果卡在 HIGH → OSD IC System Fail 是下游独立检测 → 不依赖 Des_LOCK

FAIL_DET 如果卡在 HIGH → MCU 还通过 SPI 轮询 OSD IC 状态 → 第二条路径

2.3 Excel 怎么生成

Excel 是 Head 在 CR 通过后生成的，Engineer 不管这事。`generate_fmea_excel.py` 从 MD 表里解析数据，输出 5 个 sheet：

Sheet	内容	行数
DFMEA	完整 FMEA 表	350+
FMEA-MSR	完整 MSR 表	350+
Optimization	优化措施清单	~6
Summary	统计摘要 + AP 分布 + SG 覆盖	–
Open Items	开口项列表	~5

格式细节：H 项红底、M 项黄底、L 项绿底、S=10 额外标记、表头蓝色白字。解析脚本踩过的坑——正则把 Summary 表里的 FMEA-MSR 声明行当成数据行匹配、占位符 `MSR-xxx` 残留导致计数虚高。每次 Excel 生成完必须核对 MD 末尾 Self-Check 表的声明数。

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

三、VR 中最常见的翻车项及怎么修

这部分内容全来自真实 VR 记录。基于两个项目实例，审核出来的问题高度一致。

翻车 1：MSR 独立成章

现象：Engineer 把所有 MSR 写成一个独立的 `## MSR Analysis` 章节。FMEA 在 §4，MSR 在 §5。Manager 无法核实哪条 MSR 对应哪条 FMEA。

判定：R4 违规。

修复：把每条 MSR-xxx 挪到对应 FMEA-xxx 下面，一行 FMEA 紧跟一行 MSR。修起来费力——350+ 条要一条条对位——但改完之后后续版本不会再犯。

翻车 2：S=10 被打破

现象：某条 FMEA 的失效模式明显可能违背安全目标（比如 MCU SPI 数据损毁导致错误图标 → SG 违背），但 Engineer 评了 S=8。理由是”E2E 检测能拦住，实际影响没那么严重”。

判定：R5 违规。S 描述失效模式本身——”如果没有检测会怎样”——跟有没有检测机制没关系。

修复：改回 S=10。同时检查 D 值是否合理——这个错误常见于 Engineer 把 mitigation 效果往 S 列塞而不是往 D 列塞。

翻车 3：同类别 P2 接口 FM 集不一致

现象：Cat 2 GPIO 接口中，Des_LOCK 用了 5 个 HAZOP guide words，Des_PASS 只用了 3 个。Engineer 说”那几个 FM 在这个接口上用不上”。

判定：R3 违规。P2 强制：同类别所有接口必须用完全相同的 FM 集，不适用也要显式标注 N/A 并说明理由。

修复：补齐缺失 FM，标注为”N/A — 此接口只有 ON/OFF 两个状态，不存在 Part of 情况”。

翻车 4：接口数量不一致

现象：分类表 42 个接口，FMEA 报告实际分析了 40 个。少了 2 个——Engineer 说”那两个不重要”。

判定：R2 违规。分类表多少接口就意味着多少接口要分析。数量不一致直接 Fail。VR 必须逐接口点数。

修复：补齐缺失接口的全量 FMEA+MSR 条目。两个接口 × 4 个 FM × (FMEA + MSR) ≈ 16 条——不是小改动。

翻车 5：DC 值不标来源

现象：DC 列写了 High (99%)，但没说是从哪来的。Manager 无法判定这个值是否合理。

判定：R6 违规。每个 DC 要标来源——P1 标文档名+章节，P2 标 Annex D 表格号。

修复：在 DC Claim 列补标注。比如 `DC=High (99%) per ISO 26262-5 Annex D, Table D.4 — E2E Communication Protection`。

翻车 6：声明数跟实际数对不上

现象：报告末尾 Self-Check 写”FMEA 条目 350+”，实际 grep 出来只有 300。Engineer 改了几条之后忘了更新计数。

判定：交付物完整性。声明跟实际不符，过。

修复：逐条核对，补齐缺失，更新 Self-Check。这个最容易被忽视——因为内容没问题，仅仅是”数错了”——但提交审查时这会直接导致退件。

修复对照表

翻车项	修改范围	是否连锁
MSR 独立成章	结构调整，内容不变	否
S 值不对	S→10 + 重算 AP	是
FM 集不一致	补齐缺失 FM + 新增 FMEA/MSR 条目	是
接口遗漏	新增全条 FMEA + MSR	是
DC 缺来源	只补标注	否
计数不一致	补齐或修正	可能有

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

四、可复用技巧

真实踩完两轮 FMEA 之后总结的——每条都能省时间。

4.1 永远不跳 B.1a

B.1a 分类确认是最便宜的改错时机。分类一错，全盘重来。B.1a 阶段 Manager 不做 VR——收到就转给 Head。这个规则写在 VR 活动卡 Lesson 4 里。

4.2 Manager 下发任务时不自创规则

Manager 向 Engineer 发 task，写的必须是”按活动卡 Path B 执行，路径：xxx”，不要自己在 task 里写简化版 R1-R6。一旦 Manager task 里的规则跟活动卡原文不一致，Engineer 可能用 task 里不完整的规则替代活动卡——跳过 B.1a、漏掉 R4、MSR 不在对位置。Manager VR Lesson 1 记录了这个教训。

4.3 接口修改时查四列一致性

用户要求改一个接口的属性（比如 ASIL 从 QM(B) 升到 ASIL B），不是只改 ASIL 那一列就完了。Signal 列、Mechanism 列、Notes/Effect 列全要查——四列是联动的。MEMORY.md 里专门记了这条。

4.4 FMEA 跟 TSC 是双向的

FMEA 用 TSC 里的安全机制做检测和控制。如果 FMEA 发现某个接口没机制覆盖——不要自己在 FMEA 里发明一个。标为 Gap，反馈回 TSC。反过来，TSC 修改后（新增或删除了安全机制），所有引用该机制的 FMEA 条目都要重新检查。

4.5 Lesson 闭环

每次跑完 FMEA，Engineer 的 lessons 文件自动更新。两次实战沉淀的核心：

Lesson 1：FM Source 必须来自源端。接收方检测机制放 DC 列，不混到 FM Source 里。

Lesson 2：提交前自检三重一致——分类表接口数 = 报告中分析接口数 = Self-Check 声明数。

这两条下次活动执行前 Engineer 先读，确保不重复犯错。

4.6 第一轮不要追求完美

350+条 FMEA + 350+ 条 MSR，AI 跑完全量 10~15 分钟。第一轮先让 AI 跑完——不要中间打断、不要逐条审。跑完之后 VR 抓问题、Enginer 修正。三轮修正（分类 + 规则违反 + 格式计数）比一轮精工细作高效得多。真实项目数据：v1.0（初版）→ v1.1（6 项修复）→ v1.2（37 项占位符清理）→ v2.2（最终），四轮出成品。

4.7 VR+CR 快速通过的前提 — B.1a 扎实

实战中最后一轮的 FMEA B.2 在 Manager VR 和 Head CR 中均未出现 FAIL——VR 仅 6 FLAG（0 FAIL），CR 仅 3 个文档缺口（无技术性错误）。这不是运气好，是因为 B.1a 阶段投入了足够的时间：42 个接口逐条经用户确认方向/类别/信号归属，三轮才定稿。

B.1a 投入的时间会在 B.2 阶段加倍偿还——分析基础扎实，Engineer 不需要在分析过程中反复猜测接口属性，Manager VR 不需要逐条质疑 FM 来源。反过来，B.1a 马虎了事，B.2 写完之后 VR 会全盘打回。

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

五、总结

执行层的全部内容——7 类接口分组 + P1/P2 两级 FM 来源、 FMEA & MSR 的产出格式、安全功能链与检测路径、Excel 导出和解析坑、VR 最高频的 7个翻车项及修复策略、7条从真实项目里提炼的可复用技巧。

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

Next: Part 9 — 软件安全分析

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