JP6257797B2 - 設備機器システム、及び、制御装置 - Google Patents

Description

本発明は、設備機器を制御する複数の制御装置がネットワークを介して接続された設備機器システム、及び、制御装置に関する。

近年、ビル等の建物内において、空調機器や照明機器等の設備機器を制御（監視等も含む）する設備機器システムが配置されている。一例として、このような設備機器システムは、制御装置（コントローラ）が複数の設備機器を制御可能となっている。また、大規模な設備機器システムともなると、例えば、フロア毎に制御装置が配置され、各制御装置がフロア内の各設備機器を制御するようになっている。それでも、これらの制御装置が直接制御することのできる設備機器の台数には上限がある。このため、複数の制御装置同士をネットワークを介して接続することにより、１台の制御装置から直接的又は間接的に制御できる設備機器の台数を増加させた設備機器システムが提案されている。

このようなシステムの一例として、特許文献１には、ビル内の設備状況を外部から確認できる設備監視システムの発明が開示されている。この設備監視システムでは、監視サーバ装置が、インターネットを通じて外部の装置（監視情報表示装置）と通信可能であり、また、ＬＡＮを通じて内部の装置（各監視装置）とも通信可能となっている。監視サーバ装置は、監視情報表示装置からのリクエストに応じて、複数の設備機器（非常灯）を監視している監視装置（要求された監視装置）にアクセスし、監視装置からファイルを取得する。そして、監視サーバ装置は、取得したファイルを監視情報表示装置へ提供して表示させる。

特開２００７−３１６８６３号公報

しかしながら、上述した特許文献１に開示された設備監視システムでは、分散して管理されているデータを集めて変更可能とすることができなかった。つまり、特許文献１の設備監視システムにおいて、監視サーバ装置は、監視情報表示装置からのリクエストを監視装置にリダイレクトしているだけであり、結局のところ、個々の監視装置がリクエストに応答していることになる。そのため、監視サーバ装置は、そのようなリクエストの中継処理を行うことで、監視装置のファイルを表示（表示可能に提供）できるものの、そのファイルの内容を変更することまではできなかった。

また、特許文献１の設備監視システムでは、仮に、監視サーバ装置側でファイルの内容を変更したとしても、監視サーバ装置と監視装置とで一括してファイルを更新することができなかった。つまり、集めたデータを変更したとしても、同一のタイミングで更新することができなかった。また、特許文献１の設備監視システムでは、仮に、監視サーバ装置及び監視装置の両方から、同時期に同じデータに対して変更が行われると、後になされた方の変更だけが反映されてしまう。つまり、監視サーバ装置を操作するユーザ、及び、監視装置を操作するユーザにとって、自分の操作によるデータの変更が反映されない場合があり、しかも、反映されない場合でもそのことに気付かないという不具合が懸念される。

本発明は、上記課題を解決するためになされたもので、分散して管理されているデータを集めて変更可能とすると共に、複数の制御装置（コントローラ）から同時にデータの変更要求が発生した場合であっても、不具合を生じさせないようにすることのできる設備機器システム、及び、制御装置を提供することを目的とする。

上記目的を達成するために、本発明に係る設備機器システムは、
設備機器を制御する第１の制御装置及び第２の制御装置がネットワークを介して接続された設備機器システムであって、
前記第１の制御装置は、
前記設備機器の制御に関するデータを記憶する第１の記憶部と、
前記第２の制御装置に記憶されているデータを取得し、当該データへの変更が前記第１の制御装置を操作するユーザによってなされると、変更後データを前記第２の制御装置に送信して更新を要求するデータ更新要求部と、
前記変更後データを送信した後に、前記第２の制御装置から送られる通知内容に従って、前記第１の記憶部にデータを書き込むデータ更新処理部と、を備え、
前記第２の制御装置は、
前記設備機器の制御に関するデータを記憶する第２の記憶部と、
前記第１の制御装置から送られた前記変更後データを取得後、前記第２の制御装置を操作するユーザによる前記第２の記憶部に記憶されたデータに対する変更の有無を判別する判別部と、
前記判別部による判別結果に従って、前記変更後データを前記第２の記憶部に書き込むデータ更新処理部と、を備え、
前記第２の制御装置の前記データ更新処理部は、前記判別部がデータに対する変更がないと判別した場合に、前記変更後データの更新を許諾する許諾通知を前記第１の制御装置に送信し、前記判別部がデータに対する変更があると判別した場合に、前記変更後データの更新を拒絶する拒絶通知を前記第１の制御装置に送信し、
前記第１の制御装置の前記データ更新処理部は、前記第２の制御装置から前記許諾通知が送られた場合に、前記第１の記憶部に前記変更後データを書き込み、前記第２の制御装置から前記拒絶通知が送られた場合に、前記第１の制御装置を操作するユーザに対して変更が拒絶されたことを報知する。

本発明によれば、第２の制御装置が保持しているデータが第１の制御装置に集められて変更可能となる。そして、変更後データが第１の制御装置から第２の制御装置に送られた後、第２の制御装置が保持しているデータへの変更の有無が判別される。ここで、第２の制御装置が保持しているデータへの変更がないと判別されると、許諾通知が第１の制御装置に送信され、第１及び第２の制御装置の双方で変更後データの書き込みが行われる。一方、第２の制御装置が保持しているデータへの変更があると判別されると、拒絶通知が第１の制御装置に送信され、第１の制御装置を操作するユーザに対して変更が拒絶されたことが報知される。これによって、分散して管理されているデータを集めて変更可能とすると共に、複数の制御装置（コントローラ）から同時にデータの変更要求が発生した場合であっても、不具合を生じさせないようにすることができる。

本発明の実施形態１に係る空調システムの全体構成の一例を示すブロック図である。 メインコントローラ及びサブコントローラの機能構成の一例を示すブロック図である。 スケジュールデータの取得動作を説明するためのフローチャートである。 スケジュールデータの更新動作を説明するためのフローチャートである。 スケジュールデータの更新動作を説明するためのフローチャートである。 本発明の実施形態２に係る空調システムの全体構成の一例を示すブロック図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。なお、図中同一又は相当部分には同一符号を付す。以下では、具体例として、本発明が第１の制御装置（後述するメインコントローラ１００）及び第２の制御装置（後述するサブコントローラ２００）がネットワークを介して接続された空調システムに適用される場合について説明するが、後述するように、他のシステムにおいても同様に本発明を適用することができる。すなわち、以下に説明する実施形態は説明のためのものであり、本発明の範囲を制限するものではない。従って、当業者であればこれらの各要素又は全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

（実施形態１）
図１は、本発明の実施形態１に係る空調システム１の全体構成の一例を示すブロック図である。図示するように、空調システム１は、各空調機３００を制御するメインコントローラ１００及び各サブコントローラ２００が、ＬＡＮ（Local Area Network）等のネットワーク１０を介して接続されて構成される。この空調システム１は、例えば、ビル等の建物に配置され、建物内の全ての空調機３００を制御（監視等も含む）する。一例として、メインコントローラ１００やサブコントローラ２００は、各フロアに配置され、それぞれ、フロア内の各空調機３００を制御する。

