JPS63311444A - 障害検出、救済制御方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔概　要〕 共通バスで接続された複数モジュール及び装置全体の資
源を管理する資源管理機能モジュールを備えた装置の障
害検出、救済制御方式において、資源管理機能モジュー
ルと同等な機能を有するスタンバイ機能モジュールとサ
ービスモジュールを設け、サービスモジュールは装置の
障害状況を把握し、資源管理機能モジュールで重大な障
害が検出されたときは、スタンバイ機能モジュールに資
源管理機能モジュールの処理を代行させる。これにより
、資源管理機能モジュールで発生した障害を容易かつ速
やかに検出２救済し、装置及びシステム全体に殆ど影響
を与えることなく処理をｍ′ｔＥ実行させることができ
る。

〔産業上の利用分野〕

本発明は、共通バスで接続された複数モジュール及び装
置全体の資源を管理するモジュールで構成される装置に
発生した障害の検出、救済制御方式、特に、装置全体の
資源を管理するモジュールに発生した障害の検出、救済
制御方式に関する。

〔従来の技術〕

ホス）ＣＰＵを有する上位装置が入出力装置（Ｉ１０装
置）等の下位装置をアクセスして入出力処理を行う場合
、入出力処理を効率良く行うとともに下位装置の各資源
が有効に利用されるようにするため、上位装置と下位装
置間に制御装置を設けて入出力処理を制御するようにし
ている。

上位装置及び下位装置の規模が大きくなると、上位装置
の複数のバスから多数の下位装置に対して非同期にアク
セス要求が発行される。これに対処するため、制御装置
は共通バスで接続された複数の制御用のモジュールで構
成されるようになってきた。

第４図は、共通バスで接続された複数の制御用のモジュ
ールで構成される従来の制御装置の構成をブロック図で
示したものである。

第４図において、３０は制御装置、４１は上位装置、４
２Ａ〜４２Ｃは上位装置４１と制御装置３０間の各バス
、４３Ａ〜４３Ｇは下位装置、４４ａ〜４４ｆは制御値
Ｗ、３０と下位装置４３Ａ〜４３Ｃ間の各バスである。

制御装置３０において、３１Ａ〜３１Ｃは上位装置制御
部で、それぞれモジュールで構成され、バス４２Ａ〜４
２Ｇに対応して設けられる。

３２Ａ〜３２Ｃはモジュールで構成された下位装置制御
部で、下位袋ｆ４３Ａ〜４３Ｃに対応して設けられる。

下位装置制御部３２Ａと下位装置４３Ａ及び４３Ｃ間は
バス４４ａ及び４４ｂで接続され、下位装置制御部３２
Ｂと下位装置４３Ａ及び４４Ｂ間はバス４４Ｃ及び４４
ｄで接続され、下位装置制御部３２Ｇと下位装置４３Ｂ
及び４３０間はバス４４ｅ及び４４ｆで接続される。

３３は資源管理機能部で、モジュール構成の資源管理部
３３１及び管理テーブル３３２を備えている。資源管理
部３３１は、装置全体の資源の管理を行う、管理テーブ
ル３３２には、資源情報及び処理の状況情報が格納され
る。

３４は共通バスで、上位及び下位装置制御部３１Ａ〜３
１Ｃ，３２Ａ〜３２Ｇ及び資源管理機能部３３がそれぞ
れ接続される。

この構成で、上位装置４１がバス４２Ａにより下位装置
４３Ａと入出力処理を行う場合は、■上位装置制御部３
１Ａ−下位装置制御部３２Ａ−バス４４ａ−下位装置４
３Ａ、又は■上位装置制御部３１Ａ−下位装置制御部３
２Ｂ−バス４４Ｃ−下位袋Ｗ４３Ａ、のいずれかのルー
トで行われる。

同様に、上位装置４１がバス４２Ｂにより下位装置４３
Ｂと入出力処理を行う場合は、■上位装置制御部３１Ｂ
−下位装置制御部３２Ｂ−バス４４ｄ−下位装置４３Ｂ
、又は■上位装置制御部３１Ｂ−下位装置制御部３２Ｃ
→バス４４ｅ−下位装置４３Ｂ、のいずれかのルートで
行われる。

