(57)【要約】      （修正有）【課題】正確に死活監視を実行可能な、通信装置および通信装置の監視方法を提供する。【解決手段】通信装置１は、バックプレーン３に接続された、管理パッケージ１１、１２と、通信パッケージ２１、２２、・・・、２ｎ間で、死活監視のロジックを決定する。通信装置１の運用時には、決定された死活監視のロジックに従って、管理パッケージ１１、１２が通信パッケージ２１、２２、・・・、２ｎに対して死活監視を行う。【選択図】図２
2020065136.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
管理パッケージと、
通信パッケージとを備え、
前記通信装置が起動されると、前記管理パッケージおよび前記通信パッケージの間で、死活監視のロジックを決定し、
前記通信装置の運用時には、決定された前記死活監視のロジックに従って、前記管理パッケージが前記通信パッケージに対して前記死活監視を行う、通信装置。
【請求項２】
前記管理パッケージを複数備え、複数の前記管理パッケージのうちの１つが、運用系の管理パッケージに割り当てられ、
前記通信パッケージを複数備え、
前記運用系の管理パッケージが前記死活監視において複数の前記通信パッケージのうち少なくとも１つの異常を検出した場合、前記運用系の管理パッケージは、他の管理パッケージに対して、前記他の管理パッケージによる前記複数の通信パッケージの前記死活監視の結果を要求する、請求項１に記載の通信装置。
【請求項３】
前記要求にも関わらず、前記運用系の管理パッケージが前記他の管理パッケージの前記死活監視の結果を取得できない場合には、前記運用系の管理パッケージは、前記複数の通信パッケージに対する、自己の前記死活監視の結果を確認し、
前記死活監視において異常を示す通信パッケージが１つである場合には、前記運用系の管理パッケージは、前記異常が検出された通信パッケージが異常であると判断し、
前記死活監視において、前記複数の通信パッケージのすべてが異常であることを示す場合には、前記運用系の管理パッケージは、前記運用系の管理パッケージ自体が異常であると判断する、請求項２に記載の通信装置。
【請求項４】
前記要求により、前記運用系の管理パッケージが前記他の管理パッケージの前記死活監視の結果を取得できた場合、前記運用系の管理パッケージは、自己の前記死活監視の結果と、前記他の管理パッケージの前記死活監視の結果とを比較して、
前記運用系の管理パッケージの前記死活監視の結果と、前記他の管理パッケージの前記死活監視の結果とが、同一の通信パッケージの異常を示す場合には、前記運用系の管理パッケージは、前記死活監視において前記異常を示す通信パッケージが異常であると判断し、
前記他の管理パッケージの前記死活監視の結果が、前記複数の通信パッケージのいずれも正常であることを示す場合には、前記運用系の管理パッケージは、前記運用系の管理パッケージ自体が異常であると判断する、請求項２または請求項３に記載の通信装置。
【請求項５】
前記複数の管理パッケージは、前記複数の管理パッケージの間で、死活監視のロジックを調整して、前記調整されたロジックに従って、前記複数の管理パッケージの間で前記死活監視を行い、
前記運用系の管理パッケージが、前記死活監視において、前記他の管理パッケージに異常があることを検出した場合、前記運用系の管理パッケージは、前記複数の通信パッケージに対して前記死活監視を実行し、
前記複数の通信パッケージに対する前記死活監視の結果が、前記複数の通信パッケージのすべてが正常であることを示す場合には、前記運用系の管理パッケージは、前記他の管理パッケージに異常があると判断し、
前記複数の通信パッケージに対する前記死活監視の結果が、前記複数の通信パッケージのすべてが異常であることを示す場合には、前記運用系の管理パッケージは、前記運用系の管理パッケージに異常があると判断する、請求項２から請求項４のいずれか１項に記載の通信装置。
【請求項６】
前記複数の管理パッケージは、バックプレーンに対して活線挿抜に構成され、
前記バックプレーンに接続済の管理パッケージは、前記バックプレーンに接続された新しい管理パッケージに対して、調整された前記死活監視のロジックを導入する、請求項２から請求項５のいずれか１項に記載の通信装置。
【請求項７】
管理パッケージと通信パッケージとを備えた通信装置の監視方法であって、
前記通信装置が起動されることにより、前記管理パッケージおよび前記通信パッケージの間で、死活監視のロジックを決定するステップと、
前記通信装置の運用時において、決定された前記死活監視のロジックに従って、前記管理パッケージが前記通信パッケージに対して前記死活監視を行うステップとを備える、通信装置の監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置および通信装置の監視方法に関する。
【背景技術】
【０００２】
特開２０１６−１６３０８４号公報（特許文献１）は、転送部と制御部とからなるネットワーク装置を開示する。制御部は転送部の死活監視を実行する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１６３０８４
【発明の概要】
【発明が解決しようとする課題】
【０００４】
管理パッケージと通信パッケージとを組み合わせて通信装置を構成することが考えられる。このような通信装置においては、管理パッケージと通信パッケージとが別々に調達される可能性があるため、死活監視のロジックあるいは仕様が、管理パッケージと通信パッケージとで異なる可能性がある。したがって正確に死活監視を実行するためには、管理パッケージと通信パッケージとの間で、死活監視のロジックの整合性を考慮する必要がある。
【０００５】
本発明の目的は、正確に死活監視を実行可能な、通信装置および通信装置の監視方法を提供することである。
【課題を解決するための手段】
【０００６】
本発明の一態様に係る通信装置は、管理パッケージと、通信パッケージとを備える。通信装置が起動されると、管理パッケージおよび通信パッケージの間で、死活監視のロジックを決定する。通信装置の運用時には、決定された死活監視のロジックに従って、管理パッケージが通信パッケージに対して死活監視を行う。
【０００７】
本発明の一態様に係る通信装置の監視方法は、管理パッケージと通信パッケージとを備えた通信装置の監視方法である。監視方法は、通信装置が起動されることにより、管理パッケージおよび通信パッケージの間で、死活監視のロジックを決定するステップと、通信装置の運用時において、決定された死活監視のロジックに従って、管理パッケージが通信パッケージに対して死活監視を行うステップとを備える。
【発明の効果】
【０００８】
上記によれば、正確に死活監視を実行可能な、通信装置および通信装置の監視方法を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態に係る通信装置の構成の模式図である。
【図２】本実施の形態に係る通信装置の概略的な構成を示したブロック図である。
【図３】本実施の形態に係る通信装置における死活監視を概略的に説明する図である。
【図４】運用系の管理パッケージに故障が発生した場合に通信パッケージの死活監視に生じうる課題を説明する図である。
【図５】運用系の管理パッケージに故障が発生した場合に待機系の管理パッケージの死活監視に生じうる課題を説明する図である。
【図６】本実施の形態に係る死活監視（通信装置の監視方法）の概略を説明した第１の図である。
【図７】本実施の形態に係る死活監視（通信装置の監視方法）の概略を説明した第２の図である。
【図８】本実施の形態に係る死活監視のフローの概略を示したフロー図である。
【図９】通信パッケージの死活監視のフローを示すフローチャートである。
【図１０】運用系の管理パッケージが待機系の管理パッケージからの応答を監視する状態を説明するための状態遷移図である。
【図１１】管理パッケージの死活監視のフローを示す第１のフローチャートである。
【図１２】管理パッケージの死活監視のフローを示す第２のフローチャートである。
【発明を実施するための形態】
【００１０】
[本発明の実施形態の説明]
最初に本発明の実施態様を列記して説明する。
【００１１】
（１）  本発明の一態様に係る通信装置は、管理パッケージと、通信パッケージとを備える。通信装置が起動されると、管理パッケージおよび通信パッケージの間で、死活監視のロジックを決定する。通信装置の運用時には、決定された死活監視のロジックに従って、管理パッケージが通信パッケージに対して死活監視を行う。
【００１２】
上記によれば、正確に死活監視を実行可能な、通信装置を提供することができる。管理パッケージと通信パッケージとを組み合わせた通信装置の場合、管理パッケージと通信パッケージとでは死活監視のロジックが異なる可能性がある。管理パッケージおよび通信パッケージの間で、死活監視のロジックを決定することによって管理パッケージと通信パッケージとの間で死活監視のロジックが整合する。これにより、正確に死活監視を実行することができる。
【００１３】
（２）  好ましくは、通信装置は、管理パッケージを複数備える。複数の管理パッケージのうちの１つが、運用系の管理パッケージに割り当てられる。通信装置は、さらに、通信パッケージを複数備える。運用系の管理パッケージが死活監視において複数の通信パッケージのうち少なくとも１つの異常を検出した場合、運用系の管理パッケージは、他の管理パッケージに対して、他の管理パッケージによる複数の通信パッケージの死活監視の結果を要求する。
【００１４】
上記によれば、運用系の管理パッケージと通信パッケージとの間の死活監視において異常が検出された場合に、正確な判断が可能となる。運用系の管理パッケージと通信パッケージとの通信において不具合が生じた場合、運用系の管理パッケージの故障の可能性と、通信パッケージの故障の可能性との両方が考えられる。しかし、運用系の管理パッケージの故障にもかかわらず、運用系の管理パッケージが、通信パッケージに異常が生じたと判定する可能性がある。他の管理パッケージによる複数の通信パッケージの死活監視の結果を要求することによって、このような誤判定の可能性を低減することができる。
【００１５】
（３）  好ましくは、前記要求にも関わらず、運用系の管理パッケージが他の管理パッケージの死活監視の結果を取得できない場合には、運用系の管理パッケージは、複数の通信パッケージに対する、自己の前記死活監視の結果を確認する。死活監視において異常を示す通信パッケージが１つである場合には、運用系の管理パッケージは、異常が検出された通信パッケージが異常であると判断する。死活監視において、複数の通信パッケージのすべてが異常であることを示す場合には、運用系の管理パッケージは、運用系の管理パッケージ自体が異常であると判断する。
【００１６】
上記によれば、運用系の管理パッケージが、他の管理パッケージの死活監視の結果を取得できない場合にも、運用系の管理パッケージは、自己の死活監視結果に基づいて、運用系の管理パッケージが異常かどうかを判断することができる。
【００１７】
（４）  好ましくは、前記要求により、運用系の管理パッケージが他の管理パッケージの死活監視の結果を取得できた場合、運用系の管理パッケージは、自己の死活監視の結果と、他の管理パッケージの死活監視の結果とを比較する。運用系の管理パッケージの死活監視の結果と、他の管理パッケージの死活監視の結果とが、同一の通信パッケージの異常を示す場合には、運用系の管理パッケージは、死活監視において異常を示す通信パッケージが異常であると判断する。他の管理パッケージの死活監視の結果が、複数の通信パッケージのいずれも正常であることを示す場合には、運用系の管理パッケージは、運用系の管理パッケージ自体が異常であると判断する。
【００１８】
上記によれば、運用系の管理パッケージは、自己の死活監視の結果と他の管理パッケージの死活監視の結果とを比較することにより、運用系の管理パッケージが異常かどうかを判断することができる。
【００１９】
（５）  好ましくは、複数の管理パッケージは、複数の管理パッケージの間で、死活監視のロジックを調整して、調整されたロジックに従って、複数の管理パッケージの間で死活監視を行う。運用系の管理パッケージが、死活監視において、他の管理パッケージに異常があることを検出した場合、運用系の管理パッケージは、複数の通信パッケージに対して死活監視を実行する。複数の通信パッケージに対する死活監視の結果が、複数の通信パッケージのすべてが正常であることを示す場合には、運用系の管理パッケージは、他の管理パッケージに異常があると判断する。複数の通信パッケージに対する死活監視の結果が、複数の通信パッケージのすべてが異常であることを示す場合には、運用系の管理パッケージは、運用系の管理パッケージに異常があると判断する。
【００２０】
上記によれば、複数の管理パッケージの間で死活監視を行い、各管理パッケージに異常が生じたどうかを正確に判断することができる。
【００２１】
（６）  好ましくは、複数の管理パッケージは、バックプレーンに対して活線挿抜に構成される。バックプレーンに接続済の管理パッケージは、バックプレーンに接続された新しい管理パッケージに対して、調整された死活監視のロジックを導入する。
【００２２】
これによれば、バックプレーンに新しく管理パッケージが接続された場合にも、接続済の管理パッケージと、新しくバックプレーンに接続された管理パッケージとの間で、死活監視のロジックを整合させることができる。
【００２３】
（７）  本発明の一態様に係る通信装置の監視方法は、管理パッケージと通信パッケージとを備えた通信装置の監視方法である。監視方法は、通信装置が起動されることにより、管理パッケージおよび通信パッケージの間で、死活監視のロジックを決定するステップと、通信装置の運用時において、決定された死活監視のロジックに従って、管理パッケージが通信パッケージに対して死活監視を行うステップとを備える。
【００２４】
上記によれば、正確に死活監視を実行可能な、通信装置を提供することができる。
【００２５】
[本発明の実施形態の詳細]
以下、各実施形態について図面を参照して詳しく説明する。なお、同一または相当する部分には同一の参照符号を付して、その説明を繰返さない。また、以下の説明において「パッケージ」との用語は、「ボード」あるいは「カード」と置き換えることができる。
【００２６】
図１は、本発明の実施の形態に係る通信装置１の構成の模式図である。図１に示すように、通信装置１は、筐体２に実装された複数のボードを含むラックマウント型の装置として実現可能である。複数のボードは、管理パッケージ１１，１２と、複数の通信パッケージ２１，２２，・・・，２ｎとを含む。図１に示した実施形態では、管理パッケージの数は２である。しかし管理パッケージの数は２より大きくてもよい。通信パッケージの数も１以上の任意の数とすることができる。
【００２７】
管理パッケージ１１，１２および通信パッケージ２１，２２，・・・，２ｎの各々は、バックプレーン３に接続される。なお、各パッケージは、いずれもバックプレーン３に活線挿抜が可能であるように構成されている。
【００２８】
通信パッケージ２１，２２，・・・，２ｎの各々は、通信回線（図示せず）に接続される。特に限定されないが、通信装置１はイーサネット（登録商標）装置であってもよい。あるいは、通信装置１はＰＯＮ（Passive Optical Network）装置であってもよい。
【００２９】
この実施形態では、複数の管理パッケージによって、通信装置１の管理機能が冗長化されている。管理パッケージ１１，１２の一方が運用系に割り当てられ、管理パッケージ１１，１２の他方が待機系に割り当てられる。以下の説明では、便宜上、管理パッケージ１１が運用系に割り当てられ、管理パッケージ１２の他方が待機系に割り当てられるものとする。
【００３０】
図２は、本実施の形態に係る通信装置１の概略的な構成を示したブロック図である。図２に示すように、管理パッケージ１１，１２および通信パッケージ２１，２２，・・・，２ｎは、バックプレーン３を介して相互に通信可能である。管理パッケージ１１，１２、および通信パッケージ２１，２２，・・・，２ｎは、それぞれ、通信のための部品１１Ａ，１２Ａ，２１Ａ，２２Ａ，・・・，２ｎＡを含む。部品１１Ａ，１２Ａ，２１Ａ，２２Ａ，・・・，２ｎＡの各々は、たとえばＬ２スイッチである。
【００３１】
さらに、管理パッケージ１１，１２および通信パッケージ２１，２２，・・・，２ｎは、それぞれ、ＣＰＵ１１Ｂ，１２Ｂ，２１Ｂ，２２Ｂ，２ｎＢを含む。各パッケージのＣＰＵは、死活監視を含む各種の処理を実行する。
【００３２】
図３は、本実施の形態に係る通信装置１における死活監視を概略的に説明する図である。管理パッケージ１１（運用系）は、自分以外の各ボード（管理パッケージ１２、および通信パッケージ２１，２２，・・・，２ｎ）の死活監視を行う。図３に示すように、管理パッケージ１１は、たとえば通信パッケージ２１の死活監視において、通信パッケージ２１に対してメッセージを送信する。通信パッケージ２１が正常である場合、通信パッケージ２１は、そのメッセージに対する応答を送信する。管理パッケージ１１は、通信パッケージ２１から応答を受信することにより、通信パッケージ２１が正常であると判断する。一方、管理パッケージ１１が通信パッケージ２１からの応答を受信できない場合には、管理パッケージ１１は、通信パッケージ２１が故障したと判断して、通信パッケージ２１の動作を停止させる。
【００３３】
しかしながら、上記の死活監視を実行するためには、いくつかの課題がある。まず、管理パッケージと通信パッケージとが異なる製造会社から供給された場合には、死活監視のロジックあるいは仕様が、管理パッケージと通信パッケージとで異なる可能性がある。この場合、管理パッケージと通信パッケージとの間で死活監視のロジックを整合させる必要がある。
【００３４】
また、管理パッケージと通信パッケージとの間で死活監視のロジックが整合していても、管理パッケージが故障した場合には、正確な死活監視ができない。このような課題を図４および図５を参照しながら説明する。
【００３５】
図４は、運用系の管理パッケージ１１に故障が発生した場合に通信パッケージ２１の死活監視に生じうる課題を説明する図である。図４に示すように、管理パッケージ１１と通信パッケージ２１との間で通信ができない状態が発生した場合、管理パッケージ１１は、通信パッケージ２１が故障したとみなす。
【００３６】
通信が不可となる原因としては、以下の可能性が考えられる。第１の可能性は、通信パッケージ２１の部品２１Ａ（または、部品２１Ｂ）が故障したという可能性である。第２の可能性は、部品２１Ａ（または、部品２１Ｂ）が正常であるものの、管理パッケージ１１の部品１１Ａが故障したという可能性である。なお、部品１１Ａ，２１Ａ（または、部品２１Ｂ）の両方がほぼ同時に故障する可能性は極めて低いと考えられるので、ここでは考慮しない。部品１１Ａが故障した場合には、通信パッケージ２１が正常にもかかわらず、管理パッケージ１１により通信パッケージ２１が停止させられる。
【００３７】
図５は、運用系の管理パッケージ１１に故障が発生した場合に待機系の管理パッケージ１２の死活監視に生じうる課題を説明する図である。図５に示す例では、管理パッケージ１１，１２は、ともに、監視相手の管理パッケージが故障していると判断する。
【００３８】
管理パッケージ１１の監視結果は誤りであり、管理パッケージ１２の監視結果は正しい。死活監視によって故障と判断された管理パッケージは、死活監視を実行した管理パッケージにより停止される。このため、管理パッケージ１１が管理パッケージ１２を停止させる可能性と、管理パッケージ１２が管理パッケージ１１を停止させる可能性との両方が考えられる。管理パッケージ１１，１２のどちらが停止するかは、管理パッケージ１１，１２の各々の処理のタイミングに依存する。管理パッケージ１２が停止した場合、故障した管理パッケージである管理パッケージ１１が死活監視を継続する。このため、正常な（通信が可能な）通信パッケージが管理パッケージ１１によって停止させられることが起こり得る。
【００３９】
図６は、本実施の形態に係る死活監視（通信装置１の監視方法）の概略を説明した第１の図である。図６に示すように、管理パッケージ１１，１２の各々は、通信パッケージに対する死活監視を実行する。管理パッケージ１１は、管理パッケージ１２に対して、管理パッケージ１２による死活監視の結果を要求する。管理パッケージ１２は、その要求に応じて管理パッケージ１１に、管理パッケージ１２による死活監視の結果を送信する。これにより、管理パッケージ１１は、管理パッケージ１２（待機系）による死活監視の結果を管理パッケージ１２から取得する。
【００４０】
管理パッケージ１１は、管理パッケージ１１による死活監視の結果および、管理パッケージ１２による死活監視の結果を用いて通信パッケージ２１〜２ｎの異常を判断する。たとえば、管理パッケージ１１，１２が同じ通信パッケージ（たとえば通信パッケージ２１）を異常と判断した場合には、管理パッケージ１１は、その通信パッケージが故障していると判断する。一方、管理パッケージ１１と管理パッケージ１２とで死活監視の結果が相違する場合、管理パッケージ１１は、管理パッケージ１２による死活監視の結果から、管理パッケージ１１自身が異常であるか、あるいは、監視対象の通信パッケージが異常であるかを判断する。
【００４１】
図７は、本実施の形態に係る死活監視（通信装置１の監視方法）の概略を説明した第２の図である。図７に示す例では、管理パッケージ１１は、管理パッケージ１２から死活監視の結果を取得できない。この場合、管理パッケージ１１は、複数の通信パッケージに対する自己の死活監視の結果を確認する。複数の通信パッケージのうち、死活監視において異常が検出された通信パッケージが１つのみである場合、管理パッケージ１１は、その通信パッケージが故障していると判断する。一方、死活監視において複数（あるいはすべて）の通信パッケージに異常が検出された場合、管理パッケージ１１は、自身が故障していると判断する。
【００４２】
図８は、本実施の形態に係る死活監視のフローの概略を示したフロー図である。図８に示すように、まず通信装置１が立ち上げられる。次に、管理パッケージ１１，１２の一方が運用系に割り当てられ、他方が待機系に割り当てられる。上述のように、たとえば管理パッケージ１１が運用系に割り当てられ、管理パッケージ１２が待機系に割り当てられる。
【００４３】
続いて、ステップＳ１０において、死活監視ロジックが調整される。管理パッケージ１１（運用系の管理パッケージ）は、管理パッケージ１２との間で死活監視ロジックを調整するとともに、通信パッケージ２１，２２，・・・２ｎの間で死活監視ロジックを調整する。
【００４４】
死活監視ロジックの調整は、たとえば、管理パッケージ１１の有する死活監視ロジックを、管理パッケージ１２および通信パッケージ２１，２２，・・・２ｎに導入することである。あるいは、死活監視ロジックの調整は、管理パッケージ１１，１２および通信パッケージ２１，２２，・・・２ｎの間で、死活監視ロジックを整合させることでもよい。死活監視ロジックを整合させることにより、汎用化されたプロトコルあるいはメッセージ等を死活監視に用いることができる。
【００４５】
通信装置１の運用が開始されると、ステップＳ１１において、管理パッケージ１１は、監視対象である他のパッケージに対して定期的監視を実行する。図８において、「パッケージ」を「pkg」と表記する（以後説明する図においても同様）。
【００４６】
ステップＳ１２において、管理パッケージ１１は監視結果に基づき、監視対象が異常に至っているかどうかを判断する。監視対象が正常に動作していると管理パッケージ１１が判断した場合（ステップＳ１２においてＮＯ）、処理がステップＳ１１に戻されて、監視が継続される。監視対象が異常に至っていると管理パッケージ１１が判断した場合（ステップＳ１２においてＹＥＳ）、処理はステップＳ１３に進む。
【００４７】
ステップＳ１３において、管理パッケージ１１は、全ての通信パッケージが異常、もしくは、異常被疑に至っているかどうかを確認する。ステップＳ１４において、管理パッケージ１１は、確認結果に基づいて、自身（管理パッケージ１１）の側に異常があるか、または、監視対象の側に異常があるかを判断する。管理パッケージ１１の側に異常がある場合には、管理パッケージ１２が待機系から運用系へと切り替わる。この場合、管理パッケージ１１は停止してもよく、運用系から待機系へと切り替わってもよい。一方、監視対象側に異常がある場合には、管理パッケージ１１は、その監視対象のパッケージを停止させる。ステップＳ１４の処理が終了すると、処理はステップＳ１１へと戻される。
【００４８】
次に、図８に示したフローチャートについて、死活監視の対象が通信パッケージである場合と、死活監視の対象が管理パッケージである場合とに分けて説明する。図９は、通信パッケージの死活監視のフローを示すフローチャートである。図９において、管理パッケージ１１および管理パッケージ１２は、それぞれ「管理pkg1」および「管理pkg2」と表記される。また、各ステップが、図８に示したいずれかのステップと対応していることを示すため、各ステップに対応する図８内のステップを括弧内に示す。
【００４９】
ステップＳ１０１（Ｓ１０に対応）において、管理パッケージ１１は、管理パッケージ１１と各通信パッケージとの間で使用する死活監視ロジックを調整する。調整される死活監視ロジックは、独自規定を含んでもよく、たとえばping、TCP keepalive、EtherOAM等を適用することができる。
【００５０】
ステップＳ１１１（Ｓ１１に対応）において、管理パッケージ１１，１２の各々から各通信パッケージの状態を定期的に監視する。
【００５１】
ステップＳ１２１（Ｓ１２に対応）において、管理パッケージ１１で、１番目の通信パッケージ（図９では「通信pkg1」と表記）が異常に至っていることを検出したかどうかを管理パッケージ１１が判断する。１番目の通信パッケージは、たとえば通信パッケージ２１である。
【００５２】
１番目の通信パッケージが正常に動作していると管理パッケージ１１が判断した場合（ステップＳ１２１においてＮＯ）、処理は、ステップＳ１１１に戻される。１番目の通信パッケージが異常に至っていると管理パッケージ１１が判断した場合（ステップＳ１２１においてＹＥＳ）、処理はステップＳ１３１に進む。
【００５３】
以後、ステップＳ１３１〜Ｓ１３３，Ｓ１４０〜Ｓ１４３の処理が実行される。ステップＳ１３１〜Ｓ１３３は、ステップＳ１３（図８）に含まれるステップであり、ステップＳ１４０〜Ｓ１４３は、ステップＳ１４（図８）に含まれるステップである。
【００５４】
ステップＳ１３１において、管理パッケージ１１で、管理パッケージ１２からみて１番目の通信パッケージが異常、もしくは、異常被疑に至っているかどうかが確認される。このために、管理パッケージ１１は、管理パッケージ１２による、１番目の通信パッケージに対する死活監視の結果を管理パッケージ１２に対して要求する。管理パッケージ１２が、この要求を受信できた場合、管理パッケージ１２は、管理パッケージ１１に、管理パッケージ１２の死活監視の結果を送信する。これにより、管理パッケージ１１は、管理パッケージ１２の死活監視の結果を取得する。管理パッケージ１１が、管理パッケージ１２から、管理パッケージ１２の死活監視の結果を取得できた場合、管理パッケージ１１は、死活監視の結果が、１番目の通信パッケージの異常、もしくは、異常被疑を示しているかどうかを確認する。
【００５５】
なお、本実施の形態では、各通信パッケージにおいて故障が発生しているかどうかを最終的に判断して、状態を変更するのは、運用系の管理パッケージである管理パッケージ１１のみである。管理パッケージ１２での状態検出においても、管理パッケージ１１が、管理パッケージ１２から管理パッケージ１２の監視結果を取得する。管理パッケージ１１は、その取得した監視結果に基づいて、各通信パッケージの状態を判断する。待機系の管理パッケージである管理パッケージ１２は、各通信パッケージとの間で死活監視のみを実施する。
【００５６】
一方、管理パッケージ１１の通信機能に異常がある場合（たとえば部品１１Ａが故障した場合）には、管理パッケージ１１が要求を発行できたとしても、管理パッケージ１２は、管理パッケージ１１からの要求を受信できない。管理パッケージ１１は、管理パッケージ１２からの応答を監視することにより、管理パッケージ１１と管理パッケージ１２との間の通信の異常を判定する。
【００５７】
図１０は、運用系の管理パッケージ（管理パッケージ１１）が待機系の管理パッケージ（管理パッケージ１２）からの応答を監視する状態を説明するための状態遷移図である。管理パッケージ１１は、たとえば１秒間隔のポーリングにより、管理パッケージ１２の応答を監視する。図１０に示した例は、管理パッケージ１１が管理パッケージ１２の応答を１０回待つ場合の例である。この例では、管理パッケージ１２からの応答があった場合、あるいは、監視失敗の回数が１〜４回までの場合には、状態が正常(Up)である。
【００５８】
監視失敗の回数が５回になると、状態は、異常(Down)被疑へと遷移する。監視失敗の回数が６〜９回までの場合、異常(Down)被疑の状態が継続される。一方、異常(Down)被疑の状態で監視が成功すれば、状態は正常(Up)へと戻る。
【００５９】
監視失敗の回数が１０回に達すると、状態は異常(Down)へと遷移する。以後、監視失敗の場合には、状態は異常(Down)のままである。一方、監視成功の場合には、状態は正常(Up)へと戻る。
【００６０】
図９に戻り、要求を発生させたにもかかわらず、管理パッケージ１１が、１番目の通信パッケージに対する死活監視の結果の情報を管理パッケージ１２から取得できない場合、処理はステップＳ１３２に進む。ステップＳ１３２において、管理パッケージ１１は、管理パッケージ１１の死活監視の結果において、２番目からｎ番目の通信パッケージ（通信pkg2〜n）の全てが異常、もしくは、異常被疑に至っているかどうかを確認する。すなわち１番目の通信パッケージ以外の残りの通信パッケージの全てが異常、もしくは、異常被疑に至っているかどうかが確認される。ステップＳ１３２の処理は、図７に示した処理に対応する。
【００６１】
２番目からｎ番目の通信パッケージの全てが正常（すなわち、１番目の通信パッケージのみ異常）である場合、処理は後述するステップＳ１４１に進む。２番目からｎ番目の通信パッケージの一部に異常、もしくは、異常被疑がある場合、処理はステップＳ１４０に進む。ステップＳ１４０では、実装の要件に応じて、ステップＳ１４１またはステップＳ１４２の処理が実行される。２番目からｎ番目の通信パッケージの全てが異常、もしくは、異常被疑である（すなわち、全ての通信パッケージが異常、もしくは、異常被疑である）場合には、処理は、ステップＳ１４２に進む。
【００６２】
なお、管理パッケージにおいて異常が検出されるとすると、通常は、１ポートのみ異常が検出されるか、または全ポートで異常が検出されるかのいずれかである。本実施の形態では、ポートの全数よりも少ない複数のポートにおいて異常が検出されることはレアケースとみなしている。また、本実施の形態では、２つの管理パッケージでそれぞれが別々のポートでの故障が発生する場合も、レアケースとみなしている。このような場合とは、たとえば管理パッケージ１１が、１番目および２番目の通信パッケージで異常、もしくは、異常被疑を検出し、管理パッケージ１２が、３番目および４番目の通信パッケージで異常、もしくは、異常被疑を検出する場合である。
【００６３】
ステップＳ１４１において、管理パッケージ１１は、１番目の通信パッケージが異常であると判断する。なお、この場合には、管理パッケージ１２も異常であると判断している。このパスは、管理パッケージ１１で管理パッケージ１２の状態が取得できていないケースである。管理パッケージ１１からみて、２番目からｎ番目の通信パッケージ（通信pkg2〜n）が正常とみえている（すなわち通信ができている）とすると、管理パッケージ１２の状態が取得できないのは管理パッケージ１２側に異常が発生しているためであると管理パッケージ１１が判断する。
【００６４】
ステップＳ１４２において、管理パッケージ１１は、管理パッケージ１１自身が異常であると判断する。この場合、管理パッケージ１１と管理パッケージ１２との間で運用系（ACT）と待機系（SBY）とが切り替えられる。すなわち管理パッケージ１２が待機系から運用系へと切り替わる。管理パッケージ１１は、運用系から待機系へと切り替わる。
【００６５】
ステップＳ１３１において、管理パッケージ１１が、要求により、管理パッケージ１２から、管理パッケージ１２の死活監視の結果を取得できた場合、管理パッケージ１１は、その死活監視の結果が、１番目の通信パッケージの異常を示しているかどうかを確認する。なお、この場合のステップＳ１３１の処理は、図６に示す処理に対応する。
【００６６】
死活監視の結果が、１番目の通信パッケージが異常、もしくは、異常被疑であることを示す場合（ステップＳ１３１においてＹＥＳ）、処理はステップＳ１４３に進む。ステップＳ１４３において、管理パッケージ１１は、１番目の通信パッケージが異常であると判断する。
【００６７】
ステップＳ１３１において、死活監視の結果が、１番目の通信パッケージが正常であることを示す場合（ステップＳ１３１においてＮＯ）、処理はステップＳ１３３に進む。ステップＳ１３３において、管理パッケージ１１は、管理パッケージ１２による死活監視の結果が、２番目からｎ番目の通信パッケージの各々が異常、もしくは、異常被疑に至っているかどうかを確認する。２番目からｎ番目の通信パッケージのうち、異常、もしくは、異常被疑に至っている通信パッケージがある場合には、処理はステップＳ１４３に進む。２番目からｎ番目の通信パッケージの中に、異常、もしくは、異常被疑に至っている通信パッケージがない場合には、処理はステップＳ１４２に進む。
【００６８】
ステップＳ１４１，Ｓ１４２，Ｓ１４３のいずれかのステップの処理が実行された場合には、全体の処理はステップＳ１１１に戻される。
【００６９】
図１１は、管理パッケージの死活監視のフローを示す第１のフローチャートである。図１２は、管理パッケージの死活監視のフローを示す第２のフローチャートである。図１１および図１２を参照して、ステップＳ１０Ａ（Ｓ１０に対応）において、管理パッケージ１１（管理pkg1）は、管理パッケージ１２（管理pkg2）との間で使用する死活監視ロジックを調整する。管理パッケージ１１の死活監視ロジックを採用する場合、処理は、ステップＳ１２Ａへと進む。管理パッケージ１２の死活監視ロジックを採用する場合、処理は、ステップＳ１２Ｂへと進む。
【００７０】
管理パッケージ１１，１２のどちらの死活監視ロジックを採用するかには、いくつかの方法を適用することができる。一実施形態では、管理パッケージ１１，１２の間で運用系および待機系が決定される。管理パッケージ１１，１２のうち、運用系に割り当てられた管理パッケージの死活監視ロジックが採用される。また、管理パッケージ１１，１２のうち、バックプレーン３に後からホットプラグで接続された新しい管理パッケージに、先にバックプレーン３に接続された管理パッケージの死活監視ロジックを導入してもよい。
【００７１】
ステップＳ１１Ａ（Ｓ１１に対応）において、管理パッケージ１１から管理パッケージ１２の状態を定期的に監視する。ステップＳ１２Ａ（Ｓ１２に対応）において、管理パッケージ１１で、管理パッケージ１２が異常に至っていることを検出したかどうかを管理パッケージ１１が判断する。管理パッケージ１２が正常に動作していると管理パッケージ１１が判断した場合（ステップＳ１２ＡにおいてＮＯ）、処理は、ステップＳ１１Ａに戻される。
【００７２】
管理パッケージ１２が異常に至っていると管理パッケージ１１が判断した場合（ステップＳ１２ＡにおいてＹＥＳ）、処理はステップＳ１３Ａ（Ｓ１３に対応）に進む。ステップＳ１３Ａにおいて、管理パッケージ１１で、１〜ｎ番目の通信パッケージ（通信パッケージpkg1〜n）が異常、もしくは、異常被疑に至っているかどうかが確認される。
【００７３】
全ての通信パッケージにおいて異常がないことが確認された場合、ステップＳ１４Ａにおいて、管理パッケージ１１は、管理パッケージ１２が異常であると判断する。一方、全ての通信パッケージが異常、もしくは、異常被疑であると確認された場合、ステップＳ１４Ｂにおいて、管理パッケージ１１は、管理パッケージ１１自身が異常であると判断する。この場合、管理パッケージ１１と管理パッケージ１２との間で運用系（ACT）と待機系（SBY）とが切り替えられる。
【００７４】
一部の通信パッケージにおいて異常、もしくは、異常被疑が確認された場合、ステップＳ１４０Ａにおいて、管理パッケージ１１は、実装の要件に応じて、ステップＳ１４ＡおよびステップＳ１４Ｂのいずれかの処理を実行する。ステップＳ１４Ａの処理またはステップＳ１４Ｂの処理が実行されると、全体の処理がステップＳ１１Ａに戻される。
【００７５】
管理パッケージ１２の死活監視ロジックを採用する場合、処理は、ステップＳ１２Ｂ（Ｓ１２に対応）へと進む。以後の処理は、管理パッケージ１２によって実行される点を除いては、ステップＳ１２Ａ〜Ｓ１４Ｂの処理と基本的に同じである。ステップＳ１２Ｂにおいて、管理パッケージ１２で、管理パッケージ１１が異常に至っていることを検出したかどうかを管理パッケージ１２が判断する。管理パッケージ１１が正常に動作していると管理パッケージ１２が判断した場合（ステップＳ１２ＡにおいてＮＯ）、処理は、ステップＳ１１Ｂに戻される。管理パッケージ１１が異常に至っていると管理パッケージ１２が判断した場合（ステップＳ１２ＢにおいてＹＥＳ）、処理はステップＳ１３Ｂ（Ｓ１３に対応）に進む。
【００７６】
ステップＳ１３Ｂにおいて、管理パッケージ１２で、１〜ｎ番目の通信パッケージが異常、もしくは、異常被疑に至っているかどうかが確認される。全ての通信パッケージにおいて異常、もしくは、異常被疑がないことが確認された場合、ステップＳ１４Ｃにおいて、管理パッケージ１２は、管理パッケージ１１が異常であると判断する。この場合、管理パッケージ１１と管理パッケージ１２との間で運用系（ACT）と待機系（SBY）とが切り替えられる。
【００７７】
一方、全ての通信パッケージが異常であると確認された場合、ステップＳ１４Ｄにおいて、管理パッケージ１２は、管理パッケージ１２自身が異常であると判断する。この場合、管理パッケージ１１は運用系（ACT）のままであり、管理パッケージ１２は、待機系（SBY）のままである。
【００７８】
一部の通信パッケージにおいて異常、もしくは、異常被疑が確認された場合、ステップＳ１４０Ｂにおいて、管理パッケージ１２は、実装の要件に応じて、ステップＳ１４ＣおよびステップＳ１４Ｄのいずれかの処理を実行する。ステップＳ１４Ｃの処理またはステップＳ１４Ｄの処理が実行されると、全体の処理がステップＳ１１Ｂに戻される。
【００７９】
本実施の形態では、管理パッケージ間、あるいは運用系の管理パッケージと各通信パッケージとの間で、使用する死活監視ロジックが調整される。死活監視には、バックプレーン部品の型番（固有値）、あるいは、その部品のステータスを監視する方法もある。しかしながら、ＥｏＬ（End of Life）等の理由による部品変更、あるいは、リビジョン（Revision）の変更のために、型番（固有値）あるいはステータスの読み方が変わってしまう可能性がある。本実施の形態によれば、管理パッケージと通信パッケージとを組み合わせた通信装置において、使用する死活監視ロジックを調整することにより正確に死活監視を実行することができる。また、新しい管理パッケージをバックプレーン３に接続する場合（ホットプラグの場合）にも、新しい管理パッケージの死活監視のロジックを、調整済の死活監視のロジックに整合させることができる。
【００８０】
本実施の形態では、死活監視において応答がないパッケージが発生した場合に、管理パッケージは、相手側のダウンとすぐに判断するのではなく、相手と自分のどちらで故障が発生しているかを判断する。これにより正確な死活監視を実現できる。具体的には、管理パッケージは、以下に説明する死活監視を実行する。
【００８１】
運用側の管理パッケージは、待機側の管理パッケージで行っている死活監視の情報をみることで、故障が、自分（管理パッケージ）と、相手（通信パッケージ）とのどちらの側で発生しているかを判断する。特定の相手だけとの通信だけが失敗するような故障について、待機側の管理パッケージの死活監視の結果を参照することにより、相手と自分のどちらに故障が発生しているかを正確に判断することができる（図６を参照）。
【００８２】
管理パッケージ間で通信ができないために、死活監視の情報を待機系の管理パッケージから取得できない場合、運用系の管理パッケージは、複数の通信パッケージに対する死活監視の情報を取得する。その情報のみに基づいて、運用系の管理パッケージは、故障が自分（管理パッケージ）および相手（通信パッケージ）のどちらの側で発生しているかを判断する（図７を参照）。
【００８３】
本実施の形態では、管理パッケージが冗長化される。本実施の形態によれば、正確な死活監視が実施可能である。したがって、運用系の管理パッケージが故障した場合にも、運用系の管理パッケージは自身に故障が生じたことを判断できる。これにより、待機系の管理パッケージが故障した管理パッケージに代わり、通信装置の管理機能を実現できる。また、管理パッケージ間の切り替えも速やかに実行できる。
【００８４】
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は上記した実施の形態ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味、および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００８５】
１  通信装置
２  筐体
３  バックプレーン
１１，１２  管理パッケージ
２１，２２，２ｎ  通信パッケージ
１１Ａ，１２Ａ，２１Ａ，２２Ａ，２ｎＡ  部品
１１Ｂ，１２Ｂ，２１Ｂ，２２Ｂ，２ｎＢ  ＣＰＵ
Ｓ１０〜Ｓ１４，Ｓ１０１，Ｓ１１１，Ｓ１２１，Ｓ１３１〜Ｓ１３３，Ｓ１４０〜Ｓ１４３，Ｓ１４０Ａ，Ｓ１１Ａ，Ｓ１１Ｂ，Ｓ１２Ａ，Ｓ１２Ｂ，Ｓ１３Ａ，Ｓ１３Ｂ，Ｓ１４Ａ，Ｓ１４Ｂ，Ｓ１４Ｃ，Ｓ１４Ｄ  ステップ
【図１】
2020065136.tif 000003
【図２】
2020065136.tif 000004
【図３】
2020065136.tif 000005
【図４】
2020065136.tif 000006
【図５】
2020065136.tif 000007
【図６】
2020065136.tif 000008
【図７】
2020065136.tif 000009
【図８】
2020065136.tif 000010
【図９】
2020065136.tif 000011
【図１０】
2020065136.tif 000012
【図１１】
2020065136.tif 000013
【図１２】
2020065136.tif 000014