機能安全編

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

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

ある高校野球部のマネージャが、ドラッガーの「マネージメント」を読んで、甲子園に行くことを集団の価値として追求したようです。そんな彼女達がIEC-61508を読んで、機能安全を学んだとしたら何をしでかすでしょうか。

IEC-61508を熟読した高校野球部マネージャ「みなみ」のチームには、和也という優秀なピッチャーがおり、彼女は交際相手として猛烈にプレッシャーをかけて練習に励ませます。その一方万一に備えて、その双子の兄の達也とも二股をかけています。なにせ双子ですから才能はあります。どちらかになにかトラブルがあって試合に出られなくても、「みなみ」の目的は達成できそうです。彼女はこれを「二股」とは言わず、「多重化」と呼ぶこととしました。機能安全っぽいですね。

しかしこの多重化が功を奏するかどうかは、機能安全的には微妙です。なにせ同じ家に住む双子ですから、基本的に同じものを食べるでしょう。学校も同じですから、通学路も同じ可能性があります。二人は特に仲が悪いわけではないので、家族で同じ車で旅行に行く機会もあるかもしれません。この様なケースでは、共通要因故障（Common Cause Failure）の可能性が高くなります。

たとえば、夕食の食事になにかあったとか、二人の目覚まし役のお母さんが寝過ごすとか、二人が乗る通学途中の電車が大幅に遅延するかもしれません。このような場合、それが試合当日であったら、大切な試合に両方とも出られない可能性があります。

機能安全的に考えるならば、「みなみ」は出来るだけ共通のトラブルに見舞われない相手で二股、いえ多重化をするべきでしょう。

可能ならば仲が悪く、生活習慣が正反対な双子が安心です。双子の二人を仲違いさせて、口も利かない間柄にすることは有効です。さらにできれば北海道と沖縄など、土地が離れているほうが安全です。二人を別居させることも意味があります。

このようにすれば、共通点が少なくなりますから、みなみの目標がトラブルで失敗する可能性は大幅に減少するかもしれません。（とはいえ、両方ともみなみと交際していますから、みなみが共通のトラブル要因になる可能性は否定できませんが。。。。）

某マンガでは他方はそもそも野球をしておらず生活も怠惰だという設定ですが、意外にそれは幼馴染の「みなみ」が幼少のころから本能的に、この双子に仕向けたことかもしれません。みなみ恐るべし。

このように共通のトラブル要因を排除する方法には、多様性（Diversity：違う個性を組み合わせる）、分離（Separation：物理的・電気的に分離する）、などいくつか方法があります。詳しくはIEC-61508 Part6のβファクタのスコア表を見てください。βファクタとは、多重化したシステムのPFDを簡略化して求めるために、このような共通点を便宜的に係数として表したものです。

βファクタというものを仮定してPFDを算出する方法は、システムがもつ問題点をわかり易く表現し、また対策の検討をしやすくする効果があります。多重化するシステムを構想設計する場合には、この共通故障要因（Common Cause Failure）を十分に洗い出し、対策を施すことが大切です。これが「みなみ」が機能安全から学んだ危険回避の方法だといえるでしょう。

とはいえ、ドラッガーを読んだ「みなみ」は青春の熱いドラマになりましたが、機能安全を熟読し二股を多重化と言い換える「みなみ」は、かなり嫌なヤツになりそうです。ベストセラーにはなりそうにありませんね。

（前回までの振り返り）
前回までのメルマガで、リスク分析から導かれる安全完全性の指標ＳＩＬと、それに対してシステムが満たすべき『危険側不動作確率の平均』PFDaveの算出方法をお話しました。
いくつかの数式が出てきましたね。その式では、「検知可能な危険側故障：λDD」と「検知できない危険側故障：λDU」に故障が区別されていました。

このλ _DU は、多重化システムを組む際に重要な要素でした。システムが多重化した意味を損ねることがないようにするためには、他方が故障した際に修理できなくてはならない、つまり故障したことが検知できることが大切でしたね。このため、機能安全ではＳＦＦ（Safe Failure Fraction）という指標を用い、多重化との関係性によって、そのシステムが主張できる安全完全性レベル（ＳＩＬ）の上限を規定していました。このことは、システムにとって、λ _DU を小さくすることが如何に大切かを示しています。

前述の「みなみ」の例で言えば、和也は実は肩を故障していて危険な状態かもしれません。それをマネージャに隠しているかもしれません。「みなみ」が適切に二股相手に乗り換える、または和也を病院に連れてゆくためには、和也の私生活をも詳しく監視する必要があります。必要ならば和也の携帯も覗く必要があるでしょう。すなわち、λ _DU を少なくすることが、この二股を確実に意味のあるものにします。これがＳＦＦの意味です。

さらに多重化したシステムでは、共通の要因での故障（Common Cause Failure）を、仮想的なサブシステムとして仮定することで全体のPFDを算出することもお話しました。その共通要因故障の故障率は、βファクタと呼ぶ便宜的なパラメータを使って割り当てること、またそれはIEC-61508 Part6にあるスコア表から算出することが出来ることもお話しましたね。冒頭の「みなみ」のお話は、このβファクタを考える上での一つの喩えでした。



βファクタは、規格書に記載の要因をチェックしながら、いくらの数値にすることが妥当か診断します。勿論この表に基づききちんと審査を受けることは大切ですが、機能安全を考慮したシステムを設計する場合、このβファクタの表は参考例でしかありません。

なぜならば、システムや開発設計プロジェクトの業務に潜むCommon Cause Failureは、つくるシステムによって複雑に変化しますし、会社や組織毎に事情は様々です。

このため機能安全に取り組む場合、この表自体を斜めから上から眺めて吟味するのではなく、ここに書かれている精神を参考に、自分たち自身で共通要因故障となる問題点を洗い出す必要があるのです。この取組みの重要なスタートが、これからお話しするSystem FMEA、およびFTAです。