JP2019124414A - 空調制御システム及び空調制御方法 - Google Patents

Abstract

【課題】環境センサのグループを作成し、その後に、各空調機をいずれかのグループに対応付ける方法が採用された場合、いずれか空調機が、異なる２以上のグループに対応付けられることがあり得る。【解決手段】エリアの空調を行う複数の空調機を制御する空調制御システムが、エリアにおける複数のブロックを基に１以上のゾーンの構成であるゾーン構成を決定し、ゾーンベースで複数の空調機を制御する。ゾーン構成は、ゾーン数（ゾーンの数）とゾーンメンバ（ゾーンを構成するメンバとしてのブロック）とのうちの少なくとも１つである。複数のブロックの各々について、当該ブロックは、複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲である。１以上のゾーンの各々について、当該ゾーンは、複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである。【選択図】図１

Description

本発明は、概して、空調制御に関し、特に、エリアの空調を行う複数の空調機の制御に関する。

エリアの空調を行う複数の空調機を制御する空調制御システムとして、特許文献１に記載の空調制御システムが知られている。特許文献１によれば、次のことが記載されている。複数の空調機と複数の環境センサがエリアに配置されている。空調制御システムは、配置された複数の環境センサを、当該複数の環境センサから取得された環境情報間の相関係数に基づき２以上のグループに分類する。空調制御システムは、２以上のグループと複数の空調機を対応付ける。空調制御システムは、各空調機を、当該空調機に対応付けられたグループ内の環境センサからの環境情報を基に、制御する。

WO2016/121390

特許文献１によれば、まず、環境センサのグループが作成され、その後に、各空調機がいずれかのグループに対応付けられる。このため、同一の空調機がカバーする範囲に２以上の環境センサが存在するエリアでは、その２以上の環境センサがそれぞれ異なる２以上のグループに分類されることがあり、結果として、当該空調機が、異なる２以上のグループに対応付けられることがある。特許文献１によれば、グループ単位で空調機が制御されるが、２以上のグループに対応付けられた空調機をグループ単位で制御することは困難である。

エリアの空調を行う複数の空調機を制御する空調制御システムが、エリアにおける複数のブロックを基に１以上のゾーンの構成であるゾーン構成を決定するゾーン決定処理を行うゾーン決定部と、各ゾーンについて、当該ゾーンにおけるゾーンベースの制御対象ブロックに対応した空調機をゾーンベースで制御する空調制御を行う空調制御部とを有する。ゾーン構成は、ゾーン数（ゾーンの数）とゾーンメンバ（ゾーンを構成するメンバとしてのブロック）とのうちの少なくとも１つである。複数のブロックの各々について、当該ブロックは、複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲である。１以上のゾーンの各々について、当該ゾーンは、複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである。

本発明によれば、いずれの空調機も異なる２以上のゾーンに分類されないようになっているので、ゾーンベース（ゾーン単位）の空調制御が可能である。

実施例１に係るＨＶＡＣ制御システムを含んだシステム全体の構成例を示す。 ＨＶＡＣ制御システムの構成例を示す。 ゾーン決定処理の流れを示す。 ゾーンテーブルの構成とゾーンテーブルの変更例とを示す。 フィードバック分析処理及び最適化処理とで構成された処理の流れを示す。 ユーザフィードバックテーブルの構成を示す。 温熱快適指標値（Φ^ＴＣ _ｔ）の算出の模式図の一例である。 各ブロックの時系列の温度遷移と、複数の時点でのゾーン構成との一例を示す。 実施例２に係る効率評価処理の流れを示す。 実施例３に係る管理者画面の一例を示す。 実施例３に係る一般ユーザ画面の一例を示す。 推奨プログラムが行う処理の模式図の一例である。

以下の説明では、「インターフェース部」は、１以上のインターフェースでよい。当該１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。

また、以下の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイスである。

また、以下の説明では、「記憶部」は、メモリ部及びＰＤＥＶ部のうちの少なくとも１つ（典型的には少なくともメモリ部）である。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサである。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。少なくとも１つのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つのプロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及び／又はインターフェース部等を用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有するコントローラのようなデバイス）とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な（例えば非一時的な）記録媒体であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる構造体を説明することがあるが、構造体は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ構造体」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明では、「データセット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペア及びタプルのうちのいずれでもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別して説明する場合は、要素のＩＤを使用することがある。例えば、ブロックを特に区別しないで説明する場合には、「ブロック１３０」と記載し、個々のブロックを区別して説明する場合には、「ブロック１」、「ブロック２」のように記載することがある。

また、以下の説明では、エリアの空調を行う複数の空調機を制御する空調制御システムとして、ＨＶＡＣ（Heating Ventilation and Air Conditioning）制御システムが採用される。

図１は、実施例１に係るＨＶＡＣ制御システムを含んだシステム全体の構成例を示す。

空調制御対象のエリア１００がある。エリア１００は、例えば、１つの部屋であり、具体的には、例えば、オフィスビルのような商業ビルにあるオフィスルーム、サーバルーム、休憩ルーム、会議室及びスポーツルームのような部屋である。エリア１００は、囲まれた空間でも囲まれていない空間でもよい。

エリア１００の空調を行う複数のＨＶＡＣユニット１６０（空調機の一例）にそれぞれ複数のＣＵ（制御ユニット）１４０が接続されており、複数のＣＵ（制御ユニット）１４０、及び、ＨＶＡＣ制御システム１８０が、インターネット１９５のような通信ネットワークに接続される。ＨＶＡＣ制御システム１８０が、インターネット１９５を介して、複数のＣＵ１４０に複数のコマンドを送信することで、複数のＨＶＡＣユニット１６０を制御する。エリア１００には、複数のシート１５０が配置されている。いずれかのシート１５０に座ってユーザが仕事又は休憩等を行うことができる。

ＨＶＡＣ制御システム１８０は、センサネットワークから定期的に又は不定期的に、エリア１００（エリア１００における複数のブロック１３０）に配置された複数の環境センサ１２０の各々についてセンサデータセットを、インターネット１９５を介して受信する。各環境センサ１２０について、センサデータセットは、センサＩＤ（環境センサ１２０のＩＤ）、温熱パラメータ値（環境メトリック値の一例）、及び、タイムスタンプ（日時を表す情報）を含む。センサネットワークは、後述するように、エリア１００に配置された複数の環境センサ１２０を含む。複数の環境センサ１２０の各々が、温熱パラメータ値を測定する。測定された温熱パラメータ値を含むセンサデータセットが、ＨＶＡＣ制御システム１８０に送信される。従って、ＨＶＡＣ制御システム１８０は、いわゆるＩｏＴ（Internet Of Things）ベースのシステムである。なお、「温熱パラメータ」とは、環境パラメータの一例であり、例えば、温度、湿度、ＣＯ_２レベル（ＣＯ_２濃度）及び気圧といったパラメータである。「温熱パラメータ値」とは、環境パラメータ値の一例であり、例えば、２５℃（温度の値）、５０％（湿度の値）、２８０ｐｐｍ（ＣＯ_２レベルの値）といったパラメータ値である。なお、本実施例では、「温度」は、内部温度（エリア１００において検出された温度）を意味し、「湿度」は、内部湿度（エリア１００において検出された湿度）を意味する。本実施例では、エリア１００外（例えば屋外）の温度を、「外部温度」と言い、エリア１００外の湿度を、「外部湿度」と言う。

本実施例では、ティア１及びティア２といった複数のティアが定義されており、空調制御は、ティア１及びティア２の両方を基に行われる。

ティア１は、エリア１００、具体的には、エリア１００の機能性である。例えば、オフィスルーム、サーバルーム、休憩ルーム及び会議室は、いずれも機能性が異なるため、同一の空間にそれらが存在していたとしても、それらは異なるエリアである。エリア１００は、物理的であり、固定的である。

