JP2015534179A - システム挙動診断のための論理ベースアプローチ - Google Patents

Abstract

ここに記載されているのは、システム状態を評価するための方法であり、この方法では、評価中のシステムの動作に関係するユーザ提供情報を受け取るステップ（Ｓ４１）が含まれている。受け取ったこの情報に基づき、上記のシステムの依存モデルを構築する（Ｓ４３ａ／ｂ）。上記のユーザ提供情報が、論理モデルを構築するのに十分であると判定された場合（Ｓ４２）、このシステムの論理モデルを構築して、これと依存モデルとを結合する（Ｓ４６）。システム内に実装されたセンサからのセンサデータが監視され、上記の結合モデルが利用可能である場合にはこの結合されたモデルが上記のセンサデータに適用され、上記の結合モデルが利用可能でない場合には上記の依存モデルが上記のセンサデータに適用される（Ｓ４８）。上記の結合モデル／依存モデルのセンサデータへの適用から、１つまたは複数の異常システムコンポーネントの集合が求められ、異常システムコンポーネントのこの求めた集合に基づいてシステム状態を評価する。

Description

本発明は、システム挙動診断に関しており、より具体的にはシステム挙動診断のための論理ベースアプローチに関するものである。

関連する明細書との相互参照
本発明は、２０１２年９月１７日付けで提出した米国暫定特許明細書第61/701,822号に基づくものであり、その全内容は参照によってここに取り込まれるものとする。

関連する技術分野についての考察
電気機械式装置、産業設備、大規模商業ビルディングなどの複合ダイナミックシステムには、種々異なる重要個所に設置された複数のセンサからなるネットワークが使用されており、これによって上記のシステムの動作状態に対する見通しがつけられる。このシステムの機能を監視することにより、適正な動作からの種々の偏差を観察することができ、メンテナンス、修復および取り替えなどの修繕のための行動を適時に行って、システムの稼働時間および信頼性を最大限に高めることができる。

しかしながら発生し得る故障、パラメタドリフト、ノイズ、センサの可観測性の限界などからなる膨大な集合のようなファクタに起因して、問題に対処するための十分な時間を伴って、故障を正確に診断することは殊に困難である。

したがって、どのようにしてシステムを診断し、また理想とは程遠いセンサデータから故障を予想するかは、複合的な動的な産業資産の管理において、取り組みがいのある困難な対象になるのである。

要約
本発明のシステム状態評価方法には、システムの動作に関係するユーザ供給情報を受け取ることが含まれており、このシステムの依存モデルが、受け取ったこの情報に基づいて構成される。上記のユーザ供給情報が上記の論理モデルを構築するのに十分であるとされた場合、上記のシステムの論理モデルが構築されて上記の依存モデルと結合される。この結合モデルが利用可能である場合にはこの結合モデルが上記のセンサデータに適用され、またこの結合モデルが利用できない場合には上記の依存モデルが上記のセンサデータに適用される。ここでは異常システムコンポーネントの集合が、上記の結合モデル／依存モデルのセンサデータへの適用から求められる。システム状態の評価は、この異常システムコンポーネントの集合に基づいて求められる。

評価中のシステムの動作に関係する上記のユーザ供給情報は、このシステムの１つまたは複数のコンポーネントの障害依存性についてのエキスパート知識、またはこのシステムの上記の１つまたは複数のコンポーネントの故障の仕方についてのエキスパート知識を含むことができる。

評価中のシステムの動作に関係する上記のユーザ供給情報は、ユーザにより、またはユーザ入力に基づいて自動的に、ＡＳＰ（Answer Set Programming）形式化でエンコードすることができる。

上記の構築された依存モデルおよび／または前記結合モデルは、ＡＳＰ（Answer Set Programming）形式化で表すことができる。

上記の構築された依存モデルは、評価中のシステムを通って故障がどのように伝播するかのみを記述することが可能である。

上記の構築された論理モデルは、評価中のシステムの１つまたは複数のコンポーネント間の複合的な機能的相互関係を記述することできる。

評価中のシステムの論理モデルを構築するために、上記の受け取ったユーザ提供情報が十分であるか否かの判定には、論理モデルを構築することと、この構築された論理モデルを監視されたセンサデータへの適用を試みることと、意味のある結果が得られるか否かを決定することとを含み得る。

上記の論理モデルと依存モデルとの上記の結合は、ＡＳＰ（Answer Set Programming）ソルバを使用して実行することができる。

上記のセンサデータへの上記の結合モデルまたは依存モデルの適用は、ＡＳＰ（Answer Set Programming）ソルバによって実行することができる。

１つまたは複数の異常システムコンポーネントの上記の求めた集合に基づくシステム状態の評価には、最小解を優先することが含まれ得る。

１つまたは複数の異常システムコンポーネントの上記の求めた集合に基づくシステム状態の評価には、最大個数のセンサによって裏付けられる解を優先することが含まれ得る。

上記のセンサデータへの上記の結合モデルまたは依存モデルの適用には、非単調論理の使用が含まれ得る。

本発明にはシステム状態を評価するための方法が記載されており、この方法では、評価中のシステムの依存モデルと、評価中のシステムの論理モデルとを受け取ることが含まれている。ここでは評価中のシステム内に実現されている１つまたは複数のセンサからのセンサデータが監視される。上記の論理モデルと依存モデルとが結合され、ＡＳＰ（Answer Set Programming）ソルバが使用されて、この結合モデルが上記のセンサデータに適用される。上記の結合モデルをセンタデータに適用することにより、１つまたは複数の異常システムコンポーネントの集合が求められる。さらに１つまたは複数の異常システムコンポーネントの求めた集合に基づいてシステム状態の評価が得られる。

１つまたは複数の異常システムコンポーネントの上記の求めた集合に基づくシステム状態の評価には、最小解を優先することが含まれ得る。

１つまたは複数の異常システムコンポーネントの上記の求めた集合に基づくシステム状態の評価には、最大個数のセンサによって裏付けられる解を優先することが含まれ得る。

本発明にはさらにコンピュータシステムが記載されており、このコンピュータシステムには、プロセッサと、このプロセッサによって実行可能な命令からなるプログラムを実現してシステム状態を評価するための方法のステップを実行する、上記のコンピュータシステムによって読み出し可能である非一時的な有体のプログラム記憶媒体とが含まれている。上記の方法では、評価中のシステムの動作に関係するユーザ提供情報を受け取る。ここでは評価中の上記のシステムの依存モデルが、上記の受け取ったユーザ提供情報に基づいて構築される。また受け取ったこのユーザ提供情報が、評価中のシステムの論理モデルを構築するのに十分であるか否かが判定される。このユーザ提供情報が十分であると判定された場合、評価中のシステムの論理モデルが構築されて、この論理モデルと上記の依存モデルとが結合される。また評価中のシステム内に実装された１つまたは複数のセンサからのセンサデータが監視される。上記の結合モデルが利用可能である場合には、上記のセンサデータにこの結合モデルが適用され、上記の結合モデルが利用可能でない場合には上記の依存モデルが適用される。上記の結合モデル／依存モデルのセンサデータへの適用から、１つまたは複数の異常システムコンポーネントの集合が求められる。上記の１つまたは複数の異常システムコンポーネントのこの求めた集合に基づいてシステム状態の評価が得られる。

上記の構築された依存モデルは、上記の評価中のシステムを通って故障がどのように伝播するかのみを記述することが可能である。

