©  All rights reserved.   

FTA解析 故障の木解析 事例解説

客観説TQM研究所




理論の概要

はじめに

 FMEA(Fault Tree Analysis:故障の木解析)を簡単に説明します。

 FTAは、米空軍が開発中だった大陸間弾道弾ミニットマンの発射管制システムの信頼性評価に関する研究をベル研究所に委託して研究されました。

 機器の故障のほか、不良品の混入・ポカミス・外部からの妨害を含めた総合的な発射失敗の 確率を把握することを目的 とした。

 分析・改善の大まかな手順は、以下のとおりです。

1.解析対象システムを理解する。
2.「望ましくない事象」をトップ事象にする。
3.トップ事象の直下に、要因事象の総枠を設定する。
4.FT図を作成する(定性解析)
5.定量解析(基本事象の頻度見積り、トップ事象の頻度集計)
6.頻度の改善

FTAの制約

(1)FTAは、不具合事象の予防のための手法です。不具合事象の発生後に原因調査の目的で行うのは間違いです。起きるまで待って、起きてから始めるのでは、時すでに遅しです。それは特性要因図と混同した結果です。

(2)FTAは、重大な不具合事象の頻度(確率)を見積もるための手法です。単に展開するだけの特性要因図と違って、頻度見積ができない下位事象があってはならない。

FMEAとの相違

  1. 不良品
     FMEAは設計した製品を評価するものであり、不良品を対象にしません。これに対し、FTAはある不具合事象が起きる頻度を問題にするから、不良品を対象にすることができます。

  2. トップ・ダウン
     FMEAはシステムの構造破壊(故障モード)を列挙し、この構造破壊が起きたらどんな不具合事象が起きるかというボトム・アップ追跡となります。これに対して、FTAはシステムの不具合事象を最初に特定して、その不具合事象がなぜ起きるかというアプローチになり、トップ・ダウンになります。

  3. 総枠設定
     FMEAの故障モードは、設計者にとって明白なため列挙もれが少ない。これに対して、FTAの頻度見積の基礎になる事象(基本事象)はトップ・ダウンに追跡するためもれやすく、漏れを防ぐための特別な工夫が必要になる。

  4. 頻度の見積と集計
     FMEAは一般的な製品や工程の最適信頼を目的とするものであり、故障による被害・頻度・大事に至る前の検知という3方面からの定性的な評価を行い、頻度見積を必ずしも数値的に行う必要はない。これに対して、FTAでは重大な不具合事象を対象に、数値的な頻度だけを目的とするため、基本事象の頻度見積が不可欠である。
 しかし一般にこれらの技法の指導は正しく行なわれず、多くの場合に飾り物になるだけです。例えば、

 *要因事象についての想定外をなくす工夫がありません。たまたま思いついた要因事象を並べるだけです。

 *展開が進むほどに、個々の些細な事象に分解される。しかし、発生頻度は、さっぱり見当がつかず、結局のところトップ事象の頻度集計ができないで終わる。こういう事例が圧倒的に多い。

 本稿では、最初に、事例1と事例2で、基礎的なことを述べ、続いてこのような「問題のある指導例」を吟味して参りましょう。

 このページではFTAだけを紹介しますが、セミナーはFMEA、ETA、特性要因図を含みます。その全体の説明は、FMEAのページに移って下さい。

FTAを行う者の立場

 要因事象としてどのようなものを含み、あるいは含まないか、FTAを行う者の立場によって異なります。

 * 製品設計者がFMEAの補助としてFTAを行う場合は、そのFTAの対象は設計通りの製品に限られ、不良品は含まれない。

 *製品の使用者がFTAを行う場合は、製品の信頼性を調査することが目的ではないから、製品の内部に展開しない。

 *製品開発者がFTAを行う場合は、製品外部の人の行動、天候、天変地異に展開し、さらに製品内部に展開して、構造破壊やユニットの故障、それに不良品なども要因事象にします。ミニットマンの開発がこれに該当します。

 FMEAが「何が起きるか分からない」というテーマを扱うのに対して、FTAは「分かっている不具合の頻度を知りたい」というテーマを扱います。だから、特性要因図のように定性的に展開するだけではFTAになりません。


 事例 1

 FTAの一般的な手順を、下の図に沿って説明します。