またパス４２Ｃにより下位装置４３Ｃと入出力処理を行
う場合は、■上位装置制御部３１Ｃ−下位装置制御部３
２Ｃ−パス４４ｆ−下位装置４３Ｃ１又は■上位装置３
１Ｇ−下位装置制御部３２Ａ→パス４４ｂ→下位装置４
３Ｃ１のいずれかのルートで行われる。

この制御装置３０に障害が発生した場合、障害を検出、
救済する方式として、ソフトウェアで統計的手法を用い
た障害検出及び被疑装置を含むパスの切離しを行うソフ
トウェアによる障害検出、救済方式がよく用いられる。

次に、このソフトウェアによる障害検出、救済方式を第
３図を参照して説明する。

上位及び下位装置制御部（３１Ａ〜３１Ｃ，３２Ａ〜３
２Ｄ）は、エラー回数をカウントするカウンタ（図示せ
ず）を備えており、その制御部を経由するルートにおけ
る入出力処理にエラーが検出された場合は、カウンタの
エラーカウント値を１だけカウントアツプする。エラー
のカウントアツプは各入出力処理毎に一回行われ、規定
の時間（例えば３０分）内に所定の閾値以上のエラーが
カウントされた場合にそのルートにエラーがあると判定
される。

エラーは一時的な場合又はリトライにより回復する場合
があるので、エラーの有無を判定するカウンタの閾値は
、チャネルエラー、パスエラー。

デバイスエラー等に対応して実験的に適宜選定される。

ソフトウェアにはルートしか意識されないが、各ルート
におけるエラーの有無に基づき、第３図に示すようにし
て障害発生の疑いのあるパス又は装置が検出される。

例工ば、パス４２Ａ→パス４４ａのルートがエラーで、
かつ、パス４２Ｂ→パス４４Ｃのルートがエラーである
場合は、下位装置４３Ａが障害被疑装置として検出され
る。一方、パス４２Ａ−パス４４ａのルートがエラーで
あるが、バス４２Ｂ→バス４４ｃのルートにエラーがな
い場合は、下位装置４３Ａは正常でバス４２Ａ或いはパ
ス４４ａが障害被疑バスとして検出される。

さらにバス４２Ａ→パス４４のルートがエラーであるが
、ハス４２Ａ→パス４４ｂのルートにエラーが発生しな
い場合は、パス４４ａが障害被疑パスとして検出される
。

パス４２Ｂ→パス４４ｄのルートがエラーで、かつ、パ
ス４２Ｃ→バス４４ｅのルートがエラーである場合は、
下位装置４３Ｂが障害被疑装置として検出される。一方
、パス４２Ｂ→パス４４ｄのルートがエラーであるが、
バス４２Ｃ→バス４４ｅのルートにエラーがない場合は
、下位装置４３Ｂは正常でパス４２Ｂ或いはパス４４ｄ
が障害被疑パスとして検出される。

さらにパス４２Ｂ→パス４４ｄのルートがエラーである
が、パス４２Ｂ→パス４４ｅのルートにエラーが発生し
ない場合は、パス４４ｄが障害被疑パスとして検出され
る。

パス４２Ｃ→バス４４ｆのルートがエラーで、かつ、バ
ス４２Ａ→パス４４ｃのルートがエラーである場合は、
下位装置４３Ｇが障害被疑装置として検出される。一方
、パス４２Ｃ−パス４４ｆのルートがエラーであるが、
パス４２Ａ→４４ｂのルートにエラーがない場合は、バ
ス４２Ｇ或いはパス４４ｆが障害被疑バスとして検出さ
れる。

サラにバス４２ｅ→バス４４ｆのルートがエラーである
が、パス４２Ｃ→バス４４ｄのルートにエラーが発生し
ない場合は、パス４４ｆが障害被疑バスとして検出され
る。

以上のようにして、ソフトウェアにより障害のある下位
装置やパスを検出することができる。検出された障害被
疑装置やパスを入出力処理ルートから切り離すことによ
り障害の救済が行われる。

〔発明が解決しようとする問題点〕

共通バスで接続された複数の制御用のモジュールで構成
される従来の制御装置における障害検出、救済方式は、
前述のようにソフトウェアによりエラーのあるルートか
ら障害被疑装置及びパスを検出し、それらを入出力処理
ルートから切り離すことにより救済していた。

