JP3771001B2 - 分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 - Google Patents
分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 Download PDFInfo
- Publication number
- JP3771001B2 JP3771001B2 JP14045097A JP14045097A JP3771001B2 JP 3771001 B2 JP3771001 B2 JP 3771001B2 JP 14045097 A JP14045097 A JP 14045097A JP 14045097 A JP14045097 A JP 14045097A JP 3771001 B2 JP3771001 B2 JP 3771001B2
- Authority
- JP
- Japan
- Prior art keywords
- diagnostic
- node
- sensor
- sensing information
- nodes
- 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 - Fee Related
Links
Images
Landscapes
- Test And Diagnosis Of Digital Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体に係り、特に、対象の診断モデルを有し、種々のジョブの複合体であるプラントやネットワークの複数のノードにおけるオペレーション等の分散システムにおいて各ノードで発生した異常を診断するための分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体に関する。
【０００２】
分散システムの診断対象は、プラント、分散オペレーティングシステム、通信システム、交通システム等のノード（構成要素）が分散していて、全体として一つのシステムを構成するものである。
【０００３】
【従来の技術】
図９は、従来の診断システムの構成を示す。同図に示すように、従来は、複数のノード１０1 〜１０ nとセンタ２０が回線を介して接続されており、例えばノード１０1 でオペレーションによるエラーを検出すると、アラーム信号は、回線を介してセンタ２０に集められる。これにより、センタ２０は、アラーム信号を受信すると、異常ノードを認識し、当該ノードに対する復旧処理等を指示する。また、センタ２０では、複数のノードの動作状態を監視し、複数のノードから送信されるアラーム信号をサンプリングして、異常原因となっているノードを抽出する。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記従来の診断システムは、１つセンタにおいて複数のノードから収集されたアラーム信号を処理しているため、少ないノードで構成される小規模なシステムであれば問題はないが、大規模なシステムにおける多数のノードからアラーム信号を受信すると、トラヒック量が増加し、回線が輻輳すると共に、センタの処理負荷が増大する。さらには、トラヒック量に比例して、センタ側の診断処理のためのサンプリング間隔が長くなり、早急に復旧処理等を講じなければならないノードへの対処が遅延する等の問題がある。
【０００５】
また、センサ自体が何らかの異常により停止している場合には、オブジェクトの異常を検知できないという問題がある。
さらに、診断対象（オブジェクト）に仕様や構成の変更が生じた場合には、ノードの仕様等が変更になるばかりではなく、センタにおいて、オブジェクトの変更に応じたプログラム等の変更の処理が必要となる。また、新たなノード及び新たなオブジェクトが設置された場合にも同様に、それらのノードやオブジェクトに対応した新規のシステム生成処理が必要となり、柔軟性や拡張性において問題がある。
【０００６】
本発明は、上記の点に鑑みなされたもので、ノードからセンタへのトラヒック負荷を削減することが可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することを目的とする。
また、本発明の目的は、センサが故障や保守のために休止している状態であってもノードの診断が可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することである。
【０００７】
また、更なる目的は、オブジェクトの仕様や構成の変更に柔軟に対処可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することである。
【０００８】
【課題を解決するための手段】
本発明は、ネットワーク上に分散配置される診断対象のオブジェクトと、
オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
センサからのデータによりオブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有し、
ノードは、
センサから渡されたセンシング情報を保持するセンサ入力情報保持手段と、
センシング情報を解析するための知識を格納する知識ベースと、
センシング情報に基づいて知識ベースを参照して該センシング情報を解析する解析手段と、
異常原因と該異常原因の現象及び症状を有する少なくとも１つの診断モデルと、
解析手段により解析された結果に基づいて診断モデルとの照合を行い、異常原因の仮説を生成すると共に、該仮説についての問い合わせを他のノードに対して行い、該他のノードからの通知に基づいて異常原因の推論を行う推論手段と、
推論手段による推論結果を診断対象の監視者のセンタに通知する通知手段と、
を有する。
【００１０】
本発明は、上記の通知手段において、異常原因と診断モデルの現象及び症状のうち、いくつが確認できたかを確信度としてセンタに通知する。
本発明は、上記の診断モデルにおいて、異常原因を根とし、該異常原因の現象及び症状を葉とする木構造とする。
【００１１】
本発明は、上記の推論手段において、他のノードの推論手段から渡された問い合わせに応じて、自ノードに入力されるセンシング情報を解析して、問い合わせの現象または、症状を確認する確認手段と、
確認手段において現象または症状を確認できる場合に、他のノードに問い合わせにマッチするセンシング情報の入力がないかを問い合わせ、推論を行う手段と、を有し、問い合わせ元のノードへ推論結果を返却する問い合わせ応答手段を含む。
【００１２】
本発明の診断モデルは、オブジェクトの変更・追加により随時更新される。
本発明の知識ベースは、オブジェクトの変更・追加により随時更新される。
本発明は、ネットワーク上に分散配置される診断対象のオブジェクトと、
オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
センサからのデータによりオブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有するシステムにおいて、
記憶手段に、センサから渡されたセンシング情報を保持するセンサ入力情報保持手段と、該センシング情報を解析するための知識を格納する知識ベースと、を有するノードとして利用されるコンピュータに、
請求項１乃至６記載の各手段を実行させるプログラムを格納した記憶媒体である。
【００１３】
本発明によれば、各オブジェクトに対応する個々のノードにおいて、センサでセンシングされたオブジェクトのセンシングデータに基づいて、当該オブジェクトの状態を診断すると共に、他のノードと協調することにより、自ノードの対象オブジェクトの状態を診断することが可能であるため、自ノードのみでは、確実に把握できなかったオブジェクトの異常原因等を把握することが可能となる。つまり、個々のノードにおいて、当該ノードに対応するオブジェクトの状態をセンタ管理することなく、ローカルなノードにおいて管理することが可能となり、センタへのトラヒック負荷が削減される。
【００１４】
また、本発明によれば、各ノードにおいて、センシング情報を知識ベースに基づいて解析し、その解析結果（現象・症状）に基づいて診断モデル（異常原因、現象・症状）との照合を行い、原因の仮説を生成すると共に、該仮説についての問い合わせを他のノードに対して行い、該他のノードからの通知に基づいて異常原因の推論を行うことにより、センタに依存しなくとも当該ノードに対応するオブジェクトの状態を把握することが可能であるため、当該オブジェクトに対する処理等を当該ノードの管理者により実施することも可能となる。
【００１５】
また、本発明によれば、あるノードにおいて、推論された最終的な結論をセンタに送信することにより、各ノードのセンサから取得したデータを直接センタで収集せずに、センタにおいて、ノード毎に解析された原因の確信度の情報のみを収集することが可能となる。
また、本発明によれば、異常原因を根とし、該異常原因の現象及び症状を葉とする木構造を採用することによい、原因を事象駆動型の後ろ向き推論が可能となり、葉の部分より順に根まで辿ることにより、異常原因を突き止めることが可能となる。
【００１６】
また、本発明によれば、他のノードの推論手段から渡された問い合わせに応じて、自ノードに入力されるセンシング情報を解析して、問い合わせの現象または、症状を確認する、さらに、他のノードに問い合わせにマッチするセンシング情報の入力がないかを問い合わせることにより、問い合わせノードとの状態の関連を探索して、問い合わせ元のノードに応答することが可能となる。これにより、問い合わせ元のノードでは、問い合わせ先のノードの現象や症状により他のノードとの異常原因の関連性を把握することが可能となる。
【００１７】
また、本発明によれば、オブジェクトの変更・追加があった場合でも診断モデル及び知識ベースをノード単位で更新することが可能となる。
【００１８】
【発明の実施の形態】
図１は、本発明の診断システムの構成を示す。同図に示す診断システムは、複数のノード１００（以下、単にエージェントと記す）がＬＡＮ／ＷＡＮ５００によりノード１００間及び監視者（センタ）２００と接続されている。また、各ノード１００は、センサ３００を介してオブジェクト４００を監視する。
【００１９】
各ノード１００は、エージェント固有のオブジェクト４００を監視する。また、各エージェント間では、ＬＡＮ／ＷＡＮ５００を介しての通信が可能であり、各ノード１００において診断した結果（異常症候情報）をノード１００間においてやり取りすることができる。
各ノード１００は、オブジェクト４００を監視し、センサ３００からオブジェクト４００の数値データを取得して当該数値データを保持するセンサ保持部１１０、センサ入力保持部１１０から取得した数値データを知識ベース１４０を参照して解析するデータ解析部１２０、データ解析部１２０から取得した解析結果に基づいて診断モデル１５０を参照し、オブジェクトの異常等を診断する診断エージェント１２０、数値データを解析するための推論規則を格納する知識ベース１４０、木構造を有する診断モデル１５０より構成される。
【００２０】
センサ３００は、オブジェクト４００を監視し、オブジェクト４００の部分的な情報を所定の時間間隔、または、センサ入力保持部１１０からの指示により数値データとして取得し、ノード１００のセンサ入力保持部１１０に転送する。
データ解析部１２０は、センサ入力保持部１１０から取得する数値データ以外に、診断の材料となるデータであればどのようなデータであってもよく、他のエージェントから取得したデータも用いる。例えば、異常時の各エージェントから渡されたメモリダンプ等であってもよい。このような数値データを取得して、知識ベース１４０を参照して、現象や症状に変換する。
【００２１】
診断エージェント１３０は、図２に示すような診断モデル１５０を参照する。同図に示す診断モデル１５０は、３つの階層から構成される木構造を有し、根が異常原因で、葉が現象・症状を表している。この診断エージェント１３０により参照される診断モデル１５０は、エージェント毎に同じでも、異なっていてもよく、オブジェクト４００の解析が可能なモデルを必要に応じてｎ種類保持するものとする。また、解析対象のオブジェクト４００に変更等が生じた場合には、当該オブジェクト４００に対応する診断モデル１５０を付随して更新する。
【００２２】
また、ここで、診断モデル１５０について詳細に説明する。
図２における診断モデル１５０の例において、根には、障害原因（Ａ）、その原因で生起する中間的な現象（Ｂ，Ｃ）、その現象が原因となって最終的に現れる現象（Ｄ，Ｅ，Ｆ，Ｇ，Ｈ）によりモデルを生成する。木の枝の関係は、“ＡＮＤ”だけとする。“ＯＲ”や“ＥＸＯＲ”の関係も考えられるが、一般的にこれらは“ＡＮＤ”のみを使って表すことができる。“ＯＲ”については、木を分割すればよく、“ＥＸＯＲ”は、“ＡＮＤ”と否定を用いることにより表すことができる。または、そのモデルに制約条件を付けることにしても“ＥＸＯＲ”を表すことができる。
【００２３】
診断モデル１５０の葉には、センサ入力保持部１１０から転送された数値データそのものを置くのではなく、データ解析部１２０において知識ベース１４０を参照することにより変換された現象や症状が設定される。例えば、センサ１１０が温度センサである場合、当該温度センサからの入力データが時間の経過と共に上昇している現象については、知識ベース１４０を用いて「温度の上昇」という現象となる。
【００２４】
知識ベース１４０は、図３に示すように、診断部１２０においてデータ解析部１２０から渡される症状情報（数値データ）を解析する際に参照される法則が格納されている。当該知識ベース１４０は、診断対象の設計知識に基づいて作成され、事象生起の原因と結果の関係を導出し、例えば、原因がＡであれば、Ｂという結論となるというような原因と解析結果の因果関係を示す知識を生成する。従って、当該知識ベース１４０は、診断モデル１５０と同様に、解析対象のオブジェクト４００が変更された場合に、当該オブジェクトの監視結果である数値データを解析可能なように適宜更新することが可能である。
【００２５】
このような構成により、診断エージェント１３０は、データ解析部１２０で変換された現象・症状を取得すると、ある一つの診断モデル１５０の葉（現象・症状）と照合し、その診断モデル１５０の根の異常原因が仮定される。このように仮定された照合結果毎に仮想の子エージェントを作成し、その子エージェントのレベルで他のエージェントとの間でメッセージを交換して、他のエージェントで照合する葉を調べる。そして、診断モデル１５０の照合した葉の数で仮説の確からしさを監視者２００に通知する。なお、データ解析部１２０において、変換されたセンサ３００からの入力（現象・症状）が複数の診断モデル１５０に照合した場合には複数の子エージェントが生成されることになる。
【００２６】
次に、上記の構成における診断の方法を説明する。図４は、本発明の２つの診断エージェント間におけるリンケージを示すシーケンスチャートである。同図に示す例は、ノード１００Ａとノード１００Ｂ間におけるリンケージを示す。
ステップ１０１） センサ３００Ａがオブジェクト４００Ａの状態を検出し、その状態を数値データとしてノード１００Ａのセンサ入力保持部１１０に転送する。
【００２７】
ステップ１０２） データ解析部１２０は、センサ入力保持部１１０より数値データを取得して知識ベース１４０を参照して、当該数値データを現象・症状を取得する。
ステップ１０３） 診断エージェント１３０は、データ解析部１２０の解析結果である現象・症状等の異常症状情報に基づいて診断モデル１５０にマッチする現象や症状が発生していないかをチェックする。チェック方法は、診断エージェント１３０においてデータ解析部１２０から取得した異常症状情報を解析して診断モデルの葉と照合し、その診断モデルの異常原因を仮説とする。
【００２８】
ステップ１０４） ステップ１０３において照合した結果、マッチした葉を有する診断モデルの根の異常原因が発生していると仮定し、自エージェントで確認された葉以外が他のエージェントで確認できないかを他のノード１００Ｂのエージェント１３０Ｂに問い合わせる。
ステップ１０５） ノード１００Ｂの診断エージェント１３０Ｂは、問い合わせを受ける毎に子エージェントを生成し、自エージェント１３０Ｂにおいてセンサ入力保持部１１０から取得した数値情報に基づいて診断モデル１５０を参照して診断エージェント１３０Ａから問い合わせがあった現象または、データがあるかをチェックする。
【００２９】
詳しくは、問い合わせの現象・症状が発生していなかを自エージェントのセンサ入力保持部１１０からセンサ情報を取得して解析することにより調査する。または、問い合わせにマッチするセンサ３００からの入力がないかを調べる。あれば、それを診断エージェント１３０Ａに返答するメッセージとする。このとき、センサ３００から入力される情報の時間的な整合性が必要となる。
【００３０】
診断エージェント１３０Ｂは、診断エージェント１３０Ａからの問い合わせに反する現象が発生している場合もノード１００Ａの診断エージェント１３０Ａに通知するものとする。
ステップ１０６） 診断エージェント１３０Ｂは、更に、他の診断エージェント１３０Ｃからセンサ３００Ｃの入力があったと仮定すると、診断エージェント１３０Ａからの問い合わせの現象・症状が確認できる場合は、当該センサ３００Ｃからの入力が他のエージェントにないかを問い合わせ、その返答を待つ。
【００３１】
また、診断エージェント１３０Ａからの問い合わせ現象を満たす要素を知識ベース１４０Ｂから取得する、または、自センサ入力保持部１１０Ｂから、問い合わせ現象を満たす要素が入力されたかをチェックする。
ステップ１０７） 診断エージェント１３０Ｂは、自診断モデル１５０Ｂを参照してチェックした結果及び他の診断エージェント１３０Ｃから取得した結果を確認し、診断エージェント１３０Ａに通知する。
【００３２】
ステップ１０８） 問い合わせの返答を受け取った診断エージェント１３０Ａは、異常原因と診断モデル１５０Ａにおいて成立した葉の割合（異常原因と診断モデル１５０Ａの葉（現象・症状）のうちのいくつ確認できたか（確信度））を診断対象の監視者（センタ）２００に通知する。このとき、もし、ノード１００Ｂの診断エージェント１３０Ｂから取得した結果において、問い合わせの現象に反する現象が観測された場合には、当該観測結果を取得することになる。診断モデル１５０は“ＡＮＤ木”であるので、仮定した原因が間違っていることになり、その場合には処理を終了する。
【００３３】
なお、ここで、診断エージェント１３０Ａから診断エージェント１３０Ｂへの問い合わせの現象に反する現象（反例）とは、仮定した原因を説明する現象を否定する現象が確認された場合を指す。また、監視者２００に通知する時に、確認できなかった現象は、成立が不明な現象であって、反例とは区別されるものである。
【００３４】
【実施例】
以下、本発明の実施例を図面と共に説明する。
図５は、本発明の一実施例の診断システムの構成を示す。
同図に示す構成は、説明の簡単化のため、３つのエージェントを用いて説明する。各エージェントの構成は、図１に示す構成を有するものとし、各ノード１００の構成要素には、それぞれＡ，Ｂ，Ｃの符号を付して説明する。
【００３５】
同図に示すノード１００間において、診断エージェント１３０Ａから診断エージェント１３０Ｂに対して自ノード１００Ａで発生している現象について診断エージェント１３０Ｂに問い合わせを行い、診断エージェント１３０Ｂは、作成した子エージェントについて他のノード１００Ｃの診断エージェント１３０Ｃに問い合わせを行い、診断エージェント１３０Ｃから取得した結果と、自診断エージェント１３０Ｂの照合結果を照合し、その結果をノード１００Ａの診断エージェント１３０Ａに通知する。これにより、エージェント１３０Ａが最終的な照合結果を監視者２００に通知する例を説明する。
【００３６】
なお、図５において、“ｑ”は、他のノードの診断エージェントに対する問い合わせを示し、“ａ”は、他の診断エージェントから問い合わせ元に対する返答を示す。
（１） ノード１００Ａのデータ解析部１２０Ａは、知識ベース１４０Ａを参照して、図２に示す葉に照合する現象が起きていないかをチェックする。図５の例では、
ｘ → Ｈ，
ｙ → Ｇ
から、診断モデル１５０Ａの２つの葉に照合する。照合すると、子エージェントを作成する。
【００３７】
（２） 照合する葉を持つモデルの異常原因、即ち、根のＡが起きていると仮定し、他の葉（現象・症状）が他のノードで起きていなかを他のノードの診断エージェント１３０Ｂに問い合わせる（ｑ１：Ｄ，Ｅ，Ｆ）。図２の例では、Ｄ，Ｅ，Ｆである。
（３） 他のノード１００Ｂの診断エージェント１３０Ｂでは、ノード１００Ａの診断エージェント１３０Ａから問い合わせを受け取り、成立していないかを調べる。図５の例では、診断ノード１００Ｃにおいて、センサ３００Ｃの入力が“ｚ”であるため、知識ベース１４０Ｃを参照すると、図２における“Ｄ”が成立していることが分かる。これにより診断エージェント１３０Ｃは、ノード１００Ｂの診断ノード１００Ｂからの問い合わせ（ｑ１）に対する返答（ａ１：Ｄ）をノード１００Ｂに通知する。
【００３８】
（４） また、診断エージェント１３０Ｂでは、センサ３００Ｂからの入力ｘを仮定すれば“Ｅ”が成立するので、センサ３００Ｂから入力ｘがないかを他のノード１００Ａの診断エージェント１３０Ａ，１３０Ｃに問い合わせる（ｑ２：ｘ）。ここで、当該入力ｘが、診断エージェント１３０Ａにセンサ３００Ａより入力されているため、診断エージェント１３０Ａがノード１００Ｂの診断エージェント１３０Ｂに対して当該入力ｘが自ノード１００Ａのセンサ３００Ａから入力されている旨を通知する（ａ２：ｘ）。
【００３９】
（５） もし、他のノードの診断ノード１００で問い合わせに反する情報（反例）を持っている場合は、その旨を通知することにより、枝の刈り取りが可能となる。枝の刈り取りは、探索範囲を狭めるために反例を利用する。知識ベース１４０に、例えば、ｕ→〜Ｇというような推論規則を設定しておき、センサ３００の入力がｕであれば、Ｇを葉に持つ部分木を探索範囲から外すことができる。これにより構造木の探索時間が削減される。
【００４０】
（６） ノード１００Ａの診断エージェント１３０Ａは、図２の異常状態にある根Ａのモデルの葉の４／５が満たされていることを監視者２００に通知する。
次に、本発明を交通システムに適用した例を説明する。
図６は、本発明の一実施例の交通システムへの適用例を示し、図７は、本発明の一実施例の交通システムの知識ベースの例を示し、図８は、本発明の一実施例の診断モデルの例である。
【００４１】
知識ベース１４０は、各ノード１００Ａ，Ｂ，Ｃに共通の知識が格納されているものとする。ここで、知識ベース１４０の内容は、センサ３００から取得される数値データが０〜２０％は、『空き状態（＝ＱＵＴ）』、２１〜４０％は、『順調（＝ＦＡＶ）』、４１〜６０％は、『やや渋滞（＝ＬＪＡＭ）』、６１〜８０％は、『渋滞（＝ＪＡＭ）』、８１〜１００％は、『かなり渋滞（＝ＭＪＡＭ）』であるとする。
【００４２】
なお、ノード１００Ａ，１００Ｂ，１００Ｃは、ある道路において監視対象の地点をオブジェクト４００としている。
（１） ノード１００Ａにおいて、交通量センサ３００Ａからセンサ入力保持部１１０が数値データとして７５％を取得したものとする。つまり、交通量センサ３００Ａでは、交通量を監視した結果、所定の時間における交通量を調査し、最大交通量との割合を取得してノード１００Ａのセンサ入力データ保持部１１０Ａに通知する。
【００４３】
（２） ノード１００Ａのデータ解析部１２０Ａは、知識ベース１４０Ａを参照して、図８に示す葉に照合する現象が起きていないかをチェックする。図７の例では、７５％は、閾値６１〜８０％に該当するため、
７５％ → ＪＡＭ
から、診断モデルの２つの葉に照合する。照合すると、子エージェントを作成する。
【００４４】
（３） 照合する葉を持つモデルの異常原因、即ち、根の『ＭＪＡＭ』が起きていると仮定し、他の葉（現象・症状）が他のノードで起きていなかを他のノードの診断エージェント１３０Ｂに問い合わせる（ｑ１：ＱＵＴ，ＬＪＡＭ，ＬＪＡＭ）。
（４） 他のノード１００Ｂの診断エージェント１３０Ｂでは、ノード１００Ａの診断エージェント１３０Ａから問い合わせを受け取り、成立していないかを調べる。診断ノード１００Ｃにおいて、センサ３００Ｃの入力が“５９％”であるため、知識ベース１４０Ｃを参照すると、図７における“ＬＪＡＭ”が成立していることが分かる。これにより診断エージェント１３０Ｃは、ノード１００Ｂの診断ノード１００Ｂからの問い合わせ（ｑ１）に対する返答（ａ１：ＬＪＡＭ）をノード１００Ｂに通知する。
【００４５】
（５） また、診断エージェント１３０Ｂでは、センサ３００Ｂからの入力６１〜８０％を仮定すれば“ＬＪＡＭ”が成立するので、センサ３００Ｂから６１〜８０％の間の入力値がないかを他のノード１００Ａの診断エージェント１３０Ａ，１３０Ｃに問い合わせる（ｑ２：ＪＡＭ）。ここで、当該入力８０％が、診断エージェント１３０Ａにセンサ３００Ａより入力されているため、診断エージェント１３０Ａがノード１００Ｂの診断エージェント１３０Ｂに対して当該入力８０％が自ノード１００Ａのセンサ３００Ａから入力されている旨を通知する（ａ２：ＪＡＭ）。
【００４６】
（６） これにより、ノード１００Ｂの診断エージェント１３０Ｂは、ノード１００Ａの診断エージェント１３０Ａに対して、ＬＪＡＭとＪＡＭが成立していることを通知する。診断エージェント１３０Ａは、診断エージェント１３０Ｂから取得したデータに基づいて、自ノード１００Ａが渋滞している原因は、自ノード１００Ａの地点のみならず、他のノード１００Ｂ，１００Ｃの各オブジェクト（地点）においても混雑していることが原因であると推測して、当該結果を交通管制センタ２００に通知する。
【００４７】
このように、交通システムにおいて、複数の地点における交通量から渋滞情報を抽出することにより、各ノードにおいてローカルに信号機等の切り替え時間の制御を行うことも可能となる。
また、上記の例では、問い合わせたノードにおいて、多少のレベルの差があるものの、渋滞状態を示しているが、この例に限定されることなく、反する現象（反例：順調、空き）を検出した場合には、誤りとは判定せずに、反例を検出したノードの状態を棄却せずに、信号の切り替え時間の制御に用いることにより、「空き」や「順調」の現象を取得したノードの地点では、信号待ち時間を長くする等の制御も考えられる。
【００４８】
また、上記の実施例では、交通システムに対応させた例を示したが、この例に限定されることなく、プラントにおける工程管理等にも適用が可能である。プラントに適用させた場合には、各ノードにおけるジョブの進行状態を調査し、もし所定の期限より工程が遅延している箇所をノード間の問い合わせ／応答により見つけることも可能である。
【００４９】
なお、本発明において、上記の実施例における各ノードの機能をプログラムで構築し、ディスク装置に格納する、または、フロッピーディスクやＣＤ−ＲＯＭ等の可搬記憶媒体に格納することも可能である。
なお、本発明は、上記の実施例に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【００５０】
【発明の効果】
上述のように、本発明によれば、分散配置されているノードにおいて、各ノードの診断対象のオブジェクトの監視を行い、隣接するノードや他のノードにアクセスすることにより、ノード単独で当該オブジェクトの情報を把握することが可能となる。従って、従来のように、診断ノードからのアラームを全て１か所のセンタに送信する必要がなく、ノードとセンタ間の通信負荷を削減することが可能となる。
【００５１】
また、本発明によれば、各ノードにおいて、隣接するまたは、予め関連が定義されているノードに対して問い合わせを行い、自ノードの異常原因を把握することが可能となるため、従来のように、センタにおいて全てのノードまたは、関連する全てのノードの情報をサンプリングする必要がなく、ローカルなノード単位で異常原因による対策等を講じることが可能となり、異常原因の復旧処理等を迅速に行うことが可能となる。さらに、問い合わせを受けたノードにおいても自ノードに入来するセンシング情報及び問い合わせノードから取得した現象・症状による自ノードの状態を把握することも可能となるため、問い合わせされたノードにおいて、問い合わせ元に反映されている原因がある場合には、自ノードにおいて対策を講じることも可能である。従って、あるセンサやあるノードのエージェントが故障や保守休止中であっても、残されたセンサとエージェントで一定精度の診断を実行できる。
【００５２】
これにより、診断システム全体のロバストネス、サバイバビリティが大幅に向上する。同様に、センタが何らかの理由により休止した場合であっても、ローカルに配置された各ノードにおいて問い合わせが可能な範囲のノードのエージェントに問い合わせすることにより、オブジェクト状態を把握することが可能である。
【００５３】
また、各エージェントに異なる診断モデルを複数おくことが可能であるので、部分的な設計情報で診断モデルを作成することが可能である。
また、本発明によれば、ノード毎に解析された原因の確信度の情報のみを収集することが可能となるため、センタにおいてすべてのセンシング情報を収集し、処理する必要がないため、センタの処理負荷が削減される。
【００５４】
また、本発明によれば、木構造を採用することにより、原因を事象駆動型の後ろ向き推論が可能となり、「葉」の部分により順に「根」まで辿ることにより、容易に異常原因を突き止めることが可能となる。
また、本発明によれば、問い合わせノードのみならず、問い合わせ先のノードにおいても現象や症状も把握できると共に、他のノードとの異常原因の関連性を把握することが可能となり、センタに問い合わせを行わなくともローカルなレベルで処理が可能となる。
【００５５】
また、本発明によれば、オブジェクトの変更・追加があった場合でも診断モデル及び知識ベースをノード単位で更新することが可能となるため、診断システムの柔軟性、拡張性が向上する。これにより、センタにおいて大規模なプログラムや診断モデルや知識ベースの更新作業を行うことなく、ローカルなレベルでの更新作業のみに留めることが可能となる。
【図面の簡単な説明】
【図１】本発明の診断システムの構成図である。
【図２】本発明の診断モデルの例である。
【図３】本発明の知識ベースの例である。
【図４】本発明の２つの診断エージェント間におけるリンケージを示すシーケンスチャートである。
【図５】本発明の一実施例の診断システムの構成図である。
【図６】本発明の一実施例の交通システムへの適用例を示す図である。
【図７】本発明の一実施例の交通システムにおける知識ベースの例である。
【図８】本発明の交通システムにおける診断モデルの例である。
【図９】従来の診断システムの構成図である。
【符号の説明】
１００ ノード
１１０ センサ入力保持部
１２０ データ解析部
１３０ 診断エージェント
１４０ 知識ベース
１５０ 診断モデル
２００ 監視者（センタ）
３００ センサ
４００ オブジェクト
５００ ＬＡＮ／ＷＡＮ
【発明の属する技術分野】
本発明は、分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体に係り、特に、対象の診断モデルを有し、種々のジョブの複合体であるプラントやネットワークの複数のノードにおけるオペレーション等の分散システムにおいて各ノードで発生した異常を診断するための分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体に関する。
【０００２】
分散システムの診断対象は、プラント、分散オペレーティングシステム、通信システム、交通システム等のノード（構成要素）が分散していて、全体として一つのシステムを構成するものである。
【０００３】
【従来の技術】
図９は、従来の診断システムの構成を示す。同図に示すように、従来は、複数のノード１０1 〜１０ nとセンタ２０が回線を介して接続されており、例えばノード１０1 でオペレーションによるエラーを検出すると、アラーム信号は、回線を介してセンタ２０に集められる。これにより、センタ２０は、アラーム信号を受信すると、異常ノードを認識し、当該ノードに対する復旧処理等を指示する。また、センタ２０では、複数のノードの動作状態を監視し、複数のノードから送信されるアラーム信号をサンプリングして、異常原因となっているノードを抽出する。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記従来の診断システムは、１つセンタにおいて複数のノードから収集されたアラーム信号を処理しているため、少ないノードで構成される小規模なシステムであれば問題はないが、大規模なシステムにおける多数のノードからアラーム信号を受信すると、トラヒック量が増加し、回線が輻輳すると共に、センタの処理負荷が増大する。さらには、トラヒック量に比例して、センタ側の診断処理のためのサンプリング間隔が長くなり、早急に復旧処理等を講じなければならないノードへの対処が遅延する等の問題がある。
【０００５】
また、センサ自体が何らかの異常により停止している場合には、オブジェクトの異常を検知できないという問題がある。
さらに、診断対象（オブジェクト）に仕様や構成の変更が生じた場合には、ノードの仕様等が変更になるばかりではなく、センタにおいて、オブジェクトの変更に応じたプログラム等の変更の処理が必要となる。また、新たなノード及び新たなオブジェクトが設置された場合にも同様に、それらのノードやオブジェクトに対応した新規のシステム生成処理が必要となり、柔軟性や拡張性において問題がある。
【０００６】
本発明は、上記の点に鑑みなされたもので、ノードからセンタへのトラヒック負荷を削減することが可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することを目的とする。
また、本発明の目的は、センサが故障や保守のために休止している状態であってもノードの診断が可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することである。
【０００７】
また、更なる目的は、オブジェクトの仕様や構成の変更に柔軟に対処可能な分散システムにおける診断システム及び分散システムにおける診断プログラムを格納した記憶媒体を提供することである。
【０００８】
【課題を解決するための手段】
本発明は、ネットワーク上に分散配置される診断対象のオブジェクトと、
オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
センサからのデータによりオブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有し、
ノードは、
センサから渡されたセンシング情報を保持するセンサ入力情報保持手段と、
センシング情報を解析するための知識を格納する知識ベースと、
センシング情報に基づいて知識ベースを参照して該センシング情報を解析する解析手段と、
異常原因と該異常原因の現象及び症状を有する少なくとも１つの診断モデルと、
解析手段により解析された結果に基づいて診断モデルとの照合を行い、異常原因の仮説を生成すると共に、該仮説についての問い合わせを他のノードに対して行い、該他のノードからの通知に基づいて異常原因の推論を行う推論手段と、
推論手段による推論結果を診断対象の監視者のセンタに通知する通知手段と、
を有する。
【００１０】
本発明は、上記の通知手段において、異常原因と診断モデルの現象及び症状のうち、いくつが確認できたかを確信度としてセンタに通知する。
本発明は、上記の診断モデルにおいて、異常原因を根とし、該異常原因の現象及び症状を葉とする木構造とする。
【００１１】
本発明は、上記の推論手段において、他のノードの推論手段から渡された問い合わせに応じて、自ノードに入力されるセンシング情報を解析して、問い合わせの現象または、症状を確認する確認手段と、
確認手段において現象または症状を確認できる場合に、他のノードに問い合わせにマッチするセンシング情報の入力がないかを問い合わせ、推論を行う手段と、を有し、問い合わせ元のノードへ推論結果を返却する問い合わせ応答手段を含む。
【００１２】
本発明の診断モデルは、オブジェクトの変更・追加により随時更新される。
本発明の知識ベースは、オブジェクトの変更・追加により随時更新される。
本発明は、ネットワーク上に分散配置される診断対象のオブジェクトと、
オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
センサからのデータによりオブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有するシステムにおいて、
記憶手段に、センサから渡されたセンシング情報を保持するセンサ入力情報保持手段と、該センシング情報を解析するための知識を格納する知識ベースと、を有するノードとして利用されるコンピュータに、
請求項１乃至６記載の各手段を実行させるプログラムを格納した記憶媒体である。
【００１３】
本発明によれば、各オブジェクトに対応する個々のノードにおいて、センサでセンシングされたオブジェクトのセンシングデータに基づいて、当該オブジェクトの状態を診断すると共に、他のノードと協調することにより、自ノードの対象オブジェクトの状態を診断することが可能であるため、自ノードのみでは、確実に把握できなかったオブジェクトの異常原因等を把握することが可能となる。つまり、個々のノードにおいて、当該ノードに対応するオブジェクトの状態をセンタ管理することなく、ローカルなノードにおいて管理することが可能となり、センタへのトラヒック負荷が削減される。
【００１４】
また、本発明によれば、各ノードにおいて、センシング情報を知識ベースに基づいて解析し、その解析結果（現象・症状）に基づいて診断モデル（異常原因、現象・症状）との照合を行い、原因の仮説を生成すると共に、該仮説についての問い合わせを他のノードに対して行い、該他のノードからの通知に基づいて異常原因の推論を行うことにより、センタに依存しなくとも当該ノードに対応するオブジェクトの状態を把握することが可能であるため、当該オブジェクトに対する処理等を当該ノードの管理者により実施することも可能となる。
【００１５】
また、本発明によれば、あるノードにおいて、推論された最終的な結論をセンタに送信することにより、各ノードのセンサから取得したデータを直接センタで収集せずに、センタにおいて、ノード毎に解析された原因の確信度の情報のみを収集することが可能となる。
また、本発明によれば、異常原因を根とし、該異常原因の現象及び症状を葉とする木構造を採用することによい、原因を事象駆動型の後ろ向き推論が可能となり、葉の部分より順に根まで辿ることにより、異常原因を突き止めることが可能となる。
【００１６】
また、本発明によれば、他のノードの推論手段から渡された問い合わせに応じて、自ノードに入力されるセンシング情報を解析して、問い合わせの現象または、症状を確認する、さらに、他のノードに問い合わせにマッチするセンシング情報の入力がないかを問い合わせることにより、問い合わせノードとの状態の関連を探索して、問い合わせ元のノードに応答することが可能となる。これにより、問い合わせ元のノードでは、問い合わせ先のノードの現象や症状により他のノードとの異常原因の関連性を把握することが可能となる。
【００１７】
また、本発明によれば、オブジェクトの変更・追加があった場合でも診断モデル及び知識ベースをノード単位で更新することが可能となる。
【００１８】
【発明の実施の形態】
図１は、本発明の診断システムの構成を示す。同図に示す診断システムは、複数のノード１００（以下、単にエージェントと記す）がＬＡＮ／ＷＡＮ５００によりノード１００間及び監視者（センタ）２００と接続されている。また、各ノード１００は、センサ３００を介してオブジェクト４００を監視する。
【００１９】
各ノード１００は、エージェント固有のオブジェクト４００を監視する。また、各エージェント間では、ＬＡＮ／ＷＡＮ５００を介しての通信が可能であり、各ノード１００において診断した結果（異常症候情報）をノード１００間においてやり取りすることができる。
各ノード１００は、オブジェクト４００を監視し、センサ３００からオブジェクト４００の数値データを取得して当該数値データを保持するセンサ保持部１１０、センサ入力保持部１１０から取得した数値データを知識ベース１４０を参照して解析するデータ解析部１２０、データ解析部１２０から取得した解析結果に基づいて診断モデル１５０を参照し、オブジェクトの異常等を診断する診断エージェント１２０、数値データを解析するための推論規則を格納する知識ベース１４０、木構造を有する診断モデル１５０より構成される。
【００２０】
センサ３００は、オブジェクト４００を監視し、オブジェクト４００の部分的な情報を所定の時間間隔、または、センサ入力保持部１１０からの指示により数値データとして取得し、ノード１００のセンサ入力保持部１１０に転送する。
データ解析部１２０は、センサ入力保持部１１０から取得する数値データ以外に、診断の材料となるデータであればどのようなデータであってもよく、他のエージェントから取得したデータも用いる。例えば、異常時の各エージェントから渡されたメモリダンプ等であってもよい。このような数値データを取得して、知識ベース１４０を参照して、現象や症状に変換する。
【００２１】
診断エージェント１３０は、図２に示すような診断モデル１５０を参照する。同図に示す診断モデル１５０は、３つの階層から構成される木構造を有し、根が異常原因で、葉が現象・症状を表している。この診断エージェント１３０により参照される診断モデル１５０は、エージェント毎に同じでも、異なっていてもよく、オブジェクト４００の解析が可能なモデルを必要に応じてｎ種類保持するものとする。また、解析対象のオブジェクト４００に変更等が生じた場合には、当該オブジェクト４００に対応する診断モデル１５０を付随して更新する。
【００２２】
また、ここで、診断モデル１５０について詳細に説明する。
図２における診断モデル１５０の例において、根には、障害原因（Ａ）、その原因で生起する中間的な現象（Ｂ，Ｃ）、その現象が原因となって最終的に現れる現象（Ｄ，Ｅ，Ｆ，Ｇ，Ｈ）によりモデルを生成する。木の枝の関係は、“ＡＮＤ”だけとする。“ＯＲ”や“ＥＸＯＲ”の関係も考えられるが、一般的にこれらは“ＡＮＤ”のみを使って表すことができる。“ＯＲ”については、木を分割すればよく、“ＥＸＯＲ”は、“ＡＮＤ”と否定を用いることにより表すことができる。または、そのモデルに制約条件を付けることにしても“ＥＸＯＲ”を表すことができる。
【００２３】
診断モデル１５０の葉には、センサ入力保持部１１０から転送された数値データそのものを置くのではなく、データ解析部１２０において知識ベース１４０を参照することにより変換された現象や症状が設定される。例えば、センサ１１０が温度センサである場合、当該温度センサからの入力データが時間の経過と共に上昇している現象については、知識ベース１４０を用いて「温度の上昇」という現象となる。
【００２４】
知識ベース１４０は、図３に示すように、診断部１２０においてデータ解析部１２０から渡される症状情報（数値データ）を解析する際に参照される法則が格納されている。当該知識ベース１４０は、診断対象の設計知識に基づいて作成され、事象生起の原因と結果の関係を導出し、例えば、原因がＡであれば、Ｂという結論となるというような原因と解析結果の因果関係を示す知識を生成する。従って、当該知識ベース１４０は、診断モデル１５０と同様に、解析対象のオブジェクト４００が変更された場合に、当該オブジェクトの監視結果である数値データを解析可能なように適宜更新することが可能である。
【００２５】
このような構成により、診断エージェント１３０は、データ解析部１２０で変換された現象・症状を取得すると、ある一つの診断モデル１５０の葉（現象・症状）と照合し、その診断モデル１５０の根の異常原因が仮定される。このように仮定された照合結果毎に仮想の子エージェントを作成し、その子エージェントのレベルで他のエージェントとの間でメッセージを交換して、他のエージェントで照合する葉を調べる。そして、診断モデル１５０の照合した葉の数で仮説の確からしさを監視者２００に通知する。なお、データ解析部１２０において、変換されたセンサ３００からの入力（現象・症状）が複数の診断モデル１５０に照合した場合には複数の子エージェントが生成されることになる。
【００２６】
次に、上記の構成における診断の方法を説明する。図４は、本発明の２つの診断エージェント間におけるリンケージを示すシーケンスチャートである。同図に示す例は、ノード１００Ａとノード１００Ｂ間におけるリンケージを示す。
ステップ１０１） センサ３００Ａがオブジェクト４００Ａの状態を検出し、その状態を数値データとしてノード１００Ａのセンサ入力保持部１１０に転送する。
【００２７】
ステップ１０２） データ解析部１２０は、センサ入力保持部１１０より数値データを取得して知識ベース１４０を参照して、当該数値データを現象・症状を取得する。
ステップ１０３） 診断エージェント１３０は、データ解析部１２０の解析結果である現象・症状等の異常症状情報に基づいて診断モデル１５０にマッチする現象や症状が発生していないかをチェックする。チェック方法は、診断エージェント１３０においてデータ解析部１２０から取得した異常症状情報を解析して診断モデルの葉と照合し、その診断モデルの異常原因を仮説とする。
【００２８】
ステップ１０４） ステップ１０３において照合した結果、マッチした葉を有する診断モデルの根の異常原因が発生していると仮定し、自エージェントで確認された葉以外が他のエージェントで確認できないかを他のノード１００Ｂのエージェント１３０Ｂに問い合わせる。
ステップ１０５） ノード１００Ｂの診断エージェント１３０Ｂは、問い合わせを受ける毎に子エージェントを生成し、自エージェント１３０Ｂにおいてセンサ入力保持部１１０から取得した数値情報に基づいて診断モデル１５０を参照して診断エージェント１３０Ａから問い合わせがあった現象または、データがあるかをチェックする。
【００２９】
詳しくは、問い合わせの現象・症状が発生していなかを自エージェントのセンサ入力保持部１１０からセンサ情報を取得して解析することにより調査する。または、問い合わせにマッチするセンサ３００からの入力がないかを調べる。あれば、それを診断エージェント１３０Ａに返答するメッセージとする。このとき、センサ３００から入力される情報の時間的な整合性が必要となる。
【００３０】
診断エージェント１３０Ｂは、診断エージェント１３０Ａからの問い合わせに反する現象が発生している場合もノード１００Ａの診断エージェント１３０Ａに通知するものとする。
ステップ１０６） 診断エージェント１３０Ｂは、更に、他の診断エージェント１３０Ｃからセンサ３００Ｃの入力があったと仮定すると、診断エージェント１３０Ａからの問い合わせの現象・症状が確認できる場合は、当該センサ３００Ｃからの入力が他のエージェントにないかを問い合わせ、その返答を待つ。
【００３１】
また、診断エージェント１３０Ａからの問い合わせ現象を満たす要素を知識ベース１４０Ｂから取得する、または、自センサ入力保持部１１０Ｂから、問い合わせ現象を満たす要素が入力されたかをチェックする。
ステップ１０７） 診断エージェント１３０Ｂは、自診断モデル１５０Ｂを参照してチェックした結果及び他の診断エージェント１３０Ｃから取得した結果を確認し、診断エージェント１３０Ａに通知する。
【００３２】
ステップ１０８） 問い合わせの返答を受け取った診断エージェント１３０Ａは、異常原因と診断モデル１５０Ａにおいて成立した葉の割合（異常原因と診断モデル１５０Ａの葉（現象・症状）のうちのいくつ確認できたか（確信度））を診断対象の監視者（センタ）２００に通知する。このとき、もし、ノード１００Ｂの診断エージェント１３０Ｂから取得した結果において、問い合わせの現象に反する現象が観測された場合には、当該観測結果を取得することになる。診断モデル１５０は“ＡＮＤ木”であるので、仮定した原因が間違っていることになり、その場合には処理を終了する。
【００３３】
なお、ここで、診断エージェント１３０Ａから診断エージェント１３０Ｂへの問い合わせの現象に反する現象（反例）とは、仮定した原因を説明する現象を否定する現象が確認された場合を指す。また、監視者２００に通知する時に、確認できなかった現象は、成立が不明な現象であって、反例とは区別されるものである。
【００３４】
【実施例】
以下、本発明の実施例を図面と共に説明する。
図５は、本発明の一実施例の診断システムの構成を示す。
同図に示す構成は、説明の簡単化のため、３つのエージェントを用いて説明する。各エージェントの構成は、図１に示す構成を有するものとし、各ノード１００の構成要素には、それぞれＡ，Ｂ，Ｃの符号を付して説明する。
【００３５】
同図に示すノード１００間において、診断エージェント１３０Ａから診断エージェント１３０Ｂに対して自ノード１００Ａで発生している現象について診断エージェント１３０Ｂに問い合わせを行い、診断エージェント１３０Ｂは、作成した子エージェントについて他のノード１００Ｃの診断エージェント１３０Ｃに問い合わせを行い、診断エージェント１３０Ｃから取得した結果と、自診断エージェント１３０Ｂの照合結果を照合し、その結果をノード１００Ａの診断エージェント１３０Ａに通知する。これにより、エージェント１３０Ａが最終的な照合結果を監視者２００に通知する例を説明する。
【００３６】
なお、図５において、“ｑ”は、他のノードの診断エージェントに対する問い合わせを示し、“ａ”は、他の診断エージェントから問い合わせ元に対する返答を示す。
（１） ノード１００Ａのデータ解析部１２０Ａは、知識ベース１４０Ａを参照して、図２に示す葉に照合する現象が起きていないかをチェックする。図５の例では、
ｘ → Ｈ，
ｙ → Ｇ
から、診断モデル１５０Ａの２つの葉に照合する。照合すると、子エージェントを作成する。
【００３７】
（２） 照合する葉を持つモデルの異常原因、即ち、根のＡが起きていると仮定し、他の葉（現象・症状）が他のノードで起きていなかを他のノードの診断エージェント１３０Ｂに問い合わせる（ｑ１：Ｄ，Ｅ，Ｆ）。図２の例では、Ｄ，Ｅ，Ｆである。
（３） 他のノード１００Ｂの診断エージェント１３０Ｂでは、ノード１００Ａの診断エージェント１３０Ａから問い合わせを受け取り、成立していないかを調べる。図５の例では、診断ノード１００Ｃにおいて、センサ３００Ｃの入力が“ｚ”であるため、知識ベース１４０Ｃを参照すると、図２における“Ｄ”が成立していることが分かる。これにより診断エージェント１３０Ｃは、ノード１００Ｂの診断ノード１００Ｂからの問い合わせ（ｑ１）に対する返答（ａ１：Ｄ）をノード１００Ｂに通知する。
【００３８】
（４） また、診断エージェント１３０Ｂでは、センサ３００Ｂからの入力ｘを仮定すれば“Ｅ”が成立するので、センサ３００Ｂから入力ｘがないかを他のノード１００Ａの診断エージェント１３０Ａ，１３０Ｃに問い合わせる（ｑ２：ｘ）。ここで、当該入力ｘが、診断エージェント１３０Ａにセンサ３００Ａより入力されているため、診断エージェント１３０Ａがノード１００Ｂの診断エージェント１３０Ｂに対して当該入力ｘが自ノード１００Ａのセンサ３００Ａから入力されている旨を通知する（ａ２：ｘ）。
【００３９】
（５） もし、他のノードの診断ノード１００で問い合わせに反する情報（反例）を持っている場合は、その旨を通知することにより、枝の刈り取りが可能となる。枝の刈り取りは、探索範囲を狭めるために反例を利用する。知識ベース１４０に、例えば、ｕ→〜Ｇというような推論規則を設定しておき、センサ３００の入力がｕであれば、Ｇを葉に持つ部分木を探索範囲から外すことができる。これにより構造木の探索時間が削減される。
【００４０】
（６） ノード１００Ａの診断エージェント１３０Ａは、図２の異常状態にある根Ａのモデルの葉の４／５が満たされていることを監視者２００に通知する。
次に、本発明を交通システムに適用した例を説明する。
図６は、本発明の一実施例の交通システムへの適用例を示し、図７は、本発明の一実施例の交通システムの知識ベースの例を示し、図８は、本発明の一実施例の診断モデルの例である。
【００４１】
知識ベース１４０は、各ノード１００Ａ，Ｂ，Ｃに共通の知識が格納されているものとする。ここで、知識ベース１４０の内容は、センサ３００から取得される数値データが０〜２０％は、『空き状態（＝ＱＵＴ）』、２１〜４０％は、『順調（＝ＦＡＶ）』、４１〜６０％は、『やや渋滞（＝ＬＪＡＭ）』、６１〜８０％は、『渋滞（＝ＪＡＭ）』、８１〜１００％は、『かなり渋滞（＝ＭＪＡＭ）』であるとする。
【００４２】
なお、ノード１００Ａ，１００Ｂ，１００Ｃは、ある道路において監視対象の地点をオブジェクト４００としている。
（１） ノード１００Ａにおいて、交通量センサ３００Ａからセンサ入力保持部１１０が数値データとして７５％を取得したものとする。つまり、交通量センサ３００Ａでは、交通量を監視した結果、所定の時間における交通量を調査し、最大交通量との割合を取得してノード１００Ａのセンサ入力データ保持部１１０Ａに通知する。
【００４３】
（２） ノード１００Ａのデータ解析部１２０Ａは、知識ベース１４０Ａを参照して、図８に示す葉に照合する現象が起きていないかをチェックする。図７の例では、７５％は、閾値６１〜８０％に該当するため、
７５％ → ＪＡＭ
から、診断モデルの２つの葉に照合する。照合すると、子エージェントを作成する。
【００４４】
（３） 照合する葉を持つモデルの異常原因、即ち、根の『ＭＪＡＭ』が起きていると仮定し、他の葉（現象・症状）が他のノードで起きていなかを他のノードの診断エージェント１３０Ｂに問い合わせる（ｑ１：ＱＵＴ，ＬＪＡＭ，ＬＪＡＭ）。
（４） 他のノード１００Ｂの診断エージェント１３０Ｂでは、ノード１００Ａの診断エージェント１３０Ａから問い合わせを受け取り、成立していないかを調べる。診断ノード１００Ｃにおいて、センサ３００Ｃの入力が“５９％”であるため、知識ベース１４０Ｃを参照すると、図７における“ＬＪＡＭ”が成立していることが分かる。これにより診断エージェント１３０Ｃは、ノード１００Ｂの診断ノード１００Ｂからの問い合わせ（ｑ１）に対する返答（ａ１：ＬＪＡＭ）をノード１００Ｂに通知する。
【００４５】
（５） また、診断エージェント１３０Ｂでは、センサ３００Ｂからの入力６１〜８０％を仮定すれば“ＬＪＡＭ”が成立するので、センサ３００Ｂから６１〜８０％の間の入力値がないかを他のノード１００Ａの診断エージェント１３０Ａ，１３０Ｃに問い合わせる（ｑ２：ＪＡＭ）。ここで、当該入力８０％が、診断エージェント１３０Ａにセンサ３００Ａより入力されているため、診断エージェント１３０Ａがノード１００Ｂの診断エージェント１３０Ｂに対して当該入力８０％が自ノード１００Ａのセンサ３００Ａから入力されている旨を通知する（ａ２：ＪＡＭ）。
【００４６】
（６） これにより、ノード１００Ｂの診断エージェント１３０Ｂは、ノード１００Ａの診断エージェント１３０Ａに対して、ＬＪＡＭとＪＡＭが成立していることを通知する。診断エージェント１３０Ａは、診断エージェント１３０Ｂから取得したデータに基づいて、自ノード１００Ａが渋滞している原因は、自ノード１００Ａの地点のみならず、他のノード１００Ｂ，１００Ｃの各オブジェクト（地点）においても混雑していることが原因であると推測して、当該結果を交通管制センタ２００に通知する。
【００４７】
このように、交通システムにおいて、複数の地点における交通量から渋滞情報を抽出することにより、各ノードにおいてローカルに信号機等の切り替え時間の制御を行うことも可能となる。
また、上記の例では、問い合わせたノードにおいて、多少のレベルの差があるものの、渋滞状態を示しているが、この例に限定されることなく、反する現象（反例：順調、空き）を検出した場合には、誤りとは判定せずに、反例を検出したノードの状態を棄却せずに、信号の切り替え時間の制御に用いることにより、「空き」や「順調」の現象を取得したノードの地点では、信号待ち時間を長くする等の制御も考えられる。
【００４８】
また、上記の実施例では、交通システムに対応させた例を示したが、この例に限定されることなく、プラントにおける工程管理等にも適用が可能である。プラントに適用させた場合には、各ノードにおけるジョブの進行状態を調査し、もし所定の期限より工程が遅延している箇所をノード間の問い合わせ／応答により見つけることも可能である。
【００４９】
なお、本発明において、上記の実施例における各ノードの機能をプログラムで構築し、ディスク装置に格納する、または、フロッピーディスクやＣＤ−ＲＯＭ等の可搬記憶媒体に格納することも可能である。
なお、本発明は、上記の実施例に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【００５０】
【発明の効果】
上述のように、本発明によれば、分散配置されているノードにおいて、各ノードの診断対象のオブジェクトの監視を行い、隣接するノードや他のノードにアクセスすることにより、ノード単独で当該オブジェクトの情報を把握することが可能となる。従って、従来のように、診断ノードからのアラームを全て１か所のセンタに送信する必要がなく、ノードとセンタ間の通信負荷を削減することが可能となる。
【００５１】
また、本発明によれば、各ノードにおいて、隣接するまたは、予め関連が定義されているノードに対して問い合わせを行い、自ノードの異常原因を把握することが可能となるため、従来のように、センタにおいて全てのノードまたは、関連する全てのノードの情報をサンプリングする必要がなく、ローカルなノード単位で異常原因による対策等を講じることが可能となり、異常原因の復旧処理等を迅速に行うことが可能となる。さらに、問い合わせを受けたノードにおいても自ノードに入来するセンシング情報及び問い合わせノードから取得した現象・症状による自ノードの状態を把握することも可能となるため、問い合わせされたノードにおいて、問い合わせ元に反映されている原因がある場合には、自ノードにおいて対策を講じることも可能である。従って、あるセンサやあるノードのエージェントが故障や保守休止中であっても、残されたセンサとエージェントで一定精度の診断を実行できる。
【００５２】
これにより、診断システム全体のロバストネス、サバイバビリティが大幅に向上する。同様に、センタが何らかの理由により休止した場合であっても、ローカルに配置された各ノードにおいて問い合わせが可能な範囲のノードのエージェントに問い合わせすることにより、オブジェクト状態を把握することが可能である。
【００５３】
また、各エージェントに異なる診断モデルを複数おくことが可能であるので、部分的な設計情報で診断モデルを作成することが可能である。
また、本発明によれば、ノード毎に解析された原因の確信度の情報のみを収集することが可能となるため、センタにおいてすべてのセンシング情報を収集し、処理する必要がないため、センタの処理負荷が削減される。
【００５４】
また、本発明によれば、木構造を採用することにより、原因を事象駆動型の後ろ向き推論が可能となり、「葉」の部分により順に「根」まで辿ることにより、容易に異常原因を突き止めることが可能となる。
また、本発明によれば、問い合わせノードのみならず、問い合わせ先のノードにおいても現象や症状も把握できると共に、他のノードとの異常原因の関連性を把握することが可能となり、センタに問い合わせを行わなくともローカルなレベルで処理が可能となる。
【００５５】
また、本発明によれば、オブジェクトの変更・追加があった場合でも診断モデル及び知識ベースをノード単位で更新することが可能となるため、診断システムの柔軟性、拡張性が向上する。これにより、センタにおいて大規模なプログラムや診断モデルや知識ベースの更新作業を行うことなく、ローカルなレベルでの更新作業のみに留めることが可能となる。
【図面の簡単な説明】
【図１】本発明の診断システムの構成図である。
【図２】本発明の診断モデルの例である。
【図３】本発明の知識ベースの例である。
【図４】本発明の２つの診断エージェント間におけるリンケージを示すシーケンスチャートである。
【図５】本発明の一実施例の診断システムの構成図である。
【図６】本発明の一実施例の交通システムへの適用例を示す図である。
【図７】本発明の一実施例の交通システムにおける知識ベースの例である。
【図８】本発明の交通システムにおける診断モデルの例である。
【図９】従来の診断システムの構成図である。
【符号の説明】
１００ ノード
１１０ センサ入力保持部
１２０ データ解析部
１３０ 診断エージェント
１４０ 知識ベース
１５０ 診断モデル
２００ 監視者（センタ）
３００ センサ
４００ オブジェクト
５００ ＬＡＮ／ＷＡＮ
Claims (7)
- ネットワーク上に分散配置される診断対象のオブジェクトと、
前記オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
前記センサからのデータにより前記オブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有し、
前記ノードは、
前記センサから渡された前記センシング情報を保持するセンサ入力情報保持手段と、
前記センシング情報を解析するための知識を格納する知識ベースと、
前記センシング情報に基づいて前記知識ベースを参照して該センシング情報を解析する解析手段と、
異常原因と該異常原因の現象及び症状を有する少なくとも１つの診断モデルと、
前記解析手段により解析された結果に基づいて前記診断モデルとの照合を行い、異常原因の仮説を生成すると共に、該仮説についての問い合わせを他のノードに対して行い、該他のノードからの通知に基づいて異常原因の推論を行う推論手段と、
前記推論手段による推論結果を診断対象の監視者のセンタに通知する通知手段と、
を有することを特徴とする分散システムにおける診断システム。 - 前記通知手段は、
異常原因と前記診断モデルの現象及び症状のうち、いくつが確認できたかを確信度として前記センタに通知する請求項１記載の分散システムにおける診断システム。 - 前記診断モデルは、
前記異常原因を根とし、該異常原因の現象及び症状を葉とする木構造とする請求項１記載の分散システムにおける診断システム。 - 前記推論手段は、
他のノードの推論手段から渡された問い合わせに応じて、自ノードに入力されるセンシング情報を解析して、問い合わせの現象または、症状を確認する確認手段と、
前記確認手段において前記現象または症状を確認できる場合に、他のノードに前記問い合わせにマッチするセンシング情報の入力がないかを問い合わせ、推論を行う手段と、を有し、問い合わせ元のノードへ推論結果を返却する問い合わせ応答手段を含む請求項１記載の分散システムにおける診断システム。 - 前記診断モデルは、
前記オブジェクトの変更・追加により随時更新される請求項１記載の分散システムにおける診断システム。 - 前記知識ベースは、
前記オブジェクトの変更・追加により随時更新される請求項１記載の分散システムにおける診断システム。 - ネットワーク上に分散配置される診断対象のオブジェクトと、
前記オブジェクトを監視し、任意または、所定の周期でセンシングし、センシング情報を出力するセンサと、
前記センサからのデータにより前記オブジェクトの状態を診断する複数の診断機能を有し、単独または、他との協調により診断を行う複数のノードとを有するシステムにおいて、
記憶手段に、前記センサから渡された前記センシング情報を保持するセンサ入力情報保 持手段と、該センシング情報を解析するための知識を格納する知識ベースと、を有するノードとして利用されるコンピュータに、
前記請求項１乃至６記載の各手段を実行させるプログラムを格納したことを特徴とする分散システムの診断プログラムを格納した記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14045097A JP3771001B2 (ja) | 1996-06-04 | 1997-05-29 | 分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14202096 | 1996-06-04 | ||
| JP8-142020 | 1996-06-04 | ||
| JP14045097A JP3771001B2 (ja) | 1996-06-04 | 1997-05-29 | 分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1055344A JPH1055344A (ja) | 1998-02-24 |
| JP3771001B2 true JP3771001B2 (ja) | 2006-04-26 |
Family
ID=26472953
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP14045097A Expired - Fee Related JP3771001B2 (ja) | 1996-06-04 | 1997-05-29 | 分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3771001B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007096959A1 (ja) * | 2006-02-22 | 2007-08-30 | Fujitsu Limited | イベントログ管理プログラム、イベントログ管理装置、およびイベントログ管理方法 |
| JP4612598B2 (ja) * | 2006-09-06 | 2011-01-12 | Ｎｅｃフィールディング株式会社 | サーバ運用支援システム、サーバ運用支援方法およびプログラム |
-
1997
- 1997-05-29 JP JP14045097A patent/JP3771001B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1055344A (ja) | 1998-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Mansouri-Samani et al. | GEM: A generalized event monitoring language for distributed systems | |
| CN107369303B (zh) | 工厂智能诊断方法、装置及系统 | |
| US20060085361A1 (en) | Anomaly detector in a health care system using adapter | |
| KR20180108446A (ko) | Ict 인프라 관리 시스템 및 이를 이용한 ict 인프라 관리 방법 | |
| JP5274667B2 (ja) | 安全ステップの判定方法および安全マネージャ | |
| JPH02105947A (ja) | コンピユータ周辺サブシステム及びその例外事象自動検出分析方法 | |
| JPH06236207A (ja) | 故障診断方法及び装置 | |
| SE470031B (sv) | System och metod för övervakning och förändring av driften av ett datorsystem | |
| CN101507185A (zh) | 使用贝叶斯网络的电信网络中的故障定位 | |
| CN108845912B (zh) | 服务接口调用故障的报警方法及计算设备 | |
| WO2007006811A1 (en) | System and method for detecting imbalances in dynamic workload scheduling in clustered environments | |
| EP0361387B1 (en) | Automatic operation control system for computer system | |
| US7469287B1 (en) | Apparatus and method for monitoring objects in a network and automatically validating events relating to the objects | |
| Chung | Diagnosing PN-based models with partial observable transitions | |
| CA2712172A1 (en) | Apparatus for system diagnosis | |
| US8601318B2 (en) | Method, apparatus and computer program product for rule-based directed problem resolution for servers with scalable proactive monitoring | |
| CN102141948A (zh) | 带噪声的监控器检测和间歇故障隔离 | |
| EP1476794B1 (en) | Apparatus, method and computer program product for modelling causality in a flow system | |
| Cherrared et al. | LUMEN: A global fault management framework for network virtualization environments | |
| Raj et al. | Cloud infrastructure fault monitoring and prediction system using LSTM based predictive maintenance | |
| JP3771001B2 (ja) | 分散システムの診断システム及び分散システムの診断プログラムを格納した記憶媒体 | |
| CN101790722A (zh) | 监视与共享媒介连接的航空电子系统的设备与方法 | |
| CN116204386B (zh) | 应用服务关系自动识别及监控方法、系统、介质和设备 | |
| Addouche et al. | UML models for dependability analysis of real-time systems | |
| US11543803B2 (en) | Process control system with an engineering system, an operator system and an archive system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040223 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040823 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050329 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050517 |
|
| 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: 20060207 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060208 |
|
| R150 | Certificate of patent (=grant) or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090217 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100217 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140217 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |