JP2006155456A - ビル用中央監視システムおよびビル用中央監視システムにおけるデータ送信方法 - Google Patents

Abstract

【課題】 膨大なタグ数になるビル管理システムの構築時、指令状態警報用の機能を減じることなく、タグを少なくしてパフォーマンスを維持するとともに、表示設定や履歴記録設定を容易にする。
【解決手段】 中央監視装置と、中央監視装置にネットワークを介して連絡する分散制御装置と、分散制御装置にネットワークを介して連絡するコントローラと、コントローラに接続された下位制御機器とを備え、中央監視装置と分散制御装置とは、リアルタイム系のデータを送受信する手段を設け、分散制御装置は、コントローラから受信する下位制御機器の状態値をアナログ値にアナログ・ディジタル変換し、リアルタイム系のデータを送受信する手段を介して中央監視装置へ送信する。分散制御装置は、受信した下位制御機器の状態値を予め内部定義された所定の状態を示すアナログ値に変換する処理部を有する。
【選択図】 図１

Description

本発明は、ビル用中央監視システムおよびビル用中央監視システムにおけるデータ送信方法に関する。特に、下位の制御機器の状態値をアナログ値に変換して分散制御装置から中央監視装置へ送信する技術に関する。

従来の中央監視システムの入力信号は、通例、デジタル信号入力、デジタル信号出力、アナログ信号入力、アナログ信号出力、パルス入力信号で夫々タグと呼ばれる変数に信号を割り当てて画面の状態表示、履歴の記録、計測値の記録を行っている（例えば、特許文献１，２参照）。
例えば、ＡＨＵ（空調機器）で示すと、ＡＨＵに起動指令を出す際は、デジタル出力タグを［０］＝停止から［１］＝起動に変化させ、下位の分散制御装置に指示を送信する。指示を受けた下位の分散制御装置は、ＡＨＵに対して発停処理を行い、その状態を上位に返信する時には、デジタル入力タグを変化させ、それを送信する。この場合、ＡＨＵに起動指令を受けたので、実際にＡＨＵが起動したなら、ＡＨＵの状態を示すデジタル入力タグを［０］＝停止状態から［１］＝運転状態に変化させる。この時、中央監視装置の内部では、ＡＨＵの運転状態が［０］から［１］に変化したことから、まず画面表示をＡＨＵを示すグラフィックシンボルを停止色の緑色から運転色の赤色に変化させ、運転履歴に現在時刻とともに［ＡＨＵ起動］を内部データベースに記録して運転状態履歴表示エリアに表示させる。もし、ＡＨＵから起動に際して本体が故障であるとの信号が分散制御装置に入力されれば、運転状態のタグは故障で運転状態にならなかったとして［０］のままで、代わりに別のＡＨＵ故障タグを［０］＝正常から［１］＝故障に変化させ、運転状況タグと故障タグの２つを上位に送信する。上位の中央監視装置は、この２つのタグを受信して、表示色は停止状態のままの緑色とし、その上に故障状態を示す橙色に変更するとともに、警報履歴に現在時刻とともに［ＡＨＵ故障発生］と内部データベースに記録し警報履歴表示エリアに表示させるとともに警報ブザーを鳴らす動作を行う動きになっていた。
特開平１１−３９０２５号公報 特開平９−５１３８２号公報

これだけであれば、ＡＨＵの発停および運転状態を監視制御する中央監視システム内のタグは、発停に使用するデジタル出力タグ１点と、運転状態警報用を示すタグは運転状態を示すタグと故障（警報）状態を示す２つのデジタル入力タグとの合計３点のタグだけでよい。しかし、近年は、より多くの細かな制御指示や機器情報表示の機能を中央監視システムに要求されている。

さらに、ＡＨＵの例で示すと、ＡＨＵは室内を冷暖房するものであり、その運転選択内容は、従来の発停停止指令のほかに、運転モード指令として、通常は自動運転指令（従来の発停指令を示す）で運用するが、ある特定の場面で強制送風指令、強制冷房指令、強制暖房指令、強制ウォーミングアップ運転（余冷／余熱）指令を行えるように要求される場合がある。これらの各種の運転モード指示を含めた起動指令を下位の分散制御装置に送信する際には、運転指令とモード指令の自動運転指令、強制送風指令、強制冷房指令、強制暖房指令、強制ウォーミングアップ運転（余冷／余熱）指令、夫々にデジタル出力タグを割り付けて、夫々［０］、［１］の状態を下位の分散制御装置に送信して運転指示を行い、操作履歴に夫々の操作指令内容を記録する動作を指定する必要があった。この場合のデジタル出力タグ数は合計６点になる。

さらに、ＡＨＵの例で示すと、その運転モード状態は、従来の運転停止状態を示すフィードバックのほかに、モードを示す、自動運転状態（従来の運転状態を示す）、送風状態、冷房状態、暖房状態、余冷状態、余熱状態がある。強制指令であれば、そのモードで運転するが、自動運転指示を受けた場合には、起動直後は起動がかかったとして、自動運転状態（従来の運転状態）となり、しかる後ＡＨＵ内部の制御装置の判断若しくは上位からの指示で、室内をウォーミングアップ温調するため、室内が暑ければ余冷状態に、寒ければ余熱状態に、温調の必要がなければ送風状態となる。しかる後、ＡＨＵコントローラの判断若しくは上位の指示により通常の空調状態に入り、同様に室内が暑ければ冷房状態に、寒ければ暖房状態に、温調の必要がなければ送風状態にＡＨＵの状態が逐次変異する。これらを全て従来の方式の機器の状態記録方式で記録していくと、通常の運転状態と自動運転状態（従来の運転状態を示す）、送風状態、冷房状態、暖房状態、余冷状態、余熱状態のモード状態、夫々にデジタルタグを割り付て夫々［０］、［１］の状態を下位の分散制御装置から別々に受信して、夫々の状態が［１］になった時の表示色でグラフィックアイコンの表示色を切り替えるとともに、運転履歴に夫々の状態変化を記録する動作を指定する必要があった。この場合の状態のみのデジタル入力タグ数は７点となる。

また、故障に関しても、ＡＨＵから単に故障を分散制御装置に受信するだけのものであればよいが、より詳しくこの故障要因を中央監視システムで表示、記録することも要求される。ＡＨＵに対して、起動指令を送信した時、起動や停止操作に失敗した時は［操作不良］、正常運転中に何らかの要因で中央監視装置からの指示と相反するようにＡＨＵが停止してしまった時や、停止中に分散制御装置の指示に反して運転状態になってしまった時は［状態不一致］、ＡＨＵ本体（この場合、ＡＨＵに取り付けられた制御装置）から故障と分散制御装置が受信した時は［故障］、ＡＨＵ（この場合、ＡＨＵに取り付けられたＡＨＵ制御装置）との信号送受信に支障が生じて指令および状態取得が行えない状態を［通信異常］というような細かな４種類の故障要因を含めた故障状態を取得しようとした場合、これも同様に、［操作不良］、［状態不一致］、［故障］、［通信異常］、夫々にデジタルタグを割り付て夫々［０］、［１］の状態を下位の分散制御装置から別々に受信して、夫々の状態が［１］になった時の警報表示色でグラフィックアイコンの表示色を切り替えるとともに、警報履歴に夫々の警報状態変化を記録する動作を指定する必要がある。また、この場合の警報のみのデジタル入力タグは４点となる。

従来であれば、１台のＡＨＵに対する起動停止出力用デジタル出力タグ１点と状態警報入力用デジタル入力タグ２点との合計３点のタグでだけでよかったが、前記のような詳細な指令および状態警報表示を要求された場合には、運転モード指令を含めた起動停止出力用デジタル出力タグとして６点と、運転モードを含む状態デジタル入力タグとして７点と、警報用デジタル入力タグ４点との合計１７点にもなる。これは従来のゆうに６倍近くにものぼる数になる。

従来からの変化は、機器単体の詳細情報量のアップだけでなく機器の台数とそれの制御対象を細かくする要求の変化もある。
例えば、貸ビル（テナントビル）では、空調システムは、セントラル空調機と呼ばれるメインのＡＨＵ＋ＶＡＶ方式（エアハンドリングユニットとＶＡＶ（Variable Air Volume Unit)を使用する変風量方式）の空調機器と、ペリメータ（窓際）用補助個別空調機としてペリメータに複数台の手元操作が可能なＰＡＣ（パッケージ型空調機）が多数設置される。従来は、ＶＡＶの１台あたりの設置エリアは約６ｍ×１２ｍのエリアに１台であったが、近年はその倍の６ｍ×６ｍに１台のＶＡＶを設置するように、倍の台数を設置してきめ細かく制御できるようになってきている。

また、従来は、１つの空調機制御単位エリアのＡＨＵ（１台）＋ＶＡＶ（８台）の空調機を運転する場合には、ＡＨＵに対して起動指令を出しその状態を受信するため、従来のデジタル出力入力点数の３点のみで、ＡＨＵ＋ＶＡＶ（ＡＨＵとそれに接続される複数のＶＡＶ）を一括の運転状態で監視していたし、ペリメータ用ＰＡＣも同空調機制御単位エリアのペリメータ部に１８台が設置されていたとしても、個々に制御するのではなく、ＰＡＣ１８台に送電する動力盤の元の部分で一括して電源ＯＮ／ＯＦＦを行うことで、１８台を１台としてみなして扱えるため、機器発停のデジタル出力入力信号の３点のタグでまとめて動かしてその状態を監視していた。

近年は、より細かく制御することが要求され、ＡＨＵ＋ＶＡＶであれば、ＡＨＵだけでなく、ＶＡＶ個々にも起動指令を出力可能にするよう要求される。単位面積当たりのＶＡＶ台数が倍になったことと、前記の各機器毎の指令状態警報信号取得項目が増えていることに相まって、ＡＨＵ（１台）＋ＶＡＶ（１６台）の指令状態警報タグ数は２８９点（１７タグ×１７台）、ＰＡＣの１８台分で３０６点（１７タグ×１８台）、計５９５点ものタグ点数となる。３０階を超える大規模ビルの場合、例えば前記の空調機制御単位エリアが、フロアで４エリアあり、それが３０フロアあったとすると、機器として４，２００台（（１７台＋１８台）×４エリア×３０フロア）で、この機器の指令状態警報タグ数だけを単純計算すると、７１，４００点（（２８９＋３０６）×４エリア×３０フロア）のタグ数ともなる。従来方式で同様に概算計算すると、７２０点（（３タグ＋３タグ）×４エリア×３０フロア）のタグ数であることと比較すると約１００倍のタグ数になる。

