JP2010045624A - 保守システム - Google Patents

Abstract

【課題】被監視装置の構造に起因する障害の原因を特定し、被監視装置の構造に起因する障害を未然に防ぐこと。
【解決手段】保守センタ（ＯＰＥ）は、各無線ネットワーク制御装置（ＲＮＣ）から、ＲＮＣを構成する各カードのソフトウェアの版数やハードウェア版数などの構成情報を取得し、その構成情報を蓄積する。ＯＰＥは、障害が発生したＲＮＣから障害情報を取得し、その障害情報を蓄積する。ＯＰＥは、蓄積した構成情報と障害情報に基づいて障害の原因を解析し、障害の原因となるカードとそのソフトウェアの版数やハードウェア版数を特定する。ＯＰＥは、予防保全のため、障害の原因を保守者へ通知する。また、障害が発生したＲＮＣ、同じ障害の原因を有する運用中または運用中でない他のＲＮＣにおいて、障害箇所の切り離しと、冗長構成への切り替えが行われる。
【選択図】図３

Description

この発明は、複数の処理ブロックを備えた複数の被監視装置が存在する環境に対する保守システムに関する。

従来、移動通信網における通信品質の指標の測定結果に対し、その統計的信頼度を考慮して異常度を算出し、異常度に応じた保全を行うシステムが提案されている。このシステムでは、移動通信網におけるネットワーク管理装置は、正常稼動時における通信品質の指標を保持し、無線基地局制御装置から定期的に通信品質の測定結果の入力を受ける。測定結果として、無線セル毎の接続要求回数ａに対する接続失敗回数ｆが得られた場合、正常時の呼損率をｐ０として接続失敗回数がｆよりも大きくなる二項分布の上側確率Ｂを求める。この上側確率Ｂの負対数を異常度のスコアとし、異常度のスコアが予め定めた閾値を上回る場合には通信の異常と検出する。この後、算出した異常度のスコアに応じた保全制御が行われ、通信システムの障害が適切に回避される（例えば、特許文献１参照。）。

また、多数の設備から連鎖的にアラームが発生し、かつ複数の事象の多重発生を想定しなければならない場合に、多数のアラームの中から発生事象に直接的に関連する重要アラームを選別するシステムが提案されている。このシステムでは、設備相互関連学習手段は、監視対象の設備に含まれる各エレメントで発生した多数のアラーム信号の発生履歴の同期性から相関のあるアラームを選択した相関データと、連鎖的に発生するアラームの同時発生頻度データを用い、相互関連データを作成後、重要アラーム選別手段へ供給する。重要アラーム選別手段は相互関連データをもとにして、障害で発生したアラームパターン中で故障原因であるアラームだけを選別し、他の入力アラームを抑制し、重要アラームを表示手段に供給する（例えば、特許文献２参照。）。

特開２００６−３４００５０号公報 特開平８−２８８９４４号公報

しかしながら、上記に開示されたシステムでは、故障部品のメーカや版数やＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）の傾向を調査して障害の傾向を分析するものではないため、障害の原因が装置の構造にある場合、その原因を特定することができないという問題点がある。また、故障部品のメーカや版数やＬＳＩの傾向によって同様の故障が起こるおそれのある部品を的確に特定することができないため、他の装置において同様の故障が発生するのを未然に防ぐことができないという問題点がある。

複数の処理ブロックを備えた複数の被監視装置が存在する環境において、被監視装置の構造に起因する障害の原因を特定することができる保守システムを提供することを目的とする。また、複数の処理ブロックを備えた複数の被監視装置が存在する環境において、被監視装置の構造に起因する障害を未然に防ぐことができる保守システムを提供することを目的とする。

この保守システムは、複数の処理ブロックを備えた複数の被監視装置を監視装置が監視して保守するシステムである。保守システムは、構成情報収集部、障害情報収集部および特定部を備えている。構成情報収集部は、複数の被監視装置から、各被監視装置の処理ブロックの構成情報を収集する。障害情報収集部は、複数の被監視装置から、各被監視装置で発生した障害に関する障害情報を収集する。特定部は、収集された構成情報および収集された障害情報に基づいて、障害の原因となる処理ブロックの構成を特定する。

従って、構成情報収集部により、複数の被監視装置の構成情報が収集され、障害情報収集部により、複数の被監視装置の障害情報が収集され、特定部により、障害の原因となる処理ブロックの構成が特定される。その特定された構成と同じ構成を有する他の被監視装置に対して、同様の障害が発生する前に部品交換やソフトウェアの変更を行うことが可能となる。

この保守システムによれば、被監視装置の構造に起因する障害の原因を特定することができるという効果を奏する。また、被監視装置の構造に起因する障害を未然に防ぐことができるという効果を奏する。

