FMEA 方法论（DFMEA / PFMEA / FMEDA）

AIAG-VDA 2019 联合版不是只把 RPN 换成 AP,它首先解决的是北美供应链和德系供应链各讲一套 FMEA 语言的问题。手册前言与导论明确了四件事：

• 范围一次收拢：同一本手册同时覆盖 DFMEA、PFMEA,以及 Supplemental FMEA for Monitoring and System Response（FMEA-MSR）。
• 旧版正式退场：它取代 AIAG FMEA-4 与 VDA Volume 4 里彼此不完全兼容的写法；附录 F 专门列出旧法 $\to$ 新法的主要变更点。
• 术语与行业口径对齐：手册与 SAE J1739 保持一致,目的是让 OEM / Tier-1 / 供应商在同一条供应链里共享一套结构树、功能树、失效网和 AP 规则。
• 只分析技术风险：FMEA 管的是产品 / 过程的技术失效风险,不负责财务、进度、商务或战略风险；后者应留给项目风险清单与经营评审。

详细失效模式目录见 失效模式速查（121 条）；本页讲方法论。

把"失效"拆成三层是新法 Step 4 的核心——三层背后是三个独立视角：Effect 是顾客 / 上一级看到什么(决定 S),Mode 是这一级功能丢了什么(决定治理范围),Cause 是物理上为什么发生(决定 O 与 D)。三层互相独立但一对一锚定,任何一层写模糊整行就废。最常见的混用是把 "焊接质量差" 同时写进 Mode 和 Cause——前者应是"功能丢失"(电气连续性),后者应是"具体物理参数偏移"(焊脚阻抗 > 0.5 mΩ)。

关键判别：Effect 评严重度 S;Cause 评发生度 O;Cause 对应的检测手段评探测度 D。三个分数对应三个层级,不能混。

S 是产品本身的功能性质决定的——同一个失效效应在新法 1~10 评分内的位置,不会因为 O 或 D 改了而变。下表的层次有清晰的分水岭：9~10 = 安全/法规(不可被治理稀释,新法 AP 一定 H)、7~8 = 主功能丢失(影响驾驶可用性)、4~6 = 次要功能/外观(影响客户体验但不影响功能)、1~3 = 不可察觉。

S 不可降：S 是"如果发生了影响多严重",由产品本身的功能决定,不会因为加了诊断或检测而下降——降低 S 唯一办法是改设计（如加冗余、降功能等级）。

O 是频次——这条 Cause 在量产中多频繁触发该 Mode。新法 O 评分主要看 ppm 量化,而不是定性的"高/中/低"。关键是数据来源：DFMEA 阶段用历史相似设计的 PPM 经验值或仿真,PFMEA 阶段用 Cpk → ppm 换算或量产 SPC 数据。没有数据的 O 评分等于猜——这是 FMEA 流于形式的常见入口。

O 由设计鲁棒性 + 工艺能力共同决定——DFMEA 看设计是否容错,PFMEA 看 Cpk 是否够。降低 O 的方法：改设计（DFMEA）/ 收紧工艺（PFMEA）。

D 是检测可靠性——已知会发生时,有多大概率在流到客户前拦住。D 的层次按"控制方式 + 覆盖率"两维分级：1~3 = 物理防呆 / 100% 自动 + SPC(几乎不可能漏)、4~6 = 100% 仪表 / 人工(漏报概率中等)、7~9 = 抽检或事后(明显漏报)、10 = 无检测。关键陷阱是把"应该有"的检测当成"实际有"——D 评的是产线当下已部署的能力,不是改进后的目标。

关键判别：D 评的是当前已实施的检测能力,不是"以后想加什么"。FMEA 写完才能改进——改进后重新评 D。

旧法 RPN = S × O × D（1~1000 分）,通常以 RPN ≥ 100 作为整改门槛。但实践中暴露三大问题：

• 乘积失真：S=10/O=1/D=1 = RPN 10（人身安全相关却被忽视）；S=2/O=5/D=10 = RPN 100（轻微外观瑕疵反被强制整改）
• 数值魔术：团队为了"凑过 100" 把 D 偷调到 4 → 整改清单瞬间瘦身,但失效率不变
• 误把 RPN 当排序：实际两条线 RPN 同 80 但 S 一条 10 一条 4 完全是两种风险

新法用 三维查表直接给 H / M / L 三档优先级：

AP 表的内在逻辑:

• S = 9 或 10（人身安全 / 法规相关）→ 几乎全部 H,无视 O 和 D（旧法这里被 RPN 拖低）
• S = 7 或 8（主功能丢失）→ O 高 → H；O 低 + D 高 → M；O 低 + D 低 → L
• S ≤ 6（次要影响）→ 大多 M / L

完整 AP 矩阵 1000 行,实务用查表工具（FMEA 软件如 APIS / IQ-FMEA / Plato 内置）。

新法的核心思想：安全 / 法规相关的高 S 项必须治理,无论发生频次多低。这跟 ISO 26262 的 ASIL 评估逻辑同源——S（Severity）+ E（Exposure）+ C（Controllability）的组合,Severity 高就 ASIL D。

实务过渡建议：

• 新项目（2020 年后启动）一律用 AP
• 旧项目维护中：既保留旧 RPN（OEM 历史报告需要）也并列加 AP（新合规需要）；不要用 RPN→AP 的换算公式（数学上不一一对应）
• 内审 / 客户审审 RPN 还是 AP,看 OEM SOR 要求；中国 OEM 普遍 2022 年后转 AP