しかしながら、この制御装置３０においては、資源管理
部３３１が全ての資源管理が行っているため、上位装置
４１の各バスと所望の下位装置間で入出力処理を行う場
合のルートの確定は、資源管理部３３１によって行われ
る。したがって、資源管理部３３１に障害が発生すると
、上位装置と下位装置間での入出力処理ルートの確定が
出来なくなるので、ソフトウェアから見た場合、すべて
のルートにエラーが発生したように認識される。

このため、共通バスで接続される複数の制御用のモジュ
ールで構成される制御装置３０においては、その資源管
理機能部３３に障害が発生した場合には、従来のソフト
ウェアによる障害検出方式では、障害を発生したバスや
装置を検出できず、制御装置及びシステム全体の処理が
ストップするという問題があった。

このことは、共通バスで接続されたそれぞれ所定の処理
機能を有する複数モジュール及び資源管理用のモジュー
ルで構成される装置において、一般に共通する問題であ
る。

このような障害に対処する一つの方式として、制御装置
を現用と予備に２重化し、現用の制御装置に障害が検出
された場合は予備の制御装置に切り替えて代行させる方
式が用いられる。

しかしながら、システムの規模が大きくなり、それに伴
って制御装置の規模も大きくなると、制御装置を二重化
することは、ハードウェア量及びコストが大幅に増加す
るため、その実施は実際上困難である。

本発明は、共通バスで接続されたそれぞれ所定の処理機
能を有する複数のモジュール及び資源管理用のモジュー
ルで構成される装置において、資源管理用のモジュール
に障害が発生した場合にも、その検出と救済を容易かつ
速やかに行い、装置及びそのシステム全体の動作に支障
が生じないようにする障害検出、救済方式を提供するこ
とを目的とする。

〔発明を解決するための手段〕

本発明の講した解決手段を、第１図を参照して説明する
。第１図は、本発明の基本構成をブロック図で示したも
のである。

第１図において、１０は全体の装置で、共通バスで接続
された複数のモジュールで構成される。

１１、〜１１７及び１２ｌ〜１２．はモジュールで、そ
れぞれ所定の処理機能を有する（なお、記号を１１と１
２のグループに分けるのは後述する実施例との対応を容
易にするためのもので、モジュールが２つのグループか
らなることを意味するものではない）。

１３は資源管理機能モジュールで、装置１０全体の資源
（図示せず）を管理する。

１４はスタンバイ機能モジュールで、資源管理機能モジ
ュール１３と同等の機能を有し、資源管理機能モジュー
ル１３に障害が発生したときに交代してその処理を実行
する。

１５はサービスモジュールで、資源管理機能モジュール
１３からの情報に基づいて装置１０で発生した障害の状
況を把握し、資源管理機能モジュール１３でその処理実
行を不可能とする障害発生を検出したときは各モジュー
ル（１１ｌ〜１１ｎ、。

１２Ｉ〜１２．　）の処理実行を一旦中断させ、資源管
理モジュール１３の制御をスタンバイ機能モジュール１
４に移行する処理を行う。

１６は共通バスで、前述の各種モジュール（１１ｌ〜１
１１１．１２ｌ〜１２ｎ、１３，１４，１５）が接続さ
れる。

〔作　用〕

資源管理機能モジュール１３は、装置１０に障害が発生
したときは、サービスモジュール１５に障害発生状況に
関する情報を送る。

サービスモジュール１５は、この情報に基づいて資源管
理機能モジュール１３における障害発生の状況を把握す
る。

サービスモジュール１５は、資源管理機能モジュール１
３でその処理実行を不可能とする重大な障害発生を検出
したときは、各モジュール１１＋〜１１ｎ、１２ｌ〜１
２．に指令して、それらの実行している処理を一旦中断
させる。

次いで、サービスモジュール１５は、資源管理機能モジ
ュール１３の制御をスタンバイ機能モジュール１４に移
行させ、スタンバイ機能モジュール１４に資源管理機能
モジュール１３の処理を代って実行させる。

スタンバイ機能モジュール１４は、資源管理機能モジュ
ール１３の制御を受は継ぐと、各モジュール１１ｌ〜１
１？ｌ、１２＋〜１２ヨに対し、スタンバイ機能モジュ
ール１４が使用可能になったことを通知する。

この通知を受けると、各モジュール１１ｌ〜１１−．１
２＋〜１２．は処理を再開し、スタンバイ機能モジュー
ル１４を使用してそれまでの処理を再び実行する。

