(57)【特許請求の範囲】
【請求項１】
主ユニットと冗長構成を持つ通信用ユニットと該通信用ユニット配下の配下ユニットを備え、主ユニットは現用系通信用ユニットに障害がある時に予備系通信用ユニットに冗長切替を行う装置の監視制御装置であって、
該主ユニットは、現用系通信用ユニットから予備系通信用ユニットに通信経路を切り替えてコマンドを送出し、該予備系通信用ユニットからの応答を検査することで主ユニット・予備系通信用ユニット間の通信経路の異常の有無を監視し、その後に元の現用系通信ユニットに通信経路を戻すリバース処理を周期的に行い、
予備系通信用ユニットが実装された直後の動作が不安定な状態の場合に行うリバース処理の頻度よりも、それ以外の安定した状態の場合に行うリバース処理の頻度を低くするように構成した監視制御装置。
【請求項２】
上記主ユニットは上記リバース処理を行うにあたり、他の割込みをマスクしてリバース処理の優先度を最も高くするように構成した請求項１記載の監視制御装置。
【請求項３】
現用系通信用ユニットの故障により予備系通信ユニットに冗長切替を行う前に上記リバース処理を行って主ユニット・予備系通信用ユニット間の現在の通信経路の異常の有無を確認するように構成した請求項１または２記載の監視制御装置。
【請求項４】
予備系通信用ユニットに既に何らかの故障がある場合は、リバース処理を行わないように構成した請求項１〜３のいずれかに記載の監視制御装置。
【請求項５】
冗長切替前に現用系であった通信用ユニット・配下ユニット間の通信パス異常の情報は、配下ユニットが未実装になるまで通信パス異常テーブルに保持するように構成した請求項１〜４の何れかに記載の監視制御装置。
【請求項６】
配下ユニットの故障の有無を判断する際には、通信用ユニットへのコマンドに対する応答が正常かつ配下ユニットへのコマンドに対する応答が異常な場合のみ配下ユニットの故障とし、通信用ユニットへのコマンドに対する応答が異常な場合は、上記通信パス異常テーブルに上記通信パス異常の情報が保持されているとき以外は故障としないことで、故障箇所を限定するよう構成した請求項５に記載の監視制御装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、冗長構成通信経路を持つ装置の通信経路等の異常の監視を行う監視制御装置に関する。
【０００２】
近年、通信サービスが多様化する中で、通信装置も大容量化・複雑化している。これに伴い、通信装置の信頼性の向上が求められている。このため、ＣＰＵと通信機能を持つＬＳＩを搭載したＣＰＵパッケージが、冗長構成をもつ通信用パッケージを介して配下パッケージと通信する装置においては、冗長構成をもつ通信用パッケージを監視制御することが必要とされる。
【０００３】
図１はかかる装置構成を示す図である。図示のように、本装置では、ＣＰＵパッケージ４が現用系（運用系）／予備系（非運用系）の冗長構成を持つ通信用パッケージ５１、５２と通信線を介して接続され、各通信用パッケージ５１、５２は配下パッケージ６１、６２、６３・・・とそれぞれ通信線を介して接続される。
【０００４】
ＣＰＵパッケージ４はＣＰＵ（中央処理装置）４１と通信機能を持つ通信ＬＳＩ４２とを搭載し、現用系／予備系の通信用パッケージ５１、５２を選択するセレクタ４３を持つ。通信用パッケージ５１、５２それぞれは、ＣＰＵパッケージ４からのコマンドを各配下パッケージ６１、６２、６３・・・に宛てて送信し、各配下パッケージ６１、６２、６３・・・からの応答結果をＣＰＵパッケージ４に送信する。配下パッケージ６１、６２、６３・・・は、通信用パッケージ５１または５２からのコマンドに対して応答を返す機能を持ち、通信用パッケージを選択するセレクタ６１１、６２１、６３１・・・を持つ。ＣＰＵパッケージ４と配下パッケージ６１、６２、６３・・・は冗長構成を持つ通信用パッケージ５１、５２の一方をセレクタにて選択し、選択している系を現用系（運用系とも称する）、選択していない系を予備系（非運用系とも称する）とする。
【０００５】
この通信用パッケージ５１、５２の冗長切替は、現用系・予備系の通信用パッケージ５１、５２の故障の有無を見て、現用系が故障かつ予備系が正常な場合にＣＰＵパッケージ４のセレクタ４３と配下パッケージ６１、６２、６３・・・のセレクタ６１１、６２１、６３１・・・によって切替を行う。例えば０系の通信用パッケージ５１が現用系の場合、図２の通信ルートをとり、冗長切替が発生すると、図３の通信ルートをとる。
【０００６】
ただし、例えば図２に示すように、０系の通信用パッケージ５１が現用系の場合、ＣＰＵパッケージ４のセレクタ４３は現用系通信用パッケージ５１を向いているため、ＣＰＵパッケージ４からはＣＰＵパッケージ４・通信用パッケージ５２間の通信パスを通して直接に予備系通信用パッケージ５２の故障状態を検知することができず、ＣＰＵパッケージ４は現用系の通信用パッケージ５１を介して通信した予備系通信用パッケージ５２への通信結果から予備系通信用パッケージ５２の故障状態を判断する。
【０００７】
この従来の通信用パッケージの冗長切替では、例えば通信用パッケージ５１が現用系の場合、ＣＰＵパッケージ４・予備系通信用パッケージ５２間の通信パスの故障があっても、ＣＰＵパッケージ４から現用系通信用パッケージ５１を介しての予備系通信用パッケージ５２への通信には何の異常もないため、予備系通信用パッケージ５２の故障（ＣＰＵパッケージ４・通信用パッケージ５２間の通信パス故障）はＣＰＵパッケージ４には見えない。
【０００８】
この結果、現用系通信用パッケージ５１に何らかの故障があった場合、予備系は正常と判断しているので、通信用パッケージの切替が発生する。すると、初めてＣＰＵパッケージ４・通信用パッケージ５２間の故障が分かる。しかし、この時点では、既に両系の通信用パッケージ５１、５２に故障があることになり、切替動作自体が無駄であり、またその配下パッケージ６１、６２、６３・・・の通信の正常性は全く期待できない。また、予備系の通信用パッケージ５２と各配下パッケージ６１、６２、６３・・・間の通信パスに異常があった場合にも、予備系への切替が行われた後でなければそれを発見することができない。
【０００９】
また、通信用パッケージの冗長切替によって故障状態が見えなくなる通信パスが生ずることもある。例えば０系の通信用パッケージ５１が現用系の場合、図２の通信ルートをとる。この時、０系通信用パッケージ５１・配下パッケージ６１間の通信パスに異常があったとすると、通信用パッケージの冗長切替が発生するが、切替後は０系通信用パッケージ５１・配下パッケージ６１間の通信パスは使用されないので、故障状態を監視することができない。
【００１０】
したがって本発明は、予めＣＰＵパッケージ・予備通信用パッケージ間の通信パスの正常性を確認できるようにして監視制御性能を向上させることを目的とする。
【００１１】
【問題点を解決するための手段】
前述の問題点を解決するために、本発明においては、一つの形態として、ＣＰＵを搭載した主ユニットと冗長構成を持つ通信用ユニットと該通信用ユニット配下の配下ユニットを備え、主ユニットは現用系通信用ユニットに障害がある時に予備系通信用ユニットに冗長切替を行う装置の監視制御装置であって、該主ユニットは、現用系通信用ユニットから予備系通信用ユニットに通信経路を切り替えてコマンドを送出し、該予備系通信用ユニットからの応答を検査することで主ユニット・予備系通信用ユニット間の通信経路の異常の有無を検査し、その後に元の現用系通信ユニットに通信経路を戻すリバース処理を周期的に行い、予備系通信用ユニットが実装された直後の動作が不安定な状態の場合に行うリバース処理の頻度よりも、それ以外の安定した状態の場合に行うリバース処理の頻度を低くするように構成した監視制御装置が提供される。
このようにリバース処理を行うことにより、予め主ユニット・予備系通信用ユニット間の通信経路の正常性を確認することができるので、監視制御性能の向上が図られる。また、上記リバース処理の頻度を、予備系通信用ユニットが実装された直後の動作が不安定な状態の場合よりも、それ以外の安定した状態の場合に低くするようにしたので、監視制御性能を維持しつつ無駄な切替を防止することができる。
【００１２】
上記の監視制御装置では、上記主ユニットは上記リバース処理を行うにあたり、他の割込みをマスクしてリバース処理の優先度を最も高くするように構成できる。このようにすることで、リバース処理よりも優先度の高い処理が割り込んでくることがある装置構成の場合、リバース処理中に他のコマンドが飛ばないように、処理の優先度を最も高くすることで、通信の異常動作を防止できる。
【００１３】
また上記の監視制御装置では、現用系通信用ユニットの故障により予備系通信ユニットに冗長切替を行う前に上記リバース処理を行って主ユニット・予備系通信用ユニット間の現在の通信経路の異常の有無を確認するように構成できる。このようにすることで、リバース処理の頻度を低くして監視制御動作性能を維持しつつ、無駄な切替を防止することができる。
【００１５】
また上記の監視制御装置では、予備系通信用ユニットに既に何らかの故障がある場合は、リバース処理を行わないように構成できる。このようにすることで、リバース処理の頻度を低くして監視制御動作性能を維持することができる。
【００１６】
また上記の監視制御装置では、冗長切替前に現用系であった通信用ユニット・配下ユニット間の通信パス異常の情報は、配下ユニットが未実装になるまで通信パス異常テーブルに保持するように構成できる。このようにすることで、切替前に現用系であった通信用ユニット・配下ユニット間の通信パス異常は、切替が発生すると使用しない通信パスとなるため、故障状態の監視を行っても配下ユニットとの通信は正常になるので、故障状態を配下ユニットが未実装になるまで保持することによって、通信用ユニットの切替の有無に関わらず、故障として扱えるようになる。
【００１７】
また上記の監視制御装置では、配下ユニットの故障の有無を判断する際には、通信用ユニットへのコマンドに対する応答が正常かつ配下ユニットへのコマンドに対する応答が異常な場合のみ配下ユニットの故障とし、通信用ユニットへのコマンドに対する応答が異常な場合は、上記通信パス異常テーブルに上記通信パス異常の情報が保持されているとき以外は故障としないことで、故障箇所を限定するよう構成できる。このようにすることで、故障箇所を限定することができる。
【００１８】
【発明の実施の形態】
以下、本発明の実施例を説明する。
実施例装置の装置構成は図１に示したものとする。いま０系の通信用パッケージ５１を現用系として装置が運用されているものとする。ＣＰＵパッケージ４は現用系・予備系の通信用パッケージ５１、５２の故障の有無を監視する際に、ＣＰＵパッケージ４が現用系通信パッケージ５１と非通信中にＣＰＵパッケージ４のセレクタ４３を予備系通信用パッケージ５２の方へ一時的に切り替え、予備系通信用パッケージ５２へコマンドを送信する。このコマンドに対して予備系通信用パッケージ５２から応答が返って来ると、この応答を解析することで、ＣＰＵパッケージ４・予備系通信用パッケージ５２間の通信パスの異常の有無を判別する。この処理の後、再びＣＰＵパッケージ４のセレクタ４３を現用系通信用パッケージ５１の方へ戻す。以降、この処理をリバース処理と呼ぶ。
【００１９】
図４はリバース処理の処理手順を示すフローチャート、図６はＣＰＵパッケージ４が周期的に実行する装置監視制御処理手順のフローチャートである。このリバース処理は装置監視制御処理手順のなかで実行される。以下、０系の通信用パッケージ５１を現用系とした場合を例にして各処理を説明する。
【００２０】
図４のリバース処理は、予備系通信用パッケージが正常な場合のみ行う。よって、予備系通信パッケージ５２が正常かを判定する（ステップＳ１）。正常ならば他の優先度の高い処理の割込みをマスクする割込みマスクを行い（ステップＳ２）、ＣＰＵパッケージ４のセレクタ４３を予備系側に切り替え（ステップＳ３）、予備系通信用パッケージ５２にコマンドを送信し（ステップＳ４）、応答があればその応答を解析する（ステップＳ５）。解析の結果、応答が正常か異常かを判定し（ステップＳ６）、異常であればリバース故障フラグに“１”を立てる（ステップＳ７）。その後、セレクタ４３を元の現用系側に切り替え（ステップＳ８）、割込みマスクを解除して（ステップＳ９）、リバース処理を終える。
【００２１】
このようにリバース処理では、処理の最初と最後に他の優先度の高い処理の割込みをマスクする処理と、マスクを解除する処理を行う。このようにマスク処理を行うのは以下の理由による。すなわち、セレクタ４３が予備系通信用パッケージ５２を選択している間に、他の処理が割り込んで入ってくることがあり得るような処理構成の場合は、割り込んで来た処理に応答して直ちに配下パッケージ６１、６２、６３・・・にコマンドを送信すると、通常の運用時におけるＣＰＵパッケージ４・現用系通信用パッケージ５１・配下パッケージ６１、６２、６３・・・という正規の通信ルートとは異なる通信ルート（すなわち予備系通信用パッケージ５２を通る通信ルート）を通って配下パッケージに通信してしまい、問題を生じる場合がある。また、セレクタ４３を動作している時に割り込み処理が入ると、その際の通信の正常性は保証できない。これを避けるために、マスク処理を行うことによって、セレクタ４３の反転動作を行う処理を最も優先度の高い処理としている。
【００２２】
次に図６の装置監視制御処理フローについて説明する。ＣＰＵパッケージ４はＣＰＵパッケージ４・現用系通信用パッケージ５１を介して通信用パッケージ５１、５２の故障情報を収集しており（ステップＳ１１）、この故障情報とリバース処理で求めた予備系通信用パッケージ５２の通信パス異常の有無との論理和をとって現用系と予備系の故障状態とする（ステップＳ１２）。すなわち現用系は現用系側から収集された故障情報に基づいて異常が検知され、予備系はリバース処理の結果と現用系を介しての故障情報収集の結果のいずれか一方が異常の場合には異常とされる。
【００２３】
ついで、現用系／予備系の切り替えが必要かを判定するために、現用系に故障があるかを調べるとともに予備系に故障がないかを調べる。そして現用系が故障かつ予備系が正常なら図４のリバース処理を行う（ステップＳ１３）。ここで行うリバース処理は通信パッケージの運用を現在の現用系通信用パッケージ５１から予備系通信用パッケージ５２に切り替える前に、切替先の予備系が正常であるかを再度確認し信頼性を上げるためである。リバース処理の結果、通信パスに異常がなければ（ステップＳ１５）、通信用パッケージの切替処理を行う（ステップＳ１６）。予備系通信用パッケージ５２に既に何らかの故障がある場合は、リバース処理を行っても無意味であるからリバース処理を行わない（ステップＳ１３）。
【００２４】
ついで、現用系の通信パッケージ５１（現用系／予備系の切替が行われた場合には切替後に現用系となった通信用パッケージ５２、以下同じ）を介して配下パッケージ６１、６２、６３・・・の監視制御処理を行う（ステップＳ１７）。まず現用系通信パッケージ５１に通信パス異常があるかを調べ（ステップＳ１８）、異常がなければ次いで配下パッケージ６１、６２、６３・・・の通信パスに異常があるかを調べる。そして現用系通信用パッケージ５１の通信パス異常なしかつ配下パッケージに通信パス異常ありの場合にのみ、図５に示した通信パス異常テーブルに異常ありを設定する（ステップＳ２０）。一方、現用系通信用パッケージ５１に通信パス異常がある場合にはそれに基づいて配下パッケージも異常となるので、通信パス異常テーブルの設定は行わない。
【００２５】
この通信パス異常テーブルは配下パッケージ６１、６２、６３・・・にそれぞれ対応した記憶領域を持ち、その記憶領域に各配下パッケージ６１、６２、６３・・・の通信パスの異常／正常のデータを記入したものである。この通信パス異常テーブルに異常ありとなっているものは配下パッケージの故障として扱う。
【００２６】
この通信パス異常テーブルは、一旦異常ありに設定されると、その異常ありのパッケージが修理等のために抜き取られて未実装になるまでクリアしない。すなわち、配下パッケージ６１、６２、６３・・・が実装から未実装になったものがないかを調べ（ステップＳ２１）、未実装になったものがあれば、通信パス異常テーブルのその配下パッケージに該当する領域のデータをクリアする（ステップＳ２２）。
【００２７】
このように取り扱うのは以下の理由による。すなわち現用系通信用パッケージ５１・配下パッケージ６１、６２、６３・・・間の通信パス異常は配下パッケージ６１、６２、６３・・・への通信で見えるが、予備系通信用パッケージ５２・配下パッケージ６１、６２、６３・・・間の通信パス異常は見えないので、現用系通信用パッケージ５１配下の故障は、通信用パッケージの冗長切替が発生しても故障状態を保持し、配下パッケージが未実装になるまで故障状態を保持する。
【００２８】
また、配下パッケージの故障の有無を判断する際（図６のステップＳ１７以降）には、通信用パッケージへのコマンドに対する応答が正常（ステップＳ１８で「ＮＯ」）かつ配下パッケージへのコマンドに対する応答が異常な場合（ステップＳ１９で「ＹＥＳ」）のみ配下パッケージの故障とし、通信用パッケージへのコマンドに対する応答が異常な場合（ステップＳ１８で「ＹＥＳ」）は、この通信用パッケージが異常になる前に配下パッケージの通信パスに異常があった（すなわち、通信パス異常テーブルに配下パッケージの通信パス異常が記入されている）場合にのみ配下パッケージの故障として扱い、それ以外の場合は配下パッケージの故障としないことで、故障箇所を限定する。
【００２９】
次に、フローチャート中に3)で示す部分では、予備系が交換等により未実装から実装になった直後は装置監視制御処理フローと同一周期で５回リバース処理を行い、その後は装置監視制御処理の１０周期に１回だけの割合でリバース処理を行う。
【００３０】
このように扱う理由は以下の通りである。すなわち、リバース処理は、現用系・予備系の通信用パッケージが正常な場合は、本来無駄な処理であるため、処理の頻度が少ない方が全体の監視制御能力が高くなる。そこで、予備系の通信用パッケージが実装された直後の、パッケージの状態が不安定な場合は、リバース処理の頻度を高くし、安定な状態の場合は処理の頻度を低くする。この結果、安定な状態に入った後は予備系通信用パッケージの故障検出率が低下するので、前述したように予備系の通信用パッケージを現用系に切り替えようとする前には必ずリバース処理を行うようにする（ステップＳ１４）。
【００３１】
この3)部分について詳細に説明する。予備系通信用パッケージ５２が修理等で抜き取られて未実装となった後に新たな予備系通信用パッケージ５２が実装された場合、その実装されたことが判定されると（ステップＳ２３）、リバースカウンタＡ＝４、リバースカウンタＢ＝９、リバース故障フラグ＝０にそれぞれ初期設定する（ステップＳ２４）。ここでリバースカウンタＡは予備系通信用パッケージ実装直後に行うリバース処理の頻度を管理するカウンタであり、リバースカウンタＢは実装後安定な状態に入ってからのリバース処理の頻度を管理するカウンタである。
【００３２】
まず、リバースカウンタＡが、Ａ≧０かを判定し（ステップＳ２５）、肯定である場合にはリバース処理を行って（ステップＳ２６）、リバースカウンタＡの内容を一つデクリメントする（ステップＳ２７）。従って、予備系通信用パッケージ５２を実装後に装置監視制御処理フローが５回繰り返されると、リバースカウンタＡは、Ａ＜０となるので、その後はリバース処理は行われない。
【００３３】
ついでリバースカウンタＢ＝０かを判定し（ステップＳ２８）、否定の時にはリバースカウンタＢの内容を一つデクリメントする（ステップＳ３１）。Ｂ＝０の時にはリバース処理を行って（ステップＳ２９）、リバースカウンタＢにＢ＝９を再設定する（ステップＳ３０）。よって、予備系通信用パッケージ５２を実装後は装置監視制御処理フローが１０回繰り返される毎に１回、リバース処理が実行される。
【００３４】
以上の処理で故障があるパッケージが発見されたら、その故障があるパッケージに対しては外部に見えるランプを点灯することで保守者に故障があることを知らせる（ステップＳ３２）。
【００３５】
このように本実施例装置では、本来なら切り替えてみなければ分からない、ＣＰＵパッケージ・予備系通信用パッケージ間の通信パス異常の有無を予め知ることができる。リバース処理は、何の異常も無ければ無駄な処理であるため、監視制御処理の毎周期リバース処理を行うのに比べて、効果が薄れないようにリバース処理の頻度を低くすることができる。通信パス異常があるパッケージの故障状態を該当パッケージが未実装になるまで保持することにより、切り替えによって故障が回復したように見えることを防止することができる。配下パッケージの通信パス異常の条件を限定することによって、故障箇所を限定することができる。
【００３６】
【発明の効果】
以上説明したように、本発明によれば、リバース処理を行うことにより、予め主ユニット・予備系通信用ユニット間の通信パスの正常性を知ることができ、予備系通信用ユニットを交換する等の対策をとることが可能なため、保守上の効果が大きい。また、リバース処理による監視制御性能の低下を極力防ぐことができる。また、故障状態の保持、故障箇所を限定することにより、的確な保守動作を促すことができる。
【図面の簡単な説明】
【図１】本発明における監視制御装置の実施例構成を示す図である。
【図２】本発明の実施例装置における０系を現用系とした場合の通信パスを説明する図である。
【図３】本発明の実施例装置における１系を現用系とした場合の通信パスを説明する図である。
【図４】本発明の実施例装置におけるリバース処理の手順を示すフローチャートである。
【図５】本発明の実施例装置における通信パス異常テーブルの構成例を示す図である。
【図６】本発明における装置監視制御処理の手順を示すフローチャートである。
【符号の説明】
４ ＣＰＵパッケージ
４１ ＣＰＵ
４２ 通信ＬＳＩ
４３ セレクタ
５１、５２ 通信用パッケージ
６１、６２、６３・・・ 配下パッケージ
６１１、６２１、６３１ セレクタ
【図１】
0003663196.tif 000002
【図２】
0003663196.tif 000003
【図３】
0003663196.tif 000004
【図４】
0003663196.tif 000005
【図５】
0003663196.tif 000006
【図６】
0003663196.tif 000007