DFMEA 表的列顺序不是任意的——左边是"失效描述"(Step 4 输出),中间是"评分"(Step 5),右边是"措施 + 闭环数据"(Step 6/7)。这条左→右流向必须严格——团队评审时按列从左往右读一行,任何一列空白意味着流程断在那一步。

DFMEA 流于形式 vs 真起作用,差别在四条工程链是否走通——每条都是"输入→输出"的强约束,断一条整张表就成走形式。

链 1：从功能而非部件出发。从部件出发会漏交互失效(两零件单看都对组合出问题),前面已说。这条决定 Step 3/4 的写法——表里 "失效模式" 列不能写部件名,必须写功能丢失或功能偏离。

链 2：失效起因必须可复现验证。如果一条 Cause 写了但实验室无法复现,O 评分就是凭感觉——团队就会随手填 3 或 4 凑过去,FMEA 失去预测力。所以每条 Cause 必须能挂一个具体的物理量或参数偏移(电压尖峰 > X V / 阻抗 > Y mΩ / 温度 > Z ℃),不能是"焊接质量差"这种模糊话。

链 3：每条改进措施必须改设计文件。DFMEA 不是 reminder list——团队讨论一圈写"设计师注意一下"等于没做。改进必须有 ECN 编号、改了哪条规格、责任人、完成日,否则 Step 7 回填没有依据,审计直接 NC。

链 4：DFMEA 高 AP 项必须进 DVP&R 试验矩阵。这一条是 DFMEA 与 DV 试验衔接的咽喉——FMEA 列出的高风险点必须在 DV 阶段用试验验证它真的被新设计压住了,否则 FMEA 改完跟没改一样。OEM 审 DVP&R 时会反查 DFMEA 高 AP 行有没有对应试验,有缺漏就 NC。

只讲方法很容易抽象。下面用一个隔离驱动故障关断链做最小电路案例，把你点名要补的元件都放进同一条功能链里：电阻 / 电容 / 比较器 / MOSFET / BJT / LDO / 基准 / 隔离芯片。

对象不是整台逆变器，而是一条最小但真实的保护链：

R1/R2 分压 + Cfilter -> 基准 Vref + Comparator -> BJT 下拉 / MOSFET 使能 -> LDO 供电 -> 数字隔离器把 FAULT 送到主控或栅驱

目标功能只写三条就够：

• 当被监视量超阈值时，在 FTTI 内拉起 FAULT 并关断驱动。
• 正常工况、正常 dv/dt 和正常噪声下不应误触发。
• FAULT 跨隔离栅后仍保持极性、时序和 fail-safe 含义不变。

下表不是“元件百科”，而是工程里真正够用的写法：本地功能 -> 典型失效模式 -> 上层效应 -> 常见起因 -> 当前控制 -> 应做的验证 / action。

做完上表后，真正有价值的不是“表填满了”，而是把高风险行推到验证里。对这条链，最值得进 DV 的通常不是通电能不能工作，而是下面这些破坏性或边界性场景：

• 分压电阻开路 / 漂移注入：验证阈值错误时系统到底漏判还是 fail-safe。
• Cfilter 容值下跌与 ESR 上升：验证慢斜坡、脉冲和噪声下是否产生 comparator chatter。
• 比较器慢斜坡加噪声：验证迟滞设计到底够不够，而不是只在理想方波下看示波器。
• LDO 负载瞬态与掉压：验证基准和比较器电源是否会在保护动作前先自己乱掉。
• 隔离器 CMTI：验证高 dv/dt 下 fault 位是否被污染，这一项在功率回路附近尤其关键。

PFMEA 表与 DFMEA 类似,但维度从"产品"改为"工序":

为什么强制对照？因为 PFMEA 的"当前预防控制"和"当前探测控制"两栏记的是工程师理想中的控制方法,而 Control Plan（PPAP element 7）记的是产线实际执行的工序参数和检验。两份文档必须一一对应——否则就出现"FMEA 写了 SPC,产线没做"或"产线做了某项检测,FMEA 没记录"——前者意味着风险评估是基于不存在的控制(O/D 评偏低),后者意味着资源浪费。两者不一致 = PPAP NC。

闭环：PFMEA 定义控制方法 → CP 落地工序参数 → SOP 给操作员步骤 → SPC 数据回流验证 PFMEA 评分是否真。

PFMEA 高 AP 项不是平等的——里面只有一个子集是"失效会影响人身安全或违反法规"(对应 §3.1 评分表 S = 9 或 10 那两行)。这个子集必须升级为 特殊特性 CC（Critical Characteristic）/ SC（Significant Characteristic）,获得三件比普通 PFMEA 行更强的强制约束：

• 出图必标注（▽ / 钻石符号）——下游所有人看图就知道这一项是 safety-related
• CP 必有 SPC 监控——不能仅靠抽检或事后总检
• 工序参数变更必走 ECN——任何改动需正式工程变更流程,不允许操作员自行调参

为什么要把这部分单独标记？因为正常 PFMEA 行如果 D 评分高,CP 可以选 100% 检或 SPC；但 CC/SC 必须 SPC——这是 IATF 16949 强制要求,目的是让安全相关参数有长期统计趋势数据而不仅仅是"这一件 OK"。详见 特殊特性。

