【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はビル管理装置、特に情報交換を行うための共通論理モデルである空間モデルを使用するビル管理装置に関する。

【０００２】

【従来の技術】昨今のビルにおいては、ビル内に設置された空調、照明などの設備機器を効率的に運転管理するとともに、快適な居住環境を実現するためのビル管理装置の導入が活発化している。 前記ビル管理装置は、従来集中制御型の装置構成がとられていた。

【０００３】すなわち図１６に示されるように、中央監視盤１０に、空調機器１１、照明機器２５、受配電機器２６等のビル内の設備機器が接続されており、これらの設備機器は中央監視盤１０により一括して制御されている。 従って、各設備機器は中央監視盤１０からの指令により必要な動作を行っている。

【０００４】ここで、ビル管理装置に要求される主な機能としては、監視、操作、設定、メンテナンスの４つがある。

【０００５】監視とは、運転状態の監視であり、各設備機器の運転状態、すなわち機器のオン／オフや機器の正常／異常などを監視することである。

【０００６】操作とは、遠方操作であり、中央監視盤からの操作により各設備機器の運転状態を操作することである。

【０００７】設定とは、設備機器を運用するための各種情報の設定であり、例えばレイアウト設定、スケジュール設定等がある。 レイアウト設定は、ビル内の間仕切りの変更に応じて各設備機器の監視、操作のグループを中央監視盤から変更することである。 またスケジュール設定は、各設備機器の運転スケジュールを中央監視盤から設定、変更することである。

【０００８】メンテナンスとは、メンテナンス監視であり、中央監視盤により、各設備機器の故障、異常状態及び故障履歴を監視することである。

【０００９】このように、ビル管理装置に要求される機能は非常に高いので、集中制御型の装置構成では、ビルの大型化に伴い中央監視盤１０も大型化する必要があり、ビルの規模に対し装置のコストが加速度的に高くなる。 また、各設備機器を制御するのは中央監視盤１０だけなので、快適な居住空間を実現するためのきめこまやかな設備機器の運転が困難である。

【００１０】このため、ビル管理装置としては分散型の装置構成が増えてきている。 分散型のビル管理装置においては、図１７に示されるように、照明、空調、受配電等の各設備機器種別毎に、接続された設備機器を制御する制御手段としての設備コントローラ１３が接続され、
設備毎のサブシステムを構成している。 中央監視盤１０
と各設備コントローラ１３は、インタフェース１２によって接続されている。 各設備機器は、中央監視盤１０から送られてくる運転管理値に基づき、この設備コントローラ１３によって各設備サブシステム毎に独立して制御されながら運転されている。 このためビルが大型化しても、制御機能が分散されているため、集中制御型ほど中央監視盤１０を大型化する必要はなく、安価でシステムが構築できる。

【００１１】また、このような設備毎に分散型の装置構成をとることにより各設備に最適な運転、管理の方法を、設備毎に実現することができるため、よりきめこまやかな設備機器の運転が可能となる。

【００１２】一方、設備機器製造者は、各々自社の設備機器の機能を最大限に引き出すように、独自の設備サブシステムを製造している。 一般的に分散型のビル管理装置は、コンピュータメーカー等が製造する中央監視盤と各設備機器メーカーが製造した各設備サブシステムをインタフェースで接続することにより実現される。

【００１３】前記インタフェース方法は、接続対象の設備サブシステム種別毎に、さらに空調サブシステムという同種の設備のサブシステムであっても製造者が異なればインタフェース方法が異なるために、現状では、管理アドレスを利用して情報伝達を行うことが一般的に行われている。 この例が図１８に示される。 図１８においては、設備機器のうち空調機器に関する例が示されている。

【００１４】図１８において、中央監視盤１０と空調機器１１とは、インタフェース１２によって接続されている。 空調機器１１には、設備コントローラ１３が設けられており、中央監視盤１０との通信はインタフェース１
２を介して設備コントローラ１３により行われる。

【００１５】図１８に示されるように、インタフェース１２を介した通信には、全てその対象を特定するための管理アドレスが使用されている。

【００１６】例えば、「操作」について説明すると、ビル管理人が中央監視盤１０で、操作したい操作対象機器を指定し必要な操作を指示すると、中央監視盤１０は管理アドレス−対象機器対応表３０により対象機器の管理アドレスを特定する。 次いでインタフェース１２を介して前述の管理アドレスとともにその指示を対象機器、すなわち空調機器１１の設備コントローラ１３に伝達する。 設備コントローラ１３は伝達された指示に基づいて空調機器１１の運転を制御する。 このように中央監視盤１０と設備コントローラ１３の間の通信は必ず管理アドレスによって対象機器を特定しながら行われる。

【００１７】また「監視」について説明すると、機器のオン／オフ等の運転状態に関する情報が設備コントローラ１３に集められており、中央監視盤１０から運転状態の監視要求があった場合にこの情報が設備コントローラ１３からインタフェース１２を介して中央監視盤１０に伝達される。 この時設備コントローラ１３では、管理アドレス−対象機器対応表３０に基づいて、対応する機器の管理アドレスがこの情報に付される。 従って中央監視盤１０では、この管理アドレスによりどの機器の情報かを判別することができる。

【００１８】その他前記と同様に、設定及びメンテナンスについても管理アドレスで対象を特定しながら通信をすることにより実施される。

【００１９】つまり、この管理アドレスにより特定されるのは、対象機器のみならず、インタフェース１２を介して通信が行われる全てのデータである。 例えば、ビル内のある場所の温度データや機器の異常を表示するための接点などにも管理アドレスが割り当てられる。