具体的に、メインコントローラ１００は、１階フロアに配置され、同フロア内の空調機３００ａ〜３００ｃと制御バス２０ａを介して接続されている。また、サブコントローラ２００ａは、２階フロアに配置され、同フロア内の空調機３００ｄ〜３００ｆと制御バス２０ｂを介して接続されている。そして、サブコントローラ２００ｂは、３階フロアに配置され、同フロア内の空調機３００ｇ〜３００ｉと制御バス２０ｃを介して接続されている。なお、図１に示す空調システム１の構成は一例であり、実際に配置する建物の階数や間取りに応じて、サブコントローラ２００や空調機３００の数等を適宜変更可能である。

メインコントローラ１００及びサブコントローラ２００（２００ａ，２００ｂ）は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、通信ユニット、不揮発性メモリ（一例として、フラッシュメモリ）、液晶表示ユニット、及び、タッチパネルなどを含んで構成されるコントローラである。

メインコントローラ１００及び各サブコントローラ２００は、ネットワーク１０を介して互いに通信を行い、また、制御バス２０を介して各空調機３００を制御する。なお、メインコントローラ１００及びサブコントローラ２００の詳細については、後述する。

空調機３００（３００ａ〜３００ｉ）は、例えば、膨張弁及び負荷側熱交換器などを有し、図示せぬ室外機と配管により接続されている。空調機３００は、負荷側熱交換器において冷媒を蒸発又は凝縮させ、対象空間の空気調和を行う。なお、図１の空調機３００は、一例として、天井埋め込み型の空調機（室内機）を示しているが、他に、壁掛け型や据え置き型の空調機であってもよい。

図２は、メインコントローラ１００及びサブコントローラ２００の機能構成の一例を示すブロック図である。以下、このブロック図を参照して、メインコントローラ１００及びサブコントローラ２００を順に説明する。

最初に、メインコントローラ１００は、図２に示すように、通信部１１０と、Ｗｅｂサーバ１２０と、スケジュールデータ取得要求部１３０と、スケジュールデータ更新要求部１４０と、ＷｅｂＳｏｃｋｅｔクライアント１５０と、復号化部１６０と、暗号化部１７０と、スケジュールデータ１８０（１８０ａ，１８０ｂ）と、使用区画管理部１９０とを含んで構成される。

なお、通信部１１０は、例えば、上述した通信ユニットによって実現される。また、Ｗｅｂサーバ１２０〜暗号化部１７０は、例えば、上述したＣＰＵ，ＲＯＭ，ＲＡＭによって実現される。つまり、Ｗｅｂサーバ１２０〜暗号化部１７０は、ＲＯＭなどに格納されたプログラムをＲＡＭに読み出して、ＣＰＵが実行することにより実現される。そして、スケジュールデータ１８０及び使用区画管理部１９０は、例えば、上述したフラッシュメモリによって実現される。なお、この使用区画管理部１９０は、上述したＣＰＵ，ＲＯＭ，ＲＡＭによって実現されてもよい。

また、図２では省略しているが、メインコントローラ１００は、表示部や操作受け付け部も備えている。表示部は、例えば、上述した液晶表示ユニットによって実現され、種々の画面（例えば、スケジュール設定画面等）を表示する。また、操作受け付け部は、例えば、上述したタッチパネルによって実現され、表示部に表示された設定画面内に配置されたボタン画像（例えば、スケジュール設定ボタン等）の押下（ユーザの指等による押下操作）を受け付ける。また、メインコントローラ１００は、エラー音等を発生させるためのスピーカ等を備えていてもよい。

通信部１１０は、ネットワーク１０を介して、サブコントローラ２００と通信を行う。例えば、通信部１１０は、スケジュールデータ取得要求部１３０やスケジュールデータ更新要求部１４０に制御され、サブコントローラ２００との間で、スケジュールデータ等を送受信する。その際、通信部１１０は、ＷｅｂＳｏｃｋｅｔクライアント１５０の制御に従って、ＷｅｂＳｏｃｋｅｔ規格に沿った通信を行う。このＷｅｂＳｏｃｋｅｔ規格についての詳細は、後述するＷｅｂＳｏｃｋｅｔクライアント１５０と共に説明する。

Ｗｅｂサーバ１２０は、ＨＴＭＬ（Hyper Text Markup Language）形式のデータや画像を、ブラウザなどからの要求に応じて供給する。

スケジュールデータ取得要求部１３０は、通信部１１０を制御して、サブコントローラ２００に対して、スケジュールデータを要求する（取得要求を発行する）。そして、要求したスケジュールデータを、通信部１１０を通じて取得すると、スケジュールデータ取得要求部１３０は、取得したスケジュールデータを復号化部１６０によって復号化する。つまり、サブコントローラ２００から送られるスケジュールデータは、後述するように暗号化（メインコントローラ１００の公開鍵にて暗号化）されているため、自身（メインコントローラ１００）の秘密鍵を用いて復号化（解凍）する。スケジュールデータ取得要求部１３０は、復号化したスケジュールデータをＲＡＭ等の一時記憶領域に、仮スケジュールデータとして保存する。

このように得られた仮スケジュールデータを元にして、メインコントローラ１００の液晶ユニット（表示部）には、サブコントローラ２００が管理する空調機３００のスケジュール設定画面が表示される。そして、ユーザは、メインコントローラ１００のタッチパネル（操作受け付け部）からスケジュール設定画面を操作して、仮スケジュールデータの変更が行えるようになる。

スケジュールデータ更新要求部１４０は、仮スケジュールデータの変更が確定すると（例えば、スケジュール設定画面内に配置された「スケジュール設定ボタン」がユーザによって押下されると）、一時スケジュールデータ（変更されたスケジュールデータ）を作成する。そして、一時スケジュールデータを暗号化部１７０によって暗号化する。つまり、サブコントローラ２００の公開鍵を用いて暗号化する。

スケジュールデータ更新要求部１４０は、通信部１１０を制御して、暗号化したスケジュールデータ（変更されたスケジュールデータ）をサブコントローラ２００に送信すると共に、そのスケジュールデータの更新要求する。なお、この更新要求に応答して、サブコントローラ２００からは、更新要求を承諾した旨の通知（より詳細には、スケジュールデータの更新予約完了通知）、又は、更新要求を拒絶した旨の通知（より詳細には、スケジュールデータの更新予約拒絶通知）が送信される。

スケジュールデータ更新要求部１４０は、更新要求を承諾した旨の通知を、通信部１１０を通じてサブコントローラ２００から取得すると、変更されたスケジュールデータを自身（メインコントローラ１００）のフラッシュメモリに書き込む。なお、後述するように、フラッシュメモリには、スケジュールデータを格納するための領域が複数区画（一例として、Ａ区画及びＢ区画）設けられており、スケジュールデータ更新要求部１４０は、使用区画管理部１９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。

一方、スケジュールデータ更新要求部１４０は、更新要求を拒絶した旨の通知を、通信部１１０を通じてサブコントローラ２００から取得すると、ユーザが行ったスケジュール変更が拒絶されたことを報知するための警告メッセージを表示部に表示する。なお、このような警告メッセージを表示部に表示するだけでなく、メインコントローラ１００がスピーカを備えている場合に、スケジュールデータ更新要求部１４０は、スピーカからエラー音を発生させて、スケジュール変更が拒絶されたことをユーザに報知してもよい。

なお、更新要求を拒絶した旨の通知と共に、サブコントローラ２００にて変更されたスケジュールデータを取得した場合に、スケジュールデータ更新要求部１４０は、変更されたスケジュールデータに基づいて自身（メインコントローラ１００）の仮スケジュールデータを更新し、一時スケジュールデータを破棄する。