なお、資源管理機能モジュール１３以外の他のバスやモ
ジュールにおける障害発生検出も、サービスモジュール
１５によって行われる。

以上のように、資源管理機能モジュール１３を二重化し
てサービスモジュール１５を設けることにより、資源管
理機能モジュール１３において障害が発生した場合でも
容易かつ確実に検出し、装置及びシステム全体の動作に
殆ど影響を与えることなく、それらの処理を速やかに継
続実行させることができる。

〔実施例〕

本発明の実施例を、第２図を参照して説明する。

第２図は、本発明の一実施例の構成をブロック図で示し
たものである。以下、装置１０が上位装置と下位装置間
の入出力処理を制御する制御装置である場合を例にとっ
て説明する。

（Ａ）実施例の構成 第２図において、装置（以下、この実施例では制御装置
という）　１０、モジュール１１１−１１、、（以下、
この実施例では上位装置制御モジュール（ＯＣＡモジュ
ール）という）及び１２ｌ〜１２、（以下、この実施例
では下位装置制御モジュール（ＬＣＡモジュール）とい
う）、資源管理機能モジュール１３、スタンバイ機能モ
ジュール１４、サービスモジュール１５及び共通バス１
６については、第１図で説明したとおりである。ただし
、資源管理機能モジュール１３及びスタンバイ機能モジ
ュール１４は、この実施例では他の制御装置（１０’　
）と共用化されるため、制御装置１０の外部に示されて
いる。

２１はホストＣＰＵを備えた上位装置、２２゜〜２２ｆ
ｉは上位装置２１と各ＵＣＡモジュール１１ｌ〜１１ｎ
、間のバス、２３ｌ〜２３１．ｌはＩ１０装置等の下位
装置、２４ｌ〜２４□、はＬＣＡモジュール１２ｌ〜１
２．と下位装置２３ｌ〜２３゜間のバスである。各ＬＣ
Ａモジュール１２ｌ〜１２ｏ及び各下位装置２３ｌ〜２
３１１には、それぞれ２本のバスが接続される。

資源管理機能モジュール１３において、１３１は資源管
理モジュールで、装置の全資源の管理を行う、１３２は
管理テーブルで、資源情報及び処理状況の情報が格納さ
れる。

スタンバイ機能モジュール１４において、１４１はスタ
ンバイモジュールで、資源管理モジュールと同じ構成を
有している。１４２はスタンバイテーブルで、管理テー
ブル１３２と同じ構成を有し、コピーバス１７を介して
管理テーブル１３２の内容がコピーされる。

１８はサービスバスで、サービスモジュールとＬＣＡモ
ジュール１２Ｉ〜１２．　、ＵＣＡモジュール１１ｌ〜
１１１、資源管理モジュール１３１及びスタンバイモジ
ュール１４１間を接続する。

１０′は第２図に示す制御装置１０と同様に、共通バス
１６′で複数のＵＣＡモジュール、ＬＣＡモジュール及
びサービスモジュール（いずれも図示せず）が接続され
る構成の独立の制御装置（資源管理機能モジュール及び
スタンバイ機能モジュールは備えていない）で、上位装
置２１に図示しないバスを介して接続され、また複数の
下位装置にもバスを介して接続される（いずれも図示せ
ず）。

１８′は、制御装置１０′のサービスバスで、スタンバ
イモジュール１４１、資源管理モジュール１３１を制御
装置１０′内の各ＵＣＡモジュール、ＬＣＡ・モジュー
ルを経由してそのサービスモジュールに接続する。

資源管理機能モジュール１３及びスタンバイ機能モジュ
ール１４は、制御装置１０及び１０′に共通に用いられ
、共通バス１６及び１６′に並列に接続される。

（Ｂ）実施例の動作 制御装置１０及び１０′の動作は同様であるので、以下
、制御装置１０における障害検出救済動作について説明
する。

■　資源管理モジュール１３１に装置の処理状況を管理
しており、障害が発生するとサービスバス１８を経由し
てサービスモジュール１５に障害が発生したことを通知
する。共通バス１６を経由して通知することも可能であ
るが、サービスバス１８を用いることにより確実に通知
することができる。

■　サービスモジュール１５は、通知された情報より、
資源管理モジュール１３１の障害状況を分析して把握す
る。障害は再試行すなわちリトライにより回復する場合
があるので、サービスモジュール１５は資源管理モジュ
ール１３１に指令して、リトライを行わせる。リトライ
により障害が回復した場合は、従前の処理が′ｍＶｔ実
行される。

