跳至內容

失效模式佮影響分析

出自Taiwan Tongues 台語維基
這是此頁批准,以及是最近的修訂。

失效模式佮影響分析(英文:Failure mode and effects analysisFMEA), 閣叫做失效的模式佮後果的分析失效模式佮效應分析故障模式佮後果的分析抑是故障模式佮效應分析等,是一種操作規程,旨咧對系統範圍內藏佇的失效模式加以分析,通好照這个嚴重的程度加以分類,抑是確定失效對這个系統的影響。FMEA 廣泛應用佇製造業產品性命周期的各階段;而且,FMEA 佇服務行業的應用嘛佇日本增加。失效原因是講加工處理、設計過程當中抑是項目 / 物品(英文:_ item _)本身存在的任何錯誤抑是缺陷,尤其是遐的將會對消費者造成影響的錯誤抑是缺陷;失效的原因會當分做是藏佇的佮實際的。影響分析指的是對遮失效之處的調查研究。

基本術語

失效模式(閣號做故障模式)

觀察失效的時陣所採取的方式;一般指出的是失效的發生方式的。

失效影響(閣號做失效後果、故障後果)

失效對某物件 / 項目(英文:_ item _)之操作、功能抑是功能性,或者是狀態所造成的直接後果。

定級別(閣講做約定級)

代表物品 / 項目複雜性的一種標識符。複雜性隨級數接近佇一而增加。

局部影響:干焦忝和所分析的物件 / 項目的失效影響。

上階影響:忝連鞭一約定級別的失效影響。

尾溜影響:忝和上懸的定級別抑是整個系統的失效影響。

失效原因(閣講號做故障原因)

作為失效之根本原因的,抑是引起失效的某一个過程,設計的、加工處理、質量或者是零部件應用的方面所存在的缺陷

嚴重程度(閣號做嚴重度)

失效的後果。嚴重程度考慮的是終其尾可能出現的損傷程度、財產損失抑是系統歹所決定的,失效上䆀的藏佇後果。

歷史

對逐擺若無效 / 故障內底習得經驗佮教訓,是一个代價衝甲掠袂牢閣了時間的代誌,而且 FMEA 著愛共伊講一種用來研究失效 / 故障的,閣較替系統的方法。仝款,上好首先進行一寡思維實驗。

二十世紀四空年代尾期,美國空軍正式採用矣 FMEA。後來,航天技術 / 火箭製造領域將 FMEA 用佇咧小項本情形下避免代價衝懸的火箭技術發生差錯。其中的一个例就是阿波羅太空計劃。二十世紀六空年代,佇開發出共太空人送去月球閣安全倒轉來地球的手段的同時,FMEA 得著初步的推動佮發展。二十世紀七空年代尾期,福特汽車公司伊佇咧平托事件了後,出於安全佮法規方面的考慮,佇咧汽車行業採用矣 FMEA。同時,𪜶閣利用 FMEA 來改進生產佮設計做工課。

就算上早是由軍事領域所建立的方法,猶毋過 FMEA 方法學這陣已經廣泛應用於各種各樣的行業,包括半導體加工、飲食服務、塑料製造、軟體佮醫療保健行業。佇設計佮加工處理的格式方面,FMEA 已經結合著產品質量先期策劃(APQP), 通好提供基本的風險化減手段佮實現對預防策略的時機選擇。汽車行業行動工作組(AIAG)要求咱佇咧汽車的 APQP 過程中運用 FMEA 方法,並且閣發布了詳細的一份關於如何應用這一方法的手冊。對逐項藏佇遮的原因,攏愛針對其實對產品抑是加工處理過程的影響抑若加以考慮,並且根據相應的風險,確定所欲採取的行動措施,並佇咧行動的措施完成了後對風險重新加以評估。Toyota 已經進一步將這種的方法佮家己的徛無效模式的設計審核(DRBFM)方法敆做伙。這馬乎,這一方法猶同時咧得著美國品質協會的支持。美國品質協會針對應用這種方法來提供若是干的詳細指南。

實施