このようにサブコントローラ２００にて変更されたスケジュールデータ（更新後の仮スケジュールデータ）を元にして、メインコントローラ１００の液晶ユニット（表示部）には、サブコントローラ２００が管理する空調機３００のスケジュール設定画面（最新のスケジュールが反映された設定画面）が表示される。そして、ユーザは、メインコントローラ１００のタッチパネル（操作受け付け部）からスケジュール設定画面を操作して、仮スケジュールデータの変更が再度行えるようになる。

ＷｅｂＳｏｃｋｅｔクライアント１５０は、通信部１１０を制御して、サブコントローラ２００との間の通信を、ＷｅｂＳｏｃｋｅｔ規格に沿って行う。

なお、ＷｅｂＳｏｃｋｅｔ（ウェブソケット）規格は、コンピュータ・ネットワーク用の通信規格の１つであり、サーバとクライアントとの間の通信のための双方向通信用の技術規格である。このＷｅｂＳｏｃｋｅｔ規格には、専用のＡＰＩ（Application Programming Interface）とプロトコルが規定されており、ＴＣＰ（Transmission Control Protocol）上で動作する。サーバとクライアント間のデータのやり取りが頻繁に発生する場合、従来のＨＴＴＰ（Hypertext Transfer Protocol）では、あくまでクライアント側（接続する側）からサーバ側（接続される側）にデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しかった。これに対して、ＷｅｂＳｏｃｋｅｔ規格では、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。そのため、従来の手法に比べて、通信ロスを低減できることや、同一サーバに接続する他のアプリケーションへの影響が少ない（１つのコネクションで全てのデータ送受信が行えるため）などのメリットがある。

復号化部１６０は、ＳＳＬ（Secure Sockets Layer）と呼ばれる公開鍵暗号方式を用いて、データの暗号化・復号化を行う内の、復号化を担う。例えば、復号化部１６０は、自身（メインコントローラ１００）の秘密鍵を用いて、スケジュールデータを復号化する。つまり、メインコントローラ１００の公開鍵にて暗号化されたスケジュールデータを、サブコントローラ２００から取得した際に、その暗号化されたスケジュールデータを、メインコントローラ１００の秘密鍵を用いて復号化する。

暗号化部１７０は、ＳＳＬと呼ばれる公開鍵暗号方式を用いて、データの暗号化・復号化を行う内の、暗号化を担う。例えば、暗号化部１７０は、サブコントローラ２００の公開鍵を用いて、スケジュールデータを暗号化する。つまり、変更されたスケジュールデータをスケジュールデータ更新要求部１４０がサブコントローラ２００に送る際に、送り先のサブコントローラ２００の公開鍵を用いて、そのスケジュールデータを暗号化する。そのために、暗号化部１７０は、サブコントローラ２００ａ，２００ｂ両方の公開鍵を保持している。

スケジュールデータ１８０（１８０ａ，１８０ｂ）は、自身（メインコントローラ１００）のフラッシュメモリに格納されたスケジュールデータを示している。スケジュールデータ１８０は、例えば、サブコントローラ２００から取得したスケジュールデータが変更された後にフラッシュメモリに書き込まれて格納される。

なお、フラッシュメモリには、スケジュールデータを格納するための領域として、例えば、Ａ区画及びＢ区画が設けられている。そして、スケジュールデータ１８０ａは、例えば、Ａ区画に格納されたスケジュールデータを表している。一方、スケジュールデータ１８０ｂは、例えば、Ｂ区画に格納されたスケジュールデータを表している。これらＡ区画及びＢ区画は、以下に説明する使用区画管理部１９０によって、何れの区画が使用区画（空調機３００の制御に使用するための使用区画）であるかが指し示されており、使用区画として指し示されている方のスケジュールデータ１８０が、空調機３００の制御に実際に使用されるようになっている。また、フラッシュメモリに設けられた区画数は、複数であればよく、例えば、Ａ区画、Ｂ区画、及び、Ｃ区画からなる３つの区画が設けられていてもよい。その場合、使用区画管理部１９０は、全区画のうちの１つを、使用区画として指し示すものとする。

使用区画管理部１９０は、フラッシュメモリに設けられたＡ区画及びＢ区画の何れかを、空調機３００の制御に使用するための使用区画として指し示している。上述したように、スケジュールデータ更新要求部１４０は、使用区画管理部１９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。そして、使用区画管理部１９０は、一定時間後に、使用区画を切り替える。例えば、使用区画管理部１９０は、上述した更新要求に受諾した旨の通知（より詳細には、スケジュールデータの更新予約完了通知）が、サブコントローラ２００から送られた時点から一定時間経過後に、スケジュールデータ更新要求部１４０がスケジュールデータを書き込んだ区画を、使用区画として指し示す。

次に、サブコントローラ２００は、図２に示すように、通信部２１０と、スケジュールデータ取得処理部２２０と、スケジュールデータ更新処理部２３０と、変更判別部２４０と、ＷｅｂＳｏｃｋｅｔサーバ２５０と、復号化部２６０と、暗号化部２７０と、スケジュールデータ２８０（２８０ａ，２８０ｂ）と、使用区画管理部２９０とを含んで構成される。

なお、通信部２１０は、例えば、上述した通信ユニットによって実現される。また、スケジュールデータ取得処理部２２０〜暗号化部２７０は、例えば、上述したＣＰＵ，ＲＯＭ，ＲＡＭによって実現される。つまり、スケジュールデータ取得処理部２２０〜暗号化部２７０は、ＲＯＭなどに格納されたプログラムをＲＡＭに読み出して、ＣＰＵが実行することにより実現される。そして、スケジュールデータ２８０及び使用区画管理部２９０は、例えば、上述したフラッシュメモリによって実現される。なお、この使用区画管理部２９０は、上述したＣＰＵ，ＲＯＭ，ＲＡＭによって実現されてもよい。

また、メインコントローラ１００と同様に、サブコントローラ２００も、図示せぬ表示部や操作受け付け部を備えている。表示部は、例えば、上述した液晶表示ユニットによって実現され、種々の画面を表示する。また、操作受け付け部は、例えば、上述したタッチパネルによって実現され、表示部に表示された設定画面内に配置されたボタン画像の押下を受け付ける。

通信部２１０は、ネットワーク１０を介して、メインコントローラ１００と通信を行う。例えば、通信部２１０は、スケジュールデータ取得処理部２２０やスケジュールデータ更新処理部２３０に制御され、メインコントローラ１００との間で、スケジュールデータ等を送受信する。その際、通信部２１０は、ＷｅｂＳｏｃｋｅｔサーバ２５０の制御に従って、ＷｅｂＳｏｃｋｅｔ規格に沿って通信を行う。

スケジュールデータ取得処理部２２０は、通信部２１０を通じて、スケジュールデータの取得要求をメインコントローラ１００から取得する。そして、スケジュールデータ取得処理部２２０は、自身（サブコントローラ２００）のフラッシュメモリからスケジュールデータ（より詳細には、使用区画管理部２９０が使用区画として指し示している区画から読み出したスケジュールデータ２８０）を読み出し、暗号化部２７０によって暗号化する。つまり、メインコントローラ１００の公開鍵を用いて暗号化する。スケジュールデータ取得処理部２２０は、通信部２１０を制御して、暗号化したスケジュールデータをメインコントローラ１００に送信する。

スケジュールデータ更新処理部２３０は、通信部２１０を通じて、スケジュールデータ（メインコントローラ１００側で変更されたスケジュールデータ）とその更新要求を、メインコントローラ１００から取得する。スケジュールデータ更新処理部２３０は、取得したスケジュールデータを復号化部２６０によって復号化する。つまり、メインコントローラ１００から送られるスケジュールデータは、上述したように暗号化（サブコントローラ２００の公開鍵にて暗号化）されているため、自身（サブコントローラ２００）の秘密鍵を用いて復号化する。

復号化を通じてスケジュールデータに改竄や欠損がないことを確認すると、スケジュールデータ更新処理部２３０は、変更判別部２４０によってなされるサブコントローラ２００側によるスケジュールデータの変更の有無の判別結果を待機する。変更判別部２４０は、後述するように、予め定められた時間の待ち状態に入り、その待機時間内において、サブコントローラ２００側によるスケジュールデータの変更の有無を判別する。つまり、変更判別部２４０は、メインコントローラ１００側にてスケジュールデータが変更されている状態で、サブコントローラ２００側にてスケジュールデータの変更がなされたかどうかを判別する。そして、この判別結果に応じて、スケジュールデータ更新処理部２３０は、以下のような処理を実行する。

サブコントローラ２００側にて変更がないと判別された場合に、スケジュールデータ更新処理部２３０は、通信部２１０を制御して、スケジュールデータの更新予約完了通知をメインコントローラ１００に送信する。そして、スケジュールデータ更新処理部２３０は、スケジュールデータ（変更されたスケジュールデータ）を自身（サブコントローラ２００）のフラッシュメモリに書き込む。なお、フラッシュメモリには、スケジュールデータを格納するための領域が複数区画（一例として、Ａ区画及びＢ区画）設けられており、スケジュールデータ更新処理部２３０は、使用区画管理部２９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。

一方、サブコントローラ２００側にて変更があると判別された場合に、スケジュールデータ更新処理部２３０は、通信部２１０を制御して、スケジュールデータの更新予約拒絶通知をメインコントローラ１００に送信する。なお、サブコントローラ２００側にて変更がなされても、変更箇所が重ならない場合には、両方の変更を同時に反映可能となる。そのため、後述するように、変更判別部２４０は、両方の変更箇所を比較して、重複の有無も判別する。そして、変更箇所が重複しないと判別されると、スケジュールデータ更新処理部２３０は、両方の変更箇所を統合した変更後のスケジュールデータを生成して、更新予約拒絶通知と共にメインコントローラ１００に送信する。更に、変更箇所が重複すると判別された場合でも、予め定められた優先順位に従って、一方の変更箇所だけを反映させてもよい。例えば、サブコントローラ２００側の方が優先順位が高い場合に、スケジュールデータ更新処理部２３０は、サブコントローラ２００側による変更箇所だけを反映させた変更後のスケジュールデータを生成して、更新予約拒絶通知と共にメインコントローラ１００に送信する。

変更判別部２４０は、メインコントローラ１００側から送られたスケジュールデータの複合化がスケジュールデータ更新処理部２３０によって行われると（復号化を通じてスケジュールデータに改竄や欠損がないことが確認されると）、予め定められた時間の待ち状態に入り、その待機時間内において、サブコントローラ２００側によるスケジュールデータの変更の有無を判別する。つまり、変更判別部２４０は、メインコントローラ１００側にてスケジュールデータが変更されている状態で、サブコントローラ２００のタッチパネル（操作受け付け部）を操作するユーザによって、スケジュールデータの変更が行われたかどうかを判別する。変更判別部２４０は、スケジュールデータの変更が行われないまま、待機時間が経過した場合に、変更がない旨の判別結果をスケジュールデータ更新処理部２３０に通知する。

一方、スケジュールデータの変更が行われると、変更判別部２４０は、変更がある旨の判別結果をスケジュールデータ更新処理部２３０に通知する。なお、サブコントローラ２００側にて変更がなされても、その変更箇所が、メインコントローラ１００側の変更箇所と重ならない場合には、両方の変更を同時に反映可能となる。そのため、変更判別部２４０は、両方の変更箇所を比較して、重複の有無も判別する。一例として、変更判別部２４０は、以下のように重複の有無を判別する。

変更判別部２４０は、まず、サブコントローラ２００側の変更箇所を確定する。つまり、ユーザ操作によって、スケジュールデータの何バイト目〜何バイト目が変更されたのかを確定させる。より詳細に変更判別部２４０は、ユーザが行ったスケジュールの変更を、データの形式に変換した後に、現在のスケジュールデータと比較して、何バイト目〜何バイト目が変更されたのかを確定する。なお、変更箇所は複数あることもある。変更箇所に関する情報は、上述したＲＡＭ内に一時的に保存される。

次に、変更判別部２４０は、メインコントローラ１００側の変更箇所を確定する。つまり、メインコントローラ１００から取得したスケジュールデータの何バイト目〜何バイト目が変更されたのかを確定させる。より詳細に変更判別部２４０は、メインコントローラ１００から送信されたスケジュールデータ（メインコントローラ１００側で変更されたスケジュールデータ）と、現在のスケジュールデータと比較して、何バイト目〜何バイト目が変更されたのかを確定する。なお、変更箇所は複数あることもある。変更箇所に関する情報は、上述したＲＡＭ内に一時的に保存される。

そして、変更判別部２４０は、ＲＡＭ内に保存された両方の変更箇所に関する情報を比較し、重複の有無について判別する。変更判別部２４０は、このような重複についての判別結果もスケジュールデータ更新処理部２３０に通知する。なお、スケジュールデータ更新処理部２３０は、変更箇所が重複していない場合（メインコントローラ１００側の変更箇所と、サブコントローラ２００側の変更箇所とが異なる場合）に、２つの変更箇所を統合して変更後のスケジュールデータを生成する。また、変更箇所が重複していても、予め定められた優先順位に従って、一方の変更箇所だけを反映させた変更後のスケジュールデータを生成してもよい。例えば、サブコントローラ２００側の方が優先順位が高い場合に、スケジュールデータ更新処理部２３０は、サブコントローラ２００側による変更箇所だけを反映させた変更後のスケジュールデータを生成する。

ＷｅｂＳｏｃｋｅｔサーバ２５０は、通信部２１０を制御して、メインコントローラ１００との間の通信を、ＷｅｂＳｏｃｋｅｔ規格に沿って行う。

復号化部２６０は、ＳＳＬと呼ばれる公開鍵暗号方式を用いて、データの暗号化・復号化を行う内の、復号化を担う。例えば、復号化部２６０は、自身（サブコントローラ２００）の秘密鍵を用いて、スケジュールデータを復号化する。つまり、サブコントローラ２００の公開鍵にて暗号化されたスケジュールデータを、メインコントローラ１００から取得した際に、その暗号化されたスケジュールデータを、サブコントローラ２００の秘密鍵を用いて復号化する。

暗号化部２７０は、ＳＳＬと呼ばれる公開鍵暗号方式を用いて、データの暗号化・復号化を行う内の、暗号化を担う。例えば、暗号化部２７０は、メインコントローラ１００の公開鍵を用いて、スケジュールデータを暗号化する。つまり、取得が要求されたスケジュールデータをスケジュールデータ取得処理部２２０がメインコントローラ１００に送る際に、メインコントローラ１００の公開鍵を用いて、そのスケジュールデータを暗号化する。