リトライにより障害が回復せず、資源管理モジュール１
３１の障害状況が重大な場合、サービスモジュール１５
は、次の■以降の手順により資源管理機能モジュール１
３の制御をスタンバイ機能モジュール１４に移す処理を
行う。

■　資源管理モジュール１３１に障害が発生しても、各
ＵＣＡモジュール１１ｌ〜１１ｎ、及びＬＣＡモジュー
ル１２ｌ〜１２．にはその障害発生が認識されないので
、各モジュールの処理は引き続き実行されている。

各モジュールの処理を中断させるために、サービスモジ
ュール１５は、各ＵＣＡモジュール１１、〜１１．及び
ＬＣＡモジュール１２ｌ〜１２、に対して、共通バス１
６を経由して資源管理モジュール１３１で重大な障害が
発生したことを通知する。

この通知を受けると、ＵＣＡ１１＋〜１１７は、上位装
置２１に対し“制御装置使用中゛コードを通知して、上
位装置２１の行う処理を待たせるようにする。

また、ＬＣＡ１２＋〜１２．は、対応する下位装置２３
ｌ〜２３．からの割込みを受は付けないようにする。

■　サービスモジュール１５は、サービスバス１８を経
由して資源管理モジュール１３１に対して指令し、共通
バス１６から各モジュールが行う資源管理モジュール１
３１及び管理テーブル１３２へのアクセス受付けを禁止
する。

これにより、資源管理モジュール１３１及び管理テーブ
ル１３２は使用不可能となり、各モジュールが障害のあ
る資源管理モジュール１３１及び管理テーブル１３２を
アクセスして誤処理をするのを防止することができる。

■　サービスモジュール１５は、資源管理機能モジュー
ル１３からスタンバイ機能モジュールエ４に制御をスイ
ッチしてスタンバイ処理を行うことをスタンバイモジュ
ール１４１にＩ誇示する。

この指示は、確実性を期するためにサービスバス１８を
経由して行われる。

なお、資源情報及び処理状況の情報は、管理テーブル１
３２に格納されるとともに、コピーバス１７を経由して
常時スタンバイテーブル１４２にもコピーされる。

■　スタンバイモジュール１４１は、サービスモジュー
ル１６からのスタンバイ指示を受領すると、資源管理モ
ジュール１３１に交代してその動作を開始することが可
能となる。

■　スタンバイモジュール１４１は、共通バス１６を経
由して各ＵＣＡ１１＋〜１１．及びＬＣＡ１２ｌ〜１２
．に対し、スタンバイモジュール１４１及びスタンバイ
テーブル１４２が使用可能になったことを通知する。

この通知を受けると、各Ｕ　ＣＡ　１１　Ｉ〜１１．は
上位装置２１に“制御装置使用中解除”の報告を行って
、上位装置２１からの受付は処理を再開する。

また、各ＬＣＡ１２＋〜１２．は、下位装置２３ｌ〜２
３．からの割込みの受付けを再開する。

■　以後、ＯＣＡモジュール１１ｌ〜１１．及びＬＣＡ
モジュール１２ｌ〜１２．は、スタンバイモジュール１
４１及び管理テーブル１４２を使用してそれぞれの入出
力処理を実行する。

なお、資源管理モジュール１３１で障害が発生したとき
に、ＵＣＡ及びＬＣＡの各モジュールが共通バス１６を
介して下位装置２３ｌ〜２３、間との処理を実行してい
た場合は、前述の■の処理後に上位装置２１に対し、処
理を行っていた各ＵＣＡモジュールより異常終了の通知
を行う、これにより、上位装置２１よりそのＵＣＡモジ
ュールに対して同一処理が再指示されるので、それまで
の処理の誤りが訂正されて正常な処理が実行されるよう
になる。

以上のようにして、資源管理機能モジュール１３で障害
が発生しても、スタンバイ機能モジュール１４及びサー
ビスモジュール１５により速やかに障害の検出及び救済
が行われるので、制御装置１０及びシステムの処理が一
時的に中断するのみでそれらの処理に殆ど影響を与える
ことなく継続実行させることができる。

