JIS C 5750-4-3:2021 ディペンダビリティマネジメント―第４－３部：システム信頼性のための解析技法―故障モード・影響解析（ＦＭＥＡ及びＦＭＥＣＡ） | ページ 11

           48
C 5750-4-3 : 2021 (IEC 60812 : 2018)
                                          附属書D
                                          (参考)
                  FMEAとその他の総合信頼性解析手法との関係
  FMEAを他の総合信頼性解析法と組み合わせることで,その有効性を高めることが可能である。例えば : 
− FMEAの適用範囲を定義し,その開発を支援するために,システムの信頼性ブロック図(RBD)が有
    用となり得る。FMEAの結果は,その後,RBDを改訂又は更新するために用いることがある。
  注記1 FMEAと異なり,RBDの解析の視点はシステムが良好な状態となることである。
− FMEAのために複雑なシステムの重要アイテムを選択するため,適切な上位事象をもつ故障の木解析
    (FTA)を,解析するシステムのアイテムを特定するために使用可能である。
  注記2 FMEAと同様,FTAの解析の視点はシステムの故障である。
− (より低いレベルの)FMEAの結果によってFTAの基本事象を特定することが可能であり,それらの
    事象をFTAの基本事象として含めることが望ましい。
− 根本原因解析からの情報は,プロセスの故障原因の特定を支援することが可能である(IEC 62740)。
− 通常は独立的な故障だけを考慮するFMEAを補うために,FTA,RBD,事象の木解析(ETA),マルコ
    フ解析又はペトリネット解析のような,より詳細な解析方法を故障事象の出現順序,発生の条件付き
    確率,冗長性,発生の排他性,共通原因故障など,故障事象の相互依存性に対処するために使用可能
    である。
− FMEAは,アイテム又はプロセスの開発中に,他の総合信頼性解析手法と組み合わせて追加的に使用
    可能である。概念段階で,機能レベルの故障を考察するためにFMEAをRBD及びFTAと組み合わせ
    ることが可能である。詳細設計中に,より詳細なレベルでFMEAを実施することが可能である。選択
    した致命的な構成品又はプロセスに対して,最も詳細なレベルでのFMEAを実施可能である。
− 現場での試験結果又は故障の信頼性の予測及び解析を,FMEAで起こりやすさの定量化を支援するた
    めに使用可能である。
  注記3 その他の,適用できる場合がある総合信頼性解析の規格は,RBD(IEC 61078),FTA(JIS C 5750-
          4-4),ETA(IEC 62502),マルコフ解析(IEC 61165),ペトリネット解析(IEC 62551)である。
          信頼性予測に関しては,IEC 61709及びIEC 62308を参照。
  FMEAの結果は,複雑なアイテム又はプロセス設計の致命度の側面に関する情報を提供し,開発プロセ
ス中にFMEAの結果は,入力として用いるか,又は次のものと組み合わせることが可能である。
− 保全解析
− 保全中の故障診断の方策
− 試験容易性の解析
− 試験事例の定義及び仕様,及び試験結果の解析
− 補給支援の解析
− ミッションの信頼性解析
− アベイラビリティ解析
− 設計変更の結果の評価
− 規制目的での文書化(例えば,特定のシステム又はある種類のシステムに対する安全承認)。

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

                                                                                            49
                                                                C 5750-4-3 : 2021 (IEC 60812 : 2018)
                                          附属書E
                                          (参考)
                                FMEA実施上の考慮事項

E.1 一般

  附属書Eは,FMEAの一般的な適用並びに,この規格及び附属書Aに示すテーラリングの手引に示す一
般的な方法論に従ってFMEAを実施するときに考慮すべき特定の事項を検討する。ここの解説は,全てを
網羅したものではない。
  解説する適用は,致命度解析に関する特定の要求事項(例えば,安全性)をもつことがあり,又はこれ
は特定の基準(例えば,信頼性中心保全のFMECA)との互換性を確実にしていることがある。複雑なシス
テムに対するFMEAの使用も考慮されている(例えば,複数のモジュール及び構成品にまたがる信頼性及
びアベイラビリティの配分)。
  注記 “信頼性中心保全”はreliability centered maintenanceの訳だが,このmaintenance(保全)は,情報
        技術,特にソフトウェア分野では,“保守”という。同様に,“アベイラビリティ”(availability)
        は“可用性”も用いる。

E.2 ソフトウェアFMEA

  ソフトウェアFMEAは,ハードウェア又は手順に対するFMEAと類似しており,機能に対応している。
ソフトウェアの場合,次のような規約が確立されている。
− ソフトウェア誤りは,ソフトウェアのソースコードの誤りである
− ソフトウェア障害は,手続/関数の実行についての問題である
− ソフトウェア故障は,特定のソフトウェア機能の全体的又は部分的な劣化である
  ソフトウェアの設計ディフェクト(一般に“バグ”と呼ばれる)は,ソフトウェアの不具合を起こす可