スケジュールデータ２８０（２８０ａ，２８０ｂ）は、自身（サブコントローラ２００）のフラッシュメモリに格納されたスケジュールデータを示している。スケジュールデータ２８０は、例えば、メインコントローラ１００から送られたスケジュールデータ（変更されたスケジュールデータ）がフラッシュメモリに書き込まれて格納される。

なお、フラッシュメモリには、スケジュールデータを格納するための領域として、例えば、Ａ区画及びＢ区画が設けられている。そして、スケジュールデータ２８０ａは、例えば、Ａ区画に格納されたスケジュールデータを表している。一方、スケジュールデータ２８０ｂは、例えば、Ｂ区画に格納されたスケジュールデータを表している。これらＡ区画及びＢ区画は、以下に説明する使用区画管理部２９０によって、何れの区画が使用区画であるかが指し示されており、使用区画として指し示されている方のスケジュールデータ２８０が実際の制御等に使用されるようになっている。また、フラッシュメモリに設けられた区画数は、複数であればよく、例えば、Ａ区画、Ｂ区画、及び、Ｃ区画からなる３つの区画が設けられていてもよい。その場合、使用区画管理部２９０は、全区画のうちの１つを、使用区画として指し示すものとする。

使用区画管理部２９０は、フラッシュメモリに設けられたＡ区画及びＢ区画の何れかを使用区画として指し示す。上述したように、スケジュールデータ更新処理部２３０は、使用区画管理部２９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。そして、使用区画管理部２９０は、一定時間後に、使用区画を切り替える。例えば、使用区画管理部２９０は、上述した更新予約の要求に受諾した旨の通知（より詳細には、スケジュールデータの更新予約完了通知）を、メインコントローラ１００に送った時点から一定時間経過後に、スケジュールデータ更新処理部２３０がスケジュールデータを書き込んだ区画を、使用区画として指し示す。

このような構成の空調システム１の動作について、以下、図３〜５を参照して説明する。図３は、スケジュールデータの取得動作を説明するためのフローチャートである。また、図４，５は、スケジュールデータの更新動作を説明するためのフローチャートである。

最初に、図３を参照して、スケジュールデータの取得動作を説明する。このスケジュールデータの取得動作は、例えば、メインコントローラ１００の液晶ユニット（表示部）に、どの空調機３００のスケジュールデータを変更するかや、その際どの空調機３００のスケジュールデータを元に変更するかなどを含んだ選択画面が表示され、タッチパネル（操作受け付け部）からユーザの指示を受け付けた後に、開始される。

まず、メインコントローラ１００のスケジュールデータ取得要求部１３０は、通信部１１０を制御して、サブコントローラ２００に対して、スケジュールデータの取得を要求する（ステップＳ１１）。

例えば、スケジュールデータ取得要求部１３０は、ユーザに選択された空調機３００（スケジュールデータを変更する空調機３００）が、何階のフロアに配置されており、何れのサブコントローラ２００で管理されているのかを自動判別する。一例として、スケジュールデータ取得要求部１３０は、各空調機３００とフロアとの対応を規定した情報や、各サブコントローラ２００とフロアとの対応を規定した情報に基づいて、選択された空調機３００のスケジュールデータを管理するサブコントローラ２００を特定する。そして、スケジュールデータ取得要求部１３０は、特定したサブコントローラ２００に対して、スケジュールデータの取得を要求する。

サブコントローラ２００のスケジュールデータ取得処理部２２０は、スケジュールデータの暗号化を行う（ステップＳ１２）。

すなわち、スケジュールデータ取得処理部２２０は、通信部２１０を通じて、スケジュールデータの取得要求をメインコントローラ１００から取得すると、自身（サブコントローラ２００）のフラッシュメモリからスケジュールデータ（より詳細には、使用区画管理部２９０が使用区画として指し示されている区画に格納されているスケジュールデータ２８０）を読み出し、暗号化部２７０によって暗号化する。つまり、メインコントローラ１００の公開鍵を用いて暗号化する。

スケジュールデータ取得処理部２２０は、スケジュールデータをメインコントローラ１００に送信する（ステップＳ１３）。つまり、スケジュールデータ取得処理部２２０は、通信部２１０を制御して、暗号化したスケジュールデータをメインコントローラ１００に送信する。

スケジュールデータ取得要求部１３０は、スケジュールデータを復号化し、仮スケジュールデータとして保存する（ステップＳ１４）。

すなわち、要求したスケジュールデータを、通信部１１０を通じて取得すると、スケジュールデータ取得要求部１３０は、取得したスケジュールデータを復号化部１６０によって復号化する。つまりメインコントローラ１００の公開鍵にて暗号化されたスケジュールデータを、自身（メインコントローラ１００）の秘密鍵を用いて復号化する。そして、スケジュールデータ取得要求部１３０は、復号化したスケジュールデータをＲＡＭ等の一時記憶領域に、仮スケジュールデータとして保存する。

スケジュールデータ取得要求部１３０は、スケジュールデータを表示部に表示させる（ステップＳ１５）。

すなわち、スケジュールデータ取得要求部１３０は、このように得られた仮スケジュールデータを元にして、メインコントローラ１００の液晶ユニットに、サブコントローラ２００が管理する空調機３００のスケジュール設定画面を表示する。このため、ユーザは、メインコントローラ１００のタッチパネル（操作受け付け部）からスケジュール設定画面を操作して、仮スケジュールデータの変更が行えるようになる。

次に、図４，５を参照して、スケジュールデータの更新動作を説明する。なお、図４は、メインコントローラ１００側におけるスケジュールデータの変更時に、サブコントローラ２００側にてスケジュールデータの変更がなされていない場合の動作を説明するためのフローチャートである。一方、図５は、メインコントローラ１００側におけるスケジュールデータの変更時に、サブコントローラ２００側にてスケジュールデータの変更がなされた場合の動作を説明するためのフローチャートである。これらのスケジュールデータの更新動作は、例えば、上述したスケジュール設定画面を、ユーザがタッチパネルから操作して、仮スケジュールデータの変更を行った後、変更の完了を示す「スケジュール設定ボタン」がユーザによって押下されると、開始される。最初に、図４を参照して、メインコントローラ１００側におけるスケジュールデータの変更時に、サブコントローラ２００側にてスケジュールデータの変更がなされていない場合の動作について説明する。

まず、メインコントローラ１００のスケジュールデータ更新要求部１４０は、一時スケジュールデータを作成する（ステップＳ２１）。つまり、スケジュールデータ更新要求部１４０は、変更されたスケジュールデータを示す一時スケジュールデータを作成し、例えば、ＲＡＭ等の一時記憶領域に保存する。

スケジュールデータ更新要求部１４０は、スケジュールデータの暗号化を行う（ステップＳ２２）。すなわち、スケジュールデータ更新要求部１４０は、一時スケジュールデータを暗号化部１７０によって暗号化する。つまり、サブコントローラ２００の公開鍵を用いて暗号化する。

スケジュールデータ更新要求部１４０は、スケジュールデータをサブコントローラ２００に送信し、更新予約を要求する（ステップＳ２３）。すなわち、スケジュールデータ更新要求部１４０は、通信部１１０を制御して、暗号化したスケジュールデータ（変更されたスケジュールデータ）をサブコントローラ２００に送信すると共に、そのスケジュールデータの更新予約を要求する。

