JP2004363946A

JP2004363946A - Failure handling system and failure factor specifying method

Info

Publication number: JP2004363946A
Application number: JP2003159943A
Authority: JP
Inventors: Kosei Ono; 孝生大野; Satoshi Oyamada; 聡小山田; Nobuhiro Tanigawa; 延広谷川
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2003-06-04
Filing date: 2003-06-04
Publication date: 2004-12-24
Anticipated expiration: 2023-06-04
Also published as: JP3682778B2

Abstract

<P>PROBLEM TO BE SOLVED: To easily specify which of devices constituting a network gets out of order in such a case. <P>SOLUTION: Device constitution information representing the devices constituting the network and respective parts constituting those devices and fault factor definition information showing values of weighting for fault factors are stored in a constitution information DB A6 and a history DB A10. In response to reception of a fault notice message sent form a device constituting the network, a table for weighting is generated by a constitution information retrieval part A5 according to the device constitution information. According to the fault factor definition information, an estimation rule performance part A4 weights respective items of the generated table according to the fault factor definition information. According to weighting results, a device which gets out of order is specified. Consequently, if one of the devices constituting the network gets out of order, the device which gets out of order can easily be specified. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は故障措置システム、及び、故障要因特定方法に関し、特に、通信ネットワークを構成する複数の通信装置において発生した故障に関する通知を総合的に判断し、適切な故障要因解析を行う故障措置システム、及び、故障要因特定方法に関する。
【０００２】
【従来の技術】
従来技術において、通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークは、図９に示されているように構成されている。すなわち、同図において、ネットワークを構成する通信装置Ｎ１−１〜Ｎ１−３及びＮ１−１’〜Ｎ１−３’並びにＮ２と、これら通信装置にそれぞれ接続される通信端末Ｔ１、Ｔ２と、通信媒体を介して各通信装置に接続され、通信装置からの通知（メッセージ）を受信し、または通信装置に指示（コマンド）を送出する通信装置対応のオペレーションサポートシステムを構成するＯＰＳ（ＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ）装置Ｏ１〜Ｏ４と、通信ネットワーク全体を管理する汎用計算機からなるオペレーションサポートシステムを構成するＯＰＳ装置Ｏ６とを含んで構成されている。
【０００３】
さらに、同図に示されている通信ネットワークには、入出力装置Ｄ１〜Ｄ４が接続されている。これら入出力装置Ｄ１〜Ｄ４は、ＯＰＳ装置Ｏ６に接続され、オペレーションシステムで受信したメッセージを保守者に対して表示し、または、保守者からのコマンドをオペレーションシステムに入力するために設けられている。
なお、本明細書でいう「故障」は、装置の故障の他、回線の障害等も含むものとする。
【０００４】
ここで、図１０には、ＯＰＳ装置Ｏ６の内部構成例が示されている。同図において、ＯＰＳ装置Ｏ６は、メッセージの変換等、外部とのインタフェースをなすＯＰＳアダプタ部Ａ１と、メッセージの分析を行うメッセージ分析処理部Ａ２と、後述する推定ルールが記憶されている推定ルール記憶部Ａ３と、推定ルールを実行する推定ルール実行部Ａ４と、ネットワーク構成情報の検索を行う構成情報検索部Ａ５と、通信ネットワークを構成している通信装置についての構成情報を記憶する構成情報ＤＢ（ＤａｔａＢａｓｅ）Ａ６と、故障要因を特定しそれに対応する適切な措置を指示する要因特定・故障措置部Ａ７と、故障回復のための動作シナリオが記憶されている動作シナリオ記憶部Ａ８と、ソフトウェアによって所定の動作を実現するための動作部品群Ａ９と、故障措置結果の履歴を記憶する履歴ＤＢ（ＤａｔａＢａｓｅ）Ａ１０とを含んで構成されている。
【０００５】
動作部品群Ａ９は、「トラヒック収集」、「診断・試験」、「装置切替・初期設定」、「トラブルチケット発行」等の動作を実現するためのソフトウェアによる部品である。これらの動作は例示にすぎず、その他の必要な動作を実現するためのソフトウェアによる部品が、動作部品群Ａ９に含まれているものとする。
動作シナリオ記憶部Ａ８に記憶されている動作シナリオが、この動作部品群Ａ９のうちの少なくとも１つを動作させることによって、回復措置が自動的に行われる。
【０００６】
次に、以上のような構成からなるシステムの動作例について説明する。ここでは、一例として、上記通信ネットワーク内の通信装置同士の間のどこかで故障が発生した場合について、その故障に対する措置について説明する。
故障が発生すると、その旨を示すメッセージがＯＰＳ装置Ｏ６に通知される。ここでは、故障通知メッセージは、ＯＰＳ装置Ｏ１乃至Ｏ４経由で、ＯＰＳ装置Ｏ６に通知される。この通知されたメッセージは、ＯＰＳアダプタ部Ａ１において、ＯＰＳ装置Ｏ６で処理可能な情報に変換される。変換されたメッセージは、すべてＯＰＳ装置Ｏ６内のメッセージ分析処理部Ａ２で内容が分析される。この分析によって、メッセージ種別、装置名、発生時刻等の情報が抽出される。メッセージ分析処理部Ａ２では、メッセージ種別毎に対応の要否を判定し、対応要の場合には対応する推定ルール記憶部Ａ３を参照して推定ルールを決定する。
【０００７】
推定ルール実行部Ａ４では、発生時刻の前後ｔ秒間（ｔ：シナリオに記述した変化可能な値）で、当該推定ルール内に予め定義された関連メッセージ発生有無を確認する。メッセージがある場合には、構成情報検索部Ａ５と連携して、装置名をキー情報として構成情報ＤＢＡ６を検索することにより、そのメッセージが対向通信装置で発生しているかどうかや、上位装置でメッセージが発生しているかどうかを特定し、関連メッセージ発生パターンを分析することで、主要因推定を行い、動作シナリオを決定する。決定された動作シナリオを実行することにより、原則として、保守者の介在なしに故障から回復することができる。
【０００８】
ここで、故障要因推定ルールの一例が図１１及び図１２に示されている。
次に、推定ルール及び動作シナリオの例について図１１及び図１２を参照して説明する。本例においては、図１１に示されているように推定処理を行った後、図１２に示されているように回復に必要な措置を行う。なお、本例では、リンク番号「００１」、装置名「Ｎ１−１」において故障が発生し、故障発生時刻は「ｙｙｍｍｄｄｈｈｍｍｓｓ」（年月日時分秒それぞれ２桁で表現される）である。
【０００９】
まず、図１１において、同一通信装置Ｎ１−１にシステムダウンのメッセージがあるか判断する（ステップＳ１０１）。そのメッセージがあれば図１２に移行し、通信装置Ｎ１−１対応の再開対応シナリオを起動する（ステップＳ２０１）。
図１１に戻り、そのメッセージがなければ、次に、同一通信装置Ｎ１−１に上位装置（収容パッケージ）故障メッセージがあるか判断する（ステップＳ１０２）。そのメッセージがあれば図１２に移行し、通信装置Ｎ１−１対応の装置診断シナリオを起動する（ステップＳ２０２）。
【００１０】
図１１に戻り、そのメッセージがなければ、次に、同一通信装置Ｎ１−１に他リンクの同一種類のメッセージがあるか判断する（ステップＳ１０３）。そのメッセージがあれば更に対向通信装置にシステムダウンメッセージがあるか判断する（ステップＳ１０４）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応の再開対応シナリオを起動する（ステップＳ２０３）。
【００１１】
図１１に戻り、そのメッセージがなければ、次に、対向通信装置に上位装置（収容パッケージ）故障メッセージがあるか判断する（ステップＳ１０５）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応の故障対応シナリオを起動する（ステップＳ２０４）。
図１１に戻り、そのメッセージがなければ、次に、対向通信装置側でリンク故障発生のメッセージがあるか判断する（ステップＳ１０６）。そのメッセージがあれば図１２に移行し、対向通信装置Ｎ２対応のリンク故障シナリオを起動する（ステップＳ２０５）。
【００１２】
ステップＳ２０１、Ｓ２０３、Ｓ２０４、Ｓ２０５の各シナリオを起動した場合、その後に措置は終了となる。ステップＳ２０２のシナリオを起動した場合、その後にトラブルチケット発行シナリオを起動し、パッケージ交換を保守者に依頼する（ステップＳ２１０）。
また、ステップＳ１０６において、対向通信装置側でリンク故障発生のメッセージがない場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す（ステップＳ２０９）。
【００１３】
ステップＳ１０３において、同一通信装置Ｎ１−１に他リンクの同一種類のメッセージがない場合、図１２に移行し、通信装置Ｎ１−１対応のリンク故障シナリオを起動する。この場合、最初にリンク閉塞・解除によるリンク初期設定で回復したか判断する（ステップＳ２０６）。回復すれば措置は終了となる。
ステップＳ２０６において、回復しない場合、リンク試験結果が正常か判断する（ステップＳ２０７）。リンク試験結果が正常である場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す（ステップＳ２０９）。一方、リンク試験結果が正常でない場合、トラブルチケット発行シナリオを起動し、保守者の対応を促す（ステップＳ２０８）。
【００１４】
以上、図１１及び図１２を参照して説明したように、要因特定・故障措置部Ａ７では、動作シナリオに従って、トラヒック情報収集による影響把握や、診断・試験による要因特定を自動的に実施し、故障要因を特定する。そして、故障要因特定後は、対象装置に対して、初期設定や、系変更・装置切り替え等の故障措置を実施する。トラヒック情報収集や、診断・試験、装置切り替え等の個々の動作は、上述した動作部品群Ａ９として予め準備されている。また、動作部品群を用いた動作が、動作シナリオによって記述されている。そして、要因特定・故障措置部が対象通信装置を指定することにより、対象通信装置へのコマンドを実行することができる。
【００１５】
故障措置の結果、ハード装置の交換作業のような、保守者の対応が必要となった場合には、上述したように入出力装置Ｄ１からトラブルチケットを発行する。この場合、入出力装置Ｄ１の画面にその旨を表示して保守者に報知しても良いし、プリントアウトすることによって保守者に報知しても良い。
また、動作シナリオが決定できなかった場合や、故障回復ができなかった場合にも、上述したように保守者の対応を促すトラブルチケットを通知する。最後に、一連メッセージが通知されることのトリガーとなったメッセージ、決定した動作シナリオ、コマンド実行結果、故障措置結果を履歴ＤＢＡ１０に格納し、故障措置は完了する。
【００１６】
なお、ＯＰＳ装置Ｏ６のシステム保守者は、定期的に履歴ＤＢＡ１０内を統計分析し、推定ルール及び動作シナリオの正常性を確認するとともに、動作に不具合がある場合は、テキストベースでの修正を可能とする。すなわち、本例のシナリオは、上述したように、テキストファイルによって構成されているので、シナリオの変更が必要になった場合でも、その内容を容易に修正したり、シナリオ自体を新規に追加したりすることができる。
【００１７】
以上のように本システムは、通信ネットワークを構成する複数の通信装置を通信媒体を介して管理する汎用計算機を構成要素としたオペレーションシステムにおける通信ネットワークの監視・保守運用を行うシステムである。そして、通信装置から通知される自律メッセージの情報を利用し、メッセージの関連付けを行い故障の要因を分析し、自動措置を行うものである。
【００１８】
本システムでは、個々の通信装置から故障発生時に通知されるメッセージの発生パターンを予め具備し、メッセージ発生パターンによって、予め配備した、措置パターンの中から適切な措置手順を決定する。メッセージの発生パターン及び、措置手順は、予めテキストベースのシナリオとして用意され、メッセージが変更になった場合でも、容易に対応できる。このことにより、故障発生直後に保守者の作業無しに自動で故障要因の分析、故障措置が行える。
【００１９】
以上説明した故障要因推定ルールを作成するためには、運用実績や運用経験が必要となる。
ここで、故障事象と故障要因とをマトリクス表にして重み付けを行い、高い診断精度を得る技術が、特許文献１に記載されている。
また、上述したような故障措置を行うための従来技術として、非特許文献１に記載されているものがある。非特許文献１においては、各装置より出力されるメッセージをある一カ所にて集中的に受信し、メッセージの出力順を意識して関連するメッセージを待ち受けて相関を取る方法が記載されている。
【００２０】
【特許文献１】
特開平１１−１１９８２３号公報（要約、［０００５］）
【非特許文献１】
ＣＤ−ＲＯＭ「電子情報通信学会２００２年ソサイエティ大会講演論文集」、社団法人電子情報通信学会、平成１４年８月２０日、講演番号：Ｂ−６−７６、「通信移動網オペレーションにおける故障措置自動化の検討」
【００２１】
【発明が解決しようとする課題】
従来の故障要因特定方法で用いる故障要因推定ルールは、図１１及び図１２に示されている運用実績に基づく故障対応フローを基に作成する必要があり、順次通信装置の正常性を判断しながら故障箇所を絞りこむ必要があった。
その場合、既に運用実績があり、故障対応方法がパターン化されている場合には、正確な故障箇所の特定が可能である。しかし、新サービス提供に伴い導入される新規通信装置にあわせて故障要因特定方法を実装する場合には、運用実績がない。このため、想定に基づいて故障要因推定ルールを作成する必要があり、故障自動化ターゲットの絞込みや、その故障対応方法の正確さ、開発効率の面で問題があった。上述した非特許文献１にも同様の問題がある。
【００２２】
なお、上述した特許文献１は、故障対応方法がパターン化されていることが前提となるので、上記の問題を解決することはできない。
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的はネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定することのできる故障措置システム、及び、故障要因特定方法を提供することである。
【００２３】
【課題を解決するための手段】
本発明の請求項１による故障措置システムは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を記憶する記憶手段（後述する構成情報ＤＢＡ６及び履歴ＤＢＡ１０に対応）と、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成手段（後述する構成情報検索部Ａ５に対応）と、前記故障要因定義情報に基づいて、前記表作成手段によって作成した表の各項目に重み付けを行う重み付け手段（後述する推定ルール実行部Ａ４に対応）と、を含み、前記重み付け手段による重み付け結果に基づいて故障している装置を特定するようにしたことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【００２４】
本発明の請求項２による故障措置システムは、請求項１において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた待ち合わせ時間内において前記重み付けを行うことを特徴とする。こうすることにより、装置故障によって複数の故障通知メッセージが発生することがあり、そのような場合でも所定待ち合わせ時間内に受信したメッセージを用いて重み付けを行うことができる。
【００２５】
本発明の請求項３による故障措置システムは、請求項１又は２において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた該メッセージに関連するメッセージを受信した場合に限り、前記重み付けを行うことを特徴とする。こうすることにより、関連ある複数の故障通知メッセージを用いて重み付けを行うことができる。
【００２６】
本発明の請求項４による故障措置システムは、請求項１乃至３のいずれか１項において、前記重み付け手段による重み付け結果が所定閾値を超えたとき該重み付けを終了して故障している装置を特定することを特徴とする。こうすることにより、所定待ち合わせ時間とは関係なく、所定閾値を超えた場合には、故障している装置を直ちに特定することができる。
【００２７】
本発明の請求項５による故障要因特定方法は、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法であって、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、前記故障要因定義情報に基づいて、前記表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、前記重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含むことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【００２８】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
（本システムの構成）
図１は本発明による故障措置システムの実施の一形態を示すブロック図である。同図に示されているように、本実施形態による故障措置システムは、部分Ａが従来の構成（図１０）とは異なる。すなわち、図１中のメッセージ分析部Ａ２は、故障通知メッセージの分析を行う。また、構成情報検索部Ａ５は、構成情報ＤＢＡ６から構成情報を読出して、重み付けのためのマトリクス表を作成する。つまり、マトリクス表は予め作成しておくのではなく、故障通知メッセージの受信を契機に作成されることになる。
【００２９】
推定ルール実行部Ａ４は、故障要因定義Ａ４−１を読出し、その定義の内容に従って重み付け処理を行う。ここでは、作成したマトリクス表の各項目に、故障要因定義Ａ４−１に従ってポイントを加算することにより、重み付け処理を行う。この重み付け処理は予め定められた一定時間が経過するまでに受信した故障通知メッセージに応答して順次行う。
【００３０】
一定時間の経過後、推定ルール実行部Ａ４による重み付け処理結果（ポイント加算結果）は、履歴ＤＢＡ１０に格納される。
以上のように、ポイント加算結果によって重み付けを行うことで、要因特定・故障措置部Ａ７が故障要因、すなわち故障した装置を特定することができる。この要因特定・故障措置部Ａ７は、特定した装置を他の装置に告知するための故障特定メッセージを作成する。
【００３１】
要因特定・故障措置部Ａ７によって故障特定メッセージが作成されると、そのメッセージは入力装置Ｄ１に表示される。この表示は、ディスプレイ画面への表示に限らず、表示内容を印刷出力しても良い。表示に限らず、何らかの形式でオペレータに告知すれば良い。例えば、表示に代えて、又は表示と共に内容を音声出力しても良い。
なお、動作部品群Ａ９は、「診断・試験」、「装置切替・初期設定」等の動作を実現するためのソフトウェアによる部品である。
【００３２】
（故障要因定義）
本システムでは後述するように重み付け処理を行うことで、故障発生箇所を特定する。この重み付け処理に用いる故障要因の定義が図２に示されている。同図においては、メッセージの種別ごとに、ポイント加算箇所及び、加算ポイントが数値で示されている。
本例では、メッセージの種別として、「リンク断」を示すメッセージＭ００１、「パッケージ故障」を示すメッセージＭ００２、「装置異常」を示すメッセージＭ００３、「装置初期設定」を示すメッセージＭ００４、「電源異常」を示すメッセージＭ００５、「呼処理異常」を示すメッセージＭ００６、がある。
【００３３】
また、本例では、ポイント加算箇所として、「通信装置」、「電源ユニット」、「通信制御部（ソフトウェア）」、「ユニット」、「パッケージ」、「回線」、がある。ただし、これらに限定されるわけではなく、ネットワークを構成する各通信装置それぞれを構成する各部分がポイント加算箇所となる。
同図に示されているように、「リンク断」を示すメッセージＭ００１が送られてきた場合、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「１」が加算される。
また、「パッケージ故障」を示すメッセージＭ００２が送られてきた場合、「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算される。
【００３４】
さらにまた、「装置異常」を示すメッセージＭ００３が送られてきた場合、「通信装置」、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「１」が加算される。
同様に、「装置初期設定」を示すメッセージＭ００４が送られてきた場合、「電源ユニット」、「通信制御部（ソフトウェア）」にポイント「１」が、「ユニット」にポイント「２」が、それぞれ加算される。「電源異常」を示すメッセージＭ００５が送られてきた場合、「電源ユニット」にポイント「２」が加算される。「呼処理異常」を示すメッセージＭ００６が送られてきた場合、「通信制御部（ソフトウェア）」にポイント「１」が加算される。
【００３５】
なお、図２には、各メッセージＭ００１〜Ｍ００６の待ち合わせ時間（最大値）が示されている。本例では、メッセージＭ００１、Ｍ００２及びＭ００３の待ち合わせ時間がそれぞれ２０秒、メッセージＭ００４の待ち合わせ時間が３０秒、メッセージＭ００５の待ち合わせ時間が６０秒、メッセージＭ００６の待ち合わせ時間が１０秒、である。この待ち合わせ時間内において、上記のポイント加算による重み付け処理が行われる。
【００３６】
さらに、同図には、各メッセージＭ００１〜Ｍ００６に関連する関連メッセージが示されている。本例では、メッセージＭ００１に関連するメッセージは、メッセージＭ００１、Ｍ００２及びＭ００４である。また、メッセージＭ００２に関連するメッセージは、メッセージＭ００１及びＭ００４である。さらに、メッセージＭ００３に関連するメッセージは、メッセージＭ００３及びＭ００４である。同様に、メッセージＭ００４に関連するメッセージはメッセージＭ００１、Ｍ００２、Ｍ００３及びＭ００５、メッセージＭ００５に関連するメッセージはメッセージＭ００４である。メッセージＭ００６に関連するメッセージはなし（存在しない）である。
関連するメッセージとして定義されていない場合等においては、後述するように、別の故障要因と判断される。
【００３７】
（装置構成情報）
構成情報ＤＢＡ６に記憶されている構成情報の例が図３に示されている。同図は、「Ｎ１−１」という通信装置についての構成情報の例を示す図である。同図においては、「Ｎ１−１」という通信装置内に、「信号処理ユニット」というユニットが含まれており、さらに、そのユニット内に「信号処理パッケージ００」及び「信号処理パッケージ０１」というパッケージが含まれていることが示されている。
【００３８】
「信号処理パッケージパッケージ００」には、リンク番号「０００」から「００７」までのリンクが設けられている。リンク番号「０００」、「００１」、「００２」のリンクは対向通信装置名が「通信装置Ｎ２」であり、回線番号はそれぞれ「１」、「２」、「３」である。リンク番号「００３」、「００４」のリンクは対向通信装置名が「通信装置Ｎ１−２」であり、回線番号はそれぞれ「１」、「２」である。リンク番号「００５」、「００６」、「００７」のリンクは対向通信装置名が「通信装置Ｎ１−３」であり、回線番号はそれぞれ「１」、「２」、「３」である。
【００３９】
「信号処理パッケージパッケージ０１」には、リンク番号「００８」から「０１５」までのリンクが設けられている。リンク番号「００８」、「００９」、「０１０」のリンクは対向通信装置名が「通信装置Ｎ２」であり、回線番号はそれぞれ「４」、「５」、「６」である。リンク番号「０１１」、「０１２」のリンクは対向通信装置名が「通信装置Ｎ１−２」であり、回線番号はそれぞれ「３」、「４」である。リンク番号「０１３」、「０１４」、「０１５」のリンクは対向通信装置名が「通信装置Ｎ１−３」であり、回線番号はそれぞれ「４」、「５」、「６」である。
【００４０】
以上のように、装置構成情報は、ネットワークを構成している各通信装置それぞれに対応して用意されており、それら構成情報が構成情報ＤＢＡ６に記憶されている。この装置構成情報は、テキスト形式で構成されているので、部分的に変更、追加、及び、削除が可能であるので、ネットワークに含まれている装置すなわち装置構成に変更、追加、削除があった場合でも容易に対応することができ、故障要因を特定することができる。
【００４１】
（マトリクス表の作成と重み付け処理）
本システムでは、故障通知メッセージを受信したことに応答してマトリクス表を作成し、この作成したマトリクス表を用いて重み付け処理を行う。以下、このマトリクス表の作成及びそれを用いた重み付け処理について説明する。
ネットワークを構成している装置から送られてきた故障通知メッセージにおいて、故障発生装置として「Ｎ１−１」、メッセージ種別として「Ｍ００１」、メッセージ内容として「リンク断リンク番号０００」が含まれている場合、以下のようにマトリクス表（以下、単に「表」と表現することがある）が作成される。すなわち、故障の発生した通信装置Ｎ１−１に対応した、図３に示されている装置構成情報について、リンク番号「０００」をキーにして検索し、この検索結果に基づいて図４（ａ）に示されているような表を作成する。
【００４２】
同図（ａ）においては、故障の発生装置「Ｎ１−１」、メッセージ種別「Ｍ０００１」について、作成される重み付け処理のための表が示されている。同図（ａ）に示されている表には、通信装置「Ｎ１−１」、「Ｎ２」それぞれについて「通信装置」、「ユニット」、「パッケージ」の各項目があり、さらに「回線＃１」の項目がある。なお、故障が発生した装置に対向する装置に関する情報が、装置構成情報に含まれている場合、対向する装置側の構成情報を収集することで、上記のような表を作成する。
【００４３】
このように作成した表を用いて重み付け処理が行われる。この重み付け処理は、図２を参照して表中の各項目にポイントを加算することで、行われる。ポイントを加算することにより、図４（ｂ）に示されている状態になる。すなわち、図２を参照すると、メッセージＭ０００１については、「ユニット」、「パッケージ」、「回線」それぞれに「１」ポイントが加算されるため、図４（ｂ）に示されているように、「Ｎ１−１」の「ユニット」及び「パッケージ」が「＋１」ポイント、「回線＃１」が「＋１」ポイントになる。
【００４４】
この場合、受信したメッセージのメッセージ種別が「Ｍ００１」であるので、図２に定義されているように、待ち合わせ時間２０秒が経過するまでに、関連メッセージ「Ｍ００１」、「Ｍ００２」、「Ｍ００４」のいずれかを受信した場合に、上記のようなポイント加算が行われる。
待ち合わせ時間２０秒が経過するまでに、故障発生装置として「Ｎ１−２」、メッセージ種別として「Ｍ００１」、メッセージ内容として「リンク断リンク番号０００」が含まれている故障通知メッセージを受信した場合、以下のように処理される。すなわち、故障の発生した通信装置Ｎ１−２に対応した装置構成情報（図示せず）について、リンク番号「０００」をキーにして検索し、この検索結果に基づいて表を作成する。
【００４５】
故障通知メッセージによっては、故障装置に対向する装置に関する情報が含まれている場合もある。そのような対向装置に関する情報が含まれている場合、対向装置についての装置構成情報を収集する。次に、この故障発生装置に関して収集した情報又は対向装置に関して収集した情報について、上記の表において既に定義されているか（つまり表中にその項目があるか）判定が行われる。
【００４６】
この場合、同図（ｂ）の状態において、対向装置である通信装置Ｎ２の項目が表に存在するので、その項目は新たに作成されない。これに対し、故障発生装置である通信装置Ｎ１−２の項目は表に存在しないので、その項目が新たに作成される。この結果、図４（ｃ）に示されているように、項目が追加された表が作成されることになる。
【００４７】
そして、作成した表を用いて重み付け処理が行われる。今回受信したメッセージ種別が「Ｍ００１」であるので、図２を参照すると、メッセージＭ０００１については、「ユニット」、「パッケージ」、「回線」それぞれに「１」ポイントが加算されるため、図４（ｄ）に示されているように、「Ｎ１−２」の「ユニット」及び「パッケージ」が「＋１」ポイント、「回線＃２」が「＋１」ポイントになる。
【００４８】
以下同様に、待ち合わせ時間内に故障通知メッセージを受信した場合、定義されていない項目が表に追加され、重み付け処理が行われる。重み付け処理の完了した状態の例が図５に示されている。同図においては、障害の発生した「発生装置」として、「Ｎ１−１」、「Ｎ１−２」、「Ｎ１−３」、「Ｎ２」が示されている。
【００４９】
通信装置Ｎ１−１において障害が発生し、リンク断を示すメッセージＭ００１が通信装置Ｎ１−１から送られてきた場合、上述した故障要因定義（図２参照）に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「１」が加算されることになる。本例では、通信装置Ｎ１−１の「ユニット」、「パッケージ」及び「回線＃１」にそれぞれポイント「１」が加算される。リンク断を示すメッセージＭ００１が通信装置Ｎ１−２、Ｎ１−３からそれぞれ送られてきた場合も同様に、通信装置Ｎ１−２の「ユニット」、「パッケージ」及び「回線＃２」、通信装置Ｎ１−３の「ユニット」、「パッケージ」及び「回線＃３」にそれぞれポイント「１」が加算される。
【００５０】
また、通信装置Ｎ２において障害が発生し、パッケージ故障を示すＭ００２が通信装置Ｎ２から送られてきた場合、上述した故障要因定義（図２参照）に従い、「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算されることになる。本例では、通信装置Ｎ２の「通信装置」にポイント「１」が、「パッケージ」にポイント「２」が、それぞれ加算される。
【００５１】
さらに、リンク断を示すメッセージＭ００１が通信装置Ｎ２から３回送られてきた場合、上述した故障要因定義（図２参照）に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「１」が加算されることになる。本例では、通信装置Ｎ２の「ユニット」及び「パッケージ」にポイント「１」が、３回加算される。さらに、本例では、「回線＃１」、「回線＃２」、「回線＃３」にそれぞれポイント「１」が加算される。
【００５２】
以上のように、故障通知メッセージの受信を契機に、図３に示されている各通信装置の構成情報（通信装置内のユニット、パッケージ、回線収容情報等）が構成情報ＤＢＡ６から読出される。そして、メッセージ発生元通信装置の構成情報と、メッセージ内情報を元に読出した対向の通信装置とを関連付けた情報として、図５に示されている重み付け結果の表が図示せぬメモリ上に作成される。この図５に示されている重み付け結果に基づいて、故障発生箇所が特定されるのである。
【００５３】
（故障箇所の特定）
以上のようにポイントを加算して重み付けした結果が、図６に示されている。同図は、ポイントを加算して重み付けした結果を概念的に示したものである。同図を参照すると、通信装置Ｎ２はポイントが「＋１」、通信装置Ｎ２内のユニットはポイントが「＋３」、そのユニット内のパッケージ００はポイントが「＋５」である。また、通信装置Ｎ１−１内のユニット、通信装置Ｎ１−２内のユニット、通信装置Ｎ１−３内のユニットは、それぞれポイントが「＋１」である。それら通信装置Ｎ１−１、Ｎ１−２、Ｎ１−３内の各パッケージ００はポイントが「＋１」である。
【００５４】
さらに、通信装置Ｎ２のユニット内のパッケージ００の「リンク０００」と通信装置Ｎ１−１のユニット内のパッケージ００の「リンク０００」とを接続している回線＃１はポイントが「＋２」である。通信装置Ｎ２のユニット内のパッケージ００の「リンク００１」と通信装置Ｎ１−２のユニット内のパッケージ００の「リンク０００」とを接続している回線＃２はポイントが「＋２」である。通信装置Ｎ２のユニット内のパッケージ００の「リンク００２」と通信装置Ｎ１−３のユニット内のパッケージ００の「リンク００１」とを接続している回線＃３はポイントが「＋２」である。
【００５５】
以上の結果から、通信装置Ｎ２内のユニット内のパッケージ００がポイント「＋５」で最も重み付け値が大きい。このため、このパッケージ００が故障発生箇所と特定することができる。
以上のように、待ち合わせ時間の経過後、重み付け値が最も大きい部分を故障発生箇所として特定する。ただし、待ち合わせ時間の経過前であっても、重み付け値が所定の閾値を超えた場合は、その重み付け値が超えた部分を故障発生箇所として特定する。
【００５６】
（本システム全体の動作）
図１に戻り、上記の構成からなる本実施形態の故障措置システムの動作について説明する。
（１）故障通知メッセージは、ＯＰＳ装置Ｏ１、Ｏ２からＯＰＳアダプタ部Ａ１経由で、ＯＰＳ装置Ｏ６に通知される。この故障通知メッセージは、図７に示されているように、故障の発生した発生装置名７１、そのメッセージのメッセージ種別７２、メッセージ内容７３、故障の発生時刻７４、を含んで構成されている。
【００５７】
（２）ＯＰＳ装置Ｏ６に通知された故障通知メッセージは、すべてメッセージ分析処理部Ａ２でその内容が分析される。これにより、上述した、発生装置名、メッセージ種別、メッセージ内容、発生時刻の各情報が抽出される。
（３）構成情報検索部Ａ５は、故障通知メッセージに含まれている、発生装置名に基づいて、関連する構成情報（図３参照）を、構成情報ＤＢＡ６から読出すことにより、重み付け処理のためのマトリクス表（図４及び図５参照）を作成する。
（４）推定ルール実行部Ａ４は、故障通知メッセージに含まれている、メッセージ種別に基づいて、予め設定してある故障要因定義Ａ４−１（図２参照）を読出す。
【００５８】
（５）上記（４）において説明した故障要因定義の内容にしたがって、構成情報内の装置（故障被疑箇所）に対して、ポイントを加算していく。このようにポイントを加算することで、故障被疑箇所に重み付け処理を行う。
（６）予め故障要因定義に設定してあるメッセージ受信の待ち合わせ時間が経過するまでの間に通知されるメッセージに対して同様の処理を繰り返す。ただし、重み付け値が、予め定められた閾値を超えた場合は、処理は終了となる。
（７）上記（４）でメッセージ種別が関連しない場合は、別の故障要因と判断して、上記と同様の処理を実行する。また、メッセージ種別が関連した場合であっても、上記（３）において発生装置名が関連なかった場合においても、別の故障要因と判断して、上記と同様の処理を実行する。
【００５９】
（８）待ち合わせ時間経過後に、上記（５）のポイント加算結果、すなわち重み付け処理結果を分析し、重み付け値の高い装置に対して順次、コマンドを用いた正常性の確認、及び、故障措置を実行する。
（９）上記（８）の結果及び、ポイントを加算したメッセージは履歴として履歴ＤＢに保存して管理する。こうすることにより、ポイント加算対象や、ポイントの大小を分析可能とし、故障要因定義の適正化を行うことができる。
【００６０】
以上のように本システムによれば、通信装置の故障が発生した場合、複数のメッセージを関連付けた故障要因特定を行うことができる。また、故障要因特定論理は、通信装置のメッセージ設計論理に基づいて定義できるため、新規通信装置の導入やネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的な故障要因特定を実現できる。
【００６１】
（まとめ）
以上のように本システムでは、通信ネットワークを構成する複数の通信装置構成情報を管理し、通信装置から通知されるメッセージ毎に発生箇所を分析し、故障発生装置の故障箇所にポイントを加算していくことで、故障箇所の絞りこみを行い、一定時間に発生する複数のメッセージの処理を実施した後で、ポイントの最上位または、一定レベルを超えている箇所に対して、故障の対応を実施している。これにより、複数の通信装置から通知されるメッセージを一元的に処理し、適切な故障要因のしぼりこみが、効率的に実現できる。
なお、要因特定時に故障箇所にポイントを加算したメッセージを一覧として表示することで、テキストファイルに記載した故障要因特定ロジックを適切に変更できるので、加算する対象、及び、そのポイントを、本システムの端末により変更することができる。
【００６２】
（故障要因特定方法）
上述した故障措置システムにおいては、以下のような故障要因特定方法が採用されている。この故障要因特定方法について、図８を参照して説明する。同図に示されているように、故障通知メッセージを受信するまでは待ち状態であり（ステップＳ８００）、故障通知メッセージを受信した場合に、必要な情報が収集される（ステップＳ８００→Ｓ８０１）。
【００６３】
情報を収集した結果、以前受信したメッセージと関連するか判断され、関連しない場合は、ステップＳ８００に戻る（ステップＳ８０２→Ｓ８００）。
次に、既にマトリクス表が作成され、表中に項目が含まれているか判断される（ステップＳ８０３）。マトリクス表が作成されていない場合、又は作成されていても項目が存在しない場合、マトリクス表又はその項目を作成する（ステップＳ８０３→Ｓ８０４）。その後、重み付け処理に移行する（ステップＳ８０４→Ｓ８０５）。マトリクス表が既に作成され、かつ、項目が存在する場合、そのまま重み付け処理に移行する（ステップＳ８０３→Ｓ８０５）。
【００６４】
重み付け処理においては、上述したように、表の各項目にポイントを加算する（ステップＳ８０５）。この重み付け処理の結果、重み付け値が予め定められた閾値を超えた場合、処理は終了となり、故障装置が特定される（ステップＳ８０６→Ｓ８０８）。
以上の処理は、重み付け値が予め定められた閾値を超えない限り、予め定められた待ち合わせ時間を経過するまで行われる（ステップＳ８０６→Ｓ８０７→Ｓ８００…）。待ち合わせ時間が経過した後、上記と同様に、処理は終了となり、故障装置が特定される（ステップＳ８０７→Ｓ８０８）。
【００６５】
このように、上述した故障措置システムでは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法が実現されている。そして、この故障要因特定方法は、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、故障要因定義情報に基づいて、表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含んでいる。
【００６６】
要するに本方法では、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、表の各項目に重み付けを行い、その重み付け結果に基づいて故障している装置を特定するので、故障した装置を容易に特定できるのである。
【００６７】
【発明の効果】
以上説明したように、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、その表の各項目に重み付けを行った結果を用いることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できるという効果がある。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、１つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【図面の簡単な説明】
【図１】本発明による故障措置システムの実施の一形態を示すブロック図である。
【図２】重み付け処理に用いる故障要因の定義を示す図である。
【図３】構成情報ＤＢに記憶されている構成情報の例を示す図である。
【図４】マトリクス表の作成過程を説明する図である。
【図５】重み付け処理の完了した状態の例を示す図である。
【図６】重み付けした結果を示す図である。
【図７】故障通知メッセージの構成例を示す図である。
【図８】本発明による故障要因特定方法を示すフローチャートである。
【図９】通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークの例を示す図である。
【図１０】図９中のＯＰＳ装置の内部構成例を示すブロック図である。
【図１１】故障要因推定ルールの一例を示すフローチャートである。
【図１２】故障要因推定ルールの一例を示すフローチャートである。
【符号の説明】
Ａ１ＯＰＳアダプタ部
Ａ２メッセージ分析処理部
Ａ３推定ルール
Ａ４推定ルール実行部
Ａ４−１故障要因定義
Ａ５構成情報検索部
Ａ６構成情報ＤＢ
Ａ７要因特定・故障措置部
Ａ８動作シナリオ
Ａ９動作部品群
Ａ１０履歴ＤＢ
Ｄ１〜Ｄ４入出力装置
Ｎ１―１〜Ｎ１―３、
Ｎ２、Ｎ１―１’〜Ｎ１―３’ 通信装置
Ｏ１〜Ｏ４、Ｏ６ＯＰＳ装置
Ｔ１、Ｔ２通信端末[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a failure handling system, and a failure factor identifying method, in particular, a failure handling system that comprehensively determines a notification regarding a failure that has occurred in a plurality of communication devices configuring a communication network and performs appropriate failure factor analysis. And a failure factor identification method.
[0002]
[Prior art]
In the related art, a communication network adopting a failure handling system for specifying a failure location when a failure occurs in the communication network is configured as shown in FIG. That is, in the figure, communication devices N1-1 to N1-3 and N1-1 'to N1-3' and N2 forming a network, communication terminals T1 and T2 respectively connected to these communication devices, and a communication medium OPS (Operation System) device O1 that is connected to each communication device via an OPS, receives a notification (message) from the communication device, or sends an instruction (command) to the communication device and configures an operation support system corresponding to the communication device. To O4 and an OPS device O6 constituting an operation support system including a general-purpose computer for managing the entire communication network.
[0003]
Further, input / output devices D1 to D4 are connected to the communication network shown in FIG. These input / output devices D1 to D4 are connected to the OPS device O6, and are provided for displaying a message received by the operation system to a maintenance person or inputting a command from the maintenance person to the operation system. .
It should be noted that the term “failure” in this specification includes not only a failure of a device but also a failure of a line.
[0004]
Here, FIG. 10 shows an example of the internal configuration of the OPS device O6. In the figure, an OPS device O6 includes an OPS adapter unit A1 for interfacing with the outside such as message conversion, a message analysis processing unit A2 for analyzing a message, and an estimation rule storage for storing an estimation rule described later. Unit A3, an estimation rule execution unit A4 that executes an estimation rule, a configuration information search unit A5 that searches for network configuration information, and a configuration information DB that stores configuration information about communication devices that make up the communication network ( Data Base) A6, a factor identification / failure measure unit A7 for identifying a failure factor and instructing an appropriate measure corresponding thereto, an operation scenario storage unit A8 storing an operation scenario for failure recovery, and software. An operation component group A9 for realizing a predetermined operation, and a history DB ( Data Base) A10.
[0005]
The operation component group A9 is a component by software for realizing operations such as “traffic collection”, “diagnosis / test”, “device switching / initial setting”, and “trouble ticket issuance”. These operations are merely examples, and it is assumed that software-based components for realizing other necessary operations are included in the operation component group A9.
When the operation scenario stored in the operation scenario storage unit A8 operates at least one of the operation component groups A9, a recovery measure is automatically performed.
[0006]
Next, an operation example of the system having the above configuration will be described. Here, as an example, when a failure occurs somewhere between the communication devices in the communication network, measures for the failure will be described.
When a failure occurs, a message indicating the occurrence is notified to the OPS device O6. Here, the failure notification message is notified to the OPS device O6 via the OPS devices O1 to O4. The notified message is converted by the OPS adapter unit A1 into information that can be processed by the OPS device O6. The contents of all the converted messages are analyzed by the message analysis processing unit A2 in the OPS device O6. Through this analysis, information such as a message type, a device name, and an occurrence time is extracted. The message analysis processing unit A2 determines whether or not a response is required for each message type, and if a response is required, refers to the corresponding estimated rule storage unit A3 to determine an estimation rule.
[0007]
The estimation rule execution unit A4 checks the presence or absence of the occurrence of a related message predefined in the estimation rule for t seconds before and after the occurrence time (t: a variable value described in the scenario). If there is a message, by searching the configuration information DBA6 using the device name as key information in cooperation with the configuration information search unit A5, it is determined whether the message has occurred in the opposite communication device, The main factor is estimated by identifying whether or not the message has occurred and analyzing the related message occurrence pattern, and the operation scenario is determined. By executing the determined operation scenario, it is possible in principle to recover from the failure without the intervention of a maintenance person.
[0008]
Here, an example of the failure factor estimation rule is shown in FIGS.
Next, examples of the estimation rule and the operation scenario will be described with reference to FIGS. In this example, after performing the estimation processing as shown in FIG. 11, measures necessary for recovery are performed as shown in FIG. In this example, a failure occurs in the link number “001” and the device name “N1-1”, and the failure occurrence time is “yymmddhhmmss” (each date is represented by two digits).
[0009]
First, in FIG. 11, it is determined whether there is a system down message in the same communication device N1-1 (step S101). If there is such a message, the flow shifts to FIG. 12 to start a restart-response scenario corresponding to the communication device N1-1 (step S201).
Returning to FIG. 11, if there is no such message, it is next determined whether or not there is a higher-level device (accommodated package) failure message in the same communication device N1-1 (step S102). If there is such a message, the flow shifts to FIG. 12 to activate a device diagnosis scenario corresponding to the communication device N1-1 (step S202).
[0010]
Returning to FIG. 11, if there is no such message, it is next determined whether or not there is a message of the same type of another link in the same communication device N1-1 (step S103). If there is such a message, it is further determined whether or not there is a system down message in the opposite communication device (step S104). If there is such a message, the flow shifts to FIG. 12 to activate a restart-response scenario corresponding to the remote communication device N2 (step S203).
[0011]
Returning to FIG. 11, if there is no such message, it is next determined whether or not there is a higher-level device (accommodated package) failure message in the opposite communication device (step S105). If there is such a message, the flow shifts to FIG. 12, and a failure handling scenario corresponding to the opposite communication device N2 is started (step S204).
Returning to FIG. 11, if there is no such message, it is next determined whether or not there is a link failure occurrence message on the opposite communication device side (step S106). If there is such a message, the flow shifts to FIG. 12 to activate a link failure scenario corresponding to the opposite communication device N2 (step S205).
[0012]
When the scenarios in steps S201, S203, S204, and S205 are started, the measures are ended thereafter. When the scenario in step S202 is started, a trouble ticket issuance scenario is started thereafter, and a maintenance person is requested to replace the package (step S210).
In step S106, when there is no message indicating that a link failure has occurred on the opposite communication device side, a trouble ticket issuance scenario is started, and the maintenance person is urged to give up as a give up (step S209).
[0013]
In step S103, when there is no message of the same type of another link in the same communication device N1-1, the process proceeds to FIG. 12, and a link failure scenario corresponding to the communication device N1-1 is activated. In this case, first, it is determined whether or not the link has been recovered by the link initial setting due to the link blockage / release (step S206). If it recovers, the measures will end.
If the link test is not recovered in step S206, it is determined whether the link test result is normal (step S207). If the link test result is normal, a trouble ticket issuance scenario is activated, and a maintenance is urged as a give up (Step S209). On the other hand, if the link test result is not normal, a trouble ticket issuance scenario is activated to urge the maintenance person to respond (step S208).
[0014]
As described above with reference to FIGS. 11 and 12, the factor identification / troubleshooting unit A7 automatically performs the effect grasp by collecting the traffic information and the factor identification by the diagnosis / test according to the operation scenario. Identify the cause of the failure. Then, after the cause of the failure is specified, failure measures such as initial setting, system change, and device switching are performed on the target device. Individual operations such as traffic information collection, diagnosis / test, and device switching are prepared in advance as the operation component group A9 described above. The operation using the operation component group is described by an operation scenario. The command to the target communication device can be executed by specifying the target communication device by the factor identification / failure measure unit.
[0015]
As a result of the failure measures, when a maintenance person needs to take measures such as replacement of a hardware device, a trouble ticket is issued from the input / output device D1 as described above. In this case, this may be displayed on the screen of the input / output device D1 to notify the maintenance person, or may be notified to the maintenance person by printing out.
Also, when the operation scenario cannot be determined or when the failure cannot be recovered, the trouble ticket for urging the maintenance person to respond is notified as described above. Finally, the message that triggered the notification of the series of messages, the determined operation scenario, the command execution result, and the failure measure result are stored in the history DBA 10, and the failure measure is completed.
[0016]
The system maintainer of the OPS device O6 periodically performs statistical analysis of the history DBA 10 to confirm the normality of the estimation rules and operation scenarios, and, when there is a malfunction in the operation, can perform text-based correction. And That is, as described above, the scenario of the present example is configured by a text file. Therefore, even when the scenario needs to be changed, its contents can be easily modified or the scenario itself can be newly added. can do.
[0017]
As described above, the present system is a system for monitoring and maintaining a communication network in an operation system including a general-purpose computer that manages a plurality of communication devices configuring a communication network via a communication medium. Then, using the information of the autonomous message notified from the communication device, the messages are correlated, the cause of the failure is analyzed, and automatic measures are taken.
[0018]
In this system, an occurrence pattern of a message notified from each communication device when a failure occurs is provided in advance, and an appropriate action procedure is determined from the action patterns that have been deployed in advance according to the message occurrence pattern. The occurrence pattern of the message and the procedure of the measure are prepared in advance as a text-based scenario, and even if the message is changed, it can be easily handled. As a result, immediately after the occurrence of the failure, the failure factor can be automatically analyzed and the failure measure can be taken without the maintenance person's work.
[0019]
In order to create the above-described failure factor estimation rule, operation results and operation experience are required.
Here, a technique for obtaining high diagnostic accuracy by performing weighting with a failure event and a failure factor in a matrix table is described in Patent Document 1.
As a conventional technique for performing the above-described failure measures, there is a technique described in Non-Patent Document 1. Non-Patent Document 1 describes a method in which messages output from respective devices are intensively received at a certain location, and related messages are waited for and correlated in consideration of the output order of the messages.
[0020]
[Patent Document 1]
JP-A-11-119823 (abstract, [0005])
[Non-patent document 1]
CD-ROM "Transactions of the Society of Electronics, Information and Communication Engineers 2002 Society Conference", The Institute of Electronics, Information and Communication Engineers, August 20, 2002, Lecture Number: B-6-76. Examination "
[0021]
[Problems to be solved by the invention]
The failure factor estimation rule used in the conventional failure factor identification method needs to be created based on the failure handling flow based on the operation results shown in FIGS. 11 and 12, and sequentially determines the normality of the communication device. It was necessary to narrow down the failure location.
In this case, if the operation has already been performed and the failure handling method has been patterned, it is possible to accurately specify the failure location. However, when the failure factor identification method is implemented according to a new communication device introduced with the provision of a new service, there is no operation record. For this reason, it is necessary to create a failure factor estimation rule based on assumptions, and there have been problems in narrowing down failure automation targets, accuracy of a failure handling method, and development efficiency. Non-patent document 1 described above has a similar problem.
[0022]
Note that the above-mentioned Patent Literature 1 is based on the premise that the failure handling method is patterned, and thus cannot solve the above problem.
SUMMARY OF THE INVENTION The present invention has been made to solve the above-described drawbacks of the related art, and has as its object to provide a method for easily identifying a failed device when any of the devices constituting the network fails. It is to provide an action system and a failure factor identification method.
[0023]
[Means for Solving the Problems]
A failure handling system according to claim 1 of the present invention stores device configuration information indicating devices constituting a network and respective components constituting the devices, and failure factor definition information indicating a value of a weight for a failure factor. In response to receiving a failure notification message sent from a device constituting the network, a storage means (corresponding to the configuration information DBA 6 and the history DBA 10 described later) and a weighting device based on the device configuration information. Table creation means (corresponding to a configuration information search unit A5 described later) for creating a table, and weighting means (described later) for weighting each item of the table created by the table creation means based on the failure factor definition information. (Corresponding to the estimation rule execution unit A4), and specifies the faulty device based on the weighting result by the weighting means. Characterized in that the. By doing so, when any of the devices constituting the network fails, the failed device can be easily specified. In particular, even when a new communication device is introduced or the network configuration is changed, the cause of the failure can be efficiently specified only by changing the definition file. In addition, since the occurrence of a message in the related device is sequentially confirmed from one failure notification message, redundant processing that requires confirmation of message generation between the opposite devices is not required.
[0024]
The failure handling system according to claim 2 of the present invention is characterized in that, in claim 1, the weighting means performs the weighting within a predetermined waiting time for each failure notification message. By doing so, a plurality of failure notification messages may be generated due to a device failure, and even in such a case, weighting can be performed using a message received within a predetermined waiting time.
[0025]
In the failure handling system according to claim 3 of the present invention, in claim 1 or 2, the weighting means assigns the weight only when a message related to the failure notification message is received for each failure notification message. It is characterized by performing. By doing so, weighting can be performed using a plurality of related failure notification messages.
[0026]
According to a fourth aspect of the present invention, there is provided a failure handling system according to any one of the first to third aspects, wherein when the weighting result by the weighting means exceeds a predetermined threshold value, the weighting is terminated to specify a faulty device. It is characterized by doing. By doing so, the faulty device can be immediately specified when the predetermined threshold is exceeded, regardless of the predetermined waiting time.
[0027]
The failure factor specifying method according to claim 5 of the present invention uses the device configuration information indicating the devices constituting the network and the respective parts constituting the devices, and the failure factor definition information indicating the weight of the failure factor. A failure factor identification method for identifying a malfunctioning device, wherein the weighting is performed based on the device configuration information in response to receiving a failure notification message sent from a device configuring the network. A weighting step for weighting each item of the table created in the table creation step based on the failure factor definition information, and a failure based on the weighting result of the weighting step. Identifying the device that is running. By doing so, when any of the devices constituting the network fails, the failed device can be easily specified. In particular, even when a new communication device is introduced or the network configuration is changed, the cause of the failure can be efficiently specified only by changing the definition file. In addition, since the occurrence of a message in the related device is sequentially confirmed from one failure notification message, redundant processing that requires confirmation of message generation between the opposite devices is not required.
[0028]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, an embodiment of the present invention will be described with reference to the drawings. In the drawings referred to in the following description, the same parts as those in the other drawings are denoted by the same reference numerals.
(Configuration of this system)
FIG. 1 is a block diagram showing an embodiment of the failure handling system according to the present invention. As shown in the figure, in the failure handling system according to the present embodiment, the portion A is different from the conventional configuration (FIG. 10). That is, the message analyzer A2 in FIG. 1 analyzes the failure notification message. Further, the configuration information search unit A5 reads the configuration information from the configuration information DBA6 and creates a matrix table for weighting. That is, the matrix table is not created in advance, but is created when the failure notification message is received.
[0029]
The estimation rule execution unit A4 reads the failure factor definition A4-1 and performs a weighting process according to the content of the definition. Here, a weighting process is performed by adding points to each item of the created matrix table according to the failure factor definition A4-1. This weighting process is performed sequentially in response to a failure notification message received until a predetermined time has elapsed.
[0030]
After a certain period of time, the result of the weighting process (point addition result) by the estimation rule execution unit A4 is stored in the history DBA10.
As described above, by performing weighting based on the result of the point addition, the factor identification / failure measure unit A7 can identify a failure factor, that is, a failed device. The factor identification / failure measure unit A7 creates a failure identification message for notifying the identified device to another device.
[0031]
When a failure identification message is created by the factor identification / failure measure unit A7, the message is displayed on the input device D1. This display is not limited to the display on the display screen, and the display content may be printed out. Not only the display but also the operator may be notified in some form. For example, the content may be output as audio instead of or together with the display.
The operation component group A9 is a component based on software for realizing operations such as “diagnosis / test” and “device switching / initial setting”.
[0032]
(Failure factor definition)
In the present system, a failure occurrence location is specified by performing a weighting process as described later. FIG. 2 shows the definitions of the failure factors used in the weighting process. In the drawing, the point addition points and the addition points are indicated by numerical values for each message type.
In this example, as the types of messages, a message M001 indicating “link break”, a message M002 indicating “package failure”, a message M003 indicating “device error”, a message M004 indicating “device initial setting”, and “power error” And a message M006 indicating “abnormal call processing”.
[0033]
In the present example, the points to be added include “communication device”, “power supply unit”, “communication control unit (software)”, “unit”, “package”, and “line”. However, the present invention is not limited to these, and each part constituting each communication device constituting the network is a point addition point.
As shown in the figure, when a message M001 indicating “link break” is sent, a point “1” is added to each of “unit”, “package”, and “line”.
When the message M002 indicating “package failure” is sent, the point “1” is added to “communication device” and the point “2” is added to “package”.
[0034]
Furthermore, when the message M003 indicating “device abnormality” is sent, a point “1” is added to each of “communication device”, “unit”, “package”, and “line”.
Similarly, when the message M004 indicating “device initial setting” is sent, the point “1” is assigned to the “power supply unit” and the “communication control unit (software)”, and the point “2” is assigned to the “unit”. Is added. When the message M005 indicating “power failure” is sent, the point “2” is added to the “power supply unit”. When the message M006 indicating “abnormal call processing” is sent, the point “1” is added to the “communication control unit (software)”.
[0035]
FIG. 2 shows the waiting time (maximum value) of each of the messages M001 to M006. In this example, the waiting time of each of the messages M001, M002, and M003 is 20 seconds, the waiting time of the message M004 is 30 seconds, the waiting time of the message M005 is 60 seconds, and the waiting time of the message M006 is 10 seconds. The weighting process by the above point addition is performed within the waiting time.
[0036]
Further, FIG. 7 shows related messages related to each of the messages M001 to M006. In this example, the messages related to the message M001 are the messages M001, M002, and M004. Messages related to the message M002 are the messages M001 and M004. Further, messages related to the message M003 are the messages M003 and M004. Similarly, messages related to message M004 are messages M001, M002, M003 and M005, and messages related to message M005 are message M004. There is no message (exists) related to message M006.
If it is not defined as a related message, it is determined to be another cause of failure as described later.
[0037]
(Device configuration information)
An example of the configuration information stored in the configuration information DBA 6 is shown in FIG. FIG. 13 is a diagram illustrating an example of configuration information about a communication device “N1-1”. In the figure, a unit called "signal processing unit" is included in a communication device called "N1-1", and further, a package called "signal processing package 00" and "signal processing package 01" are included in the unit. Is included.
[0038]
In the “signal processing package package 00”, links from link numbers “000” to “007” are provided. The links with link numbers "000", "001", and "002" have the opposite communication device name of "communication device N2" and the line numbers of "1", "2", and "3", respectively. The links of link numbers “003” and “004” have the opposite communication device name of “communication device N1-2” and the line numbers of “1” and “2”, respectively. The links with link numbers “005”, “006”, and “007” have the opposite communication device name “communication device N1-3” and the line numbers “1”, “2”, and “3”, respectively.
[0039]
In the “signal processing package package 01”, links from link numbers “008” to “015” are provided. The links of link numbers “008”, “009”, and “010” have the opposite communication device name of “communication device N2” and the line numbers of “4”, “5”, and “6”, respectively. The links of link numbers “011” and “012” have the opposite communication device name of “communication device N1-2” and the line numbers of “3” and “4”, respectively. The links of link numbers “013”, “014”, and “015” have the opposite communication device name of “communication device N1-3” and the line numbers of “4”, “5”, and “6”, respectively.
[0040]
As described above, the device configuration information is prepared corresponding to each of the communication devices configuring the network, and the configuration information is stored in the configuration information DBA6. Since the device configuration information is configured in a text format, it can be partially changed, added, and deleted. Therefore, the device included in the network, that is, the device configuration has been changed, added, or deleted. In this case, it is possible to easily cope with the problem and to specify the cause of the failure.
[0041]
(Matrix table creation and weighting processing)
In this system, a matrix table is created in response to receiving the failure notification message, and weighting processing is performed using the created matrix table. Hereinafter, creation of the matrix table and weighting processing using the matrix table will be described.
When a failure notification message sent from a device configuring the network includes “N1-1” as the failure generating device, “M001” as the message type, and “link disconnected link number 000” as the message content A matrix table (hereinafter, sometimes simply referred to as a “table”) is created as follows. That is, the device configuration information shown in FIG. 3 corresponding to the failed communication device N1-1 is searched using the link number “000” as a key, and FIG. Create a table as shown in.
[0042]
FIG. 9A shows a table for the weighting process to be created for the failure generator “N1-1” and the message type “M0001”. The table shown in FIG. 3A includes items of “communication device”, “unit”, and “package” for each of the communication devices “N1-1” and “N2”, and further includes “line # 1”. Item. When information on the device facing the failed device is included in the device configuration information, the above-described table is created by collecting the configuration information on the device facing the failure.
[0043]
The weighting process is performed using the table created in this way. This weighting process is performed by adding points to each item in the table with reference to FIG. By adding the points, the state shown in FIG. 4B is obtained. That is, referring to FIG. 2, for the message M0001, "1" point is added to each of "unit", "package", and "line", so that "1" point is added as shown in FIG. The “unit” and “package” of “N1-1” are “+1” points, and the “line # 1” is “+1” points.
[0044]
In this case, since the message type of the received message is “M001”, the related messages “M001”, “M002”, and “M004” are received before the waiting time of 20 seconds elapses, as defined in FIG. Is received, the above point addition is performed.
If a failure notification message including “N1-2” as the failure generating device, “M001” as the message type, and “link disconnected link number 000” as the message content is received before the waiting time of 20 seconds elapses, It is processed as follows. That is, a search is made for device configuration information (not shown) corresponding to the communication device N1-2 in which the failure has occurred, using the link number "000" as a key, and a table is created based on the search result.
[0045]
Depending on the failure notification message, information about the device facing the failed device may be included. When such information on the opposing device is included, device configuration information on the opposing device is collected. Next, it is determined whether the information collected for the failure generating device or the information collected for the counterpart device is already defined in the table (that is, whether the item is present in the table).
[0046]
In this case, in the state of FIG. 3B, since the item of the communication device N2 which is the opposite device exists in the table, the item is not newly created. On the other hand, since the item of the communication device N1-2 which is the failure generating device does not exist in the table, the item is newly created. As a result, as shown in FIG. 4C, a table in which items are added is created.
[0047]
Then, a weighting process is performed using the created table. Since the message type received this time is “M001”, referring to FIG. 2, for the message M0001, “1” points are added to each of “unit”, “package”, and “line”. As shown in d), the “unit” and “package” of “N1-2” have “+1” points, and the “line # 2” has “+1” points.
[0048]
Similarly, when a failure notification message is received within the waiting time, undefined items are added to the table and weighting processing is performed. FIG. 5 shows an example of a state in which the weighting process has been completed. In the figure, “N1-1”, “N1-2”, “N1-3”, and “N2” are shown as “generating devices” in which a failure has occurred.
[0049]
When a failure occurs in the communication device N1-1 and the message M001 indicating the link disconnection is sent from the communication device N1-1, the "unit", "package", and "package" are defined in accordance with the above-described failure factor definition (see FIG. 2). The point "1" is added to each "line". In this example, a point “1” is added to each of “unit”, “package”, and “line # 1” of the communication device N1-1. Similarly, when the message M001 indicating the link disconnection is sent from each of the communication devices N1-2 and N1-3, the "unit", "package" and "line # 2" of the communication device N1-2, the communication device N1 The point “1” is added to the “unit”, “package”, and “line # 3” of -3.
[0050]
Further, when a failure occurs in the communication device N2 and M002 indicating a package failure is transmitted from the communication device N2, the point “1” is assigned to the “communication device” according to the above-described failure factor definition (see FIG. 2). The point "2" is added to the "package". In this example, the point “1” is added to “communication device” of the communication device N2, and the point “2” is added to “package”.
[0051]
Further, when the message M001 indicating the link disconnection is sent three times from the communication device N2, the point “1” is assigned to each of the “unit”, “package”, and “line” according to the above-described failure factor definition (see FIG. 2). Will be added. In this example, the point “1” is added to the “unit” and “package” of the communication device N2 three times. Furthermore, in this example, the point “1” is added to “line # 1”, “line # 2”, and “line # 3”.
[0052]
As described above, upon receiving the failure notification message, the configuration information (units, packages, line accommodation information, and the like in the communication device) of each communication device illustrated in FIG. 3 is read from the configuration information DBA6. Then, a table of the weighting results shown in FIG. 5 is created in a memory (not shown) as information associating the configuration information of the message generating source communication device with the opposing communication device read out based on the information in the message. Is done. Based on the result of the weighting shown in FIG. 5, the location where the failure has occurred is specified.
[0053]
(Identification of failure location)
FIG. 6 shows the result of weighting by adding points as described above. FIG. 6 conceptually shows the result of adding and weighting points. Referring to the figure, the communication device N2 has a point of "+1", a unit in the communication device N2 has a point of "+3", and a package 00 in the unit has a point of "+5". The points in the units in the communication device N1-1, the units in the communication device N1-2, and the units in the communication device N1-3 are “+1”. The points of the packages 00 in the communication devices N1-1, N1-2, and N1-3 are "+1".
[0054]
Further, the point of the line # 1 connecting the “link 000” of the package 00 in the unit of the communication device N2 and the “link 000” of the package 00 in the unit of the communication device N1-1 is “+2”. . The point of the line # 2 connecting the “link 001” of the package 00 in the unit of the communication device N2 and the “link 000” of the package 00 in the unit of the communication device N1-2 is “+2”. The point of line # 3 connecting “link 002” of package 00 in the unit of communication device N2 and “link 001” of package 00 in the unit of communication device N1-3 is “+2”.
[0055]
From the above results, the package 00 in the unit in the communication device N2 has the largest weight value at the point “+5”. Therefore, the package 00 can be specified as a failure occurrence location.
As described above, after the elapse of the waiting time, the portion having the largest weight value is specified as the failure occurrence location. However, even before the elapse of the waiting time, if the weighted value exceeds a predetermined threshold, the portion where the weighted value is exceeded is specified as a failure occurrence location.
[0056]
(Operation of the entire system)
Returning to FIG. 1, the operation of the failure handling system according to the present embodiment having the above configuration will be described.
(1) The failure notification message is notified from the OPS devices O1 and O2 to the OPS device O6 via the OPS adapter unit A1. As shown in FIG. 7, the failure notification message includes a generator name 71 in which a failure has occurred, a message type 72 of the message, a message content 73, and a failure occurrence time 74.
[0057]
(2) The contents of all the failure notification messages notified to the OPS device O6 are analyzed by the message analysis processing unit A2. As a result, the above-described information of the generator name, message type, message content, and occurrence time is extracted.
(3) The configuration information search unit A5 reads out the relevant configuration information (see FIG. 3) from the configuration information DBA 6 based on the generator name included in the failure notification message to perform the weighting process. (See FIGS. 4 and 5).
(4) The estimation rule execution unit A4 reads a failure factor definition A4-1 (see FIG. 2) set in advance based on the message type included in the failure notification message.
[0058]
(5) Points are added to the device (suspected failure) in the configuration information according to the content of the failure factor definition described in (4) above. By adding the points in this way, a weighted process is performed on the suspected failure location.
(6) The same processing is repeated for a message notified before the elapse of the message reception waiting time set in the failure factor definition in advance. However, if the weight value exceeds a predetermined threshold, the process ends.
(7) If the message type is not related in the above (4), it is determined to be another cause of the failure, and the same processing as described above is executed. Even if the message type is related, and even if the generator name is not related in the above (3), it is determined as another cause of failure, and the same processing as above is executed.
[0059]
(8) After the elapse of the waiting time, the result of the point addition in (5) above, that is, the result of the weighting process is analyzed, and normality using commands is sequentially checked for devices with higher weighting values, and failure measures are executed. I do.
(9) The result of (8) and the message to which the points are added are stored and managed as a history in the history DB. By doing so, it is possible to analyze the point addition target and the point size, and it is possible to optimize the failure factor definition.
[0060]
As described above, according to the present system, when a failure occurs in a communication device, it is possible to specify a failure factor in which a plurality of messages are associated. In addition, since the failure cause identification logic can be defined based on the message design logic of the communication device, even if a new communication device is introduced or the network configuration is changed, the failure cause identification can be performed simply by changing the definition file. realizable.
[0061]
(Summary)
As described above, in the present system, a plurality of communication device configuration information configuring a communication network is managed, an occurrence location is analyzed for each message notified from the communication device, and a point is added to the failure location of the failure occurrence device. By processing the messages that occur within a certain period of time by narrowing down the failure location, and then responding to the failure at the highest point or at a point that exceeds a certain level are doing. As a result, messages notified from a plurality of communication devices can be processed in a centralized manner, and appropriate failure factors can be efficiently narrowed down.
In addition, by displaying a list of messages in which points have been added to the failure location when identifying the cause, the failure cause identification logic described in the text file can be changed appropriately. It can be changed by the terminal.
[0062]
(Failure factor identification method)
In the above-described failure handling system, the following failure factor identification method is employed. This failure factor identification method will be described with reference to FIG. As shown in the figure, the apparatus is in a waiting state until a failure notification message is received (step S800), and when the failure notification message is received, necessary information is collected (step S800 → S801).
[0063]
As a result of collecting the information, it is determined whether or not the message is related to the previously received message. If not, the process returns to step S800 (step S802 → S800).
Next, a matrix table has already been created, and it is determined whether the table contains any items (step S803). If a matrix table has not been created, or if an item does not exist even if it has been created, a matrix table or its items are created (steps S803 → S804). Thereafter, the process proceeds to the weighting process (steps S804 → S805). If a matrix table has already been created and an item exists, the process directly proceeds to the weighting process (step S803 → S805).
[0064]
In the weighting process, points are added to each item in the table as described above (step S805). As a result of the weighting process, when the weight value exceeds a predetermined threshold, the process ends, and the faulty device is identified (steps S806 → S808).
The above processing is performed until a predetermined waiting time elapses (steps S806 → S807 → S800...) Unless the weighting value exceeds a predetermined threshold. After the elapse of the waiting time, the process ends, and a faulty device is specified (steps S807 → S808), as described above.
[0065]
As described above, in the above-described failure countermeasure system, using the device configuration information indicating the devices configuring the network and the respective components configuring the devices and the failure factor definition information indicating the value of the weight for the failure factor, A failure factor identification method for identifying a failed device has been realized. The failure factor identification method includes a table creation step of creating a table for weighting based on the device configuration information in response to receiving a failure notification message sent from a device configuring the network. A weighting step of weighting each item of the table created in the table creation step based on the failure factor definition information; and a step of specifying a faulty device based on the weighting result of the weighting step.
[0066]
In short, in the present method, in response to receiving a failure notification message sent from a device configuring the network, a table for weighting is created based on the device configuration information, and based on the failure factor definition information. , Each item in the table is weighted, and the faulty device is specified based on the weighting result, so that the faulty device can be easily specified.
[0067]
【The invention's effect】
As described above, in response to the reception of the failure notification message sent from the device configuring the network, a table for weighting is created based on the device configuration information, and based on the failure factor definition information. By using the result of weighting each item in the table, when one of the devices constituting the network fails, the failed device can be easily specified. In particular, even when a new communication device is introduced or the network configuration is changed, the cause of the failure can be efficiently specified only by changing the definition file. In addition, since the occurrence of a message in the related device is sequentially confirmed from one failure notification message, redundant processing that requires confirmation of message generation between the opposite devices is not required.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an embodiment of a failure handling system according to the present invention.
FIG. 2 is a diagram showing a definition of a failure factor used in a weighting process.
FIG. 3 is a diagram illustrating an example of configuration information stored in a configuration information DB.
FIG. 4 is a diagram illustrating a process of creating a matrix table.
FIG. 5 is a diagram illustrating an example of a state in which a weighting process has been completed;
FIG. 6 is a diagram showing a result of weighting.
FIG. 7 is a diagram illustrating a configuration example of a failure notification message.
FIG. 8 is a flowchart showing a failure factor identification method according to the present invention.
FIG. 9 is a diagram illustrating an example of a communication network employing a failure handling system for specifying a failure location when a failure occurs in the communication network.
10 is a block diagram illustrating an example of the internal configuration of the OPS device in FIG.
FIG. 11 is a flowchart illustrating an example of a failure factor estimation rule.
FIG. 12 is a flowchart illustrating an example of a failure factor estimation rule.
[Explanation of symbols]
A1 OPS adapter section
A2 Message analysis processing unit
A3 estimation rule
A4 Estimation rule execution unit
A4-1 Failure factor definition
A5 Configuration information search unit
A6 Configuration information DB
A7 Cause identification and troubleshooting unit
A8 Operation scenario
A9 Working parts group
A10 History DB
D1 to D4 I / O device
N1-1 to N1-3,
N2, N1-1 'to N1-3' communication device
O1-O4, O6 OPS equipment
T1, T2 communication terminal