トップ事象

 起こしてはならない事象を決め、これを矩形の枠の中に記載してFT図の最上位に置く。矩形の枠は展開事象を示し、この事象がなぜ起きるか、要因事象を下方に展開することを示す記号です。

展開→中間事象→基本事象

 トップ事象から展開して、頻度見積が可能な事象が見つかったら、これを基本事象としてマルで囲む。基本事象は、頻度見積を数値的に示す要因事象です。

 トップ事象と基本事象の間に配置した展開事象は、中間事象と呼びます。中間事象は1次に限らず数次に及ぶことがあります。

論理記号

*上位事象に対して下位事象が複数ある時、どれか1個の下位事象が起きれば上位事象が起きるなら、「OR ゲート」で示す。この場合、頻度は足し算になります。

〔ORゲートは頻度を足し算〕

 工程抜けの頻度を年に換算して、
1回/週=4回/月=48回/年

 両方の頻度を加算して、
48回/年+1回/年=49回/年

 あるいは、1回/年を無視することもできます。

*上位事象に対して下位事象が複数ある時、全ての下位事象が同時に起きるときだけ上位事象が起きるなら、「AND ゲート」で示す(下の図)。この場合、頻度は掛け算になる。

〔ANDゲートは頻度を掛け算〕

(48回/年)×(48回/年)=(48回/年)×(48日/250日) =9回/年

*下位事象Aが、条件事象Bが起きている時に起きれば上位事象Xが起きる場合は、制約ゲートを用い、その横に条件事象を、下に下位事象を配置する。

*下に論理記号の一覧表を示す。

*トップ事象の頻度が過大なら、確率が最大のルートに対して対策を講じ、トップ事象の頻度が十分に小さくなるまで繰り返す。

クリティカル・パス

 トップ事象から下に展開した事象には、頻度が高いものや低いものがあります。

 トップ事象から展開した直下の事象が A、B、C の3つのユニットの故障だとする。

 Aの頻度は非常に高く、次にBの頻度も高いが、これらに比べてCの頻度は十分に低いとする。こういう場合に、頻度の高い事象も低い事象も差別なく展開するのは間違いです。

〔頻度が低い事象、対策がある事象は展開せず〕

 頻度の低い事象や対策がある事象を放置して、高い事象を優先的に展開して危険な故障経路(クリティカル・パス)をあぶり出すのが上手な展開の仕方です。

 だから、頻度見積をしながら展開するのです。構わず展開して、これ以上展開できない末端の事象を基本事象として、その頻度を見積もる・・・というのは間違いです。

 Cはとりあえず対策の必要がないから展開もこれ以上行わず、○枠で囲って基本事象とし頻度を見積もります。

 Bは頻度は高いが、定期交換というメンテ制度によって常に新品に維持できるユニットなので、これ以上は展開しないで、非常に低い頻度に見積もる。

 Aは中間事象として、同様に展開を続け、頻度見積と対策が可能な基本事象にまで展開する。

 FT図の全体から、トップ事象の頻度に最も貢献しているクリティカル・パスの頻度を下げるよう、対策を考案する。


事例2(客観説TQM研究所の実施例)

 セミナー当日に何らかの事情でセミナーを開催できなくなる事象を何としても回避するために、FTAを行った当研究所の事例を紹介します。

総枠設定

 下の図で、「開催不能」がトップ事象です。基本事象をもれなく列挙するために中間事象として5Mを列挙し、それぞれの基本事象を導いて頻度を評価します。

 このように、展開すべき要因事象の抜けを無くすために、「これ以外にはない」という総枠を設定して、その中で要因事象を列挙します。要因事象が全てわかっている場合は、総枠設定は不要です。

 本件では総枠として5Mを使っていますが、これに限りません。


