以下に、実施の形態にかかる空気調和制御システムおよび空気調和制御システムプログラムを図面に基づいて詳細に説明する。
実施の形態1.
図1は、実施の形態1における空気調和機器の構成を示す図である。実施の形態1における空気調和機器1は、記憶部2Aと、制御部4Aと、通信部7と、センサ8と、リモートコントローラ9と、アクチュエータ10と、を備える。
記憶部2Aは、空気調和機器1の制御に用いられる各種の情報を記憶する。記憶部2Aは、エンジン3を記憶するエンジン格納部2を備える。
エンジン3とは、空気調和機器1を制御するための制御ロジックまたは設定パラメータのうちの少なくとも一方が含まれる、空気調和機器1を制御するための制御エンジンであり、例えば風向または風速を決定するための処理、ファン等のアクチュエータ10を制御する処理、センサ8から人を検出する処理及び検出の閾値、空気調和制御に関わる設定の自動設定時の温度、湿度、風向、風速等の設定値などが挙げられる。エンジン3の物理的実体としては、例えば、実行形式ファイルまたはライブラリ等の実行形式、バッチまたはスクリプトが記載されたファイル、パラメータが記載された設定ファイル、もしくはこれらの要素を組み合わせたものが挙げられる。エンジン3の物理的実体は、上記のものに限られず、空気調和機器1の制御を行うために必要な情報が保存される形式であればよい。また、1つのファイルまたは1つのメモリ領域に複数のエンジン3が保存されていてもよい。
制御部4Aは、空気調和機器1の制御動作を決定し、アクチュエータ10へ送信する指令値または通信部7から送信する情報を出力する空気調和制御システム4を有する。
通信部7は、クラウドシステム11等の空気調和機器1の外部の機器と通信を行う。
センサ8は、空気調和機器1における空気調和制御に用いられる各種の情報を検出する。
空気調和制御システム4は、空気調和機器1の制御動作において必要なエンジン3を取得または生成するエンジン取得部5と、空気調和機器1の制御を行う機器制御部6とを有する。機器制御部6は、通信部7、センサ8及びリモートコントローラ9から入力された情報に基づいて、空気調和機器1の制御動作を決定し、アクチュエータ10への指令値または通信部7から送信する情報を出力する。以降、リモートコントローラをリモコンと記載する場合がある。
エンジン取得部5は、空気調和機器1の制御に用いる1つ以上のエンジン3を取得するか、与えられた情報を基に1つ以上のエンジン3を生成し、機器制御部6に渡す。エンジン3を取得する方法としては、例えば、図1に示すように空気調和機器1にエンジン格納部2を用意しておき、予めエンジン格納部2に保存しておいたエンジン3を取得する方法を用いることができる。
エンジン3を取得する方法としては、エンジン3が必要となったタイミングで空気調和機器1の外部からエンジン3を取得する方法を用いることができる。空気調和機器1の外部からエンジン3を取得する方法としては、例えば、インターネット経由でクラウドシステム11からダウンロードする方法を用いることができる。エンジン3を生成する方法としては、例えば、個別の処理の要否などの設定パラメータを受け取り、設定パラメータを基にソースコードをビルドしてエンジン3を得る方法が挙げられる。
機器制御部6は、エンジン取得部5から渡されたエンジン3を用いて空気調和機器1の制御を行う。具体的な例として、エンジン3が定義された実行形式ファイル、ライブラリまたはスクリプトの形式である場合は、エンジン3をメモリ上にロードして実行する方法が挙げられる。エンジン3が設定パラメータファイルである場合は、設定パラメータファイルから設定パラメータを読み込み、制御処理で該当情報を活用する方法が挙げられる。上記の方法はあくまで例示であり、エンジン3を用いて空気調和機器1の制御を行う方法は、エンジン3に含まれる情報を用いて制御を行う方法であればどのような方法でもよい。
図2は、実施の形態1における機器制御部における情報の流れを示す概念図である。図2を参照して機器制御部6の動作における情報の流れを説明する。機器制御部6は、抽象制御エンジン14と、前処理エンジン13と、後処理エンジン15と、を有する。機器制御部6は、抽象制御エンジン14と、前処理エンジン13と、後処理エンジン15と、のうちの少なくとも1つずつ以上を使用して処理を行う。
抽象制御エンジン14は、個々の機器の外部入出力に依存しない空気調和機器1の制御アルゴリズム及びパラメータである。外部入出力は、前処理エンジン13への入力である外部入力12と、後処理エンジン15からの出力である外部出力16と、を含む。
前処理エンジン13は、外部入力12より受け取った情報から抽象制御エンジン14の入力に適した情報を生成するための処理を行うエンジンである。以降、外部入力12より受け取った情報を「外部入力情報」と記載する。抽象制御エンジン14の入力に適した情報とは、抽象制御エンジン14において処理可能な情報である。
後処理エンジン15は、抽象制御エンジン14の出力から外部出力16に適した情報を生成するための処理を行うエンジンである。以降、外部出力16に適した情報を「外部出力情報」と記載する。外部出力16に適した情報とは、外部出力先において処理可能な情報である。
なお、図2及び以降の図では、抽象制御エンジン14と前処理エンジン13と後処理エンジン15との各エンジンが実行形式ファイルまたはライブラリである前提でエンジンが直接処理を行っているように記載している。ただし、抽象制御エンジン14と前処理エンジン13と後処理エンジン15との各エンジンが設定パラメータファイルであり、制御処理がエンジンに含まれる設定パラメータを読み込む場合でも、本質は変わらない。
機器制御部6へ入力された外部入力情報は、まず前処理エンジン13にて処理が行われる。外部入力情報の例としては、温度、湿度、赤外線センサの出力、リモコン9による設定内容、外部機器との通信内容が挙げられる。
前処理エンジン13は、空気調和機器1の機種、空気調和機器1のオプション、空気調和機器1のハードウェア等の、空気調和機器1のバリエーションによって異なるセンサ8、リモコン9、通信等の外部入力12から、空気調和機器1のバリエーションに依存しない情報を生成する。以降、上記の空気調和機器1のバリエーションを総称して単に「機種」と記載する。すなわち、前処理エンジン13は、機種に依存しない情報を生成する。また、機種が異なる空気調和機器1は、仕様が異なる空気調和機器1といえる。
具体的には、前処理エンジン13の行う処理は、赤外線センサから得られた熱画像から、人の位置、姿勢、運動、特定箇所の現在温度を算出する処理、空気調和機器1の室内機の機種によって異なる風向または風速の設定から、物理量による表現によって示される情報を生成する処理が挙げられる。空気調和機器1の室内機の機種には、例えば、天井埋込型、天吊型、壁掛型、床置型等の設置方法がある。物理量による表現は、例えば、風向の場合は水平面及び空気調和機器正面からの角度によって表現し、風速の場合はm/s単位によって表現する。
したがって、前処理エンジン13が行う処理は、前処理エンジン13に入力された1つ以上の外部入力情報に対して演算を行い、入力情報とは異なる意味の情報を生成する処理を含む。
抽象制御エンジン14は、機種に依存しない情報を入力に空気調和機器1の制御動作を決定し、空気調和機器の機種に依存しない情報として出力を行う。機種に依存しない情報の例としては、風温、風向、風速、消費電力、ユーザへ通知する内容、空気調和機器1の室外機または空気調和機器1の外部の外部システムへ通信する内容が挙げられる。ユーザへ通知する内容は、リモコン9の操作を受け付けたことの通知および空気調和機器1の運転状態が挙げられる。機種に依存しない情報は、機種に依存しない抽象的な表現形式により表される。
したがって、抽象制御エンジン14が行う処理は、前処理エンジン13に入力された1つ以上の入力情報に対して演算を行い、入力情報とは異なる意味の情報を生成する処理を含む。より詳細には、抽象制御エンジン14が行う処理は、抽象制御エンジン14に与えられた1つ以上の入力情報に対して演算を行い、入力情報とは異なる意味の情報を生成する処理を含む。
なお、抽象制御エンジン14への入力は、前処理エンジン13が生成した情報に限らず、機種に依存しない外部入力情報を直接入力としてもよいし、空気調和機器1の前回の制御結果等の内部データを入力に用いてもよい。抽象制御エンジン14には、ユーザの快適性を向上するための制御、およびユーザの快適性を損なわずに消費電力を低減する制御など、ユーザにとって具体的な価値を訴求できるような制御機能を含むことが最も好ましい。
後処理エンジン15は、機種に依存しない情報から、アクチュエータ10への指令値、外部システムへの実通信内容等の外部出力情報を生成する。具体的には、後処理エンジン15の行う処理は、物理量で表現された目標とする風向、風速からファン、フラップ、ルーバといったアクチュエータ10の指令値を算出する処理、空気調和機器1の空気調和対象空間である室内の特定箇所の目標温度からアクチュエータ10への指令値、風温度及び室外機に要求する熱量を算出する処理が挙げられる。
したがって、後処理エンジン15が行う処理は、前処理エンジン13に入力された1つ以上の入力情報に対して演算を行い、入力情報とは異なる意味の情報を生成する処理を含む。すなわち、後処理エンジン15が行う処理は、後処理エンジン15に与えられた1つ以上の入力情報に対して演算を行い、入力情報とは異なる意味の情報を生成する処理を含む。
以上のように、抽象制御エンジン14は、機種が異なっても共通となる制御を実現する。前処理エンジン13及び後処理エンジン15は、機種ごとに異なる外部入力情報または外部出力情報と、機種間で共通の入出力情報との差異を吸収することで、抽象制御エンジン14が具体的な機種に依存しないように隠蔽する役割を有する。
図3は、実施の形態1における空気調和機器の処理手順を示すフローチャートである。まず、空気調和機器1を制御するためのロジックまたは設定パラメータの少なくとも一方が含まれる1つ以上のエンジン3がエンジン格納部2に格納されるエンジン格納処理が行われる(ステップS110)。次に、エンジン取得処理において取得されたエンジン3を用いて空気調和機器1の制御を行う機器制御処理が行われる。
ここで、機器制御処理では、まず、前処理エンジン13の行う処理である前処理が行われる(ステップS120)。前処理は、外部入力12より受け取った情報から抽象制御エンジン14の入力に適した情報を生成するための処理である。次に、抽象制御エンジン14の行う処理である抽象制御処理が行われる(ステップS130)。抽象制御処理は、機器制御部6に対する外部入出力に依存しない空気調和機器1の制御アルゴリズム及びパラメータを用いた処理である。つぎに、後処理エンジン15の行う処理である後処理が行われる(ステップS140)。後処理は、抽象制御エンジン14の出力から外部出力16に適した情報を生成するための処理である。機器制御処理では、前処理と抽象制御処理と後処理とが、それぞれ1回以上行われる。すなわち、機器制御処理は、前処理と抽象制御処理と後処理とを、それぞれ1つ以上含む。
機器制御処理は、前処理と抽象制御処理と後処理とをそれぞれ1回以上行うためのプログラムである空気調和制御システムプログラムをコンピュータが実行することにより実現される。
次に、異なる機種間において、エンジン3がどのように活用されるのかを図4及び図5を用いて説明する。
図4は、実施の形態1における機種Aの空気調和機器における機器制御部の情報の流れの例を示す図である。図4では、機種Aの空気調和機器1の機器制御部6における外部入出力を含めた情報の流れを表している。機種Aの空気調和機器1の機器制御部6は、機種A向け前処理エンジン19と、抽象制御エンジン(共通)20と、機種A向け後処理エンジン21と、を有する。抽象制御エンジン(共通)20における(共通)は、後述する図5を参照して説明する機種Bの空気調和機器1における機器制御部6と共通に用いられていることを示す。
機種Aの空気調和機器1が使用する機種A向け前処理エンジン19は、リモコン9、センサ8である室温センサ17、及びセンサ8である赤外線センサ18等の機器からの情報を入力にして、抽象制御エンジン(共通)20に適した情報を生成する。機種A向け後処理エンジン21は、抽象制御エンジン(共通)20が出力した情報を入力にして、機種Aの空気調和機器1で使用しているファン22およびフラップ23等の構成部に適した指令値を生成する。
図5は、実施の形態1における機種Bの空気調和機器における機器制御部の情報の流れの例を示す図である。図5では、機種Bの空気調和機器1の機器制御部6における外部入出力を含めた情報の流れを表している。機種Bの空気調和機器1の機器制御部6は、機種B向け前処理エンジン25と、抽象制御エンジン(共通)20と、機種B向け後処理エンジン26と、を有する。
機種Bの空気調和機器1が使用する機種B向け前処理エンジン25は、機種A向け前処理エンジン19とは異なるものであり、機種Bの空気調和機器1に特有である通信部7およびセンサ8である高画質赤外線センサ24から受け取る情報を扱うことができる。なお、機種B向け前処理エンジン25は、リモコン9および室温センサ17から受け取る情報も扱うことができる。一方で、機種B向け前処理エンジン25が出力する情報は、機種A向け前処理エンジン19が出力する情報と同じである。また、抽象制御エンジン(共通)20は、機種Aの空気調和機器1と機種Bの空気調和機器1とで共通のものを使用できる。
また、機種Bの空気調和機器1が使用する機種B向け後処理エンジン26は、機種A向け後処理エンジン21とは異なるものであり、通信部7を介したデータ送信、左フラップ27及び右フラップ28の2つのフラップを別々に制御するといった、機種Bに特有な処理を実現できる。なお、機種B向け後処理エンジン26は、ファン22を制御する処理も実現できる。ただし、抽象制御エンジン(共通)20は、機種Aの空気調和機器1と機種Bの空気調和機器1とで共通である。このため、機種B向け後処理エンジン26の入力となる情報は、機種A向け後処理エンジン21の場合と同じである。
上記の例に示すとおり、抽象制御エンジン14は機種間で共通して使用できるため、他の機種で使用していたものをそのまま使用できる。例えば、ユーザが普段使用する空気調和機器1で好んで使用している空気調和制御が存在する場合、臨時で使用する空気調和機器1または新規に設置する空気調和機器1に対しても、ユーザが好んで使用している空気調和制御と全く同じ制御処理を導入でき、ユーザのフィードバックを得なくても即座に快適な空気調和制御を実施できる。臨時で使用する空気調和機器1は、例えば、ホテル、飲食店、カラオケおよび病室で使用する空気調和機器1である。新規に設置する空気調和機器1は、今まで空気調和機器1を設置していなかった自宅の部屋に設置する空気調和機器1である。
また、上記の例に示すとおり、抽象制御エンジン14は機種間で共通して使用できるため、将来の技術進歩により開発されたさらなる快適性の向上を実現する制御、消費電力削減に貢献する制御、ユーザ及び環境の状態も考慮した制御などの制御の導入も容易に行える。
一方で、前処理エンジン13及び後処理エンジン15は、センサ8、アクチュエータ10及び通信機能などといった、それぞれの機種の特徴を生かした処理を行える。例えば、熱画像の画素数が向上した赤外線センサを搭載した機種を使用する場合、向上した画素数に合わせた人体検出処理を前処理エンジン13で実行することにより、抽象制御エンジン14を変えることなく、より高精度な空気調和制御を行える。
なお、前処理エンジン13及び後処理エンジン15が情報の生成を行う目的は、機種によって抽象制御エンジン14を変える必要が無いようにすることであり、全ての機種で共通かつ今後も変化しない可能性の高い入出力に関しては、新たな情報を生成しなくてもよい。全ての機種で共通かつ今後も変化しない可能性の高い入出力は、例えば設定温度である。例えば外部入力情報の場合、直接、抽象制御エンジン14の入力としてもよいし、前処理エンジン13に入力はするが無変換でそのまま抽象制御エンジン14に出力してもよい。
また、図1では、エンジン取得部5および機器制御部6が共に空気調和機器1内に配置されているが、エンジン取得部5および機器制御部6の各機能ブロックの配置は任意であり、これに限られない。図6は、実施の形態1における空気調和制御システムの構成の変形例を示す図である。例えば、図6に示すように、エンジン格納部2およびエンジン取得部5が、クラウドシステム11に配置されてもよい。この場合、空気調和機器1の通信部7は、クラウドシステム11の通信部29と通信可能とされる。そして、機器制御部6は、クラウドシステム11の通信部29及び空気調和機器1の通信部7を介して、エンジン取得部5からエンジン3を取得することが可能である。
上述したように、実施の形態1における空気調和制御システム4では、機器制御部6に対する外部入出力に依存しない空気調和機器1の制御アルゴリズム及びパラメータである抽象制御エンジン14と、機器制御部6の外部から入力された情報から抽象制御エンジン14の入力に適した情報を生成するための処理を行うエンジンである前処理エンジン13と、抽象制御エンジン14の出力から機器制御部6の外部への出力に適した情報を生成するための処理を行うエンジンである後処理エンジン15と、のそれぞれを少なくとも1つ以上用いて制御を行うように構成されている。
そして、抽象制御エンジン14は、機種が異なっても共通となる制御を実現する。また、前処理エンジン13及び後処理エンジン15は、機種ごとに異なる外部入力情報または外部出力情報と、機種間で共通の入出力情報との差異を吸収することで、抽象制御エンジン14が具体的な機種に依存しないように隠蔽する役割を有する。これにより、例えば、ユーザが普段使用する空気調和機器1で好んで使用している空気調和制御が存在する場合、臨時で使用する空気調和機器1または新規に設置する空気調和機器1に対しても、ユーザが好んで使用している空気調和制御と全く同じ制御処理を導入でき、即座に快適な空気調和制御を実施できる。
したがって、実施の形態1における空気調和制御システム4によれば、仕様が異なる空気調和機器間で、一方の空気調和機器で使用している制御アルゴリズムを他方の空気調和機器でも再現でき、普段使用しない空気調和環境においても快適な空気調和環境を得ることができる空気調和制御システムを実現できる。
実施の形態2.
続いて実施の形態2では、空気調和制御に使用するエンジン3の処理構成の情報を用いることで、複数のエンジン3を用いた空気制御を実現する例について説明する。
図7は、実施の形態2における空気調和制御システムの構成を示す図である。実施の形態2における空気調和制御システム4は、処理構成格納部30と、エンジン取得部5と、機器制御部6と、を有する。
処理構成格納部30は、空気調和制御に使用するエンジン3を一意に特定する情報、及び複数のエンジン3の処理の実行順序または複数のエンジン3の依存関係を示す処理構成の情報を保存する。
実施の形態2において、エンジン取得部5は、処理構成格納部30から処理構成を取得した上で、必要なエンジン3を取得または生成する。
実施の形態2において、機器制御部6は、処理構成格納部30から取得した処理構成の情報を基に空気調和機器1の空気調和制御動作を決定して、空気調和制御を行う。
処理構成格納部30は、空気調和機器1の空気調和制御に用いるエンジン3の情報を1つ以上保持する。空気調和機器1の空気調和制御に用いるエンジン3の情報には、処理構成の情報が含まれる。処理構成は、エンジン3を一意に特定する情報、及び複数のエンジン3における処理の実行順序または複数のエンジン3における依存関係を示す。
エンジン3を一意に特定する情報とは、例えばエンジン3を識別する文字列などが挙げられる。エンジン3を識別する文字列の例は、エンジン3のID(Identification)を示す文字列およびエンジン3のバージョンを示す文字列である。
エンジン3の処理構成の情報は、1つ以上の前処理エンジン13と、1つ以上の抽象制御エンジン14と、1つ以上の後処理エンジン15から構成され、各エンジンの実行順序または依存関係が示された情報である。すなわち、エンジン3の処理構成の情報は、機器制御部6に用いられる、1つ以上の前処理エンジン13と、1つ以上の抽象制御エンジン14と、1つ以上の後処理エンジン15についての、各エンジンの実行順序または依存関係が示された情報である。以降、エンジンの処理構成の情報を、「処理構成情報」と記載する場合がある。
図8は、実施の形態2におけるエンジン取得部の処理手順を示すフローチャートである。エンジン取得部5は、処理構成格納部30から処理構成情報を取得する(ステップS210)。次に、エンジン取得部5は、取得した処理構成情報から特定される1つ以上のエンジン3として、空気調和機器1の制御に用いる1つ以上のエンジン3を取得するか、空気調和機器1の制御に用いる1つ以上のエンジン3を与えられた情報を基に生成する(ステップS220)。つぎに、エンジン取得部5は、取得または生成したエンジン3を機器制御部6に出力する(ステップS230)。
次に、処理構成の具体的な例について説明する。図9は、実施の形態2における処理構成の基本例を示す図である。図9では、前処理エンジンX102と、前処理エンジンY105と、抽象制御エンジン106と、後処理エンジン107と、稼働情報送信エンジン111と、を用いた空気調和機器1の制御動作を実現するための処理構成である。実際の空気調和機器には、図9よりはるかに多くの入出力、制御処理が含まれているが、説明のためにそのごく一部のみを切り取って簡略化している。
前処理エンジンX102は、外部入力情報として赤外線センサ101から熱画像を取得し、空気調和機器1の空気調和対象空間である室内における在室人数、室内における人の位置、室内における人の姿勢、室内における人の運動量などの情報を出力する処理を行う。
前処理エンジンY105は、外部入力情報として室内センサ103から室温の情報を取得する。また、前処理エンジンY105は、機種依存の情報として、リモコン104から設定温度、設定湿度、風向および風速などのリモコン104の操作内容の情報であるリモコン操作情報を取得する。そして、前処理エンジンY105は、物理量で表現された情報として、風向および風速などの機種に依存しない物理量を生成する処理を行う。
抽象制御エンジン106は、前処理エンジンX102と前処理エンジンY105とが生成した情報から、空気調和機器1の空気調和制御動作を決定し、空気調和機器1の機種に依存しない情報として、風向および風速などの制御情報、運転モードおよび消費電力などの稼働情報、を出力する。抽象制御エンジン106は、例えば、風向および風速の情報がリモコン104によって明示的に指定されている場合は指定された風向および風速をそのまま制御情報として出力する。また、抽象制御エンジン106は、風向および風速の情報が「自動」などのように明示されていない場合は、前処理エンジンX102及び前処理エンジンY105が生成した情報を基に適切な値を算出して、制御情報として出力する。図9に示した例の場合、抽象制御エンジン106は、前処理エンジンX102と前処理エンジンY105とに依存しており、両方の前処理エンジンの処理の完了後に、抽象制御エンジン106の処理を開始する。
後処理エンジン107では、抽象制御エンジン106から出力された風向および風速などの情報を入力として、ファン108の回転数、フラップ109の向き及びルーバ110の向きといった、各アクチュエータ10への指令値を算出する。
稼働情報送信エンジン111は、抽象制御エンジン106から出力された稼働情報を入力として、クラウドシステム11などの外部システムへ稼働情報を通信部112から送信できるように情報生成処理を行う。
処理構成格納部30に保存される処理構成情報は、上述した5つのエンジンの処理の実行順序または5つのエンジンの依存関係がわかるものであり、例えばスクリプトなどに記載する。
なお、処理構成情報は図9に示すように処理構成のパターンごとに保存してもよいし、各エンジン3で必要な入出力を保存して、エンジン取得部5で条件に合ったエンジン3を選択できるようにしてもよい。各エンジン3が使用する情報の依存関係が示されていれば形式は問わない。
図10は、実施の形態2における処理構成の定義例を示す図である。図10では、依存元エンジンと、依存先のエンジンと、使用する情報の名前と、が表形式で示されている。図10では、表において同じ行に示された、依存元エンジンと、依存先エンジンと、使用する情報の名前と、が関連している。使用する情報の名前は、依存先エンジンの出力情報の名前であって、依存元エンジンが使用する情報の名前である。
例えば、図10に示すように、依存元エンジンごとに、依存先エンジンと使用する情報とを定義することにより、各依存元エンジンがどの依存先エンジンのどの出力情報を使用するかが一意に特定される。なお、図10では外部入出力先も依存先エンジンの一部として取り扱っているが、必ずしもそのように扱う必要はなく、依存元エンジンと依存先エンジンとの間の依存関係のみが分かればよい。
図11は、実施の形態2における処理構成の変更例を示す図である。図11では、図9で示した処理構成において、外部入力情報の取得先となるセンサを変更した場合の処理構成の例を示したものである。具体的に、図11で示した処理構成は、空気調和機器の買い替えまたは外出先での空気調和機器の利用などにより、赤外線センサ101に対応した空気調和機器1からBLE(Bluetooth Low Energy)(登録商標)デバイス201に対応した空気調和機器1に変更して使用する場合である。
前処理エンジンX’202は、外部入力情報としてBLEデバイス201からビーコン情報を取得し、空気調和機器1の空気調和対象空間である室内における在室人数、室内における人の位置、室内における人の姿勢、室内における人の運動量などを出力する処理を行う。
処理構成格納部30は、図11に示すような、前処理エンジンX’202を含む処理構成を、処理構成情報として保存する。
エンジン取得部5は、処理構成格納部30から図11に示す処理構成情報を取得する。エンジン取得部5は、取得した処理構成情報に基づきエンジン3を取得または生成するため、空気調和機器の機種や対応可能な外部機器が変更されても、ユーザは変更される前の空気調和機器1で行われていたとおりの空気調和機器の空気調和制御動作を実現することができる。
なお、図11では空気調和機器1のセンサ8を1つだけ変更したが、追加、変更または削除する空気調和機器1のセンサ8、アクチュエータ10及び外部機器は複数あってもよい。
図12及び図13は、図9に示した処理構成に対する処理構成の追加例を示す図である。図12は、インターネット等を介して天気予報から1時間後の気温及び湿度を入手できる機種Cの空気調和機器1の例である。図13は、天気予報から1時間後の気温及び湿度を入手する機能が搭載されていない機種Dの空気調和機器1の例である。
図12及び図13では、図9に示した処理構成において、抽象制御エンジンへの入力を追加し、前処理エンジンを追加した入力に対応する前処理エンジンに置き換えた処理構成の例を示したものである。具体的には、1時間後の気温及び1時間後の湿度の予測情報から、空気調和機器1の現在の空気調和制御動作を決定する機能を抽象制御エンジン14へ追加する。
図12において、前処理エンジンZ302は、外部入力情報として、機種Cの空気調和機器1が備える通信部301から天気予報を取得し、1時間後の気温の情報及び1時間後の湿度の情報を出力する処理を行う。
図13において、前処理エンジンZ’402は、外部入力情報として、機種Dの空気調和機器1が備える温湿度センサ401から外気温の情報と湿度の情報とを取得し、1時間後の気温の情報及び1時間後の湿度の情報を出力する処理を行う。
処理構成格納部30は、図12及び図13に示すような前処理エンジンZ302及び前処理エンジンZ’402を含む処理構成を、処理構成情報として保存する。ここで、図9に示した処理構成から前処理エンジン13が1つ追加されているため、処理構成情報には、前処理エンジンZ302及び前処理エンジンZ’402から出力したパラメータである、1時間後の気温の情報および1時間後の湿度の情報を入力として処理可能な抽象制御エンジン14である抽象制御エンジン(新バージョン)303を含める。抽象制御エンジン(新バージョン)303における(新バージョン)は、図9に示した抽象制御エンジン106に対して新しいバージョンの抽象制御エンジン14であることを示す。
機種Cの空気調和機器1を使用する場合、エンジン取得部5は、処理構成格納部30から図12に示す処理構成情報を取得し、処理構成情報に基づきエンジン3を取得または生成する。
機種Dの空気調和機器1を使用する場合、エンジン取得部5は、処理構成格納部30から図13に示す処理構成情報を取得し、処理構成情報に基づきエンジン3を取得または生成する。
上記の構成をとることにより、空気調和機器1によって対応可能な機能が異なる場合でも、ユーザは自分が普段使用している空気調和機器1において行われている普段通りの空気調和制御動作を実現することができる。
なお、図12及び図13では前処理エンジン13を1つだけ追加したが、追加、変更または削除するエンジン3は複数あってもよい。
また、図12及び図13では前処理エンジン13の追加のみであったが、追加、変更または削除するエンジン3は前処理エンジン13、抽象制御エンジン14、後処理エンジン15、またはその他の性質を持つエンジン3のいずれかもしくはこれらのエンジン3を複数組み合わせたものであってもよい。
図14は、実施の形態2における空気調和制御システムの変形例を示す図である。実施の形態1及び実施の形態2において、図14に示すように、空気調和制御システム4に、エンジン取得部5が取得した各エンジン3に含まれる処理を適正化する処理適正化部31を追加することで、空気調和機器1の空気調和制御の処理速度および空気調和機器1が備えるメモリのメモリ効率性の向上が可能となる。
処理適正化部31は、各エンジン3に含まれている処理を、使用する空気調和機器1に合わせて適正化する。例えば、エンジン3がスクリプト形式で保存されていた場合、処理適正化部31が行う適正化の処理は、使用する空気調和機器1では不要なスクリプトを削除する処理が挙げられる。また、エンジンがソースコード形式で管理されている場合、処理適正化部31が行う適正化の処理は、ソースコードをビルドして処理速度、メモリ使用量、コードサイズ等の観点で適正化したオブジェクトファイルを生成する処理が挙げられる。
機器制御部6は、処理適正化部31が適正化した、エンジン3に含まれている処理を用いて、空気調和機器1の空気調和制御動作を実行する。
図15は、実施の形態2における空気調和制御システムにおいて嗜好推定部をエンジンとして処理構成に含んだ場合の処理構成例を示す図である。図15は、嗜好推定部503が空気調和機器1の内部に配置されて、空気調和機器1の内部で嗜好推定部503による嗜好推定処理が行われる場合の処理構成の例を示している。
実施の形態1及び実施の形態2において、外部から入力された情報および機器制御部6の内部データのうちの少なくとも一方を用いて空気調和機器1の空気調和制御動作に関するユーザの嗜好を推定する嗜好推定部503を具備することで、空気調和機器1の制御動作に関するユーザの好みを推定し、好みを反映した空気調和機器1の制御動作を実現することができる。
嗜好推定部503は、嗜好推定部503の外部から入力された情報、各エンジン3から入力された情報、および機器制御部6の内部データのうち、少なくとも1つを用いて、空気調和機器1の空気調和制御動作に関するユーザの嗜好を推定する。嗜好推定部503の外部から入力された情報および各エンジン3から入力された情報は、外部から入力された情報である。
嗜好推定部503への入力としては、例えば、嗜好推定部503の外部から入力された情報であるリモコン操作内容、エンジン3から入力された情報である空気調和機器の制御情報、および嗜好推定部503の外部から取得できる外部入力情報などがある。リモコン操作内容の例は、設定温度、設定湿度、風向、風速についてのリモコン104における操作内容である。空気調和機器の制御情報の例は、時刻、室内温度、稼働時間、空気調和機器1の設定である。外部から取得できる外部入力情報の例は、熱画像、活動量、体温である。
嗜好推定部503が出力する解析結果である嗜好解析結果は、嗜好推定部503における推定結果であり、空気調和機器1の制御動作に関するユーザの好みを示す情報であり、例えば、風当ての好み、風よけの好み、暑がり、寒がりなどがある。
嗜好推定部503の処理は、例えば、ユーザのリモコン操作の履歴から、風あての好み、風よけの好み、暑がり、寒がりおよび節電志向の強さなどの嗜好を推定する処理が挙げられる。また、嗜好推定部503の処理は、例えば、熱画像を用いて、ユーザの体温および手足の温度から、暑がりまたは寒がりを推定する処理が挙げられる。また、ユーザの姿勢およびユーザの運動状態に対応して、空気調和機器1の制御動作に関するユーザの嗜好を別々に解析することも有効である。ユーザの運動状態は、例えば、ユーザが立っている「立位」、ユーザが座っている「座位」、ユーザが作業中である「作業中」、ユーザが寝ている「睡眠中」などが挙げられる。
図15に示す処理構成は、具体的には、図9に示した処理構成に加えて、前処理エンジンY105から取得したリモコン操作内容と、抽象制御エンジン501が出力した空気調和機器1の制御情報を蓄積した制御履歴502の情報とを入力とし、嗜好解析結果を出力する嗜好推定部503を有するものである。
通信部112は、嗜好推定部503から嗜好解析結果を取得し、例えばクラウドシステムおよびアプリケーションといった外部システムと通信を行う。
なお、図15では嗜好推定部503をエンジン3の1種類として示しているが、嗜好推定部503は、エンジン3とは異なる独立した仕組みとして実現されてもよい。すなわち、空気調和機器1の制御動作に関するユーザの嗜好を推定する処理が含まれていれば、嗜好推定部503の実現方法は問わない。
図15に示した処理構成では、各エンジン3及び嗜好推定部503が空気調和機器1内に配置されているが、各エンジン3及び嗜好推定部503の各ブロックの配置は任意であり、これに限らない。図16は、実施の形態2における空気調和制御システムにおいて嗜好推定部をエンジンとして処理構成に含んだ場合の処理構成例を示す図である。例えば図16のように、嗜好推定部503がクラウドシステム11に配置され、空気調和機器1の通信部112及びクラウドシステム11の通信部601を介して嗜好解析に必要な情報を空気調和機器1から嗜好推定部503に渡す構成としてもよい。
図16において抽象制御エンジン501は、前処理エンジンY105から取得したリモコン操作情報と、空気調和機器1の制御情報を含む稼働情報を出力する。
稼働情報送信エンジン111は、抽象制御エンジン501から出力された稼働情報を入力とし、クラウドシステム11などの外部システムへ稼働情報を送信できるように情報生成処理を行う。
空気調和機器1の通信部112は、クラウドシステム11の通信部601と通信を行い、稼働情報送信エンジン111から出力された稼働情報をクラウドシステム11へ送信する。
嗜好推定部503は、空気調和機器1から取得した稼働情報を入力とし、空気調和機器1の空気調和制御動作に関するユーザの嗜好を推定し、嗜好解析結果を出力する処理を行う。
なお、図16における嗜好推定部503は、空気調和機器1から取得した稼働情報のみを入力としたが、嗜好推定部503が空気調和機器1の外部のシステムに配置される場合における嗜好推定部503への入力はこれに限らない。嗜好推定部503が空気調和機器1の外部のシステムに配置される場合は、嗜好推定部503が配置されているシステムが取得可能な情報、または嗜好推定部503が配置されているシステムが保存している情報を、嗜好推定部503への入力の1つとしてもよい。嗜好推定部503が配置されているシステムが取得可能な情報には、例えば、空気調和機器1の制御情報、稼働情報の履歴、他のユーザの空気調和機器1の制御動作に関する嗜好の情報などがある。
図17は、実施の形態2における環境特性推定部を具備する空気調和制御システムの処理構成例を示す図である。実施の形態1及び実施の形態2において、外部から入力された情報および機器制御部6の内部データのうちの少なくとも一方を用いて空気調和対象とする環境の特性を推定する環境特性推定部702を具備することで、空気調和対象の環境を考慮した空気調和機器1の制御動作を実現することができる。
環境特性推定部702は、環境特性推定部702の外部の外部機器から入力された情報、各エンジン3から入力された情報、および機器制御部6の内部データのうち、少なくとも1つを用いて、空気調和対象とする環境の特性を推定する。環境特性推定部702の外部の外部機器から入力された情報および各エンジン3から入力された情報は、外部から入力された情報である。外部機器から入力された情報としては、例えば熱画像、室内温湿度、風速、気圧、室内空気質などの情報が挙げられる。機器制御部6の内部データとしては、例えば時刻、室内温度、稼働時間、空気調和機器1の設定、ファン108の回転数、フラップ109の向き、ルーバ110の向きなどの情報が挙げられる。
空気調和対象とする環境の特性とは、環境特性推定部702から出力される、空気調和対象となる空間に関する情報である。空気調和対象とする環境の特性は、例えば、熱損失係数を示すQ値、外皮平均熱貫流率を示すUA値、家具または熱源の位置の情報などがある。以降、空気調和対象とする環境の特性を「環境特性」と記載する場合がある。
環境特性推定部702の処理は、例えば、投入した熱量と室温の時間変化とに基づいてQ値を推定する処理、熱画像から窓などの熱が出入りしやすい箇所を検出する処理が挙げられる。また、環境特性推定部702の処理は、例えば、空気調和機器1から空気調和対象となる空間に吐出する調和空気の吐出温度、風向、風速、過去の熱画像情報及び現在の熱画像情報に基づいて、空気調和機器1から空気調和対象となる空間に吐出される風の到達状況を判断し、空気調和対象となる空間における家具などの障害物の配置を推定する処理、及び空気調和対象となる空間における壁、天井、床の位置を推定する処理などが挙げられる。
図17に示す処理構成は、具体的には、図9で示した処理構成に加えて、外部入力である赤外線センサ101から取得した熱画像と、抽象制御エンジン701が出力した空気調和機器の制御情報を蓄積した制御履歴502を入力とし、環境特性を出力する環境特性推定部702を有するものである。
図17における抽象制御エンジン701は、図9で示した抽象制御エンジン106が行う処理に加え、環境特性推定部702から取得した環境特性を入力の1つに含み、風向、風速、稼働情報、制御情報などの空気調和機器1の機種に依存しない情報として出力する処理を行う。
なお、図17では環境特性推定部702をエンジン3の1種類として示しているが、環境特性推定部702は、エンジン3とは異なる独立した仕組みとして実現されてもよい。すなわち、空気調和対象の環境特性を推定する処理が含まれていれば、環境特性推定部702の実現方法は問わない。
図17に示した処理構成では、各エンジン3及び環境特性推定部702が空気調和機器1内に配置されているが、各エンジン3及び環境特性推定部702の各ブロックの配置は任意であり、これに限らない。例えば図16の嗜好推定部503と同様に、環境特性推定部702がクラウドシステム11に配置され、空気調和機器1の通信部112及びクラウドシステム11の通信部601を介して、空気調和対象とする環境の特性の解析に必要な情報を環境特性推定部702に渡す構成としてもよい。
実施の形態3.
実施の形態3では、使用するエンジン3を適切に選択することで、ユーザにとってより好ましい空気調和制御を実現する例について説明する。
図18は、実施の形態3における空気調和制御システムの構成を示す図である。空気調和制御システム4は、実施の形態1において図1に示す構成に加えて、通信部29と、ユーザ識別部33と、ユーザ情報管理部34と、使用エンジン決定部32と、を有する。
通信部29は、グローバルな情報通信網であるインターネット等の不図示のネットワークを介して外部システムと通信を行う。外部システムの例は、スマートフォン35である。すなわち、ユーザは、外部機器を用いて空気調和制御システム4にアクセスする。
ユーザ識別部33は、外部システムから空気調和制御システム4にアクセスしてきたユーザを識別する。
ユーザ情報管理部34は、ユーザと、ユーザが普段使用するエンジン3またはユーザの嗜好とを紐付けた情報を管理する。以降、ユーザが普段使用するエンジン3とユーザの嗜好を合わせて「嗜好情報」と記載する。なお、ユーザが普段使用するエンジン3とユーザの嗜好のうち一方であってもよい。ユーザが普段使用するエンジン3は、ユーザが普段使用する空気調和機器1において使用されているエンジン3である。
使用エンジン決定部32は、ユーザ情報管理部34が有する情報から使用するエンジンである使用エンジンを特定する。
図18上では、通信部29、エンジン取得部5、エンジン格納部2、使用エンジン決定部32、ユーザ識別部33及びユーザ情報管理部34は、クラウドシステム11に配置されているが、これらの各ブロックの配置は任意でありこれに限られない。すなわち、通信部29、エンジン取得部5、エンジン格納部2、使用エンジン決定部32、ユーザ識別部33及びユーザ情報管理部34は、空気調和機器1内に配置されてもよい。
次に、本実施の形態3における空気調和制御システム4の動作を説明する。動作は大きく分けて、「ユーザ登録」、「嗜好情報登録」、「エンジン取得」の3つの段階に分かれる。
図19は、実施の形態3におけるユーザ登録での空気調和制御システムの処理手順を示すフローチャートである。ユーザ登録段階では、通信部29がユーザ登録の要求を受ける。すなわち、ユーザが、スマートフォン35のアプリケーション等を通じて空気調和制御システム4の通信部29にアクセスし、ユーザ登録を要求する(ステップS310)。
つぎに、空気調和制御システム4の通信部29がユーザ識別部33にユーザ登録を依頼すると、ユーザ識別部33は、ユーザを一意に識別する情報であるユーザ識別情報を発行する(ステップS320)。ユーザを一意に識別する情報は、ユーザ識別部33で自動的に発行されてもよい。また、ユーザを一意に識別する情報は、ユーザを一意に識別する情報を確認した旨の情報がユーザからユーザ識別部33に入力されることで、ユーザ識別部33によるチェックとユーザによるチェックとによる重複チェックが行われた上で、ユーザ識別部33が発行してもよい。
続いて、ユーザ識別部33は、嗜好情報を生成する(ステップS330)。初期の嗜好情報は、無しとしてもよいし、空気調和制御システム4でデフォルトとして決めているもの、もしくはユーザ登録時の情報から自動的に決定してもよい。ユーザ識別部33は、ユーザを一意に識別するユーザ識別情報と、嗜好情報とを紐付けてユーザ情報管理部34に登録する(ステップS340)。また、必須ではないが、空気調和制御システム4へのアクセスを制御するために、パスワード等のユーザを認証するための情報もユーザ情報管理部34に登録してもよい。
なお、ユーザが空気調和制御システム4にアクセスするための外部機器は、スマートフォン35の代わりに、パーソナルコンピュータ、専用の端末、およびリモコンなどの機器が用いられてもよい。ユーザ登録の方法は、Web(World Wide Web)ブラウザを用いた方法およびコマンドを用いた方法などの別の方法が用いられてもよい。また、ユーザの通信経路も任意であり、例えばクラウドシステム11にユーザ情報管理部34が配置されている場合、スマートフォン35がクラウドシステム11と直接通信を行ってもよいし、スマートフォン35が空気調和機器1の通信部7と通信を行って空気調和機器1の通信部7がクラウドシステム11の通信部29と通信を行う方式でもよい。
続いて、図20を用いて嗜好情報の登録時の動作を説明する。図20は、実施の形態3における嗜好情報登録の処理手順を示すフローチャートである。嗜好情報の登録は、任意のタイミングで行える。例えば、ユーザが現在の空気調和機器1の制御を気に入った場合に、任意のタイミングでスマートフォン35のアプリケーションを操作して嗜好情報を登録する方法、空気調和機器1が自動で定期的に嗜好情報を登録する方法、人が在室中であるが運転中の空気調和機器1に対して一定時間操作が行われなかった場合に、該当する制御が快適であると判断して嗜好情報を登録するなどの方法が挙げられる。
嗜好情報の登録時は、まず、空気調和制御システム4の通信部29が、嗜好情報登録の要求を受ける(ステップS410)。すなわち、スマートフォン35が、空気調和機器1から嗜好情報を受け取る。そして、スマートフォン35が、空気調和制御システム4の通信部29に対して、ユーザ識別情報と共に嗜好情報を送信し、嗜好情報の登録要求を行う。嗜好情報の登録要求においてパスワード等による嗜好情報の登録の認証が必要な場合は、スマートフォン35が、嗜好情報の登録を認証するための認証情報も空気調和制御システム4の通信部29へ送信する。
次に、ユーザ識別部33が、ユーザの識別及び認証を行う(ステップS420)。すなわち、ユーザ識別部33は、通信部29を介してユーザ識別情報および認証情報を受け取ると、ユーザ情報管理部34に保存された情報を用いて、該当するユーザの存在有無の確認及びユーザの認証を行う。なお、ユーザの認証は、必要な場合に行われればよい。ユーザ情報管理部34に保存された情報は、ユーザを一意に識別するユーザ情報と嗜好情報とが紐付けられた情報である。
次に、ユーザ識別部33が、ユーザの識別及び認証が成功したか否かを判定する(ステップS430)。ユーザの識別及び認証が成功した場合は(ステップS430でYes)、ユーザ識別部33は、ユーザ情報管理部34に保存されているユーザを一意に識別するユーザ情報と嗜好情報とが紐付けられた情報において、該当するユーザの嗜好情報を更新する(ステップS440)。ユーザの識別または認証の少なくとも一方が失敗した場合は(ステップS430でNo)、ユーザ識別部33は、スマートフォン35に対してエラーのメッセージを返し(ステップS450)、一連の処理を終了する。
ここで嗜好情報とは、空気調和機器1で使用しているエンジン3の情報、実施の形態2に記載の嗜好推定部503の処理結果、および後述する実施の形態4で説明するユーザの空気調和機器1の制御に対する好みのフィードバック情報が該当する。また、実施の形態2で説明したように嗜好推定部503による嗜好推定処理をクラウドシステム11で実行する場合は、嗜好推定に用いる情報をクラウドシステム11に送信する際に予めユーザ識別情報と紐付けておく。そして、スマートフォン35は、嗜好情報の登録の要求時は嗜好情報を送らずにユーザの識別情報のみを送信し、クラウドシステム11にて該当ユーザに紐付けられた嗜好情報を入手する。
また、図20に示すフローチャートでは、スマートフォン35が空気調和機器1から嗜好情報を受け取る手順で説明したが、これに限らない。すなわち、クラウドシステム11の通信部29がユーザの認証情報と嗜好情報とを取得できる方法であれば、どのような方法が用いられてもよい。例えば、スマートフォン35が空気調和機器1に嗜好情報の登録を要求する。空気調和機器1の通信部7が、スマートフォン35からユーザ識別情報を受け取り、クラウドシステム11の通信部29にアクセスする方法を採ることも可能である。そして、通信部7が、通信部29に対して、ユーザ識別情報と嗜好情報とを送信し、嗜好情報の登録要求を行う。
また、スマートフォン35が、空気調和機器1へアクセスするために必要な情報のみを取得して、ユーザ識別情報と共にクラウドシステム11の通信部29へ送信する。そして、通信部29が、空気調和機器1へアクセスするために必要な情報を用いて空気調和機器1へアクセスし、空気調和機器1から嗜好情報を取得してもよい。通信部29がユーザ識別情報と嗜好情報とを取得することで、嗜好情報の登録要求が行われたこととする。
最後に、図21を用いてエンジン3の取得時の動作を説明する。図21は、実施の形態3におけるエンジン3の取得時の処理手順を示すフローチャートである。エンジン3の取得は、任意のタイミングで行われればよいが、主には空気調和機器1の起動時に行われる。まず、通信部29が、エンジン3の取得の要求を受ける(ステップS510)。すなわち、スマートフォン35が空気調和制御システム4の通信部29にアクセスし、ユーザ識別情報を通信部29に送信し、エンジン3の取得要求を行う。エンジン3の取得の要求においてパスワード等によるエンジン3の取得の要求の認証が必要な場合は、スマートフォン35が、エンジン3の取得の要求を認証するための認証情報も空気調和制御システム4の通信部29へ送信する。
次に、ユーザ識別部33が、ユーザの識別及び認証を行う(ステップS520)。すなわち、ユーザ識別部33は、通信部29を介してユーザ識別情報および認証情報を受け取ると、ユーザ情報管理部34に保存された情報を用いて、該当するユーザの存在有無の確認及びユーザの認証を行う。なお、ユーザの認証は、必要な場合に行われればよい。ユーザ情報管理部34に保存された情報は、ユーザを一意に識別するユーザ識別情報と嗜好情報とが紐付けられた情報である。
次に、ユーザ識別部33が、ユーザの識別及び認証が成功したか否かを判定する(ステップS530)。ユーザの識別及び認証が成功した場合は(ステップS530でYes)、使用エンジン決定部32が、ユーザ情報管理部34に保存されているユーザを一意に識別するユーザ識別情報と嗜好情報とが紐付けられた情報から、該当するユーザの嗜好情報を取得する(ステップS540)。
ユーザの識別または認証のうち少なくとも一方が失敗した場合は(ステップS530でNo)、ユーザ識別部33は、エラーとするか否かを判定する(ステップS570)。ステップS570においてエラーとするか否かは、あらかじめ決められてユーザ識別部33に設定される。
エラーとすると判定された場合は(ステップS570でYes)、ユーザ識別部33は、スマートフォン35に対してエラーのメッセージを返し(ステップS590)、一連の処理を終了する。
エラーとしないと判定された場合は(ステップS570でNo)、使用エンジン決定部32が、空気調和制御システム4でデフォルトとして決めている既定の嗜好情報を取得する(ステップS580)。例えば、使用エンジン決定部32は、空気調和機器1の外部から入力されて保存されている既定の嗜好情報を取得する。既定の嗜好情報は、例えば使用エンジン決定部32に記憶されるが、これに限定されない。
使用エンジン決定部32は、取得した嗜好情報を基に、ユーザが使用するエンジン3を決定する(ステップS550)。使用エンジン決定部32は、例えば、ユーザ情報管理部34に記憶されている、ユーザと、ユーザが普段使用するエンジン3またはユーザの嗜好とを紐付けた情報において、嗜好情報が直接エンジン3と紐付いている場合は該当エンジン3を特定して、使用エンジンに決定する。使用エンジン決定部32は、例えば、ユーザ情報管理部34に記憶されている、ユーザと、ユーザが普段使用するエンジン3またはユーザの嗜好とを紐付けた情報において、嗜好情報が直接エンジン3と紐付いていない場合はユーザの嗜好との一致度が高く、より新しいエンジン3を演算により特定して、使用エンジンに決定する。使用エンジン決定部32は、ユーザが使用する1つ以上の使用エンジンを決定する。嗜好情報である嗜好推定部503の処理結果は、嗜好推定部503における解析結果である。したがって、例えば嗜好情報が嗜好推定部503の処理結果である場合は、使用エンジン決定部32は、解析結果であるユーザの嗜好に対応して、使用すべきエンジン3を特定する。
エンジン取得部5は、使用エンジン決定部32が特定したエンジン3について、エンジン格納部2からの取得または生成を行い、通信部29を介してスマートフォン35に送信する(ステップS560)。エンジン取得部5は、エンジン3をスマートフォン35に送信する際に、実施の形態2に記載の処理構成の情報も同時に送信してもよい。
スマートフォン35は、受け取ったエンジン3を空気調和機器1の機器制御部6に送信する。機器制御部6は、受け取ったエンジン3を基に、空気調和機器1の制御を行う。さらに、スマートフォン35は、受け取った処理構成を必要に応じて空気調和機器1の機器制御部6に送信する。機器制御部6は、受け取ったエンジン3及び処理構成を基に、空気調和機器1の制御を行う。
また、嗜好情報の登録と同様に、スマートフォン35が空気調和機器1へエンジン3を渡すのではなく、空気調和機器1がスマートフォン35からユーザ識別情報を受け取り、ユーザ識別情報を用いて空気調和制御システム4の通信部29にアクセスして、エンジン取得部5からエンジン3を取得する方法を採用してもよい。このように、他の方法を用いて、ユーザの識別及び認証、並びにエンジン3及び処理構成の取得が行われてもよい。
このように空気調和制御システム4が構成されることで、ユーザは、自らが好む空気調和機器1の制御を自分のスマートフォン35に保存しておき、保存した空気調和機器1の制御をスマートフォン35から他の空気調和機器に移すことで、スマートフォン35に保存した空気調和機器1の制御を他の空気調和機器で活用することを容易に実現できる。
図22は、実施の形態3における嗜好情報を活用する処理構成例を示す図である。例えば、図22に示した処理構成の場合、図9に示した抽象制御エンジン106に代わって使われている嗜好情報活用エンジン802は、リモコンから送信される設定温度、設定湿度、風向、風速等の情報を必要とせず、室温及び熱画像を解析して得られた情報から、嗜好情報を考慮して自律的に目標温湿度、風向および風速等を決定する。図22に示した処理構成の場合、図9に示した処理構成の場合と比較すると、抽象制御エンジン106が嗜好情報活用エンジン802に置き換わった影響で、前処理エンジンY’801の入力においてリモコン104からの入力情報が不要となり、前処理エンジンY’801の出力においては物理量で表現された風向および風速が不要となる。
また、本実施の形態3に、空気調和機器1の使用開始時刻を指定できるようにすることで、更なる効果が得られる。図23は、実施の形態3における空気調和制御システムの構成の変形例を示す図である。図23に示す空気調和制御システム4の構成は、図18に示す空気調和制御システム4の構成に対して、空気調和機器1の使用を開始する時刻を設定できる使用開始時刻受付部36を加えている。
ユーザは、インターネット等を介して、自らのユーザ識別情報、使用予定の空気調和機器1及び空気調和機器1の使用開始予定時刻を予約情報として、予め空気調和制御システム4の使用開始時刻受付部36に送信しておく。使用開始時刻受付部36は、使用開始時刻受付部36が実装されている空気調和機器1に対する予約の中で使用開始予定時刻が最も直近である予約情報を参照する。
続いて、使用開始時刻受付部36は、予約情報に含まれるユーザ識別情報に基づいて必要なエンジン3をエンジン取得部5から入手し、機器制御部6に送信する。エンジン取得部5は、使用開始時刻受付部36から予約情報に含まれるユーザ識別情報を受け取り、ユーザ識別情報に基づいて、上述した処理のいずれかの処理を行って、1つ以上のエンジン3を取得または生成する。エンジン取得部5は、取得または生成したエンジン3を使用開始時刻受付部36に送信する。
また、使用開始時刻受付部36は、使用開始予定時刻にユーザの嗜好に沿った空気調和環境となるように機器制御部6に指示を行う。使用開始時刻受付部36は、例えば、予約情報に含まれる目標温度と現在の室温との差と、使用開始予定時刻とから、空気調和制御の開始時刻を算出し、機器制御部6に対して設定を行う。
このような構成を取ることで、ユーザが空気調和機器1の使用を開始した際に、空気調和不足または過剰空気調和から生じる不快感を防げる。また、使用開始予定時刻を予め使用開始時刻受付部36に入力しておくことで、早すぎるタイミングで空気調和を行うことによる熱損失、または使用開始直後に急激な冷暖房を行うことによる空気調和負荷増大によって生じるエネルギーロスを低減できるため、空気調和機器1の消費電力を抑えられる。
また、ユーザの室内への入室予定時刻または使用予定の空気調和機器の識別情報が空気調和制御システム4の外部の外部システムから得られる場合は、ユーザから該当情報の送信を求めずに、空気調和制御システム4の通信部7または通信部29が外部システムと連携して、必要な情報を取得してもよい。例えば、外部システムとしてホテルまたは飲食店などの予約システムが存在する場合、予約システム上に保存されている該当ユーザの予約情報を参照し、入室予定時刻または使用予定の空気調和機器の情報を得る方法が採用できる。この場合、使用予定の空気調和機器の情報は、予約されている部屋の情報と紐付けられている。
なお、本実施の形態3では、ユーザを識別し、ユーザの嗜好情報を基にエンジン3を選択する例について説明したが、使用するエンジン3の決定方法はこれに限定されない。例えば、後述する実施の形態5で説明するように、空気調和対象とする環境の特性に対応して使用するエンジン3を選択する方法を採ってもよい。また、使用するエンジン3がユーザ個人に依存しない場合には、ユーザを識別する必要が無いため、ユーザ識別部33及びユーザ情報管理部34は不要な構成となる。
実施の形態4.
続いて実施の形態4では、ユーザの嗜好情報が予め与えられていない時に、ユーザに快適な空気調和環境を提供する例を説明する。
図24は、実施の形態4における空気調和制御システムの構成を示す図である。空気調和制御システム4は、図1に示す実施の形態1の構成に加え、ユーザへの空気調和制御に関する質問を表示するとともに空気調和制御に関する質問へのユーザからの回答を受け付けるユーザインタフェース部37と、空気調和制御システム4がインターネット等を介して外部システムと通信を行う通信部29と、使用するエンジン3を特定する使用エンジン決定部32とを有する。ユーザインタフェース部37は、ユーザが、空気調和制御に関する案内または空気調和制御に関する質問の内容を確認したり、空気調和制御に関する質問への回答または空気調和環境に対する評価を入力したりすることができる。
ユーザインタフェース部37は、図24ではスマートフォン35上に配置しているが、ユーザインタフェース部37の配置は任意であり、これに限らない。ユーザインタフェース部37は、例えばパーソナルコンピュータ上および空気調和機器1のリモコン上のいずれかに配置されてもよいし、音声等の視覚的情報以外の構成を用いたユーザインタフェースでもよい。
続いて、実施の形態4における空気調和制御システム4の動作について説明する。ユーザは、空気調和機器1の使用を開始する際など任意のタイミングで、自らが好む空気調和制御の開始をユーザインタフェース部37に要求する。ユーザインタフェース部37は、空気調和機器1の機種を識別する機種識別情報を取得し、空気調和制御システム4の通信部29へ、ユーザが好む空気調和制御の開始の要求を送信する。機種識別情報は、例えばクラウドシステム11に設けられる記憶部または空気調和機器1に設けられる記憶部に記憶されている。
続いて、使用エンジン決定部32は、ユーザが好む空気調和制御の開始の要求と機種識別情報とを通信部29から受信すると、機種識別情報に示される空気調和機器1の機種に対応して予め用意されたユーザの好みに関する質問を1つ以上、通信部29を介してユーザインタフェース部37へ送信する。質問の内容は、例えば、「暑がりですか?寒がりですか?」「風は当たらないほうがよいですか?」「風音をひかえめにしますか?」のように、該当の空気調和機器1で制御できる内容に対応したものとされる。
ユーザは、ユーザインタフェース部37に質問への回答を入力する。ユーザインタフェース部37は、ユーザから入力された質問への回答を、通信部29を介して使用エンジン決定部32に送信する。質問への回答を受け取った使用エンジン決定部32は、回答に対応して適切なエンジン3を特定する。使用エンジン決定部32は、特定したエンジン3の情報をエンジン取得部5に送信する。
エンジン取得部5は、使用エンジン決定部32から受け取ったエンジン3の情報に基づいて1つ以上のエンジン3をエンジン格納部2から取得するか、使用エンジン決定部32から受け取ったエンジン3の情報に基づいてエンジン3を1つ以上生成し、機器制御部6に渡す。機器制御部6は、エンジン取得部5から渡されたエンジン3を用いて空気調和機器1の制御を行う。
このように空気調和制御システム4が構成されることで、ユーザは、ユーザインタフェース部37から出されるいくつかの質問に答えるだけで、リモコン9を操作して設定可能な項目を把握することなく、自らの希望に近い空気調和制御を享受することができる。これにより、ユーザにおける空気調和機器1の設定の負担を下げることができる。
また、ユーザインタフェース部37が、空気調和機器1の運転中に、空気調和環境に対する評価の情報を受け付けるようにすることで、更なる効果が得られる。ユーザは、現在の空気調和環境が不快であると感じている場合、ユーザインタフェース部37から不快と感じる理由を入力する。不快と感じる理由の例は、「暑い」、「寒い」、「じめじめする」、「風が当たる」、「音がうるさい」などである。不快と感じる理由の選択肢は、前述の質問と同様、機種に対応して予め用意する必要がある。
ユーザインタフェース部37は、現在使用しているエンジン3の情報、現在の空気調和制御の設定の情報、現在の空気調和環境の情報を空気調和機器1から取得し、空気調和環境に対する評価の情報である不快と感じる理由と共に空気調和制御システム4の通信部29へ送信する。なお、ユーザインタフェース部37は、現在の空気調和制御の設定の情報および現在の空気調和環境の情報のうちの一方と、現在使用しているエンジン3の情報と、を空気調和機器1から取得し、空気調和環境に対する評価の情報と共に空気調和制御システム4の通信部29へ送信してもよい。
使用エンジン決定部32は、ユーザインタフェース部37が送信した情報を通信部29から受け取ると、受け取った情報を基に、現在使用しているエンジン3のうち変更すべきエンジン3を特定する。すなわち、使用エンジン決定部32は、現在使用しているエンジン3のうち変更すべきエンジン3を特定し、また現在使用しているエンジン3から変更する適切なエンジン3を再選択する。また、使用エンジン決定部32は、必要に対応して処理構成を特定する。使用エンジン決定部32は、変更すべきエンジン3として特定したエンジン3の情報をエンジン取得部5に送信する。また、使用エンジン決定部32は、必要に対応して処理構成をエンジン取得部5に送信する。
エンジン取得部5は、使用エンジン決定部32から受け取ったエンジン3の情報に基づいて1つ以上のエンジン3をエンジン格納部2から取得するか、使用エンジン決定部32から受け取ったエンジン3の情報に基づいてエンジン3を1つ以上生成し、機器制御部6に渡す。機器制御部6は、エンジン取得部5から渡されたエンジン3を用いて空気調和機器1の制御を行う。
このように空気調和制御システム4が構成されることで、空気調和機器1の運転を続けてユーザが評価を入力していくにつれて、空気調和機器1が、ユーザの嗜好により近い空気調和制御を行えるようになり、ユーザの快適性を向上できる。
さらに、上記のユーザの空気調和環境に対する評価の情報を実施の形態2で説明した処理構成として含む構成も可能である。図25は、実施の形態4におけるスマートフォンを介して嗜好情報を入力する際の処理構成を示す図である。例えば、図25に示すように、スマートフォン901からの入力情報を前処理エンジンZ902で変換し、嗜好推定部903に入力することで、嗜好推定部903が嗜好解析結果として空気調和制御または空気調和環境に対するユーザの嗜好を推定することができる。
通信部112は、嗜好推定部903から嗜好解析結果を取得し、エンジン取得部5に嗜好解析結果を送信する。エンジン取得部5は、嗜好推定部903における嗜好解析結果を基にエンジン3を再取得または再生成し、更新することでユーザの快適性を向上できる。
さらに、図25では記載していないが、ユーザの空気調和環境に対する評価の情報または嗜好解析結果を、抽象制御エンジン501または後処理エンジン107への入力とすることでも、ユーザの空気調和環境に対する評価を反映した空気調和制御を行うこともできる。
実施の形態5.
続いて実施の形態5では、空気調和機器1が設置されている空間環境の特性情報を活用することで、部屋の形状または部屋における障害物の配置等の条件に合わせて適切な空気調和制御を行う例について説明する。すなわち、実施の形態5では、エンジン格納部2に格納されている、空気調和機器1が配置されている部屋の特性である部屋特性を空気調和機器1の空気調和制御に加味することを可能にするエンジン3を、使用するエンジンとして選択できる場合について説明する。部屋特性は、空気調和機器1の周辺の空間環境を特定できる情報、または空気調和機器1が配置されている空間の環境である空間環境の特徴を表す情報である。部屋特性の一例は、部屋そのものの形状である。また、部屋特性の他の例は、部屋における、家具もしくはテレビといった生活家電の配置、または障害物の配置などの、物理的な情報である。実施の形態5では、これらの空間環境の特性情報に対応して、空気調和機器1の空気調和制御を可能とする。
図26は、実施の形態5における空気調和制御システムの構成を示す図である。使用エンジン決定部32は、指定された環境特性に対応して適切なエンジン3を特定する。具体的に、使用エンジン決定部32は、部屋特性である、空気調和機器1の周辺の空間環境を特定できる情報または空気調和機器1が配置されている空間の環境である空間環境の特徴を表す情報の少なくとも一方を用いて、使用するエンジン3である使用エンジンを特定する。すなわち、使用エンジン決定部32が使用するエンジンの情報は、空気調和機器1の周辺の空間環境を特定できる情報または空間環境の特徴を表す情報の少なくとも一方である、といえる。ここでのエンジンの情報は、使用エンジン決定部32が使用するエンジンを特定するために用いる情報である。空気調和機器毎の環境特性の抽出方法は、例えば実施の形態2で説明したように、赤外線センサ101の情報を用いて空気調和機器1またはクラウドシステム11で推定する方法が挙げられる。機器制御部6では、エンジン取得部5を介して使用エンジン決定部32が特定したエンジン3を入手し、空気調和制御に用いる。
図27は、実施の形態5における処理構成の例1を示す図である。図28は、実施の形態5における処理構成の例2を示す図である。また、環境特性が特徴量等のパラメータで表現されている場合、図27のように環境特性1002を一種のエンジンとして処理構成に含み、制御アルゴリズムを実現するエンジンの入力とする構成も取ることができる。図27上では、当該エンジンを環境特性情報活用エンジン1003としている。また、図27における嗜好情報活用エンジン1001は、図22における嗜好情報活用エンジン802と同様の機能を有するとともに、例えば特定箇所の目標温度といった情報を環境特性情報活用エンジン1003に送信する。同様に、図28における嗜好情報活用エンジン1001は、図22における嗜好情報活用エンジン802と同様の機能を有するとともに、例えば特定箇所の目標温度といった情報を環境特性情報活用エンジン1104に送信する。
この場合、環境特性1002を環境によって差し替えるだけでよく、環境特性情報活用エンジン1003を変更する必要は無い。同様に、図28に示すように通信部1101からBIM(Building Information Modeling)情報を取得し、空間情報解析エンジン1102によって空気調和対象環境の特徴量1103を算出し、環境特性情報活用エンジン1104へのインプットとすることも可能である。図28では、空気調和対象環境の特徴量1103を空間特徴量1103と示している。さらに、空間情報または空間特徴量を算出するために必要な情報、例えば、部屋の広さ、形状、壁の材質などをリモコンまたはスマートフォンのアプリケーションから手動で入力する手段を採ることも可能である。
環境特性情報活用エンジン1003及び環境特性情報活用エンジン1104における具体的な処理例としては、例えば、図27及び図28で示す処理構成のように、空間の形状、家具等の障害物の設置位置及び空気調和機器自身の設置位置による風の届き方を考慮して風向や風速を調整する処理や、窓の位置や断熱性能を表すQ値から今後の温度を先読みして特定箇所の目標温度を決定する処理などが挙げられる。
このような構成を取ることで、風が届きにくい箇所への送風の適正化による省エネルギー、今後の気温変化による不快感防止などの効果を得られる。特に、ホテルおよび飲食店のように、空気調和機器が使用される環境は固定されているがユーザが一時的にしか滞在しない空間の場合、ユーザが空間環境に合わせて適切な設定を行うことは比較的困難である。上記構成を用いることで、ユーザが空間環境の特性を把握していなくても、環境特性情報活用エンジン1003及び環境特性情報活用エンジン1104によって適切な制御を行うことができるため、ユーザに快適な空気調和環境を適用できる。
また、実施の形態2で説明した環境特性推定部702と組み合わせることで、新規に設置した空気調和機器においても、空間環境特性を学習し、制御に反映することが可能となる。これにより、空気調和機器を使用していくにつれて、空間環境特性に合わせた省エネルギーかつ快適性の高い制御へと進化していくことが期待できる。
上述した実施の形態1から5にかかる空気調和制御システム4は、パーソナルコンピュータまたは汎用コンピュータといったコンピュータシステムにより実現される。図29は、実施の形態1から5にかかる空気調和制御システム4の機能をコンピュータシステムで実現する場合のハードウェア構成を示す図である。空気調和制御システム4の機能は、図29に示したハードウェア構成の処理回路として実現される。空気調和制御システム4の機能が図29に示す処理回路を有するコンピュータにより実現される場合、空気調和制御システム4の機能は、プロセッサ1201がメモリ1202に記憶された空気調和制御システムプログラムを実行することにより、実現される。また、複数のプロセッサおよび複数のメモリが連携して空気調和制御システム4の機能を実現してもよい。また、空気調和制御システム4の機能のうちの一部を電子回路として実装し、他の部分をプロセッサ1201およびメモリ1202を用いて実現するようにしてもよい。
以上の実施の形態に示した構成は、一例を示すものであり、別の公知の技術と組み合わせることも可能であるし、実施の形態同士を組み合わせることも可能であるし、要旨を逸脱しない範囲で、構成の一部を省略、変更することも可能である。