能性がある。このような故障がソフトウェアの機能及びソフトウェアの出力に及ぼす影響は,他の項目と
同様に解析可能である。故障の発生確率は,“バグ”を含む関数が作動した回数を,関数の総実行回数で除
した値として推定可能であるが,この情報は滅多に得られないため,定量的解析はほとんど不可能である。
ソフトウェアの障害状態は断続的に発生することが多く,ある種の障害状態はソフトウェアのリセットで
修復が可能である。要求事項の誤った解釈,コードの誤り,不十分なメモリー,オープンループ,構文エ
ラーなどのいずれに起因するかにかかわらず,ソフトウェア障害の大部分は設計に関連する。
  ソフトウェアは,トップダウン又はボトムアップで解析が可能である。ハードウェア同様,ソフトウェ
アは,例えば,ソフトウェアパッケージ,ソフトウェアモジュール及び実行可能コード機能のように,異
なるレベルへと分解される(表1)。各要素について,解析では入力,処理及び出力を考察することが望ま
しい。処理は,例えば,メニュー構造における位置,レジスタ及びメモリー(RAM及びROM)の内容の
ような,入力前の初期状態に依存する。より低いレベルでは,障害は入力(例えば,不正データ又は破損
したデータ),初期状態(例えば,メニューにおける誤った位置,誤った又は破損したメモリー内容),又
は誤った処理(例えば,アルゴリズムにおいて)で生じ得る。システムレベルの故障は,多くの場合出力
(例えば,破損した出力又は無効データ)と関係している。最終的にソフトウェアの出力は,例えば,タ
イミングの問題のような,ハードウェアと相互作用する問題を引き起こし得る。解析は一般に,ソフトウ
ェアに関係した故障モードに着目するが,故障の原因,対策及び影響は,関連するハードウェアに関係す

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

           50
C 5750-4-3 : 2021 (IEC 60812 : 2018)
ることがある。したがって,ソフトウェアを知る解析者とハードウェアを知る解析者とが,共に解析に参
加するのが一般的である。
  ソフトウェアFMEAの深さ及び広さは環境によって異なる。FMEAは,ソフトウェアのコンポーネント
又はモジュールだけに限定され得る。ソフトウェア開発の初期に開始されるFMEAでは,システム運用の
ために必要とされるソフトウェア機能,及びその故障モードの一つ以上における機能故障の原因となり得
る潜在的な誤り又は障害に,集中することがある。こうした解析は,ソフトウェア開発の開始時に行い,
ソフトウェアテストケースの生成のための情報源として用いる。システム設計が進むにつれて,ソフトウ
ェアのエラー,フォールト又は故障の影響,並びに故障事象を誘発する諸状況又はそれらの組合せは,よ
りよく定義できるようになる。
  故障の根本原因には,プログラマーによるエラー(“バグ”)及びハードウェアの原因を含み得る。FMEA
を実施するために,ソフトウェアの何らかの単一故障が,例えば,(最終的/全体的影響以外に)次のよう
な受容できない局所的影響を引き起こすかどうかを判断する必要がある。
− 変数が予想外の値を仮定している
− メッセージが予想外のデータ又は予想外のタイミングを伝える
− モジュールが予想外の出力を生成する
  次にFMEAはシステムの(最終的)影響について各故障モードを解析する。影響は時間及び状態に依存
するため,規則に基づいた複雑なものになる。ソフトウェアFMEAを実施する前に,要求仕様に関して別
の解析を実施することが望ましい。ソフトウェア誤り又は障害は,しばしば,望ましくないハードウェア
影響につながるため,まず,システム影響を明確にするためにハードウェアFMEAを行うことが望ましい。
そうすれば,ソフトウェアのシステムの影響は,ハードウェアシステムの影響に基づいて実施可能である。
  次のリストは,Ozarin(2016年)[29]に示されている例に基づいている。ソフトウェアFMEAは,例え
ば,次のような運用条件も考慮しなければならない。
− メモリーのハードウェア故障
− メモリーマップされた周辺機器の故障(例えば,アナログ/デジタル変換器又はI/O装置)
− 電源故障,例えば,電源電圧低下によるリセット
− 電磁障害(EMI),電磁パルス(EMP)
− 誤った入力の不適切な処理。ブート時のエラーを含む。
  システムレベルの故障原因には,次のような例がある。
− オペレーティングシステム(OS)のシステムコールの誤用
− タイミング,例えば伝ぱ(播)時間の変化によるデータコリジョンなど
− 処理の中断及び不適切な解析
− 不適切な例外処理又は例外処理の欠落
  プログラミングエラーの故障原因には,次のような例がある。
− 設計及び実装のエラー(例えば,コーディング,スケーリング,アルゴリズム)
− エラー検出の不備(例えば,境界違反,範囲外のポインター)
− 有効範囲検出の不備
− 意図しないメモリーの上書き

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

                                                                                            51
                                                                C 5750-4-3 : 2021 (IEC 60812 : 2018)