ティア２は、ティア１よりも上位のティアである。ティア２は、エリア１００における１以上のゾーン１１０、具体的には、エリア１００の仮想的な１以上の区画である。各ゾーン１１０は、１以上のホモジニアスのブロック１３０の集合である。ブロック１３０は、ＨＶＡＣユニット１６０毎に存在し、対応するＨＶＡＣユニット１６０が影響する（カバーする）範囲である。ゾーン１１０は、仮想的であり、動的に変更される。具体的には、例えば、定期的に、ＨＶＡＣ制御システム１８０が、複数の環境センサ１２０に対応した複数のセンサデータセットをセンサネットワークから受信し、当該複数のセンサデータセット中の複数の温熱パラメータ値に基づく１以上のゾーン決定ファクタを含む複数のゾーン決定ファクタを基に、ゾーン数（ゾーン１１０の数）、及び、ゾーンメンバ（いずれの１以上のブロック１３０をいずれのゾーン１１０とするか）を、決定する。ゾーン数及びゾーンメンバは、ゾーン構成の一例である。エリア１００の機能性によって、いずれの温熱パラメータを優先するかが異なり（つまり、エリア１００の機能性が異なれば、同一の温熱パラメータであっても優先度が異なり）、ゾーン数及びゾーンメンバのうちの少なくとも１つは、エリア１００の機能性に従うキー温熱パラメータ（相対的に優先される（例えば最も優先される）温熱パラメータ）の温熱パラメータ値を基に決定される。

なお、上述したように、エリア１００の機能性によってキー温熱パラメータは異なる。例えば、エリア１００がオフィスルームの場合、キー温熱パラメータは温度である。エリア１００がサーバルームの場合、キー温熱パラメータは湿度である。エリア１００が会議室の場合、キー温熱パラメータはＣＯ_２レベルである。エリア１００がスポーツルームの場合、キー温熱パラメータは代謝率である。

また、いずれの１以上のブロック１３０が、ホモジニアスなブロック１３０であるかは、エリア１００の機能性と各ブロック１３０の１以上の温熱パラメータの温熱パラメータ値とに依存する。

図２は、ＨＶＡＣ制御システム１８０の構成例を示す。

ＨＶＡＣ制御システム１８０は、インターフェース部２９０、記憶部２１０及びそれらに接続されたプロセッサ部２８０を有する。インターフェース部２９０、記憶部２１０及びプロセッサ部２８０は、例えば、１以上の計算機で構成されたシステム（例えばクラウド基盤）に存在してよい。

インターフェース部２９０を介して、センサデータセットがセンサネットワーク２００から受信される。受信されたセンサデータセットが記憶部２１０に格納される。記憶部２１０には、例えば、センサデータセットのデータベースが存在する。例えば、記憶部２１０には、環境センサ１２０毎に、時系列の温熱パラメータ値が格納されることになる。センサデータセット中の日時は、年月日時分秒で表現されるが、別の表現が採用されてもよい。センサネットワーク２００は、複数の環境センサ１２０と、ゲートウェイ１９１と、複数の環境センサ１２０からゲートウェイ１９１を介して温熱パラメータ値を受けて格納し格納された温熱パラメータ値を含んだセンサデータセットをＨＶＡＣ制御システム１８０に送信する中継計算機（例えばパーソナルコンピュータ）１９２とを含む。センサデータセットは、環境センサ１２０から受信されてもよいし、環境センサ１２０からの温熱パラメータ値を基に中継計算機１９２により生成されてもよい。中継計算機１９２が複数の環境センサ１２０から温熱パラメータ値を受信する周期と、中継計算機１９２がＨＶＡＣ制御システム１８０にセンサデータセットを送信する周期は、同じあって異なっていてもよい。また、キー温熱パラメータ値を出力する環境センサ１２０であるか、キー温熱パラメータ値以外のパラメータ値を出力する環境センサ１２０であるかに応じて、中継計算機１９２の受信周期及び送信周期の少なくとも１つが異なっていてもよい。また、中継計算機１９２は、少なくとも１つの環境センサ１２０について、当該環境センサ１２０から一定期間に受信した複数の温熱パラメータ値に基づく温熱パラメータ値（例えば平均値）を取得し、取得した温熱パラメータ値を含んだセンサデータセットをＨＶＡＣ制御システム１８０に送信してもよい。

また、インターフェース部２９０を介して、天候情報２９１、ＨＶＡＣ／センサマッピングテーブル２９２、ユーザロケーション２９３、ユーザフィードバック２９４、及びＨＶＡＣデータ２９５が受信される（これらの情報２９１〜２９５のうちの一部の情報（例えば天候情報２９１）は無くてもよい）。天候情報２９１（例えばリアルタイムの天候情報）は、例えば定期的に、外部のサイト（サーバ）から受信される。ＨＶＡＣ／センサマッピングテーブル２９２は、ＨＶＡＣユニット１６０とブロック１３０と環境センサ１２０との対応関係（いずれの環境センサ１２０がいずれのＨＶＡＣユニット１６０に対応したブロック１３０に属するか）を示すテーブルであり、例えば管理者の端末から受信される。ＨＶＡＣ／センサマッピングテーブル２９２は、例えば、環境センサ１２０毎に、センサＩＤ、ＨＶＡＣユニットＩＤ、ブロックＩＤ及びブロック範囲情報（ブロックの位置的範囲を示す情報であって、例えばユーザロケーション２９３をキーに参照される情報）を含んでよい。ユーザロケーション２９３は、エリア１００におけるロケーションを示す情報であって、エリア１００における図示しないデスクトップＰＣ（Personal Computer）のＩＤ（例えば、ＩＰアドレスやＭＡＣアドレス）を基に特定されたデスクトップＰＣロケーションを示す情報であってもよいし、スマートフォンのようなモバイル端末のＧＰＳ機能により取得されたロケーションを示す情報であってもよい。ユーザフィードバック２９４は、温熱環境についてユーザの感想（例えば、“Ｈｏｔ”、“Ｃｏｌｄ”又は“ＯＫ”（快適）といった感想）を示す情報であり、エリア１００におけるユーザ端末から受信される。「ユーザ端末」は、通信機能を有する計算機であり、エリア１００におけるデスクトップＰＣ及びモバイル端末のいずれでもよい。ユーザフィードバック２９４に、当該ユーザフィードバック２９４を入力したユーザのロケーションを示すユーザロケーション２９３が関連付けられていてもよい。また、ユーザフィードバック２９４は、ユーザ端末で実行されるＡＰＩ（Application Programming Interface）経由又はＷｅｂブラウザ経由で入力されてもよい。また、本実施例では、ユーザフィードバック２９４は、“Ｈｏｔ”、“Ｃｏｌｄ”及び“ＯＫ”の３つの選択肢からユーザにより選択された選択肢に相当するが、選択肢は３つより多くても少なくてもよいし（例えば更に“Ｖｅｒｙ ｈｏｔ”及び“Ｖｅｒｔ ｃｏｌｄ”があってもよいし）、選択に代えて又は加えてテキスト入力等が採用されてもよい。ＨＶＡＣデータ２９５は、ＨＶＡＣユニット１６０の稼働状況に関するデータ（例えば、消費電力、設定されている情報（例えば、温度、湿度、運転モード））であり、例えば定期的に、当該ＨＶＡＣユニット１６０から受信される。

プロセッサ部２８０が、空調モードを決定するデータアナライザ２２０、占有分析を行う占有アナライザ２３０、及び、ＨＶＡＣ制御を行うＨＶＡＣコントローラ２４０といったプログラムを実行する。ＨＶＡＣコントローラ２４０は、ゾーン決定処理を行うゾーンアナライザ２４１、フィードバック分析処理を行うフィードバックアナライザ２４２、及び、最適化処理を行うオプティマイザ２４３を有する。

ＨＶＡＣ制御システム１８０は、例えば以下の処理を行う。

ＨＶＡＣ制御システム１８０は、センサネットワーク２００から、定期的に、センサデータセットを受信し、記憶部２１０に、受信したセンサデータセットを格納する。また、ＨＶＡＣ制御システム１８０は、定期的に又は不定期的に、天候情報２９１、ＨＶＡＣ／センサマッピングテーブル２９２、ユーザロケーション２９３、ユーザフィードバック２９４及びＨＶＡＣデータ（例えば消費電力）２９５を受信する。受信された情報は、記憶部２１０に格納され、記憶部２１０からＨＶＡＣコントローラ２４０によって読み出されてもよい。なお、ＨＶＡＣ／センサマッピングテーブル２９２は、少なくとも１つの環境センサ１２０又は少なくとも１つのＨＶＡＣユニット１６０の移動又は増減によりＨＶＡＣユニット１６０と環境センサ１２０との対応関係が変更された場合には、更新される。また、受信したユーザロケーション２９３及びユーザフィードバック２９４等を基に後述のユーザフィードバックテーブル６００が生成され記憶部２１０に格納される。ユーザフィードバックテーブル６００は、例えば、フィードバックアナライザ２４２により生成及び更新される。