手册正文最有价值的部分，不是再次解释什么叫 FMEA，而是给出一套评审时能直接落地的判断标准。

• Step 1 不只要写 included / excluded，还要说明 boundary 里只放团队拥有 design control 或 process control 的对象。边界内的块通常比当前分析层级低一级；存在但不属于本次分析的 carry-over 元素，可以画出来但要明确标记不分析。
• Block / Boundary Diagram 不是装饰图。它至少要让评审者看见内部块、外部块、接口方向、终端用户，以及静态/动态间隙、运动关系、热暴露等无接触但会失效的耦合。
• P-Diagram 不是“有空再做”的附图。它把 control factors、noise factors 和 diverted outputs 显性化，直接给后续试验计划输入，特别适合把环境、老化、误用和批差引入 DFMEA。
• 失效语句必须让后续读者不看会议纪要也能懂。只写 not fulfilled、not OK、defective、broken 这类泛词，不足以构成合格的 failure description。
• Step 6 的 action 必须是具体、可测量、可执行的承诺。已经写进当前 prevention / detection controls、并且已经计入初始风险判断的活动，不能再重复写成新 action 伪装成降风险。
• Step 7 不只是把表格归档，而要形成 FMEA report：至少能交代 intent / timing / team / task / tool、分析范围、功能建立方式、高风险项摘要、采用的 S/O/D/AP 口径、已采取或计划采取的措施，以及 open actions 的关闭时间承诺。

VDA QMC 2024 white paper 的价值，在于它把 2019 联合手册相对于旧 AIAG FMEA-4 / VDA Volume 4 的变化点重新按七步法压缩了一遍，适合拿来做培训或做旧模板迁移。

• 它明确把 focus element 作为核心概念拉出来，要求团队在结构、功能、失效三张网里始终围绕同一个关注元素分析，而不是在不同层级来回漂移。
• 对 DFMEA，它点名强调 block / boundary diagram；对 PFMEA，则点名强调 process flow diagram 和 structure tree。这意味着新法的前置工作不是同一套图换个名字。
• Step 3 被强化的不只是 function tree，还包括 parameter diagram，以及系统、功能安全、零部件团队之间的功能协同。
• Step 4 和 Step 6 都把 customer / supplier collaboration 提到了显性位置。也就是说，高层 failure effect、接口责任和优化动作，并不默认能由单一公司闭门完成。
• Step 5 的 change point 不是简单把 RPN 删掉，而是把 severity、occurrence、detection 的表重新校准，并要求用 AP 作为动作优先级语言。
• Step 7 被单独拆出来，意味着结果文档和对外沟通不再被视作 Step 6 的附属工作，而是完整分析流程的一部分。

如果团队手里用的是首印扫描件、旧培训课件或从旧模板复制出来的栏位名，errata 不只是文字修正，而会直接影响分析逻辑。

• DFMEA 的边界对象不应只挂在 Block / Boundary Diagram 上，Structure Tree 同样可以定义分析边界。也就是说，评审时不能因为没单独画边界图，就断言范围定义无效。
• Function tree/net 与 P-Diagram 的关系被修正为 and/or, as applicable，不是所有对象都必须同时画两张图，但团队必须能说明为什么当前对象需要或不需要 P-Diagram。
• DFMEA Detection 表里 D = 7 的成熟度口径被修正为新测试方法、尚未证明、但时机仍足以在量产发布前修改生产工具。这跟“成熟方法但安排太晚”是两种完全不同的工程状态。
• No Action Taken 的含义被修正得更硬：风险状态不变，AP 也不下降。也就是说，不采取措施不等于“接受后自动结案”，而是要把残余风险作为明确决策留在记录里。
• PFMEA 的 function-structure linking 方向在 errata 里被纠正过一次。顺着“what does it do”往上看时，应从 process work element 回到 process step 和 process item；顺着“how is it implemented”往下看时，则从 process item 追到 step 和 work element。旧课件里这两个方向经常被写反。
• FMEA-MSR 与监视时序有关的术语也被纠正：核心判断应以 Fault Tolerant Time Interval 为准，而不是把它混成 Fault Handling Time Interval。对运行时监视类风险，这会直接影响 M=10 的判定。

把几份官方源放在一起看，当前行业主线其实很清楚，不适合再把旧表格式口径当作默认主线。

• AIAG 官方手册页仍把联合手册定义为用于 Design FMEA、Process FMEA 和 Supplemental FMEA for Monitoring and System Response 的主参考手册；同时，产品页当前已标成 1st Edition, 2nd Printing。
• SAE J1739_202605 已在 2026-05-07 进入 Stabilized 状态。它明确写出标准里同时包含 must 与 should，并要求任何偏离标准的方法都要有文档化理由和顾客一致同意，才能在客户或第三方审核里站得住。
• VDA QMC 公开页面已经把旧 VDA Volume 4 中的 Product and Process FMEA 章节列为 withdrawn，并指向新 VDA Volume 4 风险分析章节以及 AIAG-VDA FMEA Handbook。这意味着旧 VDA Volume 4 已不应再被当作当前主线手册。

