従属故障分析を考える（再）

2025.12.10

　今回は、2025年４月に配信した ISO 26262における従属故障分析（DFA: Dependent Failure Analysis）の内容を、再配信という形でお届けします。ただし単なる再掲ではなく、現在企画中の「従属故障分析ワークショップ」で扱う予定の内容から、一部を先取りしてご紹介します。
　ISO 26262の機能安全では、ご存じの通り複数の属性が関係し合い、下図のように ①～⑥の組み合わせが存在します。理屈の上では、これらすべての組み合わせ（①⇔②、①⇔③、①⇔④ …）を従属故障分析の対象とすべき、という“ありたき論”もあります。しかし、現場の工数やリソースを考えると、全組み合わせを網羅的に分析するのは現実的ではありません。
そこでワークショップでは、限られた工数の中で
「本当に守らなければならないのはどこなのか？」
ここに焦点を当て、冒頭から丁寧に議論していく予定です。

以下、以前に配信した内容になります。

　今回は、ISO 26262における従属故障分析（DFA: Dependent Failure Analysis）について考えてみます。一般的には、安全分析（演繹的・帰納的手法）を通じてリスクを特定し、適切な対策を講じる流れが取られますが、従属故障分析がどのようにこのプロセスに関与するのか、また、どのような課題があるのかについて考察していきます。

従属故障分析とは

　従属故障分析は、カスケード故障（CF：Cascade Failure）、共通原因故障（CCF：Common Cause Failure）を特定するために実施される分析活動です。

安全分析（FMEA、FTA）との違い

　安全分析（例：FMEA、FTA）と従属故障分析の違いは下表の通りです。

手法	目的	考え方
FMEA	安全機構の各故障モードが安全目標を侵害するかを分析する。	各エレメントや機能の故障モードを洗い出し、それが安全目標に与える影響を評価。重大度、発生頻度、検出可能性を基にリスクを評価し、高リスクな故障モードを特定する。
FTA	安全目標の侵害を引き起こす故障経路を特定し、根本原因を分析する。	トップ事象（安全目標の侵害）を分析し、その事象を引き起こす可能性のある故障モードを分析しツリー状に展開する。
DFA	データフローやインタフェースを通じて、故障がシステム全体に与える影響を分析する。	システム内の依存関係や相互作用を分析し、各エレメント間のデータフローやインタフェースに関連する故障が他のエレメントにどのように影響を与えるかを分析する。

従属故障分析は本当に必要なのか

　FMEAやFTAでインタフェースやデータフローを考慮したツリー構成を採用しているのであれば、従属故障分析を実施する必要はないのではないか、という疑問を抱く方もいらっしゃるかもしれません。本稿では、FTAを例にとり、その必要性を考えていきたいと思います。

　図1は前提とするシステムアーキテクチャを示しており、A、B、C、Dはシステムエレメントを表しています。AはCの出力を入力として動作し、Bも同様の動作を行います。
　図2はミニマルカットセット化されたツリー構造で、データフローの関係は表現されていません。ORゲートの下にある要素はすべて並列であるため、エレメント間の依存関係を把握することができません。また、共通原因故障についてはAND要素から外れ、単一故障として表現されてしまうため、その因果関係を本ツリーから直接検証することは困難です。
　一方、図3は各エレメント間のデータフローを表現したツリーであり、カスケード故障や共通原因故障の関係を可視化できる構造となっています。そのため、安全目標を侵害する要因の妥当性に限っては、本ツリーを用いて検証することが可能です。しかし、どちらの方法においても共通して言えることは、「安全目標を侵害しない根拠」を示すことができないという点です。

安全分析が先か、従属故障分析が先か

　「なぜ安全目標を侵害するのか」という点よりも、「なぜ安全目標を侵害しないのか」の根拠の方が実は重要です。侵害する要因が判定されれば対策を講じることができますが、侵害しないと判断された要因に関しては、抜け漏れを引き起こす可能性があるからです。このように安全分析には、担当者の思い込みが入り込むリスクがあり、かつ外からは確認しづらいという特徴があります。そのため、事前に従属故障分析を行い、網羅的に伝播経路や共通原因故障を特定してから、その結果を基に安全分析を実施することが合理的であると考えます。