イベント / EVENT

今回の故障に対するアプローチの対象は、ハードウェアに限定されるのでしょうか。ソフトウェアにも適用できる方法論がありましたら教えてください。
ソフトのロジック的な不具合の場合、同時に発生するその対策は？

冗長性を利用するという概念自体はソフトウェアにも適用できます。ただし、ソフトウェアの故障はバグであり、同じソフトウェア（コード）を使っている限り、多重化しても同じ誤りが発生してしまいます。すなわち独立性がありません。そのため、ソフトウェアを多重化する場合には、同じ要求仕様に対して、いくつかのソフトウェア開発チームが、それぞれ独立にソフトウェアを開発するというアプローチが必要になります。場合によっては、開発言語やオペレーティングシステムも異なるものにするといったことも行われるようです。このようにして開発されたソフトウェアはある程度の独立性を持つと考えられ、冗長化による比較や多数決を行うことができます。このようなアプローチを「Nバージョンプログラミング」と呼ばれます。

この分野の入門書やおすすめの解説書、参考文献がありましたら紹介してください。

拙著ですこし専門的になりますが、「ディペンダブルシステム―高信頼システム実現のための耐故障・検証・テスト技術」（共立出版、2005年発行）という本があります。

２重糸、３重糸にして安心していたら、１系故障に引っ張られて２系も止まってしまうことがあるが、独立させるには、どうすればいいのでしょうか。（今回の話は、各システムが独立であることが前提にあると思われますが。）

独立性を高めるためには、ソフトウェアの場合のように、ハードウェアであっても実現方法や構成方法をそれぞれ異なるものを使用するといった工夫が必要と思われます。

同じ機能をもったユニットを使う必要があるのでしょうか。
異なるユニットを組み合わせるような場合もあるのでしょうか。

比較や多数決を行う場合は、結果が同じになる必要はありますが、詳細な実現は異なっていてももちろん構いません。むしろ、独立性を向上するという意味では、そのほうが好都合です。

ハードディスクのRAIDのように、コストと耐故障性を両立するようなしくみはあるのでしょうか。

単にスペアとして、通常時は使わないでおく代わりに、マルチコアシステムのように、性能を向上させる目的で冗長ユニットを使用することもできると思います。

冗長度を上げると故障に耐えるようになるかもしれませんが、故障に気づかなくなることはありませんか？

単なる３重系多数決システムの場合は故障を検出できませんが、例えば、多数決結果と各ユニットの（多数決を取る前の）出力を比較することで、故障ユニットを検出することができます。正しい出力を出すということと、故障を検出するということは別の機能であり、必要なら後者も実現しておく必要があります。

冗長は、数学的には計算されるかもしれませんが、実際の現象（事象）と一致するのでしょうか？

あくまで確率論的な計算により得られる数値ですので、実際の事象と一致するという保証はありません。ただし、確率計算を行うためのパラメータは、長年実際の現場で起った部品等の故障データから抽出され、データベース化されているものもあり、そのようなデータを元にした計算値はより精度が高いと思われます。

冗長性の確立計算（改悪か改善）は常に行うものなのでしょうか。

冗長システムの評価をするという意味では、必要だと思います。

二重実行をして一致しなかったとき、どちらが正しいかはどう判定するのですか？

アプリケーションによって異なりますが、例えば、計算結果の値が本来入るべき範囲に入っていないような場合は、その出力を出した側を故障と見なすことができます。その他、再実行する、自己診断を行う、等さまざまな方法が考えられています。

ソフトのロジック的な不具合の場合、同時に発生するその対策は？

質問１の回答を参照して下さい。

故障が重なって→システム障害が発生する。重大な故障が起きて→システム障害が発生する。と理解してよろしいでしょうか？

故障が起こることにより、場合によってはシステム障害が引き起こされます。ただし、故障が起ってもシステム障害が起こらないように設計することは可能です。その場合でも、想定した以上の故障が重なるとシステム障害につながります。

冗長性そのものの語句の①定義はどうなるのですか？②英語でいえばなんというのですか？③「何が？」冗長だということですか？

ここでは冗長性として「ある機能を実現するために必要ものが複数個ある」という意味で使っています。英語では、redundancyです。例えば、ある機能を実現するためにコンピュータが１台で十分であるのに、それを２台、３台と用意する場合に、コンピュータが冗長であると言えます。