JP3682778B2 - 故障措置システム、及び、故障要因特定方法 - Google Patents
故障措置システム、及び、故障要因特定方法 Download PDFInfo
- Publication number
- JP3682778B2 JP3682778B2 JP2003159943A JP2003159943A JP3682778B2 JP 3682778 B2 JP3682778 B2 JP 3682778B2 JP 2003159943 A JP2003159943 A JP 2003159943A JP 2003159943 A JP2003159943 A JP 2003159943A JP 3682778 B2 JP3682778 B2 JP 3682778B2
- Authority
- JP
- Japan
- Prior art keywords
- failure
- weighting
- message
- configuration information
- communication device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【発明の属する技術分野】
本発明は故障措置システム、及び、故障要因特定方法に関し、特に、通信ネットワークを構成する複数の通信装置において発生した故障に関する通知を総合的に判断し、適切な故障要因解析を行う故障措置システム、及び、故障要因特定方法に関する。
【0002】
【従来の技術】
従来技術において、通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークは、図9に示されているように構成されている。すなわち、同図において、ネットワークを構成する通信装置N1−1〜N1−3及びN1−1’〜N1−3’並びにN2と、これら通信装置にそれぞれ接続される通信端末T1、T2と、通信媒体を介して各通信装置に接続され、通信装置からの通知(メッセージ)を受信し、または通信装置に指示(コマンド)を送出する通信装置対応のオペレーションサポートシステムを構成するOPS(Operation System)装置O1〜O4と、通信ネットワーク全体を管理する汎用計算機からなるオペレーションサポートシステムを構成するOPS装置O6とを含んで構成されている。
【0003】
さらに、同図に示されている通信ネットワークには、入出力装置D1〜D4が接続されている。これら入出力装置D1〜D4は、OPS装置O6に接続され、オペレーションシステムで受信したメッセージを保守者に対して表示し、または、保守者からのコマンドをオペレーションシステムに入力するために設けられている。
なお、本明細書でいう「故障」は、装置の故障の他、回線の障害等も含むものとする。
【0004】
ここで、図10には、OPS装置O6の内部構成例が示されている。同図において、OPS装置O6は、メッセージの変換等、外部とのインタフェースをなすOPSアダプタ部A1と、メッセージの分析を行うメッセージ分析処理部A2と、後述する推定ルールが記憶されている推定ルール記憶部A3と、推定ルールを実行する推定ルール実行部A4と、ネットワーク構成情報の検索を行う構成情報検索部A5と、通信ネットワークを構成している通信装置についての構成情報を記憶する構成情報DB(Data Base)A6と、故障要因を特定しそれに対応する適切な措置を指示する要因特定・故障措置部A7と、故障回復のための動作シナリオが記憶されている動作シナリオ記憶部A8と、ソフトウェアによって所定の動作を実現するための動作部品群A9と、故障措置結果の履歴を記憶する履歴DB(Data Base)A10とを含んで構成されている。
【0005】
動作部品群A9は、「トラヒック収集」、「診断・試験」、「装置切替・初期設定」、「トラブルチケット発行」等の動作を実現するためのソフトウェアによる部品である。これらの動作は例示にすぎず、その他の必要な動作を実現するためのソフトウェアによる部品が、動作部品群A9に含まれているものとする。
動作シナリオ記憶部A8に記憶されている動作シナリオが、この動作部品群A9のうちの少なくとも1つを動作させることによって、回復措置が自動的に行われる。
【0006】
次に、以上のような構成からなるシステムの動作例について説明する。ここでは、一例として、上記通信ネットワーク内の通信装置同士の間のどこかで故障が発生した場合について、その故障に対する措置について説明する。
故障が発生すると、その旨を示すメッセージがOPS装置O6に通知される。ここでは、故障通知メッセージは、OPS装置O1乃至O4経由で、OPS装置O6に通知される。この通知されたメッセージは、OPSアダプタ部A1において、OPS装置O6で処理可能な情報に変換される。変換されたメッセージは、すべてOPS装置O6内のメッセージ分析処理部A2で内容が分析される。この分析によって、メッセージ種別、装置名、発生時刻等の情報が抽出される。メッセージ分析処理部A2では、メッセージ種別毎に対応の要否を判定し、対応要の場合には対応する推定ルール記憶部A3を参照して推定ルールを決定する。
【0007】
推定ルール実行部A4では、発生時刻の前後t秒間(t:シナリオに記述した変化可能な値)で、当該推定ルール内に予め定義された関連メッセージ発生有無を確認する。メッセージがある場合には、構成情報検索部A5と連携して、装置名をキー情報として構成情報DBA6を検索することにより、そのメッセージが対向通信装置で発生しているかどうかや、上位装置でメッセージが発生しているかどうかを特定し、関連メッセージ発生パターンを分析することで、主要因推定を行い、動作シナリオを決定する。決定された動作シナリオを実行することにより、原則として、保守者の介在なしに故障から回復することができる。
【0008】
ここで、故障要因推定ルールの一例が図11及び図12に示されている。
次に、推定ルール及び動作シナリオの例について図11及び図12を参照して説明する。本例においては、図11に示されているように推定処理を行った後、図12に示されているように回復に必要な措置を行う。なお、本例では、リンク番号「001」、装置名「N1−1」において故障が発生し、故障発生時刻は「yymmddhhmmss」(年月日時分秒それぞれ2桁で表現される)である。
【0009】
まず、図11において、同一通信装置N1−1にシステムダウンのメッセージがあるか判断する(ステップS101)。そのメッセージがあれば図12に移行し、通信装置N1−1対応の再開対応シナリオを起動する(ステップS201)。
図11に戻り、そのメッセージがなければ、次に、同一通信装置N1−1に上位装置(収容パッケージ)故障メッセージがあるか判断する(ステップS102)。そのメッセージがあれば図12に移行し、通信装置N1−1対応の装置診断シナリオを起動する(ステップS202)。
【0010】
図11に戻り、そのメッセージがなければ、次に、同一通信装置N1−1に他リンクの同一種類のメッセージがあるか判断する(ステップS103)。そのメッセージがあれば更に対向通信装置にシステムダウンメッセージがあるか判断する(ステップS104)。そのメッセージがあれば図12に移行し、対向通信装置N2対応の再開対応シナリオを起動する(ステップS203)。
【0011】
図11に戻り、そのメッセージがなければ、次に、対向通信装置に上位装置(収容パッケージ)故障メッセージがあるか判断する(ステップS105)。そのメッセージがあれば図12に移行し、対向通信装置N2対応の故障対応シナリオを起動する(ステップS204)。
図11に戻り、そのメッセージがなければ、次に、対向通信装置側でリンク故障発生のメッセージがあるか判断する(ステップS106)。そのメッセージがあれば図12に移行し、対向通信装置N2対応のリンク故障シナリオを起動する(ステップS205)。
【0012】
ステップS201、S203、S204、S205の各シナリオを起動した場合、その後に措置は終了となる。ステップS202のシナリオを起動した場合、その後にトラブルチケット発行シナリオを起動し、パッケージ交換を保守者に依頼する(ステップS210)。
また、ステップS106において、対向通信装置側でリンク故障発生のメッセージがない場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す(ステップS209)。
【0013】
ステップS103において、同一通信装置N1−1に他リンクの同一種類のメッセージがない場合、図12に移行し、通信装置N1−1対応のリンク故障シナリオを起動する。この場合、最初にリンク閉塞・解除によるリンク初期設定で回復したか判断する(ステップS206)。回復すれば措置は終了となる。
ステップS206において、回復しない場合、リンク試験結果が正常か判断する(ステップS207)。リンク試験結果が正常である場合、トラブルチケット発行シナリオを起動し、ギブアップとして保守者の介入を促す(ステップS209)。一方、リンク試験結果が正常でない場合、トラブルチケット発行シナリオを起動し、保守者の対応を促す(ステップS208)。
【0014】
以上、図11及び図12を参照して説明したように、要因特定・故障措置部A7では、動作シナリオに従って、トラヒック情報収集による影響把握や、診断・試験による要因特定を自動的に実施し、故障要因を特定する。そして、故障要因特定後は、対象装置に対して、初期設定や、系変更・装置切り替え等の故障措置を実施する。トラヒック情報収集や、診断・試験、装置切り替え等の個々の動作は、上述した動作部品群A9として予め準備されている。また、動作部品群を用いた動作が、動作シナリオによって記述されている。そして、要因特定・故障措置部が対象通信装置を指定することにより、対象通信装置へのコマンドを実行することができる。
【0015】
故障措置の結果、ハード装置の交換作業のような、保守者の対応が必要となった場合には、上述したように入出力装置D1からトラブルチケットを発行する。この場合、入出力装置D1の画面にその旨を表示して保守者に報知しても良いし、プリントアウトすることによって保守者に報知しても良い。
また、動作シナリオが決定できなかった場合や、故障回復ができなかった場合にも、上述したように保守者の対応を促すトラブルチケットを通知する。最後に、一連メッセージが通知されることのトリガーとなったメッセージ、決定した動作シナリオ、コマンド実行結果、故障措置結果を履歴DBA10に格納し、故障措置は完了する。
【0016】
なお、OPS装置O6のシステム保守者は、定期的に履歴DBA10内を統計分析し、推定ルール及び動作シナリオの正常性を確認するとともに、動作に不具合がある場合は、テキストベースでの修正を可能とする。すなわち、本例のシナリオは、上述したように、テキストファイルによって構成されているので、シナリオの変更が必要になった場合でも、その内容を容易に修正したり、シナリオ自体を新規に追加したりすることができる。
【0017】
以上のように本システムは、通信ネットワークを構成する複数の通信装置を通信媒体を介して管理する汎用計算機を構成要素としたオペレーションシステムにおける通信ネットワークの監視・保守運用を行うシステムである。そして、通信装置から通知される自律メッセージの情報を利用し、メッセージの関連付けを行い故障の要因を分析し、自動措置を行うものである。
【0018】
本システムでは、個々の通信装置から故障発生時に通知されるメッセージの発生パターンを予め具備し、メッセージ発生パターンによって、予め配備した、措置パターンの中から適切な措置手順を決定する。メッセージの発生パターン及び、措置手順は、予めテキストベースのシナリオとして用意され、メッセージが変更になった場合でも、容易に対応できる。このことにより、故障発生直後に保守者の作業無しに自動で故障要因の分析、故障措置が行える。
【0019】
以上説明した故障要因推定ルールを作成するためには、運用実績や運用経験が必要となる。
ここで、故障事象と故障要因とをマトリクス表にして重み付けを行い、高い診断精度を得る技術が、特許文献1に記載されている。
また、上述したような故障措置を行うための従来技術として、非特許文献1に記載されているものがある。非特許文献1においては、各装置より出力されるメッセージをある一カ所にて集中的に受信し、メッセージの出力順を意識して関連するメッセージを待ち受けて相関を取る方法が記載されている。
【0020】
【特許文献1】
特開平11−119823号公報(要約、[0005])
【非特許文献1】
CD−ROM「電子情報通信学会2002年ソサイエティ大会講演論文集」、社団法人電子情報通信学会、平成14年8月20日、講演番号:B−6−76、「通信移動網オペレーションにおける故障措置自動化の検討」
【0021】
【発明が解決しようとする課題】
従来の故障要因特定方法で用いる故障要因推定ルールは、図11及び図12に示されている運用実績に基づく故障対応フローを基に作成する必要があり、順次通信装置の正常性を判断しながら故障箇所を絞りこむ必要があった。
その場合、既に運用実績があり、故障対応方法がパターン化されている場合には、正確な故障箇所の特定が可能である。しかし、新サービス提供に伴い導入される新規通信装置にあわせて故障要因特定方法を実装する場合には、運用実績がない。このため、想定に基づいて故障要因推定ルールを作成する必要があり、故障自動化ターゲットの絞込みや、その故障対応方法の正確さ、開発効率の面で問題があった。上述した非特許文献1にも同様の問題がある。
【0022】
なお、上述した特許文献1は、故障対応方法がパターン化されていることが前提となるので、上記の問題を解決することはできない。
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的はネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定することのできる故障措置システム、及び、故障要因特定方法を提供することである。
【0023】
【課題を解決するための手段】
本発明の請求項1による故障措置システムは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を記憶する記憶手段(後述する構成情報DBA6及び履歴DBA10に対応)と、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成手段(後述する構成情報検索部A5に対応)と、前記故障要因定義情報に基づいて、前記表作成手段によって作成した表の各項目に重み付けを行う重み付け手段(後述する推定ルール実行部A4に対応)と、を含み、前記重み付け手段による重み付け結果に基づいて故障している装置を特定するようにしたことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、1つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【0024】
本発明の請求項2による故障措置システムは、請求項1において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた待ち合わせ時間内において前記重み付けを行うことを特徴とする。こうすることにより、装置故障によって複数の故障通知メッセージが発生することがあり、そのような場合でも所定待ち合わせ時間内に受信したメッセージを用いて重み付けを行うことができる。
【0025】
本発明の請求項3による故障措置システムは、請求項1又は2において、前記重み付け手段は、前記故障通知メッセージ毎に予め定められた該メッセージに関連するメッセージを受信した場合に限り、前記重み付けを行うことを特徴とする。こうすることにより、関連ある複数の故障通知メッセージを用いて重み付けを行うことができる。
【0026】
本発明の請求項4による故障措置システムは、請求項1乃至3のいずれか1項において、前記重み付け手段による重み付け結果が所定閾値を超えたとき該重み付けを終了して故障している装置を特定することを特徴とする。こうすることにより、所定待ち合わせ時間とは関係なく、所定閾値を超えた場合には、故障している装置を直ちに特定することができる。
【0027】
本発明の請求項5による故障要因特定方法は、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法であって、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、前記故障要因定義情報に基づいて、前記表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、前記重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含むことを特徴とする。こうすることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できる。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、1つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【0028】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
(本システムの構成)
図1は本発明による故障措置システムの実施の一形態を示すブロック図である。同図に示されているように、本実施形態による故障措置システムは、部分Aが従来の構成(図10)とは異なる。すなわち、図1中のメッセージ分析部A2は、故障通知メッセージの分析を行う。また、構成情報検索部A5は、構成情報DBA6から構成情報を読出して、重み付けのためのマトリクス表を作成する。つまり、マトリクス表は予め作成しておくのではなく、故障通知メッセージの受信を契機に作成されることになる。
【0029】
推定ルール実行部A4は、故障要因定義A4−1を読出し、その定義の内容に従って重み付け処理を行う。ここでは、作成したマトリクス表の各項目に、故障要因定義A4−1に従ってポイントを加算することにより、重み付け処理を行う。この重み付け処理は予め定められた一定時間が経過するまでに受信した故障通知メッセージに応答して順次行う。
【0030】
一定時間の経過後、推定ルール実行部A4による重み付け処理結果(ポイント加算結果)は、履歴DBA10に格納される。
以上のように、ポイント加算結果によって重み付けを行うことで、要因特定・故障措置部A7が故障要因、すなわち故障した装置を特定することができる。この要因特定・故障措置部A7は、特定した装置を他の装置に告知するための故障特定メッセージを作成する。
【0031】
要因特定・故障措置部A7によって故障特定メッセージが作成されると、そのメッセージは入力装置D1に表示される。この表示は、ディスプレイ画面への表示に限らず、表示内容を印刷出力しても良い。表示に限らず、何らかの形式でオペレータに告知すれば良い。例えば、表示に代えて、又は表示と共に内容を音声出力しても良い。
なお、動作部品群A9は、「診断・試験」、「装置切替・初期設定」等の動作を実現するためのソフトウェアによる部品である。
【0032】
(故障要因定義)
本システムでは後述するように重み付け処理を行うことで、故障発生箇所を特定する。この重み付け処理に用いる故障要因の定義が図2に示されている。同図においては、メッセージの種別ごとに、ポイント加算箇所及び、加算ポイントが数値で示されている。
本例では、メッセージの種別として、「リンク断」を示すメッセージM001、「パッケージ故障」を示すメッセージM002、「装置異常」を示すメッセージM003、「装置初期設定」を示すメッセージM004、「電源異常」を示すメッセージM005、「呼処理異常」を示すメッセージM006、がある。
【0033】
また、本例では、ポイント加算箇所として、「通信装置」、「電源ユニット」、「通信制御部(ソフトウェア)」、「ユニット」、「パッケージ」、「回線」、がある。ただし、これらに限定されるわけではなく、ネットワークを構成する各通信装置それぞれを構成する各部分がポイント加算箇所となる。
同図に示されているように、「リンク断」を示すメッセージM001が送られてきた場合、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「1」が加算される。
また、「パッケージ故障」を示すメッセージM002が送られてきた場合、「通信装置」にポイント「1」が、「パッケージ」にポイント「2」が、それぞれ加算される。
【0034】
さらにまた、「装置異常」を示すメッセージM003が送られてきた場合、「通信装置」、「ユニット」、「パッケージ」、「回線」、それぞれにポイント「1」が加算される。
同様に、「装置初期設定」を示すメッセージM004が送られてきた場合、「電源ユニット」、「通信制御部(ソフトウェア)」にポイント「1」が、「ユニット」にポイント「2」が、それぞれ加算される。「電源異常」を示すメッセージM005が送られてきた場合、「電源ユニット」にポイント「2」が加算される。「呼処理異常」を示すメッセージM006が送られてきた場合、「通信制御部(ソフトウェア)」にポイント「1」が加算される。
【0035】
なお、図2には、各メッセージM001〜M006の待ち合わせ時間(最大値)が示されている。本例では、メッセージM001、M002及びM003の待ち合わせ時間がそれぞれ20秒、メッセージM004の待ち合わせ時間が30秒、メッセージM005の待ち合わせ時間が60秒、メッセージM006の待ち合わせ時間が10秒、である。この待ち合わせ時間内において、上記のポイント加算による重み付け処理が行われる。
【0036】
さらに、同図には、各メッセージM001〜M006に関連する関連メッセージが示されている。本例では、メッセージM001に関連するメッセージは、メッセージM001、M002及びM004である。また、メッセージM002に関連するメッセージは、メッセージM001及びM004である。さらに、メッセージM003に関連するメッセージは、メッセージM003及びM004である。同様に、メッセージM004に関連するメッセージはメッセージM001、M002、M003及びM005、メッセージM005に関連するメッセージはメッセージM004である。メッセージM006に関連するメッセージはなし(存在しない)である。
関連するメッセージとして定義されていない場合等においては、後述するように、別の故障要因と判断される。
【0037】
(装置構成情報)
構成情報DBA6に記憶されている構成情報の例が図3に示されている。同図は、「N1−1」という通信装置についての構成情報の例を示す図である。同図においては、「N1−1」という通信装置内に、「信号処理ユニット」というユニットが含まれており、さらに、そのユニット内に「信号処理パッケージ00」及び「信号処理パッケージ01」というパッケージが含まれていることが示されている。
【0038】
「信号処理パッケージパッケージ00」には、リンク番号「000」から「007」までのリンクが設けられている。リンク番号「000」、「001」、「002」のリンクは対向通信装置名が「通信装置N2」であり、回線番号はそれぞれ「1」、「2」、「3」である。リンク番号「003」、「004」のリンクは対向通信装置名が「通信装置N1−2」であり、回線番号はそれぞれ「1」、「2」である。リンク番号「005」、「006」、「007」のリンクは対向通信装置名が「通信装置N1−3」であり、回線番号はそれぞれ「1」、「2」、「3」である。
【0039】
「信号処理パッケージパッケージ01」には、リンク番号「008」から「015」までのリンクが設けられている。リンク番号「008」、「009」、「010」のリンクは対向通信装置名が「通信装置N2」であり、回線番号はそれぞれ「4」、「5」、「6」である。リンク番号「011」、「012」のリンクは対向通信装置名が「通信装置N1−2」であり、回線番号はそれぞれ「3」、「4」である。リンク番号「013」、「014」、「015」のリンクは対向通信装置名が「通信装置N1−3」であり、回線番号はそれぞれ「4」、「5」、「6」である。
【0040】
以上のように、装置構成情報は、ネットワークを構成している各通信装置それぞれに対応して用意されており、それら構成情報が構成情報DBA6に記憶されている。この装置構成情報は、テキスト形式で構成されているので、部分的に変更、追加、及び、削除が可能であるので、ネットワークに含まれている装置すなわち装置構成に変更、追加、削除があった場合でも容易に対応することができ、故障要因を特定することができる。
【0041】
(マトリクス表の作成と重み付け処理)
本システムでは、故障通知メッセージを受信したことに応答してマトリクス表を作成し、この作成したマトリクス表を用いて重み付け処理を行う。以下、このマトリクス表の作成及びそれを用いた重み付け処理について説明する。
ネットワークを構成している装置から送られてきた故障通知メッセージにおいて、故障発生装置として「N1−1」、メッセージ種別として「M001」、メッセージ内容として「リンク断 リンク番号000」が含まれている場合、以下のようにマトリクス表(以下、単に「表」と表現することがある)が作成される。すなわち、故障の発生した通信装置N1−1に対応した、図3に示されている装置構成情報について、リンク番号「000」をキーにして検索し、この検索結果に基づいて図4(a)に示されているような表を作成する。
【0042】
同図(a)においては、故障の発生装置「N1−1」、メッセージ種別「M0001」について、作成される重み付け処理のための表が示されている。同図(a)に示されている表には、通信装置「N1−1」、「N2」それぞれについて「通信装置」、「ユニット」、「パッケージ」の各項目があり、さらに「回線#1」の項目がある。なお、故障が発生した装置に対向する装置に関する情報が、装置構成情報に含まれている場合、対向する装置側の構成情報を収集することで、上記のような表を作成する。
【0043】
このように作成した表を用いて重み付け処理が行われる。この重み付け処理は、図2を参照して表中の各項目にポイントを加算することで、行われる。ポイントを加算することにより、図4(b)に示されている状態になる。すなわち、図2を参照すると、メッセージM0001については、「ユニット」、「パッケージ」、「回線」それぞれに「1」ポイントが加算されるため、図4(b)に示されているように、「N1−1」の「ユニット」及び「パッケージ」が「+1」ポイント、「回線#1」が「+1」ポイントになる。
【0044】
この場合、受信したメッセージのメッセージ種別が「M001」であるので、図2に定義されているように、待ち合わせ時間20秒が経過するまでに、関連メッセージ「M001」、「M002」、「M004」のいずれかを受信した場合に、上記のようなポイント加算が行われる。
待ち合わせ時間20秒が経過するまでに、故障発生装置として「N1−2」、メッセージ種別として「M001」、メッセージ内容として「リンク断 リンク番号000」が含まれている故障通知メッセージを受信した場合、以下のように処理される。すなわち、故障の発生した通信装置N1−2に対応した装置構成情報(図示せず)について、リンク番号「000」をキーにして検索し、この検索結果に基づいて表を作成する。
【0045】
故障通知メッセージによっては、故障装置に対向する装置に関する情報が含まれている場合もある。そのような対向装置に関する情報が含まれている場合、対向装置についての装置構成情報を収集する。次に、この故障発生装置に関して収集した情報又は対向装置に関して収集した情報について、上記の表において既に定義されているか(つまり表中にその項目があるか)判定が行われる。
【0046】
この場合、同図(b)の状態において、対向装置である通信装置N2の項目が表に存在するので、その項目は新たに作成されない。これに対し、故障発生装置である通信装置N1−2の項目は表に存在しないので、その項目が新たに作成される。この結果、図4(c)に示されているように、項目が追加された表が作成されることになる。
【0047】
そして、作成した表を用いて重み付け処理が行われる。今回受信したメッセージ種別が「M001」であるので、図2を参照すると、メッセージM0001については、「ユニット」、「パッケージ」、「回線」それぞれに「1」ポイントが加算されるため、図4(d)に示されているように、「N1−2」の「ユニット」及び「パッケージ」が「+1」ポイント、「回線#2」が「+1」ポイントになる。
【0048】
以下同様に、待ち合わせ時間内に故障通知メッセージを受信した場合、定義されていない項目が表に追加され、重み付け処理が行われる。重み付け処理の完了した状態の例が図5に示されている。同図においては、障害の発生した「発生装置」として、「N1−1」、「N1−2」、「N1−3」、「N2」が示されている。
【0049】
通信装置N1−1において障害が発生し、リンク断を示すメッセージM001が通信装置N1−1から送られてきた場合、上述した故障要因定義(図2参照)に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「1」が加算されることになる。本例では、通信装置N1−1の「ユニット」、「パッケージ」及び「回線#1」にそれぞれポイント「1」が加算される。リンク断を示すメッセージM001が通信装置N1−2、N1−3からそれぞれ送られてきた場合も同様に、通信装置N1−2の「ユニット」、「パッケージ」及び「回線#2」、通信装置N1−3の「ユニット」、「パッケージ」及び「回線#3」にそれぞれポイント「1」が加算される。
【0050】
また、通信装置N2において障害が発生し、パッケージ故障を示すM002が通信装置N2から送られてきた場合、上述した故障要因定義(図2参照)に従い、「通信装置」にポイント「1」が、「パッケージ」にポイント「2」が、それぞれ加算されることになる。本例では、通信装置N2の「通信装置」にポイント「1」が、「パッケージ」にポイント「2」が、それぞれ加算される。
【0051】
さらに、リンク断を示すメッセージM001が通信装置N2から3回送られてきた場合、上述した故障要因定義(図2参照)に従い、「ユニット」、「パッケージ」及び「回線」にそれぞれポイント「1」が加算されることになる。本例では、通信装置N2の「ユニット」及び「パッケージ」にポイント「1」が、3回加算される。さらに、本例では、「回線#1」、「回線#2」、「回線#3」にそれぞれポイント「1」が加算される。
【0052】
以上のように、故障通知メッセージの受信を契機に、図3に示されている各通信装置の構成情報(通信装置内のユニット、パッケージ、回線収容情報等)が構成情報DBA6から読出される。そして、メッセージ発生元通信装置の構成情報と、メッセージ内情報を元に読出した対向の通信装置とを関連付けた情報として、図5に示されている重み付け結果の表が図示せぬメモリ上に作成される。この図5に示されている重み付け結果に基づいて、故障発生箇所が特定されるのである。
【0053】
(故障箇所の特定)
以上のようにポイントを加算して重み付けした結果が、図6に示されている。同図は、ポイントを加算して重み付けした結果を概念的に示したものである。同図を参照すると、通信装置N2はポイントが「+1」、通信装置N2内のユニットはポイントが「+3」、そのユニット内のパッケージ00はポイントが「+5」である。また、通信装置N1−1内のユニット、通信装置N1−2内のユニット、通信装置N1−3内のユニットは、それぞれポイントが「+1」である。それら通信装置N1−1、N1−2、N1−3内の各パッケージ00はポイントが「+1」である。
【0054】
さらに、通信装置N2のユニット内のパッケージ00の「リンク000」と通信装置N1−1のユニット内のパッケージ00の「リンク000」とを接続している回線#1はポイントが「+2」である。通信装置N2のユニット内のパッケージ00の「リンク001」と通信装置N1−2のユニット内のパッケージ00の「リンク000」とを接続している回線#2はポイントが「+2」である。通信装置N2のユニット内のパッケージ00の「リンク002」と通信装置N1−3のユニット内のパッケージ00の「リンク001」とを接続している回線#3はポイントが「+2」である。
【0055】
以上の結果から、通信装置N2内のユニット内のパッケージ00がポイント「+5」で最も重み付け値が大きい。このため、このパッケージ00が故障発生箇所と特定することができる。
以上のように、待ち合わせ時間の経過後、重み付け値が最も大きい部分を故障発生箇所として特定する。ただし、待ち合わせ時間の経過前であっても、重み付け値が所定の閾値を超えた場合は、その重み付け値が超えた部分を故障発生箇所として特定する。
【0056】
(本システム全体の動作)
図1に戻り、上記の構成からなる本実施形態の故障措置システムの動作について説明する。
(1)故障通知メッセージは、OPS装置O1、O2からOPSアダプタ部A1経由で、OPS装置O6に通知される。この故障通知メッセージは、図7に示されているように、故障の発生した発生装置名71、そのメッセージのメッセージ種別72、メッセージ内容73、故障の発生時刻74、を含んで構成されている。
【0057】
(2)OPS装置O6に通知された故障通知メッセージは、すべてメッセージ分析処理部A2でその内容が分析される。これにより、上述した、発生装置名、メッセージ種別、メッセージ内容、発生時刻の各情報が抽出される。
(3)構成情報検索部A5は、故障通知メッセージに含まれている、発生装置名に基づいて、関連する構成情報(図3参照)を、構成情報DBA6から読出すことにより、重み付け処理のためのマトリクス表(図4及び図5参照)を作成する。
(4)推定ルール実行部A4は、故障通知メッセージに含まれている、メッセージ種別に基づいて、予め設定してある故障要因定義A4−1(図2参照)を読出す。
【0058】
(5)上記(4)において説明した故障要因定義の内容にしたがって、構成情報内の装置(故障被疑箇所)に対して、ポイントを加算していく。このようにポイントを加算することで、故障被疑箇所に重み付け処理を行う。
(6)予め故障要因定義に設定してあるメッセージ受信の待ち合わせ時間が経過するまでの間に通知されるメッセージに対して同様の処理を繰り返す。ただし、重み付け値が、予め定められた閾値を超えた場合は、処理は終了となる。
(7)上記(4)でメッセージ種別が関連しない場合は、別の故障要因と判断して、上記と同様の処理を実行する。また、メッセージ種別が関連した場合であっても、上記(3)において発生装置名が関連なかった場合においても、別の故障要因と判断して、上記と同様の処理を実行する。
【0059】
(8)待ち合わせ時間経過後に、上記(5)のポイント加算結果、すなわち重み付け処理結果を分析し、重み付け値の高い装置に対して順次、コマンドを用いた正常性の確認、及び、故障措置を実行する。
(9)上記(8)の結果及び、ポイントを加算したメッセージは履歴として履歴DBに保存して管理する。こうすることにより、ポイント加算対象や、ポイントの大小を分析可能とし、故障要因定義の適正化を行うことができる。
【0060】
以上のように本システムによれば、通信装置の故障が発生した場合、複数のメッセージを関連付けた故障要因特定を行うことができる。また、故障要因特定論理は、通信装置のメッセージ設計論理に基づいて定義できるため、新規通信装置の導入やネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的な故障要因特定を実現できる。
【0061】
(まとめ)
以上のように本システムでは、通信ネットワークを構成する複数の通信装置構成情報を管理し、通信装置から通知されるメッセージ毎に発生箇所を分析し、故障発生装置の故障箇所にポイントを加算していくことで、故障箇所の絞りこみを行い、一定時間に発生する複数のメッセージの処理を実施した後で、ポイントの最上位または、一定レベルを超えている箇所に対して、故障の対応を実施している。これにより、複数の通信装置から通知されるメッセージを一元的に処理し、適切な故障要因のしぼりこみが、効率的に実現できる。
なお、要因特定時に故障箇所にポイントを加算したメッセージを一覧として表示することで、テキストファイルに記載した故障要因特定ロジックを適切に変更できるので、加算する対象、及び、そのポイントを、本システムの端末により変更することができる。
【0062】
(故障要因特定方法)
上述した故障措置システムにおいては、以下のような故障要因特定方法が採用されている。この故障要因特定方法について、図8を参照して説明する。同図に示されているように、故障通知メッセージを受信するまでは待ち状態であり(ステップS800)、故障通知メッセージを受信した場合に、必要な情報が収集される(ステップS800→S801)。
【0063】
情報を収集した結果、以前受信したメッセージと関連するか判断され、関連しない場合は、ステップS800に戻る(ステップS802→S800)。
次に、既にマトリクス表が作成され、表中に項目が含まれているか判断される(ステップS803)。マトリクス表が作成されていない場合、又は作成されていても項目が存在しない場合、マトリクス表又はその項目を作成する(ステップS803→S804)。その後、重み付け処理に移行する(ステップS804→S805)。マトリクス表が既に作成され、かつ、項目が存在する場合、そのまま重み付け処理に移行する(ステップS803→S805)。
【0064】
重み付け処理においては、上述したように、表の各項目にポイントを加算する(ステップS805)。この重み付け処理の結果、重み付け値が予め定められた閾値を超えた場合、処理は終了となり、故障装置が特定される(ステップS806→S808)。
以上の処理は、重み付け値が予め定められた閾値を超えない限り、予め定められた待ち合わせ時間を経過するまで行われる(ステップS806→S807→S800…)。待ち合わせ時間が経過した後、上記と同様に、処理は終了となり、故障装置が特定される(ステップS807→S808)。
【0065】
このように、上述した故障措置システムでは、ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法が実現されている。そして、この故障要因特定方法は、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、故障要因定義情報に基づいて、表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含んでいる。
【0066】
要するに本方法では、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、表の各項目に重み付けを行い、その重み付け結果に基づいて故障している装置を特定するので、故障した装置を容易に特定できるのである。
【0067】
【発明の効果】
以上説明したように、ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、装置構成情報に基づいて、重み付けのための表を作成し、故障要因定義情報に基づいて、その表の各項目に重み付けを行った結果を用いることにより、ネットワークを構成する装置のいずれかが故障した場合に、その故障した装置を容易に特定できるという効果がある。特に、新規通信装置の導入や、ネットワーク構成を変更した場合でも、定義ファイルを変更するのみで、効率的に故障要因を特定できる。また、1つの故障通知メッセージから順次関連装置でのメッセージ発生有無を確認するため、対向装置間で、お互いにメッセージ発生確認を必要とするような重複した処理が不要となる。
【図面の簡単な説明】
【図1】本発明による故障措置システムの実施の一形態を示すブロック図である。
【図2】重み付け処理に用いる故障要因の定義を示す図である。
【図3】構成情報DBに記憶されている構成情報の例を示す図である。
【図4】マトリクス表の作成過程を説明する図である。
【図5】重み付け処理の完了した状態の例を示す図である。
【図6】重み付けした結果を示す図である。
【図7】故障通知メッセージの構成例を示す図である。
【図8】本発明による故障要因特定方法を示すフローチャートである。
【図9】通信ネットワーク内で故障が発生した場合に故障箇所を特定するための故障措置システムを採用した通信ネットワークの例を示す図である。
【図10】図9中のOPS装置の内部構成例を示すブロック図である。
【図11】故障要因推定ルールの一例を示すフローチャートである。
【図12】故障要因推定ルールの一例を示すフローチャートである。
【符号の説明】
A1 OPSアダプタ部
A2 メッセージ分析処理部
A3 推定ルール
A4 推定ルール実行部
A4−1 故障要因定義
A5 構成情報検索部
A6 構成情報DB
A7 要因特定・故障措置部
A8 動作シナリオ
A9 動作部品群
A10 履歴DB
D1〜D4 入出力装置
N1―1〜N1―3、
N2、N1―1’〜N1―3’ 通信装置
O1〜O4、O6 OPS装置
T1、T2 通信端末
Claims (5)
- ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を記憶する記憶手段と、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成手段と、前記故障要因定義情報に基づいて、前記表作成手段によって作成した表の各項目に重み付けを行う重み付け手段と、を含み、前記重み付け手段による重み付け結果に基づいて故障している装置を特定するようにしたことを特徴とする故障措置システム。
- 前記重み付け手段は、前記故障通知メッセージ毎に予め定められた待ち合わせ時間内において前記重み付けを行うことを特徴とする請求項1記載の故障措置システム。
- 前記重み付け手段は、前記故障通知メッセージ毎に予め定められた該メッセージに関連するメッセージを受信した場合に限り、前記重み付けを行うことを特徴とする請求項1又は2記載の故障措置システム。
- 前記重み付け手段による重み付け結果が所定閾値を超えたとき該重み付けを終了して故障している装置を特定することを特徴とする請求項1乃至3のいずれか1項に記載の故障措置システム。
- ネットワークを構成している装置及びそれら装置を構成している各部分を示す装置構成情報及び故障要因に対する重み付けの値を示す故障要因定義情報を用いて、故障している装置を特定する故障要因特定方法であって、前記ネットワークを構成している装置から送られてくる故障通知メッセージの受信に応答して、前記装置構成情報に基づいて、重み付けのための表を作成する表作成ステップと、前記故障要因定義情報に基づいて、前記表作成ステップにおいて作成した表の各項目に重み付けを行う重み付けステップと、前記重み付けステップによる重み付け結果に基づいて故障している装置を特定するステップとを含むことを特徴とする故障要因特定方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003159943A JP3682778B2 (ja) | 2003-06-04 | 2003-06-04 | 故障措置システム、及び、故障要因特定方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003159943A JP3682778B2 (ja) | 2003-06-04 | 2003-06-04 | 故障措置システム、及び、故障要因特定方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004363946A JP2004363946A (ja) | 2004-12-24 |
JP3682778B2 true JP3682778B2 (ja) | 2005-08-10 |
Family
ID=34052869
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003159943A Expired - Lifetime JP3682778B2 (ja) | 2003-06-04 | 2003-06-04 | 故障措置システム、及び、故障要因特定方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3682778B2 (ja) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5428934B2 (ja) | 2010-02-22 | 2014-02-26 | 富士通株式会社 | 障害パターン生成プログラムおよび障害パターン生成装置 |
JP5802152B2 (ja) * | 2012-03-06 | 2015-10-28 | 株式会社Nttドコモ | 通信網監視システム、監視装置および通信網監視方法 |
JP6378653B2 (ja) * | 2015-07-30 | 2018-08-22 | 日本電信電話株式会社 | サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法 |
JP2018157292A (ja) * | 2017-03-16 | 2018-10-04 | ソフトバンク株式会社 | ネットワーク調査装置、ネットワーク調査方法、及びプログラム |
CN113328872B (zh) | 2020-02-29 | 2023-03-28 | 华为技术有限公司 | 故障修复方法、装置和存储介质 |
WO2024127474A1 (ja) * | 2022-12-12 | 2024-06-20 | 日本電信電話株式会社 | アラーム情報更新装置、アラーム情報更新方法、及びプログラム |
-
2003
- 2003-06-04 JP JP2003159943A patent/JP3682778B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2004363946A (ja) | 2004-12-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100405311C (zh) | 用于计算机系统中的多个分区的错误监视的方法 | |
US20080065928A1 (en) | Technique for supporting finding of location of cause of failure occurrence | |
CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
JP4948679B1 (ja) | サーボ制御装置の異常診断装置および異常診断システム | |
JP4598065B2 (ja) | 監視シミュレーション装置,方法およびそのプログラム | |
EP2360590A2 (en) | Apparatus and method for analysing a computer infrastructure | |
JP6655001B2 (ja) | 故障対応支援サーバー及び故障対応支援方法 | |
CN101127003A (zh) | 收集数据的方法、装置和系统 | |
CN101388808B (zh) | 一种基于简单网络管理协议的trap处理方法 | |
JP2019057139A (ja) | 運用管理システム、監視サーバ、方法およびプログラム | |
JP2019049802A (ja) | 障害解析支援装置、インシデント管理システム、障害解析支援方法及びプログラム | |
CN110855489B (zh) | 故障处理方法、装置和故障处理装置 | |
JP2006190138A (ja) | アラーム管理装置及びアラーム管理方法及びプログラム | |
JP3682778B2 (ja) | 故障措置システム、及び、故障要因特定方法 | |
CN115037597A (zh) | 一种故障检测方法及设备 | |
JP4842738B2 (ja) | 障害管理支援システム及びその情報管理方法 | |
JP2014228932A (ja) | 障害通知装置、障害通知プログラムならびに障害通知方法 | |
CN115102838B (zh) | 服务器宕机风险的应急处理方法和装置、电子设备 | |
CN110095144A (zh) | 一种终端设备本地故障识别方法及系统 | |
JP3867868B2 (ja) | 障害統合管理装置 | |
JP2014078067A (ja) | データベースシステム、データベース装置、データベースの障害回復方法およびプログラム | |
JP3019789B2 (ja) | 監視装置 | |
JP4437102B2 (ja) | 設備故障判定システム、方法、プログラム、及び記録媒体 | |
JP2004080297A (ja) | 故障措置システム、及び、故障措置方法 | |
JP2630255B2 (ja) | ネットワーク障害表示復旧方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050428 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050510 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050518 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3682778 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090603 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100603 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100603 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110603 Year of fee payment: 6 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120603 Year of fee payment: 7 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120603 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130603 Year of fee payment: 8 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |