JP2006127039A - ビル用中央監視システムおよびビル用中央監視システムにおける非リアルタイム系のデータ送信方法 - Google Patents

Abstract

【課題】 監視制御対象機器が多く、機器毎のスケジュールの山数が非常に多くなっても中央監視装置の送信遅延を防止する。
【解決手段】 中央監視装置と、分散制御装置と、コントローラとを備え、中央監視装置と分散制御装置とは、リアルタイム系のデータを送受信する手段を設けて成るビル用中央監視システムにおいて、中央監視装置は、中央監視装置から分散制御装置に非リアルタイム系のデータを送信する手段を設けるとともに、非リアルタイム系のデータを送信する部分に汎用リレーショナルデータベースを持つサーバを設け、分散制御装置は、非リアルタイム系のデータを受信する手段を設け、非リアルタイム系の送信する手段および受信する手段は、リアルタイム系の送受信に遅延を生じさせずにその合間を縫ってサーバから非リアルタイム系のデータの送受信を行うことを特徴とする。
【選択図】 図２

Description

本発明は、ビル用中央監視システムおよびビル用中央監視システムにおける非リアルタイム系のデータ送信方法に関する。特に、ローカル側のスケジュールを記録する分散制御装置に、中央監視装置からスケジュールデータを送信するときのデータ送信方法に関する。

従来、ビル用中央監視システムでは、スケジュールの開始終了の時刻を１山と称してこれを複数設定可能になっており、このデータをローカル制御装置に送信し、ローカル制御装置は受信したスケジュールの開始終了の時刻から機器の起動停止を行うようにしていた。
通常、スケジュールの山数は５山程度あるので、残業時の運転スケジュールのようなデータを入力する場合には、山数が非常に多くなる。山数を多くすると、機器毎かつモード毎に最悪１分単位の開始終了の時刻を持つこととなり、ローカル制御装置の多くのメモリを消費してしまう。従って、従来は、山数制限を行っていた。

ところで、従来、ビル用中央監視システムでは、ローカル側の状態信号や計測温度等のアナログ値のリアルタイム系のデータを、中央監視装置へ送信していた。この通信方式と同じ方法で、上位の中央監視装置からローカルのゲートウェイ等のローカル制御機器にスケジュールや温度設定値等の非リアルタイム系のデータを送信する方式をとっていた。これは、上位の中央監視装置と下位のローカル制御装置との通信ドライバを１つにできるためであり、あえて分ける必要はなかった。

しかも、通常のビルの中央監視システムでは、管理点数が２０００点前後、多くても５０００点程度であった。
ところが、近年Ｌｏｎ(Local Operating Netwaork)等の通信を使用したローカル機器の制御システムの採用により、ローカル機器の各種の状態を通信で取得できるため、多量のデータを中央監視装置に取り込むようになっている（例えば、特許文献１参照）。通常のビルでは、管理点数が２０００点程度であったものが、約５倍以上のデータ量を中央監視装置に取り込む要求が出てきている。大規模なビルでは、１棟で最大管理点数が１５万点になるものがあり、従来の方式では対応できなくなってきている（例えば、特許文献２参照）。

そこで、大規模なビルにおいて、ローカル制御用の分散制御装置が１５０台程度、管理点数が１５万点を超えるようなビルの中央監視システムを構築しようとする場合、ローカルから毎秒データを取得すると仮定して、１台の分散制御装置に割り当てられる通信時間は６ｍｓｅｃ程度であり、この時間で１台あたり１０００点超の管理点数を管理している分散制御装置が送受信を行わなければならないこととなる。管理点数は１０００点でも、実際には内部の各種パラメータ等の非リアルタイム系のデータの設定値等もあり、実際の管理点数は約４倍程度にもなる。また、各機器毎１週間分のデータを分散制御装置に保管するような場合、多量のスケジュールデータを逐次中央監視装置から分散制御装置に送信する必要がある。この送受信の通信処理を効率化しないと、システム的に成り立たなくなる。
特開２００２−１１８８８２号公報 特開平６−６００８４号公報（［０００５］［０００６］）

上述したように、通常のビルのように比較的小規模なシステムの場合は、中央監視装置が通信対象とするローカル制御装置の台数がせいぜい１０台以下であり、上位から送信する非リアルタイム系のデータを下位の比較的遅いＣＰＵを使用しているコントローラでも受信することが可能である。
しかし、大規模なビルの場合、通信対象となるローカル制御装置が膨大になる。また、近年Ｌｏｎ等の通信を使用したローカル制御システムの場合、各種の多量のデータを制御機器から取得することが可能になってきた関係上、ローカル制御装置の台数も非常に多くなり、１００台以上の場合もある。この場合、１台の中央監視装置が１００台以上のローカル機器と同時に送受信しなければならない状況になる。

しかも、通常、中央監視装置には、高性能ＣＰＵを持ったサーバ系コンピュータを使用するが、ローカルの分散制御装置には、比較的処理速度の遅い安価なＣＰＵを持った機器を使用するため、高性能の中央監視装置から多量のデータを一気に分散制御装置に送信した場合、分散制御装置側では制御を行いながら通信を受信するため、多量のデータを一気に受け取れない場合が生じ、中央監視装置に送信を待たせることが発生する。このような遅延が、複数の分散制御装置で常に発生することから、実際の送受信が非常に遅くなり、リアルタイム系のデータの送信に障害が生じてしまう。

本発明は斯かる従来の問題点を解決するために為されたもので、その目的は、監視制御対象機器が多く、機器毎のスケジュールの山数が非常に多くなっても中央監視装置の送信遅延を起こすことがないビル用中央監視システムおよびビル用中央監視システムにおける非リアルタイム系のデータ送信方法を提供することにある。

請求項１に係る発明は、中央監視装置と、前記中央監視装置にネットワークを介して連絡する分散制御装置と、前記分散制御装置にネットワークを介して連絡するコントローラとを備え、前記中央監視装置と前記分散制御装置とは、リアルタイム系のデータを送受信する手段を設けて成るビル用中央監視システムにおいて、前記中央監視装置は、前記中央監視装置から前記分散制御装置に非リアルタイム系のデータを送信する手段を設けるとともに、前記非リアルタイム系のデータを送信する部分に汎用リレーショナルデータベースを持つサーバを設け、前記分散制御装置は、前記非リアルタイム系のデータを受信する手段を設け、前記非リアルタイム系の送信する手段および受信する手段は、前記リアルタイム系の送受信に遅延を生じさせずにその合間を縫って前記サーバから非リアルタイム系のデータの送受信を行うことを特徴とする。

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

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

請求項４に係る発明は、請求項１記載のビル用中央監視システムにおいて、前記非リアルタイム系のデータは、（１）スケジュールデータ、（２）設定値データ、（３）メンテナンス用設定値データであることを特徴とする。
請求項５に係る発明は、請求項１ないし請求項４の何れか記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた文字列（キャラクタ）とするとともに、１日を所定の時間単位に区切った時間単位毎に割り付けて送信し、前記所定の時間単位毎に受信した前記非リアルタイム系のデータを、前記分散制御装置の不揮発メモリ上に一旦保管し、前記保管された前記非リアルタイム系のデータから現在の時刻に相当する文字列（キャラクタ）を選択し、その文字列（キャラクタ）に従った制御動作を行うを有することを特徴とする。

請求項６に係る発明は、請求項５記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた１４４文字列（キャラクタ）とするとともに、１日を１０分毎に区切った時間単位毎に割り付けて送信することを特徴とする。

請求項７に係る発明は、請求項５記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた１４４０文字列（キャラクタ）とするとともに、１日を１分毎に区切った時間単位毎に割り付けて送信することを特徴とする。

本発明によれば、リアルタイム系のデータを分散制御装置から上位の中央監視装置の送信する手段と、上位の中央監視装置から下位の分散制御装置に非リアルタイム系のデータを送信する手段とを別にして、下位へ非リアルタイム系のデータを送信する部分に汎用リレーショナルデータベースを設けたので、下記の利点が得られる。
分散制御装置は、制御をしながら所定の送信対象のデータを、変化が生じた時にリアルタイム系のデータとして、中央監視装置に逐次送信する。この通信方式には、ＭＯＤＢＵＳ（登録商標）やＯＰＣ（OLE for Process Control）等のオープンな標準的なリアルタイム系送受信手段を使用する。中央監視装置に送信されるデータは、１５０台にものぼる分散制御装置から送られてくるが、中央監視装置のリアルタイム系処理用通信ドライバはほとんど受信のみに専念できるため、高速なＣＰＵで十分処理が可能である。一部システム的にリアルタイムで分散制御装置に送信しなければならないものがある。これは、火災発生信号や停電発生信号、非リアルタイム系のデータベース変更通知等である。このリアルタイム系のデータで中央監視装置から分散制御装置に送信するものは、極端に少ないアイテムとしていて、イベント発生を通知する極めて短い電文としている。本発明でのアイテムでは、火災発生信号、停電発生信号、データベース変更通知のみである。他にも、場合により、別なアイテムがあるが極めて少ないものに限定している。

中央監視装置で設定値（メンテナンスで各種の設定パラメータを変更した場合も含まれる）を入力したり、スケジュールを設定により変更された膨大なデータを、非リアルタイム系のデータとして、逐次汎用リレーショナルデータベースに書き込まれる。汎用リレーショナルデータベースが変更されると、変更があったというだけのイベント通知をリアルタイム系通信で分散制御装置に送信する。すなわち、中央監視装置の膨大な設定データのほとんどの出力先は、汎用リレーショナルデータベースのみとなり、まとめて設定することが可能で、分散制御装置が忙しくて多量のデータを受信する際の遅延が発生しない。

汎用リレーショナルデータベースに中央監視装置が書き込んだことにより変化が生じた場合、前記のようにリアルタイム系の通信で分散制御装置に変化があったことだけのイベントを通知する。非リアルタイム系の送信手段（以降、ＲＤＢ(Relational DataBase)ドライバと称する）は、変化のあったデータを分散制御装置毎にデータベース上で整理し分散制御装置に送信可能な状態としておき、分散制御装置が受信可能でＲＤＢドライバに受信依頼をしてきたら、データを送信する。送信に際しては、汎用リレーショナルデータベースからＯＤＢＣ（Open DataBase Connectivity ）手順によりデータを読み出して送信する。送信時は、分散制御装置の状態に合わせて送信する。この場合、送信には遅延が発生するが、送信するデータは全て非リアルタイム系のデータばかりなので遅延に伴う問題は生じない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＧＷ１８内管理の設定値の何れかが更新されたことを速やかに通知し、ＧＷ１８に送信する。
前記の通り、リアルタイム系の通信手段で「変更通知」をＧＷ１８が受信して、その後ゆっくりと前記の処理が行われるようになっている。
ＧＷ１８は自管理の設定値の何れかが更新されたことを検知し、ＳＱＬ／ＤＢ１０ｅ上の変化した設定値を検索し、変更データ（この場合、温度設定値等の非リアルタイム系設定値）の取得を行う。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スケジュール・設定値等非リアルタィム系設定値類のＧＷ１８とＳＱＬ／ＤＢ１０ｅとのデータ送受信方法を表４に示す。

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

また、本実施形態によれば、複数の発停停止をスケジュールすることが可能なスケジュールシステムを構築することが可能となる。
また、本実施形態によれば、運転対象の機器に各種の条件で運転することを指示できるスケジュールシステムを構築することが可能となる。
また、本実施形態によれば、スケジュール送信手段と同じ手段で温度設定値等の非リアルタイム系のデータのローカルヘの送信を実現することが可能となる。

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

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

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

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

本発明に係るビル用中央監視システムを適用した機器構成を示す図である。 図１におけるデータ送受信系統図である。 図１におけるソフトウエア構成図である。 スケジュールデータベースの一例を示す図である。 設定値の一例を示す図である。

符号の説明

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

Claims (7)