データアナライザ２２０が、ＨＶＡＣ／センサマッピングテーブル２９２及び各ユーザのユーザロケーション２９３を基に、ブロック１３０毎のユーザ数を特定し、占有アナライザ２３０に、ブロック１３０毎のユーザ数を通知する。占有アナライザ２３０が、ブロック１３０毎のユーザ数を基に、各ブロック１３０のＨＶＡＣユニット１６０の運転モードを決定し、各ブロック１３０のＨＶＡＣユニット１６０の運転モードをＨＶＡＣコントローラ２４０に通知する。なお、データアナライザ２２０及び占有アナライザ２３０の少なくとも１つは、ＡＩ（Artificial Intelligence）プログラムのような学習プログラムでもよく、十分に学習（例えば、エリア１００における占有パターン（例えば、時間帯と、ブロック１３０毎のユーザ数との関係）の認識）が済んだら、データアナライザ２２０及び占有アナライザ２３０の実行はスキップされてもよい。また、データアナライザ２２０及び占有アナライザ２３０に代えて、予め各ＨＶＡＣユニット１６０の運転モードが時間帯毎に決められていてもよい。各ＨＶＡＣユニット１６０の運転モードは、ゾーン数及びゾーンメンバの決定に利用されてもよい。

ＨＶＡＣコントローラ２４０におけるゾーンアナライザ２４１が、各環境センサ１２０の時系列のセンサデータセット（記憶部２１０における時系列のセンサデータセット）を基に、１以上のゾーン１１０（ゾーン数及びゾーンメンバ）を決定する。フィードバックアナライザ２４２が、ゾーンメンバと、各ブロック１３０についてのユーザフィードバック２９４の有無と等に基づいて、今回（ｔ）の温熱快適指標値（温熱指標値）Φ^ＴＣ _ｔと、今回の温熱快適指標値の最低値Φ^{ＴＣ，ｍｉｎ} _ｔとを決定する。オプティマイザ２４３は、ゾーンアナライザ２４１により決定されたゾーン１１０毎に、最適化処理を行う、すなわち、最適なＨＶＡＣパラメータ値を決定し、且つ、当該ゾーン１１０を構成する全ブロック１３０のうちの全制御対象ブロック１３０のＨＶＡＣユニット１６０に同一のコマンド（空調制御のコマンド）を送信する。

図３は、ゾーン決定処理の流れを示す。ゾーン決定処理は、定期的（例えばｎ分毎（ｎ＞０））にゾーンアナライザ２４１により行われる（例えばｎ＝３０）。

ゾーンアナライザ２４１は、ファクタＡ（エリア１００の大きさ）、ファクタＦ（エリア１００の機能性）、ファクタＰ（エリア１００の優先度）、ファクタＰｔ（エリア１００の全ＨＶＡＣユニット１６０の消費電力の上限）、及び、ファクタΔ_ｔ−ｎのうちの少なくとも１つを基に、エリア１００におけるゾーン１１０の数であるゾーン数を決定する（Ｓ３０１）。具体的には、例えば、ゾーン数＝ｆ（δΔ_ｔ−ｎ＋γＡ＋βＦ＋αＰ＋ωＰｔ）である。Δ_ｔ−ｎは、温熱偏差である。Δ_ｔ−ｎは、前回に得られた所定の温熱パラメータの温熱パラメータ値（例えば温度）のうちの最高値（Ｔ^ｈｉｇｈ _ｔ−ｎ）と、前回に得られた措定の温熱パラメータの温熱パラメータ値のうちの最低値（Ｔ^ｌｏｗ _ｔ−ｎ）との差分（Ｔ^ｈｉｇｈ _ｔ−ｎ−Ｔ^ｌｏｗ _ｔ−ｎ）である。「ｔ−ｎ」は、今回（ｔ）のｎ分前（例えば３０分前）を意味する。「所定の温熱パラメータ」は、キー温熱パラメータでよい。初回は、Δ_ｔ−ｎ無しにゾーン数が決定され、後に、定期的に、Δ_ｔ−ｎを基にゾーン数が更新される。δ、γ、β、α及びωの各々は、係数である。δ、γ、β、α及びωの各々の値は、ファクタＡ、Ｆ、Ｐ、Ｐｔ及びΔ_ｔ−ｎの各々の相対的な優先度（重み）に基づき決められている。δ、γ、β、α及びωの少なくとも１つは、エリア１００の機能性に応じた値とされてよい。ファクタＡ、Ｆ、Ｐ、Ｐｔ及びΔ_ｔ−ｎのうちの一部が無くてもよいし、ファクタＡ、Ｆ、Ｐ、Ｐｔ及びΔ_ｔ−ｎのうちの少なくとも一部が他のファクタに代替されてもよい。ゾーン１１０（ティア２）は、エリア１００（ティア１）上に存在するため、ゾーン数は、エリア１００に関する情報をファクタとして決定される。

ゾーンアナライザ２４１は、Ｓ３０１で決定されたゾーン数のゾーンの各々の構成を決定する（Ｓ３０２）。各ゾーンは、１以上のホモジニアスのブロック１３０で構成される。いずれの１以上のブロック１３０が、ホモジニアスのブロック１３０であるかは、本実施例では、温熱パラメータ値を基に決定される（後の実施例２では、温熱パラメータ値に代えて（又は加えて）、ユーザフィードバックを基に決定される）。１つのゾーン１１０を構成する１以上のホモジニアスのブロック１３０の決定は、ブロック１３０のクラスタ化に相当する。ブロック１３０のクラスタ化は、例えば、k-means clusteringのようなアルゴリズムを基に決定されてよい。ゾーンメンバの決定の際に使用されるブロック値（ブロック１３０毎の値）は、上述したように、本実施例では、温熱パラメータ値に基づく値であり、例えば、キー温熱パラメータ値でよい。各ブロック１３０について、２以上の温熱パラメータが採用されている場合、２以上の温熱パラメータ値に基づく１つの値（例えば温熱快適指標値Φ^ＴＣ _ｔ）を基に、ブロック１３０のクラスタ化が行われてもよい。また、ゾーンメンバにおいて、温熱パラメータ値の重みは、当該温熱パラメータ値に対応した環境センサ１２０の位置属性に応じて異なってもよい。例えば、窓近傍に配置された環境センサ１２０の温熱パラメータ値は、窓近傍とは異なる位置に配置された環境センサ１２０の温熱パラメータ値よりも、ＨＶＡＣユニット１６０の影響に加えて屋外の温熱環境（例えば、外部温度）の影響を受け易いと考えられるため、窓近傍に配置された環境センサ１２０の温熱パラメータ値の重みと、窓近傍とは異なる位置に配置された環境センサ１２０の温熱パラメータ値の重みが、異なっていてもよい。また、１つのゾーン１１０を構成する１以上のホモジニアスのブロック１３０は、温熱パラメータ値に依存するブロック値に代えて又は加えて、ブロック１３０の占有率（ブロック１３０に存在するユーザの数（ブロック１３０に属するユーザロケーション２９３の数）を基に決定されてもよい。例えば、ブロック値に基づくクラスタ化では、同一のグループに属しても、ユーザ数がゼロのブロック１３０とユーザ数が１以上のブロック１３０とで、異なるグループとなるよう異なるゾーンが構成されてもよい。

ゾーンアナライザ２４１は、Ｓ３０１及びＳ３０２の結果を基に、ゾーンテーブルを作成（更新）し、当該ゾーンテーブルを出力する（３０３）。ゾーンテーブルの構成は、例えば図４に示す通りである。例えば、ゾーンテーブル４００は、ゾーン１１０毎にエントリを有し、各エントリは、ゾーンＩＤ４０１（ゾーン１１０のＩＤ）、及び、ブロックＩＤ４０２（ブロック１３０のＩＤ）といった情報を格納する。図４に例示するように、１つのゾーンを構成するブロック１３０の数は、１であることもあれば、２以上であることもある。

以上のように、定期的に（ｎ分毎）にゾーン決定処理が行われるため、定期的にゾーン数及びゾーンメンバが動的に変わり得る（例えば図４参照）。

図５は、フィードバック分析処理及び最適化処理とで構成された処理の流れを示す。図５に示す処理も、定期的（例えばｎ分毎）に行われる。図５に示す処理が行われる周期は、ゾーン決定処理が行われる周期と同じでよい。図５に示す処理は、ゾーン決定処理の終了を契機に開始されてよい。具体的には、例えば、図５に示す処理は、ゾーンアナライザ２４１から出力されたゾーンテーブル４００をフィードバックアナライザ２４２が受けたときに開始される。また、フィードバック分析処理では、適宜、図６に例示するユーザフィードバックテーブル６００が参照される。ユーザフィードバック２９４を受信する都度に、例えばフィードバックアナライザ２４２により、ユーザフィードバックテーブル６００が更新される。いずれのブロック１３０についていずれのユーザフィードバック２９４が得られたかは、ユーザフィードバックテーブル６００から特定可能である。

