JIS C 5750-4-3:2011 ディペンダビリティ マネジメント―第4-3部:システム信頼性のための解析技法―故障モード・影響解析(FMEA)の手順 | ページ 2

4
C 5750-4-3 : 2011 (IEC 60812 : 2006)
FMEAの適用の前に,システム(ソフトウェアを含むハードウェア又はプロセス)をより基本的な階層
構造の要素へ分解する。この分解を説明するためには,単純なブロック図を用いることが有益である(IEC
61078参照)。解析は,最下位レベルの要素から開始する。下位レベルのアイテムの故障モードの影響は,
その上位レベルのアイテムの故障モードの原因となり得る。この解析は,そのシステムに対する最終的な
影響が明らかになるまで,ボトムアップの方法で進める。この関係を,5.2.2.3及び図1に示す。
FMECAはFMEAの拡張であり,改善策の優先順位を決めるために,故障モードの厳しさについて格付
けする方法を含む。これは,致命度と呼ばれる測定基準を作成するために,厳しさの尺度と発生頻度とを
組み合わせることによって行われる。
FMEAの諸原則は,設計活動以外にも適用できる。FMEAの手順は,製造工程,又は病院,医学研究室,
学校などのその他の作業プロセスに適用できる。FMEAを製造工程に適用する場合,この手順は,産業界
では工程FMEA又はプロセスFMEA(以下,“PFMEA”という。)として知られている。FMEAを有効に
するために,チーム活動にとって適切なリソースを確保しなければならない。解析中のシステムの細部に
わたる理解は,準備段階のFMEAにとって不可欠なものではない。設計開発に伴い,詳細な故障モード解
析には,設計性能及び仕様書に関する細部にわたる知識が必要となる。複雑な設計には,通常,様々な分
野の設計専門家の参加が必要となる(例えば,機械工学,電気工学,システム工学,ソフトウェア工学,
保全支援など)。
FMEAは,通常,個々の故障モード及びシステムに対するこれらの故障モードの影響を扱う。それぞれ
の故障モードは互いに独立なものとして扱う。したがって,その手順は,従属故障又は一連の事象から引
き起こされる故障の検討には適していない。これらの状況を解析するには,マルコフ解析(IEC 61165参
照)又は故障の木解析(JIS C 5750-4-4参照)など,その他の方法又は技法が必要となる。
故障の影響を決定するときに,より上位のレベルで誘発される(結果として生じる)故障又は場合によ
っては同じレベルでの誘発される故障を検討しなければならない。その解析は,より上位のレベルの影響
の原因となる故障モードの組合せ又はそれらの結果について,できる限り示すことが望ましい。その場合,
そのような影響の規模又は発生確率を推定するための更なるモデル化が必要となる。
FMEAは,特定の産業又は製品のニーズに合わせて工夫ができる柔軟なツールである。特定の記入を求
める専用のワークシートが,ある用途のために採用される。故障モードの厳しさのレベルが規定されたら,
ワークシートは異なるシステム又は異なるシステムレベルのために個別に規定してもよい。

4.2 解析の目的及び目標

  FMEA又はFMECAを実施する目的を,次に示す。
a) システム運用について好ましくない影響をもつ故障を明らかにする。例えば,運用を妨げたり,著し
く低下させたり,ユーザの安全に影響を及ぼしたりすることなどがこれに当たる。
b) 適用可能な場合には,顧客の契約に基づく要求事項を満たす。
c) システムの信頼性又は安全性を改善できるようにする(例えば,設計の部分変更又は品質保証活動)。
d) システムの保全性を改善できるようにする(保全性に対するリスク又は不適合を明らかにすることに
よって)。
FMEAを実施するための上記a) d)の観点から,FMEA又はFMECAの目標には,次に示す項目を含め
る場合がある。
a) 解析するシステムで,規定する条件での全ての好ましくない影響,並びに原因によらず当該システム
の機能階層構造の様々なレベルで明らかになったアイテムの故障モードによって生じる一連の事象の
包括的な識別及び評価。

――――― [JIS C 5750-4-3 pdf 6] ―――――

                                                                                              5
C 5750-4-3 : 2011 (IEC 60812 : 2006)
b) システムの正しい機能若しくは遂行能力又は関連するプロセスに対する影響に関して,各故障モード
への対処又は緩和(箇条6参照)のための致命度又は優先課題の判定。
c) 関連特性に従って識別された故障モードの分類。関連特性には,検出の容易さ,診断能力,試験容易
性,修復及び運用の供給(修理,保全,補給など)を含む。
d) システム機能故障の明確化並びに厳しさの尺度及び故障確率の推定
e) 故障モード削減の設計改善計画の立案
f) 故障の可能性を軽減し,削減するための効果的な保全計画立案の支援(IEC 60300-3-11参照)。
注記 致命度又は発生確率について言及する場合,上記のコメントはFMECAの方法に関するもので
ある。