上記の構築された論理モデルは、上記の評価中のシステムの１つまたは複数のコンポーネント間の複合的な機能的相互関係を記述することが可能である。

上記の論理モデルと依存モデルとの結合は、ＡＳＰ（Answer Set Programming）ソルバを使用して実行することができる。

上記のセンサデータへの結合モデルまたは依存モデルの適用は、ＡＳＰ（Answer Set Programming）ソルバによって実行することができる。

１つまたは複数の異常システムコンポーネントの上記の求めた集合に基づくシステム状態の上記の評価には、最小解を優先するかまたは最大個数のセンサによって裏付けられる解を優先することを含むことが可能である。

本発明の実施例を説明するためのＷＴＰ（Water Tank Problem）を示す概略図である。 本発明の実施例を適用可能な簡略化した潤滑油システムを説明する図である。 本発明の実施例にしたがって図２のシステムに基づく依存モデルを表すステートメントの集合である。 本発明の実施例にしたがい、システム診断のためのハイブリッドアプローチを説明するフローチャートである。 本発明の実施例にしたがい、システム診断のための全体的なアーキテクチャを説明する図（Ａ）およびシステムを監視しかつ診断するためのシステムのアーキテクチャを説明する図（Ｂ）である。 上記の方法を実現することの可能なコンピュータシステムと、本発明の実施形態による装置との例を示す図である。

本発明の一層完全な評価およびその付随的な様相の多くは、以下の詳細な説明を参照し添付の図面に関連して考えれば一層理解され、容易に得られる。

図面の詳細な説明
図面に示した本発明の説明用の実施例において、わかりやすくするために特定の専門用語を使用した。しかしながら本発明は、このように選択された特定の専門用語に限定することを意図するものではなく、特定の各要素には、同様に動作するあらゆる技術的な等価物が含まれることは明らかである。

センサデータからの将来の故障のような問題の証拠を検出するため、コンピュータ学習が使用されるシステム診断のためのアプローチもあるが、別のアプローチでは、一人またはそれ以上の人間のユーザのエキスパート知識が使用される。さらに別のアプローチでは、コンピュータ学習の様相と、エキスパート知識の使用とが組み合わせられる。センサデータを解釈するのにエキスパート知識を使用するアプローチでは、上記の知識は、論理的な表現のようなコンピュータ可読形式にエンコードされ、上記のシステムが正常に動作しているか、システムが誤動作しているか、このシステムのどの部分が誤動作しているか、どのような補修行動が推奨されるか、また故障が発生する前に補修行動を行うためのどのくらいの時間が残っているかなどを、コンピュータ化された診断システムが求めるのを支援するために使用される。

エキスパート知識を利用し、センサデータに基づいて診断を行うための１つのアプローチは、故障依存モデルである。このアプローチは、いくつかのコンポーネントは適切に動作するために別のコンポーネントが適切に動作することを要求する認識に基づくものである。１つの故障は、複数のセンサ異常読み取り値として現れることがあるため、上記の故障依存モデルは、どのタイプの誤動作が別のセンサ異常読み取り値を発生させる傾向があるかという事前の知識に基づき、これらの異常読み取り値の原因となっている根本原因をピンポイントで突き止めようと試みる。

この診断アプローチを説明し易くするため、ＷＴＰ（Water Tank Problem）を考察する。図１、このＷＴＰを説明する概略図である。この図には左側のタンク１０および右側のタンク１１の２つのタンクがある。１つの蛇口１２は各タンクの間で自由に動かすことができるため、両方のタンクに水を充填することができる。各タンクには水を漏らす孔が底部にある。左側のタンク１０はｖ１の速度で水を漏らすのに対し、右側のタンク１１は、ｖ２の速度で水を漏らす。蛇口１２はどちらのタンクも速度ｗで充填する。簡単にするため、ｖ１＝ｖ２＝ｖかつｗ＞ｖと仮定する。蛇口を移動してタンクを切り換えるため、「スイッチ」と称されるコマンドを使用することができる。

センサｘ１は、左側タンク１０の状態を監視するブールの（Boolean）センサであるのに対し、センサｘ２は、右側タンク１１の状態を監視するブールのセンサである。センサｘ１およびｘ２は、上記のタンクにおける水準が上がる場合に１を記録し、水準が下がる場合に０を記録する。

ここで時間１においてｘ１の値が１であり、ｘ２の値が０であるとする。このことが示しているのは、蛇口１２が左側のタンク１０を充填していることである。上記のスイッチコマンドが時間１と時間２との間に発生され、かつ、時間２にｘ１およびｘ２の値がそれぞれ１および０のままであると仮定すると、ｘ１およびｘ２の値はこの段階で異常であると考えられる。なぜならば、このシステムでは上記のスイッチの後、ｘ１が０でｘ２が１であることが予想されるからである。このシナリオにおいて蛇口１２は、左側のタンク１０上に固着して動かなくなっている。しかしながら蛇口１２用のセンサは設けられていないため、この問題は直接観察することはできず、診断が必要なのである。

ｘ１およびｘ２の状態を一緒に検査するために非単調論理を使用することができる。ｘ２が減少し増大していないという事実は、例えば漏れによって左側のタンク１１が故障していることを示し得る。しかしながらｘ１が増大し減少していないという事実と組み合わせると、誤動作しているのは蛇口１２であると判定することができる。非単調論理の一例は、解集合プログラミング（ＡＳＰ：Answer Set Programming）形式化である。本発明の実施形態では、特定の問題が直接には観察できないセンサ異常の原因を導き出すための種々異なる監視および診断システムにＡＳＰを適用することが試みられている。さらにＡＳＰは、別の複数の推論アプローチを統合するための統一言語として使用することができる。

本発明の実施例では、診断を推論するために付加的な２つのアプローチを使用することができる。このようなアプローチの第１のアプローチは、障害依存モデルと称することができる。このアプローチでは、１つの誤動作によって別の複数のセンサが異常読み出しを行い得るという知識を使用して一連のセンサ異常読み取り値を遡り、欠陥の実際の原因に到達する。上述のＷＴＰの例に適用すると、蛇口における故障は左側のタンクの異常状態に結び付くことがあり、この異常状態はｘ１に対する異常読み取り値に結び付き得るというエキスパートの知識から出発するのである。同様に蛇口における故障は右側のタンクの異常状態に結び付くことがあり、この異常状態はｘ２に対する異常な読み取り値に結び付き得る。したがってこの知識は
蛇口→タンク１→ｘ１
蛇口→タンク２→ｘ２
と表すことができる。

この依存モデルは、ｘ１が異常であると観察される場合には、タンク１および／または蛇口が障害を有している可能性があり、また同様にｘ２が異常であると観察される場合には、タンク２および／または蛇口が障害を有している可能性があることを意味すると解釈することができる。つぎの依存マトリクスをこの状況を表すのに使用可能である。すなわち、

である。

ここからわかるように、上記の障害依存モデルを生成するために必要なただ１つのエキスパート知識は、複数のコンポーネント間で障害がどのように伝搬するかということだけである。このような知識は、ＣＡＤ／ＣＡＭのようなシステム設計書から自動的に得ることができる。このシステムの機能的観点のような別の情報は、無視することができる。このような理由により、上記の障害依存モデルは、構築が容易であり、診断目的に使用できるが、このアプローチは、別の推論アプローチに比べて比較的分解能が低くなってしまう可能性がある。このため、所定の個数のセンサに対し、上記の障害依存モデルは、別のアプローチほど問題の原因に迫ってピンポイントで指摘できない可能性がある。

