小馬混跡汽車零部件行業6年有余，主要從事娛樂系統硬件設計。就這段工作經驗里我所接觸到的公司里，能認真分析設計DFMEA的硬件工程師確實比較少。雖然在外企，硬件設計流程中都有需要DFMEA的文檔輸出以及跟客戶主機廠之間的評審，但是國內員工對DFMEA不管是在熟悉度，重視度上都不及國外員工。可能是因為國內主機廠客戶本身對於這方面的失效分析也並沒有足夠的重視？小馬沒有去做太多的調查，不敢隨便斷言。這幾天小馬在做一個項目時候利用機會研究了一下DFMEA，有一點感想和理解，在這里稍微做點分享，如果有理解錯誤的地方，煩請指正。
我只從我理解的幾個方面做如下介紹：
1, 什么是DFMEA
下面引用一下度娘百科的內容.
在設計和制造產品時，FMEA是一種可靠性設計的重要方法。它實際上是FMA（故障模式分析）和FEA（故障影響分析）的組合。它對各種可能的風險進行評價、分析，以便在現有技術的基礎上消除這些風險或將這些風險減小到可接受的水平。及時性是成功實施FMEA的最重要因素之一，它是一個“事前的行為”，而不是“事后的行為”。為達到最佳效益，FMEA必須在故障模式被納入產品之前進行。
DFMEA則是Design Failure Mode and Effects Analysis的縮寫，是在設計前期對設計上可能存在的失效模式和原因的分析。
2，為什么要設計DFMEA
這里從功能上開始闡述。我們設計一款產品，最終是要流向市場面向用戶，用戶所關心的顯示功能是否能實現。一款產品如果連最基本的共能實現都做不到，我想已經沒有必要再稱之為產品了。
既然有功能，那必然會存在功能實現不了的時候，我們稱之為功能失效。
功能失效的原因是什么？
產品功能是由各個模塊的功能堆疊而成，而各個功能模塊又是由模塊里的各個原件組成。順着這個思路，從功能失效分析>模塊失效分析>組成元件分析，一步一步找出失效的根本原因。
分析失效原因的目的是什么？
這就要回到我們為什么要設計DFMEA這個問題上了。DFMEA的主要目的是：
一， 為了在產品功能失效時有理論和實際的文檔可以查詢用以得知功能失效的根本原因，從一定程度上，對於生產過程鍾出現的失效項可以快速排查維修以節省單件分析時間。
二， 為了實現設計和生產過程成中對潛在失效的預防並對各個失效項做出相應的預防措施以降低失效率和不良率。
從這兩點上，設計一個完整可靠的DFMEA將可以為企業節省很大的質量管控成本。
3,DFMEA的結構，如何設計DFMEA
分析DFMEA, 就是從功能角度去頭腦風暴產品功能可能存在哪些失效項，進而分析功能失效的原因。
從層級上分，產品有失效影響，失效模式，失效原因。失效影響主要針對功能來講，而失效模式則是失效的現象，失效原因則是引起失效模式的深層次根源。DFMEA設計一般從失效模式分析，因為它描述的時現象，進而容易去分析這個現象會產生什么影響，是因為什么原因產生。
從表達順序上一般有：
a， 失效模式>失效影響>失效原因
b， 失效影響>失效模式>失效原因
下面分享的實例將會按照第二種表達順序來設計DFMEA的樹形結構。
按照b表達順序設計的樹形結構如下：
分析的正向思路如下：
I，設計評審，根據圖紙去分析每個元件和相關電路
II，評估可能存在的失效模式並列出
III， 針對b項可能存在的失效模式，列出可能影響到b項失效模式的影響
IV， 評估每個失效項的發生度（occurance），可檢測度（detection）以及因為失效項和失效模式產生影響的嚴重度（severity），計算RPN（Risk Priority Number, RPN=S*O*D）
V， 根據d項里的SOD和失效項確定預防和檢測措施
簡化成2個步驟：
第一步，分析產品功能，產品的功能(function of product...)是由哪些子模塊功能(function of part A,B...)堆疊？子模塊功能由哪些元件(design of part A,B...)設計而成？
第二步，產品的功能會產生哪些失效（function failure1, function failure2...function failure x), 這些功能失效是因為子模塊哪些功能的失效（function of part A failure A1, function of part A failure b1, function of part B failure A1...)，子模塊失效是因為哪些設計導致（Design part A failure A2， Design part A failure B2...)
然而作為硬件工程師，在做DFMEA過程中經常會采用逆向分析來設計DFMEA，原因在於，硬件工程師對底層的電路設計和元件特性更了解，從這些特性去分析可能存在的失效項逆推出可能存在的失效模式，再而推出上一層的功能失效和失效影響。
4，簡單的實例分析：
以汽車安全氣囊控制器的flexray電路為例：
Flexray在汽車安全氣囊控制器內部的功能主要是與車上其他ECU通信，硬件圖如下
其DFMEA 草稿如下：
a， 功能和失效項如下（影響）：
b ，子功能模塊和失效（模式，現象）：
c， 底層硬件設計和失效（原因）：
I, 硬件層次1
II， 硬件層次2
III, 硬件層次3（根本原因）
這些失效影響，模式，原因需要構成一個網絡，來闡明是什么原因引起的失效模式和失效影響。 以靜電防護為例
D115 為防靜電TVS，如果TVS損壞則會帶來防護ESD不利的影響，失效網絡關系圖如下：
按照底層往上層的思路分析，會得到如下一條網絡：
產品不滿足客戶EMC,ESD要求<Flex ray 不滿足客戶EMC，ESD要求<Flexray硬件無法防護ESD<Flexray電路TVS 損壞斷開。
當然不滿足客戶需求的原因由很多，這需要工程師對每個元件都做到詳細的分析。當無法滿足客戶ESD，EMC需求是，可以對着DFMEA的思路順向查找失效原因。
以上是小馬這幾天對DFMEA的淺薄理解，文字水平有限，也沒有先理好思路再下筆，純粹想到哪寫到哪，各位看官如果有不同的意見和建議，望指正。