【００２０】管理アドレスを使用した通信用フレームの例が図１９に示される。 このフレームは、通信ソフト上必要になるヘッダ３１とテキスト３２により構成される。 テキスト３２は、通信の内容を表すコマンドと、管理アドレス及び操作指示やその応答等を表すオペランドからなる。 この例では、管理アドレスが６桁の数字で構成されている。

【００２１】

【発明が解決しようとする課題】しかし、管理アドレスを使用する場合は、上述のようにインタフェース１２を介して通信が行われる全ての対象について管理アドレスの割り付けが必要になる。 従って、インタフェース１２
を構築するためには中央監視盤１０と各設備機器のメーカがそれぞれ相手の装置の仕様を十分理解する必要があるが、装置の仕様はメーカごとに異なるため、相互の理解、調整のためには膨大な打ち合わせ時間およびインタフェースを実現するソフトウェアの開発が必要になり、
そのためのコストも高くなるという問題がある。

【００２２】また、通信されるデータの内容は、ビルの間仕切りなどビルの運用によって決定される部分があり、ビルの完成間近にならないとインタフェース１２の仕様が確定しない場合が多いが、上述のように物件毎に膨大な打ち合わせ時間および開発が必要だと工期に間に合わないという問題もある。

【００２３】さらに、ビル管理装置の機能の高度化や昨今の人手不足によるメンテナンス要員の不足により、従来人手を介して行ってきたビル設備機器のグルーピング情報や運転スケジュールの設定、メンテナンス作業をシステム内で自動的に行う診断機能やファシリティマネージメント機能の実現への要求が高まっている。

【００２４】本発明は前記従来の課題に鑑みなされたものであり、その目的は、インタフェースの仕様決定のための打ち合わせ時間および物件ごとの開発労力を削減でき、簡易に設計ができ、また拡張性の向上したビル管理装置を提供することにある。

【００２５】

【課題を解決するための手段】ビル管理装置の機能を前述のように監視、操作、設定、メンテナンスと大別する。

【００２６】ビル管理者のビル設備機器の運営管理に必要な監視、操作の対象は、設備機器の運転状況ではなく、むしろビル内の設備機器の設置された空間（テナント、部屋）の運転状況である。 現状のビル管理装置では、各設備サブシステムから集めた設備機器の状態を中央監視装置１０にて、ビル空間上の部屋単位の情報に変換することにより、前記機能を実現している。 一方、設定、メンテナンスに関しては、空間の情報ではなく、各設備機器の情報が必要である。

【００２７】本発明では、前記ビル管理装置の機能による対象の違いに着目し、中央監視盤と各設備サブシステム間のインタフェースに、監視、操作の対象としての空間をモデル化するとともに、設定、メンテナンスの機能のためには、ファイル転送機能を持たせることにより、
インタフェース実現のコストを大幅に削減しようとするものである。

【００２８】また、本発明では、設定、メンテナンス用に、設定、メンテナンス情報を中心とするインタフェースのための仮想的な機器モデルを使用することにより、
診断やファシリティマネジメント機能の実現に対しても、インタフェース仕様決定に要する時間やコストを削減し、ビル管理装置設計の簡易化と拡張性向上を図る。

【００２９】前記達成のために、本発明の請求項第１項に係わるビル管理装置は、ビル内空間（テナント、部屋等）に設置された空調機器、照明機器などを制御して、
ビルの居住環境を対象空間毎に管理する分散型のビル管理装置であって、空調機器、照明機器などのビル設備機器と、これら機器の動作を自律的に制御する制御手段として、管理対象空間の生活環境を計測および調整する設備コントローラと、ビル全体の運転状態の監視、操作を行う中央監視盤と、を備え、前記設備コントローラと前記中央監視盤とは、前記監視、操作機能を行うために、
インタフェースを介して相互の情報交換を行うための共通論理モデルとして、前記管理対象空間をモデル化した空間モデルを共有することを特徴とする。

【００３０】請求項２に係るビル管理装置は、前記管理対象空間がビルにおいて設定される最小テナント単位の集合で構成されることを特徴とする。

【００３１】請求項３に係るビル管理装置は、前記管理対象空間がビルにおいて建築設備の基本単位として設定される最小単位ユニットであるモジュール単位の集合で構成されることを特徴とする。

【００３２】請求項４に係るビル管理装置は、前記管理対象空間を構成する単位の集合をセルとし、前記セルの集合をグループとして、各単位、セル及びグループについての前記空間モデルに階層を設け、それぞれのデータを共用できるようデータ構造に継承をもたせたことを特徴とする。

【００３３】請求項５に係るビル管理装置は、前記中央監視盤は前記空間モデルとして送られてくる情報を表示装置に表示し及び前記管理対象空間の環境設定情報を前記空間モデルに変換して前記インタフェースに出力し、
前記設備コントローラは、前記空間モデルとして送られてくる前記環境設定情報を前記設備コントローラが有する各機器の制御情報に変換し及び前記管理対象空間の環境情報を前記空間モデルに変換して前記インタフェースに出力することを特徴とする。

【００３４】請求項６に係るビル管理装置は、前記インタフェースに、前記管理対象空間の区分及び管理スケジュールの設定と前記環境調整装置が有する各機器のメンテナンスのための情報をトランスペアレントにやりとりするためのファイル転送モードを設けたことを特徴とする。

【００３５】請求項７に係るビル管理装置は、前記中央監視盤と設備コントローラで、前記インタフェースを用いてクライアントサーバ型の機能を実現し、前記中央監視盤の表示装置にて、設定およびメンテナンスを行いその確認ができることを特徴とする。

