1 概述与定位
FMECA（Failure Modes, Effects and Criticality Analysis，失效模式、影响与危害性（关键性）分析）是一类以可靠性与安全性为导向的分析方法。它在识别“可能会怎么坏”的基础上，进一步评估“坏了会造成什么后果”“后果有多严重”“发生的概率如何”“发现的难易程度如何”，并据此进行优先级排序。由此，团队能够将有限资源优先投入到最需要改进的环节上，而不是仅凭经验平均用力。
在组织层面，FMECA 常被视为“从设计到验证，再到运行维护”的贯穿式风险管理工具：前期用于设计改进和验证策划，中后期用于变更影响评估与持续改进。其优势在于把离散知识（专家判断、历史数据、试验结果）结构化为可追溯的决策依据。
1.1 FMECA 与 FMEA 的关系
FMECA 通常可理解为 FMEA 的增强版。FMEA 侧重于系统地枚举失效模式及其影响，并根据风险优先级（常见为 RPN：风险优先级数或类似指标）做相对排序；而 FMECA 在此基础上更强调“关键性（Criticality）”的表达方式与排序准则，使评估结果更容易与安全目标、验证资源与处置计划挂钩。
换言之，FMEA 偏“发现与归类”，FMECA 更强调“定量/半定量的关键性比较”，让同一张表能够同时服务于设计改进与风险沟通。
1.2 典型应用场景与适用对象
FMECA 常见于对可靠性、安全与合规要求较高的系统，例如航空航天、汽车、医疗器械、工业装备以及关键基础设施等。其适用对象不仅包括硬件组件，也涵盖软件与流程控制环节，尤其当失效后果可能影响人身安全、系统稳定性或关键功能时。
从分析对象的性质看，FMECA 适合“功能—失效—影响”链条清晰、并且需要在多个风险之间作出资源取舍的场景；若系统结构极其简单或影响后果完全同质化，FMECA 的收益可能会相对有限。
1.3 核心目标：从“发现问题”到“排序与决策”
FMECA 的核心并不止于列出风险清单，而是要把风险转化为可执行的决策信息。一般包括以下目标：
- 识别系统在给定边界下的关键失效模式；
- 评估每种失效对功能、安全、性能与合规性的影响；
- 将风险进行可比较的优先级排序；
- 将高优先级风险落实为设计、工艺、验证或运维层面的行动项；
- 在后续变更中复审，确保风险状态随设计演进而更新。
2 基本概念
2.1 失效模式（Failure Mode）的定义与粒度
失效模式指系统或其组成部分在特定条件下可能出现的“偏离预期功能”的表现形式。它通常以可观察的行为来描述，例如“输出信号丢失”“阀门无法打开”“控制逻辑进入错误状态”等。
粒度决定了分析能否兼顾准确性与可操作性：过粗会导致关键细节被隐藏，难以制定针对性措施；过细则会造成条目爆炸、评分难以一致，最终难以落地。常见做法是在“能够对应具体设计/工艺/验证动作”的层级停住。
2.2 失效机理（Failure Mechanism）与失效模式的区别
失效模式描述“表现是什么”，失效机理解释“为什么会这样”。例如：
- 失效模式：电池容量衰减导致供电不足；
- 失效机理：材料老化、内部副反应或极化增大等。
在实践中，FMECA 表格通常以失效模式为主字段；机理信息往往作为补充，以帮助后续选择合适的预防或控制措施。若只写到“结果偏差”而缺少机理线索，可能造成改进方向不够精准。
2.3 失效影响（Effects）的分类方式
失效影响是指失效发生后对系统运行所造成的后果。常见分类维度包括：
- 影响范围：局部部件影响、子系统影响、系统级后果；
- 影响性质：安全相关、功能可用性、性能下降、合规性受损、成本或运维负担增加等；
- 影响时序：瞬时影响、持续影响、累积影响；
- 影响对象：对人员、对设备、对环境或对任务目标。
良好的分类有助于在后续把“影响严重性”与“验证重点”对应起来。
2.4 危害/关键性（Criticality）的含义与表达
关键性（Criticality）强调“某一失效在整体风险排序中的重要程度”。它通常不仅依赖后果严重性，还可能与发生可能性、探测能力（发现难易程度）有关。不同组织可能采用不同公式或指标体系，但共同点是：关键性用来支持资源优先级分配，并促使风险处置有依据。
在一些场景中，“关键性”也可用于区分“仅影响性能”的风险与“可能导致安全或法规后果”的风险，使输出更符合管理决策逻辑。
3 方法框架
3.1 分析输入与边界条件
FMECA 的结果高度依赖输入信息。常见输入包括：
- 系统架构与功能分解（从需求到功能再到部件/步骤）；
- 运行剖面与工况范围（温度、载荷、模式切换、运行阶段等）；
- 安全目标与合规约束（例如必须满足的关键功能或失效后必须保持的状态）；
- 现有控制措施（设计冗余、保护逻辑、检测手段、运维策略）；
- 历史故障与试验数据、或专家经验与建模假设。
边界条件通常明确：哪些场景纳入分析、哪些不纳入、分析采用的时间窗口与是否考虑维护操作等。
3.2 工作流程总览（识别—评估—排序—处置）
典型流程可概括为四步循环：
- 识别：确定要分析的功能、部件与失效模式列表；
- 评估：为每条失效记录影响，并给出关键性相关评分或指标；
- 排序：按关键性结果形成优先级，从而定位需要重点改进的对象；
- 处置：制定预防、检测与控制策略，并把措施转入设计、工艺、验证或运维计划。
在闭环管理中，这一循环会随变更重复执行。
3.3 分工与角色（工程、质量、可靠性、设计等）
FMECA 往往需要跨职能协作。常见角色包括：
- 系统/设计工程：负责功能与结构分解、提出可行的设计改进；
- 可靠性/测试工程：负责关键性指标的计算逻辑、验证关联与试验可行性；
- 质量与工艺：负责制造差异、过程控制与偏差风险；
- 运行/运维团队：负责识别现场操作和维护相关的失效诱因；
- 风险管理或项目管理：负责阈值分级、行动项跟踪与复审节奏。
多角色参与的目的在于降低“只从单一视角做判断”的风险，并提升结果一致性。
3.4 结果输出形式（表格、报告与行动清单）
常见输出包括：
- FMECA 主表：每条失效模式对应字段信息与关键性结果；
- 附件报告：说明分析边界、评分准则、假设条件与关键结论；
- 行动清单（Action Item List）：列出需要采取的措施、责任部门与计划时点；
- 追溯性材料：把表项与设计更改、验证方案、测试报告或审核记录关联起来。
当输出能直接映射到“下一步做什么”，表格才真正成为决策工具。
4 风险优先级与关键性计算
4.1 RPN 及其在 FMECA 中的常见用法
RPN（Risk Priority Number）常用于把“严重度、发生频度、可探测度”合成为一个可比较的数值。其思想是：严重后果、发生更常见、且难以发现的失效应获得更高优先级。
在 FMECA 中，RPN 往往作为半定量排序依据之一；同时也可能结合关键性定义（例如更强调对安全或任务关键性的加权）以避免“同分但后果本质不同”的情况。
4.2 严重度、发生频度、可探测度的评分逻辑
评分通常依赖统一的准则表，常见逻辑为：
- 严重度：关注失效对安全、功能与合规的最大后果等级；
- 发生频度：关注在给定工况与时间窗口内发生的可能性；
- 可探测度：关注在失效发生后，现有检测手段是否能在造成更大损害之前发现。
关键点在于“评分准则一致”和“边界条件清晰”。例如，可探测度若基于特定检测覆盖范围或特定维护周期，则需要在表中明确假设。
4.3 替代或补充的关键性指标（半定量/定量思路）
除 RPN 外，也可采用或补充其他关键性指标思路，例如：
- 以概率乘以后果的定量/半定量模型（在有数据或可估计概率时）；
- 将严重度作为主导权重、发生与探测作为修正项（适合强调整体安全管理的场景）；
- 基于“关键故障类别”的分类加权（例如把某些安全相关后果单独处理）。
这些替代指标的共同目的，是提升不同风险之间的可比性，并使排序更贴近管理目标。
4.4 阈值与分级：如何将优先级转化为行动等级
将关键性结果转化为行动等级，通常需要阈值策略，例如：
- 高关键性：必须采取设计/工艺预防措施，并制定针对性验证；
- 中关键性：采取改进或加强控制，并在测试与过程监控中覆盖；
- 低关键性：保留现有控制措施，持续监测或在变更时复审。
阈值的制定应与组织风险承受能力、法规/合同要求以及可用资源相匹配，避免“分数高但无任何处置路径”的尴尬。
5 失效分析内容组织
5.1 功能与需求分解（Function Tree / 结构分解）
分析一般从功能出发，把需求拆解为可验证的功能层级，再映射到部件或步骤。功能分解的价值在于：它把“失败如何影响任务”与“设计如何实现功能”建立连接。
常见组织方式包括功能树（Function Tree）或结构分解树（例如按系统—子系统—组件—部件/步骤）。无论采用何种方式，核心是保证层级之间可追溯、字段可对齐。
5.2 块/组件/步骤的选择原则
选择分析对象时通常遵循可操作性原则：
- 对关键功能链路上的部件优先覆盖；
- 对可能触发系统异常状态的控制/保护模块重点关注；
- 对制造工艺差异较大或工况敏感的步骤加强粒度；
- 对接口与边界条件上易产生失配的位置进行补充。
同时要避免把所有零件都当作独立条目，导致表格难以维护。
5.3 多故障与组合失效的处理策略（简化与边界）
组合失效通常带来指数级复杂度。实践中常采用简化策略，例如：
- 只分析最可能或最危险的组合；
- 以共同原因（Common Cause）将相关失效归并；
- 设定“组合分析边界”，明确哪些联动情形纳入。
这种策略需要在边界条件中说明：否则读表者容易误以为分析穷尽了所有组合情形。
5.4 环境与工况（载荷、温度、运行阶段等）考虑
失效可能高度依赖环境与工况。FMECA 在组织时会把不同运行阶段或工况窗口作为评估维度，例如：
- 启动、稳态、关机或切换阶段；
- 高温/低温、过载、振动、湿热等条件；
- 长期运行与短时冲击差异。
通过将工况信息固化到评分假设中，关键性结果更具可解释性。
6 影响评估与验证关联
6.1 影响范围：局部、子系统、系统级
影响评估通常从局部开始，但最终需要回到系统目标。表述方式可采用逐级归并：
- 局部：部件性能偏差或功能丧失；
- 子系统：导致特定功能失效或降级；
- 系统级：影响任务、人员安全、关键性能或合规状态。
这种层级映射有助于避免“只看部件指标却错判系统后果”的情况。
6.2 安全性、合规性与性能影响的映射
影响并不总是以“安全”单一维度呈现。实践中常见做法是将影响映射到多个管理关切，再统一转换为严重度评分依据。例如：
- 安全相关：可能造成伤害或不可接受的风险；
- 合规相关：违反法规要求、失去认证条件；
- 性能相关：精度下降、响应变慢、寿命缩短等；
- 可用性相关：导致停机、降级或无法完成任务。
映射规则应在分析准则中固定，减少主观差异。
6.3 现有控制措施（Detect/Prevent/Control）的记录
FMECA 通常记录三类控制：
- 预防（Prevent）：从源头降低失效发生；
- 控制（Control）：减轻失效扩散或影响程度；
- 探测（Detect）：在造成重大后果前发现异常。
记录控制措施的意义在于：可探测度评分并非凭空出现，而应与现有检测逻辑、报警阈值、维护策略或监控覆盖范围对齐。
6.4 与验证计划（测试、检查、监控）的衔接
关键性越高，越需要在验证计划中体现。衔接方式通常包括：
- 为高关键性失效指定更高覆盖率的测试或检查；
- 将探测相关假设转化为可执行的监控项或验收标准；
- 在试验中验证关键控制措施是否有效，并更新失效发生或可探测评分。
验证不是一次性动作，而应在结果反馈后用于更新关键性结论。
7 处置与改进闭环
7.1 风险降低策略：设计、工艺、流程与运维
风险处置可从多个层次降低关键性：
- 设计：冗余设计、失效安全架构、约束极限、改善材料或结构；
- 工艺：关键参数控制、过程能力提升、变更管理；
- 流程：操作规程优化、培训与作业指导；
- 运维：维护周期调整、状态监测、替换策略优化。
选择策略时需要考虑“措施与失效机理的匹配度”，以及验证成本与效果。
7.2 风险接受、风险转移与风险消减
处置并不一定都以“消除”为目标。常见决策包括：
- 风险接受：在满足阈值与合规前提下承认风险，并设置监控与复审机制；
- 风险转移：通过合同、保险或外包服务边界划分部分风险责任（需符合组织治理要求）；
- 风险消减：通过前述设计、工艺、流程与运维改进降低关键性。
合理的平衡能避免“过度工程”或“无约束接受”两种极端。
7.3 行动项（Action Item）与责任人管理
行动项是闭环的落点。行动项通常包含：
- 需要采取的具体措施；
- 对应的表项编号或失效条目；
- 责任部门或责任人；
- 完成时点与验收标准；
- 资源与验证路径。
良好管理能防止“表格里写了措施，但没有人负责、没有验收”的脱节现象。
7.4 复审与再分析（变更影响评估）
设计变更、工艺调整、软件版本升级或运维策略更新都会影响失效模式与关键性。复审通常触发于：
- 重大设计变更；
- 新的历史故障或试验异常；
- 关键控制措施调整；
- 工况边界扩展或使用场景变化。
再分析的重点在于更新：发生可能性、可探测度与严重度之间的关系是否仍成立，并确保行动项与验证计划同步。
8 工具与数据支持
8.1 FMECA 表单结构与字段设计要点
表单字段一般应覆盖“能算、能解释、能追踪”。典型字段包括：
- 分解层级与功能/部件标识；
- 失效模式描述；
- 失效影响（分级到系统级）；
- 严重度/发生频度/可探测度评分或关键性指标；
- 控制措施（预防/控制/探测）与证据；
- 计算结果与阈值等级；
- 建议措施与行动项追踪编号。
字段设计的关键是避免“信息难以补齐”，以及确保计算逻辑在表中可复用、可审查。
8.2 数据来源：历史故障、试验、专家经验
数据来源可分为三类：
- 历史故障：基于既往产品或相似项目的故障记录；
- 试验与验证：试验结果、筛选数据与覆盖率信息；
- 专家经验：在数据不足时的结构化判断。
实践中常需要明确证据等级或数据置信度，并在评分准则中体现其影响，避免所有条目用同一种“确定性语气”包装起来。
8.3 可靠性数据与先验假设的处理
当采用半定量或定量关键性时，先验假设（例如分布形式、时间窗口、条件概率）会显著影响结果。较规范的处理包括：
- 在分析记录中写明假设来源与适用边界；
- 对关键假设进行敏感性检查；
- 在试验数据到位后更新关键性计算与评分依据。
这样可以降低“算得很漂亮但不可追溯”的风险。
8.4 自动化与软件工具（版本控制、追溯性）
软件工具常用于提升一致性与追溯能力，例如：
- 结构化表单管理与字段校验；
- 计算自动化（减少手工误差）；
- 版本控制与变更记录（知道谁在何时改了什么）；
- 与需求、设计、验证文档的链接。
追溯性是审查与复审的基础：没有链接，闭环就难以成立。
9 常见问题与实践误区
9.1 评分主观性与一致性不足
常见问题是团队成员对“严重度、发生频度、可探测度”的理解不一致，导致同类型失效被赋予不同分数。解决思路通常是统一评分准则、用例校验和复核机制，例如引入评审会对高关键性条目进行共识确认。
9.2 粒度过粗或过细导致可用性下降
粒度过粗会让行动难以落地；粒度过细会导致条目数量激增、分析耗时过长，反而难以维持一致性。建议采用“能对应设计/工艺/验证动作”的粒度作为折中标准，并在必要时对关键链路加密粒度。
9.3 忽略“可探测性变化”（检测条件变更）
可探测度并非固定属性。检测策略、报警阈值、维护周期、监测覆盖范围改变后，探测能力会随之变化。若只在初次分析时给出探测评分而不随变更更新，关键性排序可能失真。
9.4 只做表格不做行动闭环
一些项目可能停留在“写完表就结束”。这种做法会让关键性排序失去意义，因为没有对应的设计改进、验证计划或运维策略。真正的闭环应确保行动项有负责人、有时间表、有验收结果，并在复审时反馈执行效果。
10 案例化表达
10.1 面向产品设计的 FMECA 示例结构
面向产品设计的示例通常按“功能—组件—失效模式—影响—控制措施—关键性—行动项”的顺序组织。行动项往往指向设计修改、材料或结构优化、保护逻辑增强，以及与之对应的验证测试与验收指标。
示例表述要点包括：失效影响需能回到系统功能层；控制措施要能解释“为何还能接受”；行动项要能直接映射到设计变更或试验计划。
10.2 面向流程/工艺的 FMECA 示例结构
面向流程或工艺时，失效模式常表现为过程偏差导致的质量或功能偏离，例如参数失控、装配错误、检测漏检等。此时影响评估会更强调“工艺偏差如何进入成品功能”，并将控制措施与过程检验、统计过程控制或工装校准相衔接。
行动项常指向工艺参数窗口优化、关键工序增加检测点、完善防错机制等。
10.3 面向运维阶段的关键性评估思路
运维阶段的失效模式往往与使用环境、维护操作与状态监测能力相关。例如部件逐渐劣化、误操作、维护延迟造成的风险累积等。关键性评估需要纳入维护周期、监测频率与发现渠道的变化。
输出不仅包括风险排序，也应明确后续运维策略：例如更换周期、状态监测阈值与告警处置流程。
10.4 一次“从忽略到发现”的典型改进路径（轻度梗式叙述：把“风险清单”变成“行动清单”）
常见的轻度“梗式”改进路径是：团队起初只把每条失效都写进“风险清单”，看起来项目很认真，但到了评审才发现高关键性的条目没有对应行动。于是他们把表格导出，逐条追问一句话：如果风险评分更高，那下一步谁来做、做什么、用什么验证来证明。
结果是“风险清单”被替换成更实际的“行动清单”：每条高优先级风险都绑定责任人、时间表与验证证据。表格不再只是记录，而是推动改进的任务清单。
11 相关标准与术语参照
11.1 与可靠性工程术语的互通
FMECA 与可靠性工程中的关键概念存在天然联系，例如可靠性、失效率、故障模式、失效分布、可用性与安全性等。在术语互通时，重点是确保“评分依据”和“输出指标”与工程语言一致，避免把不同体系的概念混用。
11.2 与行业标准的常见对应关系（概述层面）
在不同工业领域，FMEA/FMECA 通常与各自的质量管理体系、可靠性规范或安全审查要求相配套。此类对应关系的共同点在于：都要求结构化分析、可追溯记录以及与验证/评审过程联动。
由于具体条款随行业与组织体系差异较大，使用时一般应以项目采用的正式标准版本为准，并在分析报告中说明采用背景与满足方式。
11.3 输出文档的典型命名与审查要求
输出文档通常包括分析报告、主表附件和行动项跟踪文件。命名常体现项目阶段与版本信息，以便审查与追踪。
审查要求一般关注四点：边界与假设是否明确、评分准则是否一致、关键性结论是否可解释、行动项是否能闭环验证。若缺少其中任一要素，容易在评审中被要求补强。
12 比较与替代方法
12.1 FTA（故障树分析）与 FMECA 的互补关系
FTA（Fault Tree Analysis，故障树分析）从“顶事件”（例如系统失效）出发，向下推导可能导致顶事件的逻辑组合。FMECA 则从“部件/功能失效可能性”向上归纳后果。两者视角不同：FTA 更擅长揭示逻辑结构与组合关系，FMECA 更擅长覆盖具体失效模式并建立改进行动。
实际项目中常将两者结合：FMECA 提供失效模式清单与控制措施线索，FTA 用逻辑推导验证组合路径是否被覆盖或是否需要补充。
12.2 FTA、ETA 与 FMECA 在层级上的差异
FTA 与 ETA（事件树分析）通常围绕系统从异常状态到后果的路径展开，层级更强调“从某事件如何演化”。FMECA 则更偏向“失败来源与影响归纳”的层级。选择方法时，需要匹配项目希望回答的问题类型：是“哪些组合会导致灾难性顶事件”，还是“各失效模式会如何影响功能与安全”。
12.3 与 HAZOP 等方法的边界与选型思路
HAZOP（危害与可操作性研究）常用于过程工业领域，通过引导词与参数偏差来系统探索风险。其优势是对流程偏差与工况参数的系统性覆盖。FMECA 更适合当系统结构明确、功能链条清晰，并需要把失效模式与关键性排序转化为行动时的场景。
选型通常取决于：工艺是否以“参数偏差为主”的探索方式为主，还是以“组件/功能失效与关键性决策”为主。
12.4 何时选择“FMEA+关键性”而非其他方法
当项目需要在多风险之间形成可比较的优先级，并将结果直接导入设计改进、验证策划与运维策略时，“FMEA+关键性”的优势更明显。尤其是在：
- 风险处置资源有限，需要排序；
- 失效影响与控制措施之间存在可映射关系；
- 需要半定量或定量表达以支持管理层决策；
- 希望在变更后快速复审更新。
此时，FMECA 往往比单纯的失效枚举或仅基于逻辑推导更能直接转化为工程行动。
13 术语小抄与读表指南
13.1 常用缩写与评分含义速查
常见缩写包括：
- FMEA：失效模式与影响分析；
- FMECA：失效模式、影响与关键性分析；
- RPN：风险优先级数；
- Criticality：关键性（以关键性指标表达的重要程度）；
- Prevent/Control/Detect：预防/控制/探测（与控制措施记录相关）。
评分含义通常对应严重度、发生频率与可探测度的等级体系，读表时应优先参照项目的评分准则表。
13.2 如何解读表格字段与优先级结论
解读顺序可按“边界—失效模式—影响—控制措施—评分与关键性—行动项”进行。优先级结论应结合控制措施与评分假设：同一个失效在不同检测覆盖范围下，可探测度可能不同，关键性排序也可能变化。
因此，读表不应只看最终数值，还要回到评分依据。
13.3 如何从一行记录推导行动项
推导行动项可采用“问答式”：
- 影响是否触及安全或关键功能目标？若是，措施通常必须更强；
- 当前控制是预防、控制还是探测？缺口在哪一类？
- 如果探测困难，是否需要新增检测点或调整阈值？
- 行动项能否对应到设计、工艺、流程或运维的具体变更与验证？
当行动项无法对应到具体“做什么与怎么验证”，这行记录通常需要返工或补充证据。
13.4 常见“读错表”的坑（轻度调侃）
最常见的“读错表”坑包括：只看分数不看边界，只看条目不看证据，只看第一次评分不看后续变更。还有一种常见情况是把“可探测度”当成“检测一定能发现”，忘了它往往是建立在特定工况、特定维护周期和特定检测覆盖范围上的“条件性结论”。一句话总结：表格能读出结论，但不能替代评分准则与假设的回看。