1. 中央監視装置と、
   前記中央監視装置にネットワークを介して連絡する分散制御装置と、
   前記分散制御装置にネットワークを介して連絡するコントローラと
   を備え、
   前記中央監視装置と前記分散制御装置とは、リアルタイム系のデータを送受信する手段を設けて成るビル用中央監視システムにおいて、
   前記中央監視装置は、前記中央監視装置から前記分散制御装置に非リアルタイム系のデータを送信する手段を設けるとともに、前記非リアルタイム系のデータを送信する部分に汎用リレーショナルデータベースを持つサーバを設け、
   前記分散制御装置は、前記非リアルタイム系のデータを受信する手段を設け、
   前記非リアルタイム系の送信する手段および受信する手段は、前記リアルタイム系の送受信に遅延を生じさせずにその合間を縫って前記サーバから非リアルタイム系のデータの送受信を行う
   ことを特徴とするビル用中央監視システム。
2. 請求項１記載のビル用中央監視システムにおいて、
   前記汎用リレーショナルデータベースには、前記中央監視装置と前記分散制御装置との通信に使用する変数定義のマスターデータベースが保管され、
   前記マスターデータベースには、全ての前記分散制御装置毎の通信に使用する変数の定義があり、前記各変数毎にリアルタイム系の上位通信に使用するもの、リアルタイム系の下位通信に使用するもの、非リアルタイム系の下位通信に使用するものの３種類の通信手段及び通信方向が判別可能なフィールド定義があり、
   前記中央監視装置は、前記フィールド定義を元に前記分散制御装置との通信を行い、
   前記分散制御装置は、前記分散制御装置を設置して前記中央監視装置と接続する時、若しくは、送受信変数内容に変更が生じた時、各変数毎の送受信方法が記載されている前記マスターデータベースから自局の分の変数定義のみを取り込んで保管し、これを用いて前記中央監視装置との通信を行う
   ことを特徴とするビル用中央監視システム。
3. 請求項１または請求項２記載のビル用中央監視システムにおいて、
   前記リアルタイム系のデータを送受信する手段では、前記分散制御装置から各種機器状態、計測値、警報が前記中央監視装置へ送信され、前記中央監視装置からサーバ変更通知、火災警報通知、停電発生通知が前記分散制御装置へ送信され、
   前記非リアルタイム系のデータを送信および受信する手段では、前記中央監視装置からリアルタイム系のデータとして前記分散制御装置へ送信後に前記分散制御装置から送信される送信要求に対し、前記サーバから要求スケジュール返信、要求更新済み設定値返信が前記分散制御装置へ送信される
   ことを特徴とするビル用中央監視システム。
4. 請求項１記載のビル用中央監視システムにおいて、
   前記非リアルタイム系のデータは、（１）スケジュールデータ、（２）設定値データ、（３）メンテナンス用設定値データである
   ことを特徴とするビル用中央監視システム。
5. 請求項１ないし請求項４の何れか記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、
   前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた文字列（キャラクタ）とするとともに、１日を所定の時間単位に区切った時間単位毎に割り付けて送信し、
   前記所定の時間単位毎に受信した前記非リアルタイム系のデータを、前記分散制御装置の不揮発メモリ上に一旦保管し、
   前記保管された前記非リアルタイム系のデータから現在の時刻に相当する文字列（キャラクタ）を選択し、その文字列（キャラクタ）に従った制御動作を行う
   を有することを特徴とするビル用中央監視システムにおける非リアルタイム系のデータ送信方法。
6. 請求項５記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、
   前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた１４４文字列（キャラクタ）とするとともに、１日を１０分毎に区切った時間単位毎に割り付けて送信する
   ことを特徴とするビル用中央監視システムにおける非リアルタイム系のデータ送信方法。
7. 請求項５記載のビル用中央監視システムにおける非リアルタイム系のデータ送信方法において、
   前記サーバから前記分制御装置に送信する前記非リアルタイム系のデータを、スケジュールまたは設定値と対応づけた１４４０文字列（キャラクタ）とするとともに、１日を１分毎に区切った時間単位毎に割り付けて送信する
   ことを特徴とするビル用中央監視システムにおける非リアルタイム系のデータ送信方法。
   

Images