5 故障モード・影響解析(FMEA)

5.1 一般的事項

  伝統的に,FMEAを実施し,表現する方法には,多様性がみられる。その解析は,通常,故障モード,
それらの原因,並びに直接及び最終の影響を明らかにすることで実施される。解析の結果は,全体システ
ム及びそのシステムの細部の重要情報の核心部分を含むワークシートに表すことができる。それは,シス
テムが潜在的に故障になりそうな道筋,システム故障の原因となりそうな構成品及びそれらの故障モード,
並びに個々の故障モードの発生原因を表す。
複雑な製品に適用するFMEAにかける労力は,極めて広範囲にわたる。これは,一部のサブアセンブリ
又はそれらの部品が完全には新しくはないことを念頭に置くことによって,かつ,製品設計の一部が前の
製品設計からの繰返し又は部分変更であることを明らかにすることによって,ときには縮小してもよい。
新たに行うFMEAは,それを構成する既存のサブアセンブリに関する情報をできる限り使用することが望
ましい。またそれは,新しい特色及びアイテムに対しては,最終試験又は十分な解析の必要性を明らかに
するものでなければならない。いったん,一つの設計に対して詳細なFMEAを作成したら,その設計以降
の世代まで更新かつ改善できる。このように既存のFMEAを更新かつ改善することで全く新しく解析する
よりも著しく少ない労力で作成できる。
過去の製品の既存のFMEAを使用する場合,その繰り返された設計が本当に同じ方法で,前の設計と同
じストレスの下で使用されることの確認が重要である。新たな運用ストレス又は環境ストレスがある場合
は,既に完成したFMEAの見直しが必要となる。異なる運用ストレス及び環境ストレスがある場合は,新
たな運用条件を考慮して全く新たなFMEAを作成することが要求される。
FMEA手順は,次の主な四つの段階で構成する。
a) MEAの基本的ルールの確立,解析を行うための時間並びに専門的知識を確保するための計画及び工
程の作成
b) 論理図若しくは故障の木など他の手段又は適切なワークシートを活用したFMEAの実施
c) 様々な結論及び提言を含む解析の要約及び報告書の作成
d) 開発活動の進展に伴うFMEAの更新

5.2 準備作業

5.2.1  解析のための計画
FMEA活動,追跡調査(フォローアップ)活動,手順,他の信頼性活動との関係,是正処置の管理及び
その終了の各プロセス並びにマイルストーンは,全体のプログラム計画の中に統合することが望ましい。

――――― [JIS C 5750-4-3 pdf 7] ―――――

6
C 5750-4-3 : 2011 (IEC 60812 : 2006)
信頼性プログラム計画は,使用するFMEA解析方法を記述することが望ましい。この記述は,要旨又は
方法の記述を含む出典文書から参照したものであってもよい。
この計画には,次の事項を含むことが望ましい。
− 解析の具体的目的及び期待する結果についての明確な定義
− FMEAがどのように特定の設計要素に焦点を当てるのがよいかに関する,現状解析の範囲。この範囲
は,設計の成熟度,及び重要な機能を果たすという理由又は用いる技術の未成熟さの理由によってリ
スクとみなされる設計の要素を反映することが望ましい。
− 現状の解析がプロジェクト全体のディペンダビリティをいかに支えているかの記述
− FMEAの改訂及びその関連文書の管理に用いる決められた方法。解析文書及びワークシートの改訂管
理及び保存方法を規定することが望ましい。
− 必要なときに対応可能な設計専門家の解析への参加
− 適時な解析を確実にすることを明記したプロジェクトスケジュールの重要なマイルストーン。
− 対処が必要な故障モードの削減のプロセスにおいて,全ての明確にした処置の終了方法。
計画書は,全ての参加者の同意を反映し,プロジェクト管理者が承認することが望ましい。製品の設計
の最終段階又はその製造プロセス(プロセスFMEA)で完成したFMEAの最終レビューは,重要な故障モ
ードの削減のために記録された処置及びそれらの終了方法を明確にする。
5.2.2 システムの構造
5.2.2.1 システムの構造に関する情報
次に示す事項を,システムの構造に関する情報の中に含める。
a) 特性,性能,役割及び機能を含む異なるシステム要素
b) 各要素間の論理的な結び付き
c) 冗長レベル及びその性質
d) 設備全体でのシステムの位置及び重要性(可能な場合)
e) システムのインプット及びアウトプット
f) 運用モードを変えたときのシステム構造の変化
FMEAがそれら機能のいずれかを妨げる故障モードに適切に対処できるように,機能に関する情報,特
徴及び性能は,全てのシステムレベルについて,最高位のレベルまで検討しなければならない。
5.2.2.2 解析のためのシステムの境界の定義
システムの境界は,システムと環境との間の物理的及び機能的なインタフェースを形成する。この環境
は,システムと互いに影響し合う他のシステムを含む。解析のためのシステム境界は,設計及び保全につ
いて定義する境界と一致することが望ましい。これは,いかなるレベルにあるシステムにも適用すること
が望ましい。境界の外側にあるシステム及び/又はその構成品は,明確に除外して定義することが望まし
い。
システム境界の定義は,FMEAの最適な要求事項よりも,設計,用途,供給源及び商業基準によって影
響される可能性が高い。ただし,システムFMEAとプログラム内のその他の関連する調査・研究との統合
を容易にするために,可能な場合は境界を定義することが望ましい。このことは,特に,システムが境界
をまたぐ複数のアウトプットと境界内の複数のアイテムとの複数の相互結合で機能的に結び付いている場
合に当てはまる。このような場合,他のシステムとのインプット及びアウトプットの結び付きの数を制限
するために,ハードウェア及びソフトウェアの視点よりも,機能の観点から検討して境界を定義する方が
適切である。これは,システムの故障の影響の数を削減する結果となる。

――――― [JIS C 5750-4-3 pdf 8] ―――――

                                                                                              7
C 5750-4-3 : 2011 (IEC 60812 : 2006)
対象システムの境界の外にある他のシステム又は構成品も,検討除外であることを明白に示し,その存
在を忘れないように配慮することが望ましい。
5.2.2.3 解析のレベル
解析に用いるシステム内の保全実施単位を決定することは重要である。例えば,システムは,機能,サ
ブシステム,交換可能ユニット又は個別の構成品に分解できる(図1参照)。解析のためにシステムの保
全実施単位を選択する基本ルールは,期待する結果及び設計情報の入手の可能性に依存する。有用な指針
を,次に示す。
a) システムの最上位レベルは,設計概念及び規定したアウトプット要求事項から選択する。
b) 解析が効果的であるシステムの最下位レベルは,各機能の定義及びその説明を制定するための情報が
入手できるレベルである。適切なシステムのレベルの選択は,これまでの経験の影響を受ける。詳細
でない解析でも,確かな信頼性,保全性及び安全性記録をもつ成熟した設計に基づくシステムについ
ては,適切と判断できる場合もある。逆に,新たに設計されたシステム,又は信頼性の履歴が不明な
システムについては,極めて詳細でそれに対応する,より下位のレベルが必要となる。
c) 規定した又は意図した保全及び修復のレベルは,より下位のシステムレベルを決定する上で有用な指
針となり得る。
FMEAにおける故障モード,故障原因及び故障の影響の内容は,解析及びシステム故障基準のレベルに
依存する。解析が進むにつれ,より下位レベルの故障の影響が,上位レベルの故障モードの原因になる場
合もある。それらの下位レベルの故障モードの影響が,上位レベルの故障モードの原因となる場合もある。
システムをその構成要素に分解する場合,一つ以上の故障モードの影響が,別の故障モードの原因とな
り,それが上位レベルに影響,すなわち,部品故障の原因となる。部品故障は,更に上位レベルに影響,
すなわち,モジュール故障の原因となり,それ自体がサブシステム故障の原因となる。このように,ある
構成要素レベルの原因による影響は,より上位のレベルで別の故障の原因となる。上記の関係を図1に示
す。

――――― [JIS C 5750-4-3 pdf 9] ―――――

8
C 5750-4-3 : 2011 (IEC 60812 : 2006)
システム
サブシス
テム2
サブシス サブシス サブシス
テム1 テム4 テム5
サブシス
テム3 システム故障の原因
故障モード
サブシステム4の故障に影響
サブシステム4
モジュ モジュ モジュ モジュ
ール1 ール2 ール3 ール4
サブシステム4の故障の原因
故障モード
モジュール3の故障に影響
モジュール3
部品3
部品1 部品2 部品5
部品4
モジュール3の故障の原因
故障モード
部品2の故障に影響
部品2
モード モード モード
1 2 3
部品2の故障の原因
故障の原因
モード3の故障に影響
原因 原因 原因
1 2 3
部品2のモード3の故障の原因
図1−システム階層構造内の故障モードと故障の影響との関係
5.2.2.4 システム構造の表示
システムの構造及び運用の記号による表現,特に図による表示は,解析を進める上で極めて有用である。
システムに不可欠な全ての機能を示した単純な図を作成することが望ましい。図の中の各ブロックは,
各機能に関するインプット及びアウトプットを示す線によって結び付けられている。通常,各機能及び各
インプットの特性は,正確に記述する必要がある。システム運用の異なる段階を網羅する複数の図があっ
た方がよい。

――――― [JIS C 5750-4-3 pdf 10] ―――――

次のページ PDF 11

JIS C 5750-4-3:2011の引用国際規格 ISO 一覧

  • IEC 60812:2006(IDT)

JIS C 5750-4-3:2011の国際規格 ICS 分類一覧

JIS C 5750-4-3:2011の関連規格と引用規格一覧