ingest 不只是“本地 PDF 进 auto_ingest.py”。对这个仓库，真正的知识获取链已经至少包含：本地文件、网页 / feed / search / scholar 发现、抓取与提取、AI 总结与分类、merge/create、rewrite、archive/index、health/watchdog。既然它已经是一个多阶段系统，就可以而且应该用 FMEA 去看。

更稳妥的分析边界不是“一个 ingest 脚本”，而是下面这条链：

1. source discovery：feed、web search、scholar、人工投喂、本地 sources/
2. intake / queue：sources/inbox/、enqueue_sources.py
3. fetch / extract：PDF/HTML/image 提取、pdftotext、OCR
4. AI structuring：抽取主题、生成/合并页面、重写段落
5. page mutation：merge/create/reflow
6. archive / index：归档、search-index、sources-index
7. quality monitor：feed_audit.py、review issue、coverage 构建
8. liveness / recovery：auto_ingest_health.py、auto_ingest_watchdog.py

下面这张表故意把本地 PDF、网页抓取、AI 总结、merge/create、watchdog 放在一起，因为这正是“不是只看本地 PDF”的版本。

把仓库里的问题抽象一下，会发现和通用数据管道的控制原则几乎一致。本轮额外对照了几类一手资料，核心共识很清楚：

• Google Cloud Dataflow 的 exactly-once 依赖稳定 record ID + 去重账本；这和本仓库 .ingested-hashes.json 的方向一致，但当前还偏“文件级”，还没完全覆盖 phase 级 side effect。
• AWS 对 durable execution 的要求很直白：重试天然意味着 side effect 可能执行多次，因此业务动作必须幂等。这正对应本仓库的 merge/create/rewrite 不能只靠“脚本大概率不会重跑”。
• Confluent 的官方 DLQ 口径是：坏记录应该被隔离出去，让主管道继续，而不是把错误静默吞掉继续伪装成功。对本仓库，feed 摘要失败、抽取为空、schema 不合法，都更适合进 quarantine / DLQ，而不是直接 raw fallback 混过去。

这不是纯理论。本地脚本已经给出了两个非常明确的仓库状态信号：

• auto_ingest_health.py 当前检查结果是健康的，说明 liveness 层没有马上卡死。
• 2026-05-09 本地窗口复核里，feed_audit.py --days 7 --mode first_seen 显示最近 7 天只有 44 次尝试、其中 7 条拿到合格结构化摘要，success rate 只有 16%、raw fallback rate 高达 70%。这说明当前最大问题不是“有没有跑”，而是AI 结构化质量没有被当成一级控制对象。
• 现在这条链至少已经有了自动门限：min_success_rate=70%、max_fallback_rate=30%、max_failed_source_count=5、max_source_failure_rate=80%。也就是说，问题不再只是“事后看报表”，而是能在 workflow 中被显式标红并指向最吵的源。

11.1.1 为什么很多 FMEA 过了评审却没有真正降风险

现有章节已经把 FMEA 的方法主链讲清，但审核和量产现场真正追问的不是团队会不会填 S/O/D，而是 FMEA 有没有改变设计输出、过程控制、放行证据和后续问题处理。换句话说，FMEA 一旦不能驱动组织行为，它就只是分析文档，不是风险管理。

11.1.1 审核为什么顺着文件链往下追

IATF 16949 和 VDA 6.3 共同关心的是同一件事：风险分析是否被吸收到开发、放行、量产和变更管理里。审核员之所以会从 FMEA 一路追到 Control Plan、作业指导书和客诉闭环，是因为只有这些下游文件和动作真的被改写，风险状态才算真正下降。

• 对安全相关产品，DFMEA 和 PFMEA 不能只是留在工程部门，而要进入特殊批准和放行流程。
• DFMEA 应进入设计输出，PFMEA 应进入制造过程设计输出；它们不是项目结束后补写的附件，而是输出本身的一部分。
• PFMEA 的当前预防措施和当前探测措施，必须被 Control Plan、防错、返工返修规则、统计控制和检验规范吸收；否则表里的 O 和 D 会建立在并不存在的控制上。
• 特殊特性、临时过程变更、量产异常、内部审核、过程审核、管理评审和顾客抱怨，都应能反向追溯到 FMEA 是否更新、措施是否执行、残余风险是否被重新接受。
• VDA 6.3 比 IATF 16949 更强调项目节点和量产交接，因此它会特别检查 FMEA 是否按计划前置启动、生产工厂是否进入团队、以及放行前定义的措施是否已经被证明有效。

11.1.2 一份可运行的 FMEA 项目缺什么

FMEA 失效，通常不是因为团队不会写表，而是因为没人对时机、资源、主持和措施落地负责。七步法只是方法框架；要让它变成稳定产出，还需要一套组织前提把分析活动固定成项目纪律。

• 需要明确的管理层 ownership。管理者既要批准时间和资源，也要对高风险项的措施追踪负责，否则 FMEA 会最先被项目节奏挤掉。
• 需要前置启动时机。无论设计还是过程，FMEA 都应在方案冻结前展开；越晚启动，越容易从预防工具退化成事后解释文件。
• 需要把要求先收齐。法律法规、行业要求、顾客要求、内部标准以及顾客对 FMEA 方法本身的要求，都应在前期显性化。
• 需要跨职能团队和相对中立的主持人。设计、过程、质量、试验和现场经验必须汇到同一张失效链里，主持人则要负责维持问题导向，而不是只负责记录会议纪要。
• 需要默认对不确定性偏保守。没有数据支撑时，发生度和探测度不应凭乐观经验下调，而应等试验、过程能力或量产数据把不确定性收敛掉。
• 需要把措施转成现实动作。纸面上写了防错、验证或检查，不会自动降低任何风险；只有进入计划、执行文件、现场动作并完成有效性验证，风险才会真的下降。