ゾーンアナライザ２４１により決定された各ゾーン１１０について、図示のＳ５０１〜Ｓ５１１が行われる。以下、図５の説明において、１つのゾーン１１０を例に取る（図５の説明において「ターゲットゾーン１１０」）。

フィードバックアナライザ２４２は、ターゲットゾーン１１０について１つでもユーザフィードバック２９４があるか否かを判断する（Ｓ５０１）。例えば、受けたユーザフィードバック２９４に関連付いているユーザロケーション２９３をキーにＨＶＡＣ／センサマッピングテーブル２９２から特定されたブロック１３０が、当該ブロック１３０のブロックＩＤをキーにゾーンテーブル４００から特定されたゾーン１１０が、ターゲットゾーン１１０の場合に、Ｓ５０１の判断結果が真である。

Ｓ５０２の判断結果が偽の場合（Ｓ５０１：Ｎｏ）、フィードバックアナライザ２４２は、ターゲットゾーン１１０について、今回（ｔ）の温熱快適指標値の下限値Φ^{ＴＣ，ｍｉｎ} _ｔとして、デフォルトの下限値Φ^{ＴＣ，ｍｉｎ}を設定する（Ｓ５０２）。

Ｓ５０２の判断結果が真の場合（Ｓ５０１：Ｙｅｓ）、フィードバックアナライザ２４２は、ターゲットゾーン１１０について、ゾーンマジョリティユーザフィードバックを特定する（Ｓ５０３）。ターゲットゾーン１１０について、「ゾーンマジョリティユーザフィードバック」とは、ターゲットゾーン１１０についてマジョリティのユーザフィードバック２９４、具体的には、ターゲットゾーン１１０を構成する全ブロック１３０についての全ユーザフィードバック２９４のうち最も多いユーザフィードバック２９４である。より具体的には、例えば、フィードバックアナライザ２４２は、ターゲットゾーン１１０を構成する各ブロック１３０について、ブロックマジョリティユーザフィードバックも特定する。各ブロック１３０について、「ブロックマジョリティユーザフィードバック」とは、当該ブロック１３０についてマジョリティのユーザフィードバック２９４、具体的には、当該ブロック１３０についての全ユーザフィードバック２９４のうち最も多いユーザフィードバック２９４である。１以上のブロックマジョリティユーザフィードバックのうち最も多いブロックマジョリティユーザフィードバックが、ゾーンマジョリティユーザフィードバックである。

Ｓ５０３の後、フィードバックアナライザ２４２は、ターゲットゾーン１１０を構成する各ブロック１３０について、ブロックマジョリティユーザフィードバックがゾーンマジョリティフィードバックと同じか否かを判断する（Ｓ５０４）。フィードバックアナライザ２４２は、Ｓ５０４の判断結果が偽のブロック１３０（すなわち、ゾーンマジョリティフィードバックと異なるブロックマジョリティユーザフィードバックに対応したブロック１３０）を、制御対象ブロックから除外する（Ｓ５０５）。具体的には、例えば、各ブロック１３０に関する情報を保持するブロックテーブル（図示せず）が記憶部２１０に格納されていて、フィードバックアナライザ２４２は、Ｓ５０４の判断結果が偽のブロック１３０について、制御対象から除外することを意味するフラグをブロックテーブルに設定する。

Ｓ５０３の後、フィードバックアナライザ２４２は、ゾーンマジョリティユーザフィードバックが“ＯＫ”（快適）か否かを判断する（Ｓ５０６）。

Ｓ５０６の判断結果が真の場合（Ｓ５０６：Ｙｅｓ）、フィードバックアナライザ２４２は、ターゲットゾーン１１０について、Φ^{ＴＣ，ｍｉｎ} _ｔとして、前回の下限値Φ^{ＴＣ，ｍｉｎ} _ｔ−ｎを設定する（Ｓ５０８）。

Ｓ５０６の判断結果が偽の場合（Ｓ５０６：Ｎｏ）、フィードバックアナライザ２４２は、ターゲットゾーン１１０について、設定されているΦ^{ＴＣ，ｍｉｎ} _ｔを、ゾーンマジョリティユーザフィードバックを基に調整する（Ｓ５０７）。例えば、フィードバックアナライザ２４２は、ターゲットゾーン１１０について、設定されているΦ^{ＴＣ，ｍｉｎ} _ｔを、ゾーンマジョリティユーザフィードバックが“Ｈｏｔ”であるか“Ｃｏｌｄ”であるかに応じて増減する。

Ｓ５０１〜Ｓ５０９とは別に、フィードバックアナライザ２４２は、例えばΦ^ＴＣ _ｔカリキュレータ（図７参照）を呼び出す等の方法により、Φ^ＴＣ _ｔを算出する（Ｓ５０９）。

以上のＳ５０１〜Ｓ５０９により、Φ^ＴＣ _ｔとΦ^{ＴＣ，ｍｉｎ} _ｔとが決まる。オプティマイザ２４３が、ターゲットゾーン１１０について最適化処理を行う。すなわち、オプティマイザ２４３が、ターゲットゾーン１１０についてのΦ^ＴＣ _ｔとΦ^{ＴＣ，ｍｉｎ} _ｔを基に、ターゲットゾーン１１０を構成する全ブロック１３０のうちの全制御対象ブロック１３０のＨＶＡＣユニット１６０に送信される同一のコマンド（空調制御のコマンド）に含めるパラメータ値（ＨＶＡＣパラメータ値）を決定する（Ｓ５１０）。決定されたＨＶＡＣパラメータ値は、Φ^ＴＣ _ｔをΦ^{ＴＣ，ｍｉｎ} _ｔ以上に維持する（つまりΦ^ＴＣ _ｔ≧Φ^{ＴＣ，ｍｉｎ} _ｔを維持する）ためのＨＶＡＣパラメータ値である。オプティマイザ２４３が、ターゲットゾーン１１０を構成する全ブロック１３０のうちの全制御対象ブロック１３０について、Ｓ５１０で決定したＨＶＡＣパラメータ値を含んだコマンドを生成し、生成したコマンドを、各制御対象ブロック１３０のＨＶＡＣユニット１６０のＣＵ１４０に送信する（Ｓ５１１）。

なお、上述したように、図５に示す処理のうちのフィードバック分析処理では、適宜、図６に示すユーザフィードバックテーブル６００が参照される。ユーザフィードバックテーブル６００は、ユーザフィードバック２９４を受信する都度に更新される。ユーザフィードバックテーブル６００は、例えば、ユーザ毎にエントリを有する。各エントリは、ユーザＩＤ６０１（ユーザのＩＤ）、ブロックＩＤ６０２（ユーザがいるブロック１３０のＩＤ）、ユーザフィードバック６０３（受信したユーザフィードバック２９４）、日時６０４（ユーザフィードバック２９４の受信日時）、温度６０５（ユーザフィードバック２９４の受信時点の周期における温度）、湿度６０６（ユーザフィードバック２９４の受信時点の周期における湿度）、外部温度６０７（ユーザフィードバック２９４の受信時点の周期における外部温度）、及び、外部湿度６０８（ユーザフィードバック２９４の受信時点の周期における外部湿度）といった情報を格納する。外部温度及び外部湿度は、天候情報２９１から特定可能である。