− ソフトウェアのエラー処理の不備(例えばケースの想定漏れ)
  故障モードには,次のような例がある。
− 誤った終了点,時間超過,予想外のI/O相互作用
− データの欠落,誤ったデータ,データのタイミング,余分なデータ
− 異常終了,イベント処理の抜け,正しくない手順,タイミング/順序
− 停止,クラッシュ,ハング,応答の遅れ,起動時の故障,誤ったメッセージ
  スプレッドシートを用いて解析を実施するときは,一般に,次の列が設けられることがある。
a) 階層的なシステム及びコンポーネント
b) コンポーネントの指示子
c) 故障モード
d) 故障原因
e) 故障した機能のアンアベイラビリティの結果及び影響(ソフトウェアが修復される場合)
f) 設計規定の緩和(設計回復手段,代替経路,障害保護)
g) 補償規定
h) 問題の終結
i) 特定された故障モードに起因した,最終的に低減された機能アンアベイラビリティ
  注記 部分的にソフトウェアが修復されることによって,機能に影響する場合がある。
  図E.1に,ソフトウェア故障モデルの例を示す。
           図E.1−構成品ソフトウェアユニット(CSU)の一般的なソフトウェア故障モデル
  ハードウェア設計が進むと,解析はソフトウェア及びハードウェアを含むシステム全体を視野に入れ,
システムの機能及びそれらの連鎖を対象として解析する。
  ハードウェアFMEAがソフトウェア部分によって修正される場合には,システム故障をもたらす影響の

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

           52
C 5750-4-3 : 2021 (IEC 60812 : 2018)
連鎖を調べ,それらの性能低下の程度又はシステム性能に与えるその喪失の深刻さを評価している間に,
解析が望ましくない比率にまで大きくなることがある。ハードウェア/ソフトウェアの混合システムを解
析する場合の望ましい方法は,システム機能の分岐点を下にたどって,構成品ソフトウェアユニット(CSU)
とそれらの潜在的誤り又は障害とを特定し,潜在的故障モード及び潜在的原因を特定することである。
  FMEAは,一度に一つの故障モードだけに対処するということを思い起こすことが望ましい。FMEAは,
機能的な依存性,事象(故障)のシーケンス,又は事象の組合せに対処することを意図したものではない。
ハードウェア故障は,ソフトウェア故障を引き起こすことがあるが,FMEAの観点では,そのときソフト
ウェア故障はハードウェア故障の影響ということになる。
  ソフトウェアFMEAは,ソフトウェアの信頼性の向上に役に立つ(試験以外の)一つの方法である。試
験も,致命的と考えられる故障モードに対する一つの処置になるかもしれない。

E.3 プロセスFMEA,工程FMEA

  プロセス及び手順の場合,一般的なFMEAの方法論は,ハードウェア及びソフトウェアアイテムに対す
るものと同じである。解析の開始点は,プロセスフロー図,作業の分解構造又はタスク解析である。プロ
セスは,プロセスのステップである要素へ下位分割する。分解のレベルは,用途に合うように選択する。
各ステップの機能又はその意図する成果は,故障を構成する性能のレベルが明確となるように十分に具体
的に機能を記述して定義する。ハードウェア及びソフトウェアアイテムのFMEA同様に,プロセス機能が
果たされない可能性がある道筋を,プロセスFMEAの故障モードとして列挙する。故障の影響,メカニズ
ム及び考えられる故障原因も定義する。故障のメカニズム及び原因は,しばしば,人とハードウェアの故
障との両方に関わっている。致命度解析は,FMEAの一般的手引に記述したものと同じやり方で適用可能
である。
  プロセスFMEAは,当初,“工程FMEA”として製造工程に適用されたが,現在はより広範に用いられ
ている。例えば,ヘルスケアにおける医療手順の解析に広く用いられている。
  注記 一般的な機能FMEAと異なる,プロセスFMEAの特徴には,作業ステップの順序に関する故障
        又は不具合の存在がある。例えば,逆のステップ順で作業してしまう逆順故障,でたらめなステ
        ップ順で作業してしまう乱順故障,なすべきステップを抜かして作業してしまう欠順故障などが
        挙げられる。

E.4 設計及び開発のためのFMEA

  FMEAは,概念から複雑なシステムの開発まで,設計プロセスに不可欠な部分である。FMEAは反復的
であり,システムの最上位レベルで予備設計の情報が利用可能になり次第,すぐに開始され,より多くの
情報が利用可能になると,システムの階層のより低いレベルへ拡張される。FMEAのテーラリング(附属
書A)は,それが設計アプローチの実現可能性及び適切性などの,組織の決定に有意に貢献することを確
実にすることが望ましい。
  設計中のFMEAの目標は,できる限り早期に,設計によって除去又は低減できるシステム内の故障モー
ド及び潜在的な致命的故障を明確にすることである。
  信頼性の重視に加え,FMEAは保全性及び支援性の取組,及びリスク解析を支援する。

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

次のページ PDF 56