JP2001502449A - フォールト回復／フォールト許容計算 - Google Patents

Abstract

(57)【要約】 計算エレメント（１４ａ、１４ｂ）と、データソースから計算エレメントにデータを提供するコントローラ（１２）を含むコンピュータシステム（１０）において、計算エレメントへのデータ転送が同期化される。計算エレメント（１４ａ、１４ｂ）からのデータ要求は遮断されコントローラに送信される。少なくとも第一コントローラが、要求データを計算エレメントに送信し遮断された要求に第二コントローラがどう対応するかを示すことにより応答する。

Description

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フィッツジェラルド マーティン ジェイ ヴィー アメリカ合衆国 マサチューセッツ州 02053 メドウェイ ホルブルック スト リート ５ (72)発明者 レヴェイル ポール エイ アメリカ合衆国 マサチューセッツ州 01519 グラフトン ストラットン ロー ド 12 (72)発明者 マッコーラム ジェームズ ディー アメリカ合衆国 マサチューセッツ州 01588 ウィッティンスヴィル スウィフ ト ロード 275 (72)発明者 メンチ エリック アメリカ合衆国 マサチューセッツ州 01834 グローヴランド セイラム スト リート 677 (72)発明者 トランブレイ グレン エイ アメリカ合衆国 マサチューセッツ州 01568 アプトン サウス ストリート 139

Claims (1)