本発明の実施例ではまた、診断推論のために別のアプローチを使用することも可能である。この別のアプローチは、論理モデルアプローチと称することができる。ここでは、システムコンポーネント間の複合的な機能的相互依存性が論理式として表すことができる。このアプローチには付加的なエキスパート知識が必要になり得るが、これによってより高い診断分解能が達成可能であり、このことは、所定の個数のセンサに対し、問題の原因に一層迫ってピンポイントで指摘できることを意味し得る。

この論理モデルアプローチを上記のＷＴＰの例に適用することができる。しかしながら、関係するコンセプトを一層容易に説明するため、上記の蛇口の切り換えを起動するコマンド「スイッチ」を使用する代わりに、コマンド「充填１」は左側タンクを充填することを意味するために値１を採ることができ、これに対して右側タンクを充填することを意味するために値０を採り得る。またこの記法のアプローチにおいて、センサ異常読み取り値は、"ab(センサ名)"で表される。付加的に各コマンドは、システム状態を表す状態変数に関連付けられている。例えば、コマンド充填１に対し、蛇口がタンク１を充填中の場合には状態「充填中１」が真になり、その他の場合にはこの状態「充填中１」が偽になる。これにより、上記のＷＴＰ例のエキスパート知識は、以下の２つのルールで捉えることができ、ここでもＡＳＰのモデル言語を使用することができる。すなわち、
inStatus(充填中１)←value(充填１，１)，not ab(蛇口) （１）
not inStatus(充填中１)←value(充填１，０)，not ab(蛇口) （２）
である。

これらのＡＳＰルールに対し、ルールの右辺は論理積として解釈され、左辺が成り立つためには、右辺のすべての条件も成り立たなければならないことを意味する。ルール（１）は、コマンド充填１の値が１（左側タンクを充填する）であり、かつ、蛇口が障害状態にない場合、システムは左側タンクが充填されている状態にあるはずであることを意味する。ルール（２）は同様に、コマンド充填１が０（左側タンクを充填しない）であり、かつ、蛇口が障害状態ない場合にこのシステムは、左側タンクが充填されていない状態にあることを意味する。

論理式はまた、センサ読み取り値と状態変数との間の関係を指定するためにも使用可能であり、例えば、
value(ｘ１，０)←not inStatus(充填１)，not ab(タンク１) （３）
value(ｘ２，１)←not inStatus(充填１)，not ab(タンク２) （４）
である。

ここでルール（３）は、システムが、タンク１（左側タンク）を充填する状態になく、かつ、タンク１に障害がない場合、ｘ１の増大が検出されるはずがないことを意味する。ルール（４）は同様に、システムがタンク１（左側タンク）を充填する状態になく、かつ、タンク２に障害がない場合、ｘ２の減少が検出されるはずであることを意味する。

ｘ１およびｘ２の両方に障害が検出される場合、センサ読み取り値は、
value(充填１，０)，value(ｘ１，１)，value(ｘ２，０) （５）
である。

センサによって読み取ったこのvalue(充填中１，０)およびルール（２）により、ab(蛇口)またはnot inStatus(充填中１)を結論付けることができる。not inStatus(充填中１)およびルール（３）からは、ab(タンク１)またはvalue(ｘ１，０)のいずれかが真であると推論することができる。value(ｘ１，０)は、上記のセンサ読み取り値とは矛盾するため、ab(タンク１)を結論付けることができる。このことから、２つの最小限の説明が得られる。すなわち｛ab(蛇口)｝および｛ab(タンク１)，ab(タンク２)｝である。すなわち、蛇口が誤動作しているかまたは２つのタンクが誤動作しているかのいずれかである。考察対象を上記の最小限の説明に限定することができる。なぜならば｛ab(蛇口)｝が上記の観察を説明できるのであれば、大きい方の集合｛ab(蛇口)，ab(タンク１)｝もこれを説明できるからである。これらの２つの最小限の説明からは、ab(蛇口)を裏付ける２つの徴候(ｘ１，ｘ２)を見つけることができるのに対し、ab(タンク１)を裏付けるただ１つの徴候(ｘ１)およびab(タンク２)を裏付けるただ１つの徴候しか見つからない。ここでの上記の優先の設定により、上記の診断として第１の最小限の説明｛ab(蛇口)｝が選択され得る。なぜならばそれぞれの異常を裏付けるより多くの徴候があるからである。

上で説明した例からわかるのは、一層複雑になるが論理モデルアプローチにより、考えられる故障の原因についての一層詳細な説明が得られることである。上記の依存モデルアプローチはより単純ではあるが、考えられる故障の原因について得られる詳細は少ないのである。

本発明の実施例では、ＡＳＰのモデリング言語を使用して、上記の論理モデルアプローチと依存モデルアプローチとが結合され、これにより、必要な場合には単純である共に、利用できる場合には高い分解能が得られるハイブリッド方式モデルアプローチが得られる。このハイブリッド方式アプローチから、考えられ得る複数の解が得られる場合には、実施例により、最小解が優先される。例えば、観察されるセンサ読み取り値を考慮することの可能な最も単純な説明が優先されるのである。さらに、単純な最小解が複数ある場合、裏付ける証拠が最も多い解が優先される。例えば、裏付けるセンサ観察値が最も多い最小解が優先されるのである。

上記のＡＳＰ（Answer Set Programming）の非単調論理形式は、計算フレームワークとして使用することができる。それはこの形式が非単調論理を利用しており、また動的な領域が扱われるような十分な機能を備えているためである。このアプローチは、上記のようなセンサデータを使用する既存の監視および診断システムに組み込むことができる。

ここでは、単純化された潤滑油システムについて、本発明の実施例を説明する。しかしながらこの単純化された潤滑油システムは、本発明の実施例を適用することが可能な例示的なシステムとして提供されているのであり、本発明の上記の実施例は、監視が行われる任意のシステムに適用できることは明らかである。

量的な診断アプローチのベースである、意図した挙動を表すすべての状態空間方程式および推移を有する、複合システムの完全なモデルを得るのが困難であるかまたは不可能になり得るケースもある。これに相応して、本発明の実施例は、この複合システムの完全なモデルが利用できないかまたは他に供給されていない場合、依存モデルだけを頼りにすることが可能である。

図２は、本発明の実施例を適用可能な単純化された油潤滑システムを示す図である。ここでは３つのポンプ"ACPMP1"２０１，"ACPMP2"２０２および"DCPMP"２０３が、潤滑油リザーバ２００に接続されている。２つのＡＣポンプ２０１および２０２は、冗長／バッグアップシステムを構成することができ、ＤＣポンプ２０３は別の管路上で動作し得る。ＡＣ管路では冷却器２０４と、フィルタ２０５と、圧力制御バルブ２０６とが順に接続されている。ここには４つのコマンドセンサ、すなわちpump1Dmd２０７と、pump2Dmd２０８と、dcPmpDmd２０９と、controlValve２１０とが設けられている。また４つの指示センサが設けられている。これらの指示センサには、リザーバ２００における圧力を示すpsvac２１１と、上記の２つの管路に油が流れているか否かを示すｄｐｓｗ２１２およびｐｓ２１３と、終端部における油圧を示すLOPS２１４とが含まれている。