以下に添付図面を参照して、この保守システムの好適な実施の形態を詳細に説明する。特に限定しないが、ここでは、保守システムを携帯電話などの無線通信システムの保守に適用した場合について説明する。

（概略）
図１は、無線通信システムの構成の一例を示す概略図である。図１に示すように、無線通信システムは、無線ネットワーク１、コアネットワーク２、保守センタ（ＯＰＥ：ＯＰｅｒａｔｉｏｎ Ｅｑｕｉｐｍｅｎｔ）３および開発メーカ各社のサーバ（以下、開発元サーバとする）４により構成されている。無線ネットワーク１は、携帯電話機等のユーザ端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）５、無線基地局装置（ＢＴＳ：Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ）６、アンテナ等の通信タワー７および無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）８を備えている。コアネットワーク２は、移動マルチメディア交換装置（ＭＭＳ：Ｍｏｂｉｌｅ Ｍｕｌｔｉｍｅｄｉａ ｓｗｉｔｃｈｉｎｇ Ｓｙｓｔｅｍ）９および公衆網１０を備えている。

移動マルチメディア交換装置９、無線ネットワーク制御装置８および無線基地局装置６は、ピラミッドの階層構造をなしている。保守センタ３は、監視装置として、被監視装置である移動マルチメディア交換装置９、無線ネットワーク制御装置８および無線基地局装置６を監視し、それらの保守および運用を行う。日本国内には、例えば１０００を超える数の無線ネットワーク制御装置が存在する。無線ネットワーク制御装置は、制御部（ＣＰ）、処理部（ＦＢ）および回線部（ＩＦ）などの種々のブロックが組み合わされる。各処理ブロックは、無線ネットワーク制御装置に着脱可能なカードとして提供されている。各無線ネットワーク制御装置は、冗長構成を含めて、例えば２００枚を超えるカードを搭載している。

無線ネットワーク制御装置には、新たな通信技術に対応することや、長期間安定して運用を継続することが要求される。そのため、ソフトウェアが変更されたり、カードが追加や変更されることがある。また、故障した箇所を切り離したり、交換する必要がある。長期間の運用中には、部品の生産が終了し、在庫がなくなることがある。そのような場合には、部品の交換によって、異なる無線ネットワーク制御装置間で異なる種類の部品が使用されたり、同一の無線ネットワーク制御装置において異なる種類の部品が使用されることになる。このようなことは、無線基地局装置や移動マルチメディア交換装置においても同様である。

図２および図３は、実施の形態にかかる保守システムの概略を示す説明図である。以下の説明では、被監視装置として無線ネットワーク制御装置を例にして説明するが、被監視装置が無線基地局装置や移動マルチメディア交換装置である場合も同様である。図２に示すように、保守センタは、監視対象の各無線ネットワーク制御装置から、無線ネットワーク制御装置を構成する各カードの構成情報を取得し、その構成情報を蓄積する。その構成情報としては、例えばＣＰ、ＦＢおよびＩＦなどのカード名称、そのカードの搭載位置、そのカードで実行されるソフトウェアの版数、そのカードを構成するハードウェアの版数および製造番号などの、障害の原因を特定するための解析に必要な情報である。

また、図３に示すように、保守センタは、障害が発生した無線ネットワーク制御装置から障害情報を取得し、その障害情報を蓄積する。そして、保守センタは、蓄積した構成情報と障害情報に基づいて障害の原因を解析し、障害の原因を特定する。例えば、図３に示す例では、今回、制御リンク断が発生したＲＮＣ＃０では、過去にも制御リンク断が発生している。運用中の他のＲＮＣ＃８では、制御リンク断が発生していない。ＲＮＣ＃０の今回と過去の障害発生時のカード構成と、ＲＮＣ＃８のカード構成とを比較すると、処理部（ＦＢ）カードのソフトウェアの版数が異なっている。従って、保守センタにおいて、処理部（ＦＢ）カードの被疑レベルが高く（Ｈ：Ｈｉｇｈ）、かつ処理部（ＦＢ）カードのソフトウェアの版数（同図に、太線で囲む箇所）が故障の原因であるという分析結果が導き出される。被疑レベルについては、Ｈ（またはＨｉｇｈ）、Ｍ（またはＭｉｄｄｌｅ）、Ｌ（またはＬｏｗ）の順で、障害の原因であることの確度が低くなる。

保守センタは、予防保全のため、この分析結果を通信事業者などの保守者へ通知する。また、この分析結果に基づいて、障害が発生しているＲＮＣ＃０において、障害箇所の切り離しと、冗長構成への切り替えが行われる。同様に、障害原因とされたソフトウェアの版数と同じ版数のソフトウェアを使用している運用中の他のＲＮＣ（図３には示されていない）および運用中でない他のＲＮＣ＃９においても、障害箇所の切り離しと、冗長構成への切り替えが行われる。