Claims

Storage means for storing device configuration information indicating devices constituting a network, components constituting the devices, and failure factor definition information indicating a value of a weight for a failure factor, and devices constituting the network In response to the reception of the failure notification message sent from the apparatus, based on the device configuration information, a table creating means for creating a table for weighting, based on the failure factor definition information, by the table creating means A weighting means for weighting each item of the created table, wherein a faulty device is specified based on a result of weighting by the weighting means.

2. The failure handling system according to claim 1, wherein the weighting means performs the weighting within a predetermined waiting time for each failure notification message.

The failure handling system according to claim 1, wherein the weighting unit performs the weighting only when a message related to the failure notification message, which is predetermined for each failure notification message, is received.

The failure handling system according to any one of claims 1 to 3, wherein when the weighting result by the weighting means exceeds a predetermined threshold value, the weighting is terminated and a faulty device is specified.

Failure factor identification that identifies a faulty device by using device configuration information that indicates the devices that make up the network and each part that configures the devices, and failure factor definition information that indicates the value of the weight for the failure factor A method for creating a table for weighting based on the device configuration information in response to receiving a failure notification message sent from a device configuring the network; A weighting step of weighting each item of the table created in the table creation step based on the failure factor definition information, and a step of identifying a faulty device based on the weighting result by the weighting step. Characteristic failure factor identification method.