JP7212245B2

JP7212245B2 - 診断装置

Info

Publication number: JP7212245B2
Application number: JP2018168985A
Authority: JP
Inventors: 拓哉小田; 正啓小林; 章平野
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2018-09-10
Filing date: 2018-09-10
Publication date: 2023-01-25
Anticipated expiration: 2038-09-10
Also published as: JP2020042507A; WO2020054379A1; US20210328861A1; US11876670B2

Description

本発明は、診断装置に関する。

通信用ネットワークにおいて、様々なサービスを提供するため仮想化などが進むにつれネットワークはより複雑化する傾向にあり、保守運用もまた高度なものが求められている。特に故障診断の分野では、ネットワークのモニタリング情報や故障事例から確率モデルを作成し、故障診断を行う検討が進められている。

図７は、従来の故障診断システムを示す図である。運用管理者は、通信用ネットワークにおける様々な情報（アラート情報、カウンタ情報、伝送品質情報など）を、管理用ネットワークを介して収集し、監視するＮＷモニタリングを行う。故障診断システムは、それらの収集情報を入力として故障診断プロセスを実行し、運用する通信用ネットワークにおける故障の発生有無（故障有りの場合には、その原因）を診断する。なお、故障診断が実行される契機としては、監視情報の変化時や周期的な実施、運用管理者による任意のタイミングなどがある。

故障診断プロセスでは様々な推論アルゴリズムが用いられるが、ここでは推論アルゴリズムとしてベイジアンネットワークを用いた確率モデルを用いたものを従来例として示す。ベイジアンネットワークとは、因果関係を確率として表現するモデルの一つであり、複雑な因果関係の推論を有向非巡回グラフ構造で表すとともに、個々の「原因」と「結果」の関係を条件付き確率で表す確率推論のモデルである。

図８は、ベイジアンネットワークの簡単な例を示す図である。ベイジアンネットワークは、ノードと矢印によって構成される。各ノードは、ある事象における確率変数Ｐを持つ。また、ノード間の矢印は、事象間の因果関係を示す。矢印の元のノードを親、矢印の先のノードを子と呼び、ノード間で親子の関係性を持つ。同図では、ノードＡ、Ｂに親が存在しないことから、その単体の事象による確率変数Ｐ（Ａ）、Ｐ（Ｂ）を確率変数として持つ。また、それ以外のノードＪ、Ｌ、Ｍでは親子関係が存在することから、親ノードに依存した条件付確率Ｐ（Ｊ｜Ａ，Ｂ）、Ｐ（Ｌ｜Ｊ）、Ｐ（Ｍ｜Ｊ）をそれぞれ確率変数として持つ。これらの関係性・確率変数は、対象とする故障事例・監視データや保守担当者によるパラメータ調整などにより、故障診断プロセス前に事前に設定される。

例えば、故障Ｆ１が発生する事象をノードＡに、故障Ｆ２が発生する事象をノードＢに、故障Ｆ１または故障Ｆ２が発生する際に装置アラートＭ１が報告される事象をノードＪに、装置アラートＭ１が報告される際に装置内デバイスＤ１のアラートが異常を示す事象をノードＬに、装置アラートＭ１が報告される際に装置内デバイスＤ２のアラートが異常を示す事象をノードＭに対応付け、事前の故障事例並びに監視情報に基づいて各ノードの確率変数を与える。また、装置内デバイスＤ１、Ｄ２のアラートをモニタリング情報として収集しており、それらの情報に基づき故障Ｆ１、故障Ｆ２が発生する確率を、与えられた関係性・確率変数を元に判定・評価する。このようにして確率モデルを用いて故障診断を行うことで、人手で判別が難しいような複雑な故障などもその故障原因を推定することができる。ベイジアンネットワークを用いて故障診断を行う例として、非特許文献１がある。

このような確率モデルを用いた故障診断システムは、与えられた監視情報に基づき最も確率が高い故障原因を導き出す。ここで故障原因とは、監視情報で観測された事象（上記の例ではノードＪ、Ｌ、Ｍに対応付けられた事象である装置アラートＭ１、装置内デバイスＤ１のアラート、装置内デバイスＤ２のアラート）の原因となる故障（上記の例では、ノードＡ、Ｂに対応付けられた事象である故障Ｆ１、Ｆ２）である。しかし、その故障原因として推定された故障が実際に発生しているかどうかは把握しておらず、実際の故障対応を行う場合には別途確認作業が必要となる。

S. Gosselin，J. Courant，S. R. Tembo，S. Vaton，"Application of Probabilistic Modeling and Machine Learning to the Diagnosis of FTTH GPON Networks"，2017 International Conference on Optical Network Design and Modeling (ONDM) Conference Proceedings，2017年

上述したように、従来技術である確率モデルを用いた故障診断システムでは最も可能性が高い故障原因や故障箇所を導き出すことは可能だが、その故障原因や故障個所の故障が実際に発生しているかどうかは故障診断のみでは確認することが出来ない。そのため、故障の対応を実際に行う前に診断結果を確認する必要があり、確認作業における人手の必要性や、診断結果が誤っていた場合のリスク（誤った故障対応による別故障の誘発など）の問題がある。

上記事情に鑑み、本発明は、確率モデルを用いた診断により得られた事象が実際に診断対象において発生しているかの確からしさを確認することができる診断装置を提供することを目的としている。

本発明の一態様は、１以上の確率的推論ステップを有する確率推論アルゴリズムにより診断対象の状態を推定する状態推定部と、推定された前記状態を検証するため検証試験を行う試験実施部と、前記検証試験の試験結果に基づいて、推定された前記状態の確からしさを判定する判定部と、を備える診断装置である。

本発明の一態様は、上述の診断装置であって、前記判定部は、前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記状態推定部により推定された前記状態とに差分があると判定した場合、前記差分を生じた前記確率的推論ステップに遷移し、前記診断対象の状態を推定するよう前記状態推定部に指示する。

本発明の一態様は、上述の診断装置であって、前記判定部が前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記状態推定部により推定された前記状態とに差分があると判定した場合、前記差分を生じた前記確率的推論ステップから、推定された前記状態に至る確率を前記試験結果に整合するように修正する推論過程変更部をさらに備える。

本発明の一態様は、上述の診断装置であって、前記確率推論アルゴリズムは、ベイジアンネットワークを用いた状態推定アルゴリズムである。

本発明の一態様は、上述の診断装置であって、１以上の前記状態推定部と、１以上の前記試験実施部と、１以上の前記判定部との組み合わせを複数備え、前記組み合わせのそれぞれにおいて前記状態推定部により推定された状態と前記判定部が前記状態について判定を行った結果とを用いて前記診断対象の前記状態を判定する総合判定部をさらに備える。

本発明の一態様は、上述の診断装置であって、前記診断対象は、通信用ネットワークであり、前記状態推定部は、前記通信用ネットワークにおいて故障が発生している状態を推定する。

本発明により、確率モデルを用いた診断により得られた事象が実際に診断対象において発生しているかの確からしさを確認することが可能となる。

本発明の第１の実施形態による故障診断システムの構成図である。同実施形態による故障診断システムの動作例を表すフローチャートである。第２の実施形態による故障診断システムの構成図である。同実施形態による故障診断システムの動作例を表すフローチャートである。同実施形態による推論過程の更新例を示す図である。同３の実施形態による故障診断システムの構成例を示す図である。従来の故障診断システムを示す図である。ベイジアンネットワークの簡単な例を示す図である。

以下、図面を参照しながら本発明の実施形態を詳細に説明する。本実施形態の診断装置は、確率推論アルゴリズムを用いて診断対象の状態を推定し、その推定された状態が診断対象に生じているかを検証する試験機能を有し、推定された状態の確からしさを向上させる。以下では、診断対象が通信用ネットワークであり、診断装置が通信用ネットワークの故障診断を行う故障診断システムである場合を例に説明する。

（第１の実施形態）
本発明の第１の実施形態を、図１及び図２を用いて説明する。
図１は、本実施形態による故障診断システム１の構成を示す図である。故障診断システム１は、通信用ネットワーク２と、管理用ネットワーク３と、故障診断装置４とを有する。同図に示す故障診断システム１は、図７に示す従来技術の故障診断システムに、本実施形態の代表的な機能構成を適応した一例である。故障診断システム１は、従来技術の故障診断システムと同様に通信用ネットワーク２に対する故障診断を行った結果に応じて、通信用ネットワーク２における実際の状態を確認する試験機能を具備している。

通信用ネットワーク２は、例えば、複数の通信装置により構成されるネットワークである。管理用ネットワーク３は、通信用ネットワーク２と故障診断装置４との間で送受信されるデータを中継するネットワークである。

故障診断装置４は、ＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３、試験実施部４４、試験項目ＤＢ５１及び試験結果ＤＢ５２を備える。ＮＷモニタリング部４１は、管理用ネットワーク３を介して、通信用ネットワーク２における様々な情報（アラート情報、カウンタ情報、伝送品質情報など）を収集し、記憶する。ＮＷモニタリング部４１は、例えば、図７に示す従来の故障診断システムと同様のＮＷモニタリング機能を有する。故障診断部４２は、図７に示す従来の故障診断システムが備える故障診断プロセスを実行する。つまり、故障診断部４２は、ＮＷモニタリング部４１が収集した情報に基づいて、例えばベイジアンネットワーク等により通信用ネットワーク２における故障を診断する。故障診断部４２は、故障の発生有無と、故障発生有りの場合にはその原因や発生個所などとを診断結果（以下、故障診断結果とも記載する。）として得る。