（保守センタのハードウェア構成）
図４は、実施の形態にかかる保守センタのハードウェア構成を示す説明図である。図４に示すように、保守センタ３は、中央処理装置２１、作業領域として用いられるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの主記憶装置２２、専用ネットワーク向けＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェース２３、保守者向けＬＡＮインタフェース２４およびハードディスクや磁気テープなどの補助記憶装置２５を備えている。専用ネットワーク向けＬＡＮインタフェース２３は、専用ネットワーク３１との接続を制御する。専用ネットワーク３１には、無線基地局装置６、無線ネットワーク制御装置８、移動マルチメディア交換装置９および開発元サーバ４などが接続されている。保守者向けＬＡＮインタフェース２４は、保守端末ネットワーク２６との接続を制御する。保守端末ネットワーク２６には、保守者端末２７が接続されている。

（保守センタの構成）
図５は、実施の形態にかかる保守センタの構成を示す説明図である。図５に示すように、保守センタ３は、カード情報収集部４１、障害情報収集部４２、詳細対応情報収集・展開部４３、構造的障害切り分け部４４、対象装置抽出部４５、装置制御部４６、ダウンロード制御部４７および保守者通知部４８の各処理部を備えている。これら各処理部は、中央処理装置２１が保守用のソフトウェアを実行することにより実現される。保守用のソフトウェアは、例えば主記憶装置２２または補助記憶装置２５に格納されている。また、保守センタ３は、カード情報５１、障害履歴情報５２、ハードウェア版数−詳細対応情報５３、障害判定パラメータ５５、装置状態５６、ダウンロードデータ５７およびソフトウェア版数変更可否情報５８の各データベースを備えている。これら各データベースは、補助記憶装置２５に格納されている。主記憶装置２２の作業領域には、障害分析領域５４が展開される。なお、図５において、実線の矢印は、制御の流れを示し、破線の矢印は、情報の流れを示す（図１５においても同じ）。

カード情報収集部４１は、カード情報インタフェース６１を介して、図示省略した各無線ネットワーク制御装置から、各無線ネットワーク制御装置が搭載する全カードの情報を収集する。カード情報収集部４１は、構成情報収集部としての処理を行う。収集された全カードの情報は、カード情報５１に格納される。図６に、カード情報５１のデータ構成の一例を示す。図６に示すように、カード情報５１には、例えば、カードを搭載している装置、その装置におけるカードの搭載位置、そのカードの名称、そのカードを製造したメーカの名称、そのカードで実行されるソフトウェアの版数およびそのカードを構成するハードウェアの版数の各情報がカードごとに格納される。カード情報５１は、各無線ネットワーク制御装置のカードの構成が変更されるたびに、更新される。

障害情報収集部４２は、障害情報インタフェース６２を介して、図示省略した各無線ネットワーク制御装置から、各無線ネットワーク制御装置で発生した障害の情報を収集する。障害情報収集部４２は、障害情報収集部としての処理を行う。収集された障害の情報は、障害履歴情報５２に格納される。図７に、障害履歴情報５２のデータ構成の一例を示す。図７に示すように、障害履歴情報５２には、例えば、障害の発生時刻、障害の分類、障害が発生した装置、その装置における被疑カードの搭載位置、被疑レベル、その被疑カードの名称、その被疑カードを製造したメーカの名称、その被疑カードで実行されるソフトウェアの版数およびその被疑カードを構成するハードウェアの版数の各情報が障害の発生ごとに格納される。障害履歴情報５２は、無線ネットワーク制御装置から障害の情報を受信するたびに、更新される。被疑カードとは、障害の原因であると疑われるカードのことを意味する。

詳細対応情報収集・展開部４３は、例えば、開発元サーバ４のハードウェア版数−詳細対応情報７１から詳細対応情報通知部７２を介して、各カードに使用されている部品の詳細情報を収集する。収集された詳細情報は、ハードウェア版数−詳細対応情報５３に格納される。図８に、ハードウェア版数−詳細対応情報５３のデータ構成の一例を示す。図８に示すように、ハードウェア版数−詳細対応情報５３には、例えば、カードを製造したメーカの名称、そのカードの名称およびそのカードを構成するハードウェアの版数、並びにそのカードに実装されている全部品について、種別、製造したメーカの名称、型番および固有情報がカードごとに格納される。このハードウェア版数−詳細対応情報５３は、ハードウェアの版数をキーとして詳細情報を索引することができるようになっているとよい。ハードウェア版数−詳細対応情報５３は、任意に更新される。また、詳細対応情報収集・展開部４３は、障害の原因を解析する際に、部品の詳細情報を展開する。