サブコントローラ２００のスケジュールデータ更新処理部２３０は、スケジュールデータの復号化を行う（ステップＳ２４）。すなわち、スケジュールデータ更新処理部２３０は、取得したスケジュールデータを復号化部２６０によって復号化する。つまり、メインコントローラ１００から送られるスケジュールデータは、サブコントローラ２００の公開鍵にて暗号化されているため、復号化部２６０にて復号化する。つまり、自身（サブコントローラ２００）の秘密鍵を用いて復号化する。

スケジュールデータ更新処理部２３０は、受領データを確認する（ステップＳ２５）。すなわち、スケジュールデータ更新処理部２３０は、復号化を通じてスケジュールデータに改竄や欠損がないことを確認する。なお、データが欠損していたり、改変されていた場合は、スケジュールデータを正常に復号化できないため、ここで破棄される。

スケジュールデータ更新処理部２３０は、変更判別部２４０の判別結果を待つ（ステップＳ２６）。つまり、変更判別部２４０が、予め定められた時間の待ち状態に入り、その待機時間内において、サブコントローラ２００側によるスケジュールデータの変更の有無を判別するため、スケジュールデータ更新処理部２３０は、その判別結果を待機する。なお、変更判別部２４０の待機時間は、おおよそ数秒程度である。これは、サブコントローラ２００の操作受け付け部が、ユーザによるスケジュールデータの変更を受け付けるために必要な時間である。

サブコントローラ２００側にてスケジュールデータの変更がない旨の判別結果を変更判別部２４０から得ると、スケジュールデータ更新処理部２３０は、スケジュールデータの更新予約完了通知をメインコントローラ１００に送信する（ステップＳ２７）。すなわち、更新予約を承諾した旨の通知であるスケジュールデータの更新予約完了通知を、スケジュールデータ更新処理部２３０は、通信部２１０を制御して、メインコントローラ１００に送信する。

なお、この時点では、メインコントローラ１００，サブコントローラ２００共に、スケジュールデータを、フラッシュメモリに書き込んでいない。また、スケジュールデータの更新予約完了通知は、非常に小さいデータのため、即時にメインコントローラ１００に到着する。すなわち、この間の時間遅れはほとんど無視できる。そして、以下に示すように、この直後に、メインコントローラ１００，サブコントローラ２００共に、変更されたスケジュールデータをフラッシュメモリ（使用区画とは異なる区画）に書き込み始める。

スケジュールデータ更新要求部１４０は、フラッシュメモリへのデータの書き込みを行う（ステップＳ２８）。すなわち、サブコントローラ２００からのスケジュールデータの更新予約完了通知を、通信部１１０を通じて取得すると、スケジュールデータ更新要求部１４０は、変更されたスケジュールデータを自身（メインコントローラ１００）のフラッシュメモリに書き込む。その際、スケジュールデータ更新要求部１４０は、使用区画管理部１９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。

また、同一のタイミングで、スケジュールデータ更新処理部２３０は、フラッシュメモリへのデータの書き込みを行う（ステップＳ２９）。すなわち、スケジュールデータ更新処理部２３０は、復号化したスケジュールデータ（変更されたスケジュールデータ）を自身（サブコントローラ２００）のフラッシュメモリに書き込む。その際、スケジュールデータ更新処理部２３０は、使用区画管理部２９０が使用区画として指し示していない方の区画に、変更されたスケジュールデータを書き込む。

なお、これらステップＳ２８，Ｓ２９では、どちらのコントローラも同じ速度でフラッシュメモリに書き込んでいく。フラッシュメモリへの書き込み時間は、書き込むデータのサイズに比例するため、メインコントローラ１００，サブコントローラ２００共に、ほぼ同時にフラッシュメモリへの書き込みが完了する。

スケジュールデータ更新要求部１４０は、一定時間待つ（ステップＳ３０）。つまり、スケジュールデータ更新要求部１４０は、スケジュールデータの更新予約完了通知を受信した時点から、一定時間の経過を待つ。

また、同様に、スケジュールデータ更新処理部２３０は、一定時間待つ（ステップＳ３１）。つまり、スケジュールデータ更新処理部２３０は、スケジュールデータの更新予約完了通知をメインコントローラ１００に送信した時点から、一定時間の経過を待つ。なお、これらステップＳ３０，Ｓ３１の待ち時間により、スケジュールデータを読み込み中だった場合でも読み込みが完了し、不整合が発生することを防止できる。つまり、使用区画のスケジュールデータの読み込み途中でないことが保証される。

スケジュールデータ更新要求部１４０は、フラッシュメモリの使用区画を切り替える（ステップＳ３２）。すなわち、スケジュールデータ更新要求部１４０は、使用区画管理部１９０に使用区画の切替を指示する。つまり、使用区画管理部１９０は、上述したステップＳ２８にてスケジュールデータ更新要求部１４０がスケジュールデータを書き込んだ区画を、使用区画として指し示す。

また、同一のタイミングで、スケジュールデータ更新処理部２３０は、フラッシュメモリの使用区画を切り替える（ステップＳ３３）。すなわち、スケジュールデータ更新処理部２３０は、使用区画管理部２９０に使用区画の切替を指示する。つまり、使用区画管理部２９０は、上述したステップＳ２９にてスケジュールデータ更新処理部２３０がスケジュールデータを書き込んだ区画を、使用区画として指し示す。なお、これらステップＳ３２，Ｓ３３により、メインコントローラ１００，サブコントローラ２００の両方で更新されたスケジュールデータは、同一のタイミングで空調機３００の制御に使用可能となる。

スケジュールデータ更新要求部１４０は、一時スケジュールデータを破棄する（ステップＳ３４）。つまり、スケジュールデータ更新要求部１４０は、フラッシュメモリへの書き込みが終了したため、不要となった一時スケジュールデータを破棄する。

続いて、図５を参照して、メインコントローラ１００側におけるスケジュールデータの変更時に、サブコントローラ２００側にてスケジュールデータの変更がなされた場合の動作について説明する。なお、ステップＳ２１〜Ｓ２６までの処理は図４と同じであるため省略する。以下、ステップＳ４１から説明する。

サブコントローラ２００側にてスケジュールデータの変更がある旨の判別結果を変更判別部２４０から得ると、スケジュールデータ更新処理部２３０は、変更箇所の重複の有無も変更判別部２４０から得る（ステップＳ４１）。つまり、変更判別部２４０は、サブコントローラ２００側の変更箇所と、メインコントローラ１００側の変更箇所とを確定し、両方の変更箇所が重複するかどうかについても判別するため、スケジュールデータ更新処理部２３０は、重複の有無の判別結果も変更判別部２４０から得る。

スケジュールデータ更新処理部２３０は、新しいスケジュールデータを作成する（ステップＳ４２）。すなわち、スケジュールデータ更新処理部２３０は、重複の有無の判別結果に応じて、変更後のスケジュールデータを生成する。例えば、変更箇所が重複していない場合（メインコントローラ１００側の変更箇所と、サブコントローラ２００側の変更箇所とが異なる場合）に、スケジュールデータ更新処理部２３０は、２つの変更箇所を統合して変更後のスケジュールデータを生成する。なお、変更箇所が重複していても優先順位が定められている場合には、優先順位の高い方の変更箇所だけを反映させた変更後のスケジュールデータを生成する。例えば、サブコントローラ２００側の方が優先順位が高い場合に、スケジュールデータ更新処理部２３０は、サブコントローラ２００側による変更箇所だけを反映させた変更後のスケジュールデータを生成する。