診断結果判定部４３は、故障診断部４２による故障診断の結果を元に、通信用ネットワーク２の状態を確認及び判定する。診断結果判定部４３は、通信用ネットワーク２の状態を確認及び判定するための試験項目を決定し、試験実施部４４に通知する。試験実施部４４は、診断結果判定部４３が決定した試験項目の確認試験を実施し、診断結果判定部４３に試験結果を通知する。試験項目ＤＢ５１は故障診断結果に応じた試験項目のデータを記憶する。試験結果ＤＢ５２は、試験実施部４４が実行した確認試験の結果のデータを記憶する。

なお、故障診断装置４は、１台又は複数台のコンピュータ装置により実現される。故障診断装置４が複数台のコンピュータ装置により実現される場合、いずれのコンピュータ装置がいずれの機能部を有するかは任意とすることができる。また、複数台のコンピュータ装置で一つの機能部を実現してもよい。ここでは、診断結果判定部４３及び試験実施部４４は、管理用ネットワーク３と直接的又は間接的に接続されるサーバ群・クラウド等の計算リソースである。

図２は、故障診断部４２より故障診断結果が報告された後の故障診断装置４の動作例をフローチャートの形式で表した図である。同図を用いて、通信用ネットワーク２内で装置Ａの装置故障が発生し、そのアラート情報をＮＷモニタリング部４１により収集し、故障診断部４２で判定を実施した場合における具体例を述べる。

ＮＷモニタリング部４１は、通信用ネットワーク２から監視対象の情報（リンク状態、装置死活監視情報など）を収集する。監視対象の情報は、装置故障のアラート情報を含む。故障診断部４２は、ＮＷモニタリング部４１が収集した情報を用いて、故障の診断を実施する。この診断には、例えば、確率モデルで表現されるベイジアンネットワークを用いたアルゴリズムを利用する。なお、判定の際には、予め故障や監視の情報などからアルゴリズムが確定しており、その確定したアルゴリズムを用いて現在の事象を判定する。

故障診断の結果、装置Ａが故障していると判定されたとする。診断結果判定部４３は、故障診断部４２から故障原因「装置Ａが故障している」という故障診断結果の情報を受け取る（ステップＳ１０）。ここでは、故障診断結果に故障原因の情報が設定されている場合、故障発生の有無「故障有」の情報が含まれているものとする。その後、診断結果判定部４３は、試験項目ＤＢ５１を参照し、装置Ａが本当に故障しているのかを確認するための試験項目を作成する（ステップＳ２０）。ここでは、「項目（１）：管理用ネットワーク３からの装置Ａの状態確認」、「項目（２）：装置Ａとネットワーク的に隣接する装置Ｂから装置Ａへ疎通が取れるかの状態確認」、「項目（３）：装置Ａの装置故障のアラート情報確認」、の３項目が含まれる確認試験を行うとする。診断結果判定部４３は、決定したこれら３項目を示す確認試験の内容を試験実施部４４へと通知する。

試験実施部４４は、通知された確認試験の項目を実施する（ステップＳ３０）。通知された確認試験には、３項目の試験内容が含まれていることから、試験実施部４４は、以下の３つの試験を実施し、その結果を得る。

項目（１）：試験実施部４４は、管理用ネットワーク３を介して、通信用ネットワーク２内の装置Ａの状態を確認する。今回の事例では装置Ａの故障のため、アクセスができずという結果となる。

項目（２）：試験実施部４４は、管理用ネットワーク３を介して装置Ｂへと指示を出し、装置Ｂから装置Ａへの疎通確認（例：Ping）を実行させる。今回の事例では装置Ａの故障のため、装置Ｂからのアクセスも出来ず、疎通が取れないという結果となる。

項目（３）：試験実施部４４は、ＮＷモニタリング部４１から装置Ａのアラート情報を取得する。今回の事例では、ＮＷモニタリング部４１において装置Ａのアラート情報を収集・格納していることから、装置Ａのアラート情報が検知されていることを確認できる。

試験実施部４４は、確認試験の３項目を実施すると、その試験実施結果（項目（１）：アクセスできず、項目（２）：疎通なし、項目（３）：アラート情報あり）を診断結果判定部４３に通知する（ステップＳ４０）。

診断結果判定部４３は、試験実施部４４から通知された試験実施結果を受け取ると、故障診断部４２が行った故障診断によって診断された装置Ａの故障という結果と、試験実施結果とを比較する（ステップＳ５０）。装置Ａが故障しているという故障診断結果に基づき３項目の確認試験が行われ、それら全ての項目で装置Ａが故障しているという事象が満たされていることから、診断結果判定部４３は、装置Ａの故障が発生しているという故障診断結果の確認が取れたと判断する。最終的に、診断結果判定部４３は、故障診断結果「装置Ａの故障である」と、確認結果「装置Ａが故障していることを確認」を合わせた結果を出力する（ステップＳ６０）。結果の出力は、オペレータへの通知としてもよく、また別システムへのトリガーとしてもよい。あるいは単純にデータとして、故障診断装置４の内部又は外部に備える記憶装置に格納してもよい。

診断結果判定部４３及び試験実施部４４は、故障診断部４２からの故障診断結果の入力を契機として、上述した故障診断結果の確認プロセスを実行してもよい。確認プロセスが開始されると、診断結果判定部４３は、故障診断結果を、故障診断部４２から、または、故障診断部４２による故障診断結果が格納されているデータ領域から取得する。診断結果判定部４３は、取得した故障診断結果の内容に応じて、確認試験の試験内容（試験項目、試験対象箇所など）を決定する。例えば、故障原因、故障個所、又は、それらの組み合わせと試験項目とを対応付けたデータセットを事前に用意し、試験項目ＤＢ５１に登録しておいてもよい。試験項目の決定過程において、診断結果判定部４３は、試験項目ＤＢ５１に登録しておいたデータセット内の対応関係から、診断結果で示される故障原因や故障個所に応じた試験項目や試験対象箇所などの試験内容を決定する。なお、試験項目としては、通信経路の疎通確認（例：Internet Control Message Protocolを用いた確認)、装置・デバイス・通信経路におけるパラメータの確認、装置内ログ・システムログ・アプリケーションログの確認、運用管理・メンテナンスの情報（例：Ethernet Operations, Administration and Maintenance）確認などが含まれる。

診断結果判定部４３による試験内容の決定後、試験実施部４４は、対象となる装置や通信経路に対して確認試験を行う。なお、確認試験に含まれる対象データが既にＮＷモニタリング部４１に収集されている場合には、ＮＷモニタリング部４１から試験結果としてその情報を得てもよい。試験実施部４４が確認試験を行った後に、診断結果判定部４３は、その試験結果を収集する。試験結果は、試験実施時のログなどを直接用いてもよい。また、一旦別の保存領域（例えば、試験結果ＤＢ５２）に格納した後に、その保存領域から該当の試験結果を取得する形式でもよい。診断結果判定部４３は、故障診断結果の確認に必要な試験結果が収集できた後に、故障診断結果と試験結果が意味するネットワークの状態の比較を行う。診断結果判定部４３は、比較結果を故障診断結果と合わせて出力する。

なお、故障診断結果に最も有力な故障原因候補の他の故障原因（２番目に確率の高い故障原因など）が含まれている場合、故障診断装置４は、それらの別の故障原因に対しても同様に確認試験を実施してもよい。また、故障診断装置４は、一つの故障原因について確認試験後の状態比較結果に差分が生じた場合のみ、状態比較を行ったその故障原因とは異なる故障原因に対して確認試験を実施してもよい。

本実施形態により、故障診断結果の確からしさを確認することができる。

（第２の実施形態）
第１の実施形態では、故障診断の診断結果と確認試験の結果を比較し、その比較結果と診断結果を報告している。第２の実施形態では、診断結果と確認試験の結果に差分が生じた場合に、更なる故障診断及び確認試験を行うことで、故障原因の特定精度を向上させる。第２の実施形態を、図３及び図４を用いて説明する。

図３は、本実施形態による故障診断システム１ａの構成を示す図である。同図に示す故障診断システム１ａは、図７に示す従来技術の故障診断システムに、確認試験実施後の状態推定で差分が生じた場合の故障診断再実行と、故障診断機能で用いられる推論過程の変更とを可能とする機能構成を適応した一例である。同図において、図１に示す第１の実施形態による故障診断システム１と同一の部分には同一の符号を付し、その説明を省略する。同図に示す故障診断システム１ａが、図１に示す故障診断システム１と異なる点は、故障診断装置４に代えて故障診断装置４ａを備える点である。

故障診断装置４ａは、ＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３ａ、試験実施部４４、推論過程変更部４５、試験項目ＤＢ５１及び試験結果ＤＢ５２を備える。診断結果判定部４３ａは、故障診断部４２による故障診断の結果を元に確認試験の試験内容を決定し、故障診断の結果と確認試験の結果との状態比較により、通信用ネットワーク２の状態を確認及び判定する。さらに、診断結果判定部４３ａは、状態比較に差分が生じたと判断した場合に、故障診断部４２へ診断再実行を指示する。試験実施部４４は、診断結果判定部４３ａが決定した試験内容の確認試験を実施する。推論過程変更部４５は、診断結果判定部４３ａからの指示に基づき故障診断部４２における推論過程の変更を行う。