頻度の見積

 頻度の数値的な見積は、ほとんどの場合、正確なところは分かりません。しかし、月1回よりは少ないが10年に1回よりは多いなら年に1回と判断します。年に2回か3回かという調整は、後日、実績を参照して行います。


 その結果、本件の場合は、上図に示すように危険な日は、年間で17日あることが分かる。

 他方、講習会は年に6回開催するとして、6日/年 と表します。すると、危険日と開催日がかち合う頻度は、

(17日/年)×(6日/年)=(17日/年)×(6/260)=0.4/年

となって、2年に1回ほど危ない目に合うという計算になる。勿論、不合格です。

 頻度の表し方を整理すると、下の表のようになります。

事象の頻度
頻度の表現
年に1回(1日)
1/年
月に1回(1日)
12/年
週に1回(1日)
48/年
10年に1回(1日)
0.1/年

 「1年に1回」は、260日(稼働日)のうちの1日がブラックデーになると考えて「1/260」とも表すことができます。

 合否判断に明確な基準はありません。大人数の生命に関わるような大事故なら10万年に1回程よりも小さい頻度が求められるでしょう。本件の場合のような個人的なケースで少額の損失を問題とする場合は、100年に1回程ほどで十分かと思われます。

対策と効果

 そこで、本件の対策を考えたものが次の図です。


* 列車異常の対策は、会場に近いホテルに前泊して徒歩で講習会場に行くようにする。これで頻度=0 になる。

* PC、アダプター(電源)、マウス、プロジェクターは予備を会場に持ち込み、故障したら直ちに交換する(冗長設計)。

* 講師の病気は、代替の講師を準備する(冗長設計)。

 上の冗長業設計は、いずれも頻度を自乗する。

(1日/年)×(1日/年)=(1日/年)×(1/260)=1日/260年

これが5個あるから5倍して、

5×(1日/260年)=5日/260年-----@

* 停電は災害がない限り、日本では1回/10年程度であり、これに自家発電設備を有する会場を使うという対策を織り込んで、

(1回/10年)×(1回/年)=(1/2600)×(1日/年) =1日/2600年-----A

 @とAを比較すると、Aを無視できるので、危険日の頻度は 5日/260年=1日/50年 とすることができる。

 上の計算を下の図に示す。

 この危険日と開催日がかち合う頻度を求めると、

(1日/50年)×(6日/年)=(1日/50年)×(6/260) =1日/5,000年

となって、合格とみなすことができる。

 FTAにより、リスク全体を見渡し、クリティカル・パス(最大リスク箇所)が可視化されます。

実績による修正

 このような概算見積もりのもとで5年過ごした実績データと照合して、確率の是正を行った。

 パソコン等の故障や講師の病気などの頻度を、「1回/年 → 1回/4年」に修正した結果、右の図のようにトップ事象の頻度は、「1回/50年 → 1回/500年」と一桁小さいものとなった。

 上の事例では、基本事象が起きるとストレートに事故(トップ事象)につながった。しかし、システムによっては、下の表に示すように、いろいろなものがある。


様々なケース

基本事象の性格
基本事象と影響
結果の内容と程度が一定
停電 → パソコン機能停止→講習会の中止
程度が不定
地震 → 震度によって、影響の程度は不定
内容も程度も不定
修理途中を修理完了と勘違いして自動車を運転

 このようなさまざまな基本事象が起こるシステムでは、どのようにFTAを構築するか?

 実務ではこのようなシステムが多く、かような問題をどんどんこなすような力がないと、実務は勤まりません。

 例えば、ヒヤリハット活動というのがありますが、ヒヤリハットは次から次へと、無数に出てきます。

 その全てのヒヤリハットに発生対策を講じなければならないかどうか判定するツールにFTAが使われます。そして、ヒヤリハットには上の表に示す3種類のものが含まれるので、これらの扱いが分からないと収拾がつかないことになります。


[客観説TQM−TOP]