カード情報５１、障害履歴情報５２およびハードウェア版数−詳細対応情報５３は、障害分析領域５４に展開され、障害の解析に供せられる。図９に、障害分析領域５４のデータ構成の一例を示す。図９に示すように、障害分析領域５４には、例えば、障害の有無、障害の発生時刻、障害の分類、障害が発生した装置、装置におけるカードの搭載位置、被疑レベル、カードの名称、カードを製造したメーカの名称、カードで実行されるソフトウェアの版数およびカードを構成するハードウェアの版数、並びにカードに実装されている全部品について、種別、製造したメーカの名称、型番および固有情報がカードごとに展開される。障害分析領域５４は、無線ネットワーク制御装置から障害の情報を受信するたびに、更新される。障害分析領域５４には、被疑カードだけではなく、正常なカードの情報も展開される。

構造的障害切り分け部４４は、障害分析領域５４および障害判定パラメータ５５に基づいて、障害の原因を解析し、無線ネットワーク制御装置の構造が原因である障害と、そうでない障害とを区別する。図１０に障害判定パラメータ５５のデータ構成の一例を示す。図１０に示すように、障害判定パラメータ５５には、例えば、処理部（ＦＢ）カードのソフトウェアの版数などの判定の対象、ｘｘ障害（例えば、制御リンク断）などの障害の種別および判定の基準となるパラメータが判定の対象と障害の種別の組み合わせごとに格納される。パラメータとしては、例えば、「障害検出数／運用数」、「障害検出数／障害検出版数」および「障害検出版数／運用数」が用意される。

「障害検出数／運用数」は、検出された障害の原因が構造にあると疑うに十分な、全体の運用数に対する障害検出数の割合を規定し、例えば、適当な数値○を用いて○％以上と定義される。障害検出数とは、実際に障害が検出されたカードの数のことである。運用数とは、運用されているカードの数のことである。「障害検出数／運用数」の値が○％以上であれば、検出された障害の原因が構造にあると判断される。○の値が小さいと、障害の原因が構造にあるのか、そうではなくて部品などの突発的な故障が原因であるのか、ということを判断することができない。一方、○の値が大きいと、障害の原因が構造にあると判断するタイミングが遅れ、同様の障害が広範囲に及んでしまう。これらを考慮して、○の値は、適切に設定される。

「障害検出数／障害検出版数」は、検出された障害が、障害検出版数に依存した障害であると判断することができる、障害検出版数に対する障害検出数の割合を規定し、例えば、適当な数値△を用いて△％以上と定義される。障害検出版数とは、検出された障害の原因となる構成と同じ構成を有するカードの数のことである。つまり、障害検出版数は、実際に障害が検出されたカードの数と、未だ障害は検出されていないが、将来、障害が検出されたカードと同じ原因で障害が発生する可能性のあるカードの数を足した数である。「障害検出数／障害検出版数」の値が△％以上であれば、検出された障害が、障害検出版数に依存した障害であると判断される。障害が発生する確率は、ネットワークの負荷や部品の特性やタイミングなどの影響により異なるので、これらを考慮して、△の値は、適切に設定される。

「障害検出版数／運用数」は、検出された障害の原因となる構成と同じ構成を有するカードと、検出された障害の原因となる構成と同じ構成を有していないカードとが混在している状況において、検出された障害の原因が構造にあるか否かの最適な判断を行なうための、全体の運用数に対する障害検出版数の割合を規定し、例えば、適当な数値□を用いて□％未満と定義される。「障害検出版数／運用数」の値が□％未満であれば、適切な判断を行うことができる。運用されているカードの全てが、検出された障害の原因となる構成と同じ構成を有するカードである場合には、適切な判断を行うことができない。これらを考慮して、□の値は、適切に設定される。

前記○、△および□の各値は、判定の対象ごとに設定され、任意に更新されるようになっている。また、カードの出荷開始直後、および出荷後、ある程度の期間が経過した後の安定期では、前記○、△および□の各値を変更することができるようになっていてもよい。さらに、運用者である通信事業者または開発メーカが前記○、△および□の各値を随時提供し、それを障害判定パラメータ５５に反映するようになっていてもよい。

対象装置抽出部４５は、障害分析領域５４に展開された情報に基づいて、全ての無線ネットワーク制御装置のカードの中から、障害の原因となる構造を有するカードを対象カードとして抽出する。詳細対応情報収集・展開部４３、構造的障害切り分け部４４および対象装置抽出部４５は、特定部としての処理を行う。

装置制御部４６は、装置状態５６に基づいて、対象カードの切り離しを実施した場合の影響を判断し、装置制御インタフェース６３を介して、対象カードの切り離しや、冗長構成への切り替えを制御する。装置制御部４６は、装置制御部としての処理を行う。装置状態５６には、無線通信システム内の全無線ネットワーク制御装置の状態が格納されている。