また、Φ^ＴＣ _ｔは、例えば図７に示すようにして算出されてよい。すなわち、Φ^ＴＣ _ｔカリキュレータ７００が、温度“ｔ^ｒｏｏｍ _ｔ”、湿度“ｈ^ｒｏｏｍ _ｔ”、衣服レベル“ｃｌ”、代謝率“ｍｒ”、代謝活動“ｍｂ”及び時間帯“Ｔ［ｔ］−Ｔ［ｔ−ｎ］”といったΦ^ＴＣ _ｔファクタを基に、Φ^ＴＣ _ｔを算出する。温度“ｔ^ｒｏｏｍ _ｔ”及び湿度“ｈ^ｒｏｏｍ _ｔ”は、ターゲットゾーン１１０の温度及び湿度である（例えば、ターゲットゾーン１１０について複数の温度センサ（環境センサ１２０の一例）及び湿度センサ（環境センサ１２０の一例）がある場合、温度又は湿度の平均値でよい）。衣服レベル“ｃｌ”、代謝率“ｍｒ”及び代謝活動“ｍｂ”の各々は、エリア１００（ティア１）について予め設けられたデフォルト値でよい（すなわち、全ゾーン１１０について共通でよい）。Φ^ＴＣ _ｔカリキュレータ７００は、フィードバックアナライザ２４２に含まれているプログラムでもよいし、フィードバックアナライザ２４２とは別のプログラムであってもよい。また、Φ^ＴＣ _ｔファクタは、図７に示す例に限られない。例えば、ＰＭＶ（Predicted Mean Vote）及びＰＰＤ（Predicted Percentage of Dissatisfied）のうちの少なくとも１つがΦ^ＴＣ _ｔファクタとしてΦ^ＴＣ _ｔの算出に使用されてよい。Φ^ＴＣ _ｔの算出に使用されるΦ^ＴＣ _ｔファクタは、例えば、ＩＳＯ７７３０又はＡＳＨＲＡＥ５５標準といった規定に基づき決められてよい。ＰＭＶ及びＰＰＤのうちの少なくとも１つは、ゾーンマジョリティユーザフィードバックを基に決められてよい。

また、Φ^{ＴＣ，ｍｉｎ} _ｔ及びΦ^ＴＣ _ｔは、ゾーンベースに代えて、エリア１００について決定されてもよい。エリア１００についてのΦ^ＴＣ _ｔ≧Φ^{ＴＣ，ｍｉｎ} _ｔを維持するために、ゾーンベースの最適化処理（空調制御）が行われてもよい。

以上、本実施例によれば、空調制御の単位とされるゾーン１１０は、ホモジニアスのブロック１３０のクラスタであり、各ブロック１３０は、対応するＨＶＡＣユニット１６０による空調の影響範囲である。このため、異なる２以上のゾーン１１０に同一のブロック１３０（同一のＨＶＡＣユニット１６０）が含まれることが無い。故に、ゾーンベースの空調制御が可能である。ゾーンベースの空調制御として、同一ゾーンに属する全制御対象ブロックのＨＶＡＣユニット１６０について同一のコマンドを用意すればよいので、ＨＶＡＣ制御システム１８０の処理負荷を低減することができる。

また、本実施例によれば、定期的に、温熱環境状況に応じて（具体的には、エリア１００における複数のブロック１３０に配置された複数の環境センサ１２０からの複数の温熱パラメータ値に基づく複数のセンサデータセットを基に）、ゾーン数及びゾーンメンバが更新される。例えば、図８に示すように、ブロック１〜４の各々の３０分毎のセンサデータセットを基に、３０分毎に、ゾーン数及びゾーンメンバが変更され得る。具体的には、例えば、７：００では、ゾーン数は３であるが、１１：００及び１５：００では、ゾーン数は２である。また、同じゾーン数＝２でも、１１：００と１５：００とではゾーンメンバが異なる。具体的には、１つ目のゾーンは、１１：００でも１５：００でも、２番目に低い温度範囲に属するブロックのクラスタとしてのゾーンであるが、当該ゾーンのメンバ（及びメンバの数）が異なる（１１：００では、メンバはブロック２及び３であるが、１５：００では、メンバはブロック１、２及び４である）。また、２つ目のゾーンは、１１：００では、最も高い温度範囲に属するブロックのクラスタであるが、１５：００では、最も低い温度範囲に属するブロックのクラスタである。このように、定期的に、空調制御単位であるゾーンの数及びメンバは、温熱環境状況に応じた数及びメンバとされるので、ゾーンベースの空調制御を適切な空調制御とすることが期待できる。なお、温度範囲の大きさ及び数のうちの少なくとも１つは、固定でもよいし、各時点でのゾーン数に応じて可変でもよい。また、同一のゾーン１１０のメンバは、隣接したブロック１３０に限らず、１以上のブロック１３０を隔てて離れた２以上のブロック１３０でもよい。

また、本実施例によれば、ゾーン数及びゾーンメンバの少なくとも１つの決定の際に優先されるキー温熱パラメータは、ゾーン１１０の基になるエリア１００の機能性によって異なる。つまり、ゾーン数及びゾーンメンバの少なくとも１つは、エリア１００の機能性に依存する。このため、エリア１００の機能性（例えば、エリア１００が、オフィスルーム、サーバルーム、会議室及びスポーツルームのいずれの機能性に該当するエリアであるか）に応じた空調制御が可能である。

また、本実施例によれば、空調制御に際して、ユーザフィードバック２９４が考慮される。具体的には、ゾーンマジョリティユーザフィードバックと異なるブロックマジョリティユーザフィードバックに対応したブロック１３０は、空調制御の対象から外される。これにより、本実施例に係るＨＶＡＣ制御システム１８０による空調制御を不快に感じるユーザを低減することができる。

以上が、本実施例の説明である。

なお、本実施例では、ティア１及びティア２の両方が考慮されるが、エリア１００の機能性を考慮せずに（つまりいずれの温熱パラメータの優先度も同じとして）、ゾーン数、及び、ゾーンメンバのうちの少なくとも１つが決定されてもよい（つまり、ティア１及びティア２といった定義が無くてもよい）。

また、本実施例では、ゾーン数及びゾーンメンバのうちゾーン数が優先されるが（すなわち、ゾーン数が決定され、決定されたゾーン数のゾーンが構成されるが）、ゾーンメンバが優先されてもよい（つまり、ゾーン数は決定されないでもよい）。

また、本実施例では、図３に示した処理も図５に示した処理も定期的に行われるが、少なくとも１つの処理が不定期的に行われてもよい。

また、本実施例では、フィードバックアナライザ２４２は無くてもよい。すなわち、オプティマイザ２４３は、ゾーンアナライザ２４１によるゾーン決定処理の結果を基に最適化処理を行ってもよい。

また、本実施例では、ユーザフィードバック２９４は、ユーザにより入力された情報であるが、それに代えて又は加えて、ユーザ以外の者（例えば管理者）により入力された情報でもよい。また、本実施例では、ユーザフィードバック２９４は、入力時点でのユーザの感想（空調に対する感想）を示す情報であるが、それに代えて又は加えて、温熱環境に関してのユーザの好み（例えば、比較的暑い方が好き、比較的乾燥している方が好き）を示す情報であってもよい。

実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。

実施例２では、ゾーンアナライザ２４１は、複数の環境センサ１２０についての複数のセンサデータセットに代えて、複数のブロック１３０における複数のユーザのユーザフィードバック２９４を基に、ゾーン数及びゾーンメンバが決定される（ユーザフィードバック２９４は、ユーザにより入力されてもよいし、ユーザ以外の者（例えば管理者）により入力されてもよい）。ゾーン数及びゾーンメンバは、定期的に又は不定期的に、各ブロック１３０のブロックマジョリティユーザフィードバックを基に、更新されてよい。各ブロック１３０について、ブロックマジョリティユーザフィードバックは、１以上のユーザの移動（例えば、ブロック１３０間での移動、エリア１００への入室、エリア１００からの退室）、及び、動的なユーザフィードバック２９４の入力、のうちの少なくとも１つに伴い、変わり得る。例えば、ゾーンアナライザ２４１は、下記のようにしてゾーンを構成することができる。
（ａ）ゾーンアナライザ２４１は、ブロックマジョリティユーザフィードバックが同一のブロック１３０をクラスタ化することで、ブロックマジョリティユーザフィードバックが共通したゾーン１１０を構成する。これによれば、ゾーン１１０が作成された時点では、当該ゾーン１１０に、当該ゾーン１１０のゾーンマジョリティユーザフィードバックと異なるブロックマジョリティユーザフィードバックのブロック１３０は存在しない。
（ｂ）（ａ）に加えて、ゾーンアナライザ２４１は、ユーザフィードバック２９４が存在しないブロック１３０のクラスタとしてのゾーン１１０を構成してもよい。

このように、本実施例によれば、ユーザフィードバック２９４を基にゾーン１１０を構成することができるため、環境センサ１２０が無くてもよい。

本実施例では、図９に示すように、効率評価プログラム９００が、空調制御の効率を評価（測定）する処理である効率評価処理を行うことができる。効率評価プログラム９００は、ＨＶＡＣ制御システム１８０において実行されるプログラムであり、ＨＶＡＣコントローラ２４０の内部の要素でもよいし外部の要素でもよい。