スケジュールデータ更新処理部２３０は、スケジュールデータの更新予約拒絶通知と、新しいスケジュールデータとをメインコントローラ１００に送信する（ステップＳ４３）。すなわち、更新予約を拒絶した旨の通知であるスケジュールデータの更新予約拒絶通知と、ステップＳ４２にて生成した新しいスケジュールデータとを、スケジュールデータ更新処理部２３０は、通信部２１０を制御して、メインコントローラ１００に送信する。

スケジュールデータ更新要求部１４０は、一時スケジュールデータを破棄し、警告メッセージを表示部に表示すると共に、新しいスケジュールデータを表示部に表示する（ステップＳ４４）。すなわち、スケジュールデータ更新要求部１４０は、ユーザが行ったスケジュール変更が拒絶されたことを報知するための警告メッセージを表示部に表示する。また、スケジュールデータ更新要求部１４０は、送られた新しいスケジュールデータに基づいて自身（メインコントローラ１００）の仮スケジュールデータを更新し、一時スケジュールデータを破棄する。そして、更新後の仮スケジュールデータを元にして、メインコントローラ１００の表示部には、最新のスケジュールが反映された設定画面が表示される。そして、ユーザは、メインコントローラ１００の操作受け付け部からスケジュール設定画面を操作して、仮スケジュールデータの変更が再度行えるようになる。

以上説明したように、メインコントローラ１００からの取得要求に応答して、サブコントローラ２００のフラッシュメモリに格納されているスケジュールデータが読み出されてメインコントローラ１００に送信される。そして、このスケジュールデータに対する変更がメインコントローラ１００が操作されてなされると、変更されたスケジュールデータがサブコントローラ２００に送信される。サブコントローラ２００は、変更されたスケジュールデータを自身のフラッシュメモリに書き込む前に、スケジュールデータの更新予約完了通知をメインコントローラ１００に送信する。そして、メインコントローラ１００は、このスケジュールデータの更新予約完了通知を契機に、変更されたスケジュールデータを自身のフラッシュメモリに書き込む。これによって、分散して管理されているデータを集めて変更可能とすると共に、変更されたデータを同一のタイミングで更新することができる。

また、メインコントローラ１００側にてスケジュールデータが変更されている状態で、サブコントローラ２００側にてスケジュールデータの変更がなされたかどうかを判別し、変更がなされれば、メインコントローラ１００側にスケジュールデータの更新予約拒絶通知が送られて、警告メッセージが表示される。このため、メインコントローラ１００側のユーザは、自分が行ったスケジュール変更が拒絶されたこと知ることになる。なお、サブコントローラ２００側にて変更がなされても、その変更箇所が、メインコントローラ１００側の変更箇所と重ならない場合には、両方の変更を同時に反映可能となる。そのため、サブコントローラ２００は、両方の変更箇所を統合した新しいスケジュールデータを生成して、メインコントローラ１００に送信する。なお、変更箇所が重複していても優先順位が定められている場合には、優先順位の高い方の変更箇所だけを反映させた変更後のスケジュールデータを生成する。このような新しいスケジュールデータを受信したメインコントローラ１００は、新しいスケジュールデータが反映された設定画面を表示し、スケジュールデータの変更をユーザが再度行えるようにする。

また、メインコントローラ１００とサブコントローラ２００との間で、スケジュールデータを送受信する際に、暗号化と復号化とを行っているため、改変や盗聴などの危険性を排除し、安全に集めて、更新することができる。

なお、以上の説明においては、メインコントローラ１００側の変更箇所とサブコントローラ２００側の変更箇所が重複した場合に、サブコントローラ２００の変更を優先する場合について説明したが、メインコントローラ１００の変更を優先するようにしてもよい。

（実施形態２）
上記の実施形態１に係る空調システム１は、上述した図１に示す構成であったが、他に図６に示すような構成としてもよい。図６に示す本発明の実施形態２に係る空調システム２では、管理情報表示装置４００を構成に追加した点において、実施形態１の空調システム１と異なる。なお、以下の説明において、実施形態１と共通する構成要素などについては、同一の符号を付す。

図６に示すように、空調システム２は、各空調機３００を制御するメインコントローラ１００及び各サブコントローラ２００に加えて、管理情報表示装置４００も、ネットワーク１０を介して接続されて構成される。この空調システム２も、例えば、ビル等の建物に配置され、建物内の全ての空調機３００を制御（監視等も含む）する。一例として、メインコントローラ１００やサブコントローラ２００は、各フロアに配置され、それぞれ、フロア内の各空調機３００を制御する。また、管理情報表示装置４００は、中央制御室等に配置される。

メインコントローラ１００、サブコントローラ２００（２００ａ，２００ｂ）、及び、空調機３００（３００ａ〜３００ｉ）の構成は、上述した実施形態１に係る空調システム１と同様である。

管理情報表示装置４００は、例えば、Ｗｅｂブラウザを実行可能な汎用的なＰＣ（Personal Computer）等からなり、ユーザに操作される。Ｗｅｂブラウザが実行された管理情報表示装置４００は、ネットワーク１０を介して、メインコントローラ１００のＷｅｂサーバ１２０にアクセスし、メインコントローラ１００を操作可能となっている。つまり、実施形態２に係る空調システム２は、ユーザがメインコントローラ１００を直接操作する代わりに、管理情報表示装置４００のＷｅｂブラウザからメインコントローラ１００を間接的に操作する点で、実施形態１の空調システム１と異なっている。

管理情報表示装置４００のＷｅｂブラウザを通じてユーザに操作されるメインコントローラ１００は、上述した実施形態１と同様に、スケジュールデータの取得動作やスケジュールデータの更新動作を行う。

例えば、ユーザが管理情報表示装置４００を操作して、どの空調機３００のスケジュールデータを変更するかや、その際どの空調機３００のスケジュールデータを元に変更するかなどを選択すると、メインコントローラ１００は、スケジュールデータの取得動作を行う。

すなわち、メインコントローラ１００は、サブコントローラ２００に対してスケジュールデータの取得を要求する。サブコントローラ２００は、自身のフラッシュメモリに格納されたスケジュールデータ（より詳細には、使用区画管理部２９０が使用区画として指し示している区画に格納されたスケジュールデータ２８０）を読み出して、メインコントローラ１００に送信する。そして、メインコントローラ１００のＷｅｂサーバ１２０によって、管理情報表示装置４００のＷｅｂブラウザにスケジュール設定画面が表示される。ユーザは、管理情報表示装置４００に表示されるスケジュール設定画面を操作して、スケジュールデータの変更が行えるようになる。

そして、ユーザが管理情報表示装置４００を操作して、スケジュールデータの変更を行った後、変更の完了を示す「スケジュール設定ボタン」を押下すると、メインコントローラ１００は、スケジュールデータの更新動作を行う。

すなわち、メインコントローラ１００は、変更されたスケジュールデータをサブコントローラ２００に送信すると共に、スケジュールデータの更新予約を要求する。サブコントローラ２００は、待機時間内において、操作受け付け部を操作するユーザによって、スケジュールデータの変更が行われたかどうかを判別した後、変更されたスケジュールデータを自身のフラッシュメモリに書き込む前に、スケジュールデータの更新予約完了通知、又は、スケジュールデータの更新予約拒絶通知と新しいスケジュールデータをメインコントローラ１００に送信する。そして、メインコントローラ１００は、スケジュールデータの更新予約完了通知が送られた場合に、変更されたスケジュールデータを自身のフラッシュメモリに書き込む。一方、スケジュールデータの更新予約拒絶通知が送られた場合に、警告メッセージを表示すると共に、新しいスケジュールデータに基づいて、スケジュール設定画面を更新する。