ダウンロード制御部４７は、ソフトウェア版数変更可否情報５８に基づいて、版数の異なるソフトウェアへの変更が可能であるか否かを判断する。版数の変更が可能である場合には、ダウンロード制御部４７は、ソフトウェア版数変更可否情報５８に基づいて、ダウンロードデータ５７から適当な版数のソフトウェアを選択し、ダウンロードデータ６４として無線ネットワーク制御装置へ送信する。ダウンロード制御部４７は、ダウンロード制御部としての処理を行い、この場合、ダウンロードデータ５７はサーバとなる。ダウンロードデータ５７には、種々の版数の種々のソフトウェアが格納されている。図１１にソフトウェア版数変更可否情報５８のデータ構成の一例を示す。図１１に示すように、ソフトウェア版数変更可否情報５８には、例えば、カードの名称と障害の重要度に応じて適用可能なソフトウェアの版数の範囲がカードごとに格納される。ソフトウェア版数変更可否情報５８は、任意に更新される。図１２に、障害の分類と重要度の関係の一例を示す。

保守者通知部４８は、構造的障害切り分け部４４により切り分けられた、障害発生の原因となったカードのソフトウェアの版数やハードウェアの版数や部品などの警報を保守者端末２７へ送り、それらの情報を保守者に通知する。また、保守者通知部４８は、対象装置抽出部４５により抽出された対象カードの警報を保守者端末２７へ送り、対象カードを保守者に通知する。保守者通知部４８は、通知部としての処理を行う。

（カード情報インタフェース）
図１３は、カード情報インタフェースの通知情報の一例を示す説明図である。図１３に示すように、カード情報インタフェース６１は、各無線ネットワーク制御装置から保守センタに、無線ネットワーク制御装置に搭載されている全てのカードの情報または差分のカードの情報を通知する。

（障害情報インタフェース）
図１４は、障害情報インタフェースの通知情報の一例を示す説明図である。図１４に示すように、障害情報インタフェース６２は、各無線ネットワーク制御装置から保守センタに、全ての被疑カードの情報と被疑レベルを通知する。

（無線ネットワーク制御装置の構成）
図１５は、実施の形態にかかる無線ネットワーク制御装置の構成を示す説明図である。図１５に示すように、無線ネットワーク制御装置８は、制御部（ＣＰ）カード８１、処理部（ＦＢ）カード８２および回線部（ＩＦ）カード８３を備えている。各カードは、各カードで実行されるソフトウェア８４と、カード格納情報８５を備えている。カード格納情報８５は、各カードの不揮発性メモリに予め格納されている。図１６に、カード格納情報８５のデータ構成の一例を示す。図１６に示すように、カード格納情報８５には、例えば、カードを製造したメーカの名称、そのカードの名称、そのカードで実行されるソフトウェアの版数、そのカードの版数および製造番号が格納される。また、無線ネットワーク制御装置８は、カード情報収集部８６、障害情報検出部８７、自己診断制御部８８、装置制御部８９およびダウンロード制御部９０の各処理部を備えている。これら各処理部は、制御部（ＣＰ）カード８１で、制御部（ＣＰ）カード８１に格納されているソフトウェア８４が実行されることにより実現される。

カード情報収集部８６は、各カードのカード格納情報８５からカードの情報を収集する。収集されたカードの情報は、無線ネットワーク制御装置８の起動時やカードの保守を行うタイミングで、カード情報インタフェース６１を介して、図示省略した保守センタ３へ送信される。障害情報検出部８７は、障害の発生を検出し、障害情報インタフェース６２を介して、図示省略した保守センタ３へ被疑カードの情報と被疑レベルを通知する。自己診断制御部８８は、障害情報検出部８７で障害を検出すると、自己診断を行い、カードの切り替えなどによって自律で被疑カードと被疑レベルを特定する。装置制御部８９は、装置制御インタフェース６３を介して図示省略した保守センタ３から指示された被疑カードの切り離しや、冗長構成への切り替えを制御する。ダウンロード制御部９０は、被疑カードのソフトウェア８４を、図示省略した保守センタ３から受信したダウンロードデータ６４で置き換える。

（無線ネットワーク制御装置の処理手順）
図１７は、実施の形態にかかる保守システムにおける無線ネットワーク制御装置の処理手順を示す説明図である。図１７に示すように、各無線ネットワーク制御装置においては、起動時やカードの保守を行う際に、自身が搭載する全てのカードの情報を読み出す（ステップＳ１）。そして、読み出されたカードの情報に変化があるか否かを判断する（ステップＳ２）。カードの情報に変化がある場合（ステップＳ２：Ｙｅｓ）、全てのカードの情報を保守センタへ送信する（ステップＳ３）。カードの情報に変化がない場合（ステップＳ２：Ｎｏ）、保守センタへカードの情報を送信する必要はない。次いで、障害の発生を検出したか否かを判断する（ステップＳ４）。障害の発生を検出した場合（ステップＳ４：Ｙｅｓ）、装置の切り替えなどによって自律で障害を切り分け（ステップＳ５）、被疑カードと被疑レベルを特定する（ステップＳ６）。そして、被疑カードと被疑レベルを障害情報として保守センタへ送信する（ステップＳ７）。その後、監視周期分待機して（ステップＳ８）、ステップＳ１へ戻る。障害の発生を検出しない場合（ステップＳ４：Ｎｏ）、ステップＳ５〜ステップＳ７を行わずに、監視周期分待機して（ステップＳ８）、ステップＳ１へ戻る。

（保守センタの処理手順）
図１８および図１９は、実施の形態にかかる保守システムにおける保守センタの処理手順を示す説明図である。図１８に示すように、保守センタにおいては、全ての無線ネットワーク制御装置から、各無線ネットワーク制御装置に搭載されている全てのカードの情報を受信する（ステップＳ１１）。次いで、全ての無線ネットワーク制御装置から全ての障害情報を受信し、その障害情報を障害履歴情報のデータベースに格納する（ステップＳ１２）。次いで、先に受信した全てのカード情報に変化があるか否かを判断する（ステップＳ１３）。カードの情報に変化がある場合（ステップＳ１３：Ｙｅｓ）、その新たなカードの情報をカード情報のデータベースに格納し、全てのカードの情報を更新する（ステップＳ１４）。カードの情報に変化がない場合（ステップＳ１３：Ｎｏ）、カードの情報を更新する必要はない。次いで、いずれかの無線ネットワーク制御装置から障害情報を受信したか否かを判断する（ステップＳ１５）。障害情報を受信しない場合（ステップＳ１５：Ｎｏ）、ステップＳ１１へ戻る。障害情報を受信した場合（ステップＳ１５：Ｙｅｓ）、その障害情報を障害履歴情報のデータベースに格納し、障害情報を更新する（ステップＳ１６）。次いで、被疑カードの被疑レベルの高い順に、カードごとに次のステップＳ１６〜ステップＳ３１（図１９参照）の分析処理を行う。

分析処理では、まず、障害履歴情報のデータベースから、ステップＳ１５で受信した障害情報の被疑カードと障害分類が同じカードの情報を抽出し、それを被疑カードとして障害分析領域に登録する（ステップＳ１７）。また、カード情報のデータベースから正常なカードの情報を取得し、それを正常カードとして障害分析領域に登録する（ステップＳ１８）。そして、ハードウェア版数−詳細対応情報のデータベースから、各カードのハードウェア版数に対応した詳細情報を取得し、それを障害分析領域に展開する（ステップＳ１９）。次いで、図１９に示すように、ソフトウェアの版数が原因となる障害であるか否かを判断する（ステップＳ２０）。その際、上述したように、第１に「障害検出数／運用数」の値が○％以上であるか否か、第２に「障害検出数／障害検出版数」の値が△％以上であるか否か、第３に「障害検出版数／運用数」の値が□％未満であるか否かが、判断の基準となる。この３つの条件が全て満たされるときに、障害の原因がソフトウェアの版数にあると判断される。そうでない場合には、障害の原因がソフトウェアの版数以外にあると判断される。ソフトウェアの版数が原因となる障害である場合（ステップＳ２０：Ｙｅｓ）、その原因であると疑われるソフトウェアの版数を保守者へ通知する（ステップＳ２１）。ソフトウェアの版数が原因となる障害でない場合（ステップＳ２０：Ｎｏ）、保守者への通知は行われない。

次いで、ハードウェアの版数が原因となる障害であるか否かを判断する（ステップＳ２２）。その際、部品レベルの詳細情報も解析対象とする。判断の基準は、前記ソフトウェアの場合と同様である。ハードウェアの版数が原因となる障害である場合（ステップＳ２２：Ｙｅｓ）、その原因であると疑われるハードウェアの版数と部品を保守者へ通知する（ステップＳ２３）。ハードウェアの版数が原因となる障害でない場合（ステップＳ２２：Ｎｏ）、保守者への通知は行われない。次いで、ソフトウェアの版数とハードウェアの版数の組み合わせが原因となる障害であるか否かを判断する（ステップＳ２４）。その際、部品レベルの詳細情報も解析対象とする。判断の基準は、前記ソフトウェアの場合と同様である。組み合わせが原因となる障害である場合（ステップＳ２４：Ｙｅｓ）、その原因であると疑われるソフトウェアの版数とハードウェアの版数と部品の組み合わせを保守者へ通知する（ステップＳ２５）。組み合わせが原因となる障害でない場合（ステップＳ２４：Ｎｏ）、保守者への通知は行われない。