この図から依存モデルを作成することができる。依存モデルは単に、システムを通して異常が伝搬するパスに関係する情報だけを必要とするため、ここに示した図から得られるエキスパート知識以外の付加的なエキスパート知識は、この依存モデルを構成するのに不要である。図３は、本発明の実施例にしたがい、図２のシステムに基づく依存モデルを表す一連のステートメントである。図３に示した依存モデルは、図２の図から直接得ることができる。

図３の依存モデルには、図２に示したシステムにおけるオブジェクト毎の依存性のチェーンが示されている。例えば、第１の行（３１）からわかるように、ｌｏｐｓ（２１４）において検出されるセンサ異常読み取り値は、ｌｏｐｓ（２１４）における問題、制御バルブ（２０６）における問題、フィルタ（２０５）における問題、冷却器（２０４）における問題、acpmp1（２０１）における問題、またはｒｅｓ（２００）における問題によって生じ得る。第２の行（３２）からわかるように、ｌｏｐｓ（２１４）において検出されるセンサ異常読み取り値は、ｌｏｐｓ（２１４）における問題、制御バルブ（２０６）における問題、フィルタ（２０５）における問題、冷却器（２０４）における問題、acpmp2（２０２）における問題、またはｒｅｓ（２００）における問題によって生じ得る。第３の行（３３）からわかるように、ｄｐｓｗ（２１２）において検出されるセンサ異常読み取り値は、ｄｐｓｗ（２１２）における問題、制御バルブ（２０６）における問題、フィルタ（２０５）における問題、冷却器（２０４）における問題、acpmp1（２０１）における問題、またはｒｅｓ（２００）における問題によって生じ得る。第４の行（３４）からわかるように、ｄｐｓｗ（２１２）において検出されるセンサ異常読み取り値は、ｄｐｓｗ（２１２）における問題、制御バルブ（２０６）における問題、フィルタ（２０５）における問題、冷却器（２０４）における問題、acpmp2（２０２）における問題、またはｒｅｓ（２００）における問題によって生じ得る。第５の行（３５）からわかるように、ｌｏｐｓ（２１４）において検出されるセンサ異常読み取り値は、ｌｏｐｓ（２１４）における問題、dcpmp（２０３）における問題、またはｒｅｓ（２００）における問題によって生じ得る。第６の行（３６）からわかるように、ｐｓ（２１３）において検出されるセンサ異常読み取り値は、ｐｓ（２１３）における問題、dcpmp（２０３）における問題またはｒｅｓ（２００）における問題によって生じ得る。第７の行（３７）からわかるように、psvac（２１１）において検出されるセンサ異常読み取り値は、psvac（２１１）における問題またはｒｅｓ（２００）における問題によって生じ得る。

センサ異常読み取り値および考えられ得る原因のこの階層関係は、以下に示す依存マトリクスに要約されている。この依存マトリクスにおいて列は、センサ異常読み取り値を表しており、行は、考えられ得る原因を表している。値「１」は、列におけるセンサ異常読み取り値が、行に示した故障または誤動作によって発生し得ることを示しているのに対し、値「０」は、列におけるセンサ異常読み取り値が、行に示した故障または誤動作によって発生し得ないことを示している。

したがってこの依存マトリクスからわかるのは、単純化された潤滑油システムの例が、既存の指示センサを使用しても完全には診断できないことである。例えば、ｌｏｐｓおよびｄｐｓｗの両方が障害を有していることが検出される場合、依存情報だけに基づいてどのコンポーネントが障害を有しているかを区別できないことになり得る。このような場合、任意１つまたは複数のコンポーネントが障害を有している可能性がある。

しかしながら、以下に示すように、上記の論理モデルアプローチを使用して解析した場合には、上記と同じ一連のセンサデータによって一層事実を見極めることのできる答えが得られる。このアプローチによれば、図２に示した潤滑油システムから、各センサがシステム状態変数を定めることを識別することができるのである。例えば、acPmp1が障害状態になければ、value(acPmp1Dmd,１)＝pumpRun，value(acPmp1Dmd,０)＝not pumpRunでないことがわかり、すなわち、Pump1Dmdが１の値を供給する場合にはACPMP1が動作しており、Pump1Dmdが０の値を供給する場合にはACPMP1が動作していないことがわかるのである。この情報は、以下のＡＳＰルールを使用してエンコードすることができる。すなわち、
inStatus(pumpRun1)←value(adPmp1Dmd,１)，not ab(acPmp1) （６）
not inStatus(pumpRun1)←value(acPmp1Dmd,０)，not ab(acPmp1) （７）
別の例として、上記の指示センサ、すなわちvalue(ｌｏｐｓ,０)＝lowPress，value(ｌｏｐｓ,１)＝not lowPressである。この情報は以下のＡＳＰルールにエンコードすることができる。すなわち、
value(ｌｏｐｓ,１)←not inStatus(lowPress) （８）
value(ｌｏｐｓ,０)←inStatus(lowPress) （９）
異なる状態変数間の関係は、以下の制約を使用してエンコード可能である。すなわち、
← not inStatus(lowPress)，inStatus(流れ１)，
not inStatus(流れ２)，not ab(制御バルブ) （１０）
である。

ここで、ＡＳＰルールの左辺が空白のままになっているのは、このルールの右辺が成り立たないことを示している。この制約が意味しているのは、管路１に流れがあり、管路２に流れがあり、制御値に障害がない場合には、終端部の圧力が低ではあり得ないことである。

ｌｏｐｓおよびｄｐｓｗに障害があることが検出されるシナリオを考察する。センサ読み取り値は、value(acPmp1Dmd,１)，value(acPmp2Dmd,０)，value(dcPmpDmd,０)，value(ｄｐｓｗ,０)，value(ｐｓ,１)，value(ｌｏｐｓ,０)になる。

上記の表現（６）〜（９）から結論付けられるのはinStatus(流れ１)，not inStatus(流れ２)およびnot inStatus(lowPress)である。この結果、ルール（１０）からは、ab(制御バルブ)が真であると推測することができる。

上記の例からは、２つのモデルの各モデルをどのように潤滑油システムの例に適用できるかがわかる。上記の依存モデルアプローチは、作成するのが容易であり、推論は簡単であるが、比較的低い分解能しか得られない。このことが意味し得るのは、所定の個数のセンサに対し、論理モデルアプローチを使用する場合のようには誤動作を絞り込めないことである。論理モデルアプローチにより、一層高い分解能を得ることができる。このことが意味するのは、所定の個数のセンサに対し、発生し得る問題の一層小さい部分集合に誤動作を絞り込めることである。しかしながらこの論理モデルアプローチではこれを構築するために付加的なユーザ入力が必要になり得る。例えば、上記のシステムを理解するための、論理ステートメントの完全な集合を構築するために一層多くのエキスパートデータが必要になり得る。

本発明の実施例では、上記の依存モデルアプローチと、論理モデルアプローチとを組み合わせようとしている。図４は、本発明の実施例にしたがい、システム診断のためのハイブリッド型アプローチを説明するフローチャートである。まずはじめにユーザ情報が取得される（ステップＳ４１）。このユーザ情報は、監視するシステムについてのエキスパート知識とすることができ、またシステムの正しい動作および問題が観察され得る既知のパスに関係するものとすることが可能である。このユーザ情報は、例えば、ユーザに所望の情報の入力を促すユーザインタフェースを介して供給することができる。このユーザ情報に取得には、ユーザによって供給された入力を、曖昧性がなくかつ都合のよい形式にフォーマットすることも含まれ得る。

つぎに、取得した上記のユーザ供給情報が、論理モデルを構築するのに十分であるか否かが決定される（ステップＳ４２）。この決定は、ユーザに質問することによって手動で行うか、または情報が十分である否かを分析することによって自動的に行うことができる。本発明の一実施例によれば、論理モデルはいずれのイベントにおいても構築することができ、構築される論理モデルが十分であるか否かは、この論理モデルが意味のある結果を提供し得るか否かによって決定することができる。択一的には、この論理モデルが十分であるか否かは、シミュレーションを行うことによって評価できるか、または論理ステートメントの集合の相互依存性を検証し、発生し得るセンサ値のいくつの異なる組み合わせがこのモデルによって説明できることを確かめることによって評価することができる。

上記の取得したユーザ提供情報が論理モデルを構築するのに十分な場合（Ｙｅｓ，ステップＳ４２）、上記の利用可能な情報から論理モデルを生成することができる（ステップＳ４３）。上記の取得したユーザ提供情報が論理モデルを構築するのに十分でない場合（Ｎｏ，ステップＳ４２）、上記の利用可能な情報から依存モデルを生成することができる（ステップＳ４４ａ）。付加的には上記の論理モデルが構築された場合に、さらに上記の依存モデルも構築することが可能である（ステップＳ４４ｂ）。その後の任意の時点においてこのシステムについての付加情報をユーザから得ることができるか、そうでなければシステムの動作を監視することによって学習され、付加情報が得られた場合には、上記の論理モデルを拡張するか、または十分な情報が欠落していたために前には生成されていなかった場合でも論理婦モデルを生成することができる。

上記の依存情報はつぎに、ＡＳＰ（Answer Set Programming）フレームを使用してエンコードすることができる（ステップ４５ａ／ｂ）。例えばシステムコンポーネント間の依存性に対して、以下を使用することができる。すなわちconnectTo(dcPmpDmd,ｒｅｓ)を使用することができる。コンポーネントとインジケータとの間の依存関係に対しては、以下を使用することができる。すなわち、associate(dcPump,ｐｓ)を使用することができる。

接続の推移閉包は、以下のＡＳＰルールを使用することによって計算することができる。すなわち、
tcConnectTo(Ｃ,Ｃ１)←connectTo(Ｃ,Ｃ１)
（１１）
tcConnectTo(Ｃ,Ｃ２)←tcConnectTo(Ｃ,Ｃ１)，tcConnectTo(Ｃ１,Ｃ２)
（１２）
である。

それぞれのコンポーネントＣに対し、インジケータＩがＣに関係付けられており、かつ、別のコンポーネントＣ１がＣの推移閉包内にある場合、ＩもつぎのようにＣ１に関係付けられる。すなわち
associate(Ｃ１,Ｉ)←associate(Ｃ,Ｉ)，tcConnectTo(Ｃ,Ｃ１)
（１３）
である。

上記の依存モデルが一旦ＡＳＰルールでエンコードされれば、上記の２つのモデルを結合させてＡＳＰソルバで実行することができる（ステップＳ４６）。論理モデルが構成されていない場合も上記の依存モデルをなお上記のＡＳＰソルバで実行することができる（ステップＳ４７）。

ＡＳＰソルバの計算は、センサ異常読み取り値の原因を求めるかそうでなければ発生し得る問題を診断するために殊に効率な方法になり得る。

上記のモデルルールのＡＳＰエンコーディング、手動または自動的に記述することができる。例えば、ＡＳＰの知識はエンドユーザからは見えないようにすることができ、またＡＳＰエンコーディングは、ユーザに馴染みのある形式で入力した知識を使用して自動生成することができる。以下のような情報をエンドユーザに指定させるためビジュアルモデルリングツールを使用することができる。すなわち、コンポーネント、コマンド、インジケータおよび状態変数、ならびに、コマンドおよびインジケータとコンポーネントとの関係、ならびに、コンポーネント間の依存関係、ならびに、センサ読み取り値を使用する状態変数の定義、ならびに制約、および／または、エキスパートルールのような情報を指定させるためビジュアルモデルリングツールを使用することができる。

上記の論理モデルが生成されると、上記のモデルを使用して、システム内に実現されている複数のセンサのネットワークから得られるセンサデータを分析することができ、これによってメンテナンスおよび／または修理作業をいつ行うべきかが決定されるかまたはそうでなければシステムの状態に関する診断が行われる（ステップＳ４８）。

本発明の実施例によれば、上記の論理モデルと依存モデルとが結合される場合（ステップＳ４６）、依存モデルの結果は、論理モデルの結果をよりよくするために使用することができる。したがって依存モデルを使用して実行した前の診断の取り組みを、論理モデルアプローチに繰り越すことができるのである。

上記の（複数の）モデルにより、センサ異常値に対して考えられ得る複数の原因を含み得る診断結果が得られた後、最小解および裏付ける証拠が最も多い解を優先させることができる。これは上述したとおりである（ステップＳ４９）。優先の設定には、優先されておらずかつ発生し得る結果を拒否するか、そうでなければ表示のためにこの優先の設定にしたがって結果の順序を設定することが含まれ得る。

上述したシステムモデルによれば、プログラムにより、依存モデルおよび論理モデルを自動的に生成することができる。診断エンジンとしてＡＳＰソルバを使用することができる。図５Ａは、本発明の実施例にしたがってシステムを診断するための全体アーキテクチャを説明する図である。

上記のシステムから得られるセンサデータ５０１は、例えば日毎のように周期的にまたは連続的に監視システム５０３に供給することができ、これによって任意の異常な挙動が識別される。このデータは、監視の前に妥当性検査５０２を行うことができる。データの妥当性検査は、監視されるデータに意味があることを保証するために実行することができる。

異常なデータが見つかった場合、監視システム５０３は、警告を返し、すべてのセンサ読み取り値および識別した障害のあるセンサを伴って診断システムを起動する。この情報およびシステムモデルを使用して、診断エンジン５０４は、上の段落で説明した推論を使用して、考えられ得る一連の説明を生成し、その結果コンポーネント診断５０５を行うのである。

図５Ｂは、本発明の実施例にしたがう、監視および診断システムのためのアーキテクチャを示す概略図である。このアーキテクチャは、ISO 13374（機械の状態監視および診断）と整合し得る。このアーキテクチャには、データ取得５０６，データ操作５０７，状態検出５０８、正常性評価５０９，予測評価５１０およびアドバイス生成５１１のためのISO 13374レイヤを含み得る。

本発明の実施例では付加的に予測評価を利用することができる。ダイナミシティについての推論は、予測およびプランニングのための基礎になり得る。ダイナミシティは、有効な診断においても所定の役割を果たすことができる。例えば上記のルール（１）および（２）はつぎのような動的ルールに修正することできる。すなわち、
inStatus(充填中１,Ｔ＋１)←¬inStatus(充填中１,Ｔ)，value(スイッチ,１,Ｔ＋１)，not ab(蛇口,Ｔ＋１) （１４）
¬inStatus(充填中１,Ｔ＋１)←inStatus(充填中１,Ｔ)，value(スイッチ,１,Ｔ)，not ab(蛇口,Ｔ＋１) （１５）
である。

