FTAとFMEAそしてDRBFM

FTAとFMEA

「FTA」は ”Fault Tree Analysis”（故障の木解析）、「FMEA」は ”Failure Mode and Effect Analysis”（故障モード影響解析）、そして「DRBFM」は ”Design Review based on Failure Mode”（故障モードに基づくデザインレビュー）の略です。

いずれも故障・不具合の発生を未然防止するための手法ですが、これらの用語はどのように違い、どのように使うのでしょうか？

FTAとFMEAの使われ方

元々、FTAは開発中や量産後に不具合が発生した時に原因を見つけ対策を行うために、一方、FMEAは量産前に量産時の不具合発生を予防するために使われていました。現在は、FTAを不具合予防の手法としても、またFMEAを量産後の変更や変化点影響解析としても活用されるようになっています。

FTAとは

FTAは不具合原因を特定するため、可能性のある要因を「木の枝」、さらにその要因を「枝の先の葉」のように分解していきます。

例えば、製造要因（開発中であれば試作品の品質）なのか、設計要因なのか、といった観点から分解していきます。設計要因の場合、もちろん設計不良要因も含まれますが、使われ方が設計時の想定を上回っていないかという点でも要因分析を行います。単独要因で起こりうるか、複合要因か、不具合を加速している要因は無いかという分析も重要です。
FTAは、犯人捜しと似ています。犯行が単純であれば、ある目星や勘を頼りに捜査をしても簡単に犯人を見つけられるでしょうが、複雑な場合はそうはいきません。

太い木の枝にあたる一次解析では、先入観を持たずに、可能性のある分野、要因領域の全網羅が必要です。

次の小枝、葉にあたる二次分析、三次分析、四次分析には、原因を早期に発見するためにメリハリが必要です。何によってメリハリをつけるかというと、証拠（evidence,エビデンス）によってです。
現場・現象の情報、現物の観察・測定結果、実験結果及び設計検討結果などから得たエビデンスを基に、シロ（可能性無し）あるいはグレー（可能性有り）を決め、グレーの領域はより深く分析を行っていきます。
複雑な問題の場合、グレーの領域にクロ（原因）が見つからず、シロ領域を再度見直しすることもあります。この場合は、エビデンスの確からしさも含めて確認することになります。

FTAの予防的使用方法においては、「もし故障が起こるとしたら」という仮定で始め、どのような要因があったらその想定した故障にいたるかを分析し、弱い部分を強化します。

FMEAとは

FMEAの目的は、ロバスト性（robust、頑健性）を確認して、不足している部分の補強を行うことです。

ロバスト性は高ければ高いほど良いですが、安全率を2倍にするのか10倍にするのかと考えればキリがありません。ロバスト性を向上するには、コストと時間もかかるため優先順位を決めて改善します。

優先順位を評価するために、影響度、発生頻度そして検出度の三つを用います。

このためFMEAでは、まず製品を構成する機能を分解することから始め、その機能が失われた時の「影響度」を評価します。
次に影響度が中レベルでも、発生する割合が低ければ、対策優先度を下げることができるため、この因子を「発生頻度」と呼び評価します。
さらに、不具合が見つけられ流失しないようにすることが容易ならば、対策優先度を下げられるため、この因子を「検出度」と呼び評価します。

ロバスト性を上げるアプローチには二つあります。
一つは、構成要素の強度を上げることですが、それが難しい場合には、多重化を行います。
システムの場合には、この多重化が良く用いられますが、より多重化されている状態を、冗長性（redundancy）が高いと言います。
システムに特化したFMEAは、製品FMEAに対して、「システムFMEA」と呼ばれます。

一般的にFMEAという場合は、設計FMEA (Design FMEA)ですが、FMEAには工程FMEA（Process FMEA）もあります。考え方は同様です。設計FMEAの機能＆影響分析で、重要と評価された部分に関係する工程のロバスト性（工程安定性）を、工程不良の影響度、発生頻度及び検出度を基に優先順位を決めて、向上させます。検査方法の改善やポカヨケ追加などの対応策は、設計FMEAにおける、「検出度」を上げることにもつながります。

DRBFMとは

デザインレビュー（DR）は、設計が目的を達成するためにできているかを検討・確認するための設計検証のために用いますが、このDRを可能性のある故障モードに重点を置いて行い、不具合を未然防止しようとするのが「DRBFM」です。

製品にとって市場実績というのは非常に重要です。
それは実際の様々な市場の負荷により設計の妥当性が評価され「OK」となっていること示します。
逆に言えば、製品に関する変更点、変化点に不具合リスクがあります。

DRBFMは、その変更点、変化点に関係する機能と可能性のある故障モードを考え、設計検証と評価を行うという考えです。意図的に変更した部分だけではなく、その変更の影響を受けて結果的に変わってしまう変化点にも注意して検討しなければいけません。製品自体に変更が無いが、搭載方法が変わる、新たな市場で環境や使われ方が変わるというのも、もちろん変化点となります。