佇咧 FMEA 之中,失效之優先級別確定依據的是𪜶的後果到底有偌爾仔嚴重,𪜶到底出現甲偌爾頻繁以及予人發現到底有偌爾仔簡單。FMEA 同時閣記載當當前對失效風險的了解佮行動措施,通好用繼續改進。佇設計階段,FMEA 應用旨咧避免將來發生失效。了後,佇咧製程控制當中猶閣有佇咧相應過程的不斷運行進前佮過程當中,嘛攏會去用著 FMEA。佇理想的情形下,佇上早的概念設計階段就開始使用 FMEA,並且繼續加使用,一直到貫穿產品抑是服務的規个性命周期。

FMEA 的目的佇對優先級別上懸的失效對手,採取行動措施,對而消除或者是減少失效。FMEA 閣會當用佇評價風險管理優先級別,通好來緩和已經造成威脅的薄弱部位。FMEA 對選擇補救措施有幫贊,對減少因為系統失效(故障)所造成的若干生命周期後果(風險)的累積效應按呢。

目前,真濟正規的品管體系嘛咧採用 FMEA,比如講 QS 交九千抑是 IATF 一爿六千九百四十九(原來的 ISO / TS 一爿六千九百四十九)。

FMEA 佇設計工作內底的應用

咧處理失效模式佮其相關的原因的時陣,FMEA 會當提供分析手段。佇咧考慮設計內底可能存在的失效之時,比如講安全、成本、性能、品質佮可靠性,為著避免這寡失效的發生,工程師會當利用 FMEA,得著大量關於如何變閣較開發 / 製造過程的信息。FMEA 提供的是一種簡便易用的,用來確定到底佗一種風險上蓋予人煩惱的工具,從而且會使佇問題真正發生進前,採取相應的行動措施,避免伊的發生。遮的規格講明的編制,將會保證相應的產品會當滿足預定的需求。

準備工課

FMEA 的過程簡單現矣。FMEA 分做三个主要的階段。佇遮的階段之中,愛確定合適合的行動措施。猶毋過,佇咧 FMEA 開始進前,重要一點就是,欲完成一寡前期準備工課,通好確定這改分析有穩健性,而且其中包括著既往的歷史。

穩健性分析會當利用接口矩陣(Interface Matrix)、 邊界圖(Boundary Diagram,簡稱 B 圖)佮參數圖來(Parameter Diagram,簡稱 P 圖)來完成。真濟失效問題往往是因為噪音的因素以及佮其他的零部件佮 / 抑是系統之間共享的接口所造成的,因為工程師傾向共𪜶集中注意所直接控制的物件。

首先,有必要對當前系統佮其實功能加做伙描述。透徹的理解會簡省進一步的分析工作。按呢乎,工程師就知影講,到底系統的佗一寡用法是人需要的,按怎無影。重要的是愛同時考慮著預期佮意外用法。意外用法屬於是不利環境的一種形式。

紲落來伊,需要為系統創建一幅框圖。這个圖樣就用於是描述主要的組件抑是過程程程佮𪜶之間是按怎關聯起來的。遮的就是所謂的邏輯關係,而且 FMEA 就是圍踅遮的關係而進行落去的。建立一个編碼系統會對標識無仝款的系統討素。FMEA 之中應當初終包括有上述框圖。

佇咧開始進行這實際的 FMEA 進前,閣需要創建一份工課表示,其中包括的是有關做前系統的重要信息,就是修訂日期或者是組件名稱。佇咧這張工課表中,應當依照上述框圖,照合邏輯的方式,列出分析對象的所有的項目抑是功能。

弄青一下 : 嚴重程度

根據功能的需求佮其影響來確定所有的失效模式。失效模式的例有:電路短路、生鉎抑是變形。重要的是愛注意著,一个組件內底失效模式會當致使另外一組物件內底失效模式。所以,對逐種無效的模式來講,平均應當採用技術語,並且按功能列出。此後,需要加以考慮的是逐種失效模式的最終影響。失效的影響予人定義做,按照用戶的認知方式,失效模式對系統功能產生影響的結果。按呢乎,就按呢用一戶所可能看著抑是經歷的狀況,來描寫遮的影響。失效影響的例有:性能下降、噪音,甚至對用戶的傷害。對逐種影響,分別攏予一个取值為一(無危險)到十(危重)之間的嚴重程度。但是類的數值對工程師排定失效模式佮其影響閣較緊急次序。若某影響的嚴重程度值做九抑是十,是應當考慮採取行動措施,雖然可能通過消除這間失效模式,或者是保護用戶免受著影響,來變更相應的設計。嚴重程度分級九抑是十一般保留用佇咧那些會對用戶造成傷害抑是用其他的方式引起訴訟的影響。

行二 : 出現頻率

佇這步內底,需要考慮失效的原因以及伊所出現的頻數。這項工課會當通過檢查類似的產品抑是過程佮已經記錄佇案件的遐的相關的失效情形來完成。失效原因予人看做設計缺陷。對無效模式所有藏佇的原因,均應當加起來確定佮記載。仝款,遮嘛應當採用技術語來講。原因的例有:錯誤的算法、過懸的電壓或者不當的操作 / 做工課條件。仝款,嘛會當替逐種失效模式予一个範圍做一種~十的概率值(O)。 若出現頻度懸(是概率值 > 四的非安全失效模式佮第一步的嚴重程度值為九或者是十而且概率值 > 一時), 就需要確定出行動措施。這步叫做 FMEA 過程的幼化部份。另外咧,閣會當將出現頻度定義做百分數(%)。 若是發生某種非安全問題的比例不足百分之一,按呢就會當予伊數值一。這決定佇產品佮客戶規格說明。

弄花三 : 檢查

做一旦確定矣適當的行動措施,需要做的一件工課就是欲測試𪜶的效能。同時,猶閣需要進行設計驗證。而且,閣需要選擇合適的檢查方法。首先,工程師應當關注當前對系統所採取的控制措施,也就是遐的防止失效模式發生或者是佇失效的問題衰及客戶進前予以前發現。了後,應當確定會當或者是已經用於類似系統的,旨咧發現失效問題的測試、分析、監控佮其他的技術方法。根據遮的控制措施,工程師會當了解著某一種失效的問題會當熟似別抑是發現的可能性到底有偌大。前兩步的逐種組合的形式攏共得著一个發現指數(D)。 該指數表示的是,預定的測試抑是檢查工課咧消除欠點抑是發現失效模式方面的能力。

佇完成上述三个基本步數了後,愛計算的就是風險優先級數(英文:Risk Priority Numbers,RPN)。

風險優先級數

RPN 佇選擇防範失效模式的行動措施方面並無發揮啥物要緊作用。𪜶閣較大程度上是屬於評價遮的行動措施方面的追值。

佇咧對嚴重程度、出現頻度佮易發現性進行分級了後,只需要共這三个數值乘起來,就會使得著 RPN:

對規个過程佮 / 抑是設計來講,這是一項著愛完成的工課。一旦完成,上大的街仔路的確定工課就會變做輕鬆。就糾正措施來講,RPN 上懸的失效模式應當得著上懸的優先級別。這就是講,嚴重程度值上懸的失效模式並無一定就應該第一先加以處理。代先著愛做處理的可能是遐的嚴重程度相對較低,毋過閣較捷發生而且無蓋好發現的失效問題,

咧分配遮的數值了後,欲記錄下配有目標、責任猶閣有實施日期的行動建議。遮的行動措施會當包括具體的檢查、測試抑是質量程序、重新設計(就是選擇新的組件)、 增加閣較濟的工作佮限制環境壓力抑是工作的範圍。一旦咧設計 / 過程之中實施了遮的行動措施了後,就應當檢查新的 RPN,通好確認改善狀況。為著方便會當看著,往往會共遮的測試呈現做圖樣。不管時,只要設計抑是過程發生了變化,就應當對 FMEA 更新。

合邏輯就是閣重要的幾點就是:


* 努力消除失效模式(有一寡失效預防起來欲比其他的閣較容易)
  • 上大程度降低無效的嚴重程度
  • 降低失效模式的出現頻度
  • 改進檢查發現工課

FMEA 的時機安排

只要是下列情形,均應當對 FMEA 更新:


* 逐禮拜的開始(新產品 / 製程)
  • 對操作條件作出變更
  • 對設計作出變更
  • 建立新的法律抑是規章制度
  • 消費者反饋表明佇咧某一種問題

FMEA 的用途