团队角色也要提前分清。项目负责人管整体过程与文档，方法负责人保证步骤、规则和软件正确，内容负责人则对设计事实或工艺事实以及措施执行负责。没有这三种角色分工，FMEA 很容易在出现冲突时退化成谁声音大就听谁。

11.1.3 维护为什么不是补文档

FMEA 维护的本质，不是把旧表格重新存一个版本，而是把新的要求、变化和问题重新写回当前风险模型。只要项目结束后 ownership 断掉、措施没有持续追踪、量产异常和 8D 结论没有反写回去，FMEA 就会在最需要它的时候失真。

• 典型触发至少有三类：出现新情况、发生变化、问题发生并被解决。新要求、新应用、新设计或新过程属于第一类；设计、工艺、材料、法规和顾客要求变更属于第二类；内部不良、客诉、现场失效和跨项目经验教训属于第三类。
• 过程监控要同时盯三件事：关键成员是否真正参与、会议节奏是否稳定、措施是否按时并且有效地落地。缺成员、跑题和拖期，最后会一起把评分做空。
• 当前措施和优化措施都要检查执行状态与效果，不能因为它们已经写在当前栏位里就默认有效。
• 高风险项需要责任人、到期日、实施证据和效果验证；只写一句后续关注，不构成闭环。
• 项目结束时应形成高风险项摘录、措施清单、验证结果和管理层结论，并把后续维护责任移交给长期 owner，而不是把文件归档后就默认风险已经被管理。
• 持续更新既可以由事件触发，也可以按周期回顾触发；两者目标相同，都是让 FMEA 始终代表当前真实状态，而不是某个旧项目阶段的历史快照。

11.1.4 把七步法挂到开发里程碑里，FMEA 才不会漂

很多团队“会讲 FMEA”，但不会把它变成项目动作。真正的区别不在会不会背七步法，而在能不能把七步法挂到开发里程碑、会议节奏、验证计划和问题闭环上。FMEA 一旦脱离这四条链，就会退化成项目后期补写的表格。

更稳妥的做法不是“项目里找时间开一次 FMEA 会”，而是按开发冻结点倒推分析输出。这样每个阶段都知道自己到底要交什么，不会把结构分析拖到原理图冻结后才开始。

11.1.5 一次可运行的 FMEA 评审到底怎么开

把 FMEA 会议开成“边看图边自由讨论”，通常 2 小时后只能得到一堆模糊备注。更有效的方式是把会议拆成会前准备、结构/功能会、失效/评分会、闭环会四个短节奏。

1. 会前准备：项目负责人先发范围、对象层级、图纸 / 流程图、已知问题、上轮 8D、已有 DV/PV 结论，不带这些输入不要开会。
2. 结构 / 功能会：只做 Step 1~3，不提前打分。输出是边界、结构树、接口和功能句，确保每个人分析的是同一个对象。
3. 失效 / 评分会：围绕 focus element 逐行写 Effect -> Mode -> Cause，只允许在失效链完整后再评 S/O/D/AP。
4. 闭环会：把高 AP 行逐条落到 ECN、图样、规范、DVP&R、Control Plan、现场动作或 8D，并指定 owner / due date / evidence。

一个简单但非常有用的纪律是：每次会议结束只允许留下“可执行动作”，不允许留下“以后关注一下”。后者几乎等于没有 action。

11.1.2 DFMEA 怎样把七步法落到可验证的设计闭环

现有页已经解释了 DFMEA 的表结构和失效三层结构，但实务上真正决定评分是否可信的，不是第 5 步打分本身，而是前四步有没有把要求、结构、功能和失效对象定义准确。DFMEA 一旦在前面就分析错对象，后面的 S/O/D 只是在给模糊印象打分。

11.2.1 为什么 Step 1 到 Step 4 决定后面评分是否可信

DFMEA 的前四步不是行政铺垫，而是后续风险分析的因果基础。团队只有先把谁来满足要求、它要完成什么功能、它会怎样失效三件事说清，后面的评分才有稳定锚点。

