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

           8
C 5750-4-3 : 2021 (IEC 60812 : 2018)
− システム運用について好ましくない影響をもつ故障モードを特定する。例えば,運用を妨げる,著し
    く低下させる,又はユーザー及びその他の人々の安全に影響を及ぼすことが対象の故障モードに相当
    する。
− 開発プログラムにおいて早い時期に関与することによって,費用対効果の高いやり方で,アイテム又
    はプロセスの設計及び開発を改善させる。
− リスクを,リスクマネジメントプロセスの一部として特定する(JIS Q 31000参照)。
− 予見可能なリスクが特定され,説明されていることを実証することによって,法令及び事業上の義務
    を果たす。
− 他の総合信頼性解析に対して基礎を与える(附属書Dで,FMEAと他の総合信頼性解析の方法との関
    係を解説する)。
− 信頼性試験プログラムを開発及び支援する。
− 例えば信頼性中心保全を通じて,保全及び支援プログラムを計画する基盤,根拠,又は土台を与える
    (IEC 60300-3-11参照)。
− アセットマネジメントシステムにおける主要プロセスとなる(JIS Q 55000参照)。
  一般に,FMEAは,単一の故障の影響を解析する方法である。相互依存する複数のアイテムの故障に
FMEAを用いる場合,これら複数のアイテムの故障を一定の制約内で解析することは可能である(5.3.6及
び5.3.7.2参照)。

4.2 役割,責任及び力量

  FMEAは,次の事項に対して責任者(例えば,個人又はチーム)を必要とする。
− FMEAの実施プロセスを運用管理する。
− FMEAの形式を,適用の状況に合わせてテーラリングするために決定する。
− アイテム又はプロセスの故障モード及び影響を特定し,解析する。
− 必要とされる処置を決定する。
− 処置及び推奨事項を含め,FMEAを報告する。
  この規格は,FMEAの実施に関する役割及び責任を記述するために,次の用語を用いる。
a) 解析者
      適切なFMEAかどうかを検討し,FMEAのテーラリングを主導し,FMEAを確実に進め,運用管理
    者及びその他の利害関係者との意思疎通に責任をもつ人。解析者はFMEAについて力量をもち,解析
    に関わる力量をもつ他の人々に作業を促すための十分な技術的理解をもつことが望ましい。
      注記 チームでの取組の場合には,関与する人々に作業を促す役割は,時に“ファシリテーター”
            と呼ばれる人が引き受けることが可能である。
b) 関連する力量をもつ人
      必要とされる社会的,経済的及び環境的な側面の考察を含む,解析するアイテム又はプロセスの全
    ての側面にわたる関連知識及び経験をもつ人。
c) 運用管理者
      FMEAの目的を定義し,リソースの使用権限をもち,テーラリングの承認,及び必要な対策及び改
    善要求を指示する人。この役割は,最終的な設計の権限をもつ運用管理者が引き受けてもよい。
d) 利害関係者

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

                                                                                             9
                                                                C 5750-4-3 : 2021 (IEC 60812 : 2018)
      決定又は処置に対して,何らかの影響又は利害関係が生じる,又は影響を受けると感じる人又は組
    織。例えば,利害関係者は,顧客(例えば,発注者),当局(例えば,規制者),ユーザー(例えば,
    製造業者及び保全業者),供給者(例えば,サービス提供者,構成品供給者),及び故障によって悪影
    響を受け得る人を含むことがある。

4.3 用語

  この規格での便宜を図り,FMECAを含む,解析の何らかの適用又は何らかの程度のテーラリングを表
す一般用語として,“FMEA”と略されるタイトル“故障モード·影響解析”を用いる。
  用語“アイテム”又は“プロセス”を,FMEA解析の対象を示すために用いる。アイテム又はプロセス
