RAMS[12] 故障対策

（注：ここでは「部品」と言っていますが、「機能」と置き換えても問題ありません）

ここでは、ハードウエアアーキクチャ―について少し書きたいと思います。ハザードが起きる原因は二つあります。それは、設計ミスとハードウエア故障によるものです。設計ミスとは、そもそもハザードを認識していなかったり、その対策を間違えたり、ソフトやハードの設計にバグ（設計は正しかったけど、実装に間違いが意図せずに入った）あったりすることです。これは、もう、設計のプロセスとテストで抑え込むしかありません。前回までに設計手法で説明したのはこのような誤りを排除するための手段だったのです。このような故障を系統的な故障（システマチック故障）と言います。系統的な故障が内在した装置はすべてにおいて同じ故障を誘発します。

一方ハードウエア故障というのは部品の故障によるものです。これを偶発故障とかランダム故障と言います。この故障はその故障が起きた装置だけに発生して、他の同じ設計した装置には起きません。もし、多数同じランダム故障が起きるのであれば、それは設計ミス、すなわち、系統的な故障に分類されます。これは、部品の選定を間違えたとか、部品の使い方を間違えたとかで発生します。部品そのものの製造不良も広義の系統的故障になるのではないかと思います。

部品のランダム故障は一定の確率で起こります。これを防がないと安全装置とは言えません。ランダム故障は起きるものだという前提のもとアーキテクチャーが考えられて、IEC62425ではSIレベルによってそのアーキテクチャーが決まっています。

対策には考え方が二つあります。一つは部品が壊れても危険側にならないようにすることです。これをフェールセーフ( Fail -Safe) と言います。代表的なものは鉄道用信号リレーです。リレーの危険側故障はリレーが落下しないという故障です。これを重力やばねで強制的に落下させることによって、必ず落下させることを保証することでフェールセーフを担保しています。

もう一つのやり方は、部品が故障したことを検知して、安全側に推移させることです。この場合は、故障した部品によって多重故障を誘発しない、検知機能がなくならないことが条件です。これを独立性と言います。例えば、一つの部品が壊れることによって、単一故障しか想定していないのに複数の故障を誘発するとか、検知機能そのものを喪失するとかです。

同時に複数の部品が故障、検知機能が喪失するような事象 （多重故障） の原因があっても駄目です。このような原因で起きる故障を共通原因故障（Common Cause Failure : CCF）と言います。例えば、東日本大震災の電源喪失は複数の自家発電機があったのにも関わらず、一度の津波で複数の電源喪失を起こして、原発の安全機能が喪失しました。これがCCFです。

CCFの対策には多様性（Ⅾiversity）が有効です。前述の電源喪失の場合は、各々の電源を離れたところに置くという空間ダイバーシティが有効です。ほかの多様性として、時間ダイバーや手法を変えるダイバシティもあります。部品レベルでも機能レベルでもシステムレベルでも同じ考えが使用できます。また、安全性という視点ではなく稼働率という考え方の多重系でも同じ考え方使われます。せっかく、多重系にして稼働率を上げようとしたのに、多重系全部が機能喪失するCCFがあれば稼働率は満足できないケースがあるということです。