• 策划和准备先看要求与范围。要求来源至少包括法律法规、行业要求、顾客要求和内部要求；范围则要按新设计、设计变更或问题解决三种触发情形显性定义。
• Step 1 里有几道问题不能跳过：客户到底在向你买什么、是否出现新要求、你是否真的拥有 design control、接口设计归谁负责、以及这次分析到底是 system / subsystem / component 哪一层。答不清这些，后面的行项目再完整也只是写错对象。
• 范围定义既要写清分析什么，也要写清明确不分析什么。对成熟产品，更稳妥的做法通常不是从空白表开始，而是先判定能否继承 foundation / family / similar product DFMEA 作为 baseline，再只对新增结构、功能和工况补差异。
• 更细一点说，边界内只应放本团队真正设计或控制的对象；边界里的块通常比当前分析层级低一级。存在但不属于本次分析的 carry-over 元素可以出现，但要显式标记不分析，否则评审时很容易把责任边界看错。
• 结构分析回答谁来实现要求。它通常同时借助方框图和结构树，先画清内部元素、外部元素、交互作用和系统边界，再保证至少有三层结构承接后面的影响、模式和原因。
• Step 2 不能只画“盒子”，还要显式扫接口。手册把 DFMEA 常见接口至少拆成五类：物理连接、材料交换、能量传递、数据交换、人机接口；此外还要单独看无接触但会出问题的 static / dynamic clearance。很多交互失效并不在元件内部，而在这些接口上。
• 功能分析回答这些结构如何实现要求。更稳妥的写法是动词加名词加要求，把主要功能、次要功能、自我保护功能和防止损害功能都纳入，而不是只写主功能。
• 不能自然写成功能的约束，应转成特性，例如尺寸、材料、间隙、耐压或表面要求；这些特性往往正是后续失效原因的真实落点。
• 对复杂或创新程度高的对象，应借参数图把输入输出、噪声因素和控制因素显性化，因为很多失效不是在标称工况下出现，而是在老化、误用、环境应力或系统交互下暴露；这些信息同时也是后续试验计划的重要输入。
• 失效分析本质上是把功能网络反转成失效链。团队要先枚举范围类、偏差类、时间类和负面作用类失效，再把它们沿上下层功能因果连接成原因、模式和影响。
• 失效语句应尽量落到根本原因层，而不只停在症状层。例如比起写定位柱限制电路板移动过大，更应写定位柱尺寸设计过小导致电路板移动过大。
• 失效语句也必须避免空泛结论。像 not fulfilled、not OK、defective 这类泛词，不足以支撑后面的 S/O/D 评分，因为它们没有把失效对象、偏离方向和工况讲清。

11.2.2 当前措施、验证计划和规格文件如何接住失效链

失效链建立之后，DFMEA 才进入当前措施、评分和优化动作。但这里最容易做错的，是把控制措施提前写进失效链，或者把验证动作留在会议纪要里而没有进入正式计划。这样一来，评分和实际执行就会再次分离。

• 连接失效时，应先沿功能因果寻找上层影响和下层原因，而不是先看当前有哪些测试或经验措施。
• 预防措施通常来自五类来源：设计原理或规则、经验教训复用、因果研究、设计防错和失效安全设计。它们直接作用于失效原因，因此主要影响 O。
• 当前预防控制必须写成可追溯的现行依据，例如设计规范编号、仿真与容差计算方法、材料/螺纹/热处理规范、传感器性能规范、冗余设计或已验证过的 carry-over 设计。只写“proven material”“lessons learned” 这种泛词，不足以支撑 O 的评分。
• 探测措施要分清边界。零件、模块和整机的设计验证属于 DFMEA 探测；制造过程中的尺寸检查属于生产探测；运行时的监视与响应则属于后文的 FMEA-MSR，不能混充当前探测措施。
• 当前探测控制同样必须写成能落到具体验证活动的名字，例如某个 burst test、environmental test、endurance test、HIL / SIL、DOE 或实验室测量，并最好带测试编号、条款或试验计划引用。只写 test、lab test 不足以支撑 D 的评分。
• 还没有进入当前验证库、只是团队准备新增的验证动作，不能提前写进 current control；它们应进入右侧 action，并在真正执行且证明确实能抓到该失效后，才有资格回填成当前探测控制。
• 手册对 action 和 current control 的边界也画得很硬：已经在当前 prevention / detection controls 中计划并计入初始风险判断的活动，不应再作为新 action 重复出现；真正的 action 必须是新的、具体的、可测量的承诺。
• 严重度看的是最严重失效影响；发生度看的是失效原因及其生命周期概率；探测度看的是方法的能力和时机。AP 的意义是指示措施优先级，而不是制造一个可以机械切线的绝对风险值。
• 所有测试型措施都应被转进正式验证计划，至少写清测试编号、方法、接受准则、样本、负责人、阶段和时间；否则 DFMEA 输出无法稳定落进 DV/PV。
• 图样、规格书和设计文件必须与 DFMEA 保持一致。如果 FMEA 定义了一条设计约束，而规格文件里没有；或者规格文件引入了 FMEA 从未分析过的新设计，两者中至少有一边已经失真。

11.2.3 设计变更和 8D 之后应从哪一步重开

DFMEA 更新最容易犯的错，不是没开会，而是主题和起始步骤一开始就判错了。更稳妥的做法，是先看变化打到了哪一层对象，再决定从七步法的哪一步重开，而不是不分情况地从头重写或只补一行注释。

• 如果变化打到了结构元素、模块或承担要求的物理对象，应从结构分析重开。
• 如果变化打到了新要求、新功能、新特性或新应用，应从功能分析重开。
• 如果出现了新的失效、变化的失效，或者现实问题已经暴露出旧失效链没有覆盖到的对象，应从失效分析重开。
• 如果变化只发生在预防措施或探测措施，则至少要从风险分析重走，因为 O、D 和 AP 已经被直接改写。
• 8D 可以直接映射进 DFMEA：D2 帮团队定位失效模式，D4 提供根因，D6 给出纠正措施及其确认结果，D7 则要求把这些新认知回写到 FMEA、标准和经验教训库。
• 只有已经执行并验证有效的措施，才有资格进入当前控制基线；尚未完成的措施不能提前写成当前措施，否则文档会再次跑到实物前面去。
• 旧的 S/O/D 不应在版本演进中直接消失。更稳妥的做法是保留原评分或至少保留可追溯版本历史，再在 action 完成后记录新评分；但如果把某份 DFMEA 提升为 foundation / family / generic DFMEA 的新起点，则允许按新基线重置起始评分。

