論理回路のエラー訂正

このようにメモリに関してはエラー訂正コードを使って比較的少ないビット数と回路を追加することでエラーの検出、訂正を行うことができるのであるが、複雑な論理機能をもつ論理回路のエラー訂正は簡単ではない。

原理的に最もすっきりしているのは、図2.20に示す多数決である。エラー検出を行うために、まったく同じ機能を持つユニットを2個使って出力を比較する構成は以前に述べたが、多数決では、同じ機能のユニットを3個使用する。そして、各出力信号は、3つのユニットの対応する出力ビットの多数決で決める。

図2.20 Voterで3ユニットの出力の多数決をとる

故障は1つのユニットの出力にしか影響を与えないとすると、常に2つのユニットの出力は正しく、等しいので、1つのユニットが誤った出力を出しても、それは多数決を行うVoter(投票メカニズム)で訂正されてしまう。

しかし、この構成では、ユニットの中の単一故障は多数決で訂正されるが、Voterの故障や出力線のStuck故障が起こるとエラーになってしまう。これらの部分も3重化したのが、次の図2.21に示すTriple Voterの構成である。

図2.21 3組のVoterを使うTriple Voter構成

図2.21の構成では、次段のユニット1~3それぞれの入力の生成のための3つのVoter群を使う。この構成では、Voterの故障や出力線に故障が発生しても、1つの次段ユニットへの入力が誤るだけで、残りの2つの次段ユニットの入力は正しい。これらのユニットは正しい結果を出し、次段ユニットの出力に設けられたVoterでエラーが訂正される。このように、Triple Voter構成を使えば、すべての単一故障を訂正することができる。

これら図2.20や図2.21の構成は3つのユニットを使う冗長構成であるので、TMR(Triple Modular Redundancy)と呼ばれる。

TMRは、単一故障であれば誤ることはないが、1つのユニットに固定故障が発生し、そのユニットを切り離すと2つのユニットしか残らず、どちらか一方に間欠故障が発生して出力が誤ると、訂正できないという問題がある。非常に高い信頼度を要求されるシステムでは、スペアの4番目のユニットを持ち、固定故障が発生したユニットをスペアで置き換えることによりTMRを維持するというような構成もある。

少し話がそれるが、このように多重化しても設計にバグがあると全部のユニットの出力が同じように誤ってしまうので、訂正ができない。このため、エアバス社のA300のFly-by-Wireシステムでは、異なるプロセサを使い2つのデザインチームが独立に開発したハードウェア、ソフトウェアを使うという風にして設計時のエラーも検出するという構成になっている。ここまでやっても元の機能仕様が間違っていればダメであるが、そこは形式論理のチェックなどをつかって矛盾がないことを検証している。このような設計や実装はコストがかさむが、大型旅客機が電子回路の故障や誤動作で墜落するリスクやコストを考えるとペイする。なお、A300のFly-by-Wireシステムは3重化によるエラー訂正ではなく、異なるチームの開発した同一機能のユニットの出力が異なる場合には、人間のパイロットに判断を委ねる。その意味ではパイロットは装置の判断の上位の最終権限を持つ、3重化の内の1つのユニットとみることもできる。

ボーイングの777のPrimary Flight Controlシステムはさらに徹底しており、AMD 29050、Motorola 68040、Intel 80486と3種類の異なるマイクロプロセサを使うコンピュータを使ってTMR構成を取り、さらに、このTMRユニットを機体の左右と中央と位置的にも分散して置き、これらの3つのTMRユニットで多数決を行う2階層のTMR構成となっている。

また、NASAの有人ロケットの打ち上げなども、電子回路の誤動作で失敗した場合の損失が大きいので、多重化システムが用いられている。

このような多数決システムは非常に信頼度が高いが、同じユニットを3個使い、多数決回路の追加も必要となるので、コスト的には単一ユニットの場合と比べて3倍以上のコストとなってしまう。

論理回路のエラー訂正をもう少し安く実現できないかということで考えられた方式の1つが、Checkpoint-Restart方式である。この方式では図2.22に示すように、ハードウェアのアーキテクチャ状態(フリップフロップやメモリなどの状態)を定期的に記憶する。ただし、キャッシュメモリなどは全てクリアして実行を再開したときにメモリから再度読み込みを行わせるようにして、アーキテクチャ状態の記憶量を節約する。

この記憶されたハードウェア状態をチェックポイントと呼ぶ。そして2重化比較やその他の方法でエラーが検出された場合は、エラーが検出される前の時点のチェックポイントの値を読み出してハードウェアの状態を復元して、そのチェックポイントを作った時点以降の命令実行の影響を全てキャンセルし、チェックポイントの次の命令から実行を再開する。

図2.22 Checkpointにアーキテクチャ状態を格納し、エラー時にはエラー前の状態を復元

このようにすれば、ちょうど、Wordなどのソフトのundo(取り消し)機能と同じで、間違った実行の影響を取り消し、間違いの前の時点からやり直せる。Checkpoint-Restartは、これのハードウェア版である。しかし、この機能を実現するのは容易では無く、プロセサのCheckpoint-Restartを実装しているのは、IBMのZシリーズメインフレームとPOWER6以降のハイエンドサーバプロセと、富士通のメインフレームとSPARC64プロセサに限られている。

通常のデータを処理するプロセサでは3重化はハードウェアの増加が大きいので、 Checkpoint-Restartが用いられるが、Checkpoint-Restartはエラーの検出から正常動作に復帰するまでにある程度の時間がかかる。通常のデータ処理を行うサーバでは、この遅延時間はあまり問題ではないが、Fly-by-Wireのようなリアルタイムシステムでは、レスポンスが遅れるとその間に飛行機が墜落してしまう恐れもある。したがって、リアルタイムシステムではCheckpoint-Restartではなく、3重化などの処理が中断しないエラー訂正方式が用いられる。