JP3724300B2

JP3724300B2 - 設備管理システム

Info

Publication number: JP3724300B2
Application number: JP34757899A
Authority: JP
Inventors: 紀之小宮; 紀之久代; 繁樹鈴木; 成憲中田
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1999-12-07
Filing date: 1999-12-07
Publication date: 2005-12-07
Anticipated expiration: 2019-12-07
Also published as: JP2001166822A

Description

【０００１】
【発明の属する技術分野】
本発明は、ビル内の空調や照明などの設備機器の制御や状態監視等を行うビル管理あるいはビルメンテナンスシステム等の設備管理システムであって、管理者あるいは居住者が空調や照明等の設備機器を遠隔から制御または監視する手段を提供するための設備管理システムに関するものである。
【０００２】
【従来の技術】
従来、ビル内の空調や照明などの設備機器の制御や監視を行うビル管理システムあるいはビルメンテナンスシステム等の設備管理システムにおいては、これら設備機器の制御や監視はネットワークを介して中央監視室で集中的に行われるのが通例であり、このようなシステムを構築する上で次のような点が難点であった。
【０００３】
第一に、空調制御や照明制御はそれぞれメーカごとの独自制御方式によるため、これら空調制御や照明制御を統括する上位システムであるビル管理のシステムである設備管理システムにおいては、これら空調、照明等々のメーカごとの独自方式とのすり合わせが必要で、この設備管理システム構築のための設計負荷は上位システム側、下位システム側の双方にとって大きな負荷であった。
【０００４】
第二に、上記したような設備管理システムは、テナントである居住者にとって設備機器の監視や制御のネットワークは絶縁されており、せっかくのネットワークの恩恵を受けることができなかった。すなわち、空調運転時間のスケジュール設定や臨時の運転時間の延長、または設定温度の確認や変更などは逐一中央監視室へ依頼するという方法をとっており、これを受けて中央監視室の作業員が設備管理システムを用いて該当する設定を行っていた。
【０００５】
第三に、設備管理システムのネットワーク自体が標準的な技術を用いていないため、世の中にあるソフトウェアの資産を活用して、使用者の使い勝手を向上させるために活用することが難しく、使用者の使い勝手を向上させるためには専用の管理システムの開発を行うことが必要不可欠となり、この負荷が大きなものであった。
【０００６】
第四に、設備管理システムは、複数の機器種に対して、さまざまな機能を提供する必要があるために一般的にソフトウェアとしての規模が大きく、通信、データベース設計、設備特有の制御アルゴリズムを含む多様な技術が必要とされるため、それらの技術は複数の専門技術者により分担した開発が行われる。そのため、各種機器、およびソフトウェア各部位のインタフェース設計が容易に行える仕組みが重要である。また、複数の技術者間でインタフェース定義を共有するためには、厳密かつきめ細かなデータ定義が行えるデータ記述方法が必要不可欠となる。
【０００７】
そこで、発明者は特願平１１−１１９２７８号等に示されたような、構造記述言語による静的かつ動的仕様表現としてのインタフェースの明確化の発明を行っているが、この発明では、データ授受自体の信頼性の確保については考慮されているが、設備機器の監視、制御に関する情報の伝達が正常な状態で行われることが前提であるため、正常に伝達が行われない場合の監視、制御に必要な情報であるエラー情報の伝達が考慮されていないという問題点があった。
また、インタフェース設計の容易化、および厳密かつきめ細かなデータ定義を行う手段についての問題点が残っていた。
【０００８】
【発明が解決しようとする課題】
本発明は、上述のような課題を解決するためになされたものであり、設備管理システムにおいて監視、制御対象機器およびシステムの異常等のエラー情報の伝達を可能とし、また、インタフェース設計の容易化、および厳密かつきめ細かなデータ定義を行う手段を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明に係る設備管理システムは、対象設備に対する設備制御手段への入出力を行う対象制御部と、外部の通信手段への入出力を行う通信管理部と、対象制御部と通信管理部との入出力を整理し、データを蓄積するデータ管理部とを有する設備管理装置とから構成され、この設備管理装置を構成する対象制御部、通信管理部およびデータ管理部はデータ構造記述言語処理部を内包して成り、通信管理部の入出力と、通信管理部とデータ管理部との間で扱うデータのやり取りと、データ管理部と対象制御部との間で扱うデータのやり取りとを共通のデータ構造記述言語で行い、データ構造記述言語は、データ値範囲の定義を含んだデータ定義記述と、実データを表すインスタンス記述とを備え、データ構造記述言語処理部は、インスタンス記述がデータ定義記述で規定されたデータ値の範囲を逸脱した指定が行われている場合には、エラーとみなして、エラー情報を伝達させるものである。
【００１０】
また、データ定義記述は、データ値範囲の他に、データ型の定義、データの単位の定義を含むものである。
【００１２】
また、データ定義記述を、データ構造記述言語の一文書全体に係る定義としてのみではなく、前記一文書内の一部に係る定義としても適用可能とするものである。
【００１３】
【発明の実施の形態】
実施の形態１．
以下、本発明の実施の形態１について図１、図２、図３および図４により説明する。まず図１において、設備管理装置１００は対象制御部１０２とデータ管理部１０３と通信管理部１０４とからなっており、対象制御部１０２とデータ管理部１０３と通信管理部１０４とは各々が後述するデータ構造記述言語処理部１５０を内包する形となっている。これにより、意味情報のやりとりを可能としている。
【００１４】
また、設備制御手段１０１はビル設備すなわち空調や照明などに接続され、それらを制御するネットワークを形成する。ここでは代表として対象設備２００を示した。通信手段１０５はビル管理人や居住者などが利用する情報系端末へのネットワークを形成する。これらネットワークはさらに電話回線などを通じて外部に延長され遠隔管理や遠隔メンテナンスを可能とする。とくに通信手段１０５はインターネットを通じた延長を可能とする。
【００１５】
ここで、データ構造記述言語処理部とはソフトウェア構成上の一部品で、従来の表現ではサブルーチンと呼ばれていた位置付けのものである。図２はこのデータ構造記述言語処理部１５０の内部構成の一例を表しており、データ構造記述言語処理部１５０が解釈部１５１とインタフェース記述部１５２と属性記述部１５３とエラー制御部１５４とから成っていることを示す。ソフトウェアの動作自体は解釈部１５１で行い、必要に応じてインタフェース記述部１５２や属性記述部１５３やエラー制御部１５４が参照される。
【００１６】
例えば、図１および図２においてデータ構造記述言語処理部１５０を持つデータ管理部１０３と通信管理部１０４とは最初に相互の仕様交換を行う。まずデータ管理部１０３の中のデータ構造記述言語処理部１５０のインタフェース記述部１５２からデータ管理部１０３の動作概要表現を作成し、属性記述部１５３から属性一覧表現を作成する。これを通信管理部１０４に伝達し、通信管理部１０４がデータ管理部１０３の仕様を得る。次に通信管理部１０４からデータ管理部１０３に向かって逆の手順が取られる。
【００１７】
この手順により通信管理部１０４はデータ管理部１０３に対してデータ全体を伝達するという約束事が確立し、逆にデータ管理部１０３は通信管理部１０４に対して通信手段１０５に関わる情報のみを抜き出したデータを伝達するという約束事が確立する。これらの約束事が確立すると通常の実行状態に移り、この実施の形態において後述する動作を可能とする。
【００１８】
ここで、データ構造記述言語処理部１５０におけるデータ構造記述言語としては、例えば、ＨＴＭＬの文書を管理しているＷ３Ｃ（ＷＷＷＣ）、すなわちＷｏｒｌｄＷｉｄｅＷｅｂコンソーシアムが提唱しているＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）がある。このＸＭＬによるデータ構造記述言語ではデータ全体の構造とデータの値とを両方表現できるため、データそのものの送受信のほか、各部のデータ仕様公開／交換といった上位の意味情報をやりとりすることが可能になる。
【００１９】
図３はデータ構造記述言語の一つであるＸＭＬデータの簡単な構文例である。ＸＭＬデータ３００は配送情報３０１とコマンド３０２とメッセージ本体３０３とから成っている。配送情報３０１は該ＸＭＬの発信元と要求先とを示し、中継する各部位のデータ構造記述言語処理部ではこの情報を元にＸＭＬデータ３００を要求先へ向けて配送する。
【００２０】
コマンド３０２は後続の項目をどのように扱うのかを決定する。メッセージ本体３０３は具体的なソフトウェアの部位であり、監視、制御対象機器に対するメッセージ内容を表す。この例では、コマンド３０２とあわせ、ＩＤ番号０００１の空調室内機に対し、運転状態をＯＮにする設定要求を行うことを表している。
【００２１】
この設備管理装置の動作概要は次のようになる。例えば通常の監視においてはビル管理人または居住者またはメンテナンス業者または遠隔監視業者（以下単にユーザと記す）が情報系端末から通信手段１０５を通じてデータ構造記述言語による監視要求の情報を通信管理部１０４へ伝達し、通信管理部１０４はその内容をデータ管理部１０３へ伝達する。
【００２２】
データ管理部１０３ではユーザの要求が監視であるのか、制御であるのかを判断し、設備情報を入手するためのデータ構造記述言語を作成して対象制御部１０２へ伝達する。対象制御部１０２ではこれが設備への情報要求であることを判断し、情報要求の通信メッセージを設備制御手段１０１へ流し、設備制御手段１０１に接続されている対象設備２００が要求に対して応答するのを待つ。
【００２３】
対象制御部１０２で通信メッセージの内容を判断できるのはデータ構造記述言語の中から自身が処理できる意味情報だけを抜き出せるためである。このような分業作業は一貫してデータ構造記述言語処理部を持つ部位で実現される。
【００２４】
対象設備２００からの応答があると、以上の動作概要と逆の流れで情報を伝達し、ユーザの監視要求を完了する。なお、ユーザの要求を早急に満たすためデータ管理部設備状態の主なものを内包しており、対象制御部１０２以降の処理を省略することも可能である。
【００２５】
ここで例えば、予め対象制御部１０２で設定してある応答許容時間内に対象設備２００からの応答が無い場合、対象制御部１０２はエラー要因を「監視対象機器無応答」とした上で、データ構造記述言語処理部１５０に対しエラー制御部１５４を参照するように指示する。データ構造記述言語処理部１５０は上記エラー要因を元にエラー制御部１５４を参照し、エラー情報伝達のためのデータ構造記述言語を作成した後、対象設備２００から応答があった場合と同様に、上記動作概要と逆の流れでエラー情報を伝達し、ユーザの監視要求に対してエラー情報を提示することで完了する。エラー情報伝達のためのデータ構造記述言語の例をＸＭＬの場合として図４に示す。図４（ａ）では、コマンド４０１で監視要求に対するエラーの応答であることを表現し、メッセージ本体の監視対象機器の属性としてエラー発生場所、エラーコード、エラーメッセージの情報を含むエラー情報４０２が提示されている。この場合、インスタンスＩＤ番号０００１の空調室内機の運転状態の監視要求に対し、無応答でエラーと判定されたことが表現されている。また、同様に図４（ｂ）の例ではコマンド４０３で機器からのエラー通知が上がってきていることを表現し、メッセージ本体４０４でインスタンスＩＤ番号０００１の空調室内機が機器異常を発生していることが表現されている。
【００２６】
その他、監視、制御対象機器、システムの異常、無応答、制御不能、制御対象不在、データ構造記述言語による監視、制御指示の不正、設備管理システム内部のエラー等の場合にも同様に該当するデータ構造記述言語処理部のエラー制御部が参照され、各々のエラー要因に基づいたエラー情報を含めたデータ構造記述言語が生成され、他の正常系のデータと同様に必要部位に配送され、利用される。
【００２７】
実施の形態２．
以下、本発明の実施の形態２について図５、図６および図７により説明する。設備管理システムにおいては、制御対象となる機器、あるいはシステムを設計する際には、機器そのもの、および機器構成の論理的階層構造、実装の階層構造を図５（ａ）、図７（ａ）のようなオブジェクト図で表現することが最近では一般的となっている。一方、上記オブジェクト図で表現された機器あるいはシステムに対して、それらの実装上のインタフェースの設計はシステムごとにまちまちに行われているのが現状である。例えば、図５（ａ）に示す空調室内機オブジェクト５０１に対し、あるシステムでは空調室内機の運転ＯＮに対するコマンドは０ｘ０１でＯＦＦに対するコマンドは０ｘ００とし、そのコマンドに引き続く値が空調室内機の何号機かを表現する、すなわち空調室内機の２号機に対してＯＮのコマンドを送るには０ｘ０１、０ｘ０２のコマンド列を送ることとする、また別の属性、例えば運転モードに対して制御を行う場合にはまた別のコマンドを割り当てる、等の取り決めが各システムごとに行われており、ソフトウェアのインタフェース設計に多大な工数が必要となっていた。
【００２８】
そこで、本実施の形態に係る設備管理システムでは、設計されたオブジェクト５０１および階層構造７０１を、その構造を機械的に射影したデータ構造記述言語によって記述することで機器およびシステムの外部インタフェースを機械的に導出可能とした。
【００２９】
例えば、データ構造記述言語に前述のＸＭＬを用いた場合について説明する。空調室内機が図５（ａ）のように設計された場合、空調室内機オブジェクト５０１のオブジェクト名称である空調室内機５０２を、ＸＭＬのタグ名５１２に射影する。また、空調室内機オブジェクト５０１の持つ各属性、すなわちインスタンスＩＤ５０３、運転状態５０４、運転モード５０５、設定温度５０６をそれぞれ空調室内機タグを持つＸＭＬのアトリビュートとして射影する。すなわち空調室内機タグ５１２を持つＸＭＬのアトリビュートであるインスタンスＩＤ５１３、運転状態５１４、運転モード５１５、設定温度５１６に射影する。各アトリビュートが取り得る値はオブジェクト５０１の設計時に決定される各属性の取り得る値に対応させる。以上のようにして機器レベルのオブジェクトをデータ構造記述言語に射影する。
【００３０】
上記の例では図６（ａ）のように模式化されるスカラ属性の場合を述べたが、その他、リスト表現、配列表現、構造体表現としてオブジェクトが設計された場合にも同様に図６（ｂ）、図６（ｃ）、図６（ｄ）のようにデータ構造記述言語（図６の例ではＸＭＬ）に射影できる。
【００３１】
次に、上記機器レベルのオブジェクトを含む論理的、および実装上の階層構造をデータ構造記述言語に射影する方法について、図７により、上記と同様ＸＭＬの例を用いて説明する。例えば階層構造が図７（ａ）のように設計された場合を考える。最上位に示されたドメイン識別子７０２と、サーバ側かクライアント側かを表す情報を配送情報７１２に射影する。これにより、ＸＭＬの配送先が決定される。図７（ｂ）の配送先７１２の例では、ドメイン識別子１のクライアント側からドメイン識別子１のサーバ側に対して配送するよう記述されている。サーバ側か、もしくはクライアント側かの各ドメインに配送された後の階層表現はメッセージ本体内で表現する。図７の例では、空調室内機７０５はデータベースマネージャ７０３／プロファイル第一種７０４の階層下となっている。これら各階層をそれぞれメッセージ本体の中の階層化タグとしてＸＭＬに射影する。上記の例では、図７（ｂ）に示すように、データベースマネージャタグ７１３、プロファイル第一種タグ７１４と階層化され、さらにその階層下に空調室内機タグ７１５、７１６が射影される。空調室内機タグの内容については前述の機器レベルのオブジェクトのデータ構造記述言語への射影に準ずる。以上のようにして設計された階層構造７０１はデータ構造記述言語７１１に射影され、インタフェース記述が機械的に導出される。
【００３２】
以上のように、設計されたオブジェクトおよび階層構造を、その構造を機械的に射影したデータ構造記述言語によって記述することで機器およびシステムの外部インタフェースを機械的に導出可能にすることにより、ソフトウェアのインタフェース設計を容易に行うことができる他、一般に普及している種々のオブジェクト仕様、例えばＬｏｎＭａｒｋやＢＡＣｎｅｔ等のオブジェクト仕様に関しても容易にシステムに取り込むことが可能となる。
【００３３】
実施の形態３．
以下、本発明の実施の形態３について図８および図９により説明する。本実施の形態においても、データ構造記述言語としてＸＭＬを用いた場合を例に取り説明する。この実施の形態におけるデータ構造記述言語はデータ定義記述８０１とインスタンス記述８０２とからなっている。データ定義記述８０１には、従来のＸＭＬにもあるデータ構造定義の他、データ型の定義８０３、データ値範囲の定義８０４、データの単位の定義８０５が含まれる。データ値範囲の定義の方法は、例えば取り得る値の集合や、最小値と最大値の組あるいはどちらか一方などのものがある。インスタンス記述８０２ではデータ定義記述８０１を適用することをタグのアトリビュートとして指定する。図８（ｂ）に具体的な一例を示す。この例では、データ定義記述の一例８１１において、データ定義１の名称で定義されるデータ中に空調室内機と照明器の持つ各アトリビュートについて記述してある。空調室内機には運転状態、運転モード、設定温度のアトリビュートがあり、運転状態のデータ型はタイプ１、値範囲は「ＯＮ」か「ＯＦＦ」の値を取り得ることが、運転モードのデータ型はタイプ２、値範囲は「冷房」「暖房」「ドライ」の何れかの値を取り得ることが、設定温度のデータ型はタイプ３、値範囲は最小値が１６、最大値が３１、単位としては「℃」が用いられることが、それぞれ規定してある。照明器についても同様である。
【００３４】
インスタンス記述の一例８１２では、上記データ定義記述の一例８１１を指定した上で、空調室内機、照明器の各インスタンスに対してアトリビュート値の設定を行っている（コマンドを設定要求と仮定）。インスタンス記述の一例８１２では、インスタンスＩＤ番号０００１の空調室内機に対してアトリビュート運転状態のアトリビュート値をＯＦＦに、インスタンスＩＤ番号０００２の空調室内機に対してアトリビュート運転状態、運転モード、設定温度のアトリビュート値をそれぞれＯＮ、暖房、２０に、インスタンスＩＤ番号１００１の照明器のアトリビュート点灯状態、調光率のアトリビュート値をそれぞれＯＮ、１００に設定することを表している。これらのアトリビュート値はいずれも指定されたデータ定義１のデータ定義記述８１１で示された値範囲を逸脱していないことから、正常な指定と判定されて機器への制御信号送信へと導かれる。一方、例えば図８（ｃ）に示したインスタンス記述の一例８１３のように、空調室内機の運転モードに送風が指定されていたり、設定温度に３２が指定されていたり、点灯状態に点灯が指定されていたりするなど、指定されているデータ定義記述８１１で規定された値範囲を逸脱した指定が行われている場合には、エラーとみなされ、本発明の実施の形態１で示した場合と同様にして、エラー情報が伝達される。すなわち、機器側の正常範囲を上記データ定義記述８１１に反映させることにより、機器に制御信号が発行される前にシステム側で事前にエラーを検出できるため、機器へ不正なコマンドを送信して機器に悪影響を与えたり、エラー処理のための無駄な処理を発生させたり、無駄なコマンドを送信することによる余計な通信トラフィックを発生させたりすること等を防ぐことができる。併せて、このようにデータ定義記述を利用することにより、厳密なデータ定義が可能となる。また、データ定義記述のデータ型の定義からは、そのデータ型が使用するメモリ容量が分かるので、静的あるいは動的にインスタンスを生成する際に確保するメモリ量の決定にも利用することができる。
【００３５】
図９では、さらに上記データ定義記述をデータ構造記述言語の一文書全体に対して適用するのではなく、一文書中の一部分に適用可能として、よりきめ細かなデータ定義を可能とした例を提示する。図９（ａ）において、データ定義記述９０１は前記データ定義記述８０１と同様の書式を持つ。説明の都合上、定義内容を２つ用意し、それぞれの定義内容は簡単にした例を示す。このようなデータ定義記述９０１に対して、インスタンス記述９０２は、タグＢ９０２のアトリビュートとしてはデータ定義１を、タグＣ９０３のアトリビュートとしてはデータ定義２を指定し、それぞれのタグの有効範囲内でのみそれぞれのデータ定義記述を有効としている。図９（ｂ）に具体的な一例を示す。インスタンス記述９０６では一文書中の一部分のみにおいてそれぞれ必要なデータ定義をデータ定義記述９０５から利用している。プロファイル第一種タグの１番目のインスタンス記述９０７ではデータ定義１を、プロファイル第一種タグの２番目のインスタンス記述９０８ではデータ定義２を利用している。これにより、プロファイル第一種タグの１番目のインスタンス記述９０７の有効範囲内では空調室内機の運転状態アトリビュートのデータ型はタイプ１で、取り得る値の範囲はＯＮ、ＯＦＦのいずれかとなる。一方、プロファイル第一種タグの２番目のインスタンス記述９０８の有効範囲内では空調室内機の運転状態アトリビュートのデータ型はタイプ２で、取り得る値の範囲は運転、停止のいずれかとなる。よって、インスタンス記述９０６のように、一文書中に、例えば同一オブジェクトの同一アトリビュートに対し別個のアトリビュート値の指定が混在させるようなことが可能となり、部分ごとにきめ細かなデータ定義を行うことができるようになる。ここでは、同じオブジェクトの同じアトリビュートの取り得る値の範囲を変更する例を示したが、その他、データ定義記述をデータ構造記述言語の一文書全体に対して適用するのではなく、一文書中の一部分に適用可能とすることにより、使用可能なオブジェクトを部分ごとに限定したり、同じオブジェクトではあるが利用可能なアトリビュートを変更したり、別名のアトリビュートを利用可能としたり、あるいは単位を変更し、それに伴い取り得る値の範囲を変更したりするなど、使用箇所、使用場面に応じたきめ細かなデータ定義を行うことができるようになる。
【００３６】
【発明の効果】
本発明に係る設備管理システムは、データ構造記述言語処理部が、解釈部とこれに連なるインタフェース記述部と属性記述部とエラー制御部とからなり、ソフトウェアの動作を、必要に応じてインタフェース記述部や属性記述部やエラー制御部を参照しながら上記解釈部で行うようにしたので、対象設備機器およびシステムの監視、制御の際に必要となるエラー情報、すなわち監視、制御対象機器およびシステムの異常、無応答、制御不能、制御対象不在、データ構造記述言語による監視、制御指示の不正等を伝達することができる。
【００３７】
また、機器そのものおよび機器構成の論理的階層構造、実装の階層構造を表現するオブジェクトを、前記構造を機械的に射影した構造記述言語によって記述するようにしたので、機器およびシステムの監視、制御に供する外部インタフェースを機械的に導出することができ、ソフトウェアのインタフェース設計を容易に行うことができる。
【００３８】
さらに、データ構造記述言語において、データ定義記述にデータの型、データ値の範囲、データの単位を含み、前記データ定義記述と、実データを表すインスタンス記述とを分離したので、従来のデータ定義記述にない厳密なデータ定義記述が可能となり、またデータの妥当性の判定も容易に行うことができる。
【００３９】
また、前記データ定義記述を、データ構造記述言語の一文書全体に係る定義としてのみではなく、前記一文書内の一部に係る定義としても適用可能としたので、必要な箇所ごとにきめ細かなデータ定義を行うことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１を示す設備管理システムの構成図である。
【図２】本発明の実施の形態１のデータ構造記述言語処理部の内部構成の一例を示す構成図である。
【図３】本発明の実施の形態１のデータ構造記述言語の簡単な例を示す構文例である。
【図４】本発明の実施の形態１のデータ構造記述言語のエラー情報の記述例である。
【図５】本発明の実施の形態２の機器オブジェクトのデータ構造記述言語への射影の一例である。
【図６】本発明の実施の形態２の各種データ構造のデータ構造記述言語への射影の一例である。
【図７】本発明の実施の形態２の階層構造のデータ構造記述言語への射影の一例である。
【図８】本発明の実施の形態３のデータ構造記述言語におけるデータ定義記述とインスタンス記述の一例である。
【図９】本発明の実施の形態３のデータ構造記述言語における一文書中複数箇所へのデータ定義記述適用の一例である。
【符号の説明】
１００設備管理装置、１５０データ構造記述言語処理部、１５１解釈部、１５２インタフェース記述部、１５３属性記述部、１５４エラー制御部、３００ＸＭＬデータ例、４０２エラー情報、５０１空調室内機オブジェクト、５１１ＸＭＬデータ例、７０１システム階層構造、７１１ＸＭＬデータ例、８０１データ定義記述例、８０２インスタンス記述例、９０１データ定義記述例、９０２インスタンス記述例。