インジケータ読み取り値と、状態変数との間の静的な関係も同様に拡張することができる。例えばルール（３）および（４）は、
value(ｘ１,０,Ｔ)←¬inStatus(充填中１,Ｔ)，not ab(タンク１,Ｔ) （１６）
value(ｘ２,１,Ｔ)←¬inStatus(充填中１,Ｔ)，not ab(タンク２,Ｔ) （１７）
によって置き換えられる。

否定¬およびデフォルトの否定はここでは区別していない。なぜならば静的なケースと異なり、一般的な慣性の法則は、明示的に指定しなければならないからである。すなわち、
inStatus(Ｓ,Ｔ＋１)←inStauts(Ｓ,Ｔ)，not ¬inStatus(Ｓ,Ｔ＋１) （１８）
¬inStatus(Ｓ,Ｔ＋１)←¬inStauts(Ｓ,Ｔ)，not inStatus(Ｓ,Ｔ＋１) （１９）
であり、Ｆはすべての状態変数を動く。この法則が示すのは、変化のための原因がなければシステム状態が変化しないことである。

診断推論は、動的なケースでは一層洗練される。ｘ１およびｘ２の両方に障害があることが上記の監視システムによって検出されるシナリオを検討する。上記のセンサ読み取り値は、value(スイッチ,１,０)，value(ｘ１,１,０)，value(ｘ１,１,１)，value(ｘ２,０,０)，value(ｘ２,０,１)である。

タイムスタンプ０を有する値とは、前のステップにおける読み取り値のことであるのに対し、タイプスタンプ１を有する値とは、現在の状態における読み取り値のことである。センサ読み取り値value(ｘ１,１,１)，value(ｘ２,０,１)および対応するinStatus(充填中１,Ｔ)に対するルールからは、｛ab(タンク１,１)，ab(タンク２,１)｝またはinStatus(充填中１，１)のいずれかを結論付けることができる。value(ｘ１,１,０)，value(ｘ２,０,０)および上記と同じルールからは、｛ab(タンク１,０)，ab(タンク２,０)｝またはinStatus(充填中１,０)を結論付けることができる。上記のパワーモニタは、上記の前の状態においていかなるエラーも通知していないため、｛ab(タンク１,０)，ab(タンク２,０)｝は真ではあり得ないと仮定することができる。この結果、inStatus(充填中１,０)となる。inStatus(充填中１,０)，inStatus(充填中１,１)、センサ読み取り値value(スイッチ,１,０)およびルール（１５）から、｛ab(蛇口,１)｝を結論付けることができる。推論の残りは、上で説明したアプローチと同様である。

上記の診断システムは、ダイナミシティについての推論を行うことができ、その結果、予想およびプランニングサービスを提供することができる。これを達成するため、本発明の実施例により、動作および変更について推論する能力を有するように診断フレームワークを拡張することができる。例えば、上で論じたＷＴＰに戻ると、現在の状態においてコマンドvalue(スイッチ,１)が与えられると何が起こるかと問われる場合、このシステムは、蛇口がまだ固着して動かないため、value(ｘ１,１,２)，value(ｘ２,０,２)を予測することができることになる。蛇口を固定することについての知識がエンコードされ、このシステムがそれ自体を通常状態に戻るように求められる場合、修復プランが生成される。

本発明の実施例では、付加的により高水準のアクション言語を利用して、ダイナミシティについての知識をユーザがエンコードし易いようにすることが可能である。例えば、ルール（１４）を記述する代わりに、ユーザは一層自然言語的なアプローチを使用してエンコードすることができる。ルール（１４）はそこから自動的に生成される。
¬inStatus(充填中１)の場合、value(スイッチ,１)はinStatus(充填中１)を生じさせる （２０）
となる。

また本発明の実施例では、診断の正確さを増すためにオントロジ知識でシステムを強化することができる。例えば、潤滑油システムの例を考察する。コンポーネントの異常の点から障害を一律に記述するのではなく、本発明の実施例では、センサ異常読み取り値が一般的な故障または機能の故障を表し得るというオントロジを利用して、障害のタイプと、それら関係とを指定することができる。

一般的な障害は、コンポーネントの全体的な故障に相応し得るのに対し、機能的な障害は、その機能だけに影響し得る。上記のオントロジを援用すれば、ユーザは、終端部における低圧が制御バルブの機能に関連することを指定することができる。すなわち、
←not inStatus(低圧)，inStatus(流れ１)，not inStatus(流れ２)，not functionalFault(制御バルブ) （２１）
である。

故障が発生した場合に一般的な障害および機能的な障害の両方が上記の観察を説明できるのであれば、一般的な障害ではなく機能的な障害が発生したと仮定することができる。この結果、本発明の実施例では、最小の診断を計算する場合、より高い優先度が機能の障害に与えられる。このことは以下のＡＳＰルールで記述することができる。すなわち、
#minimize{functionalFault(Ｃ):components(Ｃ)＠1} （２２）
#minimize{generalFault(Ｃ):components(Ｃ)＠2} （２３）
である。

上記のオントロジおよび上記のルールを用いれば、上で考察しているシナリオにおいて、このシステムは、{functionalFault(制御バルブ)}を結論付けることができる。

本発明の実施例では、オントロジへの問い合わせインタフェースを加えることによって診断システムを拡張することができる。このようなインタフェースは、ユーザがより良好にその知識をエンコードし、これをシステムの診断の強化に使用できるようにする。

上述のように本発明の実施例では、最小解を優先させるために、最小診断を計算する。本発明の実施例では、メタプログラミング技術を使用することができ、これにより、最小診断の部分集合の計算が、別のプログラムの応答の集合の計算に還元される。択一的には、本発明の実施例ではこのアプローチを拡張して、これが上記の安定モデル意味論の元で任意のプログラムをカバーするようすることが可能である。

最小診断を説明するための１つの方法は、サーカムスクリプションを参照することである。このアプローチは、上記の診断領域に拡張することができる。

自動モニタリングおよび診断システムに対して上で説明したアプローチは、資産管理に必要な時間および努力を低減し、メンテナンスサイクルを採算がとれるように最適化するために使用することができる。診断作業、推論の複雑さに起因して、例えば、非単調論理技術を使用することができる。本発明の実施例では、ＡＳＰの非単調論理形式化を産業システムの診断に使用している。この場合にＡＳＰゾルバは、特定の分野において最小診断問題を解くために使用可能である。

図６には、本発明の方法およびシステムを実現することの可能なコンピュータシステムの例が示されている。本発明のこのシステムおよび方法は、例えばメインフレーム、パーソナルコンピュータ（ＰＣ）、ハンドヘルドコンピュータ、サーバなどのコンピュータシステム上で動作するソフトウェアアプリケーションの形態で実現可能である。このソフトウェアアプリケーションは、上記のコンピュータシステムによってローカルにアクセス可能な記録媒体に記憶可能であり、またこのソフトウェアアプリケーションには、例えばローカルエリアネットワークまたはインターネットのようなネットワークへの有線または無線のコネクションを介してアクセス可能である。