1. 【特許請求の範囲】 １．計算エレメントと、データソースから前記計算エレメントへデータを提供す る複数のコントローラを有するコンピュータシステム中で、前記計算エレメン トへのデータ転送を同期化する方法において、計算エレメントがなすデータ要 求を遮断する段階と、前記遮断された要求をコントローラに送信する段階と、 前記遮断された要求に前記コントローラを通して応答する段階であって、少な くとも第一コントローラが、要求されたデータを前記計算エレメントへ送信す ることと、前記遮断された要求に第二コントローラがどのように応答するかを 表示することとで応答する、そのような応答する段階とから成ることを特徴と する方法。 ２．前記第二コントローラを通じて、前記遮断された要求に対応するデータを前 記第二コントローラが持たない旨を表示することと、前記遮断された要求に対 して前記第一コントローラがデータを計算エレメントに送信することで応答す る旨を表示することにより、前記遮断された要求に応答する段階を更に含むこ とを特徴とする上記請求項１に記載の方法。 ３．前記遮断された要求に対してあるコントローラがなす各応答において、他の 各コントローラが前記遮断された要求に対しどのように応答するかに関する表 示を含ませる段階を更に含むことを特徴とする上記請求項１に記載の方法。 ４．前記遮断された要求に対する応答の一貫性を比較する段階を更に含むことを 特徴とする上記請求項１に記載の方法。 ５．前記遮断された要求に対し他の各コントローラがどのように応答するかに関 する表示を各応答に含ませる段階を更に含み、前記比較する段階が前記の表示 の一貫性を比較することを含むことを特徴とする上記請求項４に記載の方法。 ６．複数のコントローラの応答が要求データを含む場合、前記比較する段階がデ ータの一貫性を比較することを更に含むことを特徴とする上記請求項５に記載 の方法。 ７．計算エレメントが全コントローラから応答を受信した後に、計算エレメント を通して応答の一貫性を比較する段階と、比較結果と全コントローラから応答 を受信したことを計算エレメントを通して知らせる段階とを更に含むことを特 徴とする上記請求項４に記載の方法。 ８．応答が一貫してない場合、コントローラの一つを作動不能にする段階を更に 含むことを特徴とする上記請求項４に記載の方法。 ９．計算エレメントが所定時間内に全コントローラから応答を受信しない場合、 エラー条件を生成する段階を更に含むことを特徴とする上記請求項１に記載の 方法。 １０．データソースが前記第１コントローラに関連し、前記データソースから要 求データを、遮断された要求に応じ又前記第１コントローラを通して、獲得す る段階を更に含むことを特徴とする上記請求項１に記載の方法。 １１．第２コントローラの状態の記録を第１コントローラを通して維持する段階 と、第２コントローラが遮断された要求に対してどのように応答するかを表示 する時に前記記録を使う段階とを更に含むことを特徴とする上記請求項１に記 載の方法。 １２．データソースが前記第２コントローラに関連し、前記データソースの状態 の記録を第１コントローラを通して維持する段階と、第２コントローラが遮断 された要求に対してどのように応答するかを表示する時に前記記録を使う段階 とを更に含むことを特徴とする上記請求項１１に記載の方法。 １３．他の全てのコントローラの状態の記録を各コントローラを通して維持する 段階を更に含み、前記他のコントローラが遮断された要求に対してどのように 応答するかを表示する時に前記記録をコントローラに使わせることを特徴とす る上記請求項１１に記載の方法。 １４．各コントローラをデータソースに関連させる段階と、他の全てのコントロ ーラに関連したデータソースの状態の記録を各コントローラを通して維持する 段階と、前記他のコントローラが遮断された要求に対してどのように応答する かを表示する時に前記記録をコントローラに使わせる段階を更に含むことを特 徴とする上記請求項１３に記載の方法。 １５．データソースの状態が第２コントローラの変化に関連している時、遮断さ れた要求に対する他のコントローラからの応答を棄却する指示を、第２コント ローラを通して計算エレメントに送信する段階を更に含むことを特徴とする上 記請求項１２に記載の方法。 １６．遮断された要求に対する他のコントローラからの応答を棄却することと、 前記応答が棄却された旨の知らせをコントローラに送信することで、前記指示 に対して計算エレメントを通して応答する段階を更に含むことを特徴とする上 記請求項１５に記載の方法。 １７．第２コントローラに関連するデータソースの記録を更新することにより、 前記知らせに対して第１コントローラを通して応答する段階を更に含むことを 特徴とする上記請求項１６に記載の方法。 １８．前記記録を更新後、要求データを計算エレメントに第１コントローラを通 して再送信する段階と、第２コントローラが遮断された要求に対してどのよう に応答するかを第１コントローラを通して表示する段階を更に含むことを特徴 とする上記請求項１７に記載の方法。 １９．データソースが各コントローラに関係しており、各コントローラは、関連 するデータソースが要求を処理すると予想されるか否かを決定することと、前 記関連するデータソースが要求を処理すると予想される場合、関連するデータ ソースに対する要求を送信し、要求に関する結果を関連するデータソースから 受信し、要求に関する結果を計算エレメントに送ることと、前記関連するデー タソースが要求を処理すると予想されない場合、要求に対してデータが提供さ れない旨を計算エレメントに知らせることによって遮断された要求に対して応 答することを特徴とする上記請求項１に記載の方法。 ２０．計算エレメントと、データソースと、前記データソースから前記計算エレ メントへデータを提供する複数のコントローラを有するコンピュータシステム 中で、前記計算エレメントへのデータ転送を同期化する方法において、計算エ レメントがなすデータ要求を遮断する段階と、前記遮断された要求をコントロ ーラに送信する段階と、前記遮断された要求に前記各コントローラを通して応 答する段階とから成り、この応答する段階は、関連するデータソースが要求を 処理すると期待されるか否かを決定することと、前記関連するデータソースが 要求を処理すると予想される場合、関連するデータソースに対する要求を送信 し、要求に関する結果を関連するデータソースから受信し、要求に関する結果 を計算エレメントに送ることと、前記関連するデータソースが要求を処理する と予想されない場合、要求に対してデータが提供されない旨を計算エレメント に知らせることによって遮断された要求に対して応答することとで成ることを 特徴とする方法。 ２１．計算エレメントと、データソースから前記計算エレメントへデータを提供 しかつ前記計算エレメントに対し非同期的に作動する複数のコントローラを有 するコンピュータシステム中で、同一インストラクションストリームを処理す る計算エレメント間において同期を維持する方法において、同一インストラク ションストリームを処理する計算エレメントにおいては、各計算エレメントが インストラクションストリーム中の共通点でインストラクションストリームの 処理を停止する段階と、フリーズ要求メッセージを生成する段階と、前記フリ ーズ要求メッセージをコントローラに送信する段階とを含み、或るコントロー ラにおいては、或る計算エレメントからフリーズ要求メッセージを受信する段 階と、他の計算エレメントからのフリーズ要求メッセージを待ち受ける段階と 、同一インストラクションストリームを処理する各計算エレメントからフリー ズ要求メッセージを受信した時に、フリーズ応答メッセージを生成し、前記フ リーズ応答メッセージを計算エレメントに送信する段階とを含み、同一インス トラクションストリームを処理する計算エレメントにおいては、前記計算エレ メントが、或るコントローラからのフリーズ応答メッセージを受信時に、フリ ーズ要求メッセージが送信された他のコントローラからのフリーズ要求メッセ ージを待ち受ける段階と、前記各コントローラからのフリーズ応答メッセージ を受信した時に、フリーズリリースメッセージを生成する段階と、フリーズリ リースメッセージをコントローラに送信する段階と、インストラクションスト リームの処理を再開する段階を含むことを特徴とする方法。 ２２．インストラクションストリーム中の前記共通点がＩ／Ｏ操作に対応するこ とを特徴とする上記請求項２１に記載の方法。 ２３．前記インストラクションストリーム中の共通点がＩ／Ｏ操作なしで所定数 のインストラクションが発生することに対応することを特徴とする上記請求項 ２１に記載の方法。 ２４．フリーズ応答メッセージを生成する段階が、前記フリーズ応答メッセージ 中に時間更新を含ませることを含んでおり、更に計算エレメントを所有するこ とと、フリーズ要求メッセージが送信された各コントローラからのフリーズ応 答メッセージを受信する時に、フリーズ応答メッセージからの時間更新を使っ てシステム時間を更新することを含むことを特徴とする上記請求項２１に記載 の方法。 ２５．システム時間を更新する段階が、ある特定のコントローラが生成するフリ ーズ応答メッセージからの時間更新を使うことを含むことを特徴とする上記請 求項２４に記載の方法。 ２６．計算エレメントを所有することと、フリーズ要求メッセージが送信された 各コントローラからのフリーズ応答メッセージを受信する時に、フリーズ応答 メッセージを受信する以前にコントローラから受信したデータを処理すること を更に含むことを特徴とする上記請求項２１に記載の方法。 ２７．エラー報告エレメントと、エラー処理エレメントを有するコンピュータシ ステム中でフォールトを扱う方法において、或るエラー報告エレメントを通し てエラー条件を検出し、前記エラー条件に関する情報をエラーメッセージとし てエラー報告エレメントに接続されたエラー処理エレメントに送信する段階と 、少なくとも１つのエラー処理エレメントを通して、前記少なくとも１つのエ ラー処理エレメントに接続される他のエラー処理エレメントへ前記エラーメッ セージを再送信することを特徴とする方法。 ２８．エラー報告エレメントと、エラー処理エレメントを有するコンピュータシ ステム中でフォールトを扱う方法において、複数のエラー報告エレメントを通 してエラー条件を検出し、前記エラー条件に関する情報をエラーメッセージと して、エラー報告エレメントに接続されたエラー処理エレメントに送信するこ とと、少なくとも１つのエラー処理エレメントを通して、複数のエラー報告エ レメントから関係エラーメッセージの情報を組合せ、エラー条件のソースを特 定する際に前記組合せ情報を使うことから成ることを特徴とする方法。 ２９．前記少なくとも１つのエラー処理エレメントが、関係エラーメッセージの 情報を組合せるために状態表を使うことを特徴とする上記請求項２８に記載の 方法。 ３０．前記少なくとも１つのエラー処理エレメントが、特定のエラーを識別する エラー識別子と、エラーメッセージが表すエラーを生じさせたサブコンポーネ ントを識別するエラーターゲットと、エラーメッセージを生成したエラー報告 エレメントとエラーメッセージが受信されたパスを特定する報告ソースとを使 って、エラーメッセージを表すことを特徴とする上記請求項２９に記載の方法 。 ３１．エラー処理エレメントが、以前に受信されたエラーメッセージを表す状態 に対して受信したエラーメッセージを比較することにより、エラーメッセージ が関係あるか否かを決定することを特徴とする上記請求項２９に記載の方法。 ３２．計算エレメントと、データソースと、前記データソースから前記計算エレ メントへデータを提供するコントローラとを有し、前記計算エレメントは、前 記計算エレメント上で作動するソフトウェアがなすデータ要求を遮断しかつ遮 断された要求をコントローラに送信するするように構成され、少なくとも第１ コントローラは、要求されたデータを計算エレメントへ送信することと、第２ コントローラが遮断された要求に対してどのように応答するかを表示すること で、遮断された要求に対し応答するよう構成されていることを特徴とするシス テム。 ３３．前記第２コントローラは、２コントローラが遮断された要求に対応するデ ータを持っていない旨表示することと、第１コントローラが遮断された要求に 対して応答するデータを計算エレメントに送信することによって応答する旨表 示することで、遮断された要求に対し応答するよう構成されていることを特徴 とする上記請求項３２に記載のシステム。 ３４．各コントローラが遮断された要求に応じて、他の各コントローラが遮断さ れた要求に対してどのように応答するかに関する表示を含むよう構成されてい ることを特徴とする上記請求項３２に記載のシステム。 ３５．計算エレメントが遮断された要求に対する応答の一貫性を比較するよう構 成されていることを特徴とする上記請求項３２に記載のシステム。 ３６．計算エレメントが全コントローラからの応答を受信した後に応答の一貫性 を比較し、応答が全コントローラから受信された旨と比較結果をコントローラ に知らせるよう構成されていることを特徴とする上記請求項３５に記載のシス テム。 ３７．計算エレメントが全コントローラからの応答を所定時間内に受信しなかっ た場合エラー条件を生成するよう構成されていることを特徴とする上記請求項 ３２に記載のシステム。 ３８．第１データソースが第１コントローラと関連しており、第１コントローラ は遮断された要求中に要求されているデータを第１データソースから得るよう 構成されていることを特徴とする上記請求項３２に記載のシステム。 ３９．第１コントローラは第２コントローラの状態の記録を維持しかつ第２コン トローラが遮断された要求にどのように応答するかを表示する時に前記記録を 使うよう構成されていることを特徴とする上記請求項３２に記載のシステム。 ４０．第１データソースは第２コントローラと関連しており、第１コントローラ は第１データソースの状態の記録を維持しかつ第２コントローラが遮断された 要求にどのように応答するかを表示する時に前記記録をつかうよう構成されて いることを特徴とする上記請求項３９に記載のシステム。 ４１．第１コントローラは、第１データソースの状態が変化した時、計算エレメ ントに他のコントローラからの応答を棄却する指示を送信するよう構成されて いることを特徴とする上記請求項４０に記載のシステム。 ４２．前記計算エレメントが指示に対して、遮断された要求に対する他のコント ローラからの応答を棄却することと、応答が棄却された旨の知らせをコントロ ーラに送信することにより、応答するよう構成されていることを特徴とする上 記請求項４１に記載のシステム。 ４３．第１コントローラが、第１データソースの状態の記録を更新することで、 前記知らせに応答するよう構成されていることを特徴とする上記請求項４２に 記載のシステム。 ４４．第１コントローラが、記録更新後に要求データを計算エレメントへ再送信 し、第２コントローラが遮断された要求に対しどのように応答するかを表示す るよう構成されていることを特徴とする上記請求項４３に記載のシステム。 ４５．データソースが各コントローラに関連しており、各コントローラが、関連 するあるデータソースに要求の処理を期待されるか否かを決定することと、前 記データソースが要求を処理するよう期待される場合、前記関連するデータソ ースに要求を送信し、要求の結果をデータソースから受信し、前記要求の結果 を計算エレメントに送ることと、前記データソースが要求を処理すると期待さ れない場合、要求に対しデータが提供されない旨計算エレメントに知らせるこ とで、遮断された要求に対し応答するよう構成されていることを特徴とする上 記請求項３２に記載のシステム。 ４６．計算エレメントと、データソースと、前記データソースから前記計算エレ メントにデータを提供するコントローラを有するコンピュータシステムにおい て、前記計算エレメントは、計算エレメント上で作動するソフトウェアがなす データ要求を遮断しかつ遮断されたデータ要求をコントローラに送信するよう 構成され、各コントローラは、関連するあるデータソースに要求の処理を期待 されるか否かを決定することと、前記データソースが要求を処理するよう期待 される場合、前記関連するデータソースに要求を送信し、要求の結果をデータ ソースから受信し、前記要求の結果を計算エレメントに送ることと、前記デー タソースが要求を処理すると期待されない場合、要求に対しデータが提供され ない旨計算エレメントに知らせることで、遮断されたデータ要求に応答するよ う構成されていることを特徴とするコンピュータシステム。 ４７．同一のインストラクションストリームを処理するよう構成された計算エレ メントと、データソースと、前記データソースから前記計算エレメントにデー タを提供しかつ前記計算エレメントに対して非同期的に作動するよう構成され たコントローラを有するコンピュータシステムにおいて、前記計算エレメント の各々は更に、インストラクションストリーム中の或る共通点でインストラク ションストリームの処理を停止し、フリーズ要求メッセージを生成し、フリー ズ要求メッセージをコントローラに送信するよう構成され、或るコントローラ は更に、計算エレメントからのフリーズ要求メッセージを受信し、他の計算エ レメントからのフリーズ要求メッセージを待ち受け、各計算エレメントからの フリーズ要求メッセージを受信した時、フリーズ応答メッセージを生成してか つ計算エレメントに送信するよう構成され、前記計算エレメントの各々は、更 に、或るコントローラからのフリーズ応答メッセージを受信した時、フリーズ 要求メッセージが送信された他のコントローラからのフリーズ応答メッセージ を待ち受け、前記各コントローラからのフリーズ応答メッセージを受信したと き、フリーズリリースメッセージを生成し、フリーズリリースメッセージをコ ントローラに送信し、インストラクションストリームの処理を再開するよう構 成されていることを特徴とするコンピュータシステム。 ４８．エラー報告エレメントとエラー処理エレメントを有し、或るエラー報告エ レメントはエラー条件を検出し、前記エラー条件についての情報をエラーメッ セージとしてエラー報告エレメントに接続されているエラー処理エレメントに 送信するよう構成され、少なくとも１つのエラー処理エレメントは、エラーメ ッセージを前記エラー処理エレメントに接続されたエラー処理エレメントに送 信するよう構成されていることを特徴とするコンピュータシステム。 ４９．複数のエラー報告エレメントと複数のエラー処理エレメントとを有し、前 記複数のエラー報告エレメントは、エラー条件を検出しかつ前記エラー条件に ついての情報をエラーメッセージとしてエラー報告エレメントに接続されてい る前記複数のエラー処理エレメントに送信するよう構成され、少なくとも１つ のエラー処理エレメントは、多数のエラー報告エレメントから来る関係したエ ラーメッセージからの情報を組合せ、エラー条件のソースを特定する際に組み 合わせた情報を使うよう構成されていることを特徴とするコンピュータシステ ム。