JP2015228076A - 設備機器システム、および、コントローラ - Google Patents

Abstract

【課題】分散して管理されているデータを集めて変更可能とすると共に、変更されたデータを同一のタイミングで更新することのできる設備機器システム等を提供する。
【解決手段】スケジュールデータ取得要求部１３０は、サブコントローラ２００にスケジュールデータを要求して取得する。取得したスケジュールデータに対する変更がなされると、スケジュールデータ更新要求部１４０は、変更されたスケジュールデータをサブコントローラ２００に送信して更新を要求する。スケジュールデータ更新処理部２３０は、更新要求に対する受諾通知をメインコントローラ１００に送信し、変更されたスケジュールデータを自身のフラッシュメモリに書き込む。一方、スケジュールデータ更新要求部１４０は、サブコントローラ２００からの受諾通知を契機に、変更後のスケジュールデータを自身のフラッシュメモリに書き込む。
【選択図】図２

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 (9)

1. 設備機器を制御する第１及び第２のコントローラがネットワークを介して接続された設備機器システムであって、
   前記第１のコントローラは、
   前記設備機器の制御に関する関連データを格納するための第１の記憶部と、
   前記第２のコントローラに対して関連データの取得を要求し、前記第２のコントローラから送られた前記関連データを取得するデータ取得要求部と、
   前記第２のコントローラから取得した前記関連データに対する変更が、ユーザの操作に従ってなされると、変更後関連データを前記第２のコントローラに送信して更新を要求するデータ更新要求部と、を備え、
   前記第２のコントローラは、
   前記設備機器の制御に関する関連データを格納するための第２の記憶部と、
   前記第１のコントローラからの取得要求に応答して、前記第２の記憶部に格納されている前記関連データを読み出して前記第１のコントローラに送信するデータ取得処理部と、
   前記第１のコントローラから送られた前記変更後関連データ、及び、更新要求に応答して、前記変更後関連データを前記第２の記憶部に書き込むデータ更新処理部と、を備え、
   前記第２のコントローラにおける前記データ更新処理部は、前記変更後関連データを前記第２の記憶部に書き込む前に、前記更新要求に対する受諾通知を前記第１のコントローラに送信し、
   前記第１のコントローラにおける前記データ更新要求部は、前記第２のコントローラから送られた前記受諾通知を契機に、前記変更後関連データを前記第１の記憶部に書き込む、
   ことを特徴とする設備機器システム。
2. 前記第２のコントローラは、
   データの暗号化を行う暗号化部を更に備え、
   前記データ取得処理部は、前記暗号化部によって暗号化された前記関連データを、前記第１のコントローラに送信し、
   前記第１のコントローラは、
   データの復号化を行う復号化部を更に備え、
   前記データ取得要求部は、前記第２のコントローラから送られた暗号化された前記関連データを、前記復号化部によって復号化する、
   ことを特徴とする請求項１に記載の設備機器システム。
3. 前記第１のコントローラは、
   データの暗号化を行う暗号化部を更に備え、
   前記データ更新要求部は、前記暗号化部によって暗号化された前記変更後関連データを、前記第２のコントローラに送信し、
   前記第２のコントローラは、
   データの復号化を行う復号化部を更に備え、
   前記データ更新処理部は、前記第１のコントローラから送られた暗号化された前記変更後関連データを、前記復号化部によって復号化する、
   ことを特徴とする請求項１又は２に記載の設備機器システム。
4. 前記第１の記憶部には、前記関連データを格納する区画が複数設けられており、
   前記第１のコントローラは、
   前記第１の記憶部における全区画のうちの１つを、前記設備機器の制御に使用するための使用区画として指し示す使用区画管理部を更に備え、
   前記データ取得要求部は、前記使用区画管理部にて前記使用区画として指し示されていない区画に、前記変更後関連データを書き込み、
   前記使用区画管理部は、前記第２のコントローラから前記受諾通知が送られた時点から一定時間経過後に、前記データ取得要求部が前記変更後関連データを書き込んだ区画を、使用区画として指し示す、
   ことを特徴とする請求項１から３の何れか１項に記載の設備機器システム。
5. 前記第２の記憶部には、前記関連データを格納する区画が複数設けられており、
   前記第２のコントローラは、
   前記第２の記憶部における全区画のうちの１つを、前記設備機器の制御に使用するための使用区画として指し示す使用区画管理部を更に備え、
   前記データ更新処理部は、前記使用区画管理部にて前記使用区画として指し示されていない区画に、前記変更後関連データを書き込み、
   前記使用区画管理部は、前記データ更新処理部が前記受諾通知を前記第１のコントローラに送信した時点から一定時間経過後に、前記データ更新処理部が前記変更後関連データを書き込んだ区画を、使用区画として指し示す、
   ことを特徴とする請求項１から４の何れか１項に記載の設備機器システム。
6. 前記第１のコントローラと前記第２のコントローラとの間は、ＷｅｂＳｏｃｋｅｔ規格に沿って通信が行われる、
   ことを特徴とする請求項１から５の何れか１項に記載の設備機器システム。
7. 前記設備機器は、空調機であり、
   前記関連データは、前記空調機を制御するためのスケジュールデータであり、
   前記第１及び第２の記憶部は、フラッシュメモリである、
   ことを特徴とする請求項１から６の何れか１項に記載の設備機器システム。
8. 設備機器を制御する他のコントローラと通信可能なコントローラであって、
   前記設備機器の制御に関する関連データを格納するための記憶部と、
   前記他のコントローラに対して関連データの取得を要求し、前記他のコントローラから送られた前記関連データを取得するデータ取得要求部と、
   前記他のコントローラから取得した前記関連データに対する変更が、ユーザの操作に従ってなされると、変更後関連データを前記他のコントローラに送信して更新を要求するデータ更新要求部と、を備え、
   前記データ更新要求部は、更新要求に応答して前記他のコントローラから送られた受諾通知を契機に、前記変更後関連データを前記記憶部に書き込む、
   ことを特徴とするコントローラ。
9. 他のコントローラと通信可能な、設備機器を制御するコントローラであって、
   前記設備機器の制御に関する関連データを格納するための記憶部と、
   前記他のコントローラからの取得要求に応答して、前記記憶部に格納されている前記関連データを読み出して前記他のコントローラに送信するデータ取得処理部と、
   前記他のコントローラから送られた変更後関連データ、及び、更新要求に応答して、前記変更後関連データを前記記憶部に書き込むデータ更新処理部と、を備え、
   前記データ更新処理部は、前記変更後関連データを前記記憶部に書き込む前に、前記更新要求に対する受諾通知を前記他のコントローラに送信する、
   ことを特徴とするコントローラ。

Images