図９に示すように、効率評価処理は、ケース１の処理（Ｓ９０１〜Ｓ９０３）と、ケース２の処理（Ｓ９１１〜Ｓ９１６）とを含む。上述した図示しないブロックテーブルにおいて、各ブロック１３０のエントリは、効率の良さを示す指標の一例である効率カウント値を格納する。なお、以下の説明において、「快適ゾーン」とは、ブロックマジョリティユーザフィードバックが“ＯＫ”（快適を意味するユーザフィードバックの一例）であるブロック１３０のクラスタであり、「非快適ゾーン」とは、ブロックマジョリティユーザフィードバックが“ＯＫ”以外であるブロック１３０のクラスタである。快適ゾーン及び非快適ゾーンのいずれも、１種類以上存在してよい。例えば、非快適ゾーンとしては、ブロックマジョリティユーザフィードバックが“Ｃｏｌｄ”であるブロック１３０のクラスタであるＣｏｌｄゾーンと、ブロックマジョリティユーザフィードバックが“Ｈｏｔ”であるブロック１３０のクラスタであるＨｏｔゾーンとが存在してよい。また、効率評価処理は定期的（又は不定期的）に行われる。つまり、効率評価処理は、１回以上行われる。効率評価処理の周期は、ゾーン決定処理の周期と同じでも異なっていてもよい（例えば、ゾーン決定処理の終了を契機に効率評価処理が行われてもよい）。

ケース１の処理は、快適ゾーンに関する処理である。具体的には、例えば、下記の通りである。

効率評価プログラム９００が、快適ゾーンに属するいずれのブロック１３０も、連続してｋ回（ｋは自然数）以上、ブロックマジョリティユーザフィードバックが“ＯＫ”であるか否かを判断する（Ｓ９０１）。なお、上述した図示しないブロックテーブルにおいて、各ブロック１３０のエントリは、当該ブロック１３０のブロックマジョリティユーザフィードバックが連続して“ＯＫ”となった回数であるＯＫカウント値及び連続して“ＯＫ”以外となった回数である非ＯＫカウント値を格納していてよく、いずれのカウント値も、効率評価処理の都度に、インクリメント又はリセットされてもよい。

Ｓ９０１の判断結果が真の場合（Ｓ９０１：Ｙｅｓ）、効率評価プログラム９００が、快適ゾーンに属する各ブロック１３０の効率カウント値を１インクリメントする（Ｓ９０２）。

一方、Ｓ９０１の判断結果が偽の場合（Ｓ９０１：Ｎｏ）、効率評価プログラム９００が、特段の処理を行わない（Ｓ９０３）。Ｓ９０３では、効率評価プログラム９００は、連続してｋ回以上、ブロックマジョリティユーザフィードバックが“ＯＫ”とならなかったブロックのＯＫカウント値を初期値（例えばゼロ）にリセットしてもよい。

ケース２の処理は、非快適ゾーンに関する処理である。具体的には、例えば、下記の通りである。

効率評価プログラム９００が、非快適ゾーンに属するいずれのブロック１３０も、連続してｐ回（ｐは自然数）以上、ブロックマジョリティユーザフィードバックが“ＯＫ”以外であるか否かを判断する（Ｓ９１１）。なお、ｐ＝ｋでもよいし、ｐ≠ｋでもよい。

Ｓ９１１の判断結果が偽の場合（Ｓ９１１：Ｎｏ）、効率評価プログラム９００が、特段の処理を行わない（Ｓ９１２）。Ｓ９１２では、効率評価プログラム９００は、連続してｐ回以上、ブロックマジョリティユーザフィードバックが“ＯＫ”以外とならなかったブロックの非ＯＫカウント値を初期値（例えばゼロ）にリセットしてもよい。

Ｓ９１１の判断結果が真の場合（Ｓ９１１：Ｙｅｓ）、効率評価プログラム９００が、非快適ゾーンに属する各ブロック１３０の効率カウント値を１デクリメントする（Ｓ９１３）。非快適ゾーンに属する各ブロック１３０のＳ９１３後の効率カウント値を基に、オプティマイザ２４３が最適化処理を行うことができる。

Ｓ９１３の後、効率評価プログラム９００が、非快適ゾーンに属するいずれかのブロック１３０の効率カウント値が効率カウント値の下限値に達したか否かを判断する（Ｓ９１４）。

Ｓ９１４の判断結果が真の場合（Ｓ９１４：Ｙｅｓ）、効率評価プログラム９００が、下記の処理、
・非快適ゾーンに属するいずれかのブロック１３０の効率カウント値が効率カウント値の下限値未満となったことを示す情報（例えば、効率カウント値が効率カウント値の下限値未満となったブロック１３０のＩＤを含んだ情報）を、管理者に通知する、
・効率カウント値が効率カウント値の下限値に達したブロック１３０（ＨＶＡＣユニット１６０）の運転モードを“ｏｆｆ”とする、
・効率カウント値が効率カウント値の下限値に達したブロック１３０を、ゾーン１１０から除外する、
のうちの少なくとも１つを行う（Ｓ９１５）。運転モード“ｏｆｆ”のブロック１３０は、ゾーンベースの空調制御から除外されたブロック１３０、すなわち、個別制御の対象のブロック１３０である。一定期間個別制御が行われた結果として当該ブロック１３０に関して“ＯＫ”を意味するユーザフィードバック２９４が一定割合以上集まるようになった場合に（例えば、当該ブロック１３０のブロックマジョリティユーザフィードバックが“ＯＫ”となった場合に）、効率評価プログラム９００が、当該ブロック１３０を、いずれかのゾーン１１０のメンバとなり得るブロックとして管理する。具体的には、例えば、上述した図示しないブロックテーブルにおいて、各ブロック１３０のエントリは、当該ブロック１３０がゾーンベースの制御の対象か否かを示すフラグを格納していてよい。当該フラグの値を“１”（ゾーンベースの制御対象）とするか“０”（個別制御の対象）とするかにより、ブロック１３０が、ゾーンベースの制御対象であるか否かが管理されてよい。

一方、Ｓ９１４の判断結果が偽の場合（Ｓ９１４：Ｎｏ）、効率評価プログラム９００が、特段の処理を行わない（Ｓ９１６）。

定期的（又は不定期的）に行われる効果評価処理において非快適ゾーンに属するいずれかのブロック１３０の効率カウント値がデクリメントされた場合に、デクリメント後の効率カウント値を基に、最適化処理が行われる。これにより、ユーザフィードバック２９４に基づいて構成されるゾーン１１０の単位での空調制御の改善が期待できる。

実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を省略又は簡略する。

図示しない表示制御プログラムが、ユーザの役割に応じたＵＩ（User Interface）画面を当該ユーザに対して表示する。ユーザの役割は、複数の役割のうちのいずれかである。複数の役割として、例えば、管理者及び一般ユーザがある。表示制御プログラムは、ＨＶＡＣ制御システム１８０において実行されるプログラムであり、ＨＶＡＣコントローラ２４０の内部の要素でもよいし外部の要素でもよい。

例えば、表示制御プログラムは、図１０に例示する管理者向けのＵＩ画面である管理者画面１０５０を表示する。管理者画面１０５０は、エリア１００の機能性を入力するためのＵＩ（例えばプルダウンメニュー）１０００と、キー温熱パラメータとする温熱パラメータを入力するためのＵＩ１０１０と、複数のＨＶＡＣユニット１６０全体の消費電力の上限を入力するためのＵＩ１０２０と、実施例１のゾーン決定処理に代えて実施例２のゾーン決定処理の実行を指示するためのＵＩ１０３０と、管理者が選択したゾーン１１０のメンバブロック毎の消費電力の推移を示すＵＩ１０４０とを有する。管理者は、管理者画面１０５０を基に、空調制御システム１８０を管理することができる。

また、例えば、表示制御プログラムは、図１１に例示する一般ユーザ向けのＵＩ画面である一般ユーザ画面１１５０を表示する。以下、或る一般ユーザを例に取る（図１１の説明で「対象ユーザ」）。一般ユーザ画面１１５０は、対象ユーザが存在する空間（ブロック１３０又はゾーン１１０）の平均温度を示す情報１１００と、対象ユーザが存在する空間（ブロック１３０又はゾーン１１０）の平均湿度を示す情報１１１０と、各エリア（各エリア機能性）について対象ユーザ向けの推奨ブロックを示す情報である推奨情報１１２０と、対象ユーザがユーザフィードバックを入力するためのＵＩ１１３０と、対象ユーザが存在する空間における全ユーザのユーザフィードバックの比率を示すＵＩ１１４０とを有する。ＵＩ１１４０によれば、対象ユーザは、対象ユーザが存在する空間におけるどのぐらいのユーザが自分と同じ感想を持っているかを知ることができる。また、推奨情報１１２０によれば、対象ユーザは、エリア１００毎にどこが対象ユーザにとって快適な空間であるかを知ることができる。

