FMEA 表核对 PerryLink/dsh-fmea-table-check

dsh-fmea-table-check — FMEA 工作表元素完整性与风险优先数一致性检查

dsh-fmea-table-check 读取一份 FMEA 工作表——行以工作表自己的列名为键，中英文皆可——并检查其中可以机械判定的内容：分析链是否记录完整，严重度、发生度、探测度评分是否为可运算的数字，风险优先数是否等于三者之积，高风险行是否带有措施、责任人和截止日期，措施状态是否出自你自己的词表，以及失效模式中是否残留模板占位符。

它能回答什么

| 你问 | 它回答 |
| RPN 单元格不等于严重度 × 发生度 × 探测度——这能查出来吗？ | 能。FM-003 用严重度 × 发生度 × 探测度重新计算 rpn，容差为 0，并报告存储值不符的行。只有当四个单元格都存有可解析的数字时它才运行；如果发生度评分不是数字，这条规则报告 skipped，而不是通过。按 AIAG-VDA 手册搭建的工作表用 AP 而非 RPN 评分，所以要重新指定 resultField 和 factorFields，或者禁用这条规则。 |
| 严重度单元格里是 高，不是评分。会怎样？ | FM-002 要求严重度是可运算的正数，不是就报告该行。它的检查只点名 severity 字段，所以发生度和探测度需要另加同一条规则、换一个 field；它不设评分范围，因此不强制 1 到 10 的量表，也不判断某个评分是否合适。它无法解析的评分同样会让 FM-003 转为 skipped，因为乘积无法重算。 |
| 某行建议了措施，但责任人和截止日期是空的。 | FM-005 对每一行运行，只要建议措施单元格已填写，就要求 owner 和 dueAt 都存在；缺任何一个就报告该行。这两个是别名解析后的规范名，所以列标题不同的工作表需要在列映射里给出别名，或者调整 requiredFields。它检查的是这两个单元格已填写——不检查日期是否现实，也不检查责任人是否已接受。措施单元格为空的行归 FM-004 管。 |
| 我们的工作表从不说明分析的是哪个产品或过程。 | FM-007 读取工作表表头的 item，分析对象缺失时报告：FMEA 针对特定产品或过程开展，没有它，结论无法追溯，也无法与评分表对应。这是存在性检查——分析对象填了但填错了，不会报告。如果你的工作表还必须写明所用方法，把 method 加进它的 fields。 |
| 有些行的失效模式列里还写着 待填 或 XXX，另一些行那里干脆是空的。 | FM-008 会报告这样一行：失效模式单元格里还留着规则包中的占位词（【、】、{{、}}、XXX、xxx、待填、待补充、TBD、todo、示例），因为从模板复制来的表格读起来像一份做完的分析；它只读失效模式列，terms 按你的模板来。FM-001 会报告失效模式、影响、原因三列全空的行，但它只要求三者填一个——单元格里写 待填 就能满足 FM-001，然后被 FM-008 抓住。两条规则都不判断失效模式是否完整、后果分析是否到位。 |
| 报告把 FM-004 和 FM-006 列为 skipped，是出问题了吗？ | 不是。两者出厂都未配置，规则包如实报告，而不是悄悄放过。FM-004 的 threshold 是 0，读作未配置，所以在你设定自己的风险判据之前，没有哪一行算高风险——比如 triggerField: severity 配 threshold: 9，或 triggerField: rpn 配 threshold: 100。FM-006 的 values 列表为空，所以在你列出自己的取值之前，动作状态词表不会被检查。配置好之后，FM-004 只检查高风险行的动作单元格是否填了内容——不检查动作是否有效、是否可行——FM-006 只检查状态是否在配置的列表里，不检查动作是否真的执行了。 |

遵循的标准

| 文档 | 编号 | 引用它的规则 |
| 《系统可靠性分析技术 失效模式和影响分析（FMEA）程序》 | GB/T 7826（现行版本号与条号本次未核实） | FM-001, FM-002, FM-003, FM-004, FM-005, FM-006, FM-007, FM-008 |

边界： 这个插件检查 FMEA 工作表中一张表能被机械核对的部分——分析链条是否记录在案、严重度 / 频度 / 探测度评分是否为可运算的数字、风险优先数是否等于三者之积、高风险行是否带有动作及其责任人和截止日期、动作状态是否出自你的词表、以及是否还有模板占位词残留。它不判断失效模式是否完整、后果分析是否到位、评分是否正确、风险是否可接受。那些是研究团队的判断，也正是 FMEA 的价值所在。

⚠️ 在相信报告里的引文之前，请先读这段

这个插件规则包里每一条 excerpt 都明说了：没有拿到条款原文。 这套方法的出处是 GB/T 7826《系统可靠性分析技术 失效模式和影响分析（FMEA）程序》、IEC 60812，以及汽车行业的 AIAG-VDA 手册。核查环节没能从这些出处取到逐字条款原文，所以规则包没有转述引文，而是在 excerpt 字段里直接写明这一缺口，把诚实的推理放进 note。因此每条规则都是 warn 或 info，而一项测试断言没有任何规则声称拥有它并不具备的引文。拿到文本后，必须做两件事：把每个 excerpt 换成真实条款，并把 kind 提升为 direct。