上述した３つの原因のうちのいずれかが原因となる障害であるか否かを判断する（ステップＳ２６）。そうである場合（ステップＳ２６：Ｙｅｓ）、カード情報のデータベースから、他の無線ネットワーク制御装置を含めて、その障害の原因と同じ構造を有する全てのカードを対象カードとして抽出する（ステップＳ２７）。そして、その対象カードの警報を保守者へ通知する（ステップＳ２８）。次いで、対象カードを有する無線ネットワーク制御装置から対象カードを切り離した場合に、無線ネットワーク制御装置への影響を判断し、重大な影響がなければ、対象カードの切り離しを制御する（ステップＳ２９）。次いで、障害の原因がソフトウェアの版数にある場合には、ソフトウェア版数変更可否情報に基づいて、ソフトウェアの版数を変更できるか否かを判断する（ステップＳ３０）。変更できる場合（ステップＳ３０：Ｙｅｓ）、ソフトウェア版数変更可否情報の障害の重要度に応じて、ダウンロードデータのデータベースから適用可能なソフトウェアを選択し、無線ネットワーク制御装置へ送信する。それによって、無線ネットワーク制御装置において、ソフトウェアの版数が変更される（ステップＳ３１）。そして、次の被疑カードに対してステップＳ１７〜ステップＳ３１の分析処理を行う。ソフトウェアの版数を変更できない場合（ステップＳ３０：Ｎｏ）、ステップＳ３１を行わずに、次の被疑カードに対する分析処理へ移行する。また、ステップＳ２６において、いずれかが原因となる障害ではない場合（ステップＳ２６：Ｎｏ）、次の被疑カードに対する分析処理へ移行する。全ての被疑カードについて分析処理が終了したら、ステップＳ１１へ戻る。

以上説明したように、本実施の形態によれば、全ての無線ネットワーク制御装置から、各無線ネットワーク制御装置に搭載された全てのカードについて、ソフトウェアの版数、ハードウェアの版数および部品情報を収集するとともに、全ての障害情報を収集し、それらカードの情報と障害情報を照らし合わせることによって、障害の原因となるカードを特定し、その原因が、カードのソフトウェアの版数、ハードウェアの版数、あるいはソフトウェアの版数とハードウェアの版数の組み合わせにあるのかを特定することができる。また、その原因に特定された構成と同じ構成を有する他の無線ネットワーク制御装置に対して、同様の障害が発生する前に部品交換やソフトウェアの変更を行うことができるので、将来発生する可能性のある障害を未然に防ぐことができる。

また、無線ネットワーク制御装置と同様に、無線基地局装置や移動マルチメディア交換装置に対しても本実施の形態の保守システムを適用し、同時間帯に異なる装置で発生した障害を含めて解析することによって、それらの装置間で障害が発生した場合でも、どちらの装置のどのカードで障害が発生したのかを特定することができる。本実施の形態の保守システムを適用しない場合に装置間で障害が発生すると、どちらの装置のどのカードで障害が発生したのかを特定することができないため、両方の装置のカードを交換する必要がある。それに対して、本実施の形態では、特定したカードのみを交換すればよいので、交換に要する工数や交換部品を削減することができる。また、交換用のカードの準備枚数を減らすことができるので、交換用のカードの製造に要する費用や保守に要する費用を削減することができる。

上述した実施の形態に限らず、種々変更可能である。例えば、ハードウェア版数−詳細対応情報、ソフトウェア版数変更可否情報および障害判定パラメータのうちの一つ以上を開発元サーバに格納しておき、保守センタの起動時または障害解析時に保守センタが開発元サーバからダウンロードするようにしてもよい。また、無線ネットワーク制御装置の各カードにおいて、不揮発性メモリに版数の異なる複数のファームウェアを格納しておき、障害発生時に保守センタからダウンロードするのではなく、自身の不揮発性メモリから適当なファームウェアを選択して版数を変更するようにしてもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）複数の処理ブロックを備えた複数の被監視装置を監視装置が監視して保守する保守システムにおいて、複数の前記被監視装置の複数の前記処理ブロックの構成情報を収集する構成情報収集部と、複数の前記被監視装置の障害情報を収集する障害情報収集部と、前記構成情報収集部により収集された前記構成情報および前記障害情報収集部により収集された前記障害情報に基づいて、障害の原因となる前記処理ブロックの構成を特定する特定部と、を備えることを特徴とする保守システム。

（付記２）前記監視装置は、前記被監視装置に使用されている部品に関する部品情報を保持し、前記特定部は、前記部品情報に基づいて障害の原因となる前記部品を特定することを特徴とする付記１に記載の保守システム。