推奨情報１１２０は、例えば、図１２に例示する推奨プログラム１２００が生成することができる。推奨プログラム１２００は、ＨＶＡＣ制御システム１８０において実行されるプログラムであり、ＨＶＡＣコントローラ２４０の内部の要素でもよいし外部の要素でもよい。推奨プログラム１２００は、例えば、各ユーザについて、下記、
・いずれの時間帯にいずれの温熱環境を好む傾向にあるかを特定する、
・特定された時間帯別の好みに応じて、エリア１００の機能性別に時間帯毎の推奨ブロックを決定する、
・当該ユーザに対して一般ユーザ画面１１５０を表示する時の日時が属する時間帯に対応した、エリア１００の機能性別の推奨ブロックのブロックＩＤを特定し、エリア１００の機能性別に、特定されたブロックＩＤを表示する、
を行う。具体的には、例えば、推奨プログラム１２００は、日時毎のユーザＩＤ、ブロックＩＤ（当該日時に当該ユーザが存在していたブロックのＩＤ）、ユーザフィードバック、温度、湿度、外部温度及び外部湿度の履歴を基に、いずれの時間帯にいずれの温熱環境を好む傾向にあるかを特定することができ、以って、エリア１００の機能性別の推奨ブロックのブロックＩＤを特定し出力できる。ユーザについての履歴が増える程、当該ユーザ向けの推奨ブロックの正確性が高まることが期待できる。

以上の実施例１〜実施例３の説明を、例えば下記のように総括することができる。下記の総括は、上述の説明に無い事項の説明を含んでもよい。また、以下の総括では、参照符号は割愛される。

エリアの空調を行う複数の空調機（例えばＨＶＡＣユニット１６０）を制御する空調制御システムが、エリアにおける複数のブロックを基に１以上のゾーンを構成するゾーン決定処理を行うゾーン決定部（例えばゾーンアナライザ２４１）と、各ゾーンについて、当該ゾーンにおけるゾーンベースの制御対象ブロックに対応した空調機をゾーンベースで制御する空調制御（例えば空調最適化）を行う空調制御部（例えばオプティマイザ２４３）とを有する。ゾーン構成は、ゾーン数（ゾーンの数）とゾーンメンバ（ゾーンを構成するメンバとしてのブロック）とのうちの少なくとも１つである。複数のブロックの各々について、当該ブロックは、複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲である。１以上のゾーンの各々について、当該ゾーンは、複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである。これにより、いずれの空調機も異なる２以上のゾーンに分類されないようになっているので、ゾーンベース（ゾーン単位）の空調制御が可能である。

ゾーン決定部は、ゾーン決定処理を、定期的又は不定期的に行う。これにより、動的に、ゾーン構成を変更できる。

複数のブロックの全部又は一部である２以上のブロックに複数の環境センサが配置されている。少なくとも１つのゾーン１１０が温熱ゾーンである。温熱ゾーンは、温熱指標値がホモジニアス（例えば同じ又は近似）である１以上のブロックで構成されたゾーンである。温熱ゾーンの各ブロックについて、温熱指標値は、当該ブロックに配置されている１以上の環境センサからの１以上の温熱パラメータ値に従う値である。これにより、温熱パラメータ値に基づく制御、例えば、ＩｏＴベースの制御ができる。なお、「温熱指標値」は、キー温熱パラメータ値でもよいし、２以上の温熱パラメータの温熱パラメータ値を基に決定された温熱快適指標値（Φ^ＴＣ）でもよい。

ゾーン決定部は、定期的又は不定期的に行うゾーン決定処理の都度に、温熱偏差に基づきゾーン数を決定し、決定したゾーン数の各ゾーンについて、当該ゾーンのゾーンメンバを決定する。これにより、決定したゾーン数を維持し、当該ゾーン数の各ゾーンについて、ゾーンベースの空調制御ができる。なお、温熱偏差は、前回のゾーン決定処理における温熱指標値の最大値と、前回のゾーン決定処理における温熱指標値の最小値との差分である。また、ゾーン数は、更に、エリアの広さ、エリアの機能性、エリアの優先度、及び、エリアの全空調機の消費電力の上限、のうちの少なくとも１つに基づいてよい。これにより、ゾーン数をエリアに応じてより適切とすることが期待できる。

空調制御システムが、エリアのユーザのユーザフィードバックを管理するフィードバック管理部（例えばフィードバックアナライザ２４２）を更に有する。フィードバック管理部は、温熱ゾーンを構成する各ブロックについて、当該ブロックに関する全ユーザフィードバックのうち最も多いユーザフィードバックであるブロックマジョリティユーザフィードバックを特定する。フィードバック管理部は、温熱ゾーンに関する全ブロックマジョリティユーザフィードバックのうち最も多いブロックマジョリティユーザフィードバックであるゾーンマジョリティフィードバックと異なるブロックマジョリティユーザフィードバックのブロックを、ゾーンベースの制御対象から除外する。これにより、ゾーンベースのより適切な空調制御が期待できる。なお、空調制御部は、当該除外されたブロックの空調機を、個別に制御してもよい。

また、フィードバック管理部は、温熱ゾーンに関するユーザフィードバックを基に、温熱快適指標値の下限値を決定してよい。この場合、空調制御部は、温熱快適指標値を下限値以上に維持する空調制御を行う。これにより、より多くのユーザが快適と感じられる温熱環境を提供することが期待できる。

フィードバック管理部は、上述の通り、エリアのユーザのユーザフィードバックを管理する。これにより、ユーザフィードバックに基づくゾーン構成の決定、ユーザフィードバックに基づく空調制御、及び、ユーザフィードバックに関する情報を含んだ情報の提供、のうちの少なくとも１つが期待できる。フィードバック管理部は、上述の処理に代えて又は加えて、以下の処理を行ってもよい。

例えば、少なくとも１つのゾーンが、ユーザフィードバックゾーンである。ユーザフィードバックゾーンは、ブロックマジョリティユーザフィードバックが同じである１以上のブロックで構成されたゾーンである。ユーザフィードバックゾーンの各ブロックについて、当該ブロックのブロックマジョリティユーザフィードバックは、当該ブロックに関する全ユーザフィードバックのうち最も多いユーザフィードバックである。このように、ユーザフィードバックに基づくゾーン構成の決定ができる。

ユーザフィードバックゾーンに関する効率評価処理を定期的に又は不定期的に行う効率評価部（例えば、効果評価プログラム９００）を、空調制御システムが更に有してよい。効率評価処理は、ユーザフィードバックゾーンを構成する各ブロックについて、下記を含む。これにより、ユーザフィードバックに基づき構成されたゾーンのゾーンベースの適切な空調制御が期待できる。
・当該ブロックの値（例えば、効率カウント値）を、当該ブロックのブロックマジョリティユーザフィードバックが快適を意味していれば（例えば連続してｋ回以上“ＯＫ”であれば）インクリメントし、当該ブロックのブロックマジョリティユーザフィードバックが快適を意味してなければ（例えば連続してｊ回以上“ＯＫ”でなければ）デクリメントすること。
・当該ブロックの値が下限値に達していれば、通知を発する、当該ブロックをゾーンベースの制御対象から除外する、当該ブロックをユーザフィードバックゾーンから除外する、のうちの少なくとも１つを行うこと。

ユーザについて日時とユーザフィードバックと温熱環境との履歴に基づき当該ユーザに提供される推奨ブロックを決定する推奨部（例えば推奨プログラム１２００）を、空調制御システムが更に有してよい。これにより、ユーザは、当該ユーザにとって快適と感じられる可能性が高いブロックを知ることができる。なお、推奨部は、機能性が異なる複数のエリアがある場合には、各エリアの機能性を基に、複数のエリアの少なくとも一部の各エリアについて、ユーザに提供される推奨ブロックを決定できる。

