JP2004363946A - 故障措置システム、及び、故障要因特定方法 - Google Patents

Abstract

【課題】ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定する。
【解決手段】ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を構成情報ＤＢＡ６及び履歴ＤＢＡ１０に記憶しておく。ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を、構成情報検索部Ａ５が作成する。故障要因定義情報に基づいて、作成した表の各項目に推定ルール実行部Ａ４が重み付けを行う。この重み付け結果に基づいて、故障している装置を特定する。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は故障措置システム、及び、故障要因特定方法に関し、特に、通信ネットワークを構成する複数の通信装置において発生した故障に関する通知を総合的に判断し、適切な故障要因解析を行う故障措置システム、及び、故障要因特定方法に関する。
【０００２】
【従来の技術】
従来技術において、通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークは、図９に示されているように構成されている。すなわち、同図において、ネットワークを構成する通信装置Ｎ１−１〜Ｎ１−３及びＮ１−１’〜Ｎ１−３’並びにＮ２と、これら通信装置にそれぞれ接続される通信端末Ｔ１、Ｔ２と、通信媒体を介して各通信装置に接続され、通信装置からの通知（メッセージ）を受信し、または通信装置に指示（コマンド）を送出する通信装置対応のオペレーションサポートシステムを構成するＯＰＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）装置Ｏ１〜Ｏ４と、通信ネットワーク全体を管理する汎用計算機からなるオペレーションサポートシステムを構成するＯＰＳ装置Ｏ６とを含んで構成されている。
【０００３】
さらに、同図に示されている通信ネットワークには、入出力装置Ｄ１〜Ｄ４が接続されている。これら入出力装置Ｄ１〜Ｄ４は、ＯＰＳ装置Ｏ６に接続され、オペレーションシステムで受信したメッセージを保守者に対して表示し、または、保守者からのコマンドをオペレーションシステムに入力するために設けられている。
なお、本明細書でいう「故障」は、装置の故障の他、回線の障害等も含むものとする。
【０００４】
ここで、図１０には、ＯＰＳ装置Ｏ６の内部構成例が示されている。同図において、ＯＰＳ装置Ｏ６は、メッセージの変換等、外部とのインタフェースをなすＯＰＳアダプタ部Ａ１と、メッセージの分析を行うメッセージ分析処理部Ａ２と、後述する推定ルールが記憶されている推定ルール記憶部Ａ３と、推定ルールを実行する推定ルール実行部Ａ４と、ネットワーク構成情報の検索を行う構成情報検索部Ａ５と、通信ネットワークを構成している通信装置についての構成情報を記憶する構成情報ＤＢ（Ｄａｔａ Ｂａｓｅ）Ａ６と、故障要因を特定しそれに対応する適切な措置を指示する要因特定・故障措置部Ａ７と、故障回復のための動作シナリオが記憶されている動作シナリオ記憶部Ａ８と、ソフトウェアによって所定の動作を実現するための動作部品群Ａ９と、故障措置結果の履歴を記憶する履歴ＤＢ（Ｄａｔａ Ｂａｓｅ）Ａ１０とを含んで構成されている。
【０００５】
動作部品群Ａ９は、「トラヒック収集」、「診断・試験」、「装置切替・初期設定」、「トラブルチケット発行」等の動作を実現するためのソフトウェアによる部品である。これらの動作は例示にすぎず、その他の必要な動作を実現するためのソフトウェアによる部品が、動作部品群Ａ９に含まれているものとする。
動作シナリオ記憶部Ａ８に記憶されている動作シナリオが、この動作部品群Ａ９のうちの少なくとも１つを動作させることによって、回復措置が自動的に行われる。
【０００６】
次に、以上のような構成からなるシステムの動作例について説明する。ここでは、一例として、上記通信ネットワーク内の通信装置同士の間のどこかで故障が発生した場合について、その故障に対する措置について説明する。
故障が発生すると、その旨を示すメッセージがＯＰＳ装置Ｏ６に通知される。ここでは、故障通知メッセージは、ＯＰＳ装置Ｏ１乃至Ｏ４経由で、ＯＰＳ装置Ｏ６に通知される。この通知されたメッセージは、ＯＰＳアダプタ部Ａ１において、ＯＰＳ装置Ｏ６で処理可能な情報に変換される。変換されたメッセージは、すべてＯＰＳ装置Ｏ６内のメッセージ分析処理部Ａ２で内容が分析される。この分析によって、メッセージ種別、装置名、発生時刻等の情報が抽出される。メッセージ分析処理部Ａ２では、メッセージ種別毎に対応の要否を判定し、対応要の場合には対応する推定ルール記憶部Ａ３を参照して推定ルールを決定する。
【０００７】
推定ルール実行部Ａ４では、発生時刻の前後ｔ秒間（ｔ：シナリオに記述した変化可能な値）で、当該推定ルール内に予め定義された関連メッセージ発生有無を確認する。メッセージがある場合には、構成情報検索部Ａ５と連携して、装置名をキー情報として構成情報ＤＢＡ６を検索することにより、そのメッセージが対向通信装置で発生しているかどうかや、上位装置でメッセージが発生しているかどうかを特定し、関連メッセージ発生パターンを分析することで、主要因推定を行い、動作シナリオを決定する。決定された動作シナリオを実行することにより、原則として、保守者の介在なしに故障から回復することができる。
【０００８】
ここで、故障要因推定ルールの一例が図１１及び図１２に示されている。
次に、推定ルール及び動作シナリオの例について図１１及び図１２を参照して説明する。本例においては、図１１に示されているように推定処理を行った後、図１２に示されているように回復に必要な措置を行う。なお、本例では、リンク番号「００１」、装置名「Ｎ１−１」において故障が発生し、故障発生時刻は「ｙｙｍｍｄｄｈｈｍｍｓｓ」（年月日時分秒それぞれ２桁で表現される）である。
【０００９】
まず、図１１において、同一通信装置Ｎ１−１にシステムダウンのメッセージがあるか判断する（ステップＳ１０１）。そのメッセージがあれば図１２に移行し、通信装置Ｎ１−１対応の再開対応シナリオを起動する（ステップＳ２０１）。
図１１に戻り、そのメッセージがなければ、次に、同一通信装置Ｎ１−１に上位装置（収容パッケージ）故障メッセージがあるか判断する（ステップＳ１０２）。そのメッセージがあれば図１２に移行し、通信装置Ｎ１−１対応の装置診断シナリオを起動する（ステップＳ２０２）。
【００１０】
図１１に戻り、そのメッセージがなければ、次に、同一通信装置Ｎ１−１に他リンクの同一種類のメッセージがあるか判断する（ステップＳ１０３）。そのメッセージがあれば更に対向通信装置にシステムダウンメッセージがあるか判断する（ステップＳ１０４）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応の再開対応シナリオを起動する（ステップＳ２０３）。
【００１１】
図１１に戻り、そのメッセージがなければ、次に、対向通信装置に上位装置（収容パッケージ）故障メッセージがあるか判断する（ステップＳ１０５）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応の故障対応シナリオを起動する（ステップＳ２０４）。
図１１に戻り、そのメッセージがなければ、次に、対向通信装置側でリンク故障発生のメッセージがあるか判断する（ステップＳ１０６）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応のリンク故障シナリオを起動する（ステップＳ２０５）。
【００１２】
ステップＳ２０１、Ｓ２０３、Ｓ２０４、Ｓ２０５の各シナリオを起動した場合、その後に措置は終了となる。ステップＳ２０２のシナリオを起動した場合、その後にトラブルチケット発行シナリオを起動し、パッケージ交換を保守者に依頼する（ステップＳ２１０）。
また、ステップＳ１０６において、対向通信装置側でリンク故障発生のメッセージがない場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す（ステップＳ２０９）。
【００１３】
ステップＳ１０３において、同一通信装置Ｎ１−１に他リンクの同一種類のメッセージがない場合、図１２に移行し、通信装置Ｎ１−１対応のリンク故障シナリオを起動する。この場合、最初にリンク閉塞・解除によるリンク初期設定で回復したか判断する（ステップＳ２０６）。回復すれば措置は終了となる。
ステップＳ２０６において、回復しない場合、リンク試験結果が正常か判断する（ステップＳ２０７）。リンク試験結果が正常である場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す（ステップＳ２０９）。一方、リンク試験結果が正常でない場合、トラブルチケット発行シナリオを起動し、保守者の対応を促す（ステップＳ２０８）。
【００１４】
以上、図１１及び図１２を参照して説明したように、要因特定・故障措置部Ａ７では、動作シナリオに従って、トラヒック情報収集による影響把握や、診断・試験による要因特定を自動的に実施し、故障要因を特定する。そして、故障要因特定後は、対象装置に対して、初期設定や、系変更・装置切り替え等の故障措置を実施する。トラヒック情報収集や、診断・試験、装置切り替え等の個々の動作は、上述した動作部品群Ａ９として予め準備されている。また、動作部品群を用いた動作が、動作シナリオによって記述されている。そして、要因特定・故障措置部が対象通信装置を指定することにより、対象通信装置へのコマンドを実行することができる。
【００１５】
故障措置の結果、ハード装置の交換作業のような、保守者の対応が必要となった場合には、上述したように入出力装置Ｄ１からトラブルチケットを発行する。この場合、入出力装置Ｄ１の画面にその旨を表示して保守者に報知しても良いし、プリントアウトすることによって保守者に報知しても良い。
また、動作シナリオが決定できなかった場合や、故障回復ができなかった場合にも、上述したように保守者の対応を促すトラブルチケットを通知する。最後に、一連メッセージが通知されることのトリガーとなったメッセージ、決定した動作シナリオ、コマンド実行結果、故障措置結果を履歴ＤＢＡ１０に格納し、故障措置は完了する。
【００１６】
なお、ＯＰＳ装置Ｏ６のシステム保守者は、定期的に履歴ＤＢＡ１０内を統計分析し、推定ルール及び動作シナリオの正常性を確認するとともに、動作に不具合がある場合は、テキストベースでの修正を可能とする。すなわち、本例のシナリオは、上述したように、テキストファイルによって構成されているので、シナリオの変更が必要になった場合でも、その内容を容易に修正したり、シナリオ自体を新規に追加したりすることができる。
【００１７】
以上のように本システムは、通信ネットワークを構成する複数の通信装置を通信媒体を介して管理する汎用計算機を構成要素としたオペレーションシステムにおける通信ネットワークの監視・保守運用を行うシステムである。そして、通信装置から通知される自律メッセージの情報を利用し、メッセージの関連付けを行い故障の要因を分析し、自動措置を行うものである。
【００１８】
本システムでは、個々の通信装置から故障発生時に通知されるメッセージの発生パターンを予め具備し、メッセージ発生パターンによって、予め配備した、措置パターンの中から適切な措置手順を決定する。メッセージの発生パターン及び、措置手順は、予めテキストベースのシナリオとして用意され、メッセージが変更になった場合でも、容易に対応できる。このことにより、故障発生直後に保守者の作業無しに自動で故障要因の分析、故障措置が行える。
【００１９】
以上説明した故障要因推定ルールを作成するためには、運用実績や運用経験が必要となる。
ここで、故障事象と故障要因とをマトリクス表にして重み付けを行い、高い診断精度を得る技術が、特許文献１に記載されている。
また、上述したような故障措置を行うための従来技術として、非特許文献１に記載されているものがある。非特許文献１においては、各装置より出力されるメッセージをある一カ所にて集中的に受信し、メッセージの出力順を意識して関連するメッセージを待ち受けて相関を取る方法が記載されている。
【００２０】
【特許文献１】
特開平１１−１１９８２３号公報（要約、［０００５］）
【非特許文献１】
ＣＤ−ＲＯＭ「電子情報通信学会２００２年ソサイエティ大会講演論文集」、社団法人電子情報通信学会、平成１４年８月２０日、講演番号：Ｂ−６−７６、「通信移動網オペレーションにおける故障措置自動化の検討」
【００２１】
【発明が解決しようとする課題】
従来の故障要因特定方法で用いる故障要因推定ルールは、図１１及び図１２に示されている運用実績に基づく故障対応フローを基に作成する必要があり、順次通信装置の正常性を判断しながら故障箇所を絞りこむ必要があった。
その場合、既に運用実績があり、故障対応方法がパターン化されている場合には、正確な故障箇所の特定が可能である。しかし、新サービス提供に伴い導入される新規通信装置にあわせて故障要因特定方法を実装する場合には、運用実績がない。このため、想定に基づいて故障要因推定ルールを作成する必要があり、故障自動化ターゲットの絞込みや、その故障対応方法の正確さ、開発効率の面で問題があった。上述した非特許文献１にも同様の問題がある。
【００２２】
なお、上述した特許文献１は、故障対応方法がパターン化されていることが前提となるので、上記の問題を解決することはできない。
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的はネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定することのできる故障措置システム、及び、故障要因特定方法を提供することである。
【００２３】
【課題を解決するための手段】
本発明の請求項１による故障措置システムは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を記憶する記憶手段（後述する構成情報ＤＢＡ６及び履歴ＤＢＡ１０に対応）と、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成手段（後述する構成情報検索部Ａ５に対応）と、前記故障要因定義情報に基づいて、前記表作成手段によって作成した表の各項目に重み付けを行う重み付け手段（後述する推定ルール実行部Ａ４に対応）と、を含み、前記重み付け手段による重み付け結果に基づいて故障している装置を特定するようにしたことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【００２４】
本発明の請求項２による故障措置システムは、請求項１において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた待ち合わせ時間内において前記重み付けを行うことを特徴とする。こうすることにより、装置故障によって複数の故障通知メッセージが発生することがあり、そのような場合でも所定待ち合わせ時間内に受信したメッセージを用いて重み付けを行うことができる。
【００２５】
本発明の請求項３による故障措置システムは、請求項１又は２において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた該メッセージに関連するメッセージを受信した場合に限り、前記重み付けを行うことを特徴とする。こうすることにより、関連ある複数の故障通知メッセージを用いて重み付けを行うことができる。
【００２６】
本発明の請求項４による故障措置システムは、請求項１乃至３のいずれか１項において、前記重み付け手段による重み付け結果が所定閾値を超えたとき該重み付けを終了して故障している装置を特定することを特徴とする。こうすることにより、所定待ち合わせ時間とは関係なく、所定閾値を超えた場合には、故障している装置を直ちに特定することができる。
【００２７】
本発明の請求項５による故障要因特定方法は、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法であって、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、前記故障要因定義情報に基づいて、前記表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、前記重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含むことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【００２８】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
（本システムの構成）
図１は本発明による故障措置システムの実施の一形態を示すブロック図である。同図に示されているように、本実施形態による故障措置システムは、部分Ａが従来の構成（図１０）とは異なる。すなわち、図１中のメッセージ分析部Ａ２は、故障通知メッセージの分析を行う。また、構成情報検索部Ａ５は、構成情報ＤＢＡ６から構成情報を読出して、重み付けのためのマトリクス表を作成する。つまり、マトリクス表は予め作成しておくのではなく、故障通知メッセージの受信を契機に作成されることになる。
【００２９】
推定ルール実行部Ａ４は、故障要因定義Ａ４−１を読出し、その定義の内容に従って重み付け処理を行う。ここでは、作成したマトリクス表の各項目に、故障要因定義Ａ４−１に従ってポイントを加算することにより、重み付け処理を行う。この重み付け処理は予め定められた一定時間が経過するまでに受信した故障通知メッセージに応答して順次行う。
【００３０】
一定時間の経過後、推定ルール実行部Ａ４による重み付け処理結果（ポイント加算結果）は、履歴ＤＢＡ１０に格納される。
以上のように、ポイント加算結果によって重み付けを行うことで、要因特定・故障措置部Ａ７が故障要因、すなわち故障した装置を特定することができる。この要因特定・故障措置部Ａ７は、特定した装置を他の装置に告知するための故障特定メッセージを作成する。
【００３１】
要因特定・故障措置部Ａ７によって故障特定メッセージが作成されると、そのメッセージは入力装置Ｄ１に表示される。この表示は、ディスプレイ画面への表示に限らず、表示内容を印刷出力しても良い。表示に限らず、何らかの形式でオペレータに告知すれば良い。例えば、表示に代えて、又は表示と共に内容を音声出力しても良い。
なお、動作部品群Ａ９は、「診断・試験」、「装置切替・初期設定」等の動作を実現するためのソフトウェアによる部品である。
【００３２】
（故障要因定義）
本システムでは後述するように重み付け処理を行うことで、故障発生箇所を特定する。この重み付け処理に用いる故障要因の定義が図２に示されている。同図においては、メッセージの種別ごとに、ポイント加算箇所及び、加算ポイントが数値で示されている。
本例では、メッセージの種別として、「リンク断」を示すメッセージＭ００１、「パッケージ故障」を示すメッセージＭ００２、「装置異常」を示すメッセージＭ００３、「装置初期設定」を示すメッセージＭ００４、「電源異常」を示すメッセージＭ００５、「呼処理異常」を示すメッセージＭ００６、がある。
【００３３】
また、本例では、ポイント加算箇所として、「通信装置」、「電源ユニット」、「通信制御部（ソフトウェア）」、「ユニット」、「パッケージ」、「回線」、がある。ただし、これらに限定されるわけではなく、ネットワークを構成する各通信装置それぞれを構成する各部分がポイント加算箇所となる。
同図に示されているように、「リンク断」を示すメッセージＭ００１が送られてきた場合、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「１」が加算される。
また、「パッケージ故障」を示すメッセージＭ００２が送られてきた場合、「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算される。
【００３４】
さらにまた、「装置異常」を示すメッセージＭ００３が送られてきた場合、「通信装置」、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「１」が加算される。
同様に、「装置初期設定」を示すメッセージＭ００４が送られてきた場合、「電源ユニット」、「通信制御部（ソフトウェア）」にポイント「１」が、「ユニット」にポイント「２」が、それぞれ加算される。「電源異常」を示すメッセージＭ００５が送られてきた場合、「電源ユニット」にポイント「２」が加算される。「呼処理異常」を示すメッセージＭ００６が送られてきた場合、「通信制御部（ソフトウェア）」にポイント「１」が加算される。
【００３５】
なお、図２には、各メッセージＭ００１〜Ｍ００６の待ち合わせ時間（最大値）が示されている。本例では、メッセージＭ００１、Ｍ００２及びＭ００３の待ち合わせ時間がそれぞれ２０秒、メッセージＭ００４の待ち合わせ時間が３０秒、メッセージＭ００５の待ち合わせ時間が６０秒、メッセージＭ００６の待ち合わせ時間が１０秒、である。この待ち合わせ時間内において、上記のポイント加算による重み付け処理が行われる。
【００３６】
さらに、同図には、各メッセージＭ００１〜Ｍ００６に関連する関連メッセージが示されている。本例では、メッセージＭ００１に関連するメッセージは、メッセージＭ００１、Ｍ００２及びＭ００４である。また、メッセージＭ００２に関連するメッセージは、メッセージＭ００１及びＭ００４である。さらに、メッセージＭ００３に関連するメッセージは、メッセージＭ００３及びＭ００４である。同様に、メッセージＭ００４に関連するメッセージはメッセージＭ００１、Ｍ００２、Ｍ００３及びＭ００５、メッセージＭ００５に関連するメッセージはメッセージＭ００４である。メッセージＭ００６に関連するメッセージはなし（存在しない）である。
関連するメッセージとして定義されていない場合等においては、後述するように、別の故障要因と判断される。
【００３７】
（装置構成情報）
構成情報ＤＢＡ６に記憶されている構成情報の例が図３に示されている。同図は、「Ｎ１−１」という通信装置についての構成情報の例を示す図である。同図においては、「Ｎ１−１」という通信装置内に、「信号処理ユニット」というユニットが含まれており、さらに、そのユニット内に「信号処理パッケージ００」及び「信号処理パッケージ０１」というパッケージが含まれていることが示されている。
【００３８】
「信号処理パッケージパッケージ００」には、リンク番号「０００」から「００７」までのリンクが設けられている。リンク番号「０００」、「００１」、「００２」のリンクは対向通信装置名が「通信装置Ｎ２」であり、回線番号はそれぞれ「１」、「２」、「３」である。リンク番号「００３」、「００４」のリンクは対向通信装置名が「通信装置Ｎ１−２」であり、回線番号はそれぞれ「１」、「２」である。リンク番号「００５」、「００６」、「００７」のリンクは対向通信装置名が「通信装置Ｎ１−３」であり、回線番号はそれぞれ「１」、「２」、「３」である。
【００３９】
「信号処理パッケージパッケージ０１」には、リンク番号「００８」から「０１５」までのリンクが設けられている。リンク番号「００８」、「００９」、「０１０」のリンクは対向通信装置名が「通信装置Ｎ２」であり、回線番号はそれぞれ「４」、「５」、「６」である。リンク番号「０１１」、「０１２」のリンクは対向通信装置名が「通信装置Ｎ１−２」であり、回線番号はそれぞれ「３」、「４」である。リンク番号「０１３」、「０１４」、「０１５」のリンクは対向通信装置名が「通信装置Ｎ１−３」であり、回線番号はそれぞれ「４」、「５」、「６」である。
【００４０】
以上のように、装置構成情報は、ネットワークを構成している各通信装置それぞれに対応して用意されており、それら構成情報が構成情報ＤＢＡ６に記憶されている。この装置構成情報は、テキスト形式で構成されているので、部分的に変更、追加、及び、削除が可能であるので、ネットワークに含まれている装置すなわち装置構成に変更、追加、削除があった場合でも容易に対応することができ、故障要因を特定することができる。
【００４１】
（マトリクス表の作成と重み付け処理）
本システムでは、故障通知メッセージを受信したことに応答してマトリクス表を作成し、この作成したマトリクス表を用いて重み付け処理を行う。以下、このマトリクス表の作成及びそれを用いた重み付け処理について説明する。
ネットワークを構成している装置から送られてきた故障通知メッセージにおいて、故障発生装置として「Ｎ１−１」、メッセージ種別として「Ｍ００１」、メッセージ内容として「リンク断 リンク番号０００」が含まれている場合、以下のようにマトリクス表（以下、単に「表」と表現することがある）が作成される。すなわち、故障の発生した通信装置Ｎ１−１に対応した、図３に示されている装置構成情報について、リンク番号「０００」をキーにして検索し、この検索結果に基づいて図４（ａ）に示されているような表を作成する。
【００４２】
同図（ａ）においては、故障の発生装置「Ｎ１−１」、メッセージ種別「Ｍ０００１」について、作成される重み付け処理のための表が示されている。同図（ａ）に示されている表には、通信装置「Ｎ１−１」、「Ｎ２」それぞれについて「通信装置」、「ユニット」、「パッケージ」の各項目があり、さらに「回線＃１」の項目がある。なお、故障が発生した装置に対向する装置に関する情報が、装置構成情報に含まれている場合、対向する装置側の構成情報を収集することで、上記のような表を作成する。
【００４３】
このように作成した表を用いて重み付け処理が行われる。この重み付け処理は、図２を参照して表中の各項目にポイントを加算することで、行われる。ポイントを加算することにより、図４（ｂ）に示されている状態になる。すなわち、図２を参照すると、メッセージＭ０００１については、「ユニット」、「パッケージ」、「回線」それぞれに「１」ポイントが加算されるため、図４（ｂ）に示されているように、「Ｎ１−１」の「ユニット」及び「パッケージ」が「＋１」ポイント、「回線＃１」が「＋１」ポイントになる。
【００４４】
この場合、受信したメッセージのメッセージ種別が「Ｍ００１」であるので、図２に定義されているように、待ち合わせ時間２０秒が経過するまでに、関連メッセージ「Ｍ００１」、「Ｍ００２」、「Ｍ００４」のいずれかを受信した場合に、上記のようなポイント加算が行われる。
待ち合わせ時間２０秒が経過するまでに、故障発生装置として「Ｎ１−２」、メッセージ種別として「Ｍ００１」、メッセージ内容として「リンク断 リンク番号０００」が含まれている故障通知メッセージを受信した場合、以下のように処理される。すなわち、故障の発生した通信装置Ｎ１−２に対応した装置構成情報（図示せず）について、リンク番号「０００」をキーにして検索し、この検索結果に基づいて表を作成する。
【００４５】
故障通知メッセージによっては、故障装置に対向する装置に関する情報が含まれている場合もある。そのような対向装置に関する情報が含まれている場合、対向装置についての装置構成情報を収集する。次に、この故障発生装置に関して収集した情報又は対向装置に関して収集した情報について、上記の表において既に定義されているか（つまり表中にその項目があるか）判定が行われる。
【００４６】
この場合、同図（ｂ）の状態において、対向装置である通信装置Ｎ２の項目が表に存在するので、その項目は新たに作成されない。これに対し、故障発生装置である通信装置Ｎ１−２の項目は表に存在しないので、その項目が新たに作成される。この結果、図４（ｃ）に示されているように、項目が追加された表が作成されることになる。
【００４７】
そして、作成した表を用いて重み付け処理が行われる。今回受信したメッセージ種別が「Ｍ００１」であるので、図２を参照すると、メッセージＭ０００１については、「ユニット」、「パッケージ」、「回線」それぞれに「１」ポイントが加算されるため、図４（ｄ）に示されているように、「Ｎ１−２」の「ユニット」及び「パッケージ」が「＋１」ポイント、「回線＃２」が「＋１」ポイントになる。
【００４８】
以下同様に、待ち合わせ時間内に故障通知メッセージを受信した場合、定義されていない項目が表に追加され、重み付け処理が行われる。重み付け処理の完了した状態の例が図５に示されている。同図においては、障害の発生した「発生装置」として、「Ｎ１−１」、「Ｎ１−２」、「Ｎ１−３」、「Ｎ２」が示されている。
【００４９】
通信装置Ｎ１−１において障害が発生し、リンク断を示すメッセージＭ００１が通信装置Ｎ１−１から送られてきた場合、上述した故障要因定義（図２参照）に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「１」が加算されることになる。本例では、通信装置Ｎ１−１の「ユニット」、「パッケージ」及び「回線＃１」にそれぞれポイント「１」が加算される。リンク断を示すメッセージＭ００１が通信装置Ｎ１−２、Ｎ１−３からそれぞれ送られてきた場合も同様に、通信装置Ｎ１−２の「ユニット」、「パッケージ」及び「回線＃２」、通信装置Ｎ１−３の「ユニット」、「パッケージ」及び「回線＃３」にそれぞれポイント「１」が加算される。
【００５０】
また、通信装置Ｎ２において障害が発生し、パッケージ故障を示すＭ００２が通信装置Ｎ２から送られてきた場合、上述した故障要因定義（図２参照）に従い、「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算されることになる。本例では、通信装置Ｎ２の「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算される。
【００５１】
さらに、リンク断を示すメッセージＭ００１が通信装置Ｎ２から３回送られてきた場合、上述した故障要因定義（図２参照）に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「１」が加算されることになる。本例では、通信装置Ｎ２の「ユニット」及び「パッケージ」にポイント「１」が、３回加算される。さらに、本例では、「回線＃１」、「回線＃２」、「回線＃３」にそれぞれポイント「１」が加算される。
【００５２】
以上のように、故障通知メッセージの受信を契機に、図３に示されている各通信装置の構成情報（通信装置内のユニット、パッケージ、回線収容情報等）が構成情報ＤＢＡ６から読出される。そして、メッセージ発生元通信装置の構成情報と、メッセージ内情報を元に読出した対向の通信装置とを関連付けた情報として、図５に示されている重み付け結果の表が図示せぬメモリ上に作成される。この図５に示されている重み付け結果に基づいて、故障発生箇所が特定されるのである。
【００５３】
（故障箇所の特定）
以上のようにポイントを加算して重み付けした結果が、図６に示されている。同図は、ポイントを加算して重み付けした結果を概念的に示したものである。同図を参照すると、通信装置Ｎ２はポイントが「＋１」、通信装置Ｎ２内のユニットはポイントが「＋３」、そのユニット内のパッケージ００はポイントが「＋５」である。また、通信装置Ｎ１−１内のユニット、通信装置Ｎ１−２内のユニット、通信装置Ｎ１−３内のユニットは、それぞれポイントが「＋１」である。それら通信装置Ｎ１−１、Ｎ１−２、Ｎ１−３内の各パッケージ００はポイントが「＋１」である。
【００５４】
さらに、通信装置Ｎ２のユニット内のパッケージ００の「リンク０００」と通信装置Ｎ１−１のユニット内のパッケージ００の「リンク０００」とを接続している回線＃１はポイントが「＋２」である。通信装置Ｎ２のユニット内のパッケージ００の「リンク００１」と通信装置Ｎ１−２のユニット内のパッケージ００の「リンク０００」とを接続している回線＃２はポイントが「＋２」である。通信装置Ｎ２のユニット内のパッケージ００の「リンク００２」と通信装置Ｎ１−３のユニット内のパッケージ００の「リンク００１」とを接続している回線＃３はポイントが「＋２」である。
【００５５】
以上の結果から、通信装置Ｎ２内のユニット内のパッケージ００がポイント「＋５」で最も重み付け値が大きい。このため、このパッケージ００が故障発生箇所と特定することができる。
以上のように、待ち合わせ時間の経過後、重み付け値が最も大きい部分を故障発生箇所として特定する。ただし、待ち合わせ時間の経過前であっても、重み付け値が所定の閾値を超えた場合は、その重み付け値が超えた部分を故障発生箇所として特定する。
【００５６】
（本システム全体の動作）
図１に戻り、上記の構成からなる本実施形態の故障措置システムの動作について説明する。
（１）故障通知メッセージは、ＯＰＳ装置Ｏ１、Ｏ２からＯＰＳアダプタ部Ａ１経由で、ＯＰＳ装置Ｏ６に通知される。この故障通知メッセージは、図７に示されているように、故障の発生した発生装置名７１、そのメッセージのメッセージ種別７２、メッセージ内容７３、故障の発生時刻７４、を含んで構成されている。
【００５７】
（２）ＯＰＳ装置Ｏ６に通知された故障通知メッセージは、すべてメッセージ分析処理部Ａ２でその内容が分析される。これにより、上述した、発生装置名、メッセージ種別、メッセージ内容、発生時刻の各情報が抽出される。
（３）構成情報検索部Ａ５は、故障通知メッセージに含まれている、発生装置名に基づいて、関連する構成情報（図３参照）を、構成情報ＤＢＡ６から読出すことにより、重み付け処理のためのマトリクス表（図４及び図５参照）を作成する。
（４）推定ルール実行部Ａ４は、故障通知メッセージに含まれている、メッセージ種別に基づいて、予め設定してある故障要因定義Ａ４−１（図２参照）を読出す。
【００５８】
（５）上記（４）において説明した故障要因定義の内容にしたがって、構成情報内の装置（故障被疑箇所）に対して、ポイントを加算していく。このようにポイントを加算することで、故障被疑箇所に重み付け処理を行う。
（６）予め故障要因定義に設定してあるメッセージ受信の待ち合わせ時間が経過するまでの間に通知されるメッセージに対して同様の処理を繰り返す。ただし、重み付け値が、予め定められた閾値を超えた場合は、処理は終了となる。
（７）上記（４）でメッセージ種別が関連しない場合は、別の故障要因と判断して、上記と同様の処理を実行する。また、メッセージ種別が関連した場合であっても、上記（３）において発生装置名が関連なかった場合においても、別の故障要因と判断して、上記と同様の処理を実行する。
【００５９】
（８）待ち合わせ時間経過後に、上記（５）のポイント加算結果、すなわち重み付け処理結果を分析し、重み付け値の高い装置に対して順次、コマンドを用いた正常性の確認、及び、故障措置を実行する。
（９）上記（８）の結果及び、ポイントを加算したメッセージは履歴として履歴ＤＢに保存して管理する。こうすることにより、ポイント加算対象や、ポイントの大小を分析可能とし、故障要因定義の適正化を行うことができる。
【００６０】
以上のように本システムによれば、通信装置の故障が発生した場合、複数のメッセージを関連付けた故障要因特定を行うことができる。また、故障要因特定論理は、通信装置のメッセージ設計論理に基づいて定義できるため、新規通信装置の導入やネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的な故障要因特定を実現できる。
【００６１】
（まとめ）
以上のように本システムでは、通信ネットワークを構成する複数の通信装置構成情報を管理し、通信装置から通知されるメッセージ毎に発生箇所を分析し、故障発生装置の故障箇所にポイントを加算していくことで、故障箇所の絞りこみを行い、一定時間に発生する複数のメッセージの処理を実施した後で、ポイントの最上位または、一定レベルを超えている箇所に対して、故障の対応を実施している。これにより、複数の通信装置から通知されるメッセージを一元的に処理し、適切な故障要因のしぼりこみが、効率的に実現できる。
なお、要因特定時に故障箇所にポイントを加算したメッセージを一覧として表示することで、テキストファイルに記載した故障要因特定ロジックを適切に変更できるので、加算する対象、及び、そのポイントを、本システムの端末により変更することができる。
【００６２】
（故障要因特定方法）
上述した故障措置システムにおいては、以下のような故障要因特定方法が採用されている。この故障要因特定方法について、図８を参照して説明する。同図に示されているように、故障通知メッセージを受信するまでは待ち状態であり（ステップＳ８００）、故障通知メッセージを受信した場合に、必要な情報が収集される（ステップＳ８００→Ｓ８０１）。
【００６３】
情報を収集した結果、以前受信したメッセージと関連するか判断され、関連しない場合は、ステップＳ８００に戻る（ステップＳ８０２→Ｓ８００）。
次に、既にマトリクス表が作成され、表中に項目が含まれているか判断される（ステップＳ８０３）。マトリクス表が作成されていない場合、又は作成されていても項目が存在しない場合、マトリクス表又はその項目を作成する（ステップＳ８０３→Ｓ８０４）。その後、重み付け処理に移行する（ステップＳ８０４→Ｓ８０５）。マトリクス表が既に作成され、かつ、項目が存在する場合、そのまま重み付け処理に移行する（ステップＳ８０３→Ｓ８０５）。
【００６４】
重み付け処理においては、上述したように、表の各項目にポイントを加算する（ステップＳ８０５）。この重み付け処理の結果、重み付け値が予め定められた閾値を超えた場合、処理は終了となり、故障装置が特定される（ステップＳ８０６→Ｓ８０８）。
以上の処理は、重み付け値が予め定められた閾値を超えない限り、予め定められた待ち合わせ時間を経過するまで行われる（ステップＳ８０６→Ｓ８０７→Ｓ８００…）。待ち合わせ時間が経過した後、上記と同様に、処理は終了となり、故障装置が特定される（ステップＳ８０７→Ｓ８０８）。
【００６５】
このように、上述した故障措置システムでは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法が実現されている。そして、この故障要因特定方法は、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、故障要因定義情報に基づいて、表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含んでいる。
【００６６】
要するに本方法では、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、表の各項目に重み付けを行い、その重み付け結果に基づいて故障している装置を特定するので、故障した装置を容易に特定できるのである。
【００６７】
【発明の効果】
以上説明したように、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、その表の各項目に重み付けを行った結果を用いることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できるという効果がある。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【図面の簡単な説明】
【図１】本発明による故障措置システムの実施の一形態を示すブロック図である。
【図２】重み付け処理に用いる故障要因の定義を示す図である。
【図３】構成情報ＤＢに記憶されている構成情報の例を示す図である。
【図４】マトリクス表の作成過程を説明する図である。
【図５】重み付け処理の完了した状態の例を示す図である。
【図６】重み付けした結果を示す図である。
【図７】故障通知メッセージの構成例を示す図である。
【図８】本発明による故障要因特定方法を示すフローチャートである。
【図９】通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークの例を示す図である。
【図１０】図９中のＯＰＳ装置の内部構成例を示すブロック図である。
【図１１】故障要因推定ルールの一例を示すフローチャートである。
【図１２】故障要因推定ルールの一例を示すフローチャートである。
【符号の説明】
Ａ１ ＯＰＳアダプタ部
Ａ２ メッセージ分析処理部
Ａ３ 推定ルール
Ａ４ 推定ルール実行部
Ａ４−１ 故障要因定義
Ａ５ 構成情報検索部
Ａ６ 構成情報ＤＢ
Ａ７ 要因特定・故障措置部
Ａ８ 動作シナリオ
Ａ９ 動作部品群
Ａ１０ 履歴ＤＢ
Ｄ１〜Ｄ４ 入出力装置
Ｎ１―１〜Ｎ１―３、
Ｎ２、Ｎ１―１’〜Ｎ１―３’ 通信装置
Ｏ１〜Ｏ４、Ｏ６ ＯＰＳ装置
Ｔ１、Ｔ２ 通信端末

Claims (5)

1. ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を記憶する記憶手段と、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成手段と、前記故障要因定義情報に基づいて、前記表作成手段によって作成した表の各項目に重み付けを行う重み付け手段と、を含み、前記重み付け手段による重み付け結果に基づいて故障している装置を特定するようにしたことを特徴とする故障措置システム。
2. 前記重み付け手段は、前記故障通知メッセージ毎に予め定められた待ち合わせ時間内において前記重み付けを行うことを特徴とする請求項１記載の故障措置システム。
3. 前記重み付け手段は、前記故障通知メッセージ毎に予め定められた該メッセージに関連するメッセージを受信した場合に限り、前記重み付けを行うことを特徴とする請求項１又は２記載の故障措置システム。
4. 前記重み付け手段による重み付け結果が所定閾値を超えたとき該重み付けを終了して故障している装置を特定することを特徴とする請求項１乃至３のいずれか１項に記載の故障措置システム。
5. ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法であって、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、前記故障要因定義情報に基づいて、前記表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、前記重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含むことを特徴とする故障要因特定方法。

Images