11.2.4 一行 DFMEA 应该怎样从左到右写

新人最容易做错的，不是评分，而是把一行写成“症状 + 感觉 + 经验判断”。更稳妥的写法是强制自己按下面顺序落笔：

1. 先写功能：必须是“动词 + 名词 + 量化要求”，例如“当 Vdc > 450 V 时在 2 µs 内关断驱动”。
2. 再写失效模式：必须是功能丢失或偏离，例如“过压时未触发关断”。
3. 再写失效效应：必须是上一级或客户真正看到的后果，例如“功率器件持续承压，可能进入二次击穿”。
4. 再写失效原因：必须落到物理或工程对象，例如“分压上臂电阻开路导致比较器输入偏低”。
5. 再写当前预防 / 探测控制：必须能追溯到现行规范、仿真、测试编号或现场控制，不能写泛词。
6. 最后才写 S/O/D/AP 和 action：action 必须改变设计、验证或控制，而不是重复当前控制。

判断一行写得对不对，可以问三个问题：

• 不看会议纪要，只看这一行，后来的人能不能复现这条逻辑？
• 这条 cause 能不能被试验或现场数据证明？
• 这条 action 完成后，O 或 D 到底为什么会下降？

11.1.3 PFMEA 怎样把过程风险真正接到量产控制

PFMEA 的难点通常不在于知道它与 Control Plan 有关，而在于团队常常不知道流程应拆到多细、过程特性和产品特性怎么分、以及哪些控制应该写进当前基线。对量产过程来说，PFMEA 只有把风险对象稳定地挂到真实工序和真实控制上，才会变成现场有执行意义的文档。

11.3.1 为什么 PFMEA 先看流程结构而不是先打分

PFMEA 分析的不是历史问题清单，而是从来料到发货这条过程链还会怎样把好设计做坏。既然风险首先沿物流和工序顺序传播，团队就必须先把流程主线画清，再谈功能、失效和评分。

• 触发条件同样至少有三类：新过程导入、现有过程变更，以及过程问题发生并被解决之后需要把教训写回控制系统。
• 策划和准备要先把法律法规、行业要求、顾客要求、内部工艺规范以及顾客对 PFMEA 方法本身的要求收齐。
• 范围要按新过程、过程变更和问题触发三种情形显性定义，并优先深挖安全影响大、创新程度高、可靠性要求高的工序。
• 进度上，PFMEA 应在理解过程概念后尽早启动，并在过程冻结和 PPAP/PPA 放行前形成足够结论。
• 结构分析首先用流程图把产品真实经过的增值、检查、运输、存储、返工和临时过程画出来；很多量产风险的根因，不是团队不会评分，而是某个真实存在的过程从来没有进入分析范围。
• PFMEA 通常至少要形成三层结构，例如整条流程、单个过程、工作元素；下层工作元素再落到人、机、料、法、环这些真实承担对象上。

11.3.2 过程功能、过程特性和失效链如何对应

流程结构画清之后，团队接下来要回答的是每道工序为什么存在、靠谁实现、以及它会怎样把产品做坏。这里最关键的不是多列几条问题，而是把过程功能、过程特性和失效链稳定地绑在一起。

• 过程功能应写成动词加名词加要求，例如按照图样要求把印制电路板与正确型号的盖体卡扣到位，而不是直接把作业步骤抄成操作说明。
• 过程功能和人员动作要分层。上层工序回答输出为什么成立，下层人员、设备和夹具功能才回答它们分别做了什么。
• 顺着结构和功能之间做逻辑追问时，方向不能混：顺着“what does it do”往上看，应从 process work element 回到 process step 和 process item；顺着“how is it implemented”往下看，才从 process item 展开到 step 与 work element。
• 产品特性是最终留在零件或总成上的结果，过程特性则是工序内部维持的参数与条件；过程特性往往是原因，产品特性则是结果，两者都要显性化。
• 对复杂工序，应借参数图或同样的思路把人员差异、设备退化、物料波动、环境变化和异常停机后的状态都纳入，因为量产问题很多都只在这些噪声因素下暴露。
• 失效分析要把功能网络反转成原因、模式和影响三层链。过程层失效看输出问题，人员层失效看动作错误，机器或夹具层失效则尽量下探到真正可治理的根因。
• 当前预防措施通常来自设计保证、作业指导、培训、维护保养、过程能力和防错；当前探测措施则分别布在原因层、模式层和最终输出层。

11.3.3 Control Plan 为什么是 PFMEA 的执行面

PFMEA 负责识别过程风险，Control Plan 负责把这些风险翻译成每天都要执行的控制动作。两者如果断开，PFMEA 里的当前探测和当前预防就会变成写给审核员看的文字，而不是现场真正存在的控制。

