機能安全編

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

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

せっかく厳密な確率の話を積み重ねてここまで来ましたけれど、多重化の場合にはなんか怪しげなβなる「鉛筆なめなめ」係数が登場してきたことは、かなり違和感がある方も多いと思います。しかし、MarkovモデルやFault Tree図を用いた厳密なモデルを設計するシステムにあわせて構築し計算すると、もう今回のメルマガの範囲を大きく逸脱するような、行列の指数関数がばんばか登場しますし、その解は数値解析でしか得られないものになる場合が多くなります。そうなると、どこがどのように問題なのかの検討も系統的に行うことが難しくなるでしょう。Common Cause Failureという考え方を用い、このような四則演算の範囲で記述することは、構想設計での検討をより深いものにする為にも有用だろうと思います。

IEC-61508 Part6 AnnexDには、このβの値を表から求める方法を提示しています。様々なチェックポイントでのスコアを最終的に合計し、その合計スコアで、βが○○％と求まる表です。なんかお昼のテレビ番組の「あなたの○○度チェック」みたいな体裁です。

しかし前述のようなモデルで機能安全の設計をするうえでは、このβファクタを避けて通ることは出来ません。βファクタとはつまり、多重化したサブシステムが潜在的にもつ、サブシステム間の共通要因での故障率の割合を示す便宜的な係数です。多重化したものが、どのような素性で設計されたのか、また作られているのか、そういう「共通要素」を洗い出し吟味することが、全体のPFDを求めることに繋がると考えているのです。（この共通要因での故障およびβファクタについては、次回以降のメルマガでも再度取り上げます。）

βファクタのスコア表には、設計するシステムの構造的な事項だけではなく、「異なる設計者が設計したか？」や、「使用する設計上の技術は５年以上実際に首尾よく稼動したか？」などの詳細設計時の設計手法や組織体系にも影響する事柄が書いてあります。

出来るだけ式を使わずにわかり易くご説明しなければならないこのメルマガで、今回数式をいくつか登場させたのは、このβファクタを決めることが多重化システムを設計する上でとても大切だということをお伝えしたかったためです。

そしてこのβファクタは、詳細設計が完了して、モノが出来てからチェックしていては、手遅れです。全部設計が終わってから、スコア表の「異なる設計者で設計されたか？」なんていわれても、後の祭りだからです。このことはすなわち、いわゆるモノづくりの詳細設計段階の前の構想設計段階で、設計手法や開発体制など、プロジェクト全体について十分に考えておくことが大切であることを示唆しています。

今回冒頭で、アニメ、エヴァンゲリオンの三重化計算機についてお話しましたが、まさにこのような重要なシステムは、１台を設計してあとはそれを単に多重化する、という構造では多重化する意味が薄れることの喩えでした。もしも全く同じ装置を単に３台並べただけであれば、敵から「共通な弱点部分」を攻撃されて「全く同時に」ダウンすることも予想されるわけです。これが、今回ご説明した、Common Cause Failureです。

Common Cause Failureを構想設計段階で十分に検討することとは、単にPFD(不動作確率)の値を目標の値にするためだけに必要なわけではありません。今回設計するシステムの全体を俯瞰し、どのようなCommon Cause Failureが想定されるのか、それを防ぐためにどう手を打つべきか、本来は自らで十分に考え出さなければなりません。規格書の上では、スコアに基づき数値を算出すれば終わりますが、本質的に十分に信頼性のあるシステムを設計する、という目標を掲げるのであれば、このβファクタのスコア表に頼るのではなく、構想設計段階で自分たちなりのCommon Cause Failureの洗い出しを十分にすることが大切なのです。これは次回取り上げるSystem FMEAでの重要な視点です。


今回はPFD(不動作確率)の算出方法をお話しすることで、多重化システムの設計を行ううえでの構想設計の大切さをお伝えしてきました。次回は、構想設計段階でもう一つ大切な活動、System FMEAについてお話します。

Archive

• 機能安全　～上流で設計すべきもうひとつの品質