【００３６】請求項８に係るビル管理装置は、前記インタフェースを介して交換される前記空間モデルの情報に、トランスペアレントに使用できるエリアを設けて、
前記環境調整装置が有する各機器の物理的なメンテナンス情報を送れることを特徴とする。

【００３７】請求項９に係るビル管理装置は、前記中央監視盤の表示装置に前記トランスペアレントな部分の情報を表示できることを特徴とする。

【００３８】請求項１０に係るビル管理装置は、前記管理対象空間がビル空間上に設けられる座標で指定されることを特徴とする。

【００３９】請求項１１に係るビル管理装置は、前記管理対象空間がラベルで指定されることを特徴とする。

【００４０】請求項１２に係わるビル管理装置においては、設定、メンテナンス用には、物理的な機器の設定、
メンテナンス情報を中心とする仮想的なインタフェースのための機器モデルを使用することを特徴とする。

【００４１】請求項１３に係わるビル管理装置は、情報のやり取りのための通信の情報形式として、「サービス名＋アクセス対象名＋属性種類＋属性値」で構成することを特徴とする。

【００４２】請求項１４に係わるビル管理装置は、前記「アクセス対象」の指定方法として、「アクセス対象名＋識別番号」で表現することを特徴とする。

【００４３】請求項１５に係わるビル管理装置は、請求項１４の表現に前記アクセス対象の詳細情報を付加するための文字列を追加し、「アクセス対象名＋識別番号＋
文字列」で表現することを特徴とする。

【００４４】請求項１６に係わるビル管理装置は、「属性種類＋属性値」を前記属性値を小数や整数など種々の表現形式でやりとりができるように属性値の前に属性値のデータの特性を表すデータ型式識別子を設け、「属性種類名＋データ型式識別子＋属性値」にすることを特徴とする。

【００４５】請求項１７に係わるビル管理装置は、前記識別番号の前に識別番号の各値の持つ特性を表すデータ型式識別子を設け、前記「アクセス対象」を「アクセス対象名＋データ型式識別子＋識別番号」で表現することを特徴とする。

【００４６】請求項１８に係わるビル管理装置は、前記「属性種類＋属性値」に前記属性値の詳細情報を付加するための文字列を追加し「属性種類名＋属性値＋文字列」の構成にすることを特徴とする。

【００４７】

【作用】前記ビル管理装置においては、各設備コントローラと中央監視盤とがインタフェース論理モデルを用いて情報交換することで、操作、監視、設定、メンテナンスなどビル管理装置として必要な情報伝達が簡便に可能になる。

【００４８】設定及びメンテナンスについては、インタフェースに設けられている、専用のトランスペアレントなファイル転送モードにより行うこともできる。

【００４９】さらに、インタフェース情報の構成方法を型式化することにより、インタフェース設計が簡易化される。

【００５０】

【実施例】以下、本発明の好適な実施例を図面に基づいて説明する。

【００５１】図１には、本発明に係るビル管理装置の第１実施例が示され、前述した図１６から図１９における従来例と同一の対象には同一の符号を付して説明を省略する。

【００５２】図１においては、ビル管理装置のうち空調機器に関する例が示される。 中央監視盤１０と空調機器１１とがインタフェース１２によって接続され、また空調機器１１には、制御手段としての設備コントローラ１
３が設けられている。

【００５３】ビル管理装置においては、監視及び操作の対象は各設備機器ではなくビル内の所定の空間、すなわち管理対象空間である。 例えばビルを使用するテナントが入っている部屋がこの管理対象空間に該当する。 従って、中央監視盤１０と設備コントローラ１３とがインタフェース１２を介して情報交換を行なう際には、この管理対象空間毎に通信を行なえばよいことになる。

【００５４】このため、中央監視盤１０と設備コントローラ１３とは、この管理対象空間毎に設定された情報通信のための論理モデルである空間モデルを共有している。

【００５５】そして、インタフェース１２はこの空間モデルの形式で情報を伝達する。 従って、監視及び操作の際には、この空間モデルに中央監視盤１０と設備コントローラ１３のそれぞれがアクセスすることにより情報交換が行なえることになる。

【００５６】ここで、空間モデルの例が図４に示される。 図４の例では、管理対象空間が空間セルとして指定される。 その空間セルには、ビル内の種々の空間を識別するために、セルＩＤがそれぞれ割り付けられている。
また、セルＩＤと共に運転状態、運転モード、異常モード等の空間の空調運転に必要な情報が設けられており、
これらにより空間モデルが構成されている。

【００５７】次に、図１に示されたビル管理装置の機能のうち、空間モデルを使用する操作及び監視の機能について説明する。

【００５８】まず操作について説明する。 管理対象空間の生活環境を調整するために、ビル管理人が中央監視盤１０から環境設定値を指示すると、中央監視盤１０は必要な情報を空間モデルに変換してインタフェース１２に出力する。 この情報は空間モデルにより管理対象空間単位で指定されている。

【００５９】この情報がインタフェース１２を介して設備コントローラ１３に到達すると、設備コントローラ１
３では管理対象空間単位で指定されている空間モデルから対象機器の制御に必要な情報、すなわち各対象機器ごとの制御情報への変換が行われる。 この制御情報に基づいて、設備コントローラ１３が対象機器である空調機器１１の制御を行ない、対象空間の環境を所定のものに調整する。