勿論、ここで示した例は、単なる機器の運転指令と状態警報に関するタグについてのみ記載したが、実際にはそれぞれの機器に対する設定温度や計測温度があり、これらも従来は一括であったものが、個別に必要となるため、これらのタグ数も大きく増えることとなる。
前記のように、近年のビル制御監視用中央監視システムに要求される高度な要求項目を満足させようとすると、非常に多量のタグを用意してそれを画面や各種履歴の表示記録設定を行わなければならなくなる。一般的な中央監視システムに使用するＳＣＡＤＡ(Supervisory Control And Data Acquisitionの略）は、中央監視画面の表示、下位との通信、各種履歴への保管等を行うソフトが一般的に使用されている。これらのＳＣＡＤＡソフトは内部的には、１６ｂｉｔ即ち６５５３５タグを最大としているものが多く、上記の概算値だけでも、この上限を超えてしまい、通常のものは使用できない。一部の最新式のＳＣＡＤＡソフトは、３２ｂｉｔになっているものもあり、点数的には処理は可能であるが、許容タグ数が増えているだけで、内部的な処理には大きな変化はないので、膨大な点数になった時に、その処理速度やパフォーマンスの確保が極めて困難であり、できる限りタグの総数を減らす必要がある。

また、従来のデジタル入出力タグを使用した方法をとった場合の画面表示設定は極めて複雑になる。まず、一番下層に運転停止を定義したタグのグラフィックシンボルを置き、停止時は停止色の緑色、運転時は運転色の赤色を定義する。それとまったく同形のグラフィックシンボルをセル画のように、運転状態のグラフィックシンボルの上にモードを示すグラフィックシンボルをモード外なら表示せず、当該モードならその表示色で表記するように定義したものを、モードの数分（この場合６種）重ね、一番上にさらに故障を示す同形のグラフィックシンボルを、故障要因の３種類分を重ねて１台の状態表示をさせるという極めた複雑で手間のかかる設定をしなければならなくなる。

本発明は斯かる従来の問題点を解決するために為されたもので、その目的は、膨大なタグ数になるようなビル管理システムを構築する時、最もタグ数が多くなる機器の指令状態警報用の機能を減じることなく、タグを少なくしてパフォーマンスを維持するとともに、表示設定や履歴記録設定を容易にすることを可能とした中央監視システムおよびビル用中央監視システムにおけるデータ送信方法を提供することにある。

請求項１に係る発明は、中央監視装置と、前記中央監視装置にネットワークを介して連絡する分散制御装置と、前記分散制御装置にネットワークを介して連絡するコントローラと、前記コントローラに接続された下位制御機器とを備え、前記中央監視装置と前記分散制御装置とは、リアルタイム系のデータを送受信する手段を設けて成るビル用中央監視システムにおいて、前記分散制御装置は、前記コントローラから受信する前記下位制御機器の状態値をアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信することを特徴とする。

請求項２に係る発明は、中央監視装置と、前記中央監視装置にネットワークを介して連絡する分散制御装置と、前記分散制御装置にネットワークを介して連絡するコントローラと、前記コントローラに接続された下位制御機器と、前記中央監視装置と前記分散制御装置とに設けたリアルタイム系のデータを送受信する手段と、前記中央監視装置に設けられ、前記中央監視装置から前記分散制御装置に非リアルタイム系のデータを送信する手段と、前記非リアルタイム系のデータを送信する部分に設けた汎用リレーショナルデータベースを持つサーバと、前記分散制御装置に設けた前記非リアルタイム系のデータを受信する手段とを備え、前記非リアルタイム系の送信する手段および受信する手段は、前記リアルタイム系の送受信に遅延を生じさせずにその合間を縫って前記サーバから非リアルタイム系のデータの送受信を行い、前記分散制御装置は、前記コントローラから受信する前記下位制御機器の状態値をアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信することを特徴とする。

請求項３に係る発明は、請求項１または請求項２記載のビル用中央監視システムにおいて、前記分散制御装置は、受信した前記下位制御機器の状態値を予め内部定義された所定の状態を示す前記アナログ値に変換する処理部を有することを特徴とする。
請求項４に係る発明は、請求項１または請求項２記載のビル用中央監視システムにおいて、前記アナログ値は、運転状態と警報状態とを記載する状態項目と、アナログ入力タグ名と、前記運転状態と前記警報状態とに対応する送信する値とを有することを特徴とする。

請求項５に係る発明は、請求項２記載のビル用中央監視システムにおいて、前記汎用リレーショナルデータベースには、前記中央監視装置と前記分散制御装置との通信に使用する変数定義のマスターデータベースが保管され、前記マスターデータベースには、全ての前記分散制御装置毎の通信に使用する変数の定義があり、前記各変数毎にリアルタイム系の上位通信に使用するもの、リアルタイム系の下位通信に使用するもの、非リアルタイム系の下位通信に使用するものの３種類の通信手段および通信方向が判別可能なフィールド定義があり、前記中央監視装置は、前記フィールド定義を元に前記分散制御装置との通信を行い、前記分散制御装置は、前記分散制御装置を設置して前記中央監視装置と接続する時、若しくは、送受信変数内容に変更が生じた時、各変数毎の送受信方法が記載されている前記マスターデータベースから自局の分の変数定義のみを取り込んで保管し、これを用いて前記中央監視装置との通信を行うことを特徴とする。

請求項６に係る発明は、請求項１ないし請求項５の何れかに記載のビル用中央監視システムにおいて、前記リアルタイム系のデータを送受信する手段では、前記分散制御装置から各種機器状態、計測値、警報が前記中央監視装置へ送信され、前記中央監視装置からサーバ変更通知、火災警報通知、停電発生通知が前記分散制御装置へ送信され、前記非リアルタイム系のデータを送信および受信する手段では、前記中央監視装置からリアルタイム系のデータとして前記分散制御装置へ送信後に前記分散制御装置から送信される送信要求に対し、前記サーバから要求スケジュール返信、要求更新済み設定値返信が前記分散制御装置へ送信されることを特徴とする。

請求項７に係る発明は、請求項２ないし請求項６の何れかに記載のビル用中央監視システムにおいて、前記非リアルタイム系のデータは、（１）スケジュールデータ、（２）設定値データ、（３）メンテナンス用設定値データであることを特徴とする。
請求項８に係る発明は、請求項２ないし請求項７の何れかに記載のビル用中央監視システムにおけるデータ送信方法において、前記中央監視装置から前記分散制御装置で送信された前記非リアルタイム系のデータを、前記下位制御機器に送信し、前記非リアルタイム系のデータに基づいて前記下位制御機器のスケジュールまたは設定値を変更し、その後、前記コントローラから受信する前記下位制御機器の状態値を、前記分散制御装置においてアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信することを特徴とする。

請求項９に係る発明は、請求項８記載のビル用中央監視システムにおけるデータ送信方法において、前記中央監視装置では、前記アナログ値を受信すると、運転履歴の状態記録または運転・警報履歴の状態警報記録を行うことを特徴とする。

本発明によれば、タグの点数は、従来に比べて約１／１０程度に少なくすることが可能になる。
画面の状態表示に関しては、簡単なものから詳細なものまでを同じシステムで定義体のみの変更で容易に実現できる仕組みを提供できる。また、画面の状態表示としてのシンボル表示に対し、タグを１つ定義するだけで良く、シンボル表示を多層重複させるような複雑な構成ではなくなり、画面設定に手間がかからない。

運転履歴や警報履歴も同様に状態タグの値を記載することで、たとえ一番簡易な記載方法であっても、内部定義されたそのアナログ値を見るだけで、オペレータは機器の状態を容易に確認できる。警報値については、必ず直前の機器運転状態値に計表状態の値を足し込むため、警報状態の値を見るだけで、警報発生した直前の機器状態の情報をオペレータに提供でき、警報要因特定のために、警報履歴と運転履歴を夫々調べる必要もなく、原因の推定を行う手助けが可能となる。

履歴にこのアナログ値を記録することで、その値を利用して別途設けた定義体により自在にディスクリプションを生成することも可能で、その内容も簡易なものから詳細なものまで初期設定で自在に選ぶことが可能な手段を提供できる。
この値をリアルタイム系のデータとして中央監視装置のデータベースに他のデータと併せ同時に書くことで、例えば運転履歴に常に機器の状態変化が記載されるため、通常中央監視装置に持っている機器運転時間の累積や運転回数の累積記録表示機能を、この運転履歴を日一回のバッチ処理で機器毎の運転状態から累積時間の演算や累積回数の演算を行うことが容易にできる。

以下、本発明を図面に示す実施形態に基づいて説明する。
図１は、本発明に係るビル用中央監視システムを適用した機器構成を示す図である。図２は、図１におけるデータ送受信系統図である。図３は、図１におけるソフトウエア構成図である。
本実施形態では、大規模なビルで、ローカル制御用の分散制御装置が１５０台程度あり、管理点数が１５万点を超えるようなビルの中央監視システムを構築しようとする場合について説明する。

本実施形態において、サーバＰＣ（パーソナルコンピュータ）から成る中央監視装置１０は、イーサネット（登録商標）１１を介してＰＣから成る複数の監視端末１２と、プリンタ１３と連絡し、またインターネット１６を介して接続する遠方監視端末１５とルータＨＵＢ（ルータハブ）１４を介して連絡している。監視端末１２は、中央監視の監視画面の表示およびスケジュールや設定値等の入力を行うため、インターネットエクスプローラ等のＷｅｂプラウザ（表示入力ソフト（マンマシンインターフェースソフト＝ＭＭＩ））でインターネットと同じソフトで監視画面の表示設定ができるようになっている。また、中央監視装置１０は、ＳＷ−ＨＵＢ（イーサネット通信を行うハブ）１７を介して上位ネットワークとＬｏｎ(Local Operating Network)通信のゲートウェイを兼ねた複数のＬｏｎ対応型コントローラ兼ゲートウェイ装置（以下、ＧＷと称する）１８と連絡している。ＧＷ１８は、ここでは、チャネル１を介してＡＨＵコントローラ（空調機器制御装置）１９と、空調機制御用の冷水弁、加熱弁、加湿弁等のバルブ２０と、空調機制御用の温度計、湿度計、露点温度計等のセンサ２１と接続し、チャネル２を介してＶＡＶ（可変風量制御装置）２２と接続し、チャネル３を介してＰＡＣ（個別ヒートポンプ式エアコン）２３と接続し、チャネル４を介してＤＩＯ（汎用接点入出力装置（各種警報等の接点入力、出力に使用））２４と接続している。

中央監視装置１０は、図２に示すように、Ｌｏｎ上の制御機器を設定調整するツール（Ｌｏｎローカル機器のコミッショニング・バインディング、Ｌｏｎローカル機器の状態監視・各種設定が可能なソフト）（図示せず）と、分散制御装置上制御ソフトを調整するツール（制御ソフトのインストール、制御ソフトの制御状態遠隔監視機能、変数・設定値の表示・設定機能を持った制御ソフト用の遠隔監視設定用ソフト）（図示せず）と、監視・設定画面表示部１０ａと、リアルタイム系のデータ受信部１０ｂと、リアルタイム系のデータ送信部１０ｃと、データベースインターフェース（データベースＩＦ）１０ｄと、ＳＱＬ（Structured Query Language）Ｄａｔａｂａｓｅ（以下、ＳＱＬ／ＤＢと称する）１０ｅとを備えている。ここで、ＳＱＬ／ＤＢ１０ｅは、監視端末１２からイーサネット１１を介して入力されたスケジュール等を統合管理・保管する汎用リレーショナルデータベースである。また、ＳＱＬ／ＤＢ１０ｅは、各種のデータを保管しそれを利用することで通信方式を汎用化するのではなく、データベースが汎用であるので、そこにアクセスする方法は万国共通であるゆえにオープン化されたシステムになっている。

また、中央監視装置１０は、図３に示すように、クライアント制御部１０ｆと、受信ドライバ１０ｇと、送信ドライバ１０ｈと、ＳＣＡＤＡ(Supervisory Control and Data Acquisition：中央監視装置プログラム)１０ｉと、ＳＣＡＤＡスケジュール管理アプリケーション１０ｊと、ＳＣＡＤＡ／ＯＤＢＣ(Open DataBase Connectivity)ドライバ１０ｋと、ＧＷ／ＯＤＢＣドライバ１０ｍと、ＳＱＬ／ＤＢ１０ｅとを備えている。ここで、クライアント制御部１０ｆは、監視端末１２に連絡し、監視・手続発停を受信し、イベント制御・運転モードを送信する。

ＳＣＡＤＡ１０ｉは、従来と同様にマイクロプロセッサの制御の下に監視制御およびデータ収集機能を実行する。ＳＣＡＤＡ１０ｉは、リアルタイム系の受信ドライバ１０ｇから下位のＧＷ１８が取り込んだデータを常に受信している。受信したデータは、ＳＣＡＤＡ１０ｉ内部で表示画面の所定の値を常に更新してクライアント制御部１０ｆからの表示要求に応えられるように動作する。クライアントの監視端末１２がある画面を表示させようとする場合には、クライアント制御部１０ｆに要求を出し、所定の画面をクライアントの監視端末１２に表示させる。画面内のデータは、常に新しい値が来るので逐次画面内の値や機器の状態値の表示を更新している。

また、ＳＣＡＤＡ１０ｉは、受信したリアルタイム系のデータをＳＣＡＤＡ／ＯＤＢＣドライバ１０ｋを介してＳＱＬ／ＤＢ１０ｅ内の所定のデータベースに保管する。計測値であれば、ある一定時間（例えば１０分単位）でＳＱＬ／ＤＢ１０ｅ内の計測データに保管するし、警報・機器状態信号であれば逐次変化の内容を履歴データに保管する。クライアントの監視端末１２から設定値の変更画面を要請されると、ＳＣＡＤＡ１０ｉ内の設定画面をクライアント制御部１０ｆが呼び出し、クライアントの監視端末１２の画面に表示する。オペレータが監視端末１２から設定値を入力すると、ＳＣＡＤＡ１０ｉを介して各パラメータを保管する変数定義体やＧＷ／機器設定値用のＳＱＬ／ＤＢ１０ｅの各データベースに保管され、必要に応じてＧＷ１８に送信される。

また、クライアントの監視端末１２からスケジュールを表示設定することが要求されると、クライアント制御部１０ｆがＳＣＡＤＡスケジュール管理アプリケーション１０ｊから所定の画面をクライアントの監視端末１２に表示させる。オペレータが監視端末１２からスケジュール等の入力（設定）を行うと、ＳＣＡＤＡスケジュール管理アプリケーション１０ｊは、所定の変換を行い、ＳＱＬ／ＤＢ１０ｅ内のスケジュール入力データに記載するとともに、ＳＣＡＤＡ１０ｉに該当するＧＷ１８のスケジュールが変更されたことを通知する。ＳＣＡＤＡ１０ｉは送信ドライバ１０ｈを通じて当該ＧＷ１８にリアルタイム系送信手段で変化した通知を下位のＧＷ１８に送信する。

ＳＱＬ／ＤＢ１０ｅは、図３に示すように、大きく６つのデータ群が保管されている。
［変数定義体］には、上位の中央監視装置１０と下位のＧＷ１８との通信に使用する変数定義のマスターデータベースが保管されている。このマスターデータベースには、全ＧＷ１８毎の通信に使用する変数の定義があり、各変数毎にリアルタイム系の下位送信通信に使用するもの、リアルタイム系の上位通信に使用するもの、非リアルタイム系の下位通信に使用するものの３種類の通信手段および通信方向が判別可能なフィールド定義があり、上位の中央監視装置１０はこれを元に下位のＧＷ１８との通信を行う。ＧＷ１８はＧＷ１８を新たに設置して中央監視装置１０と接続する時、若しくは、送受信変数内容に変更が生じた時、各変数毎の送受信方法が記載されているマスターデータベースから自局の分の変数定義のみを取り込んで、ＧＷ１８内に定義内容を保管してこれを用いて、上位の中央監視装置１０との通信を行うようになっている。

［履歴データ］は、火災警報や機器故障等の警報履歴データが保管されている。
［計測値データ］にはローカルから上位の中央監視装置１０に送信されてくる温度や湿度の計測値、電力量や演算で求めた運転時間や運転回数等の積算値が記録されている。
これらは他のシステム、例えばＢＥＭＳ（ビルエネルギー解析システム）のようなものがデータを後で解析する時に参照するために使用される。ここでは、ＳＱＬデータベースになっているので、参照するには特別な手法ではなく、ごく一般的なＯＤＢＣのオープンなアクセス方法で参照が可能なようになっている。

［スケジュール入力データ］には年間カレンダやこのカレンダに関連付けられたテナントグループスケジュールが保管されている。旧型のシステム（通常）は機器毎にスケジュールを持たせていた。例えば、あるフロアのＡＨＵを動かすスケジュールであれば、ＡＨＵ毎にそのスケジュールを入力するようなソフト構成になっていた。本実施形態におけるスケジュールシステムは、そのようになっていない。機器にスケジュールを直接割り当てるのではなく、テナントグループと呼んでいるグループにスケジュールを設定する方法をとる。これは図３に示すＳＣＡＤＡスケジュール管理アプリケーション１０ｊに監視端末１２のクライアントブラウザー１２ａ経由で入力された内容で処理を行う。

例えば、あるビルの１２階のエリアに○▲証券があったとすると、その証券会社にカレンダを割り当てる。
○▲証券が通常の日曜祭日と土曜と平日で空調運転契約であれば、当該カレンダに３種類の曜日を定義する。
テナントにはいくつものグループを定義する。例えばテナント内にある部屋の名称で、社長室や会議室等がこれに当たる。

例えば、○▲証券内の部屋として社長室や会議室、営業部エリア等々のグループを定義する。
次に、これらのグループにその部屋またはエリアに設置された機器を関連付けさせる定義を行う。
例えば、○▲証券の社長室には機器番号でＶＡＶ００１とＰＡＣ００１の２台の異なる空調機器が設置されている場合には、この機器を割り付ける。これらの情報は全て［スケジュール入力データ］のデータベース内に関連付けが定義される。

実際にスケジュールを入力する時は、監視端末１２のオペレータはＶＡＶ００１のスケジュールを入力するのではなく、ＳＣＡＤＡスケジュール管理アプリケーション１０ｊの入力画面で社長室のスケジュールを入力する。そうすると、ＳＣＡＤＡスケジュール管理アプリケーション１０ｊはその入力内容を［スケジュール入力データ］に記録する。入力されたスケジュールと関連付けされた機器データベースから自動的にスケジュール出力データが計算され、計算結果が、［スケジュール出力データ］のデータベース上に機器毎のスケジュールが生成される。

ＳＱＬ／ＤＢ１０ｅでは、監視端末１２のオペレータの設定によりテナントグループのスケジュール設定値が変更されたら逐次、ＳＱＬ／ＤＢ１０ｅ上の実行機器スケジュールを更新する。
前項では、スケジュールの更新（変更）を記載したが、スケジュールの入力と構造はまったく同じである。図３に示す監視端末１２のクライアントブラウザー１２ａを介してＳＣＡＤＡの設定画面で設定値を変更すると、［ＧＷ／機器設定値］のＳＱＬ／ＤＢ１０ｅに変更された値が記録される。

ＧＷ１８は、図２に示すように、リアルタイム送受信部１８ａと、データベースインターフェース（データベースＩＦ）１８ｂと、制御回路１８ｃと、Ｌｏｎインターフェース（ＬｏｎＩＦ）１８ｄとを備えている。
また、ＧＷ１８は、図３に示すように、ＭＯＤＢＵＳ送信部１８ｅと、ＭＯＤＢＵＳ受信部１８ｆと、ＧＷ／ＯＤＢＣドライバ受信部１８ｇと、ＧＷ通信ドライバ１８ｈと、制御ロジック１８ｉと、スケジュール・設定パラメータＤＢ１８ｊと、ソフトＰＬＣ１８ｋと、Ｌｏｎ／ＰＬＣドライバ１８ｌと、Ｌｏｎドライバ１８ｍとを備えている。

本実施形態においては、ＧＷ１８より下流のローカル側は、操作器等に分散制御チップが配設されていてＬｏｎＷｏｒｋｓ通信プロトコルを伝送することにより、ツイストペア線１本を用いて直列に各センサや操作器を接続でき、設備コストを安価にすることができる。分散制御装置１８には、図１に示すように、Ｌｏｎの通信手段（４本のＬｏｎ通信ライン１〜４、上位イーサネットケーブル等）、シリアル通信手段（ＲＳ２３２Ｃ、ＲＳ４８５等）を持っており、監視制御対象機器とは全て通信を使用してデータの授受を行う。ＧＷ１８は、通常の小型ＰＣと同じ構成（必要に応じて画面やキーボードやマウスを取り付けるが、通常は本体のみ）であり、プログラムやパラメータの保管・演算処理が可能な構成で、各種通信に対応したプログラムを組み込むことで、各種の機器とシリアル（Ｌｏｎを含む）通信が可能となっている。

本実施形態において、中央監視装置１０とＧＷ１８とは、図２に示すように、中央監視装置１０のリアルタイム系のデータ受信部１０ｂと、ＧＷ１８のリアルタイム送受信部１８ａとがネットワーク伝送路２０，２１を介して接続し、中央監視装置１０とＳＱＬ／ＤＢ１０ｅとは、ネットワーク伝送路２２を介して接続し、ＳＱＬ／ＤＢ１０ｅとＧＷ１８とは、ネットワーク伝送路２３を介して接続している。

ＳＱＬ／ＤＢ１０ｅの汎用リレーショナルデータベースからスケジュールをＯＤＢＣ(Open DataBase Connectivity)フォーマットに変換したスケジュールの内容を受信して、機器の発停制御を行うＬｏｎ対応のコントローラを有する機器には、例えば、空調機（以下、ＡＨＵと称する）、送風機（以下、ＦＡＮと称する）、その他の機器がある。Ｌｏｎローカル機器は、ＧＷ１８からＬｏｎＩＦ１８ｄを介して起動停止、温度設定等が送信される。Ｌｏｎローカル機器は、ＧＷ１８に対してＬｏｎＩＦ１８ｄを介して状態、現在計測値等の状態が送信される。

本実施形態においては、ＧＷ１８とＬｏｎローカル機器とは、Ｌｏｎによる通信が行われ、ＧＷ１８から温度設定等をチャネル１〜４を介してＬｏｎローカル機器へ送信し、Ｌｏｎローカル機器から起動停止状態、現在計測値等の状態をＧＷ１８へ送信する。そして、ＧＷ１８に集められたＬｏｎローカル機器の起動停止状態、現在計測値等の状態がネットワーク伝送路２０を介して中央監視装置１０に送信される。中央監視装置１０では、例外的な緊急を要する設定（火災発生や強制操作等、緊急を要する設定であるリアルタイム系のデータ）のみをネットワーク伝送路２１を介してＧＷ１８へ送信する。その他の非リアルタイム系のデータ（例えば、更新されたスケジュールデータ、更新された設定値データ、更新されたＬｏｎローカル機器のパラメータ、更新されたＧＷの制御パラメータ）は、ＳＱＬ／ＤＢ１０ｅにおいて自動生成される。そして、ＳＱＬ／ＤＢ１０ｅからネットワーク伝送路２３を介してＧＷ１８へ送信される。

本実施形態において、非リアルタイム系のデータには、（１）スケジュールデータ、（２）設定値データ、（３）メンテナンス用設定値データの３つがある。（１）スケジュールデータは、ビル用中央監視装置であれば、空調機器の運転停止（停止、送風運転、冷房運転、暖房運転、予冷運転等の運転条件）のスケジュール、照明の発停（消灯、点灯又は調光による点灯の条件）のスケジュールであり、（２）設定値データは、空調機の温度設定や運転風量設定等のオペレータが使用する設定値であり、（３）メンテナンス用設定値データは、分散制御装置で制御を行う上での初期値（タイムアウト時間、送受信先アドレス設定値等）のメンテナンス担当者が設定する設定値である。

次に、本実施形態によるスケジュール等設定値の処理について説明する。
先ず、スケジュール設定値制御概要について説明する。
（１）Ｌｏｎローカル機器の発停スケジュール設定値の制御
ＳＱＬ／ＤＢ１０ｅでは、テナントグループから各Ｌｏｎローカル機器毎の１週間分の実行機器スケジュールを日替わり後に自動生成する。

ＳＱＬ／ＤＢ１０ｅでは、監視端末１２のオペレータの設定によりテナントグループのスケジュール設定値が変更されたら逐次、ＳＱＬ／ＤＢ１０ｅ上の実行機器スケジュールを更新する。図３に示す監視端末１２のクライアントブラウザー１２ａを介してＳＣＡＤＡ１０ｉの設定画面で設定値を変更すると、ＳＱＬ／ＤＢ１０ｅの［ＧＷ／機器設定値］に変更された値が記録される。

スケジュールや設定値が記載されているデータベースが変更されると、図４に示すように、変更された部分に変更された旨のチェックフラグが記載される（図４の最終列の［更新フラグ］がこれに相当する。）。
また、値を変更したＳＣＡＤＡスケジュール管理アプリケーション１０ｊおよびＳＣＡＤＡ１０ｉは、図３に示すように、変更した機器群を担当するＧＷ１８に値を変更した旨の変更通知のみをリアルタイム系の伝送手段を通じて通知する（構成例の通信方式はＭＯＤＢＵＳで記載）。

通知を受け取ったＧＷ１８は、下位のＬｏｎ機器をリアルタイムで制御しており、この制御が一段落した空いた時間を使用して上位の中央監視装置１０のＧＷ／ＯＤＢＣドライバ１０ｍにデータ要求を通知する。通知を受け取ったＧＷ／ＯＤＢＣドライバ１０ｍは、通知してきたＧＷ１８の［スケジュール出力データ］［ＧＷ／機器設定値］についてデータベースの変化が記載されたものを検索してＧＷ１８に変化したデータのみを送信する。

ＧＷ１８は自分が受信したスケジュールに従って、接続されたＡＨＵ、ＦＡＮ、その他の機器に発停信号（モード込み）を送信する。
変更され、受信した変更済みスケジュールもしくは設定値は、ＧＷ１８内のスケジュール・設定値パラメータ保管ＤＢ１８ｊに記録される。
ＧＷ１８上のソフトＰＬＣ１８ｋの制御ロジック１８ｉは、このスケジュール・設定値パラメータ保管ＤＢ１８ｊに記録された内容に従って発停および所定の設定値での制御を行う。
（２）Ｌｏｎローカル機器の手動操作装置がある場合の手元操作器制限スケジュール設定値の処理
ＳＱＬ／ＤＢ１０ｅのテナントグループのスケジュールから各Ｌｏｎローカル機器毎の１週間分の実行機器スケジュールをＳＱＬ／ＤＢ１０ｅで日替わり後に自動生成する。

前記の○▲証券の場合の例で説明すると、図４に示すように、○▲証券の場合は平日は［９：００〜１８：００］運転、土曜は［９：００〜１２：００］運転、日曜祭日は終日停止という空調運転スケジュールの契約を交わしてテナントとなっているとする。オペレータは、ＳＣＡＤスケジュール管理アプリケーション１０ｊに監視端末１２のクライアントブラウザ１２ａ経由で○▲証券の社長室の定常スケジュール（通常コアスケジュールと称する）の平日、土曜のデータを入力する。これが［スケジュール入力データ］のデータベースに記録される。その他の部屋やエリアも同様に入力を行う。○▲証券にはあらかじめカレンダが定義されているので、入力された曜日毎のコアスケジュールと、○▲証券用カレンダの曜日によって今日から７日間のスケジュールが自動的に演算される。演算された各部屋もしくはエリアのスケジュールは、前記の手順で各機器のスケジュールに自動演算され、［スケジュール出力データ］のデータベースに記録される。通常、この日替わり処理は、午前零時の日替わり以後に計算が開始され、前記の送信手順でＧＷ１８にスケジュールが送信され、ＧＷ１８のスケジュール・設定値パラメータ保管ＤＢ１８ｊには常に最新の７日間のスケジュールデータが保管される（日替り時のバッチ処理と称している）。

システムオペレータによりテナントグループのスケジュールが変更されたら逐次、ＳＱＬ／ＤＢ１０ｅ上の実行機器スケジュールを更新する。
また、値を変更したＳＣＡＤＡスケジュール管理アプリケーション１０ｊおよびＳＣＡＤＡ１０ｉは、図３に示すように、変更した機器群を担当するＧＷ１８に値を変更した旨の変更通知のみをリアルタイム系の伝送手段を通じて通知する（構成例の通信方式はＭＯＤＢＵＳで記載）。

前記の通り、スケジュール設定や設定値を変更するのは、ＳＣＡＤＡ１０ｉおよびＳＡＣＤＡスケジュール管理アプリケーション１０ｊで、スケジュール変更時は図４に示すように［スケジュール出力データ］が変更される。このテーブルは、［管理ＧＷ番号］［機器種別］［機器名称］［変数名称］［曜日］［スケジュール文字列］［更新フラグ］のフィールドで構成される。設定値が変更された場合には、図５に示す［ＧＷ／機器設定値］が変更される。このテーブルは、［管理ＧＷ番号］［機器種別］［機器名称］［変数名称］［設定値］［更新フラグ］で構成される。何れも変更したデータベース上の［更新フラグ］のフィールドに更新したとして［１］を書き込み、その後、当該ＧＷ１８に［変更通知］をリアルタイム系通信手段で通知して、通知を受け取ったＧＷ１８は、下位のＬｏｎ機器をリアルタイムで制御しており、この制御が一段落した空いた時間を使用して上位の中央監視装置１０のＧＷ／ＯＤＢＣドライバ１０ｍにデータ要求を通知する。通知を受け取ったＧＷ／ＯＤＢＣドライバ１０ｍは、通知してきたＧＷ１８の［スケジュール出力データ］［ＧＷ／機器設定値］についてデータベースの変化が記載されたもの（更新フラグが［１］のもの）を検索してＧＷに変化したデータのみ送信する。送信完了した変更済みデータの［更新フラグ］に［０］を書き込む（［０］は変更なしの意味）。

ＧＷ１８は自管理の設定値の何れかが更新されたことを検知し、ＳＱＬ／ＤＢ１０ｅ上の変化した設定値を検索し、変更データ（この場合、実行機器スケジュール設定値）の取得を行う。
前記の通り、ＧＷ１８が受け取るのは、何か変化があったという簡単な変化通知のみを受け取るだけである。ＧＷ１８はリアルタイムで下位のＬｏｎ機器と通信を行って制御するとともに、上位に常に状態および計測値を送信しているので、突然大量のデータを受け取ることにより、リアルタイム系のデータの送信が遅延または止まるのは問題である。従って、スケジュールデータや設定値のような多量のデータを受信する受信手段を通常のリアルタイム系の送受信手段とは別に設けることで、通信の優先順位を変えた通信が可能になる。

ＧＷ１８は自分が受信した手元操作器制限スケジュールにより、設定器に手元制限モードを送信する。
次に、温度設定値等の非リアルタィム系設定値の制御について説明する。
（１）ＧＷ１８内の温度設定等の非リアルタイム系設定値の制御
ＳＱＬ／ＤＢ１０ｅに各種の非リアルタイム系設定値が記録されている。温度のように季節で変化する設定値は、季節切り替り時に季節毎に保持した値から現時点の設定値を自動生成する。

ＡＨＵやＶＡＶのような空調機器の設定温度や設定湿度は、季節毎に異なる。温度設定例で示せば、夏は［２６℃］設定、冬は［２３℃］設定、中間期は［２４．５℃］設定というようになっている。季節の設定はカレンダに設定され、例えば夏は［７月１５日から］とかいうように設定する。また、季節毎の設定温度は、［ＧＷ／機器設定値］の中の温度設定値に各季節毎の温度設定値が一つの機器で３季節若しくは４季節分が登録されていて、それとは別にＧＷ１８に送信する温度設定値が存在する。通常、温度設定を変更すると、ＧＷ１８の送信用温度設定値を更新（この値が送信される）するとともに、季節毎の当該温度設定値の部分を変更する。

前記の［日替り時のバッチ処理］時にカレンダの既設切替日に達した時にこのバッチ処理を行うＳＣＡＤＡスケジュール管理アプリケーション１０ｊで変化日を検出し、変化日を検出すると、全ての機器の当該季節の温度データを検索し、これをＧＷ送信用の温度設定値に書き込み、変化フラグをセットして、当該ＧＷ（結果的に季節温度設定変更のある機器を管理する全てのＧＷ１８）１８に前記の手順で季節設定温度の変更になった温度設定値が送信され、ＧＷ１８に保管されるとともに、その設定値がＬｏｎ機器に送信設定される。

オペレータの設定によりテナントグループ設定値もしくはＬｏｎローカル機器毎の各種非リアルタイム系設定値が変更更新されたら逐次、ＳＱＬ／ＤＢ１０ｅ上の設定値を更新する。
具体的には、ＡＨＵやＶＡＶの設定温度や設定湿度を変更した場合に当てはまる。オペレータが監視端末１２のＳＣＡＤＡ設定入力画面で設定値を変更すると、前記の手順で設定値を変更した機器を管理しているローカル機器を制御管理している当該ＧＷ１８に変更された設定値が受信される。

ＧＷ１８は自管理の設定値の何れかが更新されたことを検知し、ＳＱＬ／ＤＢ１０ｅ上の変化した設定値を検索し、変更データ（この場合、温度設定値等の非リアルタイム系設定値）の取得を行う。
ＧＷ１８は自分が受信した変更された設定を当該設置値の保管メモリに保管するとともに、必要に応じてＡＨＵ、ＦＡＮ、その他の機器に設定値を送信する。

ＧＷ１８には、電源が切れると消えてしまうＲＡＭ変数エリアと、変数（設定値）を保管する不揮発メモリエリア（具体的にはコンパクトフラッシュメモリ）を内蔵しており、スケジュールや温度設定値のように上位が何らかの原因で送受信が途絶えた状態でも自立的に動作するようになっている。また、ＧＷ１８内の変数で保管を要する変数は、同じ変数の前回値と現在値の２つの変数を持っており、設定された設定値は現在値に書き込まれ、前回値と比較して同じ値であれば、その変数に対して特別な処理は行わない。前回値と現在値が異なる場合には設定された設定値を不揮発メモリに書き込むとともに下位のＬｏｎ機器への設定値であれば機器に送信し、前回値に現在値を書き込み、前回値を更新する。この動作により、上位で変更された設定値が下位の機器に確実に設定されるとともに、上位との通信が遮断し、ＧＷ１８の電源が切れて再度電源投入されて再起動した際も、不揮発メモリから設定値を読み出し、ＧＷ１８が停止する前の状態で下位機器の制御を継続することが可能となる。

次に、ＡＨＵの運転スケジュール設定制御について説明する。
（１）ＡＨＵのスケジュール運転
ビル用ＡＨＵでは自動運転（内蔵コントローラで自動判断させる）や強制冷房、強制暖房、強制送風等のモードをスケジュールで制御する必要がある。
以下、この場合の制御方法の例を示す。

ＳＱＬ／ＤＢ１０ｅ作成のＧＷ送信発停スケジュールは、各ＡＨＵ毎に次の意味する文字の１４４個のキャラクタ列で１日の動作を表現する。つまり、１個のキャラクタで１０分間を受け持つ。
０：停止、１：運転（自動モード）、２：冷房モード、３：暖房モード、４：送風モード、５：ウオーミングアップ運転、６：未定義、７：未定義、８：停止再送、９：未定義
スケジュールの送信手段は、前記の通りであるので、それ以外について補足する。

送信するスケジュールは、図４に示すテーブル上および内容で形成され、これが送信される。スケジュール送信テーブルの［スケジュール文字列］に記載される文字情報が上記の［０］〜［９］の文字になる。この例では１０種類であるが、文字であるから［ａ］等の半角のキャラクタであれば何れのものでもよく、要はＧＷ１８上の制御アプリケーションとの決め事で記載することが可能になっている。上記の文字列を使用した場合のスケジュール定義方法とその内容は下記の通りである。
（一段目のスケジュールの説明）
ＡＨＵの運転スケジュールの例
・平日は、
８：３０〜１８：００の運転スケジュール、それ以外は停止。

８：３０〜８：４０まではウォーミングアップ運転で外気を入れない省エネ運転をするスケジュール。
８：４０〜１８：００までは通常の自動運転を行う。
２３：５０〜０：００までは停止再送により再度停止指令を送るスケジュール。
・日曜は、
まったく運転しないスケジュール。

２３：５０〜０：００までは停止再送により再度停止指令を送るスケジュール。
・土曜は、
８：３０〜１２：３０の運転スケジュール、例外は停止。
８：３０〜８：４０まではウォーミングアップ運転で外気を入れない省エネ運転を指示するスケジュール。

８：４０〜１２：３０までは通常の自動運転を行う。
２３：５０〜０：００までは停止再送により再度停止指令を送るスケジュール。
（二段目のスケジュールの説明）
ファンの運転スケジュールの例（常時運転し、日跨ぎのあるビル内便所ファン等のスケジュール入力例）
・平日、休日とも
６：００〜１：００の運転スケジュール、それ以外は停止。

６：００〜１：００までは通常の自動運転を行う。
１：００〜１：１０までは停止再送により再度停止指令を送るスケジュール。
（三段目のスケジュールの説明）
ＡＨＵの手元操作装置の許可制限スケジュールの例
一段目のＡＨＵの運転スケジュールに併せた制限スケジュール例
提示の運転スケジュール外にユーザに発停操作権を提供するスケジュール
・平日は、
８：３０〜１８：００の運転スケジュール中は発停操作のできないモード、それ以外は発停操作可。

・日曜は、
まったく運転しないスケジュール中は、発停操作可能なモード。
・土曜は、
８：３０〜１２：３０の運転スケジュール中は発停操作のできないモード、それ以外は発停操作可。
（２）ＳＱＬでのＡＨＵの作成
ＳＱＬ／ＤＢ１０ｅで自動的に作成されたＬｏｎローカル機器毎のスケジュールが、ＧＷ１８に１週間分保管される。

ＳＱＬ／ＤＢ１０ｅは当日を含む１週間のスケジュールを日替り時に定期的にＧＷ１８に送信する。
テナント申請にて変更されたスケジュールが更新された場合には、逐次ＧＷ１８に送信する。
前記の日替り時のバッチ処理で生成される７日間のスケジュール出力データは、図４に示す形式である。このスケジュール生成から送信にいたる構成および手順は前記の通りである。
（３）スケジュール運転時のＡＨＵとＧＷ１８との送受信概略フローを表１に示す。

表１は、ＧＷ１８内の制御ロジックが受信済みのスケジュールデータを元に動作する手順を記載したものである。
Ｌｏｎローカル機器の手動操作装置がある場合の手元操作器制限スケジュール設定値の制御について説明する。
（１）Ｌｏｎローカル機器の手動操作装置がある場合の手元操作器制限スケジュールの処理
ビル用空調機器では、オペレータが自分で温度設定値や起動停止を行うことのできる手動操作装置を持つものがある。テナントビルの場合、これをどこまで使用するかをスケジュールに合わせて制限することが要求される。

以下、この場合の制御方法の例（図４）を示す。
ＳＱＬ作成のＧＷ送信設定スケジュールは、各ＡＨＵ毎に次の意味する文字の１４４個のキャラクタ列で１日の設定スケジュールを表現する。
０：予約、１：発停・温度・モード・風速許可、２：温度・モード・風速許可、３：風速許可、４：発停・風速許可、５：未定義、６：未定義、７：未定義、８：未定義、９：未定義
ここで、用語の補足説明を行う。

発停は、手元操作器で機器の発停を許可するか否かを表す。
温度は、手元操作器で機器の設定温度を変更を許可するか否かを表す。
モードは、手元操作器で機器のモード（冷房・暖房送風）の変更を許可するか否かを表す。
風速は、手元設定器で機器の風速（強・中・弱風）の変更を許可するか否かを表す。

この項で記載した手元操作装置は、一般的な言い方をすれば家庭用エアコンの［リモコン］と同意語である。ビルのテナントユーザに温度設定や発停ができるようにリモコンがついている場合があるが、ビル管理者側からはこれを使用できたり使用できなくしたりするコントロールが必要になる。コアタイムと呼ばれる基本契約分の空調運転時は、発停はできなくさせる上記の［２］や［３］の設定とし、契約外の時間は［１］や［４］に設定し、残業時間中や休日等に自由に発停させて、その運転時間を課金として集計追加料金としてテナントに請求するように運用する。

スケジュールの設定、保管、ＧＷ１８への送信、ＧＷ１８での処理は通常のスケジュール処理と同じになる。
（２）ＳＱＬでの手元操作器制限スケジュールの作成
ＳＱＬ／ＤＢ１０ｅで自動的に作成されたＬｏｎローカル機器毎のスケジュールが、ＧＷ１８に７日分保管される。

ＳＱＬ／ＤＢ１０ｅは当日を含む１週間のスケジュールを日替り時に定期的にＧＷ１８に送信する。
システムオペレータにて変更されたスケジュールが更新された場合には、逐次ＧＷ１８に送信する。
（３）スケジュール運転時の手元操作器管理機器とＧＷ１８との送受信概略フローを表２に示す。

表２は、手元操作器制限スケジュールを受信した時のＧＷ１８上の制御ロジック１８ｉの実際の動作フローを示した説明である。
温度設定値等の非リアルタィム系設定値の制御について説明する。
（１）温度設定値等の非リアルタィム系設定値のローカルヘの設定
ビル用制御機器には、温度設定値等リアルタィム性を要求されない比較的ゆっくり送信することの許される設定値が存在する。これは、温度設定値やローカル機器の初期設定パラメータ等の設定値である。
（２）ＳＱＬでの非リアルタィム系設定値の作成
システムオペレータやオペレータが各種設定画面で設定した設定値は、ＳＱＬ／ＤＢ１０ｅで保管される。

ＳＱＬ／ＤＢ１０ｅは、Ｌｏｎローカル機器が電源投入等のイニシャル時に全設定値をＧＷ１８に送信する。
オペレータにて変更された設定値が、更新（変更）された場合には、逐次ＧＷ１８に送信する。
なお、［電源投入等のイニシャル時］とは、ＧＷ１８の電源が立ち上がった時、もっと正確に言うとＧＷ１８上のソフトＰＬＣ１８ｋの制御ロジック１８ｉが起動した時のことを指す。ＧＷ（ＧＷのソフトＰＬＣのロジック）１８が停止していた期間にスケジュールや設定値が変更されていることがあるため、制御ロジック１８ｉが起動する前に、まず自分の不揮発メモリから全ての変数を読み出し、当該ＧＷ１８の全ての設定値およびスケジュール設定値について前記の送信要求をＧＷ／ＯＤＢＣドライバ１０ｍに送信して、このＧＷ／ＯＤＢＣドライバ１０ｍから上位の全変数を受信してから制御を開始するようになっている。前記のように何らかの原因で上位が停止若しくは通信遮断して更新データが取得できないことが検出（ある一定時間たってもデータが受信できない状態で判断する）されると、不揮発メモリ上のデータのみでソフトロジックが起動して所期の制御を行うようになっている。
（３）非リアルタィム系設定値のＬｏｎローカル機器とＧＷ１８との送受信概略フローを表３に示す。

表３は、前項の設定値の説明を参照されたい。この表３はそのフローを示している。
スケジュール・設定値等非リアルタィム系設定値類のＧＷ１８とＳＱＬ／ＤＢ１０ｅとのデータ送受信方法について説明する。
スケジュール・設定値等非リアルタィム系設定値類のＧＷ１８とＳＱＬ／ＤＢ１０ｅとのデータ送受信方法を表４に示す。

表４は、前項の設定値・スケジュール更新の説明を参照されたい。この表４はそのフローを示している。
以上のように、本実施形態は、テナントからの操作で、残業時の空調延長を自由に延長運転指示することや温度の設定指示を任意に行えることの可能なビルに適用される。
また、本実施形態によれば、複数の発停停止をスケジュールすることが可能なスケジュールシステムを構築することが可能となる。

また、本実施形態によれば、運転対象の機器に各種の条件で運転することを指示できるスケジュールシステムを構築することが可能となる。
また、本実施形態によれば、スケジュール送信手段と同じ手段で、温度設定値等の非リアルタイム系のデータのローカルヘの送信を実現することが可能となる。
さらに、本実施形態によれば、例えば、１０分単位でルームクーラのスケジュールを送信する場合、１日のスケジュールを１４４文字の文字列で送れば、１０分毎に起動停止を指定できるだけでなく、例えば［０］は停止、［１］は冷暖自動運転、［２］は冷房運転、［３］は暖房運転等各種の運転動作を指示できる。また、予め温度設定値を複数設定しておき、同様に文字列に対応する設定温度にスケジュールで設定温度を変更することも可能である。また、ルームクーラの手元スイッチの操作を許可するようなスケジュールも、予め決めた文字で動作を規定しておけば、手元スイッチの操作制限をスケジューリングできる。また、ＧＷ１８は、今の時刻に相当する文字を確認して動作するため、テナントのオペレータが何時スケジュールを更新しても、文字列を上書きすることで、すぐさまそのスケジュールの状態にし、制御を移行できる。

また、本実施形態によれば、操作指示をキャラクタで送るため、８ビット（最２５５種類）の動作種別を指示可能であり、機器毎に固定長の１４４文字若しくは１４４０文字のキャラクタ列で送信するため、データが非常にコンパクトでローカル制御装置のスケジュール運転制御回路も、現在時刻に相当する位置の文字を見て動作状況を決定するような簡単な構造にすることができる。

また、本実施形態によれば、スケジュールを統合管理するサーバからＧＷ１８に送信するスケジュールデータを、１日を例えば１０分単位の１４４文字（１分単位であれば１４４０文字）の文字列（キャラクタ）で送信する。受信されたスケジュールデータは、ＧＷ１８の不揮発メモリ上に一旦保管される。保管されたスケジュールデータは、１０分（又は１分）毎のキャラクタに意味をもたせていて、下位のＧＷ１８は現在の時刻から相当するキャラクタを選択し、そのキャラクタに従った制御動作を行うようにした。また、スケジュール送信手段と同じ方式で設定値送信も行う。

次に、本実施形態に係る中央監視システムにおけるアナログ入出力タグを用いて行う機器状態記録方法について説明する。
中央監視装置１０の画面から、例えばＡＨＵのモードを含む発停指令を入力する場合、画面上のＡＨＵ起動画面で停止、運転（自動モード）、強制冷房モード、強制暖房モード、強制送風モード、強制ウォーミングアップ運転の６種類のアイテム（設定入力項目）から一つを選択して画面上の実行ボタンを押すと、ＳＣＡＤＡ１０ｉは図６に示すアナログ出力タグ凡例のアナログ値を当該ＡＨＵのアナログ出力タグにセットして、これを下位のＧＷ１８にリアルタイム系の送受信手段で送信する。ＧＷ１８でこのアナログ出力タグの値を受信すると、ＧＷ１８は上位のＳＣＡＤＡ１０ｉから強制操作指令が来たと、内部ソフトＰＬＣ制御回路１８ｋが判断し、これを当該ＡＨＵの入力仕様に合った形式に制御回路が変換を行い、当該ＡＨＵ内コントローラ１９に起動指令および運転モード指令をＬｏｎ通信手段で送信する。例えば、運転（自動運転）のｏｕｔｍｏｄｅ＝［１］を受信すると、まずＡＨＵコントローラ１９に運転モード指令として［ＡＵＴＯモード運転指令］を送信し、その後に［起動指令］を送信する。当該ＡＨＵは受信した運転モード指令の状態で起動する。他のアイテムを選択した場合も同様に下位の末端の機器まで指令が送信される。

指令を受信した例えば末端の機器であるＡＨＵコントローラ１９は、コントローラが制御しているファン（ファンを動かすインバータ）や制御弁類の起動を行い、制御を開始する。制御を開始したＡＨＵコントローラ１９は、上位のＧＷ１８に現在状態を送信する。例えば、正常に起動して冷房状態になったのであれば、［冷房運転状態］を上位のＧＷ１８に送信する。ＧＷ１８は内部のソフトＰＬＣ制御回路１８ｋでこれを一旦取り込み、正常に冷房運転状態で運転していると判断し、下位からの状態信号を上位への信号値に変換して当該ＡＨＵアナログ入力タグに値を書き込み、上位のＳＣＡＤＡ１０ｉにリアルタイム系通信手段を用いて送信する。この例では、下位から正常冷房状態が上がってきたので、ＧＷ１８からＳＣＡＣＤＡ１０ｉへの送信は図７に示すアナログ入力タグ凡例の値からｉｎｍｏｄｅ＝［３］となり、ＳＣＡＤＡ１０ｉは受信したｉｎｍｏｄｅ＝［３］の値を使用して画面の表示、運転履歴の状態記録動作を行う。勿論、起動時に暖房であれば、その状態の値が上位に送信されるし、自動運転中に冷房から暖房に切り替わった際は、イベント変化が生じたとして、変化時点で逐次状態変化の値を上位に送信する。上位のＳＣＡＣＤＡ１０ｉはその変化に応じて画面の表示、運転履歴の状態記録動作を逐次行う。

ここで、図６、図７に示す事項について説明する。
起動指令画面出力コード内訳は、ＳＣＡＤＡ１０ｉの画面に表示される。入力項目は、例えば停止、運転（自動モード）、強制冷房モード、強制暖房モード、強制送風モード、強制ウオーミングアップ運転などが設定される。アナログ出力タグ名は、ｏｕｔｏｍｏｄｅが割り当てられる。上位が送信する値は、例えば、０，１，２，３，４，５のように決められる。

監視画面・履歴記録入力コード内訳は、ＳＣＡＤＡ１０ｉの画面に表示される。状態項目は、例えば自動運転状態、暖房運転状態、暖房ウオーミングアップ状態、冷房運転状態、冷房ウオーミングアップ状態、停止状態、送風運転状態などの運転状態と、起動停止不良（いわゆる操作不良）、状態不一致、機器故障（いわゆる故障）、ノード不良（通信不可状態）（いわゆる通信異常）などの警報状態とが設定される。アナログ入力タグ名は、ｉｎｍｏｄｅが割り当てられる。下位が送信される値は、例えば、０，１，２，３，４，５，６，７，８，９，１００〜１０９，２００〜２０９，３００〜３０９，４００〜４０９のように決められる。

以上は、正常に起動した場合について説明したが、次に、正常に動かなかった場合について説明する。
上位のＳＣＡＤＡ１０ｉから下位のＧＷ１８が起動指令を受けた時、前記のように末端のＡＨＵコントローラ１９に対して起動指令とモード指令をＬｏｎ経由で送信するが、ＧＷ１８に予め設定したタイマ値の時間を超えてもＡＨＵコントローラ１９から予期した状態変化の返信が来ない場合は、ＧＷ１８内部のソフトＰＬＣ制御回路１９がこれを検出し、［操作不良］と定義する。この時、ＧＷ１８上のソフトＰＬＣ制御回路１９は、下位のＡＨＵの直前の状態値に１００を加えた値を演算し、その値を当該ＡＨＵのアナログ入力タグにセットして、上位のＳＣＡＤＡ１０ｉに送信する。例えば、直前の状態値が停止状態の［６］であったなら、ＧＷ１８からＳＣＡＣＤＡ１０ｉへの送信は、図７に示すように、アナログ入力タグ凡例の値から、直前の状態値に１００を加えた値ｉｎｍｏｄｅ＝［１０６］（１００＋停止：６）となる。ＳＣＡＤＡ１０ｉは、受信したｉｎｍｏｄｅ＝［１０６］の値が１００以上であったことから、状態が警報だと判断し、これを画面に表示するとともに、運転・警報履歴の状態警報記録動作を行う。

前記の例のように、一旦運転がかかり、状態としてｉｎｍｏｄｅ＝［３］が来た後、ＡＨＵが何らかの原因で停止して、その変化の状態値としてｉｎｍｏｄｅ＝［６］（停止）をＧＷ１８がＡＨＵコントローラ１９から受信した場合は、予め設定されたタイマ値の間に元の運転状態に戻らない時、状態不一致としてＧＷ１８内ソフトＰＬＣ制御回路１８ｋがそれを検出して［状態不一致］と定義する。この時、ＧＷ１８上のソフトＰＬＣ制御回路１８ｋは、下位のＡＨＵの直前の状態値に２００を加えた値を演算し、その値を当該ＡＨＵのアナログ入力タグにセットして、上位のＳＣＡＤＡ１０ｉに送信する。例えば、直前の状態値が冷房状態であったなら、ＧＷ１８からＳＣＡＣＤＡ１０ｉへの送信は、表５に示すように、アナログ入力タグ凡例の値からｉｎｍｏｄｅ＝［２０３］（２００＋冷房：３）となる。ＳＣＡＤＡ１０ｉは受信したｉｎｍｏｄｅ＝［２０３］の値が１００以上であったことから、状態が警報だと判断し、これを画面の表示するとともに、運転・警報履歴の状態警報記録動作を行う。

ＡＨＵコントローラ１９に故障が発生したことを示す下位からの送信がＧＷ１８に受信され、ＧＷ１８内のソフトＰＬＣ制御回路１８ｋがＡＨＵが故障したと検出した場合には、下位のＡＨＵの直前の状態値に３００を加えた値を演算し、その値を当該ＡＨＵのアナログ入力タグにセットして、上位のＳＣＡＤＡ１０ｉに送信する。例えば、直前の状態値が冷房状態であったなら、ＧＷ１８からＳＣＡＣＤＡ１０ｉへの送信は、図７に示すように、アナログ入力タグ凡例の値からｉｎｍｏｄｅ＝［３０３］（３００＋冷房：３）となる。ＳＣＡＤＡ１０ｉは、受信したｉｎｍｏｄｅ＝［３０３］の値が１００以上であったことから、状態が警報だと判断し、これを画面の表示するとともに、運転・警報履歴の状態警報記録動作を行う。

ＡＨＵコントローラ１９との通信が何らかの原因で遮断され、定期的に行っている下位機器との通信状態のチャック処理でＡＨＵコントローラ１９との通信障害が発生したことをＧＷ１８内のソフトＰＬＣ制御回路１８ｋが検出した場合には、予め設定された時間内に通信が復旧しない時、ＧＷ１８内のソフトＰＬＣ制御回路１８ｋはＡＨＵコントローラ１９との通信障害発生と定義し、下位のＡＨＵの前回の状態に４００を加えた値を演算し、その値を当該ＡＨＵのアナログ入力タグにセットして、上位のＳＣＡＤＡ１０ｉに送信する。例えば、直前の状態値が冷房状態であったなら、ＧＷ１８からＳＣＡＣＤＡ１０ｉへの送信は、図７に示すように、アナログ入力タグ凡例の値からｉｎｍｏｄｅ＝［４０３］（４００＋冷房：３）となる。ＳＣＡＤＡ１０ｉは、受信したｉｎｍｏｄｅ＝［４０３］の値が１００以上であったことから、状態が警報だと判断し、これを画面の表示するとともに、運転・警報履歴の状態警報記録動作を行う。

ＳＣＡＤＡ１０ｉの画面の逐次変化する機器状態を表示するグラフィックシンボルは、各グラフィックシンボルにタグを割り付て、そのタグの値がどうなったら何の色を表示するかを予め設定してある。今回の例のＡＨＵのグラフィックシンボルにはｉｎｍｏｄｅのみを割り付ければよい。最も簡単な表示色設定の例を示せば、［６］ならば停止色の緑色、［１００］未満で［６］以外であれば正常な何らかのモードの運転として運転色の赤色、［１００］以上は何らかの異常であるので警報色の橙色、という３種類の定義で状態を表現することができる。また、より細かな表示が要望されるのであれば、前記の条件式を狭めて夫々に表示色の定義をすることで、各種状態の表示設定を提供できる。要は設定を狭めればそれだけ設定作業時間のコストが必要で、状況に応じて同じ機能のもとで設定の変更のみで対応できる利点も持たせている。

履歴記録を行う設定も、前記の例でいえば、ｉｎｍｏｄｅが変化したら、運転履歴データに記録するとともに、その値も同時に記録するようにする。ｉｎｍｏｄｅの値が［１００］以上ならば、警報として警報履歴データに記録するとともに、ｉｎｍｏｄｅの値を同時に記録する。一番簡易な記録方法をとれば、［○月▲日■時△分○秒：ＡＨＵ機器状態 １０３］と運転履歴データと警報履歴データとに記録される。オペレータは機器状態の値から、どのような状態かを確認できる。さらに詳しく履歴に記録したければ、ＳＣＡＤＡ１０ｉ内の履歴記載処理設定部分のディスクリプション（説明文章）記載定義体に［３］＝［冷房運転］と設定しておけば、運転履歴であれば、［○月▲日■時△分○秒：ＡＨＵ機器状態 冷房運転 ３］という文字列が自動生成されて運転履歴に記録される。同様に［１００以上］＝［故障］と定義しておけば、前記の最も簡易な記載内容は［○月▲日■時△分○秒：ＡＨＵ機器状態 故障 １０３］と記載される。同様に設定する値の範囲を狭めて夫々の追記する文字定義を行うことにより、細かなわかりやすい履歴記録を行うことも簡単に実現することができる。要は設定を狭めればそれだけ設定作業時間のコストが必要で、状況に応じて同じ機能のもとで設定の変更のみで対応できる利点も持たせている。

上記の例は、全て中央監視装置１０の画面からの強制操作指令の例で示したが、前述したスケジュール運転の場合もまったく同一で、スケジュールに記載された前記のモードの値により分散制御装置は同様の動きが行われるようになっている。スケジュールシステムが、１０分単位のキャラクタ、即ちアナログ数字で機器の動作指示をスケジュールできるようにしているが、スケジュールに記載されている数字は強制操作指令で使用する数値と同じになっている。

強制運転指令とスケジュール運転との関係は、基本的に後押し優先のルールとなっている。スケジュール運転中に強制運転指令がＧＷ１８に受信されれば、スケジュールより後押しとして現在スケジュール指示の動作と異なれば、強制運転指令に切り替わる。また、強制運転指令の指令運転内容で運転中であっても、設定されたスケジュールが変化した時をスケジュールの新たな指示と解して、後押しで今度はスケジュール設定に従った動きとなる。また、分散制御装置の設定である指定時間若しくはあるモードの指定の時は、強制運転状態であっても、スケジュールの運転モード指令に切替えるという機能も持たせてある。

本実施形態では、下記のような効果を奏することができる。
過去にもアナログのタグにするようなものもあったが、これはアナログ（通常１６ｂｉｔ）の各ビットにデジタル信号を割り付たものである。この方式であると、確かに複数のデジタル信号を１つのタグで扱えるが、一般的なＳＣＡＤＡではビット内のある一つのビットに対応した画面表示制御や各種履歴記録制御には使用できない。従って、ＳＣＡＤＡ内部では、各ビットを別々のタグに内部で再分割した後に、画面表示や各種履歴記録制御に用いるため、内部タグの数はまったく減らない。

本実施形態によると、タグの点数は、劇的に少なくできる。デジタル入出力タグを使用する従来の方式であると、空調機制御単位エリア当たりＡＨＵ（１台）＋ＶＡＶ（１６台）の指令状態警報タグ数は２８９点（１７タグ×１７台）、ＰＡＣの１８台分で３０６点（１７タグ×１８台）、計５９５点で、空調機制御単位エリアがフロアで４エリアあり、それが３０フロアあったとすると、機器として４，２００台（（１７台＋１８台）×４エリア×３０フロア）で、この機器の指令状態警報タグ数だけを単純計算すると、７１，４００点（（２８９＋３０６）×４エリア×３０フロア）のタグ数であった。

これが、本実施形態によると、空調機制御単位エリア当たりＡＨＵ（１台）＋ＶＡＶ（１６台）の指令状態警報タグ数は３４点（２タグ×１７台）、ＰＡＣの１８台分で３６点（２タグ×１８台）、計７０点で、空調機制御単位エリアがフロアで４エリアありそれが３０フロアあったとすると、機器として４，２００台（（１７台＋１８台）×４エリア×３０フロア）でこの機器の指令状態警報タグ数だけを単純計算すると、８，４００点（（３４＋３６）×４エリア×３０フロア）のタグ数となり、約１／１０程度にすることが可能になる。

中央監視装置１０の画面の状態表示に関しては、グラフィックシンボルに対して１つのタグを定義するだけでよく、表示色の変更もグラフィックシンボルの定義体のタグの値の変化の定義を自在に変えることで、簡単なものから詳細なものまでを同じシステムで定義体のみの変更で容易に実現できる仕組みを提供できる。
運転履歴や警報履歴も同様に状態タグの値を記載することで、例え一番簡易な記載方法であっても、内部定義されたそのアナログ値を見るだけで、オペレータは機器の状態を容易に確認できる。警報値については、必ず直前の機器運転状態値に計表状態の値を足し込むため、警報状態の値を見るだけで、警報発生した直前の機器状態の情報をオペレータに提供でき、警報要因特定のために、警報履歴と運転履歴を夫々調べる必要もなく、原因の推定を行う手助けが可能となる。

履歴にこのアナログ値を記録することで、その値を利用して別途設けた定義体により自在にディスクリプションを生成することも可能で、その内容も簡易なものから詳細なものまで初期設定で自在に選ぶことが可能な手段を提供できる。
この値をリアルタイム系のデータとして中央監視装置１０のデータベースに他のデータと併せ同時に書くことで、例えば運転履歴に常に機器の状態変化が記載されるため、通常中央監視装置に持っている機器運転時間の累積や運転回数の累積記録表示機能を、この運転履歴を日一回のバッチ処理で機器毎の運転状態から累積時間の演算や累積回数の演算を行うことが容易にできる。

次に、本実施形態における下位から上位への状態通知方法についてさらに説明する。
ここでは、ＡＨＵコントローラ１９の状態通知方法について説明する。
ＡＨＵコントローラ１９は、ＡＨＵを制御するコントローラで、ＡＨＵコントローラ１９の下にはファンを動かすインバータ若しくはマグネット、ＡＨＵの加熱・冷却・加湿を行うバルブ、外気風量を調節するダンパが接続され、ＡＨＵコントローラ１９の演算回路でこれらの機器を起動・停止若しくは制御している。

ＡＨＵコントローラ１９は、運転・停止状態を示す信号［０＝停止／１＝運転］（以下、ＧＷ１８で受信した時の信号変数名ｎｖｏＡＨＵｓｔａｔｅと略）、冷房・暖房状態を示す信号［０＝冷房／１＝暖房］（以下、ＧＷ１８で受信した時の信号変数名ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅと略）、ウォーミングアップ状態を示す信号［０＝非動作／１＝ウォーミングアップ状態］（以下、ＧＷ１８で受信した時の信号変数名ｎｖｏＷｕｐｓｔａｔｅと略）をＧＷ１８に送信するような信号を持っている。なお、何れのＧＷ１８で受信した時の信号変数名の変数定義は、ビットデータを示すデジタル値である。

ファンを動かすインバータ若しくはマグネットは、動力盤にあってＡＨＵコントローラ１９からの指示で起動停止され、インバータ若しくはマグネットからファンを動かしたことを示す信号［０＝停止／１＝運転］（以下、ＧＷ１８で受信した時の信号変数名ｎｖｏＩＮＶｓｔａｔｅと略）、インバータが故障した若しくはマグネットがトリップしたということを示す信号［０＝正常／１＝故障］（以下、ＧＷ１８で受信した時の信号変数名ｎｖｏＩＮＶａｌａｒｍと略）をＧＷ１８に送信するような信号を持っている。なお、何れのＧＷ１８で受信した時の信号変数名の変数定義は、ビットデータを示すデジタル値である。

ＡＨＵコントローラ１９がＡＨＵを起動する時、通常起動であればＡＨＵコントローラ１９内部の予めプログラムされた手順に従ってＡＨＵコントローラ１９自体で、インバータ若しくはマグネットにファンの起動をかけ、接続されているＡＨＵの加熱・冷却用バルブ、外気風量調節用ダンパに制御信号を送信してこれらの制御を開始する。
ＡＨＵコントローラ１９がＡＨＵを正常起動すると、前記の運転・停止状態を示す信号［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］、内部の演算で暖房が選択されていれば、冷房・暖房状態を示す信号［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝１＝暖房］、通常運転なのでウォーミングアップ状態を示す信号［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］の３種類の信号がＧＷ１８に送信される。また、インバータ若しくはマグネットが正常動作してファンが運転を開始すると、インバータ若しくはマグネットからファンを動かしたことを示す信号［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］、正常運転したことからインバータが故障した若しくはマグネットがトリップしたということを示す信号［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］の２種の信号が、ＧＷ１８とＡＨＵコントローラ１９に送信される。

ＡＨＵコントローラ１９とインバータ若しくはマグネットから合計５種類の信号をＧＷ１８は受信する。この通信をＧＷ１８の下位通信ドライバ１８ｈが受信すると、ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋの前記した所定の変数名に夫々書き込む。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋはソフトＰＬＣ制御回路１８ｋ内部にあらかじめ記載された制御回路（制御プログラム）に従って、５つの信号変数からＡＨＵの状態を示す１つの内部１６ビットアナログ変数（以下、同変数名をｉｇＭａｃｈｉｎｅＳｔａｔｕｓと略）に当該変換後のアナログ値を収納する。この場合、通常運転で正常に動作したのでＧＷ１８への信号入力は［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝１＝暖房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］となり、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝１＝暖房正常運転状態］となる。

次に、各種のＡＨＵの状態の時のＧＷ１８が出力する状態出力信号アナログ値変数［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ］の変換方法について、図８に基づいて説明する。
ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３＝冷房正常運転状態］となる。

ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝１＝ウォーミングアップ動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝５＝冷房ウォーミングアップ正常運転状態］となる。

ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝１＝暖房］［ｎｖｏＷｕｐｓｔａｔｅ＝１＝ウォーミングアップ動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝２＝暖房ウォーミングアップ正常運転状態］となる。

ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝１＝暖房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷが出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝１＝暖房正常運転状態］となる。

ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝０＝停止］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝０＝停止］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝６＝正常停止状態］となる。

ＧＷ１８がＡＨＵコントローラ１９に対してＡＨＵ停止状態から起動指令を出力したにもかかわらず、所定のある一定時間後になっても、ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝０＝停止］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝０＝停止］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８の起動指令が失敗したとして、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝１０６＝起動不良状態］となる。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが判断し、現在状態の［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝６＝停止状態］の［６］に起動停止不良を示す１００を加えた値を状態出力信号アナログ値として出力するように動作する。これにより、起動指令を出しているのに、現在は止まっているということが数値より判断できる。

ＧＷ１８がＡＨＵコントローラ１９に対してＡＨＵ運転状態で停止指令を出力したにもかかわらず、所定のある一定時間後になっても、ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝運転］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＧＷ１８の起動指令が失敗したとして、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝１０３＝停止不良状態］となる。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが判断し、現在状態の［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３＝冷房運転状態］の［３］に起動停止不良を示す１００を加えた値を状態出力信号アナログ値として出力するように動作する。これにより、停止指令を出しているのに、現在は動いたままになっているということが数値より判断ができる。

ＧＷ１８がＡＨＵコントローラ１９に対してＡＨＵ停止状態から起動指令を出力し、一旦運転状態になった後、ＧＷ１８から指令を出力していないのにもかかわらず、その後に所定のある一定時間後になっても、ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝０＝停止］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝０＝停止］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＡＨＵの運転状態がＧＷ１８の指令と異なるということで、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝２０６＝状態不一致］となる。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが判断し、現在状態の［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝６＝停止状態］の［６］に状態不一致を示す２００を加えた値を状態出力信号アナログ値として出力するように動作する。これにより、起動指令を出して一旦は動いたが、現在はＧＷ１８の指示に反して止まっているということが数値より判断できる。

ＧＷ１８がＡＨＵコントローラ１９に対してＡＨＵ運転状態から停止指令を出力し、一旦停止状態になった後、ＧＷ１８から指令を出力していないのにもかかわらず、その後に所定のある一定時間後になっても、ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝１＝停止］［ｎｖｏＩＮＶａｌａｒｍ＝０＝正常］ならば、ＡＨＵの運転状態がＧＷ１８の指令と異なるということで、ＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝２０３＝状態不一致］となる。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが判断し、現在状態の［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３＝冷房運転状態］の［３］に状態不一致を示す２００を加えた値を状態出力信号アナログ値として出力するように動作する。これにより、停止指令を出して一旦は停止したが、現在はＧＷ１８の指示に反して動き出しているということが数値より判断できる。

ＧＷ１８への信号入力が［ｎｖｏＡＨＵｓｔａｔｅ＝１＝運転］［ｎｖｏＣｏｏｌＨｅａｔｓｔａｔｅ＝０＝冷房］［ｎｖｏＷｕｐｓｔａｔｅ＝０＝非動作］［ｎｖｏＩＮＶｓｔａｔｅ＝０＝停止］［ｎｖｏＩＮＶａｌａｒｍ＝１＝異常］ならば、ＧＷが出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３０３＝ＡＨＵ故障状態］となる。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが受信したインバータ若しくはマグネットの状態信号変数から判断し、現在状態の［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３＝冷房運転状態］の［３］に故障を示す３００を加えた値を状態出力信号アナログ値として出力するように動作する。この値からＡＨＵコントローラ１９は動こうとしているのに、インバータ若しくはマグネットのＡＨＵ故障要因の一つが故障を示し、ＡＨＵコントローラ１９が運転状態で故障しているということが数値より判断できる。

ＡＨＵコントローラ１９やインバータ若しくはマグネットの状態を取り込む変換ユニットとの通信に支障をきたし、ある一定時間そのノードとの通信が不可能になったことを検出した場合には、ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋのプログラムが判断し、例えば直前の状態が［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝３＝冷房運転状態］であったなら、状態値［３］に通信不良を示す４００を加えた値を状態出力信号アナログ値として出力するように動作する。この場合のＧＷ１８が出力する状態出力信号アナログ値変数は［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ＝４０３＝ＡＨＵ通信異常状態］となる。この値からＡＨＵ運転状態のままＡＨＵコントローラ１９又はインバータ若しくはマグネット状態を変換する変換ユニットとの通信が遮断されたことが数値より判断できる。

上記例は、ＡＨＵコントローラ１９からの信号が全てデジタル値で出力される場合で説明したが、高度なＡＨＵコントローラ（例えば、Ｌｏｎ通信対応ＡＨＵコントローラ）等の場合には、運転・停止状態はデジタル値で送信されるが、冷房やウォーミングアップ等の運転モード状態をＬｏｎプロトコルに準拠したアナログ値で出力するものもあり、ＧＷ１８ではこの値を取り込み故障要因時の１００，２００，３００，４００の値を加えて全ての状態を表現するようにソフトＰＬＣ制御回路１８ｋ内部のプログラムが動作するようになっている。

大規模な監視装置の場合、百数十台のＡＨＵがあり各種のＡＨＵコントローラ１９が混在し、コントローラも上記の２種の例以外のものも存在する。ＧＷ１８内部のソフトＰＬＣ制御回路１８ｋは、通信対象のＡＨＵの出力信号の種別でいくつかにパターン化された内部の処理プログラムが用意されており、該当する種別のプログラムでＧＷ１８から上位に出力する状態出力信号アナログ値変数［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ］という一定の変数に変換することを特徴としている。本実施形態では［ｉｇＭａｃｈｉｎｅＳｔａｔｕｓ］の値の定義をＬｏｎの値に準拠して定義している。これにより各種の信号出力形態を持つＡＨＵおよびその周辺機器用の制御コントローラからの信号を１種類の変数で表現ができるようにしている。

次に、上位から下位への運転指令通知方法について説明する。
ＳＣＡＤＡ１０ｉの画面の運転指令入力画面で入力されると、中央監視装置１０内のクライアント制御部１０ｆを介してＳＣＡＤＡ１０ｉにＳＣＡＤＡ１０ｉ内アナログタグ変数にアナログ値を書き込む。書き込まれるアナログ値は、所定の運転指令に併せて予め決められた値が入力される。例を示せば、画面上のＡＨＵ自動運転起動ボタンを押し、実行すると当該ボタンに定義されたＡＨＵ運転指令用アナログタグに自動運転の［１］が設定される動作となる。入力された値は、リアルタイム送信手段でＧＷ１８に送信される。送信された値は、運転指令を受けるＧＷ１８の１６ｂｉｔアナログ変数（以下、ｉｇＦｏｒｃｅＣｏｍｍａｎｄと略）に取り込まれる。

ＧＷ１８が受信した運転指令の［ｉｇＦｏｒｃｅＣｏｍｍａｎｄ］変数は、ＧＷ１８内のソフトＰＬＣ制御回路１８ｋのプログラム内に記載された送信先コントローラの指令方法に従って値が変換され、コントローラに送信される。例えば、Ｌｏｎ通信対応のＡＨＵコントローラ１９であれば、受信した［ｉｇＦｏｒｃｅＣｏｍｍａｎｄ］変数の値を、図９、図１０に示すように、運転指令変数内容で示したようにソフトＰＬＣ制御回路１８ｋのプログラムで変換してＡＨＵコントローラ１９に指令を送信するように動作する。

ここで、下位のノードからＧＷ１８に送信される信号は、（ａ）内部ソフトＰＬＣ制御回路１８ｋで制御に用いずそのまま上位に送信されるものと、（ｂ）一旦内部ソフトＰＬＣ制御回路１８ｋに取り込み制御回路で使用した後、上位に送信するとともに別な値（制御指示値）として出力されるものがある。
室内にある複数の温度センサで室内を空調するＡＨＵの例で説明する。室内の温度計は複数あって、各温度計はＬｏｎ通信で温度を外部に送信する。温度計１〜３の３台があって室内各所の温度を測定していて、その出力温度値ｎｖｏＴｅｍｐ１〜ｎｖｏＴｅｍｐ３の温度の内、ｎｖｏＴｅｍｐ１が室内代表温度として室内制御用の温度の場合、ｎｖｏＴｅｍｐ２，ｎｖｏＴｅｍｐ３は内部ソフトＰＬＣ制御回路１８ｋを介さず上位の中央監視装置１０に送信する（前記（ａ）の方式）。ＧＷ１８はｎｖｏＴｅｍｐ１を一旦内部ソフトＰＬＣ制御回路１８ｋを取り込み、ＰＬＣ制御回路１８ｋに記載された制御回路で演算を行い、ＡＨＵの給気目標温度ｎｖｉＳＡｓｅｔＴｅｍｐを演算し、ＡＨＵにｎｖｉＳＡｓｅｔＴｅｍｐを送信するとともに上位のＳＣＡＤＡ１０ｉにｎｖｏＴｅｍｐ１とｎｖｉＳＡｓｅｔＴｅｍｐを送信する。

ＧＷ１８からの送信は、受信ドライバ１０ｇを介してＳＣＡＤＡ１０ｉ内のタグに受け取られる。中央監視装置１０は複数のＧＷ１８を相手にするため、送信された変数の名称にＧＷ識別用のＧＷ名を付けたタグとして取り込む。例えば、前記の温度を送信してきたＧＷ１８が、例えばＧＷ１００１という名称であれば、ＧＷ１００１ｎｖｏＴｅｍｐ１〜ＧＷ１００１ｎｖｏＴｅｍｐ３、ＧＷ１００１ｎｖｉＳＡｓｅｔＴｅｍｐという名称のタグに値をセットする。タグの値は定期的にＳＱＬ／ＤＢ１０ｅにデータとして記録される。

ＳＣＡＤＡ１０ｉでは、タグの値が更新されると、画面データの表示部分に予め定義されているタグの表示値は自動的にタグの値が変化することで表示される値が変化する。クライアント制御部１０ｆを介して画面を参照しているクライアント１２の画面上はタグの値の変化に応じて表示される温度値が変化する。温度のようなアナログ値を表示するタグの属性には上限値を定義することが可能であり、上限値を超えると表示部のアイコンの表示色を変化させることが可能な仕組みとなっている。例えば、ＧＷ１００１ｎｖｏＴｅｍｐ１〜ＧＷ１００１ｎｖｏＴｅｍｐ３の上限値が２８℃、ＧＷ１００１ｎｖｉＳＡｓｅｔＴｅｍｐの上限値が３０℃であれば、ＧＷ１００１ｎｖｏＴｅｍｐ１〜ＧＷ１００１ｎｖｏＴｅｍｐ３の値が２８℃を超えると、同温度値の表示アイコン部分が警報色のオレンジ色に変化する。また、ＧＷ１００１ｎｖｉＳＡｓｅｔＴｅｍｐの値が３０℃を超えると同様に警報色に変化する。

なお、上記実施形態では、ＳＱＬ／ＤＢ１０ｅを中央監視装置１０に内蔵した場合について説明したが、本発明ではこれに限らず、ＳＱＬ／ＤＢ１０ｅと中央監視装置１０とを分離しても良い。また、１台の中央監視装置１０について説明したが、中央監視装置１０は複数であってもの良い。また、監視端末１２からスケジュール変更を行う場合について説明したが、中央監視装置１０の入力手段からスケジュール変更を行っても良い。また、入力手段とＳＱＬ／ＤＢ１０ｅとを中央監視装置１０に設けても良い。

本発明に係るビル用中央監視システムを適用した機器構成を示す図である。 図１におけるデータ送受信系統図である。 図１におけるソフトウエア構成図である。 スケジュールデータベースの一例を示す図である。 設定値の一例を示す図である。 アナログ出力値の一例を示す図である。 アナログ入力値の一例を示す図である。 状態変数内容の一例を示す図である。 ＳＣＡＤＡからＧＥへの運転指令変数内容の一例を示す図である。 ＧＷから下位ノードへの変換後の指令内容の一例を示す図である。

符号の説明

１０ 中央監視装置
１０ａ 監視・設定画面表示部
１０ｂ リアルタイム系のデータ受信部
１０ｃ リアルタイム系のデータ送信部
１０ｄ データベースインターフェース（データベースＩＦ）
１０ｅ ＳＱＬ／ＤＢ
１０ｆ クライアント制御部
１０ｇ 受信ドライバ
１０ｈ 送信ドライバ
１０ｉ ＳＣＡＤＡ
１０ｊ ＳＣＡＤＡスケジュール管理アップリケーション
１０ｋ ＳＣＡＤＡ／ＯＤＢＣドライバ
１０ｍ ＧＷ／ＯＤＢＣドライバ
１１ イーサネット
１２ 監視端末
１４ ルータＨＵＢ（ルータハブ）
１７ ＳＷ−ＨＵＢ（イーサネット通信を行うハブ）
１８ ＧＷ
１８ａ リアルタイム送受信部
１８ｂ データベースインターフェース（データベースＩＦ）
１８ｃ 制御回路
１８ｄ Ｌｏｎインターフェース（ＬｏｎＩＦ）
１８ｅ ＭＯＤＢＵＳ送信部
１８ｆ ＭＯＤＢＵＳ受信部
１８ｇ ＧＷ／ＯＤＢＣドライバ受信部
１８ｈ ＧＷ通信ドライバ
１８ｉ 制御ロジック
１８ｊ スケジュール・設定パラメータＤＢ
１８ｋ ソフトＰＬＣ
１８ｌ Ｌｏｎ／ＰＬＣドライバ
１８ｍ Ｌｏｎドライバ
１９ ＡＨＵコントローラ（空調機器制御装置）
２０ バルブ
２１ センサ
２２ ＶＡＶ（可変風量制御装置）
２３ ＰＡＣ（個別ヒートポンプ式エアコン）
２４ ＤＩＯ（汎用接点入出力装置（各種警報等の接点入力、出力に使用）

Claims (9)

1. 中央監視装置と、
   前記中央監視装置にネットワークを介して連絡する分散制御装置と、
   前記分散制御装置にネットワークを介して連絡するコントローラと、
   前記コントローラに接続された下位制御機器と
   を備え、
   前記中央監視装置と前記分散制御装置とは、リアルタイム系のデータを送受信する手段を設けて成るビル用中央監視システムにおいて、
   前記分散制御装置は、前記コントローラから受信する前記下位制御機器の状態値をアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信する
   ことを特徴とするビル用中央監視システム。
2. 中央監視装置と、
   前記中央監視装置にネットワークを介して連絡する分散制御装置と、
   前記分散制御装置にネットワークを介して連絡するコントローラと、
   前記コントローラに接続された下位制御機器と、
   前記中央監視装置と前記分散制御装置とに設けたリアルタイム系のデータを送受信する手段と、
   前記中央監視装置に設けられ、前記中央監視装置から前記分散制御装置に非リアルタイム系のデータを送信する手段と、
   前記非リアルタイム系のデータを送信する部分に設けた汎用リレーショナルデータベースを持つサーバと、
   前記分散制御装置に設けた前記非リアルタイム系のデータを受信する手段と
   を備え、
   前記非リアルタイム系の送信する手段および受信する手段は、前記リアルタイム系の送受信に遅延を生じさせずにその合間を縫って前記サーバから非リアルタイム系のデータの送受信を行い、
   前記分散制御装置は、前記コントローラから受信する前記下位制御機器の状態値をアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信する
   ことを特徴とするビル用中央監視システム。
3. 請求項１または請求項２記載のビル用中央監視システムにおいて、
   前記分散制御装置は、受信した前記下位制御機器の状態値を予め内部定義された所定の状態を示す前記アナログ値に変換する処理部を有する
   ことを特徴とするビル用中央監視システム。
4. 請求項１または請求項２記載のビル用中央監視システムにおいて、
   前記アナログ値は、運転状態と警報状態とを記載する状態項目と、アナログ入力タグ名と、前記運転状態と前記警報状態とに対応する送信する値とを有する
   ことを特徴とするビル用中央監視システム。
5. 請求項２記載のビル用中央監視システムにおいて、
   前記汎用リレーショナルデータベースには、前記中央監視装置と前記分散制御装置との通信に使用する変数定義のマスターデータベースが保管され、
   前記マスターデータベースには、全ての前記分散制御装置毎の通信に使用する変数の定義があり、前記各変数毎にリアルタイム系の上位通信に使用するもの、リアルタイム系の下位通信に使用するもの、非リアルタイム系の下位通信に使用するものの３種類の通信手段および通信方向が判別可能なフィールド定義があり、
   前記中央監視装置は、前記フィールド定義を元に前記分散制御装置との通信を行い、
   前記分散制御装置は、前記分散制御装置を設置して前記中央監視装置と接続する時、若しくは、送受信変数内容に変更が生じた時、各変数毎の送受信方法が記載されている前記マスターデータベースから自局の分の変数定義のみを取り込んで保管し、これを用いて前記中央監視装置との通信を行う
   ことを特徴とするビル用中央監視システム。
6. 請求項１ないし請求項５の何れかに記載のビル用中央監視システムにおいて、
   前記リアルタイム系のデータを送受信する手段では、前記分散制御装置から各種機器状態、計測値、警報が前記中央監視装置へ送信され、前記中央監視装置からサーバ変更通知、火災警報通知、停電発生通知が前記分散制御装置へ送信され、
   前記非リアルタイム系のデータを送信および受信する手段では、前記中央監視装置からリアルタイム系のデータとして前記分散制御装置へ送信後に前記分散制御装置から送信される送信要求に対し、前記サーバから要求スケジュール返信、要求更新済み設定値返信が前記分散制御装置へ送信される
   ことを特徴とするビル用中央監視システム。
7. 請求項２ないし請求項６の何れかに記載のビル用中央監視システムにおいて、
   前記非リアルタイム系のデータは、（１）スケジュールデータ、（２）設定値データ、（３）メンテナンス用設定値データである
   ことを特徴とするビル用中央監視システム。
8. 請求項２ないし請求項７の何れかに記載のビル用中央監視システムにおけるデータ送信方法において、
   前記中央監視装置から前記分散制御装置で送信された前記非リアルタイム系のデータを、前記下位制御機器に送信し、前記非リアルタイム系のデータに基づいて前記下位制御機器のスケジュールまたは設定値を変更し、
   その後、前記コントローラから受信する前記下位制御機器の状態値を、前記分散制御装置においてアナログ値にアナログ・ディジタル変換し、前記リアルタイム系のデータを送受信する手段を介して前記中央監視装置へ送信する
   ことを特徴とするビル用中央監視システムにおけるデータ送信方法。
9. 請求項８記載のビル用中央監視システムにおけるデータ送信方法において、
   前記中央監視装置では、前記アナログ値を受信すると、運転履歴の状態記録または運転・警報履歴の状態警報記録を行う
   ことを特徴とするビル用中央監視システムにおけるデータ送信方法。
   

Images