制御装置１０′側においても前述の制御装置１０側にお
けると同様な処理が行われる。なお、制御装置１０′は
制御装置１０とは別個にその入出力装置に対する入出力
処理を行うが、更に増設することができる。その場合も
、資源管理機能モジュール１３及びスタンバイ機能モジ
ュール１４は、各制御装置に共用される。

〔発明の効果〕

以上説明したように、本発明によれば次の諸効果が行わ
れる。

（イ）装置の資源管理機能モジュールで障害が発生した
場合も、それを容易かつ確実に検出して速やかにその救
済を行うことができる。

（ｔＦ）装置全体を２重化するよりもはるかに簡単な構
成で、資源管理機能モジュールで障害発生した場合でも
装置及びシステムの動作に影響を与えることなく、それ
らの処理を速やかに継続実行させることができる。

【図面の簡単な説明】

第１図は本発明の基本構成の説明図、 第２図は本発明の一実施例の構成の説明図、第３図はソ
フトウェアによる障害検出、救済方式の説明図、 第４図は従来の障害検出、救済制御方式の説明図である
。 第１図及び第２図において、 １０．１０’・・・装置又は制御装置、１１ｌ〜１１７
・・・モジュール又は上位装置制４ＢＣＵＣＡ）モジュ
ール、１２ｌ〜１２１・・・モジュール又は下位装置制
御（ＬＣＡ）モジュール、１３・・・資源管理機能モジ
ュール、１４・・・スタンバイ機能モジュール、１５・
・・サービスモジュール、１６．１６’・・・共通バス
、１７・・・コピーバス、１８．１８’・・・サービス
バス、１３１・・・資源管理モジュール、１３２・・・
管理テーブル、１４１・・・スタンバイモジュール、１
４２・・・スタンバイテーブル、２１・・・上位装置、
２３ｌ〜２３．・・・下位装置。 特許出願人　　　　富　士　通　株式会社参罹り目＾″
Ｉｌ−千不員戚゛ 第１図 ゝノットウェア１；「う鱒市＃七、叔涛方ｇ浸壕の縛賓
建払５截惰利御防式゛ 愉　Ａ　　Ｃ５

Claims (3)

【特許請求の範囲】
1. （１）共通バス（１６）で接続される、それぞれ所定の
   処理機能を有する複数のモジュール（１１＿ｌ〜１１＿
   ｎ、１２＿ｌ〜１２＿ｍ）と装置（１０）全体の資源を
   管理する資源管理機能モジュール（１３）を備えた装置
   （１０）に、発生する障害の検出、救済制御方式におい
   て、 （ａ）資源管理機能モジュール（１３）と同等の機能を
   有し、共通バス（１６）で接続され、資源管理機能モジ
   ュール（１３）で障害が発生したときに交代してその処
   理を実行するスタンバイ機能モジュール（１４）と、 （ｂ）共通バス（１６）で接続され、資源管理機能モジ
   ュール（１３）からの情報に基づいて装置（１０）で発
   生した障害の状況を把握し、資源管理機能モジュール（
   １３）でその処理実行を不可能とする障害発生を検出し
   たときは各モジュール（１１＿ｌ〜１１＿ｎ、１２＿ｌ
   〜１２＿ｍ）の処理実行を一旦中断させ、資源管理機能
   モジュール（１３）の制御をスタンバイ機能モジュール
   （１４）に移行するサービスモジュール（１６）、 を設けたことを特徴とする障害検出、救済制御方式。
2. （２）サービスモジュール（１５）、各モジュール（１
   １＿ｌ〜１１＿ｎ、１２＿ｌ〜１２＿ｍ）、資源管理機
   能モジュール（１３）及びスタンバイ機能モジュール（
   １４）を接続するサービスバス（１８）を設け、資源管
   理機能モジュール（１３）に障害が発生した場合にこの
   サービスバス（１８）を経由して情報の転送が行われる
   ことを特徴とする特許請求の範囲第１項記載の障害検出
   、救済制御方式。
3. （３）資源管理機能モジュール（１３）に設けられ、資
   源情報及び処理状況の情報が格納される管理テーブル（
   １３２）とスタンバイ機能モジュール（１４）に設けら
   れたスタンバイテーブル（１４２）との間に、管理テー
   ブル（１３２）の内容をスタンバイテーブル（１４２）
   に転送するコピーバス（１７）を設けたことを特徴とす
   る特許請求の範囲第１項又は第２項記載の障害検出、救
   済制御方式。