は,複数のFMEA解析が必要とされる,より大きなシステムの一部である場合がある。上位,中位及び下
位の階層レベルに一般的に関係する用語の例を,表1に示す。表1内の用語は,全てを網羅したものでは
ない。例えば,ソフトウェアはハードウェアシステム内に組み込まれていることがあり,システムには人
という側面を含むことがある。
                            表1−階層レベルと一般に関係する用語の例
                             最上位レベル        中位レベル         下位レベル
           ハードウェア アセンブリ          サブアセンブリ     構成品
           ソフトウェア パッケージ          モジュール         実行可能コード関数
           プロセス     手順                タスク             ステップ

5 FMEAの方法論

5.1 一般

  図1に,FMEAとして実施する諸活動のフローチャートを示す。これは,計画,実施及び文書化の三つ
に区別される。これらの活動は,一般に,順番に実施するが,例えば,FMEAが開発プログラムの一部と
して実施される場合,又は解析されたシステムを変更しなければならない場合に,これらは繰り返し行い
得る。
  FMEAは,FMEAの適用範囲の中で,又はそれに伴うリスクの種類の範囲内で法令に合うやり方で実施
することが望ましい。
  ある情報を記録,特定,規定,記述,表明,文書化するために,この規格で引用を行う場合は,その情
報を,例えば,FMEA報告書,FMEA計画書,処置計画のようなFMEA後の文書など,関連するFMEA文
書に含まれることを意味する。
  図1に示す活動は,用途に合わせてテーラリングすることが望ましい。これは,挙げている全ての活動
を実施する必要はないことを意味している。附属書Aに,テーラリングの一般的な手引及び例を示す。

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

           10
C 5750-4-3 : 2021 (IEC 60812 : 2018)
                          図1−テーラリング前のFMEAの方法論の概要

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

                                                                                            11
                                                                C 5750-4-3 : 2021 (IEC 60812 : 2018)

5.2 FMEAの計画

5.2.1 一般
  FMEAの計画は,解析の実施理由,解析対象のアイテム又はプロセス要素及びそのシナリオ,並びに最
も効果的かつ効率的な解析手法,の考察を含む。管理者及び利害関係者に,解析において彼らの目標及び
関心が適切に理解され,考慮されるように,必要に応じて意見を聞くことが望ましい。
  計画段階のアウトプットは,特定の状況に対して,テーラリングされ,費用対効果の高いFMEAの適用
について記述した,次のようなFMEA計画である。
− 解析の目標及び適用範囲の定義(5.2.2)
− 解析範囲及び使用シナリオの特定(5.2.3)
− 故障モードの処置の決定の判断基準の定義(5.2.4)
− 解析の文書化及び報告方法の決定(5.2.5)
− 解析活動へのリソースの配分の規定(5.2.6)
  計画には,解析へのアプローチに影響する,次のような要因の記述を含めることも可能である。
− 解析成果が必要となる時期の決定を目的とした,プロジェクトの主要管理点とのインタフェースに関
    する記述
− アイテムの機能又はプロセスのシーケンスを理解するための方法論又は文書
− 契約の要求事項
− 過去の経験及び利用できる情報
  FMEA計画は,独立した文書になる場合もあれば,プロジェクト計画又はシステム工学マネジメント計
画のような,より高いレベルの文書の一部となる場合もある。
5.2.2 解析の目標及び適用範囲の定義
  目標及び適用範囲の定義は,解析の取組の基盤,根拠又は土台を設定し,FMEAへのアプローチの選択
に関する情報を与えることで,解析結果が目標と整合するようにする。
  この活動のアウトプットには,次の事項を含めることが望ましい。
− 解析の理由を定義する,目的の表明
      例 概念設計の頑健性を調べるため,故障を減少させるプロセス又は手順を改善する手段を特定す
          るため,信頼性改善の機会を特定するため,リスクを特定するため,契約の要求事項を満たす
          ため,保全性及び支援性のプログラムの要求事項を提案するため。
− 解析が成功か否かを評価するための,FMEAの最終的な成果物を定義する,目標の表明
  目標の表明は,FMEA計画に含めることが望ましい。
  適用によっては,より正式に利害関係者と相談し,決定及び成果をより適用範囲の広い表明に文書化す