これによって、分散して管理されているデータを集めて変更可能とすると共に、変更されたデータを同一のタイミングで更新することができる。また、警告メッセージによって、ユーザが行ったスケジュール変更が拒絶されたこと知らせることができる。更に、新しいスケジュールデータが反映された設定画面を表示し、スケジュールデータの変更をユーザが再度行えるようにすることができる。

また、メインコントローラ１００とサブコントローラ２００との間で、スケジュールデータを送受信する際に、暗号化と復号化とが行われる。このため、改変や盗聴などの危険性を排除し、安全に集めて、更新することができる。

（他の実施形態）
上記の実施形態１，２では、メインコントローラ１００とサブコントローラ２００との間で、スケジュールデータを送受信する場合について説明したが、空調システム１，２で使用するデータは、このようなスケジュールデータに限られず他のデータであってもよい。例えば、ログデータや特殊運転（一例として、省エネ運転）のための制御データというように、空調機３００の制御に関する関連データであれば、データの内容等は任意である。

上記の実施形態１，２では、設備機器を制御する設備機器システムの一例として、空調システム１，２について説明したが、他のシステムにおいても同様に本発明を適用することができる。例えば、設備機器として照明を制御する照明システムなどにも、本発明を適宜適用可能である。

上記の実施形態では、専用のコントローラ（メインコントローラ１００やサブコントローラ２００）を用いる場合について説明したが、このような専用のコントローラの動作を規定するプログラムを既存のパーソナルコンピュータや情報端末機器などに適用することで、当該パーソナルコンピュータなどを本発明に係るメインコントローラ１００やサブコントローラ２００として機能させることも可能である。

また、このようなプログラムの配布方法は任意であり、例えば、ＣＤ−ＲＯＭ（Compact Disk Read-Only Memory）、ＤＶＤ（Digital Versatile Disk），ＭＯ（Magneto Optical disk），メモリカードなどのコンピュータ読み取り可能な記録媒体に格納して配布してもよいし、インターネットなどの通信ネットワークを介して配布してもよい。

本発明は、広義の精神と範囲を逸脱することなく、様々な実施形態及び変形が可能とされるものである。また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施形態ではなく、請求の範囲によって示される。そして、請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。

本発明は、分散して管理されているデータを集めて変更可能とすると共に、同時にデータの変更要求が発生した場合であっても、不具合を生じさせないようにすることのできる設備機器システム、及び、制御装置に採用され得る。

１，２ 空調システム、１０ ネットワーク、２０ 制御バス、１００ メインコントローラ、１１０，２１０ 通信部、１２０ Ｗｅｂサーバ、１３０ スケジュールデータ取得要求部、１４０ スケジュールデータ更新要求部、１５０ ＷｅｂＳｏｃｋｅｔクライアント、１６０，２６０ 復号化部、１７０，２７０ 暗号化部、１８０，２８０ スケジュールデータ、１９０，２９０ 使用区画管理部、２００ サブコントローラ、２２０ スケジュールデータ取得処理部、２３０ スケジュールデータ更新処理部、２４０ 変更判別部、２５０ ＷｅｂＳｏｃｋｅｔサーバ、３００ 空調機、４００ 管理情報表示装置

Claims (6)

1. 設備機器を制御する第１の制御装置及び第２の制御装置がネットワークを介して接続された設備機器システムであって、
   前記第１の制御装置は、
   前記設備機器の制御に関するデータを記憶する第１の記憶部と、
   前記第２の制御装置に記憶されているデータを取得し、当該データへの変更が前記第１の制御装置を操作するユーザによってなされると、変更後データを前記第２の制御装置に送信して更新を要求するデータ更新要求部と、
   前記変更後データを送信した後に、前記第２の制御装置から送られる通知内容に従って、前記第１の記憶部にデータを書き込むデータ更新処理部と、を備え、
   前記第２の制御装置は、
   前記設備機器の制御に関するデータを記憶する第２の記憶部と、
   前記第１の制御装置から送られた前記変更後データを取得後、前記第２の制御装置を操作するユーザによる前記第２の記憶部に記憶されたデータに対する変更の有無を判別する判別部と、
   前記判別部による判別結果に従って、前記変更後データを前記第２の記憶部に書き込むデータ更新処理部と、を備え、
   前記第２の制御装置の前記データ更新処理部は、前記判別部がデータに対する変更がないと判別した場合に、前記変更後データの更新を許諾する許諾通知を前記第１の制御装置に送信し、前記判別部がデータに対する変更があると判別した場合に、前記変更後データの更新を拒絶する拒絶通知を前記第１の制御装置に送信し、
   前記第１の制御装置の前記データ更新処理部は、前記第２の制御装置から前記許諾通知が送られた場合に、前記第１の記憶部に前記変更後データを書き込み、前記第２の制御装置から前記拒絶通知が送られた場合に、前記第１の制御装置を操作するユーザに対して変更が拒絶されたことを報知する、
   設備機器システム。
2. 前記第２の制御装置の前記データ更新処理部は、前記拒絶通知を送信する場合に、前記判別部が判別したデータに対する変更に従って生成した第２の変更後データと共に前記第１の制御装置に送信し、
   前記第１の制御装置の前記データ更新処理部は、前記第２の制御装置から前記拒絶通知が送られた場合に、前記拒絶通知と共に送られた前記第２の変更後データの内容を、前記第１の制御装置を操作するユーザに報知する、
   請求項１に記載の設備機器システム。
3. 前記判別部は、前記第１の制御装置から送られた前記変更後データに従った第１の更新箇所と、前記第２の記憶部に記憶されたデータに対する変更に従った第２の更新箇所とが重複しない場合に、当該第１の更新箇所と当該第２の更新箇所とを統合して前記第２の変更後データを生成する、
   請求項２に記載の設備機器システム。
4. 前記判別部は、前記第１の制御装置から送られた前記変更後データに従った第１の更新箇所と、前記第２の記憶部に記憶されたデータに対する変更に従った第２の更新箇所とが重複する場合に、予め定められた優先順位に従って、当該第１の更新箇所及び当該第２の更新箇所の何れかに従った前記第２の変更後データを生成する、
   請求項２に記載の設備機器システム。
5. 前記設備機器は、空調機であり、
   前記データは、前記空調機を制御するためのスケジュールデータであり、
   前記第１の記憶部及び前記第２の記憶部は、フラッシュメモリである、
   請求項１に記載の設備機器システム。
6. 第１の制御装置とネットワークを介して接続され、第２の制御装置として設備機器を制御する制御装置であって、
   前記設備機器の制御に関するデータを記憶する記憶部と、
   前記第１の制御装置から更新が要求される変更後データを取得後、前記第２の制御装置を操作するユーザによる前記記憶部に記憶されたデータに対する変更の有無を判別する判別部と、
   前記判別部による判別結果に従って、前記変更後データを前記記憶部に書き込むデータ更新処理部と、を備え、
   前記データ更新処理部は、前記判別部がデータに対する変更がないと判別した場合に、前記変更後データの更新を許諾する許諾通知を前記第１の制御装置に送信し、前記判別部がデータに対する変更があると判別した場合に、前記変更後データの更新を拒絶する拒絶通知を前記第１の制御装置に送信する、
   制御装置。

Images