有两项设置由你决定。FM-003 的 RPN 运算假定采用 S×O×D 方法；如果工作表基于 AIAG-VDA 手册，则改用 AP（action priority），所以要重新指向 resultField 和 factorFields——或者禁用该规则。另外，FM-004 的阈值默认发布为 0，意思是「未配置」：什么算高风险由你的风险准则决定，规则会报告它无法运行，而不是凭空编一个数字。

兼容性

| 层面 | 状态 |
| Harness | 对等范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0——已验证同时接受 0.2.0-rc.2 和 0.2.1-alpha.1。故意不声明 engines.dsh：它没有读取方，也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部（纯 ESM；无原生代码，无网络，无模型调用） |
| 工具模式 | 在 native、ptc 和 both 下均可工作；对于含多个工作表的工作簿，请使用 ptc |

功能

注册 fmea_table_check 工具。它读取一个工作表——行以工作表自身的列名为键，中文或英文均可——应用版本化的规则包，并返回报告。

| 规则 | 检查项 | 严重级别 | 依据类型 |
| FM-001 | 记录了失效模式、影响或原因 | warn | principle |
| FM-002 | 严重度评分是可操作的正数 | warn | principle |
| FM-003 | RPN 等于严重度 × 发生度 × 探测度 | warn | principle |
| FM-004 | 高风险行带有建议措施（默认关闭） | info | local |
| FM-005 | 带措施的行注明了负责人和截止日期 | warn | principle |
| FM-006 | 措施状态来自你的词汇表（默认关闭） | info | local |
| FM-007 | 工作表注明了分析对象 | warn | principle |
| FM-008 | 失效模式中没有残留模板占位符 | warn | principle |

安装

dsh plugin --profile <name> add dsh-fmea-table-check
dsh --profile <name> --dump-config | grep 'dsh-fmea-table-check'

配置

| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/fmea-table-check.yaml | 规则包路径，相对于包根目录 |
| disabledRules | string[] | [] | 要停止运行的规则 id；每个都会出现在 skipped 中 |
| onlyRules | string[] | [] | 只运行这些规则 id；为空则运行所有规则 |
| skipNotes | string | "" | 追加到每个 skipped 原因后的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |

值得了解的规则级参数：

- FM-003 resultField / factorFields / tolerance——RPN 运算。如果你的工作表遵循 AIAG-VDA 手册，请把它重新指向 AP 列。
- FM-004 triggerField / threshold / requiredField——你的高风险准则。阈值为 0 表示该规则不运行；常见设置是把 severity 设为 9，或把 rpn 设为 100。
- FM-005 conditionField / requiredFields —— 措施行必须携带哪些字段。
- FM-006 values —— 你的措施状态词表。
- FM-002 min / max —— 评分边界，前提是你的评分表已经定死。规则默认不设，因为各手册、各分析类型的评分表都不一样。

材料格式

工具接受 JSON 或 YAML：

item: 某型阀体加工过程 rows:
- { 项目: 某型阀体加工过程, 功能: 在规定压力下保持密封, 失效模式: 密封面泄漏,
失效后果: 介质外泄，影响安全, 严重度: '8', 失效原因: 密封面加工粗糙度超差, 频度: '4', 探测度: '3', 风险优先数: '96', 建议措施: 增加密封面粗糙度在线检测, 责任人: 张工, 完成期限: 2026-06-30, 措施状态: 进行中 }

列名匹配不区分大小写，并忽略空格、下划线和连字符，所以 严重度 和 severity 会落到同一个字段；表格自己的列名会保留，因此一条发现会指明它读的是哪一列。评分可以以字符串形式传入。

规则来源

规则数据放在 rules/fmea-table-check.yaml。规则包的头部完整说明了引用缺口，每条规则的 note 也会重复对该规则而言要紧的那部分。加载时的守卫通常要求「摘录必须是至少八个字符的真实引文」，但它分不清引文和描述——所以这个规则包靠头部、每条规则的 note，以及一个测试来兜底，该测试断言每个 excerpt 都承认这个缺口。

故障排查

- FM-004 或 FM-006 报告自己被跳过。 它们的配置是空的。两者都取决于你的风险判定准则和你的管理流程，插件不会替你猜。
- FM-003 在每一行都触发。 工作表用的是 AP 而不是 RPN；重新指向 resultField 和 factorFields，或者禁用该规则。
- FM-002 接受了 99 分。 该规则只检查分数是可运算的正数，刻意不设范围；如果你的评分表已经定死边界，就补上 min 和 max。
- FM-005 在一条没有责任人的措施上触发。 这正是检查点：没有责任人和完成期限的措施无法跟踪。
- 插件装上了，但工具一直不出现。 检查 main 是否指向 lib/index.mjs，以及 pnpm run build 是否产出了它；main 写错会让加载器静默跳过该入口。
- dsh plugin add 以不兼容为由拒绝该包。 peer 范围覆盖 0.1.x 和 0.2.x；如果你的运行时不在其中，就显式授予豁免： dsh plugin --profile <name> allow-version dsh-fmea-table-check@0.1.0 --dsh-version <runtime> --accept-risk
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围，它早于 0.2 系列。运行时会在安装时强制校验 peer 兼容性，所以声明的范围才是正确的；这是 dsh-plugin-dev 里已知的上游问题。

开发

pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, the shared table-plugin suite plus paired fixturesbash
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-fmea-table-check # refresh src/shared from ../_shared

这个插件只处理数据：src/model.ts 声明表格结构，共享工具包提供读取器和检查引擎，规则包声明每一项检查。

许可证

Apache License 2.0 © 2026 dsh-fmea-table-check contributors。