* 建立會當實現失效可能性上小化的系統需求。
  • 建立系統設計佮測試的方法,確保相應的失效著愛以消除。
  • 評價消費者需求,確保遮的需求並袂造成藏佇的失效。
  • 識別促成失效的某一寡設計特性,閣上大程度地減少消除相應的影響。
  • 佮蹤佮管理設計內底的藏佇咧風險。這對未來的項目有幫贊拄著仝款的失效。
  • 確保可能出現的任何失效攏袂傷害著消費者或者是嚴重影響系統。

優點

* 改善產品 / 過程的品質、可靠度佮安全性
  • 改善公司的形象佮競爭力
  • 提懸用戶滿意度
  • 減少系統開發作穡的時間佮成本
  • 搜集訊息,來減少未來的失效,得著工程設計智識
  • 減少出現報單問題的可能性
  • 早期發現講、確定和消除藏佇咧的失效模式
  • 重點問題的防範
  • 上細膩程度減少轉來期變佮其相關的成本
  • 促進團隊合作以及無仝部門之間的意見交換

局限性

既然 FMEA 實際上依賴佇遐負責調查產品失效問題的委員會成員,𪜶關於著既往失效問題的經驗也就制約 FMEA。若某種失效模式無法度著以確定,按呢就需要遐的了解濟濟無仝類型產品失效問題的顧問來提供外部協助。因此講,FMEA 屬於是閣較大規模的品質管制體系的組成部份;其中,文檔記錄對實施工作來講具有至關要的作用。佇工程技術鑑定(forensic engineering,鑑別工程)佮失效分析(抑是故障分析)領域,目前已經有一般性的文章佮詳細的出版物。佇產品完整性評價工作內底應用 FMEA,這馬已經是真濟具體的國家標準佮國際標準的一般要求。

若做為一種家己落型的工具,FMEA 凡勢會當發現系統內底的主要失效模式。故障樹分析(英文:Fault tree analysis,FTA)閣較適合佇自上才下型分析工作。若做為一種「自下而上型」工具,FMEA 會當著 FTA 起來增強抑是補充作用,發現佮確定濟足濟的,致使頂層症狀的原因佮失效模式。FMEA 無法度發現遐的牽涉著仝一子系統內底有真濟種失效的問題的複雜失效模式,或者是報告特定失效模式適合頂頭級子系統抑是系統的預期失效間隔。

此外,嚴重程度、出現頻度佮發現難度分級之間相乘,有可能會造成級莫倒反現象,也嚴重程度較輕的失效模式所得著的 RPN 誠嚴重會失效模式有嚴重。發生這款現象的原因就是講,遮的分級屬於是等級型標度(ordinal scale numbers), 毋過對𪜶來講,乘法並毋是一種有效的運算方法。等級型秩次只是表示,一種秩次比並好抑是講另外一秩次,但是並無講究竟到啥物程度。比如講,秩次為「二」並毋是講會害的程度是秩次為「一」時的兩倍,抑是秩次為著「八」並毋是講會害的程度是秩次為「四」時的兩倍。猶毋過,欲講乘法煞正正就是共𪜶看做按呢來處理。進一步的討論,詳細來參見測量尺度。

軟體

軟體的使用將會改善 FMEA 的記錄過程。目前,有真濟按呢的 FMEA 軟體包。佇選擇 FMEA 軟體包仔的時陣,重要的一點就是愛選擇彼種較𠢕佇學習佮有利促進協調一致地更新文檔記錄的軟體包。無必要為著欲擁有效易用的軟體系統若去開了大量的資金。有的 FMEA 軟體公司提供有免費的更新、免費的支持佮許可用戶數量無加限制的軟體。佇確保 FMEA 得著長期認可、理解佮實施方面,這點尤為有益。FMEA 適用佇所有的工程設計過程。

FMEA 的類型

* 過程:對著製造佮組裝過程的分析
  • 設計的:這欲生產進前,對產品的分析
  • 概念:佇較早的概念設計階段,對系統佮子系統的分析
  • 設備:佇咧買進前,對機械佮儀器設備的分析
  • 服務:咧發布出來致影響著人客進前,對著服務行業的過程分析
  • 系統:對全局系統功能的分析
  • 軟體:對著軟體的功能的分析

參考文獻

參見