(57)【特許請求の範囲】
【請求項１】
計算エレメントと、データソースから前記計算エレメントへデータを提供する複数のコントローラを有するコンピュータシステム中で、前記計算エレメントへのデータ転送を同期化する方法において、
前記計算エレメントにおいて、計算エレメント上で実行中のソフトウエアによってなされるデータ要求を遮断する段階と、
前記遮断された要求を前記計算エレメントから複数のコントローラに送信する段階と、及び、前記遮断された要求に対して前記複数のコントローラに応答させる段階であって、
少なくとも第一コントローラが、要求されたデータを前記計算エレメントへ送信すること及び、前記遮断された要求に第二コントローラがどのように応答するかを前記計算エレメントに表示することによって応答する、段階とから成ることを特徴とする方法。
【請求項２】
前記第二コントローラに、前記遮断された要求に対応するデータを前記第二コントローラが持たない旨を表示すること及び、前記遮断された要求に対して前記第一コントローラがデータを計算エレメントに送信することによって応答する旨を前記計算エレメントに対して表示することにより、前記遮断された要求に応答する段階を更に含むことを特徴とする上記請求項１に記載の方法。
【請求項３】
前記遮断された要求に対してあるコントローラがなす各応答において、他の各コントローラが前記遮断された要求に対しどのように応答するかに関する表示を含ませる段階を更に含むことを特徴とする上記請求項１に記載の方法。
【請求項４】
前記遮断された要求に対する一貫性のために応答を比較する段階を更に含むことを特徴とする上記請求項１に記載の方法。
【請求項５】
前記遮断された要求に対し他の各コントローラがどのように応答するかに関する表示を、各応答に含ませる段階を更に含み、前記比較する段階が一貫性のために前記表示を比較することを含むことを特徴とする上記請求項４に記載の方法。
【請求項６】
複数のコントローラの応答が要求されたデータを含む場合、前記比較する段階が一貫性のためにデータを比較することを更に含むことを特徴とする上記請求項５に記載の方法。
【請求項７】
計算エレメントが全コントローラから応答を受信した後に、計算エレメントを通して一貫性のために応答を比較する段階と、比較結果と全コントローラから応答を受信したことを計算エレメントを通して前記全コントローラに知らせる段階とを更に含むことを特徴とする上記請求項４に記載の方法。
【請求項８】
応答が一貫していない場合、コントローラの一つを作動不能にする段階を更に含むことを特徴とする上記請求項４に記載の方法。
【請求項９】
計算エレメントが所定時間内に全コントローラから応答を受信しない場合、エラー条件を生成する段階を更に含むことを特徴とする上記請求項１に記載の方法。
【請求項１０】
データソースが前記第一コントローラに関連し、前記データソースから要求されたデータを、遮断された要求に応じ又前記第一コントローラを通して、獲得する段階を更に含むことを特徴とする上記請求項１に記載の方法。
【請求項１１】
第２コントローラの状態の記録を第一コントローラを通して維持する段階と、第２コントローラが遮断された要求に対してどのように応答するかを表示する時に前記記録を使う段階とを更に含むことを特徴とする上記請求項１に記載の方法。
【請求項１２】
データソースが前記第２コントローラに関連し、前記データソースの状態の記録を第１コントローラを通して維持する段階と、第二コントローラが遮断された要求に対してどのように応答するかを表示する時に前記記録を使う段階とを更に含むことを特徴とする上記請求項１１に記載の方法。
【請求項１３】
他の全てのコントローラの状態の記録を各コントローラを通して維持する段階を更に含み、前記他のコントローラが遮断された要求に対してどのように応答するかを表示する時に前記記録をコントローラに使わせることを特徴とする上記請求項１１に記載の方法。
【請求項１４】
各コントローラをデータソースに関連させる段階と、他の全てのコントローラに関連したデータソースの状態の記録を各コントローラを通して維持する段階と、前記他のコントローラが遮断された要求に対してどのように応答するかを表示する時に前記記録をコントローラに使わせる段階を更に含むことを特徴とする上記請求項１３に記載の方法。
【請求項１５】
データソースの状態が第２コントローラの変化に関連している時、遮断された要求に対する他のコントローラからの応答を棄却する指示を、第二コントローラを通して計算エレメントに送信する段階を更に含むことを特徴とする上記請求項１２に記載の方法。
【請求項１６】
遮断された要求に対する他のコントローラからの応答を棄却することと、前記応答が棄却された旨の知らせをコントローラに送信することで、前記指示に対して計算エレメントを通して応答する段階を更に含むことを特徴とする上記請求項１５に記載の方法。
【請求項１７】
第２コントローラに関連するデータソースの記録を更新することにより、前記知らせに対して第１コントローラを通して応答する段階を更に含むことを特徴とする上記請求項１６に記載の方法。
【請求項１８】
前記記録を更新後、要求されたデータを計算エレメントに第１コントローラを介して再送信する段階と、第２コントローラが遮断された要求に対してどのように応答するかを第１コントローラを介して表示する段階を更に含むことを特徴とする上記請求項１７に記載の方法。
【請求項１９】
データソースが各コントローラに関係しており、各コントローラは、関連するデータソースが要求を処理すると予想されるか否かを決定することと、前記関連するデータソースが要求を処理すると予想される場合、関連するデータソースに対する要求を送信し、要求に関する結果を関連するデータソースから受信し、要求に関する結果を計算エレメントに送ることと、前記関連するデータソースが要求を処理すると予想されない場合、要求に対してデータが提供されない旨を計算エレメントに知らせることによって遮断された要求に対して応答することを特徴とする上記請求項１に記載の方法。
【請求項２０】
計算エレメントと、データソースと、前記データソースから前記計算エレメントへデータを提供する複数のコントローラとを有し、前記計算エレメントは、前記計算エレメント上で作動するソフトウェアがなすデータ要求を遮断しかつ遮断された要求を前記複数のコントローラに送信するように構成され、少なくとも第１コントローラは、要求されたデータを計算エレメントへ送信することと、第２コントローラが遮断された要求に対してどのように応答するかを表示することで、遮断された要求に対し応答するよう構成されていることを特徴とするシステム。
【請求項２１】
前記第２コントローラは、２コントローラが遮断された要求に対応するデータを持っていない旨表示することと、第１コントローラが遮断された要求に対して応答するデータを計算エレメントに送信することによって応答する旨表示することで、遮断された要求に対し応答するよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２２】
各コントローラが遮断された要求に応じて、他の各コントローラが遮断された要求に対してどのように応答するかに関する表示を含むよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２３】
計算エレメントが遮断された要求に対して一貫性のために応答を比較するよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２４】
計算エレメントが全コントローラからの応答を受信した後に一貫性のために応答を比較し、応答が全コントローラから受信された旨と比較結果をコントローラに知らせるよう構成されていることを特徴とする上記請求項２３に記載のシステム。
【請求項２５】
計算エレメントが全コントローラからの応答を所定時間内に受信しなかった場合エラー条件を生成するよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２６】
第１データソースが第１コントローラと関連しており、第１コントローラは遮断された要求中に要求されているデータを第１データソースから得るよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２７】
第１コントローラは第２コントローラの状態の記録を維持しかつ第２コントローラが遮断された要求にどのように応答するかを表示する時に前記記録を使うよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【請求項２８】
第１データソースは第２コントローラと関連しており、第１コントローラは第１データソースの状態の記録を維持しかつ第２コントローラが遮断された要求にどのように応答するかを表示する時に前記記録をつかうよう構成されていることを特徴とする上記請求項２７に記載のシステム。
【請求項２９】
第１コントローラは、第１データソースの状態が変化した時、計算エレメントに他のコントローラからの応答を棄却する指示を送信するよう構成されていることを特徴とする上記請求項２８に記載のシステム。
【請求項３０】
前記計算エレメントが指示に対して、遮断された要求に対する他のコントローラからの応答を棄却することと、応答が棄却された旨の知らせをコントローラに送信することにより、応答するよう構成されていることを特徴とする上記請求項２９に記載のシステム。
【請求項３１】
第１コントローラが、第１データソースの状態の記録を更新することで、前記知らせに応答するよう構成されていることを特徴とする上記請求項３０に記載のシステム。
【請求項３２】
第１コントローラが、記録更新後に要求データを計算エレメントへ再送信し、第２コントローラが遮断された要求に対しどのように応答するかを表示するよう構成されていることを特徴とする上記請求項３１に記載のシステム。
【請求項３３】
データソースが各コントローラに関連しており、各コントローラが、関連するあるデータソースに要求の処理を期待されるか否かを決定することと、前記データソースが要求を処理するよう期待される場合、前記関連するデータソースに要求を送信し、要求の結果をデータソースから受信し、前記要求の結果を計算エレメントに送ることと、前記データソースが要求を処理すると期待されない場合、要求に対しデータが提供されない旨計算エレメントに知らせることで、遮断された要求に対し応答するよう構成されていることを特徴とする上記請求項２０に記載のシステム。
【発明の詳細な説明】
発明分野
本発明は、フォールト回復及びフォールト許容計算に関する。
フォールト回復するコンピュータシステムはハードウェア故障があっても継続して機能する。このシステムはアベイラビリティ又はインテグリティのいずれかのモードでのみ作動する。システムが「アベイラブル」なのは、ハードウェア故障が許容不可能な遅延をユーザーアクセス中に生じさせない時である。従って、アベイラビリティモードで作動するシステムは、ハードウェアエラーに遭遇した時にもし可能ならば、オンラインのままであるように構成される。ハードウェア故障がデータの喪失又は汚損を生じさせない時、システムはデータのインテグリティを保つことになる。従ってインテグリティモードで作動するシステムはデータの喪失又は汚損を避けるよう構成されており、たとえシステムがデータの喪失又は汚損を回避するためオフラインにならねばならない場合でも当然そうした回避がなされる。
フォールト許容システムでは、アベイラビリティとインテグリティが強調される。フォールト許容システムは単一のハードウェア故障に遭遇した時は勿論、状況によっては複数のハードウェア故障に遭遇し時でもデータインテグリティを維持する。
災害許容システムはフォールト許容システムの一歩先を行くもので、自然又は人工的な災害を原因とする計算機能が失われても、システムのアベイラビリティを妨害したり、データを汚損・喪失させたりしないことを要求する。
通常、フォールト回復／フォールト許容システムは幾つかのプロセッサを含んでおり、このプロセッサは計算エレメント又はコントローラとして機能するか又は他の役割を果たしてもよい。多くの事例において、プロセッサの作動又はプロセッサ間のデータ送信を同期化することが重要である。
発明の背景
ある態様で一般に本発明の特徴は、計算エレメントとデータソースから前記計算エレメントにデータを提供する複数コントローラとを含むコンピュータシステムにおいて、前記計算エレメントへデータを同期転送することである。計算エレメントからのデータ要求が、遮断されて複数のコントローラに送信される。コントローラは要求に応答し、少なくとも１つのコントローラが、要求データを計算エレメントに送信しかつ遮断された要求に別のコントローラがどう応答するかを表示することで対応をする。
本発明の実施例には、以下の特徴が少なくとも１つ含まれていてもよい。或るコントローラは、前記遮断された要求に対応するデータを自分が有していない旨と、別のコントローラが計算エレメントにデータを送信することで遮断された要求に応じる旨を表示し、遮断された要求に応答してもよい。遮断された要求に対し或るコントローラがなす各応答には、他の各コントローラが前記遮断された要求にどう対応するかについての表示を含んでいてよい。
計算エレメントは、遮断された要求に対する応答の一貫性を比較してもよい。他の各コントローラが遮断された要求にどう対応するかについての表示を各応答が含んでいる場合、比較することの中に、表示の一貫性を比較することが含まれていてもよい。２つ以上のコントローラの応答が要求データを含んでいる場合、比較することの中に、データの一貫性を比較することが含まれていてもよい。計算エレメントは、比較の結果と全コントローラから応答を受信した旨をコントローラに知らせてもよい。
応答に一貫性がない場合、或るコントローラを作動不能状態にしてもよい。更には、全コントローラからの応答を計算エレメントが所定の時間内に受信しない場合、エラー条件が生成されてもよい。
或るデータソースは或るコントローラと関連していてもよく、前記コントローラは、前記データソースから要求データを遮断された要求に応じて得てもよい。
或るコントローラは、別のコントローラの状態の記録を維持し、前記別のコントローラが前記遮断された要求に対してどう対応するかを表示する際に、前記記録を使用してもよい。あるデータソースが前記他のコントローラと関連している場合、前記記録が前記データソースの状態を含んでいてもよい。各コントローラは他の全てのコントローラの状態の記録を維持してもよく、前記他のコントローラが前記遮断された要求に対してどう対応するかを表示するため、前記記録を使用してもよい。各コントローラがあるデータソースと関連している場合、各コントローラは、他の全てのコントローラに関連するデータソースの状態の記録を維持してもよい。
あるコントローラと関連するあるデータソースが変化した場合、コントローラは、遮断された要求に対する他のコントローラからの応答を棄却する指示を計算エレメントに送信してもよい。計算エレメントは、遮断された要求に対する他のコントローラからの応答を棄却しかつ応答を棄却した旨の知らせをコントローラに送信することにより、前記指示に応答してもよい。あるコントローラは、データソースの状態の記録を更新することで、前記知らせに対し応答してもよい。記録更新後、前記コントローラは、要求データを計算エレメントに再送信し、他のコントローラが遮断された要求に対しどう対応するかを表示してもよい。
あるデータソースが各コントローラと関連する場合、各コントローラは、ある関連したデータソースが要求を処理すると期待されるか否かを決定し、前記関連したデータソースが要求を処理すると期待される場合には、要求を前記関連したデータソースに送信し、前記関連したデータソースからの要求の結果を受信し、前記要求に関する前記結果を送ることで、遮断された要求に応答してもよい。前記関連したデータソースが要求を処理すると期待されない場合は、コントローラは、要求に対しデータが提供されない旨計算エレメントに知らせることで応答してもよい。
別の態様では一般に本発明は、計算エレメントとデータソースから計算エレメントにデータを提供するコントローラを有するコンピュータシステムにおいて、コントローラを計算機に対し非同期的に作動させながら、同一インストラクションストリームを処理する計算処理エレメント間に同期を維持するという特徴を有している。同一インストラクションストリームを処理する各計算処理エレメントは、インストラクションストリーム中の共通点でインストラクションストリームの処理を停止する。各計算処理エレメントは次に、フリーズ要求メッセージを生成してコントローラに送信する。或るコントローラが或る計算処理エレメントからのフリーズ要求メッセージを受信し、他の計算処理エレメントからのフリーズ要求メッセージを待ち受け、同一インストラクションストリームを処理する各計算処理エレメントからフリーズ要求メッセージを受信すると、フリーズ応答メッセージを生成し前記フリーズ応答メッセージを計算処理エレメントに送信する。各計算処理エレメントは、或るコントローラからフリーズ応答メッセージを受信すると、フリーズ要求メッセージが送信された他のコントローラからのフリーズ応答メッセージを待ち受け、各コントローラからフリーズ応答メッセージを受信すると、フリーズリリースメッセージを生成してコントローラへ送信し、インストラクションストリームの処理を再開する。
本発明の実施例は以下の特徴を少なくとも１つ含んでいてもよい。インストラクションストリーム中の或る共通点はＩ／Ｏ操作、所定数のインストラクションの発生のいずれか又は両者に対応してもよい。或るコントローラはフリーズ応答メッセージ中に時間更新を含んでもよく、フリーズ要求メッセージが送信され各コントローラからのフリーズ応答メッセージを受信時に、或るフリーズ応答メッセージからの時間更新を使ってシステム時間を更新してもよい。計算エレメントは、特定のコントローラが生成したフリーズ応答メッセージからの時間更新を使ってもよい。
フリーズ要求メッセージが送信された各コントローラからのフリーズ応答メッセージを受信した時、計算エレメントは、コントローラからのフリーズ応答メッセージを受信する前に或るコントローラから受信したデータを処理してもよい。
別の態様の場合、一般的に本発明は、エラー報告エレメントとエラー処理エレメントを有するコンピュータシステム中でフォールトを扱う特徴を有する。或るエラー報告エレメントはエラー条件を検出し、エラー条件に関する情報をエラーメッセージとして、前記エラー報告エレメントに接続されたエラー処理エレメントへ送信する。少なくとも１つのエラー処理エレメントはエラーメッセージを、前記エラー報告エレメントに接続されたエラー処理エレメントへ再送信する。
別の態様の場合一般的に本発明は、エラー報告エレメントとエラー処理エレメントを有するコンピュータシステム中でフォールトを扱う特徴を有する。複数エラー報告エレメントはエラー条件を検出し、エラー条件に関する情報をエラーメッセージとして、前記エラー報告エレメントに接続されたエラー処理エレメントへ送信してもよい。少なくとも１つのエラー処理エレメントは、複数のエラー報告エレメントから来る関係エラーメッセージからの情報を組合せ、エラー条件のソースを特定する際に前記組み合わせ情報を使う。
エラー処理エレメントは関係するエラーメッセージからの情報を組み合わせるのに状態表を使ってもよい。エラー処理エレメントは、特定のエラーを識別する識別子と、エラーメッセージによって表されるエラーを生じさせたサブコンポーネントを識別するエラーターゲットと、エラーメッセージを生成したエラー報告エレメントとエラーメッセージを受信したパスを識別するエラー報告エレメントを使って、エラーメッセージを表してもよい。エラー処理エレメントは、以前に受信したエラーメッセージが表す状態に対して受信したエラーメッセージを比較することによって、エラーメッセージが関係あるか否かを決定してもよい。
本発明の特徴と利点は、図面を含む以下の説明と請求項から明らかとなろう。
【図面の簡単な説明】
図１は、部分的にフォールト回復するシステムのブロック線図である。
図２は、図１のシステムのシステムソフトウェアのブロック線図である。
図３は、図２のシステムソフトウェアのＩＯＰモニターが用いる手順のフローチャートである。
図４は、図１のシステムのＩＰＩモジュールのブロック線図である。
図５は、図１のシステムの状態移行表である。
図６は、フォールト回復システムのブロック線図である。
図７は、分散型のフォールト回復システムのブロック線図である。
図８は、フォールト許容システムのブロック線図である。
図９は、フォールト図８のシステムのＩＯＰが用いるフォールト診断手順のフローチャートである。
図１０は、災害許容システムのブロック線図である。
図１１は、コンピュータシステムのソフトウェアコンポーネントのブロック線図である。
図１２Ａ、１２Ｂは、ＣＥとＩＯＰの間で転送される情報を示すフロー線図である。
図１３は、ＣＥトランスポートが実行するフラッシュ手順のフローチャートである。
図１４Ａ、１４Ｂは、物理的システム構成と論理的システム構成のブロック線図である。
図１５は、フラッシュ手順のフローチャートである。
図１６は、マイクロコードの状態移行表である。
図１７は、システムのブロック線図である。
図１８は、エラー処理手順のフローチャートである。
図１９Ａは、シンドロームソース表である。
図１９Ｂは、図１９Ａのシンドロームソース表に対応する状態移行表である。
図２０は、コールアウト階層線図である。
図２１Ａ、２１Ｂ、２２は、コールアウトエレメントをリストした表である。
図２３は、欠陥コンポーネントを特定する手順のフローチャートである。
好適実施例の説明
図１に示すフォールト回復システム１０は、Ｉ／Ｏプロッセサ（ＩＯＰ）１２と、２個の計算エレメント（ＣＥｓ）１４ａ、１４ｂ（ＣＥｓ１４と集合的に表す）を有する。システム１０はＩＯＰ１２を１個しか持たないから、ＩＯＰ１２で起きた故障から回復することはできない。従ってシステム１０は完全にフォールト回復する訳ではない。
ＩＯＰ１２は２個の相互プロッセサ相互接続モジュール（ＩＰＩ）１６ａ、１６ｂを有し、それぞれは対応するＩＰＩモジュール１８ａ、１８ｂにケーブル２０ａ、２０ｂにより接続される。ＩＯＰ１２は更にプロッセサ２２、メモリシステム２４、２個のハードディスクドライブ２６、２８、電源供給装置３０を有する。同様に各ＣＥ１４は、プロッセサ３２、メモリシステム３４、電源供給装置３６を有する。独立した電源供給装置３６を使用し、電源供給装置故障時でもフォールト回復を確保する。プロッセサ３２ａ、３２ｂは各指示に関し、プロッセサ３２ａがある指示を実行するのに要するサイクル数と、プロッセサ３２ｂが同一指示を実行するのに要するサイクル数とが等しいという点で互いに同一である。図示の実施例の場合、システム１０を満たすには、プロッセサ２２、３２に対し標準インテル４８６ベースのマザーボードが、メモリシステム２４、３４に対し４メガバイトのメモリが使われてきた。
システム１０のＩＯＰ１２とＣＥｓ１４ａ、１４ｂは変化しないＯＳとアプリケーションソフトウェアを実行させるが、これにはハードドライブ２６がＩＯＰ１２用のブートディスクとして、ハードドライブ２８がＣＥｓ１４用のブートディスクとして使われる。少なくとも２個のＩＯＰを持つ真にフォールト回復／フォールト許容するシステムの場合、各ハードドライブも二重にされることになろう。
図示実施例の場合、ＩＯＰ１２とＣＥｓ１４のためのＯＳはＤＯＳである。しかし、他のＯＳも使える。ＩＯＰ１２は更に、ＣＥｓ１４が作動させたＯＳから異なるＯＳを作動させることができる。例えば、ＣＥｓ１４がＤＯＳを作動させている最中にＩＯＰ１２はＵｎｉｘを作動させることができる。この手法は、周辺装置を支援しないＯＳから前記周辺装置にＣＥｓ１４をアクセスできるようにするので有利である。例えば、ＣＤ−ＲＯＭドライバを支援しないＯＳをＣＥｓ１４が作動させ、ＣＤ−ＲＯＭドライバを支援するＯＳをＩＯＰ１２が作動させることを想定した場合、ＣＥｓ１４は例えばハードドライブにアクセスするために使われたのと同一のＩ／Ｏ要求を発することにより、ＣＤ−ＲＯＭドライブにアクセスできよう。ＩＯＰ１２は次に、Ｉ／Ｏ要求をＣＤ−ＲＯＭドライブにアクセスするのに適したＩ／Ｏ要求に翻訳するであろう。
図２はシステム１０がＣＥｓ１４の立ち上げと同期化を制御し、ＣＥｓ１４中のローカル時間を作動不能にし、ＣＥｓ１４からＩＯＰ１２への全てのＩ／Ｏ実行要求を向け直し、Ｉ／Ｏ要求に関する結果を、もしあるなら、ＩＯＰ１２からＣＥｓ１４へ返却するために用いている特殊化されたシステムソフトウェア４０の全体を示している。
システムソフトウェア４０は２組のＩＰＩ−ＢＩＯＳ４２を有し、各ＢＩＯＳは各ＣＥ１４のＩＰＩモジュール１８中に置かれ、ＲＯＭをベースとしている。ＩＰＩ−ＢＩＯＳ４２は立ち上げと同期化の際に使われる。ＣＥ１４が立ち上げられると、ＩＰＩ−ＢＩＯＳ４２は、システムＢＩＯＳ割込表のＩ／Ｏ割込アドレスをＣＥドライバ４４で制御されるアドレスに置き換える。置き換えられた割込アドレスは、ビデオ、固定ディスク、シリアルコミュニケーション、キーボード、日時に関する諸サービスに対応するアドレスを含んでいる。ＣＥドライバ４４はＣＥブートディスク２８に記憶されＣＥｓ１４で作動される。ＣＥドライバ４４はシステムＢＩＯＳへのＩ／Ｏ要求を遮断し、この要求をＩＰＩモジュール１８を通じてＩＯＰ１２に実行するよう向け直す。ＣＥドライバ４４は更にＩＰＩモジュール１８からの割込要求に応答し、システム時計を作動不能にし、ＩＯＰモニタ４８から供給される情報に基づいてＣＥｓ１４の日時を制御する。
ＩＯＰブートディスク２６上に置かれＩＯＰ１２によって作動されるＩＯＰドライバ４６は、ＣＥｓ１４からのＩ／Ｏ要求をＩＯＰモニタ４８が処理するよう向け直す。その後モニタ４８は要求結果をＩＯＰモニタ４８からＣＥｓ１４へと送信する。ＩＯＰドライバ４６はパケットプロトコルを使いＣＥドライバ４４とコミュニケートする。
ＩＯＰモニタ４８はＩＯＰブートディスク２６上に置かれＩＯＰ１２によって作動される。ＩＯＰモニタ４８はシステム１０を制御し実際のＩ／Ｏ要求を実行し結果を作り出し、その結果をＩＯＰドライバ４６がＣＥｓ１４に送信する。
システムソフトウェア４０は更に、ＩＯＰ１２上で作動するコンソールソフトウェア４９を有し、システム１０をユーザーが制御できるようにする。コンソールソフトウェア４９を使ってユーザーは、ＣＥ１４のリセット、立ち上げ、同期をさせることができる。ユーザーは更に、ＣＥｓ１４の一方又は両方をリセット後又は起動時に、自動的に立ち上げたり（ａｕｔｏｂｏｏｔ）、自動的に同期させたり（ａｕｔｏｓｙｎｃ）ようにセットすることができる。ＣＥ１４をそれぞれに制御できることは正常作動中、テスト目的の両方に役立つ。コンソールソフトウェア４９を使えばユーザーは、ＩＯＰモニタ４８がミス比較エラーに遭遇した際にシステム１０を、ＩＯＰモニタ４８が両ＣＥｓ１４を停止させるインテグリティモード、ＩＯＰモニタ４８がＣＥ１４ａを作動不能にする第一アベイラビリティモード、ＩＯＰモニタ４８がＣＥ１４ｂを作動不能にする第二アベイラビリティモード、のいずれかの状態にすることができる。代替実施例のコンソールソフトウェア４９はＩＯＰ１２とコミュニケイトする独立したプロセッサを使って実行される。
各ＣＥ１４は他方のＣＥ１４が作動させる同一アプリケーション／同一ＯＳのコピーを作動させる。更に、メモリシステム３４ａ、３４ｂは同一であり、ＣＥ１４のオペレーティングコンテキストは同期時毎に同じである。従ってＩＯＰモニタ４８はＣＥｓ１４から同一シークエンスのＩ／Ｏ要求を受信すべきである。
図３に示すようにＩＯＰモニタ４８は手順１００に従ってＩ／Ｏ要求を処理・監視する。最初にＩＯＰモニタ４８はＣＥｓ１４の内の一方からのＩ／Ｏ要求を待っている（ステップ１０２）。例えばＣＥ１４ｂからのＩ／Ｏ要求パケットを受信したとき、ＩＯＰモニタ４８はＣＥ１４ａからのＩ／Ｏ要求、タイムアウト期間満了のいずれかに対し待機する（ステップ１０４）。何故ならシステム１０で使われるＤＯＳは、Ｉ／Ｏ要求を処理する間にアプリケーションの実行を停止するので、ＩＯＰモニタ４８はＣＥ１４ａからのＩ／Ｏ要求を待つ間（ステップ１０４）に、ＣＥ１４ｂからのＩ／Ｏ要求を受信しないことが保証されている。
次にＩＯＰモニタ４８は、タイムアウト期間が満了したか否かをチェックする（ステップ１０６）。満了してない（即ち、ＣＥ１４ａからのＩ／Ｏ要求パケットが届いた）場合、ＩＯＰモニタ４８はパケットのチェックサムを比較する（ステップ１０８）。チェックサムが等しい場合、ＩＯＰモニタ４８はＩ／Ｏ要求を処理する（ステップ１１０）。Ｉ／Ｏ要求を処理後、ＩＯＰモニタ４８は現在の日時を求めＩＯＰ１２のシステムＢＩＯＳに要求を発する（ステップ１１２）。日時を受信後ＩＯＰモニタ４８は、日時とＩ／Ｏ要求に関する結果を含んだＩＰＩパケットを組み立て（ステップ１１４）、ＣＥｓ１４に送信すべく本パケットをＩＯＰドライバ４６に送信する（ステップ１１６）。パケットを受信したＣＥｓ１４は、送信された日時を使って自分のローカル時間を更新するが、このローカル時間は更新が行われない場合は記述のように作動不能になる。
ＤＯＳの要求通り、ＩＯＰモニタ４８がＩ／Ｏ要求に関する結果をＩＯＰドライバ４６経由で返却するまではＣＥｓ１４中における実行は一時中断される。実行再開まで両ＣＥｓ１４の日時は、ＩＰＩパケットから送信される日時に対応する共通の値に更新される。従ってＣＥｓ１４では時間同期が保たれる。送信される日時はメタ時間と呼ばれる。マルチタスキングＯＳを使う場合、ＩＯＰモニタ４８でＩ／Ｏ要求が実行されていてもＣＥｓ１４での実行は中断されない。代わりにＣＥｓ１４での処理が中止されるのは、ＩＯＰモニタ４８がＩ／Ｏ要求の処理を開始した（ステップ１１０）ことを示すアクノレッジメントを受信するまでのみであろう。このアクノレッジメントは日時を含むことになろうし、ローカル時計を更新するのに使われることになろう。
ＩＰＩパケットをＩＯＰドライバ４６に送がオンライン状態あることを確認し（ステップ１１８）、オンライン状態なら、ＣＥｓ１４の一方からのＩ／Ｏ要求に対し待機する（ステップ１０２）。
タイムアウト期間が満了した場合（ステップ１０６）、ＩＯＰモニタ４８は応答し損なったＣＥ１４を作動不能にし（ステップ１１９）、Ｉ／Ｏ要求の処理を開始する（ステップ１１０）。
ＣＥｓ１４から来るパケットのチェックサムにミス比較がある場合（ステップ１０８）、ＩＯＰモニタ４８はシステム１０がインテグリティモード又はアベイラビリティモードの作動状態にあるか否か見極めるチェックを行う（ステップ１２０）。システム１０がアベイラビリティモードの作動状態にある場合、ＩＯＰモニタ４８は選択されたアベイラビリティモードに基づき適当なＣＥ１４を作動不能にし（ステップ１２２）、Ｉ／Ｏ要求を処理する（ステップ１１０−１１６）。その後作動不能にされたＣＥ１４が修復されて再起動されているかを決定する（ステップ１１８）。修復・再起動されてない場合、ＩＯＰモニタ４８はオンライン中にあるＣＥ１４からのＩ／Ｏ要求を待ち受ける（ステップ１２４）。ＣＥｓ１４の一方が作動不能の場合、システム１０はもはやフォールト回復の状態ではなく、ＩＯＰモニタ４８は直ちに受信したＩ／Ｏ要求を処理する（ステップ１１０）。
システム１０がインテグリティモードで作動中にミス比較を検出すると、ＩＯＰモニタ４８は両ＣＥｓ１４を作動不能にし（ステップ１２６）、処理を止める（ステップ１２８）。
再度図１、２に戻ると、例えばＣＥ１４のアプリケーション又はＯＳがシステムＢＩＯＳに非Ｉ／Ｏ呼びかけをすると、システムＢＩＯＳは要求を実行して、システムソフトウェア４０を呼び起こすことなく結果をアプリケーションに返却する。しかしアプリケーション又はＯＳがＩ／Ｏ−ＢＩＯＳ呼びかけをすると、ＣＥドライバ４４ａはＩ／Ｏ要求を遮断する。Ｉ／Ｏ要求を遮断後のＣＥドライバ４４ａはＩ／Ｏ要求をＩＰＩパケットに包み込み、そのＩＰＩパケットをＩＯＰ１２に送信する。
ＩＯＰ１２のＩＰＩモジュール１６ａがＣＥ１４ａからのＩＰＩパケットの送信を受信すると、ＩＰＩモジュール１６ａはＩＯＰドライバ４６への割込を生成する。ＩＯＰドライバ４６は次にＩＰＩパケットを読み取る。
前記のようにＩＯＰモニタ４８は、ＣＥ１４ａからのＩＰＩパケットに対し手順１００従って応答する。やはり前記のようにハードウェアに欠陥がないものとして、ＩＯＰドライバ４６は、Ｉ／Ｏ要求に関する結果とＣＥｓ１４に対する日時を含んだＩＰＩパケットを送信することになる。
ＣＥｓ１４のＩＰＩモジュール１８はＩＯＰ１２からＩＰＩパケットを受信する。ＣＥドライバ４４はＩＰＩパケットを開いてＣＥｓ１４の日時を更新し、ＣＥｓ１４上で作動するアプリケーション又はＯＳにＣＥｓ１４に関する制御を返却する。
所定時間内にＩ／Ｏ要求が発せられない場合、ＣＥ１４のＩＰＩモジュール１８は、ＣＥ１４のＣＥドライバ４４を呼び起こすいわゆる量子割込を生成する。これに応じてＣＥドライバ４４は、量子割込ＩＰＩパケットを生成しＩＯＰ１２に送信する。ＩＯＰモニタ４８はその量子割込ＩＰＩパケットを、Ｉ／Ｏ要求を伴わないＩＰＩパケットとして処理する。従ってＩＯＰモニタ４８は、入ってくる量子割込ＩＰＩパケットを検出し（図３のステップ１０２）、合致する量子割込ＩＰＩパケットを他方のＣＥ１４から受信した場合（図３のステップ１０４、１０６、１０８）、現在の日時に関する要求をＩＯＰ１２のシステムＢＩＯＳに対して発する（図３のステップ１１２）。次にＩＯＰモニタ４８は現在の日時を量子応答ＩＰＩパケットに包み込み（図３のステップ１１４）、そのパケットにをＩＯＰドライバ４６はＣＥｓ１４に送る（図３のステップ１１６）。ＣＥドライバ４４は日時を更新することと、ＣＥｓ１４上で作動するアプリケーション又はＯＳにＣＥｓ１４に関する制御を返却することで、量子応答ＩＰＩパケットに応答する。
ＩＯＰモニタ４８が所定タイムアウト期間内に量子割込ＩＰＩパッケージを他のＣＥ１４から受信しない場合（図３のステップ１０６）、ＩＯＰモニタ４８は応答のないＣＥ１４を作動不能にすることで応答する。
図１に示すように、ＩＰＩモジュール１６、１８とケーブル２０は、プロセッサ２２、３２を提供するのに使われる標準インテル４８６ベースのマザーボードから、フォールト回復システムを作るのに必要なハードウェア全てを提供する。ＩＰＩモジュール１６、１８には同一のボードを使われるが、各モジュールは同じ様な機能を実行する。
図４に示すようにＩＰＩモジュール１８は、ＣＥ１４のプロセッサのシステムバス間のＩ／Ｏ要求と応答に対し又ＩＰＩモジュール１８のパラレルインタフェイス５２に対してコミュニケートする制御論理５０を有している。パラレルインタフェイス５２は次に、ＩＰＩモジュール１６のパラレルインタフェイス５２とケーブル２０を通してコミュニケートする。パラレルインタフェイス５２は１６ビットデータ出力ポート５４、１６ビットデータ入力ポート５６、制御ポート５８を有している。ケーブル２０の構成は、データ出力ポート５４がＩＰＩモジュール１６のデータ入力ポートに、データ入力ポート５６がＩＰＩモジュール１６のデータ出力ポートに、制御ポート５８がＩＰＩモジュール１６の制御ポートに接続されるようになされる。制御ポート５８は、ＩＰＩモジュール１８とＩＰＩモジュール１６の間でハンドシェーキングプロトコルを実行する。
制御論理５０はＩＰＩ−ＢＩＯＳのＲＯＭ６０にも接続される。起動時、制御論理５０はＩＰＩ−ＢＩＯＳ４２、即ちＩＰＩ−ＢＩＯＳのＲＯＭ６０の内容をプロセッサ３２のシステムバスを通しプロセッサ３２へ転送する（図２）。
ＩＰＩモジュール１８上に置かれるＱＩカウンタ６２は上述の量子割込を生成する。ＱＩカウンタ６２はプロセッサ２２、３２のシステム時計に接続される時計入力６４と、制御論理５０に接続されるゲート入力６６を有している。ゲート入力６６を使い、ＱＩカウンタ６２のカウンタ値を起動・リセットする。起動されたＱＩカウンタ６２は、プロセッサ３２のシステム時計の各サイクル毎にカウンタ値を１つずつ段階的に減らす。カウンタ値が零に達するとＱＩカウンタ６２は、ＣＥドライバ４４を上述のように起動させる量子割込を生成する（図２）。
ＣＥドライバ４４は、各Ｉ／Ｏトランザクションの開始時にＱＩカウンタ６２を止める。ＣＥドライバ４４は、ＱＩデアクチベーションアドレスとして知られている第１アドレスにＩ／Ｏ書込を要求することにより、ＱＩカウンタ６２を止める。制御論理５０はＩ／Ｏ書込要求を検出し、ゲート入力６６を通じてＱＩカウンタ６２を止める。この特殊なＩ／Ｏ書込は制御のみを目的としており、制御論理５０はＩ／Ｏ書込をパラレルインタフェイス５２へは回さない。各Ｉ／Ｏトランザクションの終了時ＣＥドライバ４４は、ＱＩアクチベーションアドレスとして知られている第２アドレスにＩ／Ｏ書込を要求することにより、ＱＩカウンタ６２をリセットし起動させる。制御論理５０はＱＩカウンタ６２をリセット・起動させることで応答する。
代替手法の場合、量子割込はデバッギング又はプロセッサ３２中で利用可能な他の特徴を使って生成される。普通利用されるプロセッサはデバッギング又は、トラップインストラクションの以後に続いて選定された数だけのインストラクションが完了した後に、プロセッサ制御を指定されたプログラムに転送することでエラーを捕まえるトラップインストラクションを有している。本手法の場合、ＣＥドライバ４４がプロセッサ３２の制御をアプリケーション又はＯＳに返却する度にＣＥドライバ４４はトラップインストラクションを発し、プロセッサ３２の制御を例えば３００個のインストラクションを完了した時点でＣＥドライバ４４に与えるよう指示する。プロセッサ３２が指示された３００個のインストラクションを完了すると、トラップインストラクションはプロセッサ３２の制御をＣＥドライバ４４に返却させる。指示された数だけのインストラクションが完了する以前にＩ／Ｏ要求がＣＥドライバ４４を起動させた場合、ＣＥドライバ４４はトラップインストラクションをキャンセルさせるインストラクションを発する。
オフライン状態にあるＣＥ１４を起動させるのにも使われる。以下に示すように、オフライン状態のＣＥ１４を起動させる前に、作動しているＣＥ１４のメモリシステム３４の内容はオフライン状態のＣＥ１４中にコピーされる。作動中のＣＥ１４に対するコピーの影響を最小に抑えるため、作動中のＣＥ１４のプロセッサ３２は処理を継続することを許され、メモリのコピーは、作動中のＣＥ１４のプロセッサ３２のシステムバスが使われていないサイクル中だけとされる。
メモリがコピーされている最中にプロセッサ３２が処理を継続できるようにするため、ＩＰＩモジュール１８は、オフライン状態のＣＥ１４へ既にコピーされたアドレスにプロセッサ３２がメモリ書込をするのを明らかにする。そうするために、制御論理５０はシステムバスを監視し、既にコピーされたアドレスにプロセッサ３２が書込をすると、そのアドレスをＦＩＦＯ６８に記憶する。メモリの転送が完了又はＦＩＦＯ６８が一杯になると、ＦＩＦＯ６８中に記憶されたメモリアドレスに関連するメモリロケーションの内容は、オフライン状態のＣＥ１４中にコピーされ、ＦＩＦＯ６８は空になる。他の手法の場合、ＦＩＦＯ６８はメモリアドレスとメモリアドレスに関連するメモリロケーションの内容との両者を記憶する、又は現に書かれているメモリアドレスが属するメモリブロックのブロックアドレスを記憶するように変更される。
ＩＰＩモジュール１８は、非ＢＩＯＳ−Ｉ／Ｏ要求も扱う。コンピュータシステムの中には、ＢＩＯＳが遅すぎてビデオ表示のようなＩ／Ｏオペレーションを有効に実行できないものがある。結果として、構造化や洗練度の進んでないＯＳ例えばＤＯＳやＵＮＩＸの場合、アプリケーションはＢＩＯＳを巧みに回避し、Ｉ／Ｏ装置に関連するアドレスに対して直接の読み取り又は書込を行うことで、非ＢＩＯＳ−Ｉ／Ｏ要求できる。こうした非ＢＩＯＳ−Ｉ／Ｏ要求は、例えばＩ／Ｏのディスク読み取り・書込に連動してなされているようなシステム割込表を変更することでは遮断できないので、同期化がＩ／Ｏインタフェイスを厳しく制御を要求するシステムでは問題である。
この問題を解決し非ＢＩＯＳ−Ｉ／Ｏ要求をも分離させＩＯＰ１２で管理させるため、ＩＰＩモジュール１８は、物理的Ｉ／Ｏ装置のハードウェアインタフェイスを真似した仮想Ｉ／Ｏ装置を有する。この仮想Ｉ／Ｏ装置は仮想ディスプレイ７０、仮想キーボード７２を有する。必要に応じ、仮想マウス、仮想シリアルポート、仮想パラレルポートのような仮想Ｉ／Ｏ装置を使うこともできる。
制御論理５０は実際、システムＩ／Ｏ装置への非ＢＩＯＳ−Ｉ／Ｏ要求に関連してアドレスに向けられる読み取り・書込オペレーションについて、システムバスを監視する。制御論理５０はこうしたオペレーションを検知すると、オペレーションを再構築するのに必要な情報を適当な仮想装置に記憶する。従って、例えば制御論理５０は表示に関連するアドレスに向けられた書込オペレーションを検知すると、オペレーションを再構築するのに必要な情報を仮想ディスプレイ７０に記憶する。ＢＩＯＳ−Ｉ／Ｏ要求又は量子割込が起こる毎にＣＥドライバ４４は、仮想Ｉ／Ｏ装置をスキャンし、仮想装置が空でない場合は仮想装置に記憶された情報をＩＰＩパケットに組立て、ＩＰＩパケットをＩＯＰ１２に送信する。ＩＯＰ１２は、上記手順１００を使ってパケットをＢＩＯＳ−Ｉ／Ｏ要求のように処理する。制御論理５０は仮想装置に向けられた読み取りを検出すると、この読み取り要求をＩＯＰ１２が処理するためのＩＰＩパケットに組立てる。ＩＯＰ１２はＩＰＩパケットを標準的なＢＩＯＳ−Ｉ／Ｏ要求のように処理する。
図５を参照すれば分かるように、各ＣＥ１４は８つの状態内のどれか１つで必ず作動している。許容可能状態の組合せは限られた数しかないので、システム１０は必ず１４個の状態の内のどれかで作動している。ＣＥの主な作動状態はＯＦＦＬＩＮＥ、ＲＴＢ（ｒｅａｄｙ  ｔｏ  ｂｏｏｔ）、ＢＯＯＴＩＮＧ、ＡＣＴＩＶＥ、ＲＴＳ（ｒｅａｄｙ  ｔｏ  ｓｙｎｃ）、ＷＡＩＴＩＮＧ、Ｍ＿ＳＹＮＣ（ｓｙｎｃｈｒｏｎｉｚｉｎｇ  ａｓ  ｍａｓｔｅｒ）、Ｓ＿ＳＹＮＣ（ｓｙｎｃｈｒｏｎｉｚｉｎｇ  ａｓ  ｓｌａｖｅ）である。ＩＯＰモニタ４８は、システム１０の状態とコンソールソフトウェア４９からのユーザーコマンドに基づきＣＥｓ１４の作動状態を変える。コンソールソフトウェア４９を通し、ユーザーはＣＥ１４をいつでもリセットできる。ユーザーがＣＥ１４をリセットするか、フォールトがＣＥ１４に起きた時は必ず、ＩＯＰモニタ４８はＣＥ１４の状態をＯＦＦＬＩＮＥに変える。
起動時のシステム１０は、両ＣＥｓ１４をＯＦＦＬＩＮＥの状態にして作動する（状態１５０）。システム１０は、ＣＥ１４ａがＣＥ１４ｂよりも先に作動状態になる場合、図５に示された上側の状態で作動し（状態１５２−１６２）、ＣＥ１４ｂが最初に作動状態になる場合、下側の状態で作動する（状態１６６−１７６）。ＣＥｓ１４同時に作動状態となる場合、先に作動状態にあるとＩＯＰモニタ４８が認識したＣＥ１４が、作動状態に入る。あるＣＥ１４が立ち上げ要求を発して準備できていることを表示すると、ＣＥ１４の状態は、自分が自動ブートにセットされていないならＲＴＢに、又はＣＥ１４が自動ブートにセットされていればＢＯＯＴＩＮＧに変化する。例えば、両ＣＥｓ１４をＯＦＦＬＩＮＥの状態にある時に、ＣＥ１４ａが立ち上げ要求を発しかつＣＥ１４ａが自動ブートにセットされていないなら、ＣＥ１４ａの状態はＲＴＢ状態に変わる（状態１５２）。従って、ＩＯＰモニタ４８は、ユーザーがコンソールソフトウェア４９を通しＣＥ１４ａを立ち上げるのを待ち構える。ユーザーがＣＥ１４ａを立ち上げると、ＣＥ１４ａの状態はＢＯＯＴＩＮＧに変化する（状態１５４）。ユーザーがＣＥ１４ａをリセットすると、ＣＥ１４ａの状態はＯＦＦＬＩＮＥに変化する（状態１５０）。
ＣＥ１４ａが立ち上げ要求を発した時に両ＣＥｓ１４がＯＦＦＬＩＮＥにあると、ＣＥ１４ａは自動立ち上げにセットされ、ＣＥ１４ａの状態はＢＯＯＴＩＮＧに変化する（状態１５４）。ＣＥ１４ａが上手く立ち上がると、ＣＥ１４ａの状態はＡＣＴＩＶＥに変わる（状態１５６）。
ＣＥ１４ａがＡＣＴＩＶＥにありＣＥ１４ｂが立ち上げ要求を発した時、又はＣＥ１４ａがＯＦＦＬＩＮＥからＡＣＴＩＶＥに移行しつつある（状態１５２−１５６）最中にＣＥ１４ｂが立ち上げ要求を発した時、ＣＥ１４ｂの状態は、ＣＥ１４ｂがａｕｔｏｓｙｎｃにセットされていればＲＴＳ（状態１５８）に、そうでなければＷＡＩＴＩＮＧ（状態１６０）に変わる。ＣＥ１４ｂの状態がＲＴＳ（状態１５８）に変化すると、ＩＯＰモニタは、ユーザーが同期化コマンドをＣＥ１４ｂに発するのを待ち構える。ユーザーが同期化コマンドを発すると、ＣＥ１４ｂの状態はＷＡＩＴＩＮＧ（状態１６０）に変わる。
ＣＥ１４ｂの状態が一度ＷＡＩＴＩＮＧ（状態１６０）なると、ＩＯＰモニタ４８はＣＥ１４ａのシステムメモリ３４ａの内容を、ＣＥ１４ｂのシステムメモリ３４ｂにコピーする。メモリ転送が一度完了するとＩＯＰモニタ４８は、ＣＥ１４ａが量子割込又はＩ／Ｏ要求ＩＰＩパケットを転送するのを待ち構える。パケットを受信時、ＩＯＰモニタ４８は、ＣＥ１４ａの状態をＭ＿ＳＹＮに、ＣＥ１４ｂの状態をＳ＿ＳＹＮ（状態１６２）に変える。この同期化には、ＩＯＰモニタ４８がＣＥ１４ａが量子割込又はＩ／Ｏ要求ＩＰＩパケットを転送するのを待ち構えている最中に生じた如何なるメモリ変更にも応答することが含まれている。同期化完了すると、両ＣＥｓ１４の状態はＡＣＴＩＶＥ（状態１６４）変化し、システム１０は完全に作動状態にあるとみなされる。
代替実施例のＩＯＰモニタ４８は、ＣＥ１４ａの状態をＭ＿ＳＹＮに、ＣＥ１４ｂの状態をＳ＿ＳＹＮ（状態１６２）に変える以前に、メモリ転送が完了するのを待たない。代わりに、ＩＯＰモニタ４８は、ＣＥ１４ａからＩＰＩパケットを受信したときにこの状態変更を行い、同期化プロセスの一部としてメモリ転送を実施する。
ＣＥ１４ｂが立ち上げ要求を発する最初のＣＥ１４となる場合、同様の状態移動が起こる。従ってＣＥ１４ｂが自動立ち上げにセットされてないとすると、ＣＥ１４ｂはＯＦＦＬＩＮＥ（状態１５０）からＲＴＣ（状態１６６）へ、次いでＢＯＯＴＩＮＧ（状態１６８）へ、次いでＡＣＴＩＶＥ（状態１７０）へ移行する。同様に、ＣＥ１４ｂが一度ＡＣＴＩＶＥになり、ＣＥ１４ａがａｕｔｏｓｙｎｃにセットされてないとすると、ＣＥ１４ａはＯＦＦＬＩＮＥ（状態１７０）からＲＴＳ（状態１７２）へ、次いでＷＡＩＴＩＮＧ（状態１７４）へ、次いでＳ＿ＳＹＮＣ（状態１７６）へ次いでＡＣＴＩＶＥ（状態１６４）へ移行する。
本発明の他の実施例例えば図６を見ると分かるように、フォールト回復システムは、２つのＩＯＰ２０２と、２つのＣＥｓ２０４を有する。各ＣＥ２０４はＩＰＩカード２０６とケーブル２０８を経由し、各ＩＯＰ２０２のＩＰＩカード２１０に接続される。ＩＯＰｓ２０２はＩＰＩカード２１０とケーブル２１２を経由し互いに冗長系として接続される。システム２００の各コンポーネントは冗長なバックアップコンポーネントであるので、システム２００完全になフォールト回復の状態にある。代替的な手法ではケーブル２０８、２１０は、一対のＬＡＮに置き換えることができ、ＬＡＮには各ＩＯＰ２０２とＣＥ２０４が接続されるる。実際ＬＡＮはいつでもケーブル接続に置き換えることができる。
システム２００はＯＳであり、アプリケーションソフトウェアサービス割込をすることなくどのハードウェアでもアップグレードないし修繕することができる。従って、各ハードウェアを順番に置換し、置換する度にシステム２００を同期化することにより、システム２００のハードウェア全体をサービス割込な置き換えることができる。同様にシステム２００上のソフトウェアを最小限のサービス割込（即ち、ソフトウェアをアップグレードする最中、アプリケーションは許容可能な期間、例えば２秒間、利用できなくなる。）でアップグレードできる。更にアベイラビリティを目的とする災害許容性を、各ＩＯＰ／ＣＥのペアを別の位置に置きコミュニケーションリンクを経由して当該ペアを接続することにより、得ることができる。
図７の分散型高性能のフォールト回復システム２２０は２つのシステム２００を有しており、各システムのＩＯＰｓ２０２はケーブル２２２経由でを相互に接続される。システム２２０は分散型の計算環境ソフトウェアを使い、アプリケーションの独立した部分を各システム２００上で作動させることで、高性能を達成する。システム２２０はフォールト許容であり、サービス割込なしにハードウェア・ソフトウェアの両方のソフトウェアを実行する能力を有している。
図８のフォールト回復システム２３０は３つのＩＯＰｓ（２３２、２３４、２３６）と３つのＣＥｓ（２３８、２４０、２４２）を有する。ＩＰＩモジュール２４４とケーブル２４６経由で、各ＩＯＰは他のＩＯＰのＩＰＩモジュール２４４に接続される。各ＣＥは、ＩＰＩモジュール２４８とケーブル２５０経由で２つのＩＯＰｓのＩＰＩモジュール２４４に接続され、ＣＥ２３８はＩＯＰｓ２３２、２３４に、ＣＥ２４０はＩＯＰｓ２３２、２３６に、ＣＥ２４２はＩＯＰｓ２３４、２３６に接続される。システム２００と同様にシステム２３０は、サービス割込なしにハードウェアのアップグレードを、最小限のサービス割込でソフトウェアのアップグレードを可能にする。
図７、８から分かるように、システム２００、２３０のＣＥ、ＩＯＰｓは同一の構成である。結果的にフォールト回復システム２００をフォールト回復システム２３０にアップグレードするのに、既存のハードウェアを交換することは一切必要でなく、ＣＥ／ＩＯＰペアの追加、ケーブルの接続、システムソフトウェアの適切な変更という単純な手続きのみが伴うだけである。このモジュラリティは本発明の対モジュラー冗長構造の重要な特徴である。
システム２３０のコンポーネントは３重の冗長系であるので、システム２３０はハードウェアフォールトの原因を特定する能力がシステム２００より高い。従ってシステム１０がエラーが検出されると両ＣＥｓの一方又は両方を単純に作動不能にする一方で、システム２３０はより高度なフォールト診断を提供する。
フォールト診断の一手法として図９に示すように、システム２３０の各ＩＯＰ（２３２、２３４、２３６）は手順３００に基づきフォールト診断を実行する（ステップ３０２）。まず各ＩＯＰ（２３２、２３４、２３６）は、パワーセンシング、ケーブルセンシング、プロトコルタイムアウトというようなよく知られているテクニックを使って、電源落ち、ケーブル破損、ＣＥｓ又はＩＯＰｓの機能不作動のような主たるフォールトの有無を調べる。こうしたフォールトが発見されると、各ＩＯＰはフォールトを抱える装置を、必要ならばシステム全体を作動不能にする。
主なフォールトのチェックが済むと、各ＩＯＰはＩＯＰが接続されている２つのＣＥｓからのＩＰＩパケット（量子割込又はＩ／Ｏ要求）を受信するのを待ち構える（ステップ３０４）。従って例えば、ＩＯＰ２３２はＣＥ２３８、２４０からのＩＰＩパケットの受信を待つことになる。ＣＥｓに接続されている両者からのＩＰＩパケットを受信後、各ＩＯＰはＩＰＩパケットのチェックサム（“ＣＲＣｓ”）を他の２つのＩＯＰｓに送信し、他の２つのＩＯＰｓからのＣＲＣｓを受信するのを待ち構える（ステップ３０６）。
他の２つのＩＯＰｓからのＣＲＣｓを受信した各ＩＯＰは、各列がＣＥに各行がＩＯＰに対応する３ｘ３のマトリックスを生成することができ、各要素は列をＣＥ、行をＩＯＰとして受信したＣＲＣ値となる（ステップ３０６）。従って例えば、ＩＯＰ２３２は下記のマトリックスを生成する。
0004544651.tif 000002
マトリックスを生成したＩＯＰ２３２は、マトリックスの行の値の合計値、列の値の合計値を計算する。行の合計値が３つ共等しく、列の合計値が３つ共等しければ（ステップ３０８）、誤りがないことになりＩＯＰ２３２は再度主たるフォールトの有無をチェックする（ステップ３０２）。
行の合計値が３つ、列の合計値が３つのいずれかに等しくないものがあれば（ステップ３１０）、次にＩＯＰ２３２はマトリックスの各列のＣＲＣ記入値を比較する。各列のＣＲＣ記入値が一致していれば（ステップ３１２）、次にＩＯＰ２３２はＣＥが故障したと診断し、合計値が他の列の合計値に一致しない列に対応するＣＥを作動不能にする（ステップ３１４）。
マトリックスの少なくとも一つの列の記入値が一致しない場合（ステップ３１２）、次にＩＯＰ２３２はどれだけの数の列が不一致の記入値を有しているかを決定する。不一致の記入値を有する列がマトリックスに一つしかない場合、次にＩＯＰ２３２は、他のマトリックス行合計値に等しくないマトリックス行合計値に対応するＩＯＰと不一致の記入値を有する列に対応するＣＥとの間のパスが故障したと診断し、そのパスを作動不能にする（ステップ３１６）。診断上の目的から、パスはＩＯＰ中にＩＰＩモジュール２４４を、ＣＥ中にＩＰＩモジュール２４８を、そしてケーブル２５０を有している。
マトリックスに２つ以上の列で不一致の記入値があれば（ステップ３１４）、次にＩＯＰ２３２は、一つのマトリックス列合計値が他のマトリックス列合計値と等しくないと診断し、ＩＯＰ故障と診断し、他のマトリックス行合計値に等しくないマトリックス行合計値に対応するＩＯＰを作動不能にする（ステップ３１８）。
或るＣＥ故障、パス故障、ＩＯＰ故障が診断されて明らかになった後、ＩＯＰ２３２がシステム３００は依然としてフォールトでない作動可能状態に留まるに十分なハードウェアを有していると決定した場合、ＩＯＰ２３２は再度主たるフォールトの有無をチェックする（ステップ３０２）。システム２３０は３重の冗長系となっているので、システム２３０は幾つかのコンポーネントが故障した後でも作動継続可能である。例えばアベイラビリティモードで作動状態に留まるには、システム２３０が必要とするのは１つの機能するＣＥ、１つの機能するＩＯＰ、両者間を繋ぐ１つの機能するパスだけである。
手順３００を使えば各ＩＯＰ（２３２、２３４、２３６）は、完全に作動するシステム２３０、又は１つのエレメント（１つのＣＥ、１つのＩＯＰ、１つのパス）が以前に作動不能となったシステム２３０中におけるどんな単一故障でも診断できる。あるエレメントが作動不能にされたシステム２３０の場合、各ＩＯＰは、エレメントが作動不能のために受信されないＣＲＣｓを、実際に受信されたＣＲＣｓと比較して正しいと思われる値を使うことにより、明らかにする。
手順３００はＣＥｓとＩＯＰｓ間の相互接続の特定な配置に依存することがない。適切な作動をさせるため手順３００が必要とするのは、各ＣＥの出力が少なくとも２つのＩＯＰｓで直接監視することだけである。従って手順３００をシステム中で実行させることはどんな相互接続機構を使っても可能であり、ＣＥｓとＩＯＰｓ間でポイント同志の接続を要求しない。例えばＣＥｓとＩＯＰｓを少なくとも２つのＬＡＮに接続することができる。代替手法では、マトリックスの行列のＣＲＣ値を合計する代わりに、これらの値を比べることができ、記入値が一致しない行又は列に一致／不一致の指標を付けることができる。
手順３００の簡素化したものをシステム２００で実行させることができる。この手順の場合、システム２００の各ＩＯＰ２０２は、各列がＣＥ２０４に各行がＩＯＰ２０２に対応する２ｘ２のマトリックスを生成する。
0004544651.tif 000003
マトリックスを生成した後の各ＩＯＰ２０２は、２つの記入値が一致しない各行又は各列に不一致指標を付ける。
不一致指標がない場合、システム２００は正常に作動している。
不一致指標が行にはないが両列にある場合、ＩＯＰがフォールトしたことになる。システム２００の作動モードに依存して、片方のＩＯＰ２０２が別のＩＯＰ２０２を作動不能にするか又はシステム２００を停止させる。作動不能にされるＩＯＰ２０２は、システム１０で使われた２つのアベイラビリティモードに類似のユーザー供給したパラメータに基づいて選ばれる。
不一致指標が列にはないが両行にある場合、ＣＥ２０４がフォールトしたことになる。この場合ＩＯＰ２０２は、システム２００がアベイラビリティモードで作動中ならばＣＥ２０４を作動不能にして、又はシステム２００がインテグリティモードで作動中ならばシステム２００を停止させることで応答する。不一致指標が一つの列と両行にある場合、ＩＯＰ２０２間のパスの１つと不一致列に対応するＣＥ２０４が故障したことになる。システム２００の作動モードに依存して、ＩＯＰｓ２０２は故障したパスを有するＣＥ２０４を作動不能にするか又はシステム２００を停止させる。不一致指標が両列と両行にある場合、複数のフォールトがあることになり、ＩＯＰｓ２０２はシステム２００を停止させる。
不一致指標が一つの行と両列にある場合、不一致行に対応するＩＯＰ２０２がフォールトしたことになる。システム２００の作動モードに依存して、他方のＩＯＰ２０２が間違いを起こしたＩＯＰ２０２を作動不能にするかシステム２００を停止させる。不一致指標が一つの行と一つの列にある場合、不一致行に対応するＩＯＰ２０２間のパスと、不一致列に対応するＣＥ２０４が故障したことになる。システム２００の作動モードに依存して、ＩＯＰｓ２０２は故障したパスを将来の処理で明らかにするか又はシステム２００を停止させる。
図１０に示す災害許容システム２６０は、離れた場所に置かれコミュニケーションリンク２６２、例えばイーサネット又はファイバーで、接続され互いにメタタイムロックステップで作動する２つのフォールト許容システム２３０を有している。メタタイムロックステップを得るため、全ＩＰＩパケットがフォールト許容システム２３０間で送信される。システム２２０同様、システム２６０ではハードウェア・ソフトウェアのグレードアップがサービス割込無しでできる。
本発明の対モジュラー冗長系構造では、リアルタイムで非同期に作動しＩＯＰｓで制御されるＣＥｓを使うことにより、様々なレベルのフォールト回復・フォールト許容がメタ時間で同期的に作動できるようになる。この構造は単純でコスト有効性があるので、難しさを最低限に抑えて拡張・グレードアップすることができる。
図１１は本発明の別の代替実施例のシステムソフトウェア構造のコンポーネントを示しているが、これには複数のＣＥｓと複数のＩＯＰｓが含まれている。各ＣＥ１１００は、少なくとも一つの物理的デバイスリディレクタからなるセット１１０５、ＣＥトランスポート層１１１０、ＩＰＩドライバ１１１５を有している。物理的デバイスリディレクタ１１０５は周辺装置に向けられるＩ／Ｏ要求を遮断し、包み込み、ＣＥトランスポート層１１１０に送る。物理的デバイスリディレクタ１１０５は更に、ＣＥトランスポート層１１１０からの要求に対する応答を受信し、前記応答を開き、周辺装置に最初にＩ／Ｏ要求を行ったＯＳ又はアプリケーションソフトウェアに前記応答を返却する。
図１１に示すシステムソフトウェア構造はマルチスレデッド処理環境を支援する。この環境の場合、各スレッドは計算エレメントで処理される独立したストリームのインストラクションである。物理的デバイスリディレクタ１１０５は特定のスレッドによるＩ／Ｏ要求を遮断し、物理的デバイスリディレクタ１１０５が前記Ｉ／Ｏ要求に対する応答を戻すまで、前記スレッドの処理が停止する。
ＣＥトランスポート１１１０はＣＥｓとＩＯＰｓの間のＩ／Ｏ要求とコミュニケートする。ＣＥトランスポートは、要求毎にＩＯＰｓから来ると予想され又受信される応答を追跡し続ける。ＣＥトランスポートは、向け直された要求に対するＩＯＰ応答が受信された時に完了した要求（全ＩＯＰｓが応答した要求）を探し求め、結果のデータを物理的デバイスリディレクタ１１０５に送る。
各ＩＯＰ１１５０はＩＰＩドライバ１１５５、状態制御プログラム（ＳＣＰ）１１６０、デバイス同期層（ＤＳＬ）１１８０、少なくとも１つの物理的デバイスプロバイダのセット１１８０を有する。ＣＥｓとＩＯＰｓのＩＰＩドライバ１１１５、１１５５は、ＣＥｓとＩＯＰｓの間の相互接続パス１１８５に沿ったデータの実際の送受信を制御する。状態制御プログラム（ＳＣＰ）１１６０はＣＥｓとＩＯＰｓに関する状態移動を開始し応答する。フォールトハンドラー１１６５は、検出されたフォールトに関するレポートに対し、適当なハードウェアコンポーネントをデコンフィギュレーションすることにより応答する。ＩＯＰトランスポート１１７０は、ＩＰＩドライバとＩＯＰｓの他のソフトウェアコンポーネント間のデータを輸送する。デバイス同期層（ＤＳＬ）１１７５は向け直された要求と応答全てをＩＯＰベースの周辺装置の間で同期させることに対し責任を負っている。この同期化にはＣＥｓ、ＩＯＰｓ、周辺装置に関する状態移動による要求と応答を再処理し再構築することが含まれている。物理的デバイスプロバイダのセット１１８０は、ＤＳＬ１１７５から受信した要求を開き、要求を処理し、応答を包み込み、応答をＤＳＬ１１７５に送る。更に各ＩＯＰはイーサネットドライバ１１９０又はＩＯＰｓ間の直接コミュニケーションを可能にする他の機構を有してもよい。
上述のように、記述実施例の構造はＣＥｓからＩＯＰｓへの全要求の向け直しを必要としている。この向け直された要求に対する応答を同期化させる必要がある。従って向け直された要求に対し応答するＩＯＰｓは全て、既知の方法で要求に応答し、他の全ＩＯＰｓがどのように応答しているかを記述せねばならない。更に、ＩＯＰは向け直された要求に対し、要求を処理できる装置を持っていなくとも応答する必要がある。この要件により、ＣＥｓ上で作動するソフトウェアはＩＯＰｓの応答を一貫性に関して比較することができるようになる。
図１２Ａ、１２Ｂは、ＣＥの要求（図１２Ａ）に対しＩＯＰの適切な応答（図１２Ｂ）を図示した例である。２枚ディスクシャドウセットの各ディスクは異なるＩＯＰに関係しており、ディスク１２００は普通に働く第１ディスク１２０５に、ディスク１２１０はオフライン状態の第２ＩＯＰ１２１５に関連する。ＣＥ１１００からシャドウセットへのデータ要求はＩＯＰｓに向け直され、両ＩＯＰｓが応答する。（第二ＩＯＰ１２１５は、関係するディスク１２１０がオフライン状態にあるが、シャドウセットに寄せられた全要求を受信する。）各ＩＯＰは第１のＩＯＰ１２０５が予想されるデータで応答している旨と、更に第２のＩＯＰ１２１５がデータを持ち合わせていないと応答している旨を表示する。
ＣＥトランスポート１１１０（図１１）は、ＩＯＰｓが提供する応答を監視する。全ＩＯＰｓが要求に応答を一旦済ませると、ＣＥトランスポートは応答の一貫性を比べる。応答はどのＩＯＰｓが要求に実際のデータで応答しどのＩＯＰｓが要求に応答しなかったかを示す点において一貫性がなければならない。更に複数のＩＯＰがデータで応答する場合、ＩＯＰが提供するデータに一貫性がなければならない。応答の一貫性チェックがよければ、次にＣＥトランスポートは、実際のデータを含む応答を、ＣＥ１１００中の適切な物理的デバイスリディレクタ１１０５に提供し、データを含まない応答を棄却する。その後ＣＥトランスポートは、全ＩＯＰｓが要求に応答した旨をＩＯＰｓに知らせ、比較結果もＩＯＰｓに知らせる。一貫性チェックに応答がパスしない場合、次にＩＯＰｓの内の１つが、作動不能にされ構造から事実上取り除かれる。
ＣＥトランスポート１１１０は、図１３に示された手順１３００を使い、図１１のシステムに用いられている要求−応答構造を実行する。ＣＥトランスポートはまずＩＰＩドライバ１１１５に物理的デバイスリディレクタ１１０５から全ＩＯＰｓ１１５０に要求を送るように指示する（ステップ１３０５）。同時にＣＥトランスポート１１１０はタイマを初期化する。全応答を受信する（ステップ１３１５）以前にタイマが満了していないなら（ステップ１３１０）、次にＣＥトランスポートは応答を比較し、応答が一貫しているか否かを決定する（ステップ１３２０）。応答が一貫していれば（ステップ１３２５）、次にＣＥトランスポートはデータの応答を比較する（ステップ１３３０）。データの応答が一貫している又はデータ応答が１つしかないならば、次にＣＥトランスポートはそのデータを適切な物理的デバイスリディレクタ１１０５に送る（ステップ１３３５）。最終的にＣＥトランスポートはＩＰＩドライバに応答完了メッセージを全ＩＯＰｓ１１５０に送るように指示する（ステップ１３４０）。
全応答を受信する又は一貫しない応答を受信している（ステップ１３２０、１３３０）以前にタイマが満了しているなら（ステップ１３１０）、次にＣＥトランスポートは、エラー発生を報告し（ステップ１３４５）、ＩＰＩドライバに応答完了メッセージを全ＩＯＰｓ１１５０に送るように指示する（ステップ１３４０）。
ＩＰＯｓの中では、デバイス同期層（ＤＳＬ）１１７５はＩＯＰベースの物理的装置全てを論理装置又は仮想装置に見えるようにする。更にＤＳＬは装置と全ＩＯＰｓからの情報を組み合わせて、この情報を使い単一の論理ＩＯＰをＣＥｓの物理的デバイスリディレクタにプロジェクトする。従って、図１４Ａのように構成されたシステムは図１４Ｂに示す論理形式を有するＣＥベースの物理的デバイスリディレクタに見えることになろう。
ＤＳＬ１１７５は、ＣＥベースリディレクタがロケーションの知識も物理特性も持たないような形で装置を論理的に表現する。例えばＳＣＳＩリディレクタはディスクＣ（１４００、１４０５）とディスクＤ（１４１０、１４１５）が実体のないドライブであることを知ることがないであろうし、それらのドライブを単一のドライブ（１４２０、１４２５）であるかのように扱うであろう。又、イーサネットリディレクタは、複数のイーサネットコントローラが第一コントローラ（１４３０）と第二コントローラ（１４３５）を提供していることを知らないであろうし、単一のイーサネットコントローラ（１４４０）としてのみ認識するであろう。
ＤＳＬ１１７５は、ＩＯＰトランスポート１１７０からの向け直された要求全てを受信する。次にＤＳＬは物理的デバイスプロバイダ１１８０に対する応答を送るべきか又はデータのない応答を送るべきかを決定する。ＤＳＬの重要な機能はデバイスプロバイダに要求を送ることだけであり、しかも当該デバイスプロバイダが要求の処理を期待されている時に送ることである。例えば２つのＩＯＰｓが１組のシャドウディスクを制御している、即ち第１のＩＯＰはオフライン状態のディスクを制御し、第二のＩＯＰが作動状態のディスクを制御している場合、第１のＩＯＰのＤＳＬは要求をディスクに送らず代わりにデータのない応答をするであろう。第二のＩＯＰのＤＳＬは要求をディスクに送り、結果的にディスクからのデータで応答し、第１のＩＯＰがデータのない応答をする旨の表示も併せて行うであろう。
応答毎にＤＳＬ１１７５は他のＩＯＰがどのように応答するかを表示する。これを達成するためＤＳＬは、他のＩＯＰと関連する装置の状態の記録を、内部の装置状態表中に維持する。
ＤＳＬ１１７５は、ＣＥｓ、ＩＯＰｓ、又は周辺装置の状態変化の影響を明らかにする。例えばＤＳＬは、他のＩＯＰが要求に対してどのように応答するかをあるＩＯＰが表示した後でしかも他のＩＯＰが要求に対して実際に応答する以前に、ある周辺装置の状態が変化した時に生ずる状況を明らかにする。状態が変化した後に他のＩＯＰ応答したとすれば、その応答は、最初のＩＯＰで予想される応答とは異なることがあり得よう。ＤＳＬは、影響を受ける装置からの全応答送信を作動不能にし、特定の装置に関して以前に受信した未完了の応答を棄却するフラッシュシークエンスを開始することで、この問題を解決する。（先述のようにＣＥトランスポートは、要求に対する応答が全ＩＯＰｓから受信されるまで要求が完了したとは見なさない）。
ＣＥトランスポート１１１０からフラッシュ完了表示を受信すると、各ＩＯＰ１１５０のＤＳＬ１１７５は、内部の装置状態表を更新し特定装置の応答送信を作動可能にする。最終的にＤＳＬはフラッシュ以前にＣＥトランスポートへ提出された未完の全応答を再処理する。
上記のようにＣＥトランスポート１１１０は、各応答が完了した時点で各ＩＯｐのＤＳＬ１１７５に表示を送る。従ってＤＳＬはどの応答が完了しているかを常に知っている。これにより、ＤＳＬ未完の応答を追跡することができる。デバイス状態が変わりこれに続くフラッシュが発せられ、フラッシュ完了表示を受信したＤＳＬは、デバイス状態に関する内部知識をリセットし影響を受けた未完の要求を再発行できる。この機能が例えば、スタンバイプライマリ処理の実行に重要であるが、理由としてはＤＳＬがスタンバイ装置のために特定の要求に対してデータのない応答をしたかも知れないからである。プライマリ装置が故障し要求を処理できなかったとすると、ＤＳＬはフラッシュシークエンスを開始し要求を再発行するであろう。この時スタンバイ装置はプライマリ装置と見なされ（プライマリ装置が故障しているため）要求を受信することになろう。
ＤＳＬ１１７５の内部状態表はＩ／Ｏ装置とＩＯＰｓに影響し得る全フラッシュを追跡し続ける。状態表を使用することでＤＳＬは、複数のフラッシュを複数の装置に影響させ、複数の状態移動を一度に起こさせることができる。これにより、複数の関係ある又は無関係のコンポーネントの状態変化を一様に処理することができる。
ＤＳＬ１１７５は更に、装置を所有するＩＯＰ１１５０から装置の全状態変化が出るよう命ずる。これにより、一貫性のなさの問題をＣＥトランスポート１１１０に起こさせる危険を伴わずに、異なるＩＯＰｓのＤＳＬｓは装置の状態に関して異なる考えを同時に持てるようになる。これにより、定常的なオペレーションが達成されたか否かをマスターソフトウェアエンティティが決定している間に要求や応答待ち行列をフリーズする必要がないので、ＤＳＬを全体に分散させることができるようになる。
多くの状況の場合、物理的デバイスプロバイダ１１８０は周辺装置又はＩＯＰの状態を考える必要がなく、その理由はＤＳＬ１１７５は、デバイスプロバイダが要求を処理するよう期待されている時のみ前記デバイスプロバイダに要求を送るだけだからである。同様にＤＳＬは特定の装置に関連するＩ／Ｏポリシーを考慮することがない。例えばＤＳＬはあるディスク装置が実体のないＩ／Ｏポリシーを有しているのか単一目的のＩ／Ｏポリシーを有しているのかを考えない。しかしＤＳＬはＩ／Ｏポリシー使いどのＩＯＰｓ上のどのプロバイダが特定の要求を受信して処理するかを決定する。これによりＤＳＬは、実体のない、単一目的の、仮想の、第一の／スタンバイの、あるいはこれら全てを組み合わせたＩ／Ｏポリシーと装置タイプが必ずしも意味をなさなくとも、どんな装置でも任意に処理できるようになる。
ＤＳＬ１１７５は、装置故障、装置起動、装置の合体、マニュアル操作による作動可能／作動不能を始めとする装置の全移行状態を処理する。更にＤＳＬはユーザーに気付かれずに、ＩＯＰジョイニング、ＩＯＰ起動、ＩＯＰ除去、ＩＯＰ優雅停止等、装置の状態に関係するＩＯＰの全状態移行を処理する。ＤＳＬは更に、装置プロバイダのために満足させることのできない要求に対し自動的に応答する。ＤＳＬはプロバイダ開発者が使用できるアプリケーションプログラムインタフェイス（ＡＰＩ）セットを提供する。
ＤＳＬ１１７５は、自動要求タイムアウト支援を提供する。この点に関し、ＤＳＬはＣＥ発信の要求が指定した時間内に完了しない場合回復プロセスを開始させる。回復プロセスの間、ＤＳＬはどのＩＯＰが駄目になったかを決定しフォールトハンドラーに知らせる。
ＤＳＬ１１７５は、どんなＩ／Ｏポリシーをどんな物理的装置に適用することができる。例えばＤＳＬは、実体のない装置の代わりに単一目的装置としてのハードディスクを構成することができる。同様にＤＳＬは例えば、単一目的装置の代わりに、スタンバイ／作動の装置としてのＣＤ−ＲＯＭプレーヤー又はシリアルポートを構成できる。
上記のようにＤＳＬ１１７５は、周辺装置又はＩＯＰ１１５０中の状態変化に応じて、複数のＣＥｓ１１００から成るＣＥトランスポート１１１０中に、フラッシュシークエンスを開始することができる。フラッシュシークエンスによりＣＥトランスポートは、表示された装置又は物理的デバイスプロバイダ１１８０に関連する未処理の活動全てを、ＣＥのメッセージパイプライン中に流してしまい、流した結果として要求が完了したという知らせを提供する。
フラッシュ機構はＤＳＬが要求する要求−応答の同期化を様々なレベルで提供する。従って、全装置（又は物理的デバイスプロバイダ）に対して系全体に及ぶフラッシュを実行することもできれば、あるクラスの装置又は特定の装置に対してフラッシュを実行することもできる。
フラッシュシークエンスが完了すると、各ＩＯＰのＤＳＬは要求−応答のどのペアが処理・完了したかを精確に知ることになる。ＤＳＬはこの知識を使って、必要とされるどんな要求−応答のペアをも再発行、再実行、再送信し、複数の装置の定常状態の作動を中断させたシステム内の移行状態（刺激）から回復を可能にする。これにより、ＤＳＬは装置の定常状態の作動に影響するシステム内の変化に反応することができる。フラッシュシークエンスが一旦開始・完了すると、ＤＳＬはどの要求又は応答を完了させるために、再処理又は他の装置に向け直されねばならないかを精確に決めることができる。
各ＣＥトランスポート１１１０は未完の要求に関しデータベースを維持する。データベースはシステム中で全部の未完Ｉ／Ｏ要求のリストを有しており、各要求はＸＲＮ（トランスポート参照番号）と呼ばれる固有の識別子で識別される。フラッシュシークエンスは図１５に示す手順１５００に従って実行される。まず各ＩＯＰ１１５０のＤＳＬ１１７５は、フラッシュ要求を全ＣＥｓ１１００に送りフラッシュシークエンスを開始する（ステップ１５０５）。ＤＳＬは次に、フラッシュシークエンスに関与する装置に関する全ての要求／応答処理活動を、フラッシュシークエンスが完了するまで中断させる（ステップ１５１０）。各ＣＥはフラッシュ要求を受信し、システムの各ＩＯＰからの一致するフラッシュ要求を待ち構える（ステップ１５１５）。ＣＥはフラッシュ要求をデータベースに記入し、ＯＳの要求を追跡するのと同じ方法でフラッシュ要求を追跡する。フラッシュ要求が全ＩＯＰから受信されると、ＣＥはフラッシュシークエンスの最初の部分が完了したことを表示する。フラッシュシークエンスのこの部分が完了したことは、ＩＯＰ−ｔｏ−ＣＥのメッセージパイプライン中の全活動がＣＥｓによってフラッシュアウトされ処理済みであることを意味する。
フラッシュシークエンスの完了を認識するに先だって、まずＣＥはどの未完の要求が完了したかについての認識をＩＯＰｓに送る（ステップ１５２０）。ケースによっては、Ｉ／Ｏ要求をＩＯＰ−ｔｏ−ＣＥのパイプラインを通じて応答をフラッシュさせて完了させてもよい。ＣＥ完了した要求毎にＳＷＴＡＣＫ（ソフトウェアトランザクションアクノレッジメント）を送り、完了済み要求をデータベースから取り除く。各ＳＷＴＡＣＫには要求の元のＸＲＮが含まれている。ＸＲＮにより、ＩＯＰｓはＳＷＴＡＣＫを適当な完了要求と関連付けることができる。
完了した各要求にＳＷＴＡＣＫを送った後、ＣＥはフラッシュシークエンスに関するＳＷＴＡＣＫを送る（ステップ１５３０）。メッセージはＣＥ−ｔｏ−ＩＯＰメッセージパイプラインを通じて順番に送られる（又は送信シークエンスを反映するよう記録される）。従って、フラッシュＳＷＴＡＣＫは要求完了の知らせのＳＷＴＡＣＫをＣＥ−ｔｏ−ＩＯＰメッセージパイプラインを通してフラッシュする役目を果たす。従ってＤＳＬがフラッシュシークエンスに関するＳＷＴＡＣＫを受信した時（ステップ１５３５）、ＤＳＬはメッセージパイプラインに元来存在していた要求に関する全ＳＷＴＡＣＫを既に受信・処理済みである（ステップ１５２５）。フラッシュシークエンスのＳＷＴＡＣＫを受信すると、ＤＳＬはシステム中の要求／応答処理活動全ての状態を知ることになる。ＤＳＬはこの情報に対しシステムの状態を更新することで応答する（ステップ１５４０）。その後、ＤＳＬは影響を受けた装置の要求／応答処理活動を再開し、影響を受けた未完の全要求に対して応答する（ステップ１５５０）。これは新たな状態に対し装置を再同期させ、フラッシュシークエンスに関与する装置に定常的な作動状態を達成させる。
各フラッシュシークエンスには固有のＸＲＮの目印が付いているので、複数のフラッシュを同時に進行させることができる。ＣＥトランスポートとＤＳＬ中のフラッシュ処理ソフトウェアは、未処理のフラッシュシークエンスがどのように処理されるか、それらがどんな順番で認識されるかに関して、ある種ルールに従う。これによりＤＳＬは、システム内で起こるかも知れない以後又は二次的な移行状態を原因とした、先に出されるフラッシュシークエンスを回避又は無効にすることができる。
システムソフトウェアはフリーズプロトコルを実行し、ＩＯＰ−ｔｏ−ＣＥのコミュニケーションがＣＥｓのメタ時間同期化に影響しないよう保証する。先に述べたようにＩＯＰｓは、Ｉ／Ｏ装置中に元来備わっている非同時性のため、ＣＥｓや他のＩＯＰｓとは非同期的に作動する。このためＣＥｓとＩＯＰｓ間のコミュニケーションは、ＣＥｓのメタ時間同期化に混乱させないように、行われねばならない。ＣＥ−ｔｏ−ＩＯＰのコミュニケーションはＣＥのインストラクションストリームに同期しており、十分なバッファリングが提供される限りＣＥのロックステップには影響しない。しかし、ＩＯＰ−ｔｏ−ＣＥのコミュニケーションは性質上、各ＣＥのインストラクションストリームに非同期である。従ってＩＯＰ−ｔｏ−ＣＥのコミュニケーションは不適切に処理されると、各ＣＥに異なる影響を与えてＣＥのインストラクションストリームが発散してしまう。フリーズプロトコルはＩＯＰから来る非同期データの処理を、全てのＣＥｓがデータを同期的に処理できるようになるまで、遅らせる役目を果たす。特にフリーズプロトコルは、全ＣＥトランスポート１１１０が手順１３００を実行する準備を整えるまで、手順１３００の実行を遅らせる役目を果たす。
フリーズプロトコルは４つの主な特徴を有する。即ち、非同期ＩＯＰｓから緩く同期化されたＣＥｓを越えて来た入力データストリームを同期処理すること、ＣＥｓに対する同期時間の更新、ある延長された時間の間全ＣＥｓをキャプティブ状態に同期させて保持するディープフリーズ機構、ＣＥｓとＩＯＰｓ間のコミュニケーションパスに関するフォールト検出／診断である。
フリーズプロトコルはいわゆるフリーズサイクルを使ってＣＥの同期化を提供する。ＣＥのＣＥトランスポート１１１０は、物理的デバイスリディレクタ１１０５がトランスポート１１１０をリダイレクトＩ／Ｏ作動を提供するよう起動する度にフリーズサイクルを開始する。しかしフリーズサイクル実行に際し過剰な帯域使用を防ぐため、ある数のＩ／Ｏ要求が起こる度毎又はある数のインストラクションがＩ／Ｏ要求なしで処理される度毎に、ソフトウェアの実行させてフリーズサイクルを開始するようにしてもよい。例えばＣＥトランスポート１１１０は、５つ目のＩ／Ｏ要求毎又は１万個のインストラクション毎にフリーズサイクルを実行してもよい。
ＣＥトランスポート１１１０は、優先度の高いフリーズ要求メッセージを作動中の全ＩＯＰｓに送信し作動中の全ＩＯＰｓからのフリーズ応答メッセージを待ち構えることで、フリーズサイクルを開始する。ＣＥｓ全てが同じインストラクションストリームを処理しているので、作動中の各ＣＥのＣＥトランスポート１１１０はフリーズ要求メッセージを作動中の全ＩＯＰｓに送信する。各ＩＯＰはＣＥｓからフリーズ要求メッセージを受信する。あるＩＯＰが作動中の全ＩＯＰｓからフリーズ要求メッセージを受信し終えると、このＩＯＰは、ＣＥｓがインストラクションストリーム中の同一点（即ち、同期化されている）にあること、又ＣＥｓは手順１３００を使って受信データを処理してよいことを表示する。従ってＩＯＰはフリーズ応答メッセージを作動中の全ＩＯＰｓに送ることで応答する。
ＣＥはＩＯＰｓからのフリーズ応答メッセージを受信し、ＩＰＩドライバ１１１５の正常優先メッセージ待ち行列中に置きＣＥトランスポート１１１０に対して相互ＣＥ同期ポイントを提供する。最終的に、作動中の全ＩＯＰｓからフリーズ応答メッセージを受信した後、ＣＥｓはフリーズリリースメッセージをＩＯＰＳに送信することにより、フリーズサイクルを終結する。
ＣＥトランスポート１１１０はフリーズサイクルをＩＰＩドライバ１１１５を通して呼び起こす。ＩＰＩドライバはフリーズサイクルを開始（即ち、フリーズ要求メッセージを送る）し、制御をＣＥトランスポート１１１０に返却することで応答する。これによりＣＥトランスポート１１１０は、ＩＰＩドライバにフリーズプロトコルメッセージを扱わせながら処理を継続できる。ＣＥトランスポートは、例えば正常優先メッセージの送信、ＣＥ１１００の受信待ち行列からのメッセージの抜き取りと処理等役立つ仕事で可能なものを全て実行する。ＣＥトランスポート１１１０は、作動中の各ＩＯＰに対応する正常優先メッセージ待ち行列中のフリーズ応答メッセージに遭遇するまで、制御をＯＳに返却しない。
ＩＰＩドライバ１１１５はフリーズサイクルをできるだけ速く完了させようとする。この目的のためＩＰＩドライバは、優先メッセージを作り作動中の全ＩＯＰｓ１１５０に送る。メッセージはＩＯＰｓに対するデータを伴っておらず、フリーズサイクルが始まった旨の表示をする役目のみを果す。優先メッセージを送った後ＩＰＩドライバはフリーズ応答タイムアウトカウンタをスタートさせ応答し損なったＩＯＰを検出する。通常このカウンタの長さは最悪ケースでのメッセージ送信時間の２倍程度である。これにより、ＩＯＰのフリーズ応答メッセージ送信以前に各ＩＯＰがフリーズ要求メッセージを受信した時に送信した可能性のある正常優先メッセージの送信を完了させるのに十分な時間が各ＩＯＰに提供されることになる。通常正常優先メッセージは例えば６４キロバイトというサイズ限界を有し、最悪ケースでのメッセージ送信時間が正当な値となることを保証している。
各ＩＯＰのＩＰＩドライバ１１５５はフリーズ応答メッセージ中に時間スタンプ更新を置く。この時間スタンプはＩＯＰにより最新のフリーズ応答メッセージが送信されてからの時計時間に対応する。従ってＣＥ１１００は異なるＩＯＰｓから異なる時間スタンプ更新を受信する可能性がある。従ってＣＥｓは１つのＩＯＰ１１５０をメタ時間サーバとして指定し、ＣＥｓ全てがローカル時間時計を同じに更新するよう保証する。
フリーズ要求メッセージを作動中の全ＩＯＰｓから受信後、ＩＯＰ１１５０のＩＰＩドライバ１１５５はフリーズ応答メッセージをマイクロコード化優先メッセージとして送る。メッセージを送る際、ＩＯＰはフリーズリリースタイムアウトカウンタをスタートさせ、フリーズ応答に対して応答し損なったＩＯＰを検出する。
各ＣＥのＩＰＩドライバ１１５５は、入ってくるフリーズ応答メッセージを満たすよう割込がなされ、前記メッセージを正常優先メッセージにフォーマットし直して正常優先メッセージ待ち行列の最後尾に置くことで対応する。メッセージ待ち行列中に置くことで、ＣＥトランスポート１１１０はＯＳに制御を返却できるようになり、フリーズサイクルの時間クリティカルな部分が完了する。
ＣＥのＩＰＩドライバ１１５５が作動中の最新ＩＯＰからフリーズ応答を一旦受信して処理を済ませると、ＩＰＩドライバ１１５５はフリーズリリースメッセージを作動中のＩＯＰｓにブロードカストする。これでＣＥ１１００のフリーズサイクルが完了する。ＩＯＰ１１５０はリリースメッセージを受信し、作動中の全ＣＥ１１００からリリースメッセージを受信するとフリーズリリースタイマーをキャンセルする。
上記のようにフリーズ応答パケットに時間増分を加えることで、時間更新をＯＳに提供する。ＩＯＰのＩＰＩドライバ１１５５は内部の１００マイクロ秒タイマー割込を使って時間増分を維持する。１つのＩＯＰｓのみが時間プロバイダに指定され、このＩＯＰからの時間増分を全ＣＥｓが使う。ＩＯＰのＩＰＩドライバ１１５５は、最後のフリーズ応答パケットが送信されてからの微少時間を時間増分として送信する。全ての受信待ち行列に対してフリーズ応答パケットが処理されて後、ＣＥトランスポート１１１０はこの値を使いＯＳの時計時間を更新する。
ディープフリーズプロトコルは正常フリーズプロトコルのバリエーションであり、ＣＥｓとＩＯＰｓ間の正常な活動を中断する役割を果たし、主要なシステム状態移行が起こるのを可能にする。ディープフリーズ状態はＩＯＰソフトウェアによって呼び起こされるが、このソフトウェアはＩＯＰトランスポート１１７０を使いＩＯＰのＩＰＩドライバ１１５５が次のフリーズ応答メッセージをディープフリーズメッセージで置き換えるよう命令する。ディープフリーズ応答メッセージのフォーマットは正常フリーズ応答メッセージの場合と、２つのタイプのメッセージ指定するのに異なるオプコードを使う点を除き同じである。ディープフリーズ応答は、正常フリーズ応答同様にメタ時間更新を伴っている。ディープフリーズ応答では更に、最初に開始するＩＯＰがタイムアウトカウンタを開始させることなく送信機を作動不能にする。
ＩＯＰのＩＰＩドライバ１１５５はディープフリーズ応答を作動中の全ＣＥｓに送り、ディープフリーズ状態が要求されている旨を知らせる。ＣＥｓはディープフリーズ応答を正常優先応答メッセージに変換し、メッセージを正常優先メッセージ待ち行列加え、メッセージが正常フリーズ応答の代わりにディープフリーズ応答である旨の表示をすることで応答する。ＣＥｓは他のＩＯＰｓからの正常フリーズ応答メッセージを正常なやり方で処理し続ける。
正常フリーズ応答又はディープフリーズ応答を作動中のＩＯｐｓ全てから受信後、ＣＥのＩＰＩドライバー１１１５はディープフリーズ要求メッセージを未だディープフリーズ状態にないＩＯＰｓに送り、フリーズ応答タイマーを再始動させる。
ディープフリーズ要求を受信は、現在のフリーズサイクルにディープフリーズサイクルを別のＩＯＰが注入したことをＩＯＰｓに知らせることを意味する。（正常な場合、ＩＯＰのＩＰＩｓはフリーズリリースメッセージを受信する筈であった。）各ＩＯＰはフリーズリリースタイムアウトカウンタをキャンセルし、ＩＯＰのトランスミッタパスを切り、以前のフリーズ応答からのメタ時間更新を有するディープフリーズ応答メッセージを作動中の全ＣＥｓに送り、フリーズリリースタイムアウトカウンタを再始動させることで、フリーズ要求に対して応答する。
ＣＥｓのＩＰＩドライバー１１１５はディープフリーズ応答を受信し、応答を適当な受信待ち行列中に挿入する。作動中の各ＩＯＰからディープフリーズ応答を受信すると、ＣＥトランスポート１１１０は応答タイマーをキャンセルし正常フリーズリリースメッセージをＩＯＰｓに対し発行する。
ＣＥトランスポート１１１０は、その間、様々な受信待ち行列中で正常フリーズ応答メッセージとディープフリーズ応答メッセージが組み合わされたものに遭遇している。単一のディープフリーズ応答を検出すると、ＣＥトランスポートに正常フリーズ応答を越えてディープフリーズ応答を処理させる。従ってＣＥのＩＰＩドライバー１１１５はフリーズ応答とディープフリーズ応答が受信待ち行列中に適切な順番で入ることを保証せねばならない。
システムがディープフリーズ状態にある場合、優先メッセージのみがコンポーネント間で交換できる。更にシステムがディープフリーズ状態にある場合、ＣＥトランスポートが新たなフリーズサイクルを開始することはないであろう。
ディープフリーズサイクルを要求する大きな状態移行が一旦完了すると、ディープフリーズ状態はディープフリーズ終結要求の発行を伴うディープフリーズ終結サイクルを開始することで終わりとなる。ディープフリーズ終結サイクルは通常、ディープフリーズサイクルを呼び起こしたＩＯＰトランスポート１１７０によって引き起こされるが、どんなＩＯＰトランスポート１１７０でも同じ結果を伴うディープフリーズ終結サイクルを呼び起こせる。
ディープフリーズ終結要求サイクルはＩＰＩドライバ１１５５に対するレジスタレベルの要求であり、作動中の全ＣＥｓへのディープフリーズ終結優先メッセージをドライバーにブロードカストさせる。各ＣＥのＩＰＩドライバ１１５５はこのメッセージを受信し作動中の全ＩＯＰｓに伝える。ディープフリーズ終結メッセージを受信したＩＯＰｓは送信パスを起動させディープフリーズ状態を抜け出す。
フリーズ応答タイマーとフリーズリリースタイマーはフリーズプロトコル中にエラーの発生を説明する。ＣＥのフリーズ応答タイマーが満了すると、ＣＥのフリーズ状態仮想レジスタを含んだ高度優先システムエラー（ＳＹＳＥＲＲ）パケットを生成し、作動中の全ＩＯＰｓに送る。ＩＯＰｓは自分自身の関係した状態情報をＳＹＳＥＲＲパケットに対して補足し、そのＳＹＳＥＲＲをフォールトハンドラ１１６５に送る。
ＩＯＰのフリーズリリースタイマーが満了するとＩＯＰは、探知用ＩＯＰからの状態情報だけを含んだローカルＳＹＳＥＲＲパケットを生成し、このＳＹＳＥＲＲパケットをフォールトハンドラ１１６５に送る。探知用ＩＯＰは次に同様のＳＹＳＥＲＲパケットを作動中の全ＣＥｓに送る。ＣＥｓは自分自身の状態情報をＳＹＳＥＲＲパケットに対して補足し、作動中の全ＩＯＰｓに送る。ＩＯＰｓは追加状態情報をＳＹＳＥＲＲ中に記憶し、メッセージをフォールトハンドラ１１６５に送る。
ＳＹＳＥＲＲパケットを生成後、ＣＥ１１１０又はＩＯＰ１１５０のＩＰＩドライバ１１１５、１１５５は、ＩＯＰ１１５０上に常駐するフォールトハンドラ１１６５がエラー条件を解き明かすのを待機する。フォールトハンドラはどのパスがフォールト状態にあるかを決定し、フォールトパスを作動不能にするようＩＯＰのＩＰＩドライバ１１５５に命令する。フォールトパスを作動不能にした後ＩＯＰのＩＰＩドライバは、フリーズプロトコルの状態を評価し、処理要件が満足されると正常な処理を再開する。
ＩＯＰｓは、作動中の全ＣＥｓからのフリーズ要求の受信に対しタイムアウトを適用しない。１つ又は複数のＣＥｓがフリーズ要求メッセージを送り損ねるか又はフリーズ要求メッセージが何かの理由で受信されない場合、他のＣＥｓが結果的にフリーズ応答タイムアウトＳＹＳＥＲＲパケットを生成する。
ディープフリーズ拡張を始めとするフリーズプロトコルを提供するのに必要なＣＥのＩＰＩドライバ１１１５の状態移行を図１６Ａに示す。ディープフリーズ拡張を始めとするフリーズプロトコルを提供するのに必要なＩＯＰのＩＰＩドライバ１１５５の状態移行を図１６Ｂに示す。
システムは、フォールトの知らせと報告環境に基づいたメッセージをフォールトハンドラ１１６５を使って実行する。エラー処理の点からすればシステムは、エラー報告エレメントとエラー処理エレメントを持つと見なし得る。エラー報告エレメントはシステム中のコンポネントで、エラー条件を検出するか又は状態の条件を決定し、その情報をエラー処理エレメントに送信するもの全てがこれに当たる。エラー処理エレメント又はフォールトハンドラはエラー報告エレメントからエラー情報を受信する。
単一のフォールトから生ずるエラーメッセージを集積したものをフォールトイベントと呼ぶ。フォールトハンドラはフォールトイベントに関連したエラーメッセージを使い、故障しフォールトイベントを生じさせた特定のシステムコンポーネントを特定する。特定されたコンポーネントをコールアウトと呼ぶ。フォールトハンドラはフォールトを解明し、たとえグレードが落ちたにせよ正常なシステム作動を回復させる行動を取るか又は開始してもよい。
エラー報告エレメントはハードウェア又はソフトウェアのいずれの構成要素でもよい。唯一の要件は、エラー情報をエラー処理エレメントに送信する又はそうした情報が送信せしめることが可能なことである。
システムエラーを検出するエラー報告エレメントは、ＳＹＳＥＲＲと呼ばれる均一にフォーマット化されたパケット中にシステムエラーを包み込む。エラー報告エレメント次に、エラー報告エレメントと接続されている全エラー処理エレメントにＳＹＳＥＲＲを送る（送られるようにせしめる）。物理的システムの構造は、エラー条件によって少なくとも１つのエラーパケットを生成されるようにの構成される。物理的システムは更に、理想を言えば、各エラー報告エレメントが全エラー処理エレメントに接続されるように構成される。これは、診断情報として使われると期待されていたエラー表示が欠けることを許すことになる。
単一のＳＹＳＥＲＲパケットは多くの事例において、フォールトイベントのソースを曖昧でない形で特定しなくてもよい。こうした状況が生じた場合、フォールトハンドラーは複数のソースから提供される診断情報に頼ってフォールトのソースを曖昧でない形で特定する。
エラー報告エレメントとフォールトハンドラーの間の接続するため、トランスコンポーネントの中には、あるエラー報告エレメントが生成したＳＹＳＥＲＲｓをシステム中の前記トランスコンポーネントに直接接続された他のフォールトハンドラーにエコーさせることのできるものがある。従ってトランスコンポーネントに直接接続されてないフォールトハンドラーでもエラー情報を前記エレメントから得ることができる。例えば図１７に示すようにＩＯＰ１７０５上のフォールトハンドラー１７００は、ＩＯＰ１７１０が生成したＳＹＳＥＲＲパケットを直接受信することができない。これを説明すると、ＣＥ１７２０上のＩＰＩアダプタ１７１５はＳＹＳＥＲＲリフレクタとして働き、ＩＯＰ１７１０が生成したＳＹＳＥＲＲをＩＯＰ１７００にエコーさせるということになる。
フォールトハンドラー１１６５は、エラー情報を得るために他のシステムコンポーネントを詳しく調べることができる。更に、独立したフォールトハンドラーは、自分が常駐するシステムコンポーネントの実行可能性を調べ、システムコンポーネント間のコミュニケーションパスをテストし、コミュニケーションパスが損なわれていないとの仮定の下に、あるフォールトイベントに応じて各フォールトハンドラーが同じ診断を下すことを確かめるため、互いにコミュニケートしてもよい。
フォールトハンドラー１１６５は遭遇したエラーを、シンドロームとよばれる相互に関連させたエラーのセットにグループ分けする。シンドロームは一般にフォールトコンポーネント又は疑わしいコンポーネントのリストを、シンドローム中の個別エラーよりも高い特殊性を添えて表示する。
各フォールトハンドラーは状態表を使って入ってくるエラーを特定のシンドロームに構文解析する。各シンドロームは表中のある状態を代表している。可能ならばフォールトハンドラーは入ってくるエラーを使って状態表を新たな状態に移行させる。
フォールトハンドラーは図１８に示す手順１８００によりエラーを処理する。まずフォールトハンドラーは、エラーを固有に特定する正常な形式に変換し、各エラーを容認されたエラーとして表す（ステップ１８０５）。例えばフォールトハンドラーはエラーを、特定のエラーを識別するエラー識別子と、エラーが訴えを起こしているサブコンポーネントを識別するエラーターゲットと、エラーを報告したサブコンポーネントとエラーが受信されたパスを識別する報告ソースから成る三つ揃いに変換してもよい。
フォールトハンドラーは次に、容認されたエラーを処理する。フォールトハンドラーはまず既に確立されているシンドロームが表す状態に対してエラーを比較し（ステップ１８１０）、前記エラーが以前に確立されたエラーに移行するか否かを見極める（ステップ１８１５）。こうした移行が実行されうる場合、フォールトハンドラーは次に移行を実行し（ステップ１８２０）、エラーに対する状態処理を終える（ステップ１８２５）。エラーが既存のシンドロームに移行できない場合、フォールトハンドラーは初期状態に於ける新たなシンドロームを作成し（ステップ１８３０）、前記エラーが前記シンドロームをシンドロームの開始状態に移行できるか否かを決定する。移行できるのなら、フォールトハンドラーはその移行を実行し（ステップ１８２０）、エラーに対する状態処理を終える（ステップ１８２５）。前記エラーがシンドロームの開始状態に予想されない場合、フォールトハンドラーはエラーを非シンドロームエラーに変換し（ステップ１８４０）、エラーに対する状態処理を終える（ステップ１８４５）。非シンドロームエラーは、予想されない、誤報告された、送信又は受信が未完了エラーとなったがらくたである。例えば容認されたエラーが上記の三つ揃いの形式となっている場合、容認された非シンドロームエラーは“ＵＮＳＹＮＤＲＯＭＥＤ”という識別子と、ボーガスエラーの報告ソースに対応するエラーターゲットと、フォールトハンドラーを含むコンポーネントの報告ソースから成っていてもよい。
潜在的コールアウトのセットは状態表の各状態に関連している。あるシンドロームが特定の状態に移行する場合、コールアウトのセットはシンドロームのコールアウトリストと呼ばれる。
状態表は容認されたエラーをツリー構造のリストにしたものである。ツリーの各ノード上の目印は容認されたエラーの識別子である。各ノードは、他のエラーのリスト、コールアウトリスト、又は両リストへの方向を指し示している。
状態表はエラーグループ（シンドローム）から成るソースドキュメントから作成できる。シンドロームテキストは、１つのエラーがシンドローム中の別のエラーに先立って起こるべきか否かを統語的に表示する。この表示がない場合、エラーには順番がないと見なされる。コールアウトのリストは各シンドロームに関連している。
状態表はシンドロームの各エラーを並べ替え、各エラーを容認された形に変換し、シンドロームを表にマッピングすることにより作成される。各置換のターミナルノードはシンドロームのコールアウトリストを指している。例えばソース表が図１９Ａに示すコールアウトに関連するシンドロームを含み、システムのトポロジーを図１７のようになっていると仮定する。図１９Ａの「エラー」の欄はＳＹＳＥＲＲメッセージ中のフォールトハンドラーに報告された異なるエラーを特定している。特にＮＡＫエラーは送信パス上での何度もの再試行を、ＥＤＣエラーは受信パス上の低レベルのプロトコル故障を、ＮＡＫ（ｅｃｈｏｅｄ）エラーはあるコンポーネントによって送信され他のコンポーネントでエコーされたＮＡＫエラーを表示する。「パス」の欄はエラーが検出されたパスを特定しており、「受信源」の欄はＳＹＳＥＲＲを報告したマシンを特定している（Ｍ１はＩＯＰ１７０５（マシン１）、Ｍ１はＣＥ１７２０（マシン２））。最後の「コールアウト」の欄は、「エラー」の欄に挙げられたエラーを生じさせ得る可能なシステム故障を挙げている。
フォールトハンドラーで検出されたシンドローム＃１に対し図１９Ａのソース表を使うと、Ｍ１がパスＭ１−Ｍ２に関し報告したＮＡＫエラー、Ｍ２からエコーされたＭ１がパスＭ１−Ｍ２に関し報告したＮＡＫエラー、Ｍ２がパスＭ１−Ｍ２に関し報告したＥＤＣエラーが全て起こる筈である。この時に結果的に生ずるコールアウトは、シンドローム＃１の「コールアウト」欄に記入されたもの全てとなる。
上記ソースから生ずる状態移行表は図１９Ｂのようになり、容認された形のエラー指示が三重の形、ｅｒｒｏｒ（ｅｒｒｏｒ＿ｐａｔｈ，ｒｅｃｅｉｖｅｄ＿ｆｒｏｍ）となる。上記状態移行表は実際にはツリー構造となっている。ルートは「初期状態」である。初期状態から出発すると、シンドローム＃１のコールアウトに到達するには６通りがある。シンドローム＃１のコールアウトに達するには３つのエラーメッセージが必要であり、そのエラーメッセージは可能ないずれの順ででも到達できる（３の階乗＝６つの可能なオーダリング）。シンドローム＃２のコールアウトは２つのエラーメッセージを必要とし、順番を問わない（２の階乗＝２つの可能なオーダリング）。従ってＮＡＫ（Ｍ１→Ｍ２、Ｍ１ｖ．Ｍ２）とＥＤＣ（Ｍ１→Ｍ２、Ｍ２）がどの順で来ても、第３のエラーＮＡＫ（Ｍ１→Ｍ２、Ｍ１）なしでシンドローム＃２のコールアウトが生じる。この場合、ＮＡＫ（Ｍ１→Ｍ２、Ｍ１）の存在がシンドローム＃１を固有に識別する。
状態表はエラーのセットを並べることで構成されるので、非常に大きなものとなり得る。これは、表を構成するシンドロームが特に複雑な場合又はエラーを生成するシステムコンポーネント数が大きい場合に特に当てはまる。表の大きさを論理マッピングを物理的マッピングにすることで小さくしてもよい。冗長コンポーネントを有するシステム場合、一コンポーネントに対して報告されるエラーは、そのコンポーネントを含む冗長セットに対して報告されるエラーに比べれば識別しがたいくらい小さい。従って表の大きさは、論理形式のエラーとコールアウトを、冗長セットの１コンポーネントだけに対応するエラーを反映するよう識別することにより、小さくすることができる。この手法により、シンドロームが構成されたときの各シンドロームに対し、物理的識別子から論理的識別子へのマッピングが維持される。容認されたエラーをシンドローム状態のエラーに対して比べる時、エラーはシンドロームに対して論理的に容認された形に変換されねばならない。論理的形式から物理的形式へのマッピングはシンドロームにより異なる。
状態表の大きさはサブツリー折り重ねによって小さくしてもよい。ツリー構造をした状態表の下部構造の多くの部分は他の部分と同じである。同じサブツリーは、たとえ別のシンドロームから発生したにせよ、コピーされたものとして折り畳み可能である。こうした最適化を行えば、シンドロームの複雑さが増した時に表が爆発的に大きくなるのを緩和できる傾向にある。大きなシンドローム程、サブツリー折り重ねで消滅できる二重のサブツリーを生成する。
各シンドロームはシステムにおける、零、１つ、又はそれ以上の潜在的な故障コンポーネント又はコールアウトを表示している。フォールトハンドラーはこうした表示をイベントコールアウトリストの形に組合せて、単一の診断を下す。コールアウトリストは理想を言えば、故障してエラーイベントを引き起こしたシステムコンポーネント又は機能を、曖昧でない形で識別する１エレメントだけを含む。しかし、コールアウトリストは複数のエレメントを含んでいてもよい。
最終的コールアウトリストは、各シンドロームに関係する最も可能性のあるコールアウトの交点を取ることで形成される。或るシンドロームが表示する故障の幾つかは他のものよりも可能性が高い。例えば送信エラーは過渡的な二点間のエラー、送受信機の普通の欠陥、ケーブルの完全さの問題、一端に於ける初期の電源故障で生ずるかも知れない。初期の電源故障は殆どの誤った挙動を説明できよう。しかし確証的証拠がない場合、過渡的なフォールトは初期の電源故障というよりも、送信故障で説明できる可能性が高い。更にフォールトの中には、コンポーネントをあまり識別せず、その中にあるより特定のコンポーネントを識別すると想定できるものもある。例えばあるシンドロームに関するコールアウトはＩＯＰ１７０５とＣＥ１７２０間の相互接続をしていしてもよい。このコールアウトには例えば両者間のケーブル１７２５と同様、相互接続の両端のアダプタ１７１５を含んでいるであろう。別のシンドロームはＣＥ１７２０上の不特定のエラー（ＣＥ１７２０のＩＰＩアダプタ１７１５を始めとするＣＥ１７２０のハードウェアとソフトウェアの全コンポーネント）を表示してもよい。こうしたシンドロームのコールアウトリストの組合せは明らかに、ＣＥ１７２０のＩＰＩアダプタ１７１５が故障していることを表示している。
２つのコールアウトリストは、２つのコールアウトリストに共通であるが最小包括部分となるコンポーネントを選択することで組合せられる。任意の２つのコールアウトリストに関し、最初の２つのコールアウトリストでカバーされるシステムコンポーネントの交点を含む少なくとももう１つ他のコールアウトが存在する。コールアウトを組み合わせたプロダクトが、システムの最小部分をカバーするコンポーネントである。例えば、図１７のシステムのように緩やかに接続されたシステム中に、ＩＯＰ１７０５とＣＥ１７２０の相互接続に対してコールアウトがあり、ＩＯＰ１７１０とＣＥ１７２０の相互接続に対してコールアウトがあると仮定する。これらの相互接続はＣＥ１７２０中のＩＰＩアダプタ１７１５で交差する。それらはＣＥ１７２０で交差すると一般に考えられる。しかしながらアダプタは、故障した相互接続の交点として識別しうる最小包括コンポーネントであるが故に選択されたコールアウトである
コールアウトを組み合わせる上記手法は、２つの他のコールアウトの各組み合わせに対して１つのプロダクトコールアウトがあるという結果になる。従って任意の異なる２つから新たなコールアウトをフォールトハンドラーが素早く確立するために使う「マルチプリケーション表」を確立することができよう。マルチプリケーション表は図２０に示すようにコールアウト階層線図を作ることで形成される。図中の各ボックスはコールアウトを表し、２つのコールアウトのプロダクトは両者間の（階層構造中の）最下位のコールアウトとして定義される。この規則の例外は、自分自身と組み合わせたコールアウトは自分自身（即ち、全てのエントリは最下位のエントリに代わって返却される）であるという点である。従って例えば以下の通りになる。
ＣＸＵｕｘ＊ＣＸＵｖｘ＝ＲＸ（ＣＥｘ）、
ＲＸ（ＣＥｘ）＊ＴＸ（ＣＥｘ）＝ＩＰＩ（ＣＥｘ）
RX（IOPu）*Capability（IOPu）=POWER（IOPu）、and Device（IOPu）*Capability（CEx）=Tuple（IOPu）、
ｗｈｉｌｅ
ＣＸＵｕｘ＊ＣＸＵｕｘ＝ＣＸＵｕｘ
注記；以下の説明で、略号の意味は下記の通りである。
ＣＮｕｘは、マシンｕとマシンｘ間の単方向相互接続
ＣＢｕｘは、マシンｕとマシンｘ間の双方向相互接続
本方法で形成されたマルチプリケーション表は、特に多数の冗長コンポーネントを有するシステムの場合、非常に大きくなり得る。幸運なことに、このマルチプリケーション表を実際に形成することは必ずしも必要ない。むしろ表を計算する際に必要な２つのコールアウトに関し同じルールに従うことにより、マルチプリケーションは実行できる。必要なのは、コールアウト階層線図を含む方向グラフを具体的に示すことである。更にシステム中の冗長コールアウトを論理的形式で表すことにより削除してもよい。（但し、マルチプリケーションを実行時、論理コールアウトは物理コールアウトに移されてなければならない。）
フォールトハンドラーはリスト内のコールアウトを組み合わせることがない。代わりにフォールトハンドラーは、２つのコールアウトリストを「クロスマルティプライ」することにより、元のリストの固有な善組合せを含んだ第３のリストを形成する。例えば図２１Ａの両リスト１、リスト２のたすき掛けすると、図２１Ｂに示すプロダクトエレメントの結果となる。二重コールアウトを削除すると、共通マシン１／２電源供給、マシン１電源、マシン２電源、マシン１アダプタ、マシン２アダプタ、１⇔２双方向相互接続から成るプロダクトリストの結果となる。
独立ソースからのコールアウトリストを同様の方法で組み合わせることができる。例えばフォールトハンドラー１７００が図１７のシステム中の各ＩＯＰ１７０５、１７１０上に存在すると仮定する。２つのフォールトハンドラー間にコミュニケーションが存在する場合、２つのフォールトハンドラーからのコールアウトリストを、システム全体の１つのコールアウトリストに組み合わせることができる。組み合わせたこのリストの有する特殊性は、各フォールトハンドラーがリストを独立として扱った場合の特殊性に対し、等しいか又はそれ以上になる。
全てのシンドロームコールアウトリストが組合せられると、無意味なコールアウトはリストから除かれる。除去は、各コールアウトをシステムの作動に対して妥協の範囲に従って順位付けすることでなされる。最終的なコールアウトリスト（即ち、診断）を、最下位ランク（下位ランクは、より狭い範囲のコールアウトに適用するよう任意に選ばれる）のコールアウトを選択して、形成する。例えば図２２のコールアウトの順位付けの場合、図２１Ｂのコールアウトリストを単一コールアウト：マシン１⇔マシン２双方向相互接続にまで縮小できる。
順位付け手順は確率的仮定を含んでいる。他が全て等しい場合、順位が低いコールアウトは順位が高いコールアウトより、フォールトイベントの原因となり易い。上記の例では、ＩＯＰ１７００（マシン１）とＣＥ１７１０（マシン２）の間の共通電源の初期電源故障がシンドロームを起こさせた可能性があるが、確証がない（別のシンドロームの形又は既存のシンドロームを変化させる別のエラー）場合、これをコールアウトとして報告すると誤りを招くことになろう。
コールアウトはフォールトハンドラーが生成し得る最善の精度の診断を表している。一般にコールアウトは余りに特殊なのでサービス技術者は使うことができない。しかしそれらはシステムのサブコンポーネントを表すフィールド交換可能装置（ＦＲＵｓ）の形にマッピングでき、このサブコンポーネントでサービス又は交換を識別できる。例えばフォールトハンドラーは、相互接続アダプタ上の共通受信ポートを識別できてもよい。このコールアウトに対応するＦＲＵはアダプタカードとなるであろう。
要約するとフォールトハンドラー１１６５は、図２３に示す手順２３００に従って故障ＦＲＵを特定する。第１シンドロームのコールアウトリストから始まり（ステップ２３０５）、フォールトハンドラー１１６５は論理的コールアウトリストを物理的リストに移し換える（ステップ２３１０）。フォールトハンドラー１１６５は次にこの物理的リストを名称ＣＵＲＲＥＮＴで特定する（ステップ２３１５）。
処理すべきシンドロームが更にある場合（ステップ２３２０）、フォールトハンドラー１１６５は新たなコールアウトに関する論理的コールアウトリストを物理的コールアウトリストに変換し（ステップ２３２５）、このリストをＣＵＲＲＥＮＴに対してクロスマルティプライし（ステップ２３３０）、結果のプロダクトをＣＵＲＲＥＮＴとして記憶する（ステップ２３３５）。
シンドロームが一旦処理される（ステップ２３２０）と、フォールトハンドラー１１６５はＣＵＲＲＥＮＴを最も特殊なコールアウトにまとめ上げ（ステップ２３４０）、前記コールアウトをＦＲＵｓに移し（ステップ２３４５）、手順を終える（ステップ２３５０）。
他の実施例も以下の請求項の範囲内にある。
【図１】
0004544651.tif 000004
【図２】
0004544651.tif 000005
【図３】
0004544651.tif 000006
【図４】
0004544651.tif 000007
【図５】
0004544651.tif 000008
【図６】
0004544651.tif 000009
【図７】
0004544651.tif 000010
【図８】
0004544651.tif 000011
【図９】
0004544651.tif 000012
【図１０】
0004544651.tif 000013
【図１１】
0004544651.tif 000014
【図１２Ａ】
0004544651.tif 000015
【図１２Ｂ】
0004544651.tif 000016
【図１３】
0004544651.tif 000017
【図１４Ａ】
0004544651.tif 000018
【図１４Ｂ】
0004544651.tif 000019
【図１５】
0004544651.tif 000020
【図１６Ａ】
0004544651.tif 000021
【図１６Ｂ】
0004544651.tif 000022
【図１７】
0004544651.tif 000023
【図１８】
0004544651.tif 000024
【図１９Ａ】
0004544651.tif 000025
【図１９Ｂ】
0004544651.tif 000026
【図２０】
0004544651.tif 000027
【図２１Ａ】
0004544651.tif 000028
【図２１Ｂ】
0004544651.tif 000029
【図２２】
0004544651.tif 000030
【図２３】
0004544651.tif 000031