（付記３）前記監視装置は、前記被監視装置の製造元のサーバから、前記被監視装置に使用されている部品に関する部品情報を取得し、前記特定部は、前記部品情報に基づいて障害の原因となる前記部品を特定することを特徴とする付記１に記載の保守システム。

（付記４）前記特定部により障害の原因に特定された構成を有する前記被監視装置を保守者に通知する通知部、をさらに備えることを特徴とする付記１〜３のいずれか一つに記載の保守システム。

（付記５）前記特定部により障害の原因に特定された構成を有する前記被監視装置に対して、障害の原因に特定された前記構成の切り離しを制御する装置制御部、をさらに備えることを特徴とする付記１〜４のいずれか一つに記載の保守システム。

（付記６）前記特定部により障害の原因に特定されたソフトウェアを、ダウンロードによって別の版数のソフトウェアに変更するダウンロード制御部を、さらに備えることを特徴とする付記１〜５のいずれか一つに記載の保守システム。

（付記７）前記ダウンロード制御部は、異なる版数のソフトウェアを格納するサーバからソフトウェアをダウンロードすることを特徴とする付記６に記載の保守システム。

（付記８）前記被監視装置は、異なる版数のソフトウェアを格納し、前記特定部により障害の原因に特定されたソフトウェアを別の版数のソフトウェアに変更することを特徴とする付記１〜５のいずれか一つに記載の保守システム。

（付記９）前記特定部は、障害の原因となる前記処理ブロックの構成として、ハードウェアの版数とソフトウェアの版数の組み合わせを特定することを特徴とする付記１〜８のいずれか一つに記載の保守システム。

無線通信システムの構成の一例を示す概略図である。 実施の形態にかかる保守システムの概略を示す説明図である。 実施の形態にかかる保守システムの概略を示す説明図である。 実施の形態にかかる保守システムにおける保守センタのハードウェア構成を示す説明図である。 実施の形態にかかる保守システムにおける保守センタの構成を示す説明図である。 カード情報のデータ構成の一例を示す説明図である。 障害履歴情報のデータ構成の一例を示す説明図である。 ハードウェア版数−詳細対応情報のデータ構成の一例を示す説明図である。 障害分析領域のデータ構成の一例を示す説明図である。 障害判定パラメータのデータ構成の一例を示す説明図である。 ソフトウェア版数変更可否情報のデータ構成の一例を示す説明図である。 障害の分類と重要度の関係の一例を示す説明図である。 カード情報インタフェースの通知情報の一例を示す説明図である。 障害情報インタフェースの通知情報の一例を示す説明図である。 実施の形態にかかる保守システムにおける無線ネットワーク制御装置の構成を示す説明図である。 カード格納情報のデータ構成の一例を示す説明図である。 実施の形態にかかる保守システムにおける無線ネットワーク制御装置の処理手順を示す説明図である。 実施の形態にかかる保守システムにおける保守センタの処理手順を示す説明図である。 実施の形態にかかる保守システムにおける保守センタの処理手順を示す説明図である。

符号の説明

３ 監視装置
４ サーバ
６，８，９ 被監視装置
４１ 構成情報収集部
４２ 障害情報収集部
４３，４４，４５ 特定部
４６ 装置制御部
４７ ダウンロード制御部
４８ 通知部
５７ サーバ
８１，８２，８３ 処理ブロック

Claims (5)

1. 複数の処理ブロックを備えた複数の被監視装置を監視装置が監視して保守する保守システムにおいて、
   複数の前記被監視装置の複数の前記処理ブロックの構成情報を収集する構成情報収集部と、
   複数の前記被監視装置の障害情報を収集する障害情報収集部と、
   前記構成情報収集部により収集された前記構成情報および前記障害情報収集部により収集された前記障害情報に基づいて、障害の原因となる前記処理ブロックの構成を特定する特定部と、
   を備えることを特徴とする保守システム。
2. 前記監視装置は、前記被監視装置に使用されている部品に関する部品情報を保持し、
   前記特定部は、前記部品情報に基づいて障害の原因となる前記部品を特定することを特徴とする請求項１に記載の保守システム。
3. 前記特定部により障害の原因に特定された構成を有する前記被監視装置を保守者に通知する通知部、をさらに備えることを特徴とする請求項１または２に記載の保守システム。
4. 前記特定部により障害の原因に特定された構成を有する前記被監視装置に対して、障害の原因に特定された前記構成の切り離しを制御する装置制御部、をさらに備えることを特徴とする請求項１〜３のいずれか一つに記載の保守システム。
5. 前記特定部により障害の原因に特定されたソフトウェアを、ダウンロードによって別の版数のソフトウェアに変更するダウンロード制御部を、さらに備えることを特徴とする請求項１〜４のいずれか一つに記載の保守システム。

Images