【００６０】次に監視について説明する。 対象機器からの情報、例えば管理対象空間の温度や湿度あるいは各機器のオン／オフや故障に関する情報は運転情報として設備コントローラ１３に集められる。 設備コントローラ１
３でこれらの情報を空間モデルに変換し、これがインタフェース１２を介して中央監視盤１０に伝達される。 この場合にも、情報の伝達に使用されるのは、空間モデルだけであり、中央監視盤１０及び空調機器１１のそれぞれが空間モデルを共有していれば情報伝達が可能となる。 この際中央監視盤１０では、送られてきた空間モデルから表示装置に表示するための必要な変換が行われることになる。

【００６１】図５には環境調整装置としての空調機器１
１の構成が示される。 上述の通り、中央監視盤１０からインタフェース１２を介して管理対象空間を指定した空間モデルにより管理情報１４が設備コントローラ１３に送られる。 設備コントローラ１３は、管理情報１４に基づいて所定の空間の空気調和を司どる所定の室外機及び室内機の運転制御を行なう。 例えば、管理情報によって指定された管理対象空間が空間１の場合、設備コントローラ１３は図５に示される室外機１及び室内機１を制御して空間１の環境を管理情報１４に含まれる指示に合わせるように動作する。 この際、室外機及び室内機の運転制御に関しては設備コントローラ１３のみが行ない、中央監視盤１０はそれらの個別的な運転に関しては一切関与しない。

【００６２】本発明において特徴的なことは、中央監視盤１０と空調機器１１の設備コントローラ１３との間の情報交換が、それぞれに共通な論理モデルである空間モデルを使用することにより行われている点である。

【００６３】この空間モデルは、個別的な機器を対象とするものではなく、生活環境を制御したい管理対象空間そのものを対象としているので、相互の装置の仕様について詳しく知る必要がない。 すなわち、中央監視盤１０
からは、対象空間の生活環境に関する情報のみをインタフェース１２に出力すればよく、その生活環境を調整するための各機器についての個別的な指示を出す必要がない。

【００６４】また、個別的な機器、図１の例においては空調機器１１は、中央監視盤１０から送られてきた生活環境に関する情報（環境設定値）に基づいて、その環境に管理対象空間を導くために必要な動作をすればよいことになる。 そのために必要な制御は、すべて設備コントローラ１３が司どることになる。 従って、インタフェース１２を介して行われる情報通信は、上述の通り対象空間に関する生活環境設定値のみである。

【００６５】以上より、中央監視盤１０及び空調機器１
１の各メーカーとしては、空間モデルについてのみ把握しておけばよく、それぞれ相手の装置の仕様について深く理解しなくてもインタフェース１２を構築できることになる。 このため、インタフェース１２の構築のための打ち合わせ時間および接続対象の装置毎の新規開発コストを大幅に削減することができる。

【００６６】次に図１に示されるメンテナンスについて説明する。 メンテナンスは、先に説明した通り、各設備機器の故障や異常状態あるいは故障履歴を監視することであるが、本来これらの情報は、各対象機器について詳細な仕様が把握されていないとその監視が困難である。
つまり各対象機器がどのような構成かが把握されていないと、その機器のどの部分に故障があるかを中央監視盤１０の表示装置に表示することはできない。

【００６７】しかし、これらの情報は、中央監視盤１０
の表示装置に表示されるだけでメンテナンス監視の機能を果たすことができるので、各対象機器からのメンテナンス情報信号を表示装置にどの様に表示するかの点だけが決められていればよいことになる。 従って、インタフェース１２にこれらの情報を転送するためのトランスペアレントのファイル転送モードを設けておけばよい。 すなわち、対象機器から故障等に関する信号が前記ファイル転送モードにより伝達された場合には、その信号を識別して所定の表示を表示装置にする構成を中央監視盤１
０に設けておけばよい。

【００６８】これにより、対象機器からの信号の識別だけを出来るようにしておけば、各機器の詳細な仕様について中央監視盤１０の側で知る必要はなくなる。

【００６９】次に設定に関し説明する。

【００７０】設定はビル内のレイアウトに関する機器のグルーピングの情報や機器の運転スケジュールを設備コントローラ１３に設定する機能である。 ビルテナントの変更や部屋の模様替えなどにより、レイアウトを変更する場合等に必要となる機能である。

【００７１】中央監視盤１０から、設定を行う場合、従来のビル管理装置においては、設備装置１１の内部構成を中央監視盤および設備コントローラ１３の双方に設定する必要があった。 しかし、これらの設定情報は、設備コントローラ１３に、設定情報をダウンロードすることにより設定の機能を果たすことができるので、設備コントローラ１３にどのような形式で設定情報を受け渡すかの点だけが決められていればよいことになる。 したがって、メンテナンスと同様に、トランスペアレントなファイル転送モードを使用して簡単に設定機能を実現することが可能である。

【００７２】図６には設定及びメンテナンスに関する情報の伝達方法が示される。 これらの情報は、上述したように、中央監視盤１０と設備コントローラ１３の間でやりとりが行われる。 図１の説明でも述べたように、インタフェース１２に設定データ及びメンテナンスデータを転送するためのトランスペアレントなファイル転送モードを設けてこれらのデータが転送される。

【００７３】中央監視盤１０から入力された設定データは設定、メンテナンス用エディタ１５によりファイル形式に編集され、インタフェース１２を介して設備コントローラ１３に転送される。 設備コントローラ１３では、
ファイルマネージャ１６によりフォーマットが変換されかつファイル格納部１７の所定の場所へ格納される。

【００７４】また、設備機器の故障等のメンテナンスデータは、一旦フィイル格納部１７に格納され、ファイルマネージャ１６によりファイル格納部から引き出されて、中央監視盤１０に向け転送される。 中央監視盤１０
にファイル転送されたメンテナンスデータは、設定、メンテナンス用エディタ１５により中央監視盤１０の表示装置に所定の形式で表示される。 尚、このファイル転送の場合は上述した空間モデルは使用されない。

【００７５】以上説明した通信用フレームの例が図７に示される。 このフレームは、空間モデルで使用されるテキスト１８と、ファイル転送で使用されるテキスト１９
の２種類がある。 空間モデルで使用されるテキスト１８
は、そのテキストが監視及び操作で使用されるコマンドなのかファイル転送であるのかを識別するためのコマンドファイル識別部と、運転状態監視要求等のコマンドと、そのコマンドが適用される対象空間と、設備機器の運転状態等を伝達するオペランドにより構成されている。 一方ファイル転送に使用されるテキスト１９は、同じくコマンドファイル識別部と転送されるべきファイル等によって構成されている。 ここでコマンド及びオペランドの例が図７に示されている。

【００７６】次に管理対象空間の決め方について説明する。 管理対象空間とは、上述の通りビル管理装置で管理するビル内の所定の空間のことをいう。 この管理対象空間の決め方としては、当該ビルにおいて設定する最少のテナント単位の集合とすることができる。 最小テナント単位とは、そのビルにテナントを入れる場合に、１つのテナントが使用することの出来る最小の空間をいう。

【００７７】また、管理対象空間は３．３ｍ×３．３
ｍ、３．２ｍ×３．２ｍ、あるいは３．６ｍ×２．７ｍ
で照明、空調、防災設備の最小単位として利用される建築上のモジュール単位の集合で構成してもよい。

【００７８】これらの管理対象空間を構成する単位をセルとして、このセルを空間モデルの基本単位とする。

【００７９】基本的には、このセル単位の空間モデルを中央監視盤１０と設備コントローラ１３が共有し、互いにアクセスすることにより、監視、操作の機能を実現する。 監視、操作の対象としては、前記セルが基本単位となるが実際のビル運用面から考えると、いくつかのセルを組み合わせたグループという空間概念を持つことが、
テナント、部屋単位の監視、操作を実現する場合に便利なものとなる。

【００８０】そこで、複数セルの集合をグループとして、空間モデルを階層化し、グループ空間モデルの持つデータにセルとの共通性を持たせた（継承関係）。

【００８１】これにより、セルとグループに対して、操作、監視をセルの場合もグループの場合も同じ方法（同じコマンド、手順）でアクセスできるようにし、インタフェース方法を簡単にした。

【００８２】図８に示されるように、セルとしては、前述の通り建築上のモジュールあるいは最小テナント単位とすることができる。 またそのセルの集合をグループとして、一つのテナントに使用させることもできる。 これら階層が付けられた空間毎すなわちセル及びグループの空間モデル定義の一例が図９に示されている。

【００８３】図９に示されるように、セルのＩＤにより当該セルが指定される。 またこれに加えて、運転状態、
運転モード、異常モード等の情報によりセルの空間モデルが構成されている。

【００８４】またこのセルの集合としてのグループに対応する空間モデルは、グループを特定するためのグループＩＤ及びグループを構成する関連セル、更にそのグループの状態を表現するための状態作成論理がセルの空間モデルに追加された形になっている。 従って、運転状態、運転モード及び異常モード等の情報はセルとグループで共通のものとなっている。 すなわちこれらのデータ構造に継承があることになる。

【００８５】次に、管理対象空間の指定方法について説明する。 管理対象空間は、空間毎にラベルを設けてこのラベルによって指定することも可能である。

【００８６】また、図１０に示されるように、ビル内にＸ軸Ｙ軸Ｚ軸を指定して、座標の形で指定することも可能である。 すなわち、Ｘ軸Ｙ軸によって同一フロアの平面上の位置指定を行ない、Ｚ軸によってフロアの階数を指定することができる。

【００８７】図６及び図７に説明した例においては、メンテナンスの監視に関する情報は、インタフェース１２
に設けたファイル転送モードを使用して送ることになっていたが、この情報を空間モデルを使用して送ることもできる。 すなわち図１１に示されるように、空間モデルで使用されるテキスト１８にトランスペアレントに使用することができる領域、すなわちトランスペアレント領域を設けて、これにより空間モデルに定義された以外の監視情報を付加的に転送することができる。

【００８８】このようなトランスペアレント領域を有するテキスト１８によって送られてきた情報を中央監視盤１０において表示する装置の例が図１２に示される。 図１２に示される例では、例えば管理対象空間である社長室の空調がＯＮとなっており、その際トランスペアレント領域によって送られてきた当該社長室の設定温度、冷房装置の運転モード及びその運転時間などの詳細な監視情報が、中央監視盤１０の表示画面４０の中のウィンドウ４１に表示されている。

【００８９】次に、本発明に含まれるクライアントサーバー型のビル管理装置について説明する。 この例が図１
３に示される。 図１３においては、中央監視盤１０と設備機器の設備コントローラ１３とに、クライアントサーバー型システムを実現するためのネットワークＯＳ４２
が備えられている。 中央監視盤１０の側においては、ネットワークＯＳ４２上でユーザインタフェースアプリケーション２０が作動しており、設備コントローラ１３側においては、ネットワークＯＳ４２上で前述したファイルマネージャー１６及びスケジュール管理やグループの指定に関する情報を管理するサーバーアプリケーション２１が作動している。

【００９０】クライアントサーバー型システムでは、単なる情報通信に止まらず、中央監視盤１０から設備機器の設備コントローラ１３に直接働きかけ、機器の調整等を中央監視盤１０のユーザーインタフェース側から行なうことができるという利点がある。 すなわち、ユーザーインタフェースアプリケーション２０は、ネットワークＯＳ４２を介して設備コントローラ１３のファイルマネージャー１６及びサーバーアプリケーション２１に直接働きかけることができる。 このため、従来は現場に設置された設備コントローラ１３によって各機器の機器の調整等を行なう必要があったが、クライアントサーバーシステムによれば、中央監視盤１０の表示装置に設備コントローラ１３のウィンドウを開いて機器の調整等を行なうことができる。 グループ７０はグループ識別子、構成空調リストなどの属性種類があり、モニタや設定などのサービスを持つ。

【００９１】図２に、中央監視盤１０と設備コントローラ１３が情報交換のためのインタフェース論理モデルとして、操作、監視の対象となる空間モデル５２と、設定、メンテナンスの対象となる機器モデル５３を共有し、インタフェース１２を介して情報交換を行うビル管理装置図を示す。

【００９２】図２において、監視や操作では、ビル管理人５１は中央監視盤１０を使って対象空間モデル５２に対してアクセスし、設備コントローラ１３は空間モデル５２を空調機器１１に変換し、指定された内容を空調機器１１に対して実行する。

【００９３】また図２において、設定やメンテナンスでは、ビル管理人５１は中央監視盤１０を使って対象機器モデル５３に対してアクセスし、設備コントローラ１３
は機器モデル５３を空調機器１１に変換し、指定された内容を空調機器１１に対して実行する。

【００９４】図３には、図２における前記インタフェース論理モデルをオブジェクト図の形式で表現している。
前記オブジェクト図は、「オブジェクト指向分析（Ｐ．
コ−ド、Ｅ． ヨ−ドン著）」等の文献の表現形式を引用している。 図３における各オブジェクトは、請求項１２
における監視、操作、設定、メンテナンス用のインタフェース論理モデルの具体例である。 図３に示すように、
インタフェース論理モデルは、操作、監視用空間モデル５５と設定、メンテナンス用機器モデル５６の２つに分類できる。 図３において、オブジェクト５４に注目すると、各インタフェ−ス論理モデルの内部は構成要素を区別するための「アクセス対象」、各アクセス対象が管理する「属性種類」、各アクセス対象の持つ機能を表す「サービス」で構成されている。 また、図３における半円記号１２は、半円周の中点から円の外に向かう線が汎化を示すように線を引き、オブジェクト指向分析における汎化−特化構造を表わすものである。

【００９５】前記「アクセス対象」には、操作、監視用のインタフェース論理モデルの中の空間モデルの一種として空調単位、グループ等の構成要素があり、設定、メンテナンス用のインタフェース論理モデルとして空調機器、室外機、室内機、リモコン等の構成要素がある。 前記「属性種類」には、空調における制御パラメータである温度や湿度、暖房や冷房などの運転モード、運転や停止などの運転状態、設定する温度や湿度などの上下限値等を属性種類として定義している。 前記「サービス」には、監視やメンテナンスを行うためのモニタ、操作などを行うための設定がある。

【００９６】空調システムの操作、監視は、ビルの間仕切りで区切られた部屋などを空間単位で行うのが一般的である。 図３において、操作、監視におけるアクセス対象は、空調単位５７である。 空調単位５７は、温度、湿度、運転モード、運転状態、設定における上下限値などの属性種類があり、モニタや設定などのサービスを持つ。 グループ７０は、グループ識別子、構成空調リストなどの属性種類があり、モニタや設定などのサービスを持つ。

【００９７】操作の例を説明する。 空調単位５７の設定温度を２５℃にしたい場合は、請求項１３にあるインタフェース情報形式「サービス名＋アクセス対象名＋属性種類名＋属性値」に基づき、「設定＋空調単位＋設定温度＋２５℃」という形式で、中央監視盤１０からインタフェース１２を介して空調用の設備コントローラ１３へ情報を送る。

【００９８】ビルにおいては、複数の空調単位により空調制御を行うため、前記空調単位に識別番号が必要である。 例えば、ＮＯ． ５の空調単位の温度設定を行う場合、請求項１３及び請求項１４にあるインタフェース情報形式を用いて、「設定＋（空調単位＋ＮＯ．５）＋設定温度＋２５℃」と表現し、複数の空調単位のうちの１
つを選択的に操作できるようにする。 前記では、ＮＯ．
５として選択される空調単位を操作するときの例を示している。

【００９９】また、ＮＯ． ５の空調単位だけでは、ビル管理人が具体的な場所をイメージしにくいため、空調単位の具体的な場所が明示できれば、便利である。 例えば、ＮＯ． ５の空調単位がビル内の”社長室”に相当する場合を考える。 図１４には、図２と同等のビル管理装置と中央監視盤１０のウィンドウ６５から室温を２５℃
に設定している。 前記動作により、請求項１３及び請求項１５にあるインタフェース情報形式に基づき、「設定＋（空調単位＋ＮＯ．５＋”社長室”）＋設定温っ度＋
２５℃」と表現される情報が中央監視盤１０からインタフェース１２を介して設備コントローラ１３に伝達され、対象機器が制御される。