ることが適切なことがある。
5.2.3 解析範囲及びシナリオの特定
5.2.3.1 一般

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

           12
C 5750-4-3 : 2021 (IEC 60812 : 2018)
  重要な側面が,対象範囲に関係する不正確な仮定のせいで省かれることがないように,解析の適用範囲
がFMEAのユーザーと解析者との両方に理解されることを確実にするため,解析の対象範囲及びその境
界,並びに使用条件を記述することが望ましい。この記述は,計画が進行するに従って,より詳しくなる
ことが望ましく,フロー図,機能ブロック図,信頼性ブロック図,機能階層構造図,又はそれらの情報が
記載されている文書の引用を含めてもよい。
  規模が大きい又は複雑なシステムの場合(例えば,鉄道),システムをサブシステムに下位分割して(例
えば,車両,信号,制御室),それぞれについてFMEAの実施を必要とする場合がある。下位分割は,物
理的又は機能的境界に沿って行ってもよく,これは契約の要求事項又は組織の要因に影響される場合があ
る。下位分割は,個々のFMEAの規模が管理可能で,各々のFMEAが他と論理的に接続され,サブシステ
ムの相互影響,及びシステム全体に対する影響を検討できるように選択することが望ましい。サブシステ
ム間のインタフェース(群)に特別に注意を払い,それらインタフェースを含むサブシステムの境界を明
確にすることが望ましい。
5.2.3.2 階層区分及びアプローチの決定
  FMEAは,アイテム又はプロセスの階層の下位分割の,任意のレベルで適用可能である(表1)。FMEA
は解析の目的及び段階に応じて,様々なやり方でアプローチしてもよい。手引及び例を,附属書Aに示す。
  例 開発の初期段階では,FMEAは階層の最上位又は中位レベルに適用可能であり,故障モードの原因
      は,直下のレベルでの要素の故障に限定される。開発段階の後期では,目標に関わる階層の最下位
      レベルの要素が考慮される。これらの要素に関係する全ての故障モード,及び次に高いレベルへの
      それらの影響が特定される。ただし,FMEAは,常に,解析の適用範囲内の階層の最上位レベルに
      対する故障モードの影響を特定する。
5.2.3.3 解析対象範囲の境界の定義
  FMEAの対象とシステムの他の部分との間の境界,関係,依存性及びインタフェースは,ヒューマンイ
ンタフェースを含め,正確に叙述することが望ましい。境界の定義は,アイテム又はプロセスへのインプ
ット,及びそれらからのアウトプットを含み,どのインタフェースが解析の対象範囲内で,どれが範囲外
かを明確に規定することが望ましい。
  解析の範囲は解析の経緯に依存し,設計又は意図する使用のような要因に影響される。FMEAの規模を
制約するために,又はそれらの詳しい知識が得られないために,特定のアイテム又はプロセスのステップ
は明確に対象範囲の外に置くことが必要な場合がある。
  可能であれば,各FMEA,及びそれと他の関連研究との統合を容易にするように,解析範囲を定義する
ことが望ましい。場合によっては,その解析の外にあるアイテム又はプロセスとの関連付けの数を制限す
るために,機能的な視点から解析範囲を定義するとよい。これは,アイテム又はプロセスが機能的に複雑
で,範囲内又は境界をまたいで複数の内部的な関係をもつ場合にしばしばいえることである。
5.2.3.4 使用シナリオの定義
  FMEAに着手するとき,FMEAは,常に,一つ以上の特定の使用シナリオの状況に依存している。FMEA
に適用する使用シナリオは,解析の目標と一致させて定義し,全ての関連する故障モードの特定を容易に
するのに十分な詳しさで記述することが望ましい。シナリオは,規定された通常の使用条件外の,定義さ
れた状態を含むことがある。
  例 シナリオは,ハードウェアを解析するときは“通常の運用”若しくは“保管”,又はプロセスを解析

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

次のページ PDF 16