あの事故はなぜ起きたのか!!(5) ―― マネージメント規格IEC61508に基づく安全度水準の求め方

●ステップ④：危険側ランダム故障確率評価

　危険側ランダム故障確率評価とは，システム構成に基づいた信頼性理論によってランダム故障確率を評価することです．IEC 61508の第6部には，各種の冗長系に対する信頼度を求める式が例示されています．
　まず最初に安全機能の要求が低頻度か高頻度かを指定します．およそ1年に1度以下の作動要求が見込まれるものを低頻度とし，それより大きいものを高頻度と定義します（連載第4回を参照）．

• 低頻度作動モードにおける2重系（1-out-of-2D）の作動要求失敗確率

以下に，低頻度作動モードにおける2重系の作動要求失敗確率（PFD：Probability of Failure on Demand）の計算式を示します．
　　PFD＝2（1－β）λDU･{（1－β）λDU +（1－βD）λDD + λSD}TCETGE + βDλDD MTTR + βλDU（T1/2 +MTTR）
　　ただし，

　　β：検出できない共通原因故障確率，βD：検出可能な共通原因故障確率，λDD：検出可能な危険側故障率（1/h），λDU：検出できない危険側故障率（1/h），T1 ：プルーフ・テスト間隔（h），MTTR：平均修理時間（h）とする．　これは図3のような「1-out-of-2D」の例，つまり2重系において各系統の診断装置が設置されていて，各系統が危険側故障になっていないことを確認できる仕組みになっている場合の式です．なお両方のチャネルの演算結果などを相互比較する場合は，診断装置には両方のチャネルの情報が必要となります．

• 高頻度または連続モードにおける2重系（1-out-of-2D）の単位時間当たりの安全機能失敗確率

　以下に，高頻度または連続モードにおける2重系の単位時間当たりの安全機能失敗確率PFHを示します．
　　PFH＝2（1－βD）λDU･{（1－β）λDU + （1－βD）λDD +λSD}TCE + βD λDD + βλDU

　これらのデータを算出するには，各系統の故障が安全側であるか危険側であるか，それらは検出可能か検出できない故障か，また，それらの故障率はどの程度であるか，などのデータを評価しなければなりません．そのためには製品や部品の故障率測定や，FMEAなどの詳細分析を実施する必要があります．
　多重化したといっても，同一設計のものを多重化すると，同じ原因で同時に故障することがあります．これを共通原因故障と称していますが，IEC 61508には共通原因故障確率を推定する評価方法が提示されています．
　ところでPFDあるいはPFHを算出する際に注意が必要な点は，これらがプルーフ・テスト間隔に依存していることです．プルーフ・テストとは，自動車なら車検，プラントなら定期検査に当たるものです．すべての安全機能が作動することを定期的にテストし，不具合があれば新品と同じレベルに戻す作業です．このようにPFDあるいはPFHはプルーフ・テスト間隔に依存しているので，製造者は製品を出荷する際に，ユーザに対して必要なプルーフ・テスト間隔を通知する必要があります．
　以上の解析を基に表2に示すSIL定義表を参照して，PFDあるいはPFHの該当する欄から，SILの値を求めます．

図3 2重系「1-out-of-2D」の例
2重系において各系統の診断装置が設置されていて，各系統が危険側故障になっていないことを確認できる仕組み．

●ステップ⑤：SIL値の決定

　以上の手順に従い，表1に示すアーキテクチャ制約によるSIL値と，表2に示す危険側ランダム故障確率評価から求めたSIL値と，どちらか低い方を最終的なSIL値とします．
　この2重規定は産業界から評判が悪く，現在審議中のIEC 61508改訂版において再検討されています．もともとこの思想は，危険側ランダム故障確率の評価に当たって自分に都合の良い故障率データを採用するのを防止するために，外形的に明確なアーキテクチャの制約を設けているわけで，いわば人間性悪説に立ったものです．しかし最近の耐震強度偽装事件や食品偽装事件，さらには建材耐火性偽装事件などを見ると，こういう考えが適切かもしれないと思うようになりました．

表2 危険側ランダム故障確率評価から求めたSIL値
注1： 作動要求当りの設計上機能失敗平均確率
注2： 単位時間当りの危険側失敗確率（1/h）

●ステップ⑥：ハード/ソフト統合と安全妥当性確認

　ハードウェアが完成した後に，別途設計したソフトウェアを実装します．その後，あらかじめ定めた計画書に従って安全妥当性確認を行います．つまり安全要求仕様書通りの設計となっているかどうか，言い換えると定められた安全機能を実行でき，意図しない機能が実行されないことをテストによって確認します．なお機能安全設計で残るリスクについては，安全マニュアルなどの文書で，ユーザに通知する必要があります．なおソフトウェア設計については次回解説します．
　図4に安全関連系の例を示します．一般的にはセンサ，コンピュータ，アクチュエータ（弁やリレーなど）で構成され，場合により伝送系（通信系）も含まれます．なお，認証や規格適合の場合，部品だけ，例えばセンサ・メーカであればセンサだけの認証を取る，あるいは規格適合させるというケースもあり得ます．ただし最終的には図4に示すような統合された安全関連系として設計あるいは評価する必要があります．

図4 センサ入力，アクチュエータ出力をもつ安全系の構成例