【０１００】前記設定温度の指定の際には、絶対値で２
５℃と指定する場合と、現在の気温に対する相対値（現在の気温と設定値との差異、気温が３０℃のときは−５
℃）で指定する場合がある。 前記のごとく同じ設定でも異なった設定温度の指定をする場合、請求項１６のインタフェース情報形式にある［データ型式識別子］により属性値を識別することで解消できる。

【０１０１】絶対値で設定温度を指定する場合、絶対値を表す［データ型式識別子］として［ＡＢＳＯＬＵＴ
Ｅ］を用いると、請求項１３及び請求項１６により「設定＋空調単位＋設定温度＋［ＡＢＳＯＬＵＴＥ］＋２５
℃」と表現できる。

【０１０２】気温が３０℃のときに相対値で２５℃の設定温度にしたい場合、相対値を表す［データ型式識別子］として［ＲＥＬＡＴＩＶＥ］を用いると、「設定＋
空調単位＋設定温度＋［ＲＥＬＡＴＩＶＥ］＋（−５
℃）」と表現できる。

【０１０３】次に監視の例を説明する。 監視は、ある時点で対象の持つ情報の読取りを行うことである。 例えば、現在のＮＯ． ５の空調単位の室温を知りたい場合には室温の現在値のモニタ要求を行った場合、前記インタフェース情報形式を用いて「モニタ応答＋空調単位＋Ｎ
Ｏ． ５＋室温＋［ＡＢＳＯＬＵＴＥ］＋２５℃」という表現でＮＯ． ５の空調単位から現在の室温が応答される。

【０１０４】次に設定の例を説明する。 図３に示すとおり、空調機器５９は室内機６０、室外機６１、リモコン６２等のオブジェクトを持つ。 前記機器の設定項目としては、温度、湿度以外に図３の室外機６１の属性である「対象室内機リスト」がある。 「対象室内機リスト」
は、室外機が制御対象とする室内機のリスト形式のデータのことであり、室内機の番号などの複数個のデータで構成される。 前記のようなリスト形式のデータを前記インタフェース情報形式で設定する場合、前記［データ識別子］によりリスト形式のデータであることを明示すれば良い。

【０１０５】しかし、前記の場合、設定の「アクセス対象」は空間ではなく空調機器であるため、ここまで使用してきた空間モデルでは「アクセス対象」を表現できない。 したがって、設定用のインタフェース論理モデルには、空間を対象とした空間モデルではなく、物理的な機器を対象とした機器モデルを使うのがよい。

【０１０６】例えば、ＮＯ． ３の室外機の制御対象をＮ
Ｏ． １からＮＯ． ５までの室内機に設定したい場合、リスト形式のデータであることを表す［データ型式識別子］を［ＬＩＳＴ］として、「設定＋室外機＋ＮＯ．３
＋対象室内機リスト＋［ＬＩＳＴ］＋ＮＯ． １＋・・・
・＋ＮＯ． ５」と表現できる。

【０１０７】また、空調機器には設定温度の範囲が設けてあるため、設定温度の下限値と上限値を指定する場合がある。 前記の場合には、上下限値設定用の［データ型式識別子］として［ＲＡＮＧＥ］を設ければ、請求項１
３及び請求項１６におけるインタフェース情報形式で表現できる。 例えば、ＮＯ． ３の室外機の設定温度の下限値を１５℃、上限値を３０℃としたい場合、インタフェース情報形式は「設定＋室外機＋ＮＯ．３＋設定温度上下限値＋［ＲＡＮＧＥ］＋１５℃＋３０℃」と表現できる。

【０１０８】次に、メンテナンスの例を説明する。 メンテナンスは、ある時点での対象機器の運転状態に関する情報の読取りを行い、故障状況や故障への対処方法をユーザに告知することである。 前記運転状態は、〈運転〉、〈停止〉、〈正常〉、〈異常〉から１項目あるいは複数項目を選択したもので表現できる。 しかし、ある空調機器が故障した場合に必要な情報は、故障の発生した空間よりも故障機器自体に関する情報である。 したがって、メンテナンスの場合にも空間モデルではなく、機器モデルを使用することが望ましい。

【０１０９】前記運転状態を１項目で表現する場合の［データ型式識別子］を［ＳＥＬＥＣＴＯＲ］とすると、ＮＯ． ３の室外機の運転状態の監視結果が〈運転〉
の場合、請求項１３及び請求項１６のインタフェース情報形式に基づき、「モニタ応答＋室外機＋ＮＯ．３＋運転状態＋［ＳＥＬＥＣＴＯＲ］＋運転」と表現できる。

【０１１０】前記運転状態を複数項目で表現する場合の［データ型式識別子］を［ＭＵＬＴＩ＿ＳＥＬＥＣＴＯ
Ｒ］とすると、運転状態が〈停止〉及びの〈異常〉場合、請求項１３及び請求項１６のインタフェース情報形式に基づき、「異常通報＋室外機＋ＮＯ．３＋運転状態＋［ＭＵＬＴＩ＿ＳＥＬＥＣＴＯＲ］＋停止＋異常」と表現できる。

【０１１１】前記のように運転状態が＜異常停止＞の場合、ビル管理者は異常修復のために更に詳細な情報を必要とする。 請求項１８にあるインタフェース情報形式「属性種類名＋属性値＋文字列」を用いると、更に詳細な異常の内容をビル管理者が知ることができる。 例えば、室外機の故障が異常の原因であった場合のインタフェース情報形式は、「異常通報＋室外機＋ＮＯ．３＋運転状態＋異常＋”室外機故障”」と表現できる。