• Control Plan 至少要展开过程编号、过程名称、设备与工装、产品特性、过程特性、规格或公差、测量技术、样本策略、控制方法和反应计划。
• 过程流程图、PFMEA、Control Plan、作业指导书和保养文件应使用同一套过程编号和同一套特殊特性标识，否则文件链会断。
• 产品特性和过程特性通常应分别占行，因为它们的标准、测量方式、频次和反应动作往往不同。
• 反应计划不能只写通知主管，更稳妥的写法是把停线、隔离、复判、处置可疑品和升级路径写清。
• 特殊特性必须从 PFMEA 流向图样、Control Plan 和现场执行文件；如果顾客符号与企业内部符号不同，还要保留转换关系。
• 高严重度项优先考虑改变最终后果，其次是用预防类措施降发生度，最后再用更早、更可靠的检测去降探测度。优化改进要按 PDCA 跟踪，而不是只在右侧 action 栏记一句已经优化。
• 只有已经执行并验证有效的措施，才能进入当前控制基线和 Control Plan；未完成措施不能被提前算作当前能力。

11.3.4 自动化变更为什么必须重走被影响步骤

用机器人替代人工上料这一类过程变更，最容易让团队误以为只要把发生度往下调就够了。实际上，自动化改变的是承担过程功能的对象、失效形态和批量传播速度，因此至少要把被影响的结构、功能、失效和控制重新分析一遍。

• 当人工上料变成机器人上料时，下层功能会从作业员直接放板，改成作业员放置料盒加机器人定位搬运；这意味着结构分析和功能网络都必须重画。
• 自动化通常减少部分人因失效，但会新增夹爪偏移、磨损、污染、掉落、位置错误等设备状态失效；这些原因会汇聚到同一上层过程模式，而不是自动消失。
• 维护保养主要作用于 O，只能减少原因发生；如果探测仍停留在末端人工目检，D 依然会偏差，因为自动化一旦出错往往会更快制造批量问题。
• 更有效的改进通常是把检测前移到当站，例如传感器或自动检测确认放置位置是否正确，而不是只依赖末端人工发现。
• 这类变更完成后，结果文件里至少应显式记录变更主题、新增或删除的功能、新失效链、当前控制变化、验证证据和管理层批准结论。

11.1.4 什么时候必须把运行时监视单独拉成 FMEA-MSR

普通 DFMEA 关心的是设计发布前如何预防和验证失效，但有些产品的安全目标并不只靠开发阶段的设计正确性成立，而是依赖用户使用阶段仍在持续工作的监视和响应闭环。只要安全后果要靠这条运行时链路去拦住，团队就不能把它藏在普通探测措施里，而应单独拉成 FMEA-MSR。

11.4.1 DFMEA 为什么不足以覆盖监视响应安全链

一旦产品必须依靠传感器、控制器和执行机构在运行中自动发现偏差并采取动作，开发阶段做过验证并不等于最终风险已经受控。此时团队真正需要分析的对象，不再只是设计本身会不会错，而是监视、判断和响应这条第二道防线会不会失效。

• 典型对象是由传感器、电子控制单元和执行机构组成的监视响应链。
• 典型场景是防夹、防失控、防过热、防高压危险等必须在用户使用阶段自动检测并立刻响应的功能。
• 这类分析在结构、功能和失效网络上仍然遵循七步法，只是对象从设计正确性换成了运行时安全闭环本身。
• 团队要关注的核心问题变成：一旦原始故障真的发生，系统还有没有第二次机会把严重后果挡住。

11.4.2 S/F/M 与 S/O/D 的口径差异是什么

FMEA-MSR 仍然保留严重度，但把研发阶段更常用的发生度和探测度，替换成更贴近运行阶段的频度和监视度。这个替换不是换名字，而是明确分析边界已经从开发过程转到用户生命周期。

• S 仍然看最终影响的严重程度，口径与 DFMEA 一致。
• F 看的是相关原因在真实使用寿命中的出现可能性，而不是研发团队对设计成熟度的主观印象。
• M 看的是监视和系统响应这套组合在用户使用时能否及时发现并拦住后果；如果监视和响应强弱不一致，应按更弱的一侧判断。
• 这类判断必须带时间边界。按 errata 修正后的口径，如果没有 monitoring control，或 monitoring / response 不能在 Fault Tolerant Time Interval 内完成，就应按 M=10 处理，而不是因为系统“最终会报警”就乐观降分。
• 只有在工况暴露比例有充分依据时，F 才能按暴露机会适度下调；否则不应凭乐观经验降低频度。
• AP 仍然用于指示措施优先级，只是此时优先改进的对象已经变成监视链和响应链本身，而不是普通开发阶段的验证动作。

11.4.3 电动车窗案例真正说明了什么

电动车窗防夹案例说明，开发阶段已经选了保守器件、也做过测试，并不会自动把运行时安全风险降到可接受。只要最终用户使用中仍然要靠监视和响应去避免伤害，团队就必须单独证明这条闭环本身也可靠。

• 如果微处理器误读霍尔方向信号，控制器就可能不能及时停止或反转电机，向上推就会变成防夹功能失效并带来用户手或脖子被夹的危险。
• 前期测试和器件选型可以影响团队对原因频度的判断，但不会自动降低严重度，也不会自动提升运行时的监视能力。
• 真正改变风险终点的，是在系统里补入真实性检查与及时响应。一旦监视结果与真实运动状态不一致，系统立刻停止或反转电机，终点就有机会从伤害降到舒适性下降或需要手工恢复。
• 只要产品安全依赖这类第二次机会成立，这条链就属于 FMEA-MSR 的分析对象，而不应被隐藏在普通 DFMEA 的探测栏里。