一般的にシステム１０００と称される上記のコンピュータシステムには、例えば、中央演算処理ユニット（ＣＰＵ）１００１と、ランダムアクセスメモリ（ＲＡＭ）１００４と、プリンタインタフェース１０１０と、ディスプレイユニット１０１１と、ローカルエリアネットワーク（ＬＡＮ）データ伝送コントローラ１００５と、ＬＡＮインタフェース１００６と、ネットワークコントローラ１００３と、内部バス１００２と、例えばキーボード、マウスなどのような１つまたは複数の入力装置１００９とが含まれ得る。図示のようにシステム１０００はリンク１００７を介して、例えばハードディスクのようなデータ記憶装置１００８に接続することができる。

当業者には明らかなように、本発明の複数の様相はシステム、方法またはコンピュータプログラム製品として実現可能である。したがって本発明の複数の様相は、完全にハードウェアによる実施形態、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）完全にソフトウェアによる実施形態、またはソフトウェア的およびハードウェア的な様相が組み合わされた実施形態を採ることができ、これらはすべて一般的に本発明において「回路」、「モジュール」または「システム」と称することができる。さらに本発明の複数の様相は、コンピュータ可読プログラムコードを実現する１つまたは複数のコンピュータ可読媒体において実現されるコンピュータプログラム製品の形態を採り得る。

１つまたは複数のコンピュータ可読媒体の任意の組み合わせを利用可能である。このコンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体とすることが可能である。コンピュータ可読記憶媒体は、例えば、電子式、磁気式、光学式、電磁式、赤外線式もしくは半導体のシステム、装置もしくはデバイス、またはこれらの任意の適当な組み合わせとすることができるが、これらには限定されない。上記のコンピュータ可読記憶媒体の一層具体的な例（すべてを列挙し尽くしたリストではないが）には以下が含まれ得る。すなわち、１つまたはそれ以上のワイヤを有する電気的な接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、またはこれらの任意の適当な組み合わせが含まれ得る。この明細書においてコンピュータ可読記憶媒体は、命令実行システム、装置またはデバイスによって使用されるかまたはこれに関連するプログラムを含むかまたは記憶する任意の有形の媒体とすることができる。

コンピュータ可読信号媒体には、例えばベースバンドまたは搬送波の一部として、コンピュータ可読プログラムコードが実現されておりかつ伝播されるデータ信号が含まれ得る。このような伝播信号は、任意の多種多様な形態を採ることができる。これには電磁式、光学式、これらの任意の適当な組み合わせが含まれるが、これには限定されない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、かつ、命令実行システム、装置またはデバイスによって使用されるかまたはこれに関連するプログラムを通信、伝播または伝送することができる任意のコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に実現されるプログラムコードは、任意の適当な媒体を使用して伝送することができ、これにはワイヤ線、光ファイバケーブル、ＲＦなどまたはこれらの任意の適当な組み合わせが含まれ得るが、これには限定されない。

本発明の複数の様相に対する演算を実行するためのコンピュータプログラムコードは、Java，Smalltalk，C++またはこれに類似するものなどのようなオブジェクト指向プログラミング言語および「Ｃ」プログラミング言語またはこれに類似するプログラミング言語のような慣用の手続プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述することができる。上記のプログラムコードは、スタンドアロンのソフトウェアパッケージとして完全にユーザのコンピュータ上で実行されるか、一部分がユーザのコンピュータ上で実行されるか、一部分がユーザのコンピュータ上で実行されかつ一部分がリモートコンピュータ上で実行されるか、または、完全にリモートコンピュータもしくはサーバ上で実行することが可能である。後者のシナリオでは、上記のリモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）もしくはワイドエリアネットワーク（ＷＡＮ）を含む複数の任意のタイプのネットワークを介してユーザのコンピュータに接続することができるか、または外部のコンピュータ（例えば、インターネットサービスプロバイダを使用したインターネットを介して）にコネクションを確立することができる。

本発明の複数の様相はここでは、本発明の実施形態に記載した方法、装置（システム）およびコンピュータプログラム製品のフローチャートおよび／またはブロック図に関連して示されている。これらのフローチャートおよび／またはブロック図の各ブロックおよびフローチャートおよび／またはブロック図におけるブロックの組み合わせは、コンピュータプログラム命令によって実現できることは明らかである。これらのコンピュータプログラム命令は、汎用コンピュータ、特定用途向けコンピュータまたは別のプログラム可能データ処理装置に供給されて機械が構成されて、上記のコンピュータのプロセッサまたは別のプログラム可能データ処理装置を介して実行されるこれらの命令により、上記のフローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて示された機能／アクションを実現するための手段が形成されることが可能である。

これらのコンピュータプログラム命令は、コンピュータ可読媒体に格納することも可能であり、このコンピュータ可読媒体は、コンピュータ、別のプログラム可能データ処理装置、または別の装置に命令して特別な機能をするように指示し、これにより、このコンピュータ可読媒体に記憶されている命令が、上記のフローチャートおよび／またはブロック図の１つまたは複数のブロックに示した機能／アクションを実現する命令を含むメーカの製品を構成することも可能である。

上記のコンピュータプログラム命令は、コンピュータ、別のプログラム可能データ処理装置またはデバイスにロードして、一連の演算ステップが、上記のコンピュータ、別のプログラム可能データ処理装置またはデバイスで実行されて、コンピュータに実現されるプロセスが形成され、これにより、上記のコンピュータまたは別のプログラム可能装置上で実行される命令により、上記のフローチャートおよび／またはブロック図の１つまたは複数のブロックに示した機能／アクションが実現するためのプロセスが提供されるようにすることも可能である。

上記の図におけるフローチャートおよびブロック図には、本発明のさまざまな実施形態による複数のシステム、方法およびコンピュータプログラム製品の考えられ得る実現のアーキテクチャ、機能および動作が示されている。この点に関し、上記のフローチャートまたはブロック図における各ブロックは、指定された論理的な機能を実現するための１つまたは複数の実行可能な命令を含むモジュール、セグメントまたはコードの一部分を表し得る。択一的な実施によっては、上記のブロックに示された機能が、図に示したのと異なる順序で出現し得ることにも注意されたい。例えば、連続して示された２つのブロックは、実際には実質的に同時に実行できるか、または必要な機能に依存して複数のブロックが逆の順序で実行されることもあり得る。上記のブロック図および／またはフローチャートの各ブロック、ならびに、ブロック図および／またはフローチャートの複数のブロックの組み合わせは、上記の指定された機能またはアクションを実行する特定用途向けハードウェアベースのシステムにより、または特定用途向けハードウェアおよびコンピュータ命令の組み合わせによって実現できることに注意されたい。

ここで示した複数の実施例は説明のためのものであり、この開示内容の精神または添付の特許請求の範囲から逸脱することなく多くの変更を行うことができる。例えば、この開示内容および添付の特許請求の範囲内で、異なる複数の実施例の要素および／または特徴を互いに組み合わせる、および／または互いに置き換えることが可能である。

Claims (21)

1. システム状態を評価するための方法において、
   該方法は、
   評価中のシステムの動作に関係するユーザ提供情報を受け取るステップと、
   受け取った当該ユーザ提供情報に基づき、評価中の前記システムの依存モデルを構築するステップと、
   受け取った前記ユーザ提供情報が、評価中の前記システムの論理モデルを構築するのに十分であるか否かを判定するステップと、
   前記ユーザ提供情報が十分であると判定された場合、評価中の前記システムの論理モデルを構築して、当該論理モデルと前記依存モデルとを結合するステップと、
   評価中の前記システム内に実装された１つまたは複数のセンサからのセンサデータを監視するステップと、
   前記結合モデルが利用可能である場合には前記センサデータに当該結合モデルを適用し、前記結合モデルが利用可能でない場合には前記センサデータに前記依存モデルを適用するステップと、
   前記結合モデル／依存モデルの前記センサデータへの前記適用から、１つまたは複数の異常システムコンポーネントの集合を求めるステップと、
   求めた前記１つまたは複数の異常システムコンポーネントの集合に基づいてシステム状態を評価するステップとを有しており、
   各前記ステップは、１つまたは複数のコンピュータシステムを使用して実行される、
   ことを特徴とする、システム状態を評価するための方法。