【０１１２】図１５は、前記＜異常停止＞で室外機が故障した場合の中央監視盤の表示例を示している。 図１５
においては、社長室用のウィンドウ６４に異常停止と表示し、異常内容表示用のウィンドウ６５で異常の内容と対処方法の例を示している。

【０１１３】

【発明の効果】本発明により、中央監視盤と設備コントローラがインタフェース論理モデルを用いてインタフェース情報を交換することにより、操作、監視、設定、メンテナンス等の情報伝達が簡易になる。

【０１１４】設定及びメンテナンスは、インタフェースに設けられている専用のトランスペアレントのファイル転送モードによっても行うことができる。

【０１１５】また、前記インタフェース情報を型式化することにより、前記インタフェース設計がさらに簡易化される。

【０１１６】この結果、中央監視盤と各設備機器のメーカーがそれぞれ相手の装置の仕様を十分理解しなくてもインタフェースを構築できるので、インタフェースの仕様決定のための打ち合わせ時間を削減でき、簡易な設計が可能で拡張性の向上したビル管理装置を提供することができる。

【図面の簡単な説明】

【図１】本発明に係るビル管理装置の第１実施例を示すブロック図及び機能説明図である。

【図２】本発明に係るビル管理装置の第２実施例を示すブロック図及び機能説明図である。

【図３】本発明に係るビル管理装置のインタフェース論理モデルのオブジェクト例を示す図である。

【図４】本発明に係るビル管理装置の空間モデルの説明図表である。

【図５】図１の実施例の空調機器を示す構成図である。

【図６】本発明に係るビル管理装置の設定及びメンテナンスに関する情報の伝達方法の説明図である。

【図７】本発明に係るビル管理装置の通信用フレームの説明図である。

【図８】本発明に係るビル管理装置における空間の階層モデルの説明図表である。

【図９】図８の階層モデルに対応する空間モデルの説明図表である。

【図１０】本発明に係るビル管理装置における管理対象空間の指定方法の説明図である。

【図１１】本発明に係るビル管理装置におけるトランスペアレント領域を有するテキストの説明図である。

【図１２】図１１のトランスペアレント領域を表示する装置の説明図である。

【図１３】本発明に係るクライアントサーバー型のビル管理装置の構成図である。

【図１４】本発明に係るビル管理装置の操作の表示例を示すブロック図である。

【図１５】本発明に係るビル管理装置のメンテナンスの表示例を示すブロック図である。

【図１６】従来における集中制御型のビル管理装置の構成図である。

【図１７】従来における分散型のビル管理装置の構成図である。

【図１８】図１７のビル管理装置のブロック図及び機能説明図である。

【図１９】従来における管理アドレスを使用した通信用フレームの説明図である。

【符号の説明】

１０ 中央監視盤 １１ 空調機器 １２ インタフェース １３ 設備コントローラ １４ 管理情報 １５ 設定、メンテナンス用エディタ １６ ファイルマネージャ １７ ファイル格納部 １８、１９ テキスト ２０ ユーザインタフェースアプリケーション ２１ サーバーアプリケーション ２５ 照明機器 ２６ 受配電機器 ３０ 管理アドレス−対象機器対応表 ３１ ヘッダ ３２ テキスト ４０ 表示画面 ４１ ウィンドウ ４２ ネットワークＯＳ ５１ ビル管理人 ５２ 空間モデル ５３ 機器モデル ５４ オブジェクト ５５ 操作・監視用空間モデル ５６ 設定・メンテナンス用機器モデル ５７ 空調単位（オブジェクト） ５８ 半円記号 ５９ 空調機器（オブジェクト） ６０ 室内機（オブジェクト） ６１ 室外機（オブジェクト） ６２ リモコン（オブジェクト） ６３ 表示器 ６４ 制御対象表示ウィンドウ ６５ 操作入力用ウィンドウ ６６ 異常表示用ウィンドウ ７０ グループ（オブジェクト）

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成６年１月１１日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００９０

【補正方法】変更

【補正内容】

【００９０】クライアントサーバー型システムでは、単なる情報通信に止まらず、中央監視盤１０から設備機器の設備コントローラ１３に直接働きかけ、機器の調整等を中央監視盤１０のユーザーインタフェース側から行なうことができるという利点がある。 すなわち、ユーザーインタフェースアプリケーション２０は、ネットワークＯＳ４２を介して設備コントローラ１３のファイルマネージャー１６及びサーバーアプリケーション２１に直接働きかけることができる。 このため、従来は現場に設置された設備コントローラ１３によって各機器の機器の調整等を行なう必要があったが、クライアントサーバーシステムによれば、中央監視盤１０の表示装置に設備コントローラ１３のウィンドウを開いて機器の調整等を行なうことができる。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】００９９

【補正方法】変更

【補正内容】

【００９９】また、ＮＯ． ５の空調単位だけでは、ビル管理人が具体的な場所をイメージしにくいため、空調単位の具体的な場所が明示できれば、便利である。 例えば、ＮＯ． ５の空調単位がビル内の”社長室”に相当する場合を考える。 図１４には、図２と同等のビル管理装置と中央監視盤１０のウィンドウ６５から室温を２５℃
に設定している。 前記動作により、請求項１３及び請求項１５にあるインタフェース情報形式に基づき、「設定＋（空調単位＋ＮＯ．５＋”社長室”）＋設定温度 ＋２
５℃」と表現される情報が中央監視盤１０からインタフェース１２を介して設備コントローラ１３に伝達され、
対象機器が制御される。

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正内容】

【図６】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 藤崎 克己 鎌倉市大船二丁目14番40号 三菱電機株式 会社生活システム開発研究所内