なお、故障診断装置４ａは、１台又は複数台のコンピュータ装置により実現される。故障診断装置４ａが複数台のコンピュータ装置により実現される場合、いずれのコンピュータ装置がいずれの機能部を有するかは任意とすることができる。また、複数台のコンピュータ装置で一つの機能部を実現してもよい。ここでは、推論過程変更部４５は、診断結果判定部４３ａと接続されるサーバ群・クラウド等の計算リソースである。

図４は、故障診断部４２ａより故障診断結果が報告された後の故障診断装置４ａの動作例をフローチャートの形式で表した図である。同図において、図２に示す第１の実施形態の動作と同一の動作には同一の符号を付し、その説明を省略する。

ステップＳ１０の「故障診断結果の取得」からステップＳ４０の「試験結果の取得」までの動作は図２に示す第１の実施形態と同一である。確認試験の結果取得後、診断結果判定部４３ａは、故障診断結果と確認試験の試験結果のそれぞれが意味するネットワークの状態の比較を行う（ステップＳ１５０）。診断結果判定部４３ａは、両者に差分がないと判定した場合には、第１の実施形態と同じく比較結果と故障診断の結果を出力として報告を行う（ステップＳ１６０）。一方、診断結果判定部４３ａは、状態比較により差分ありと判定した場合、故障診断の再実行を行うと決定する。その際に、診断結果判定部４３ａは、推論過程の更新の要否を判定する（ステップＳ１７０）。更新の要否は、例えば、予め故障診断装置４ａに登録された設定に基づいて判断される。

ここからは、まず推論過程の更新が不要な場合における動作例を述べる。ステップＳ１７０において、診断結果判定部４３ａは、推論過程の更新が不要と判定した場合、故障診断部４２に対して再度故障診断を実行するよう指示を出す（ステップＳ１８０）。

故障診断の再実行は、診断プロセスを最初から実施してもよく、あるいは診断プロセスが複数のステップを持つ場合には状態比較において差分が生じたステップから実施してもよい。前者の故障診断の再実行では、時間経過により通信用ネットワーク２の状態が変化し再度同じ故障診断を実行することで正しい診断が出来る可能性がある。また、後者の故障診断の再実行では、同一の結果を導く計算過程を省略できることから計算資源の効率化が図ることが可能である。故障診断部４２は、これらの故障診断の再実行を行って、再度故障診断結果を出力する。これにより、故障診断装置４ａは、図４に示すフローのステップＳ１０からの動作を行い、確認試験の実行、及び、故障診断結果と確認試験の試験結果のそれぞれが意味するネットワークの状態の比較を行う。

なお、故障診断結果及び試験結果の状態比較で引き続き差分ありの場合には、故障診断装置４ａは、故障診断再実行の動作を繰り返し行ってよい。また、故障診断装置４ａは、故障診断再実行を事前に設定した任意の回数だけ繰り返してもよく、状態比較の結果で差分ありの場合には、図２に示す第１の実施形態の報告動作と同様に、比較結果が一致しないという内容と故障診断結果と合わせて出力し、図４のフローを終えてもよい。また、故障診断装置４ａは、故障診断を再実行する際には、入力情報としてＮＷモニタリングの情報だけでなく、確認試験において得られた情報も利用してもよい。

単純な故障診断の再実行は、元の確率モデルに基づき診断ステップの初めから再度故障診断を実行することである。診断プロセスの途中のステップから診断を開始する場合について故障診断部４２における確率推論アルゴリズムにベイジアンネットワークを用いた場合の動作例を述べる。

故障診断部４２の確率推論アルゴリズムにベイジアンネットワークを用いた場合について図８を用いて説明する。初回の故障診断部４２における推論計算では、入力として事象Ｌと事象Ｍにその事象の状態値が与えられ、この状態値を用いて事象Ａと事象Ｂの発生確率Ｐ（Ａ｜Ｌ，Ｍ）、Ｐ（Ｂ｜Ｌ，Ｍ）を求め、事象Ａと事象Ｂのうち、確率の高い方を故障診断結果として報告するとする。状態値は、例えば、事象の発生の有無を表す値や、事象としてとり得る複数の状態のうちいずれであるかを表す値である。図３に示す故障診断装置４ａの診断結果判定部４３ａにより、その故障診断結果と確認試験の結果による状態評価が行われ、差分が生じたと判定されたとする。その結果、故障診断装置４ａは、再度故障診断を実行するが、確認試験の結果から既に事象Ｊの状態が明らかであるとする。その場合には、故障診断を行う際に事象Ｌ、Ｍの状態値を入力値として事象Ａ、Ｂの確率を求めるのではなく、事象Ｊの状態値を入力値として事象Ａ、Ｂの発生確率Ｐ（Ａ｜Ｊ）、Ｐ（Ｂ｜Ｊ）を計算することで、診断にかかる計算リソースの削減や計算時間の短縮が可能となる。

次に、推論過程の更新が必要な場合における動作例を述べる。ステップＳ１７０において、診断結果判定部４３ａは、推論過程の更新が必要と判定した場合、故障診断部４２が用いる推論過程の内容を変更するよう推論過程変更部４５に指示する。推論過程変更部４５は、推論過程において、故障診断部４２による故障診断結果と、確認試験の試験結果が意味するネットワーク状態との差分が生じた過程から、故障診断結果に至る確率を試験結果に整合するように修正する（ステップＳ１９０）。故障診断部４２は、推論過程が更新された後に、故障診断を再度実行する（ステップＳ１８０）。故障診断部４２は、故障診断を再実行して再度故障診断結果を出力する。これにより、故障診断装置４ａは、図４に示すステップＳ１０からの動作を行い、確認試験の実行、及び、故障診断結果と確認試験の試験結果のそれぞれが意味するネットワークの状態の比較を行う。

なお、故障診断結果及び試験結果の状態比較で引き続き差分ありの場合には、故障診断装置４ａは、再度推論過程の変更を行い、故障診断を再実行する動作を繰り返し行ってよい。また、故障診断装置４ａは、故障診断再実行を事前に設定した任意の回数だけ繰り返してもよく、状態比較の結果で差分ありの場合には、図２に示す第１の実施形態の報告動作と同様に、比較結果が一致しないという内容と故障診断結果と合わせて出力し、図４のフローを終えてもよい。また、故障診断装置４ａは、故障診断を再実行する際には、入力情報として、ＮＷモニタリングの情報だけでなく、確認試験において得られた情報も利用してもよい。

図５は、推論過程の更新例を示す図である。同図を用いて、故障診断部４２の確率推論アルゴリズムにベイジアンネットワークを用いた場合の例を説明する。図５（ａ）は、更新前の推論過程を示す図である。初回の故障診断部４２における推論計算では、入力として事象Ｌと事象Ｍにその事象の状態値が与えられ、この状態値を用いて事象Ａと事象Ｂの発生確率Ｐ（Ａ｜Ｌ，Ｍ）、Ｐ（Ｂ｜Ｌ，Ｍ）を求め、確率の高い方（事象Ｂ）を出力結果として報告する。図３に示す故障診断装置４ａの診断結果判定部４３ａにより故障診断結果と確認試験の結果による状態評価が行われ、差分が生じたとする。その結果、診断結果判定部４３ａは、再度故障診断を実行するにあたり、故障診断部４２における推論過程の更新を決定する。

図５（ｂ）は、推論過程変更部４５が推論過程の更新を行った例を示す図である。この例では、推論過程変更部４５は、事象Ｊの条件付き確率Ｐ（Ｊ｜Ａ，Ｂ）を更新し、Ｐ’（Ｊ｜Ａ，Ｂ）に変更している。故障診断部４２は、更新された推論過程（ベイジアンネットワーク）を用いて、事象Ｌ，Ｍに基づいて再度事象Ａ，Ｂの発生確率を求める。更新後は、図５（ｂ）に示すように、事象Ａの発生確率が高い確率を示していることから、故障診断部４２は、事象Ａを新たな故障原因として報告する。この推論過程の更新機能より、誤った故障診断を行ったとしてもネットワークの状態確認と合わせて再度故障診断を行い、真の故障原因の特定につなげることが可能である。

なお、推論過程の更新例では１つの条件付き確率のみ変更を行ったが、ベイジアンネットワークにおけるノード、ノードに与えられる確率変数、ノード間の関係性のいずれも任意数の変更を行ってよい。また、変更後の推論過程による診断ステップにおいて、診断プロセスの途中のステップから診断を開始してもよい。

上記の動作例は推論過程の更新の要否が再実行時にどちらかに固定されている動作例をそれぞれ述べたが、診断結果判定部４３ａは、更新要否の判定時に毎回判定を行い、個別に更新の実施判断を行ってもよい。また、診断結果判定部４３ａは、更新要否の判定に、診断結果と試験結果の状態比較の乖離程度を判断基準として用いてもよい。

（第３の実施形態）
図１で示した第１の実施形態の故障診断システム１及び図３で示した第２の実施形態の故障診断システム１ａでは、ＮＷモニタリング部４１及び故障診断部４２をそれぞれ１つのみ備える構成である。しかし、実際のネットワーク運用では、膨大なモニタリング情報から故障診断を行う必要があり、扱う情報量の増加に伴い計算リソースや計算時間の増加などの問題が生じる。本実施形態では、そのようなスケーラビリティの問題を解決する。

図６は、本実施形態による故障診断システム１００の構成例を示す図である。同図において、図１に示す第１の実施形態の故障診断システム１と同一の部分には同一の符号を付し、その説明を省略する。同図に示す故障診断システム１００は、図１に示す故障診断装置４に代えて、故障診断装置４００を備える。故障診断装置４００は、複数のＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３及び試験実施部４４と、総合判定部４０１とを有する。複数のＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３及び試験実施部４４はそれぞれ、第１の実施形態の故障診断装置４が備えるＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３及び試験実施部４４と同様の機能を有する。同図では、複数のＮＷモニタリング部４１、故障診断部４２、診断結果判定部４３、及び、試験実施部４４をそれぞれ、ＮＷモニタリング部４１－１、４１－２、…、故障診断部４２－１、４２－２、…、診断結果判定部４３－１、４３－２、…、及び、試験実施部４４－１、４４－２、…と記載している。また、図示を省略しているが、故障診断装置４００は、１以上の試験項目ＤＢ５１及び１以上の試験結果ＤＢ５２を備え得る。また、通信用ネットワーク２は、ＩＰレイヤと光レイヤとを有する。

故障診断装置４００は、例えば、複数台のコンピュータ装置により実現される。いずれのコンピュータ装置がいずれの機能部を有するかは任意とすることができる。また、複数台のコンピュータ装置で一つの機能部を実現してもよい。例えば、故障診断装置４００の各部は、サーバ群・クラウド等の計算リソースである。

総合判定部４０１は、複数の診断結果判定部４３における判定情報や、ＮＷモニタリング部４１、故障診断部４２、試験実施部４４により得られた情報を総合して故障診断結果の判定を行う。ＮＷモニタリング部４１－１により通信用ネットワーク２の光レイヤのモニタリングが、ＮＷモニタリング部４１－２により通信用ネットワーク２のＩＰレイヤのモニタリングが行われている。故障診断部４２－１、４２－２は光レイヤに対応づいており、ＮＷモニタリング部４１－１が収集した情報に基づき故障診断を行う。また、故障診断部４２－３はＩＰレイヤに対応づいており、ＮＷモニタリング部４１－２が収集した情報に基づき故障診断を行う。診断結果判定部４３－ｉ及び試験実施部４４－ｉ（ｉ＝１，２，３）が、故障診断部４２－ｉによる故障診断結果の判定、確認試験の実施、故障診断結果と確認試験結果の状態比較の動作は第１の実施形態と同様である。

なお、通信用ネットワーク２のモニタリングを分割する対象は、レイヤ毎、設置エリア毎、サービス毎など任意の監視単位で設定してよい。また、１つのＮＷモニタリング部４１の収集情報を、複数の故障診断部４２で用いてもよく、その逆に１つの故障診断部４２が複数のＮＷモニタリング部４１によるモニタリング情報を取得して故障診断を行ってもよい。

なお、図６では試験実施部４４－１、４４－２、…がそれぞれ対応するレイヤに対してのみ確認試験を実施する形態を示しているが、一つの試験実施部４４が、複数レイヤに対して確認試験を実施してもよい。複数の故障診断結果が、それぞれの診断結果判定部４３から総合判定部４０１に報告される。総合判定部４０１は、それら報告された内容から、総合的に通信用ネットワーク２の状態、故障有無（故障有りの場合にはその原因）を判断し、出力する。このような形態を取ることで本実施形態のスケーラビリティを確保するだけでなく、監視単位（サービス単位、通信レイヤ単位、提供エリア単位など）などの保守運用者のポリシに基づく規則でネットワークの故障診断を実行しつつ、最終的にネットワーク全体の状態を把握することが出来る。なお、上記では、第１の実施形態における適応例について図６を用いて説明を行ったが、第２の実施形態にも同様に適応してもよい。

以上説明した実施形態によれば、故障診断システムは、故障診断の診断結果から実際のネットワーク上で該当事象が発生有無を確認する手段を有しているため、より正確な故障診断が可能となる。よって、診断結果の別途確認が不要になり、また診断結果の誤りを故障対応前に把握することができる。

上述した実施形態における故障診断装置４、４ａ、４００の機能をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

以上説明した実施形態によれば、診断装置は、状態推定部と、試験実施部と、判定部とを備える。例えば、診断装置は、故障診断装置４、４ａ、４００である。状態推定部は、１以上の確率的推論ステップを有する確率推論アルゴリズムにより、１以上の状態をとり得る診断対象の状態を推定する。例えば、状態推定部は、故障診断部４２であり、１以上の確率的推論ステップを有する確率推論アルゴリズムには、ノード間の条件付き確率変数を持つベイジアンネットワークを用いた状態推定アルゴリズムが用いられる。また、例えば、診断対象が通信用ネットワークである場合、状態推定部は、通信用ネットワークにおいて故障が発生している状態を推定する。試験実施部は、状態推定部により推定された状態を検証するため検証試験を行う。判定部は、試験実施部が行った検証試験の試験結果に基づいて、状態推定部により推定された状態の確からしさを判定する。例えば、判定部は、診断結果判定部４３、４３ａである。

判定部は、検証試験の試験結果に基づいて得られる診断対象の状態と、状態推定部により推定された状態とに差分があると判定した場合、その差分を生じた確率的推論ステップに遷移し、診断対象の状態を推定するよう状態推定部に指示する。また、診断装置は、その差分を生じた確率的推論ステップから、状態推定部により推定された状態に至る確率を、検証試験の試験結果に整合するように修正する推論過程変更部をさらに備えてもよい。

また、診断装置は、１以上の前記状態推定部と、１以上の前記試験実施部と、１以上の前記判定部との組み合わせを複数備えてもよい。この場合、診断装置は、これらの組み合わせそれぞれにおいて状態推定部が推定した状態と判定部がその推定された状態について判定を行った結果とを用いて、推定対象の状態を判定する総合判定部をさらに備える。

診断装置は、ネットワークを介して通信可能に接続された複数台の情報処理装置を用いて実装されてもよい。この場合、診断装置が備える各機能部は、複数の情報処理装置に分散して実装されてもよい。例えば、状態推定部と、試験実施部と、判定部とはそれぞれ異なる情報処理装置に実装されてもよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

通信用ネットワークの故障診断ならびに異常診断に利用可能である。

１、１ａ、１００…故障診断システム，２…通信用ネットワーク，３…管理用ネットワーク，４、４ａ、４００…故障診断装置，４１、４１－１、４１－２…ＮＷモニタリング部，４２、４２－１、４２－２、４２－３…故障診断部，４３、４３ａ、４３－１、４３－２、４３－３…診断結果判定部，４４、４４－１、４４－２、４４－３…試験実施部，４５…推論過程変更部，５１…試験項目ＤＢ，５２…試験結果ＤＢ，４０１…総合判定部

Claims

診断対象を監視して得られたモニタリング情報に基づいて、１以上の確率的推論ステップを有する確率推論アルゴリズムにより前記診断対象の状態を推定する状態推定部と、
推定された前記状態を検証するため検証試験を行う試験実施部と、
前記検証試験の試験結果に基づいて、推定された前記状態の確からしさを判定する判定部と、
を備え、
前記状態推定部は、前記判定部が前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記状態推定部により推定された前記状態とに差分があると判定した場合、前記状態の推定において用いられた前記モニタリング情報に加えて前記試験実施部による前記検証試験の試験結果から得られた明らかな状態の情報をさらに利用して前記確率推論アルゴリズムにより前記診断対象の状態を再度推定する、
診断装置。
前記判定部は、前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記状態推定部により推定された前記状態とに差分があると判定した場合、前記診断対象の状態を推定するよう前記状態推定部に指示する再推定指示を行い、
前記状態推定部は、前記判定部からの前記再推定指示を受けた場合、前記差分を生じた前記確率的推論ステップに遷移し、前記診断対象の状態と差分があると判定された前記状態の推定において用いられた前記モニタリング情報を用いて前記確率推論アルゴリズムにより前記診断対象の状態を推定する再推定を行い、前記判定部が前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記再推定により推定された前記状態とに差分があると判定した場合、前記再推定に用いられた前記モニタリング情報に加えて前記試験実施部による前記検証試験の試験結果から得られた明らかな状態の情報をさらに利用して前記確率推論アルゴリズムにより前記診断対象の状態を再度推定する、
請求項１に記載の診断装置。
前記判定部が前記検証試験の試験結果に基づいて得られる前記診断対象の状態と、前記状態推定部により推定された前記状態とに差分があると判定した場合、前記状態推定部が前記診断対象の状態を再度推定する前に、前記差分を生じた前記確率的推論ステップから、推定された前記状態に至る確率を前記試験結果に整合するように修正する推論過程変更部をさらに備える、
請求項１に記載の診断装置。
前記確率推論アルゴリズムは、ベイジアンネットワークを用いた状態推定アルゴリズムである、
請求項１から請求項３のいずれか一項に記載の診断装置。
１以上の前記状態推定部と、１以上の前記試験実施部と、１以上の前記判定部との組み合わせを複数備え、
前記組み合わせのそれぞれにおいて前記状態推定部により推定された状態と前記判定部が前記状態について判定を行った結果とを用いて前記診断対象の前記状態を判定する総合判定部をさらに備える、
請求項１から請求項４のいずれか一項に記載の診断装置。
前記診断対象は、通信用ネットワークであり、
前記状態推定部は、前記通信用ネットワークにおいて故障が発生している状態を推定する、
請求項１から請求項５のいずれか一項に記載の診断装置。