機能安全編

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

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

検知できない危険側故障：λ _DU

さてこれで、これから設計するサブシステムが目標とするPFDave／ＰＦＨが定まりました。早速実際に設計したハードウェアのPFDave／PFHを算出する流れをご紹介したいところですが、それは次回ご説明します。

機能安全を達成するための設計指標には、PFDave・ＰＦＨのほかに、SFF（Safe Failure Fraction）、HFT（Hardware Fault Tolerance）、DC（Diagnostic Coverage）もありますが、いずれもまずは、故障の分類について理解しなくてはなりません。その中核をなす重要な概念が、「検知できない危険側故障：λ _DU （ラムダ・ディー・ユー）」です。
（SFF、HFT、DCについても、次回ご説明します。）

IEC-61508では、故障を２つのカテゴリに分けて議論します。１つは電子部品の故障に見られる「ランダム故障」です。もう一方は「システマティック故障」です。システマティック故障とは、いわゆるソフトウェアのバグのように、特定の状況で必ず発生する故障のことです。マニュアルの記載間違いなども、その間違えたマニュアルの指示に従うと必ず間違いを発生させますから、システマティック故障のカテゴリに分類してよいでしょう。

設計した電子システムの実際のPFDave／PFHなどの設計指標の算出をする際に必要となるのは、ランダム故障の発生確率です。

とはいえ、ランダム故障の全てが安全機能を喪失させるような故障に相当するかというと、そうではありませんね。抵抗器一つとっても、断線するケース、短絡するケース、抵抗値がドリフトするケースがありますし、それがどう影響するのかは、その部品が使われている回路によりけりです。（このような故障の仕方をFailure Modeといいます。）冒頭のＡ先輩とＢ先輩の「うっかり口をすべらせた」話は、まさにこの喩えです。

そこで、１つの部品が持つ故障率（λ _total ）をFailure Mode毎に４つの種類に分類します。それが発生した場合にどのような状態になるのかを１つ１つ詳しく解析するのです。（正直気の遠くなる作業です。この仕分けし集計する作業を、FMEDA（Failure Modes Effects and Diagnostics Analysis）といいます。これについても次々回解説します。）

ここで問題になるのは危険となる故障（安全機能を喪失させるような故障）ですが、危険側故障といっても、故障したことが検知できる故障（λ_DD）もあれば、故障したことがすぐに表に現れず、イザというときに「実は壊れていました。ごめんなさい。」と表沙汰になる故障（λ_DU）もあります。

λ _DD ならば「危険側」といっても、対処のしようもあります。定期的にテストをすれば発見することが可能です。発見できれば修理することも出来ます。しかし、λ _DU では対処のしようもありませんし、修理することが出来ないため、長期にわたって蓄積してゆく可能性もあります。普通では同時に発生する確率が極めて低い稀な２つの故障があった場合、それがλ _DU の状態（つまり、潜在的な故障状態）だとすると、長期間の稼動では１つ目が発生しても修理されませんから、いつか２つ目が発生した際に、結果的に「同時に発生した」状態と同じ問題が発生する可能性が高くなります。ということで、λ _DU はとても厄介です。


安全の議論の後、あるドイツ人の関係者とお寿司を食べに行った際に、「わさび」が入っているかどうかを指して、「これはλ _DU だろうか」と議論になりました。お寿司が回転する様なお店では、自分でついうっかり「わさびヌキ」と「わさびイリ」を間違えて手にしてしまうからです。苦手なわさびを手にするFailureを、検知することが出来ない。だからそれをたとえ話として、λ _DU ではないか、と指摘したわけです。

その後の議論の結果、「イカなら透明で、わさびが透けて見えるから、λ _DD （検知可能）だ」となりました。（このように機能安全関係者は、酒の席でも用語を使って楽しみます。）余談でした。すみません。


次回以降ご説明する、機能安全のPFD、SFF、DCなど様々な設計指標は、この厄介なλ _DU の量がどれだけあるのか、それが重要な要素となります。機能安全に適合した電子システムを開発する作業は、このλ_DUとの戦いといっても過言ではありません。前述の様々な指標も、λ _DU がどの程度の大きさなのかに大きく依存します。言い換えれば、規格にマッチするかどうかは、どれだけλ _DU を小さくするような仕掛けや設計をするのかに掛かっているともいえます。

しかしλ _DU は、決して０にすることは出来ません。このため、λ _DU を小さくするために診断回路を充実させたり、λ _DU をλ _DU ２とすることをねらって多重化したり、また多様化（多重化の際の共通要因故障の排除※次回ご説明します。）をするなど、構想設計段階でシステム構成を検討する必要が出てくるのです。

次回はこれらの設計指標の算出方法をご紹介することで、それらがシステムの構成すなわち構想設計によって変化することをご紹介してゆきます。

Archive

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