機能安全編

株式会社制御システム研究所　森本　賢一

2010.09.30
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（多重化とサブシステムの設計指標ＳＦＦ）
しかしせっかく多重化しても意味を持たないケースもあります。たとえば火災検知器を考えてみましょう。

すごく心配性な人がいて、１つの部屋に２つの火災検知器を取り付けました。ところが設置した翌日に、１つの検知器が「火災を検知しても報知できない故障」をしたとします。しかし故障したことをその人が知ることが出来ない、としたらどうでしょうか。設置した翌日からは、２台あっても、実は１台だけの状態が何年も続くことになります。これでは、はじめから１台しかない場合となんら安心度が変わらないことはわかりますよね？

このように多重化するという工夫は、そもそも片方が故障したことが検知できることが前提となって意味を持ちます。この検知できる危険側故障率を「λ _DD 」といいました。

もちろん、故障しても火災検知器の機能に影響がない故障（＝λ _S ）なら発生しても多重化した意味は失われませんから、結局、多重化して意味を持つかどうかは、「λ _S ＋λ _DD 」が十分に大きいかどうかが判断基準になります。この割合を「ＳＦＦ：Ｓａｆe Failure Fraction」といいます。



つまり、そもそも多重化して意味があるかどうかは、λ _DU がどのぐらい沢山あるのかどうかで、話が変わってくるのです。

IEC-61508では、コンピュータを搭載したような複雑なシステムに対して、次のような関連付けを規程しています。



「HFT：Hardware Fault Tolerance」というのは、その「数値＋1」のサブシステムに障害が発生したら、機能喪失を引き起こす恐れがあることを示しますから、単純な二重化システムでは、HFT＝1となります。詳細は補足リンクをご参照下さい。

このように、

• ・サブシステムの多重化は全体のPFDave／PFH（システムの不動作確率）に影響を与える。
• ・サブシステムのλ _DU の合計は、SFFという設計指標で制約される。

つまりサブシステムを具体的に設計するためには、サブシステムの構成からサブシステムに求められるＳＦＦを明確にすることが必要です。サブシステムのSFFを算出し、それを目標値に近づけてゆくためのより詳細なサブシステムの設計（すなわち、λ _DU との戦い）をすることになります。この部分は次々回第五回にご説明します。


（構想設計の重要性）
いわゆる日本風のものづくりでは、構想設計という段階は「キックオフ」に近い印象を持つ場合が多いです。実際の詳細な設計は下流でそれぞれが分担して行い、ある程度進捗した段階で「すり合わせる」。これが誰もがもつ構想設計のイメージです。ひょっとすると構想設計段階のブロック図には、担当者の名前や担当部署が記載されて終わり、という例もあるかもしれません。

どんな部品を選定するのか、どんな回路にどのような診断機能を持たせるのか、異常の場合にどのような警報信号を出すのかなど、それぞれ下流のプロフェッショナルが経験や標準マニュアルなどのルールで規定して行くというスタイルが多いのではないでしょうか。

機能安全IEC-61508は、そのような設計フローそのものを直接否定してはいません。しかしながら規格が明確に求める設計指標や制約は、安全の達成のためには「全体」と「詳細」が相互に関係すること、一方通行ではないことを強く示唆しています。

サブシステムの実現限界が明確になると、全体の構成を考えなおす必要があるかもしれません。たとえば、SFFはどうしても90%未満にしかならないので、全体の構成を「HFT＋1」としなければならない。などのケースです。

実際にモノを作り上げる最終段階になって初めてこのような試行錯誤を始めていては、極めて深刻な工程遅延を引き起こします。しかしその半面、「よかれ」とつぎつぎに過剰な安全機能を追加してしまった結果、全体で見れば、不必要で無駄なコストの発生につながるかもしれません。このようなことから、構想設計段階で、可能な限り詳細設計との連携・連動を考える必要があるのです。

この点に於いて、（株）図研のSystem Plannerは極めて有効な構想設計の環境を提供するのではないかと考えています。構想設計の重要性とSystem Plannerについては、本連載の中心テーマですので、また次回以降、機能安全の開発プロセスをご紹介する中で、繰返しお話してゆく予定です。


（全体のPFDave／PFH[システムの不動作確率]の算出）
SFFを設計指標としたより詳細なハードウェア開発や評価、プロセスは次回以降にご紹介するとして、ここでは明確になったサブシステムの故障確率が全体にどのように影響するかをみてゆきます。

サブシステムのPFDave／PFHが判明したとして、そのサブシステムが直列接続の場合は、それぞれのPFDave／PFHは、それぞれの不動作確率の合計となることは、連載第二回にお話しました。

たとえば「入力」→「演算」→「出力」とすべての構成部分がシングルである場合、つまり単純な直列接続である場合は、そのどれが壊れても機能は失われますから、トータルのPFDaveは、各部分の合計値になるわけです。（OR接続＝たし算）

PFDave　＝　PFDave（入力部分）　+　PFDave（演算部分）　＋PFDave（出力部分）

では１つのサブシステムのPFDaveはどのように計算するのでしょうか。
IEC-61508 Part6 Annex Bには次のような考え方が掲示されています。


あるシステムがあるとする場合、その内部に、ちゃんと動作しないことに繋がる故障λ _D があるとしますと、それはさらにλ _DU とλ _DD の故障部位に分けて考えることが出来ます。



もしもシステムを定期的に検査してλ _DU （検知できない危険側故障率）を見つけることが出来るとした場合の定期健診の周期を「Ｔ」とします。また修理している期間をMTTRと書くと、次のような計算式になります。



Ｔ１：Proof Test Interval（検査インターバル）
ＭＴＴＲ：Ｍｅａｎ Time To Repair：平均修理時間


この式の説明については、補足リンクに２つの形式で掲載しています。１つは感覚的に理解する方法です（それでも数式が多少出てきますが…）。もう一方は私の同僚が導出したMarkovモデルから導出する方法です。いずれの解説も、IEC-61508には出てきません。なので、機能安全のプラントや電子システムを設計する方にとっては、IEC-61508に突然出てくるこの式を、『こういうものだ』、と覚えてしまっても、実際の設計作業や審査機関の審査には影響しません。参考としてご参照下さい。