Claims

対象設備に対する設備制御手段への入出力を行う対象制御部と、
外部の通信手段への入出力を行う通信管理部と、
前記対象制御部と前記通信管理部との入出力を整理し、データを蓄積するデータ管理部とを有する設備管理装置とから構成され、
この設備管理装置を構成する、前記対象制御部、前記通信管理部および前記データ管理部はデータ構造記述言語処理部を内包して成り、前記通信管理部の入出力と、前記通信管理部と前記データ管理部との間で扱うデータのやり取りと、前記データ管理部と前記対象制御部との間で扱うデータのやり取りとを共通のデータ構造記述言語で行う設備管理システムであって、
前記データ構造記述言語は、データ値範囲の定義を含んだデータ定義記述と、実データを表すインスタンス記述とを備え、
前記データ構造記述言語処理部は、前記インスタンス記述が前記データ定義記述で規定されたデータ値の範囲を逸脱した指定が行われている場合には、エラーとみなして、エラー情報を伝達させることを特徴とする設備管理システム。
前記データ定義記述は、データ値範囲の他に、データ型の定義、データの単位の定義を含むことを特徴とする請求項１記載の設備管理システム。
前記データ定義記述を、前記データ構造記述言語の一文書内の一部に係る定義として適用することを特徴とする請求項１又は請求項２記載の設備管理システム。