ユーザの存在するブロックの全ユーザのユーザフィードバックに関する情報（例えばＵＩ１１４０）をユーザに関して表示する表示制御部（例えば表示制御プログラム）を、空調制御システムが更に有してよい。これにより、ユーザは、当該ユーザが存在するブロックにいる他のユーザの感想を知ることができる。例えば、当該ユーザの感想がマイノリティであることがわかれば、当該ユーザは、他のブロックに移動するといったことを検討できる。

空調制御部が、エリアを含む複数のエリアの各々について、消費電力の遷移を予測してよい。空調制御部は、優先度が相対的に高いエリアについて消費電力が閾値を超える時刻が予測された場合には、優先度が相対的に低いエリアにおける空調機を節電モードに切り替えてよい（例えば予測された時刻になるときに当該切り替えを行ってよい）。空調制御部は、複数のエリアの各々について、ゾーンベースの空調制御を、当該エリアにおける空調機のモードが節電モードか通常モードかに応じて行う。これにより、複数のエリア全体の電力の消費を適切に維持しつつ、各エリアをゾーンベースに制御することが期待できる。なお、複数のエリアの各々に、複数の空調機が用意されている。各エリアについて、消費電力の推移の予測は、例えば、回帰モデルのようなモデルを使用して行うことができる。また、空調制御部は、優先度が相対的に低いエリアにおける空調機を節電モードに切り替えることとその切り替えの時刻とを含んだ通知を、管理者に送信してもよい。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。例えば、実施例１〜３のいずれに係るＨＡＶＣ制御システム１８０も、大型商業ビル内の自動空調制御に好適なシステムであり、コスト低減（例えば処理負荷の低減）と快適維持とを両立することができる。

１８０ ＨＶＡＣ制御システム

Claims (15)

1. エリアの空調を行う複数の空調機を制御する空調制御システムであって、
   前記エリアにおける複数のブロックを基に１以上のゾーンの構成であるゾーン構成を決定するゾーン決定処理を行うゾーン決定部と、
   各ゾーンについて、当該ゾーンにおけるゾーンベースの制御対象ブロックに対応した空調機をゾーンベースで制御する空調制御を行う空調制御部と
   を有し、
   前記ゾーン構成は、ゾーンの数であるゾーン数と、ゾーンを構成するメンバとしてのブロックであるゾーンメンバとのうちの少なくとも１つであり、
   前記複数のブロックの各々について、当該ブロックは、前記複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲であり、
   前記１以上のゾーンの各々について、当該ゾーンは、前記複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである、
   空調制御システム。
2. 前記ゾーン決定部は、前記ゾーン決定処理を、定期的又は不定期的に行う、
   請求項１に記載の空調制御システム。
3. 前記複数のブロックの全部又は一部である２以上のブロックに複数の環境センサが配置されており、
   少なくとも１つのゾーンが温熱ゾーンであり、
   前記温熱ゾーンは、温熱指標値がホモジニアスである１以上のブロックで構成されたゾーンであり、
   前記温熱ゾーンの各ブロックについて、前記温熱指標値は、当該ブロックに配置されている１以上の環境センサからの１以上の温熱パラメータ値に従う値である、
   請求項１に記載の空調制御システム。
4. 前記ゾーン決定部は、定期的又は不定期的に行う前記ゾーン決定処理の都度に、
   温熱偏差に基づきゾーン数を決定し、当該温熱偏差は、前回の前記ゾーン決定処理における温熱指標値の最大値と、前回の前記ゾーン決定処理における温熱指標値の最小値との差分であり、
   前記決定したゾーン数の各ゾーンについて、当該ゾーンのゾーンメンバを決定する、
   請求項３に記載の空調制御システム。
5. 前記ゾーン数は、更に、前記エリアの広さ、前記エリアの機能性、前記エリアの優先度、及び、前記エリアの全空調機の消費電力の上限、のうちの少なくとも１つに基づく、
   請求項４に記載の空調制御システム。
6. 前記エリアのユーザのユーザフィードバックを管理するフィードバック管理部を更に有し、
   前記フィードバック管理部は、
   前記温熱ゾーンを構成する各ブロックについて、当該ブロックに関する全ユーザフィードバックのうち最も多いユーザフィードバックであるブロックマジョリティユーザフィードバックを特定し、
   前記温熱ゾーンに関する全ブロックマジョリティユーザフィードバックのうち最も多いブロックマジョリティユーザフィードバックであるゾーンマジョリティフィードバックと異なるブロックマジョリティユーザフィードバックのブロックを、ゾーンベースの制御対象から除外する、
   請求項３に記載の空調制御システム。
7. 前記エリアのユーザのユーザフィードバックを管理するフィードバック管理部を更に有し、
   前記フィードバック管理部は、前記温熱ゾーンに関するユーザフィードバックを基に、温熱快適指標値の下限値を決定し、
   前記空調制御部は、前記温熱快適指標値を前記下限値以上に維持する空調制御を行う、
   請求項３に記載の空調制御システム。
8. 前記エリアのユーザのユーザフィードバックを管理するフィードバック管理部を更に有する、
   請求項１に記載の空調制御システム。
9. 少なくとも１つのゾーンが、ユーザフィードバックゾーンであり、
   前記ユーザフィードバックゾーンは、ブロックマジョリティユーザフィードバックが同じである１以上のブロックで構成されたゾーンであり、
   前記ユーザフィードバックゾーンの各ブロックについて、当該ブロックのブロックマジョリティユーザフィードバックは、当該ブロックに関する全ユーザフィードバックのうち最も多いユーザフィードバックである、
   請求項８に記載の空調制御システム。
10. 前記ユーザフィードバックゾーンに関する効率評価処理を定期的に又は不定期的に行う効率評価部、
    を更に有し、
    前記効率評価処理は、前記ユーザフィードバックゾーンを構成する各ブロックについて、
    当該ブロックの値を、当該ブロックのブロックマジョリティユーザフィードバックが快適を意味していればインクリメントし、当該ブロックのブロックマジョリティユーザフィードバックが快適を意味してなければデクリメントし、
    当該ブロックの値が下限値に達していれば、通知を発する、当該ブロックをゾーンベースの制御対象から除外する、当該ブロックを前記ユーザフィードバックゾーンから除外する、のうちの少なくとも１つを行う、
    を含む、
    請求項９に記載の空調制御システム。
11. ユーザについて日時とユーザフィードバックと温熱環境との履歴に基づき当該ユーザに提供される推奨ブロックを決定する推奨部、
    を更に有する請求項８に記載の空調制御システム。
12. ユーザの存在するブロックの全ユーザのユーザフィードバックに関する情報を前記ユーザに関して表示する表示制御部、
    を更に有する請求項８に記載の空調制御システム。
13. 前記空調制御部が、
    前記エリアを含む複数のエリアの各々について、消費電力の遷移を予測し、
    優先度が相対的に高いエリアについて消費電力が閾値を超える時刻が予測された場合には、優先度が相対的に低いエリアにおける空調機を節電モードに切り替え、
    前記空調制御部は、前記複数のエリアの各々について、ゾーンベースの空調制御を、当該エリアにおける空調機のモードが節電モードか通常モードかに応じて行う、
    請求項１に記載の空調制御システム。
14. エリアの空調を行う複数の空調機を制御する空調制御方法であって、
    前記エリアにおける複数のブロックを基に１以上のゾーンの構成であるゾーン構成を決定するゾーン決定処理を行い、
    前記ゾーン構成は、ゾーンの数であるゾーン数と、ゾーンを構成するメンバとしてのブロックであるゾーンメンバとのうちの少なくとも１つであり、
    前記複数のブロックの各々について、当該ブロックは、前記複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲であり、
    前記１以上のゾーンの各々について、当該ゾーンは、前記複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである、
    ゾーンベースで前記複数の空調機を制御する空調制御を行う、
    空調制御方法。
15. エリアの空調を行う複数の空調機に接続された計算機に、
    前記エリアにおける複数のブロックを基に１以上のゾーンの構成であるゾーン構成を決定するゾーン決定処理を行い、
    前記ゾーン構成は、ゾーンの数であるゾーン数と、ゾーンを構成するメンバとしてのブロックであるゾーンメンバとのうちの少なくとも１つであり、
    前記複数のブロックの各々について、当該ブロックは、前記複数の空調機のうち当該ブロックに対応した空調機による空調が影響する範囲として定義された範囲であり、
    前記１以上のゾーンの各々について、当該ゾーンは、前記複数のブロックのうちの１以上のホモジニアスのブロックのクラスタである、
    ゾーンベースで前記複数の空調機を制御する空調制御を行う、
    を実行させるコンピュータプログラム。