(57)【特許請求の範囲】
【請求項１】
同一の機能に関わるグループ毎に分類された複数の要素を含む設備について、各要素に設けられたセンサの出力値と、知識ベースに基づいた推論によって診断を行う設備診断システムにおいて、
前記知識ベースは、設備を構成する個々の要素について、その要素が示す症状ごとに区分された診断用ブロックと、因果関係に基づいた前記同一の機能に関わるグループ内に属する各要素間の関連を示す情報を備え、
前記各診断用ブロックは、その要素が示す症状と、前記症状の原因または前記症状の原因となる別の症状と、前記センサの出力値に基づいて原因または前記別の症状を特定する条件と、前記別の症状が発見された場合に「他の要素に移動する」との制御用記述を格納し、
前記症状が発見された要素について対応する診断用ブロックを読み出して、その要素に設けられたセンサの出力値と、その要素に対応する診断用ブロックに格納されている条件に基づいて、症状の原因または前記症状の原因となる別の症状を判定する推論手段と、
前記推論手段により前記症状の原因となる別の症状が発見された場合に、前記「他の要素に移動する」との制御用記述に従い、因果関係に基づく各要素間の関連を示す情報を参照して、前記症状が発見された要素と同一の機能に関わるグループ内の他の要素の診断用ブロックを読み出して、移動先の他の要素に設けられたセンサの出力値と、新たに読み出した診断用ブロックの情報に基づいて、前記推論手段に対して前記別の症状の原因または前記別の症状の原因となるさらに別の症状を判定させる推論制御手段と、
を備えたことを特徴とする設備診断システム。
【請求項２】
前記知識ベースは、前記推論制御手段が、前記別の症状が発見された場合に「他の要素に移動する」との制御用記述に従って他の要素の診断用ブロックを読み出すにあたり、同一の前記グループに含まれる複数の要素の中で、読み出し対象の診断用ブロックが含む要素を限定する情報を含むことを特徴とする請求項１記載の設備診断システム。
【請求項３】
コンピュータを用いて、同一の機能に関わるグループ毎に分類された複数の要素を含む設備について、各要素に設けられたセンサの出力値と、知識ベースに基づいた推論によって診断を行う設備診断方法において、
前記知識ベースは、設備を構成する個々の要素について、その要素が示す症状ごとに区分された診断用ブロックと、因果関係に基づいた前記同一の機能に関わるグループ内に属する各要素間の関連を示す情報を備え、
前記各診断用ブロックは、その要素が示す症状と、前記症状の原因または前記症状の原因となる別の症状と、前記センサの出力値に基づいて原因または前記別の症状を特定する条件と、前記別の症状が発見された場合に「他の要素に移動する」との制御用記述を格納し、
前記コンピュータは、推論手段と推論制御手段とを備え、
前記推論手段が、前記症状が発見された要素について対応する診断用ブロックを読み出して、その要素に設けられたセンサの出力値と、その要素に対応する診断用ブロックに格納されている条件に基づいて、症状の原因または前記症状の原因となる別の症状を判定する推論ステップと、
前記推論ステップにより前記症状の原因となる別の症状が発見された場合に、前記推論制御手段が、前記「他の要素に移動する」との制御用記述に従い、因果関係に基づく各要素間の関連を示す情報を参照して、前記症状が発見された要素と同一の機能に関わるグループ内の他の要素の診断用ブロックを読み出して、移動先の他の要素に設けられたセンサの出力値と、新たに読み出した診断用ブロックの情報に基づいて、前記推論手段に対して前記別の症状の原因または前記別の症状の原因となるさらに別の症状を判定させる推論制御ステップと、
を含むことを特徴とする設備診断方法。
【請求項４】
前記推論制御ステップにおいて、前記別の症状が発見された場合に、前記推論制御手段は、「他の要素に移動する」との制御用記述に従って他の要素の診断用ブロックを読み出すにあたり、同一の前記グループに含まれる複数の要素の中で、前記制御用記述において限定された要素について診断対象のブロックを読み出すことを特徴とする請求項３記載の設備診断方法。
【請求項５】
コンピュータに推論手段と推論制御手段とを実現し、同一の機能に関わるグループ毎に分類された複数の要素を含む設備について、各要素に設けられたセンサの出力値と、知識ベースに基づいた推論によって診断を行う設備診断用ソフトウェアを記録した記録媒体において、
前記知識ベースは、設備を構成する個々の要素について、その要素が示す症状ごとに区分された診断用ブロックと、因果関係に基づいた前記同一の機能に関わるグループ内に属する各要素間の関連を示す情報を備え、
前記各診断用ブロックは、その要素が示す症状と、前記症状の原因または前記症状の原因となる別の症状と、前記センサの出力値に基づいて原因または前記別の症状を特定する条件と、前記別の症状が発見された場合に「他の要素に移動する」との制御用記述を格納し、
前記推論手段は、前記症状が発見された要素について対応する診断用ブロックを読み出して、その要素に設けられたセンサの出力値と、その要素に対応する診断用ブロックに格納されている条件に基づいて、症状の原因または前記症状の原因となる別の症状を判定する推論をし、
前記症状の原因となる別の症状が発見された場合に、前記推論制御手段は、前記「他の要素に移動する」との制御用記述に従い、因果関係に基づく各要素間の関連を示す情報を参照して、前記症状が発見された要素と同一の機能に関わるグループ内の他の要素の診断用ブロックを読み出して、移動先の他の要素に設けられたセンサの出力値と、新たに読み出した診断用ブロックの情報に基づいて、前記推論手段に対して別の症状の原因または前記別の症状の原因となるさらに別の症状を判定させる、
ことを特徴とする設備診断用ソフトウェアを記録した媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ビルや工場などの建物における設備機器及びそれらの組み合わせによって機能する電気・空調・衛生などの設備を集中的に管理する技術の改良に関するもので、特に、コンピュータ資源への負荷が少ない設備診断を実現するものである。
【０００２】
【従来の技術】
近年、コンピュータ技術の発達に伴い、建物の空調等の設備をコンピュータで監視しその異常を診断する技術が普及しつつあり、その代表例は、設備を保守管理する知識をコンピュータで実現するいわゆる設備診断エキスパートシステムである。
【０００３】
この設備診断エキスパートシステムは、図１１に示すように、設備に取り付けられた温度・圧力・電流などの様々な検知器の情報を定期的に中央のシステムすなわち中央監視システム及び診断システムに収集し、その経時変化の様子と予め定められた正常な値の範囲とのずれによって診断システムが起動され、その設備に応じた知識ベースを使った推論により、考え得る原因が探索されるものである。
【０００４】
また、特開平６−１４７５８８のように、複数の異なる設備に対し遠隔で同様の診断を行うシステムも知られている。これは、上記の設備診断エキスパートシステムを複数の空調設備に対し遠隔で適用することで、煩雑な知識ベースの作成や管理を合理的に実施するものである。
【０００５】
上記のような従来技術では、診断は、コンピュータ上の磁気ディスクなどに保存された知識ベースと、それを展開するワーキングメモリと、ＣＰＵなどの制御部によって実行されるソフトウェア（推論エンジンと呼ばれる）によって実現されていた。この場合、推論エンジンは、検知した異常兆候に合致する症状を持つ知識ベースを探し出し、それをワーキングメモリに展開する。その後、知識ベースに記述された情報の中から、症状を発生させうる原因の可能性を他の情報を含めて残らずチェックし、原因として可能性のあるものを抽出する。
【０００６】
実際の現象としては、原因が存在しその結果として症状が発生することから、探索アルゴリズムとしてはこのような因果関係を逆に辿る「後ろ向き推論」が適用され、このような手法は、症状から原因を見つけだすために全ての可能性が探索されることから原因を見落とす可能性が小さく、一般的に広く利用されている。
【０００７】
【発明が解決しようとする課題】
しかしながら、上記のような従来技術では、推論エンジンが大きなワーキングメモリとＣＰＵ負荷を要求するという問題があった。一方、設備の管理では、上記のような診断だけでなく、定常的にデータを収集したりオペレータが操作する内容を入出力装置に伝達するといった監視又は監視制御に関するリアルタイム性が重視される処理も同時に必要である。このため、従来技術では、このような監視制御と、上記のように推論エンジンが要求する大きな負担とを、１台のコンピュータで処理すると、所期のレスポンスが得られないという問題があった。このため、従来では、監視制御と診断のための推論とを、相互に別々のコンピュータで実施して連携させる必要があり、構成が複雑になるという問題があった。
【０００８】
例えば、図１２は、上記のような従来技術における知識ベースの例であり、基本的にはルール形式、すなわち
Ｉｆ  左辺（Ｌｈｓ）＝（評価すべき条件節）
Ｔｈｅｎ  右辺（Ｒｈｓ）  仮説成立（Ｈｙｐｏ）  Ｅｘｅｃｕｔｅ動作
といった形式で記述されていた。
【０００９】
この例では図の▲１▼の区間が１つのルールであり、このような記述区間が１つの知識ベースに複数存在する。従来の後ろ向き推論方式では、これらの記述において順序を意識することなく記述できるため、知識を作成するエンジニア（ナレッジエンジニア）は原因と症状の因果関係をＦＴＡなどで分析し、その結果を所定のシンタックスに従って記述すればよく、それがメリットであった。
【００１０】
但し、この手法では、それら因果関係が系統化されておらず、従って何らかの症状の発生に基づいて原因を探索するためには、関連する全てのルールをワーキングメモリ上にロードし、何度も評価を繰り返す必要があった。このため、上記のように大きなワーキングメモリとＣＰＵの処理時間が必要であった。
【００１１】
このため、設備に対する監視制御と診断を１台ずつのコンピュータで行う必要があり、初期コスト、設置スペース、管理上の負担などの削減が困難であった。また、２台のコンピュータが両方稼動していないと正常とみなされないシステムは、１台のコンピュータの場合よりも信頼性が低下するという問題もあった。
【００１２】
本発明は、上記のような従来技術の問題点を解決するために提案されたもので、その目的は、コンピュータ資源への負荷が少ない設備診断の技術すなわち設備診断システム及び方法並びに設備診断用ソフトウェアを記録した記録媒体を提供することである。
【００１３】
【課題を解決するための手段】
上記の目的を達成するため、本発明の診断システムは、次の特徴を有する。
(1) 同一の機能に関わるグループ毎に分類された複数の要素を含む設備について、各要素に設けられたセンサの出力値と、知識ベースに基づいた推論によって診断を行う。
(2) 前記知識ベースは、設備を構成する個々の要素について、その要素が示す症状ごとに区分された診断用ブロックと、因果関係に基づいた前記同一の機能に関わるグループ内に属する各要素間の関連を示す情報を備える。
(3) 前記各診断用ブロックは、その要素が示す症状と、前記症状の原因または前記症状の原因となる別の症状と、前記センサの出力値に基づいて原因または前記別の症状を特定する条件と、前記別の症状が発見された場合に「他の要素に移動する」との制御用記述を格納する。
(4) 推論手段は、前記症状が発見された要素について対応する診断用ブロックを読み出して、その要素に設けられたセンサの出力値と、その要素に対応する診断用ブロックに格納されている条件に基づいて、症状の原因または前記症状の原因となる別の症状を判定する。
(5) 推論制御手段は、前記推論手段により前記症状の原因となる別の症状が発見された場合に、前記「他の要素に移動する」との制御用記述に従い、因果関係に基づく各要素間の関連を示す情報を参照して、前記症状が発見された要素と同一の機能に関わるグループ内の他の要素の診断用ブロックを読み出して、移動先の他の要素に設けられたセンサの出力値と、新たに読み出した診断用ブロックの情報に基づいて、前記推論手段に対して前記別の症状の原因または前記別の症状の原因となるさらに別の症状を判定させる。
また、前記のようなシステムを実現する設備診断方法、設備診断用ソフトウェアを記録した媒体も本発明の一態様である。
【００１４】
このような構成を有する本発明は、機器及び機器間の経路といった各要素について、生じうる症状ごとの診断用知識をブロックに分け、一方、要素間の関連は物質、熱、エネルギーの伝搬経路といった因果関係通りに定義しておく。そして、要素について検出された症状については、該当するブロックのみをメモリにロードして診断し、その原因となる症状が判明しそれが根本原因でない場合は、因果関係を逆に辿り、因果関係の上流側に関連付けられた他の要素に推論対象を移動し、対応するブロックに基づいて同様の処理を繰り返すことにより根本原因に辿り着くことができる。このようにブロックごとに処理することで、必要なワーキングメモリとＣＰＵ負荷が少なくなり、ブロックを構成するルールの条件部を一度だけ評価することにより処理速度が高速化される。このため単一のコンピュータ上で監視と診断を同時並行で処理してもリアルタイム性能等の所期のレスポンスが得られ、単純な構成で低コストでシステムを構築できる。また、ブロックに区分することで知識ベースの構造が単純明快となり、内容理解や編集も容易になる。また、例えばブロックで原因となる症状ごとに推論の伝搬先を定義することで複雑な推論制御機構が不要となる。
【００１８】
【発明の実施の形態】
次に、本発明の実施の形態（以下「実施形態」と呼ぶ）について図面を参照して具体的に説明する。なお、本実施形態は、典型的にはコンピュータをソフトウェアで制御することで実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するもので、また、従来技術との共通部分には従来技術も適用される。
【００１９】
但し、この場合のハードウェアやソフトウェアの種類や構成、ソフトウェアで処理する範囲などは各種変更可能であり、例えばこのようなソフトウェアを記録したハードディスクドライブ・ディスクパック・ＣＤ−ＲＯＭなどの記録媒体は単独でも本発明の一態様である。このため、以下の説明では、本発明及び実施形態の各機能を実現する仮想的回路ブロックを用いる。
【００２０】
〔１．構成〕
まず、本実施形態は、１台のコンピュータで高いリアルタイム性を要求される設備の監視制御などの処理と同時に、異常の発生原因診断のための推論処理を実行できるように、小さなＣＰＵ負荷とワーキングメモリによる診断を可能としたものである。
【００２１】
このために本実施形態は、従来技術に対して、推論エンジンと知識ベースの役割分担を見直し、建築物に付帯する電気・機械といった設備の異常症状とそれを発生させる原因の因果関係から推論の流れを規定し、小さなブロックに区切った知識ベースと、各ブロックをただ１回１方向に探索チェックする推論部と、その結果である原因の候補（仮説と呼ぶ）を保存するワーキングメモリを有し、そのブロックを並列または直列に逐次実行する推論制御部を備えたことを特徴とする。
【００２２】
〔１−１．全体的構成〕
具体的には、本実施形態は、複数の要素を含む設備について、監視及び制御、並びに知識ベースに基づいた推論による診断を行う設備診断システム（以下「本システム」とも呼ぶ）及び本システム上で実行される設備診断方法を示すもので、設備診断用ソフトウェアを記録した記録媒体として把握することもできる。
【００２３】
すなわち、図１の機能ブロック図に示すように、本システム１は、電気設備Ｆ１、空調設備Ｆ２、衛生設備Ｆ３（以下これらを設備Ｆと呼ぶ）に対して監視制御及び診断を行うものであり、ここで「監視制御」は、設備Ｆから計測値などのデータを収集したり、オペレータが操作する内容を設備Ｆに伝達したり、データから異常な症状を検出するなどの主にリアルタイム性の高い処理である。診断システム１と、設備Ｆとの間のデータのやり取りは入出力装置Ｃ（Ｃ１，Ｃ２，Ｃ３）によって制御される。また、「診断」は、異常な症状が検出されたときにその原因を判断する処理である。
【００２４】
また、本システム１は、これらの処理を行う中央処理ユニット２と、知識ベース３を格納する磁気ディスク４と、オペレータとの間で情報入出力を行うためのキーボード５及び表示装置６と、を備えている。このうち中央処理装置２は、ワーキングメモリ７と、ＣＰＵなどからなる制御部８の働きにより、前記監視制御を行うための監視制御部９と、前記診断を行うための推論処理部１０及び推論制御部１１と、データ収集チェック部１２と、診断前処理部１３と、診断表示部１４と、の役割を果たすように構成されている。
【００２５】
ここで、知識ベース３は、設備Ｆを構成する機器や配管といった要素に生じうる症状ごとに、その原因又は原因となる症状について診断するためのブロックＢＬを複数含み、ブロックＢＬの各部分間には、因果関係に基づいた要素間の関連が設定されている。また、推論処理部１０は、症状に対応する前記各ブロックＢＬごとに推論処理を行なう推論手段であり、推論制御部１１は、要素間の前記関連に基づいて、各ブロックＢＬごとの処理を並列または直列に推論処理部１０に逐次実行させる推論制御手段である。これら推論処理部１０及び推論制御部１１を合わせて診断サブシステムと呼び、図１において破線で示す。
【００２６】
また、データ収集チェック部１２は、設備Ｆの状態に関するセンサ出力値などのデータを収集し異常の有無をチェックする部分である。また、診断前処理部１３は、前記チェックの結果に基づいて、診断の前処理例えば異常な症状の種類や個所の判断などを行う部分である。また、診断表示部１４は、診断の結果を表示装置６に所定の形式で表示する部分である。
【００２７】
〔１−２．推論手法及び知識ベースの構成〕
続いて、本実施形態における推論手法及びこれに用いる知識ベース３の構成を説明する。概略的には、本実施形態では知識ベース３において、機器及び機器間の経路といった各要素について、生じうる症状ごとの診断用知識をブロックに分けておき、一方、要素間の関連は物質、熱、エネルギーの伝搬経路といった因果関係通りに定義しておく。
【００２８】
すなわち、従来技術における知識ベースの例を図１２に示したが、特に建築設備の分野においてはその構造も含めて異常状態、症状及びその原因の発生と伝搬経路について更に検討を加えると、もっと簡便な記述が可能であることがわかる。
【００２９】
すなわち、建築物に付帯する設備と設備を構成する機器などの要素（設備機器とも呼ぶ）は、本来、その建築物に要求される何らかの機能（要求機能と呼ぶ）を提供するために存在する。この要求機能とは、例えば、照明点灯により室内を所定の照度に維持する、適切な温度と湿度に調整された空調空気の供給により室の温湿度を維持する、上水道の圧力を維持することにより水栓をひねると適量の水が出るなど様々である。
【００３０】
そこで、その要求機能から設備機器を見ると、各設備機器は機能を提供する大きなシステムを構成する部品であると認識できる。またこれらの部品間は、電気などの電線、空気搬送などのダクト、水・油・ガスなどの配管などによって接続されている。すなわち単一の機能を持つ複数の部品と、それらの間を接続する経路によって、設備に対して要求される機能の１つを提供すると考えることができる。ここでそれらを「機能グループ」又は単にグループと呼ぶこととする。この場合、１つの建築物はそれら複数の同種または異種の機能グループの集合で構成されると考えることができる。
【００３１】
たとえば、図２は、一般的な空調設備の機器配列とエネルギーの流れ（図中「冷却水→大気」のように表す）を簡単に表したものである。この図では、機器として冷却塔、ポンプ、冷凍機、空調機などがあり、これらはエネルギーの伝搬と変換を行うノードである。また、これらノード間を経路であるダクト、配管、電線などの伝搬回路が接続していると考えることができる。そこでこの観点から図を単純化させてみると図３のようなブロック図となる。
【００３２】
この考え方によれば、異常の兆候である症状はこの要求機能を阻害する要因であると考えられるため、機器又は経路のどの部位で発生しても、それに直接的或いは間接的に関連する機能グループを探索することで原因に辿り着くことが可能であると言える。すなわち以下の原則が存在する。
（１）診断を開始するのは１つの症状が発生した場合である。
（２）症状の発生箇所は診断開始時に明確である。
（３）その症状に関して、診断すべき事項は予めブロック化した知識とすることができる。
（４）症状を発生させた原因が、その機器や経路に存在する場合と、他の機器の異常が伝搬して症状となった派生原因である場合と、がある。
（５）機能グループを物質、熱やエネルギーの伝搬経路通りに定義しておくと、その経路をたどることで根本原因である機器にたどり着くことができる。
【００３３】
すなわち、本実施形態では、診断実行時、警報を発生させた計測点の所属する機器から診断を開始し、その機器に原因が見つからず、他の機器を診断したい場合、どの機器に診断を移動させるか制御を行う手法として「機能グループ」と「ライン接続」という手法を導入する。
【００３４】
〔１−２−１．機能グループ〕
ここで、各グループは、エネルギーまたは物質（流体）の移動経路の概念に基づいて設計することができ、各機器は熱・物質移動の制御を行うと考えられる。つまり、１つの建築物には同じ機能のグループが複数存在するが、診断における推論対象の機器間での移動について、診断発生機器が所属するグループ内の移動に制限することにより、無駄な探索が回避できる。
【００３５】
図４は、このような推論対象の移動の例を示す概念図であり、この図に示すように、「冷凍機」からの移動対象を同じ「冷水グループ−Ｎｏ２」内の「冷水ポンプＡ」に制限することで、設備内に仮にこれらと無関係な別の冷水ポンプがあっても探索対象から省くことができる。
【００３６】
なお、一般に１つの機器は複数の部品で構成されるが、各部品が異なるグループに所属したり、また同一の部品でも複数のグループに所属することがある。これにより、１台の機器については症状ごとのいくつかのブロックＢＬをまとめ又は１つの診断ファイルで診断しながら、その機器を構成する部品が相異なる機能グループに接続することにより、そのような異なった機能グループに属する他の機器へ推論対象を移動させ、対応するブロックを診断に利用するといった診断の連鎖が可能となる。
【００３７】
ここで、図５は、１つの機器である「冷凍機」を構成する「凝縮器」や「蒸発器」といった各部品が、それぞれ「冷却水グループ」「冷水グループ」のような異なった機能グループに属する例を示す概念図である。
【００３８】
上記のような機能グループの考え方に基づいて、本実施形態では、設備Ｆを構成する各要素は、同一の機能に関わるグループごとに互いに関連付けられ、この関連付けは、具体的には知識ベース中に記述される。例えば、機能グループごとに構成要素を要素ＩＤなどで所定の領域に登録し、各ブロックから共通して参照することで推論対象の移動先を判断する。
【００３９】
また、これらに対応して、推論制御部１１は、ブロックＢＬに基づいて判明した症状に基づいて、同一グループ内の他の要素に推論対象を移動させるように構成されている。
【００４０】
〔１−２−２．ライン接続〕
また、「ライン接続」は、同一の機能グループへの移動時に、これを制限するものである。例えば、図６の概念図に示すように、１つの「冷水グループ」内に「冷水ポンプ」が複数あるが、冷水ポンプＢ，Ｃの系統と冷水ポンプＡ，Ｄが相互に独立した別系統のとき、同一系統ごとの例えばラインＬ１のように区分しておく。
【００４１】
この場合、図６に示す「移動元機器」からの移動先はラインＬ１内の冷水ポンプＢ及びＣに制限され、冷水ポンプＡ及びＤは対象とならない。このようなライン接続についても、知識ベース３の例えばブロックＢＬ内に記述しておくことにより、診断対象機器からの他の機器への診断移動時に、同じ機種でもラインとして制限されるものとグループとして全て診断する必要がある場合について区分し、推論の内容を変化させることができる。
【００４２】
上記のように、本実施形態では、ライン接続の考え方に基づいて、知識ベース３は、同一のグループに含まれる複数の要素間において推論対象の移動先を限定する情報を含む。このような情報の例としては、例えばブロック中で条件に応じた推論対象の移動先として具体的部品ＩＤを記述しておくか、又は例えば機能グループ中の情報をさらに接続ラインごとに分けておき、推論対象移動時の症状といったパラメータに応じて推論対象を、機能グループ中から又は同一ライン中から選択するなどが考えられる。
【００４３】
〔１−２−３．診断の概略的な例〕
以上に基づく診断の概略的な例を説明する。例えば図２及び図３に示した例において、冷房運転中「室温が高い」という症状が検知された場合の原因探索について考えてみる。この場合、まず「室」について室温検知器自体の問題かどうか判断し、そうでなければ経路を上流へ辿る。この場合、推論対象の移動先は「空調給気グループ」であり（図３）渡されるパラメータは「症状＝室温度高い」である。
【００４４】
移動先の空調給気グループに属する機器のうちこの症状に対応するのは「空調機」であるが、この機器については給気風量、給気温度、熱交換効率、制御弁動作など機器内部知識に従って探索したが、原因が発見できない。但し、冷水供給温度が高いという症状を発見し、推論対象は「冷水グループ」へ、「症状＝冷水温度高い」をパラメータとして移動する。
【００４５】
移動先の冷水グループでこの症状に対応するのは「冷凍機」であり、この機器について蒸発器熱交換効率、冷媒回路など探索した結果、冷却水温度が高いため、所定の冷凍出力が出せないことが判明し、この場合、推論対象は、「冷却水グループ」へ、「症状＝冷却水温度高い」をパラメータとして移動する。
【００４６】
移動先の冷却水グループでこの症状に対応するのは「冷却塔」であり、この機器について制御弁動作、ファン運転状態、外気温度などについて推論を行う結果、知識ベースに基づいて、冷却塔の熱交換効率の低下が指摘される。この場合、他の原因が見つからないため、原因は「冷却塔熱交換器の汚れ」という診断結果を得る。
【００４７】
この例のように、「室温を一定に保つ」機能を維持するために様々なサブ機能が組み合わされているが、１つ１つのサブ機能をそれぞれの機器・経路のブロックで構成することで、極めて単純な構造とすることができる。本実施形態では、このように「症状」に基づき機器内部の診断知識を区分けし、更にその伝搬先を定義することにより、複雑な推論制御機構が不要となる。
【００４８】
〔１−２−４．知識ベースの具体的構成〕
以上のような推論による診断を実現するため、知識ベース３の中に含まれる情報には、
・ノードである機器内部を診断するもの（その機器に根本原因がある場合）
・機能グループに症状を渡すもの（その機器自体は正常で他の機器（グループ）から派生した原因が考えられる場合）
があり、いずれの場合も「症状」をキーとした検索などの処理が行なわれる。
【００４９】
また、機器間を接続する情報として
・機能グループ
・ライン接続
があり、これらの情報を元に「症状」に沿って根本原因が判明するまで次の機器に推論が連鎖してゆく。
【００５０】
〔１−２−５．知識ベースの具体例〕
上記のような知識ベースの論理的構造の例を図７に示す。この例では、１つの機器に対して１つの知識ベースファイルが対応し、各ファイルには症状ごとの診断ブロックが１つ以上含まれる。さらに、各ブロックは１つ以上のルールを含み、各ルールは、１つ以上の条件ブロックと、その条件が成立した場合に考えられる根本原因又は症状を表す原因情報ブロックと、制御用記述である実行ブロックと、を含む。
【００５１】
ここで、条件に対応する原因又は症状は「仮説」を呼び、図１に示したワーキングメモリ７は、仮説を格納する手段としても用いられる。また、実行ブロックにおける制御用記述の種類としては、
（１）対応する症状に基づいて推論対象を他の要素に移動する旨の記述と、
（２）格納されている個々の仮説を前記条件に基づいて消去する旨の記述と、
（３）その要素に係る全ての仮説を前記条件に基づいて消去する旨の記述と、
がある。
【００５２】
このような構成の知識ベース３では（図７）、１つのファイルには１種類の機器に対して複数の症状ブロック（図中太い破線で囲まれた範囲）を記述できるため、１つの機器に対する診断知識の管理は簡単である上に、実際の症状が発生して診断を開始する場合は、このファイルの１つの症状ブロックのみをワーキングメモリにロードするのみでよい。こうした定義構造と流れによれば、異常の症状が診断開始前に判明するので、その機器全ての知識ベースをワーキングメモリに読み込む必要はなく、ルールの条件部を一度だけ評価することにより、処理速度の高速化ができる。これにより従来は別のコンピュータによって実行されていた診断処理が、監視用のコンピュータで同時に動作することが可能となり、またリアルタイム性能を低下させることがないため、低コストでシステムを構築できる。
【００５３】
〔１−３．設備に合わせた診断システムの構築について〕
【００５４】
また、このような知識ベース３は、各要素の症状ごとに予め標準化された各ブロックを原型として、診断対象となる設備の構成を表す構成情報に基づいて、要素間の関連すなわち機能グループやライン接続を設定することによって作成することができる。このような関連は、例えばソフトウェアなどの機構により知識ベースの該当個所に所定の文字列を挿入するといった手法で定義することができる。
【００５５】
この場合、構成情報としては、例えばＣＡＤによる設計図データに含まれる電線、配管、ダクトなどの情報が考えられる。なお、複数の異なる建築物に適用するため、例えば知識ベースのうち機器ごとの内容は適当な標準名称で記述し、建物固有な名称やデータとの対応は別途対照テーブルなどのデータで確保してもよい。
【００５６】
〔２．作用〕
上記のように構成された本実施形態は、次のように作用する。
〔２−１．作用の概略〕
本実施形態における診断システム１では（図１）、監視制御部９が、設備Ｆについて各種センサ類から計測データを受け取ったり制御信号を送信するなどの監視制御を行い、機器などの各要素から送られる計測データが予め決められた基準値から外れるとその要素についてデータ収集チェック部１２が異常の症状を検出する。
【００５７】
このように検出された症状については、推論処理部１０及び推論制御部１１の作用により、該当するブロックＢＬのみをメモリにロードして診断し、その原因となる症状が判明しそれが根本原因でない場合は因果関係を逆に辿り、因果関係の上流側に関連付けられた他の要素に推論対象を移動し、対応するブロックに基づいて同様の処理を繰り返すことにより根本原因に辿り着くことができる。
【００５８】
この際、推論処理部１０は、症状に対応する前記各ブロックＢＬごとに推論処理を行ない、推論制御部１１は、知識ベース内の各ブロックなどに定義された要素間の関連に基づいて、各ブロックＢＬごとの処理を並列または直列に推論処理部１０に逐次実行させる。
【００５９】
〔２−２．処理手順の例〕
ここで、図８のフローチャートは本実施形態における診断の処理手順であり、この手順では、診断は以下の順序で処理される。
【００６０】
〔２−２−１．警報検知…ステップ１〕
まず、診断システム１の中央処理ユニット２では、データ収集チェック部１２が、定期的、例えば１秒毎或いは１分毎に、予め定義された収集すべきデータを各入出力装置Ｃや監視制御部９を経て収集しチェックを行う。ここで、収集すべきデータは別のデータに列挙しておけばよく、このような別のデータをデータマスターと呼ぶ。また、ここでいう「チェック」とは、警報そのものの発生を示すオンオフの情報を得ることだけでなく、温度や圧力といった連続値に関しては所定の正常偏差を定義して、その範囲を逸脱したか否か、或いは所定の変化率を上回ったかなどといったものである。このチェックにより、何らかの警報、或いは正常範囲からの逸脱（仮に警報と総称する）を検知すると、データ収集チェック部１２は診断前処理部１３にその情報を渡す。
【００６１】
〔２−２−２．診断前処理…ステップ２〕
すると、診断前処理部１３は、渡された情報に基づいて、それら異常の兆候が、設備のどの機器、或いはどの経路で発生したかを特定し、予め定義してある症状マスターから、症状コードを検索する。この結果、診断対象となる症状があれば（ステップ３）、さらに、診断前処理部１３は、ヒットした症状コードと、対象となる機器または経路の固有名称に基づいて、知識ベース３の例えば該当するファイルを検索し、その症状をキーとして、対応するブロック及びその条件部を読み出す。またこの時点でその機器に所属するデータを収集してワーキングメモリ７に展開してもよい。
【００６２】
〔２−２−３．診断処理…ステップ４〕
引き続き起動される診断サブシステムすなわち推論処理部１０及び推論制御部１１は、症状に基づいて原因の推論を行う。すなわち、推論処理部１０は、症状に対応するブロックＢＬごとに推論処理を行ない、推論制御部１１は、要素間の関連に基づいて、各ブロックＢＬごとの処理を逐次実行させる。
【００６３】
より具体的には、診断サブシステムは、ワーキングメモリ７からルールの条件部を記述された順番に読み込み（ステップ４１）、必要なデータを取得して評価する（ステップ４２）。この際、条件部が全て真となった場合には、その節に適合する原因ブロックに記述されたコードを「仮説」としてワーキングメモリ７の所定の領域又は別のワーキングメモリ（「仮説」メモリと呼ぶ）に保存する（ステップ４４）。更にその仮説と対になる実行ブロックに記述された制御用記述を解釈し、「機器移動」「原因棄却」「機器正常」などの制御を実施する。
【００６４】
すなわち、この実行ブロックで、「機器移動」処理が記述されている場合は、機能グループ定義情報を読み出し、該当する機器を抽出し、「機器移動」のパラメータとして記述してある「症状」に基づいて、ステップ２から４の手順を繰り返す（ステップ４３）。また、「原因棄却」の記述がある場合は、既に「仮説」メモリに並んでいる原因候補から指定の仮説を消去（却下とも呼ぶ）する（ステップ４４）。また、「機器正常」の記述がある場合は、その機器の機能は正常であるとして、その機器の「仮説」メモリに並んでいる原因候補を全て消去する。
【００６５】
以上の処理を評価すべき条件がなくなるまで順次繰り返し、最終的に棄却されなかった「仮説」を原因として保存する。これにより、同一機器の条件部の評価は一度だけであり、かつ診断対象機器の移動により根本原因を見落とすことがない。
【００６６】
〔２−２−４．診断結果表示…ステップ５〕
その後起動される診断表示部１４は、診断サブシステムによって導かれた原因に関する説明、対策、画像データなどを所定のファイルから読み出し、例えばＨＴＭＬ形式などで読み易く整形して保存し、操作者が表示操作を行ったときにいつでも表示できるように必要な処理を行なう。
【００６７】
〔３．実例〕
上記のような本実施形態における診断の実例について、図９に示す空調設備を例にとって説明する。なお、この図９におけるそれぞれの記号の意味は以下のとおりとする。
Ｒ−１，２，３ ：        冷凍機
ＣＴ−１，２，３：      冷却塔
ＣＷＰ−１，２，３：    冷却水ポンプ
ＳＨ−１，ＲＨ−１：    往管ヘッダー，還管ヘッダー
ＣＰ−１−１，２，３：  冷水一次ポンプ
ＣＰ−２−１，２，３：  冷水二次ポンプ
ＡＨＵ−１，２，３  ：  空調機
ＣＶ−１：              差圧制御弁
ＳＣＵ−１：            熱源制御装置
【００６８】
また、機能グループは各機器の機能毎に接続先がどの機器かを特定する。機能グループの例としては、例えば冷却水グループは、
冷却塔の熱交換器−冷却水ポンプの本体−冷凍機の凝縮器
といったものが考えられ、図９中には次のような３つの冷却水グループがある。
・Ｒ−１  −  ＣＷＰ−１  −  ＣＴ−１
・Ｒ−２  −  ＣＷＰ−２  −  ＣＴ−２
・Ｒ−３  −  ＣＷＰ−３  −  ＣＴ−３
【００６９】
実際には三方弁などの制御装置が加わるが、いずれにせよグループ内での接続は直列１回路であり、どの機器で警報が発生して診断が起動しても、そのグループと個別の機器が特定できる。
【００７０】
また、例えば冷水グループは、
冷凍機の冷却器−冷水ポンプの本体−ヘッダーの本体−空調機の冷却コイル
のような例が考えられるが、図９において冷水グループを定義する基準は複数考えられる。
【００７１】
ここでは、冷水往還ヘッダーを境界として冷水二次ポンプ＋空調機系統（二次冷水グループと呼ぶ）と冷水一次ポンプと冷凍機（一次冷水グループと呼ぶ）の２系統に区分することが効率が良いと考えられる。なお、一次冷水グループ及び二次冷水グループの例を次に示す。
［一次冷水グループ］
・Ｒ−１  −  ＣＰ−１−１  −  ＳＨ−１  −  ＣＶ−１  −  ＲＨ−１
・Ｒ−２  −  ＣＰ−１−２  −  ＳＨ−１  −  ＣＶ−１  −  ＲＨ−１
・Ｒ−３  −  ＣＰ−１−３  −  ＳＨ−１  −  ＣＶ−１  −  ＲＨ−１
［二次冷水グループ］
・ＳＨ−１  −  ＣＶ−１  −  ＣＰ−２−１  −  ＡＨＵ−１  −  ＲＨ−１
・ＳＨ−１  −  ＣＶ−１  −  ＣＰ−２−２  −  ＡＨＵ−２  −  ＲＨ−１
・ＳＨ−１  −  ＣＶ−１  −  ＣＰ−２−３  −  ＡＨＵ−３  −  ＲＨ−１
【００７２】
この場合、例えば空調機で「冷水流量不足」または「冷水温度異常」などの症状が発生したとき、機器移動は、冷水ポンプであり、その際は冷水二次ポンプへの移動が適切であり、単純に冷水一次ポンプを診断しても原因が把握できる可能性は低い。なお、同じ冷水二次ポンプの系統に空調機が複数台存在する場合も同じグループに含める。
【００７３】
また、熱源制御グループとしては
・Ｒ−１〜３  −  ＣＴ−１〜３  −  ＣＷＰ−１〜３  −  ＣＰ−１−１〜３
−  ＣＶ−１  −  ＳＣＵ−１
などが考えられ、空調給気グループとしては、
空調機の冷却器−ファンの本体−室
といったものが考えられ、より具体的には、
・ＡＨＵ−１  −  ＲＯＯＭ−１
などがある。
【００７４】
例として「冷水流量不足」がＡＨＵ−１で発生した場合、ＣＰ−２−１に診断が移動するが、ここで原因が特定されなかった場合、次に何を診断するか固定的に考えることができない。自然な流れとして、同じ冷水二次ポンプでＣＰ−２−２とＣＰ−２−３の系統で異常の症状があるか否かを確認したり、バイパス弁の動作や二次配管系の末端圧力をチェックしたり、系統的な観察の後、冷水一次ポンプの診断に移動するのが妥当であると考えられる。なぜなら冷水一次ポンプは一般に台数制御され、そのうちの一部は回転数制御されている場合もあり、単純な「流量不足」の症状だけで異常の判断は難しい、または推定される原因の数が膨大になるためである。
【００７５】
上記のようにさまざまな要素間の関連に基づいた判断が必要な場合、従来技術では、予め定義された膨大なルールを総当り的に評価してたまたま該当する場合があれば診断が可能であるが、そうでない場合は原因の見落としなどが発生する可能性があった。これに対して、本実施形態では、さまざまな要素間の関連に基づいた判断が必要な場合でも、上記のように機能グループを設定することにより、推論において、それに含まれる機器をノードとして無駄なく機能グループ同士を連鎖させ、根本原因まで探索することができる。
【００７６】
ここで、図１０は、図９に示した例における冷凍機の診断知識ベースの例である。この例に示すように、本実施形態によれば、推論エンジン毎に特殊な文法は不要であり、使い慣れた一般的表計算ソフトウェアによる編集なども容易になる。
【００７７】
〔４．効果〕
以上説明したように、本実施形態では、監視システムのコンピュータにて監視用の機能を損ねることなく、同時に動作する診断システムを構成することができ、従来高価であった診断システムを低コストで導入できる。
【００７８】
すなわち、機器及び機器間の経路といった各要素について、生じうる症状ごとの診断用知識をブロックに分け、一方、要素間の関連は物質、熱、エネルギーの伝搬経路といった因果関係通りに定義しておく。そして、要素について検出された症状については、該当するブロックのみをメモリにロードして診断し、その原因となる症状が判明しそれが根本原因でない場合は、因果関係を逆に辿り、因果関係の上流側に関連付けられた他の要素に推論対象を移動し、対応するブロックに基づいて同様の処理を繰り返すことにより根本原因に辿り着くことができる。
【００７９】
このようにブロックごとに処理することで、必要なワーキングメモリとＣＰＵ負荷が少なくなり、ブロックを構成するルールの条件部を一度だけ評価することにより処理速度が高速化される。このため単一のコンピュータ上で監視と診断を同時並行で処理してもリアルタイム性能等の所期のレスポンスが得られ、単純な構成で低コストでシステムを構築できる。また、ブロックに区分することで知識ベースの構造が単純明快となり、内容理解や編集も容易になる。また、例えばブロックで原因となる症状ごとに推論の伝搬先を定義することで複雑な推論制御機構が不要となる。
【００８０】
また、本実施形態では、ルールに対応する制御用記述すなわち実行ブロックの作用により、あり得る仮説を格納し、あり得ない仮説を消去する処理を繰り返し、最終的に棄却されなかった「仮説」を保存する。これにより、同一要素について条件部の評価は一度だけとなり、かつ診断対象要素の移動により根本原因を見落とすことがない。なお、制御用記述は該当するルールについて存在すればよく、全てのルールについて存在する必要はない。
【００８１】
特に、本実施形態では、機能上の関連をもつ要素同士を予め機能グループとして関連付けておくことにより、ある要素で判明した症状に基づいて推論対象を他の要素へ移動する場合、適切な移動対象を機能グループに基づいて容易に判断できるだけでなく、診断対象となる設備に同種の要素が複数存在する場合でも、無駄な探索を回避することが可能となる。
【００８２】
また、本実施形態では、知識ベースが情報として接続ラインを含むことで、ある症状に基づく推論対象の移動先の候補となる種類の要素が、同じグループ内に複数存在しても、移動元の機器や症状に応じて、そのなかから推論対象の移動先を指定しておくことができる。これにより、要素間の接続関係に応じ、そのグループ内のその種類の要素を全て移動による診断対象とすることもできるし、また、その一部のみを診断対象とすることにより無駄な探索を削減することも可能となる。
【００８３】
また、本実施形態では、異なる建築設備に対して容易に診断システムを構築できる。すなわち、建築物は殆どが受注生産であり、内部の設備の構成も異なる。これらに対してそれぞれ診断知識を構成するのは多くの労力を費やす必要があったが、本実施形態によれば、機器毎に標準化した知識ベースと、対象建築物に特有な、機器を接続する経路を定義するだけで診断システムを構成でき、より一層の導入費用の削減ができる。
【００８４】
すなわち、知識ベースのうち機器や症状ごとの部分は予め標準化しておき、個々の建物特有の機器間の接続構造に合わせて、機能グループ等の関連を定義するだけで知識ベースが簡単に構成できる。このため、具体的設備ごとの知識ベース構築に大きな労力が生じず、人件費などのコスト削減が可能となる。
【００８５】
〔５．他の実施形態〕
なお、本発明は上記実施形態に限定されるものではなく、次に例示するような他の実施形態も包含するものである。例えば、知識ベースについて記述文法といった具体的な形式は自由である。また、診断対象の設備の種類も自由であり、電気や空調の設備には限定されず、工場、航空機などに適用可能である。また、知識ベースについて要素間の関連を定義する手法も自由であり、機能グループや接続ラインには限定されず、そのような関連をどの部分にどのような形式のデータとして記録しておくかも自由に選択することができる。また、制御用記述の具体的種類も、上記実施形態に示したものには限定されず、例えば途中で部分的にオペレータの判断を受け付けるような制御用記述も使用可能である。
【００８６】
【発明の効果】
以上説明したように、本発明によれば、コンピュータ資源への負荷が少ない設備診断の技術すなわち設備診断システム及び方法並びに設備診断用ソフトウェアを記録した記録媒体を提供することができるので、より低コストで信頼性の優れた設備の監視及び診断が可能となる。
【図面の簡単な説明】
【図１】本発明の実施形態の構成を示す機能ブロック図。
【図２】本発明の実施形態において、設備の一例を示す図。
【図３】本発明の実施形態において、図２の例に対応する機能グループを示す図。
【図４】本発明の実施形態において、機能グループ内の機器間における推論対象の移動を示す図。
【図５】本発明の実施形態において、１つの機器の複数の部品がそれぞれ異なった機能グループに属する状態を示す図。
【図６】本発明の実施形態において、推論対象の機器間での移動先が接続ラインによって制限される状態を示す図。
【図７】本発明の実施形態における知識ベースに含まれるブロックの構造図。
【図８】本発明の実施形態における推論手順を示すフローチャート。
【図９】本発明の実施形態における異常診断の実例について、設備の構成例を示す図。
【図１０】本発明の実施形態における異常診断の実例について、症状に対応するブロックの例を示す図。
【図１１】従来技術の一例を示す図。
【図１２】従来技術における知識ベースの内容を例示する図。
【符号の説明】
１…診断システム
２…中央処理ユニット
３…知識ベース
４…磁気ディスク
５…キーボード
６…表示装置
７…ワーキングメモリ
８…制御部
９…監視制御部
１０…推論処理部
１１…推論制御部
１２…データ収集チェック部
１３…診断前処理部
１４…診断表示部
Ｃ（Ｃ１，Ｃ２，Ｃ３）…入出力装置
Ｆ（Ｆ１，Ｆ２，Ｆ３）…設備
【図１】
0004738566.tif 000002
【図２】
0004738566.tif 000003
【図３】
0004738566.tif 000004
【図４】
0004738566.tif 000005
【図５】
0004738566.tif 000006
【図６】
0004738566.tif 000007
【図７】
0004738566.tif 000008
【図８】
0004738566.tif 000009
【図９】
0004738566.tif 000010
【図１０】
0004738566.tif 000011
【図１１】
0004738566.tif 000012
【図１２】
0004738566.tif 000013