2. 請求項１に記載の方法において、
   評価中のシステムの動作に関係する前記ユーザ提供情報には、前記システムの１つまたは複数のコンポーネントの障害依存性についてのエキスパート知識、または前記システムの前記１つまたは複数のコンポーネントの故障の仕方についてのエキスパート知識が含まれている、
   ことを特徴とする方法。
3. 請求項１に記載の方法において、
   評価中のシステムの動作に関係する前記ユーザ提供情報は、ユーザにより、またはユーザ入力に基づいて自動的に、ＡＳＰ（Answer Set Programming）形式化でエンコードされる、
   ことを特徴とする方法。
4. 請求項１に記載の方法において、
   前記構築された依存モデルまたは前記結合モデルは、ＡＳＰ（Answer Set Programming）形式化で表される、
   ことを特徴とする方法。
5. 請求項１に記載の方法において、
   前記構築された依存モデルは、評価中の前記システムを介して故障がどのように伝播するかのみを記述する、
   ことを特徴とする方法。
6. 請求項１に記載の方法において、
   前記構築された論理モデルは、評価中の前記システムの１つまたは複数のコンポーネント間の複合的な機能的相互関係を記述する、
   ことを特徴とする方法。
7. 請求項１に記載の方法において、
   前記受け取ったユーザ提供情報が、評価中の前記システムの前記論理モデルを構築するために十分であるか否かの判定には、前記論理モデルを構築すること、および、前記構築された論理モデルを前記監視されたセンサデータへ適用することを試みること、および、意味のある結果が得られるか否かを決定することが含まれている、
   ことを特徴とする方法。
8. 請求項１に記載の方法において、
   ＡＳＰ（Answer Set Programming）ソルバを使用して前記論理モデルと前記依存モデルとの前記結合を実行する、
   ことを特徴とする方法。
9. 請求項１に記載の方法において、
   前記センサデータへの前記結合モデルまたは前記依存モデルの適用をＡＳＰ（Answer Set Programming）ソルバによって実行する、
   ことを特徴とする方法。
10. 請求項１に記載の方法において、
    １つまたは複数の異常システムコンポーネントの前記求めた集合に基づくシステム状態の評価には、最小解を優先することが含まれる、
    ことを特徴とする方法。
11. 請求項１に記載の方法において、
    １つまたは複数の異常システムコンポーネントからなる求めた集合に基づいてシステム状態を評価する前記ステップには、最大個数のセンサ観測値によって裏付けられる解を優先することが含まれる、
    ことを特徴とする方法。
12. 請求項１に記載の方法において、
    前記センサデータへの前記結合モデルまたは前記依存モデルの適用には、非単調論理の使用が含まれる、
    ことを特徴とする方法。
13. システム状態を評価するための方法において、
    評価中のシステムの依存モデルと、評価中の前記システムの論理モデルとを受け取るステップと、
    評価中の前記システム内に実装されている１つまたは複数のセンサからのセンサデータを監視するステップと、
    前記論理モデルと前記依存モデルとを結合して、ＡＳＰ（Answer Set Programming）ソルバを使用して当該結合モデルを前記センサデータに適用するステップと、
    前記結合モデルを前記センタデータに適用することにより、１つまたは複数の異常システムコンポーネントの集合を求めるステップと、
    １つまたは複数の異常システムコンポーネントの前記求めた集合に基づいてシステム状態を評価するステップとを有しており、
    １つまたは複数のコンピュータシステムを使用して各前記ステップを実行する、
    ことを特徴とする方法。
14. 請求項１３に記載の方法において、
    １つまたは複数の異常システムコンポーネントの前記求めた集合に基づいてシステム状態を評価する前記ステップには、最小解を優先することが含まれる、
    ことを特徴とする方法。
15. 請求項１３に記載の方法において、
    １つまたは複数の異常システムコンポーネントの前記求めた集合に基づいてシステム状態を評価する前記ステップには、最大個数のセンサ観測値によって裏付けられる解を優先することが含まれる、
    ことを特徴とする方法。
16. コンピュータシステムであって、
    該コンピュータシステムには、
    プロセッサと、
    当該プロセッサによって実行可能な命令からなるプログラムを実現してシステム状態を評価するための方法のステップを実行する、前記コンピュータシステムによって読み出し可能である非一時的な有体のプログラム記憶媒体とが含まれている、コンピュータシステムにおいて、
    前記方法には、
    評価中のシステムの動作に関係するユーザ提供情報を受け取るステップと、
    受け取った当該ユーザ提供情報に基づき、評価中の前記システムの依存モデルを構築するステップと、
    受け取った前記ユーザ提供情報が、評価中の前記システムの論理モデルを構築するのに十分であるか否かを判定するステップと、
    前記ユーザ提供情報が十分であると判定された場合、評価中の前記システムの論理モデルを構築して、当該論理モデルと前記依存モデルとを結合するステップと、
    評価中の前記システム内に実装された１つまたは複数のセンサからのセンサデータを監視するステップと、
    前記結合モデルが利用可能である場合には前記センサデータに当該結合モデルを適用し、前記結合モデルが利用可能でない場合には前記依存モデルを適用するステップと、
    前記結合モデル／依存モデルの前記センサデータへの前記適用から、１つまたは複数の異常システムコンポーネントの集合を求めるステップと、
    １つまたは複数の異常システムコンポーネントの前記求めた集合に基づいてシステム状態を評価するステップとを有している、
    ことを特徴とするコンピュータシステム。
17. 請求項１６に記載のコンピュータシステムにおいて、
    前記構築された依存モデルは、評価中の前記システムを介して故障がどのように伝播するかのみを記述する、
    ことを特徴とするコンピュータシステム。
18. 請求項１６に記載のコンピュータシステムにおいて、
    前記構築された論理モデルは、評価中の前記システムの１つまたは複数のコンポーネント間の複合的な機能的相互関係を記述する、
    ことを特徴とするコンピュータシステム。
19. 請求項１６に記載のコンピュータシステムにおいて、
    前記論理モデルと前記依存モデルとの前記結合は、ＡＳＰ（Answer Set Programming）ソルバを使用して実行される、
    ことを特徴とするコンピュータシステム。
20. 請求項１６に記載のコンピュータシステムにおいて、
    前記センサデータへの前記結合モデルまたは前記依存モデルの適用は、ＡＳＰ（Answer Set Programming）ソルバによって実行される、
    ことを特徴とするコンピュータシステム。
21. 請求項１６に記載のコンピュータシステムにおいて、
    １つまたは複数の異常システムコンポーネントからなる前記求めた集合に基づくシステム状態の前記評価には、最小解を優先するかまたは最大個数のセンサ観測値によって裏付けられる解を優先することが含まれる、
    ことを特徴とするコンピュータシステム。

Images