以下、図面を参照して、実施形態について説明する。
まず、図1を参照して、本実施形態に係る空調システム(情報処理システム)の概要について説明する。本実施形態に係る空調システムは、ユーザ端末10、空調制御装置20及び空調機30を備える。本実施形態に係る空調システムは、空調機(室内機)30が設置されている室内にいるユーザによって利用される。
ユーザ端末10は、ユーザによって使用される端末装置である。本実施形態においては、ユーザ端末10として例えばスマートフォンまたはタブレット端末等の携帯端末を想定しているが、ユーザ端末10は、デスクトップ型またはノートブック型のパーソナルコンピュータ等であってもよいし、ユーザが個人単位で使用するリモコンのような機器であってもよい。ユーザ端末10は、ネットワークを介して、空調制御装置20と通信可能に接続されている。なお、図1においては便宜的に1つのユーザ端末10のみが示されているが、本実施形態に係る空調システムは、空調機30が設置されている室内に入室する複数のユーザの各々によって使用される複数のユーザ端末10を備えていてもよい。
空調制御装置20は、空調機30と接続されており、空調機30の運転を制御するための情報処理装置である。空調制御装置20は、管理者が室内の空調状態を把握する、または空調機30の設定を変更する目的で導入されるBEMS(Building Energy Management System)等の機能を有していてもよい。
上記したように空調機30は室内に設置されるが、本実施形態において室内とは、例えばビル内の1つの部屋等の空間を想定しているが、施設内の一区域であって、床及び内壁等で区別された空間等であってもよい。
なお、本実施形態における空調機30としては、様々な空調機やその他の冷暖房機器を用いることができる。具体的には、空調機30は、例えばチラー(冷却水循環装置)を利用した集中管理型のものやパッケージエアコン等であってもよいし、ボイラ及び当該ボイラで生成された温水を循環させるヒータの組み合わせ等であってもよい。
ここで、空調システムを利用するユーザの中には、空調機30から吹き出される風が直接当たることを不快に感じるユーザがいる一方で、例えば外回りや体を動かす作業が多いようなユーザの場合には風が当たることを快適と感じる場合もある。すなわち、空調機30から吹き出される風に対する好みは、個人差が大きい。また、空調機30から吹き出される風に対する好みは例えばユーザの体感(暑いまたは寒い等の温冷感)とは必ずしも直結せず、例えばユーザが暑いと感じている場合であっても、冷え性等の理由により風が直接当たることを好まない場合もある。
そこで、本実施形態に係る空調システムは、上記した風に対する好みを考慮した空調機の運転を実現するための構成を有する。以下、本実施形態に係る空調システム(ユーザ端末10及び空調制御装置20)の構成について説明する。
図2は、図1に示すユーザ端末10のハードウェア構成の一例を示す。ここでは、ユーザ端末10が例えばスマートフォンである場合について説明する。
図2に示すように、ユーザ端末10は、CPU11、不揮発性メモリ12、主メモリ13、通信デバイス14及びタッチスクリーンディスプレイ15等を備える。
CPU11は、ユーザ端末10内の各コンポーネントの動作を制御するハードウェアプロセッサである。CPU11は、ストレージデバイスである不揮発性メモリ12から主メモリ13にロードされる様々なプログラムを実行する。CPU11によって実行されるプログラムには、オペレーティングシステム(OS)及びユーザが空調システムを利用するためのアプリケーションプログラム(以下、空調アプリケーションと表記)等が含まれる。
通信デバイス14は、空調制御装置20等の外部装置との通信を実行するように構成されたデバイスである。
タッチスクリーンディスプレイ15は、ユーザ端末10(例えば、スマートフォン)の本体の上面に重ね合わせるように取り付けられる。タッチスクリーンディスプレイ15には、フラットパネルディスプレイと、当該フラットパネルディスプレイの画面上の例えば指等の接触位置を検出するように構成されたセンサとが組み込まれている。フラットパネルディスプレイは、例えば液晶表示装置(LCD)等を含む。センサとしては、例えば静電容量方式のタッチパネル等を使用することができる。
このようなタッチスクリーンディスプレイ15によれば、ユーザ端末10(フラットパネルディスプレイ)に表示された画面に対するユーザの操作(例えば、画面をタッチする操作等)を検出することができる。
なお、図2においては示されていないが、ユーザ端末10は、当該ユーザ端末10(を使用するユーザ)の位置を示す位置情報を取得するためのGPSセンサ等を更に備えていてもよい。
図3は、ユーザ端末10の機能構成の一例を示す。図3に示すように、ユーザ端末10は、表示処理部101、取得部102及び送信部103を含む。
本実施形態において、これらの各部101~103の一部または全ては、CPU11に上記した空調アプリケーションを実行させること、すなわち、ソフトウェアによって実現されるものとする。なお、これらの各部101~103の一部または全ては、IC(Integrated Circuit)等のハードウェアによって実現されてもよいし、ソフトウェア及びハードウェアの組み合わせ構成として実現されてもよい。
表示処理部101は、ユーザが空調システムを利用するための所定の画面を表示する。本実施形態において、ユーザは、表示処理部101によって表示された画面に対して、空調機30が設置されている室内において当該ユーザが感じる空調状態を入力することができる。なお、本実施形態において、ユーザが感じる空調状態は、当該ユーザが暑いまたは寒い等と感じる温冷感を含む。
取得部102は、ユーザによって入力された空調状態を示す体感情報を取得する。送信部103は、取得部102によって取得された体感情報を空調制御装置20に送信する。
図4は、図1に示す空調制御装置20のハードウェア構成の一例を示す。図4に示すように、空調制御装置20は、CPU21、不揮発性メモリ22、主メモリ23及び通信デバイス24等を備える。
CPU21は、空調制御装置20内の各コンポーネントの動作を制御するハードウェアプロセッサである。CPU21は、ストレージデバイスである不揮発性メモリ22から主メモリ23にロードされる様々なプログラムを実行する。CPU21によって実行されるプログラムには、オペレーティングシステム(OS)及び空調機30の運転を制御するためのアプリケーションプログラム(以下、制御アプリケーションと表記)等が含まれる。
通信デバイス24は、ユーザ端末10等の外部装置との通信を実行するように構成されたデバイスである。
なお、図4においては、不揮発性メモリ22及び主メモリ23が示されているが、空調制御装置20は、例えばHDD(Hard Disk Drive)及びSSD(Solid State Drive)のような他の記憶装置を備えていてもよい。
図5は、空調制御装置20の機能構成の一例を示す。図5に示すように、空調制御装置20は、温度推定モデル格納部201、ログデータ取得部202、ログデータ格納部203、個人特性モデル作成部204、個人特性モデル格納部205、位置情報取得部206、制御値取得部207、制御値候補生成部208、パラメータ設定部209、制御値決定部210及び空調制御部211を含む。
本実施形態において、温度推定モデル格納部201、ログデータ格納部203及び個人特性モデル格納部205は、図4に示す不揮発性メモリ22または他の記憶装置等によって実現される。
また、本実施形態において、ログデータ取得部202、個人特性モデル作成部204、位置情報取得部206、制御値取得部207、制御値候補生成部208、パラメータ設定部209、制御値決定部210及び空調制御部211の一部または全ては、CPU21に上記した制御プログラムを実行させること、すなわち、ソフトウェアによって実現されるものとする。なお、これらの各部202、204及び206~211の一部または全ては、IC等のハードウェアによって実現されてもよいし、ソフトウェア及びハードウェアの組み合わせ構成として実現されてもよい。
温度推定モデル格納部201には、空調機30が設置されている室内におけるユーザの体感温度を推定するために用いられる温度推定モデルが格納されている。
ログデータ取得部202は、上記したようにユーザ端末10(送信部103)から送信された体感情報を受信し、当該体感情報を含むログデータを取得する。このログデータは、ユーザからの空調制御要求の履歴に相当する。なお、ログデータ取得部202によって取得されるログデータには、体感情報以外に、例えば体感情報が受信された際の空調機30の制御値及び温度推定モデル格納部201に格納されている温度推定モデルを用いて推定されたユーザの体感温度(以下、推定体感温度と表記)が含まれる。また、本実施形態において、空調機30の制御値には、空調機30に設定される温度(以下、設定温度と表記)及び当該設定温度に応じて空調機30から吹き出される風の向き(以下、設定風向きと表記)等が含まれる。
ログデータ取得部202によって取得されたログデータは、ログデータ格納部203に格納される。
個人特性モデル作成部204は、ログデータ格納部203に格納されたログデータに基づいて、ユーザが快適と感じる温度(以下、ユーザの快適温度と表記)及び空調機30から吹き出される風に対する当該ユーザの好み(以下、単にユーザの風に対する好みと表記)が定義された個人特性モデルを作成する。
個人特性モデル作成部204によって作成された個人特性モデルは、個人特性モデル格納部205に格納される。
位置情報取得部206は、ユーザ(または当該ユーザが使用するユーザ端末10)の室内における位置を示す位置情報を取得する。
制御値取得部207は、空調機30の制御値を取得する。なお、空調機30の制御値は、当該空調機30から取得されてもよいし、BEMS等の他のシステムから取得されてもよい。また、上記したように空調制御装置20がBEMSの機能を有している場合には、空調機30の制御値は、空調制御装置20内で管理されていてもよい。
制御値候補生成部208は、温度推定モデル格納部201に格納されている温度推定モデル、個人特性モデル格納部205に格納された個人特性モデル、位置情報取得部206によって取得された位置情報及び制御値取得部207によって取得された空調機30の制御値に基づいて、ユーザにとって快適度が高いと想定される空調機30の制御値の複数の候補(以下、候補制御値と表記)を生成する。なお、ユーザにとって快適度が高いと想定される空調機30の制御値とは、上記した推定体感温度が当該ユーザの快適温度と一致するまたは近くなるような空調機30の設定温度及び設定風向きをいう。
パラメータ設定部209は、個人特性モデル格納部205に格納された個人特性モデルに基づいて、ユーザの風に対する好みに関するパラメータを設定する。
制御値決定部210は、制御値候補生成部208によって生成された複数の候補制御値の中から、パラメータ設定部209によって設定されたパラメータ(つまり、ユーザの風に対する好み)に基づいて空調機30の制御値を決定する。
空調制御部211は、制御値決定部210によって決定された制御値を空調機30に送信することによって、当該空調機30の運転を制御する。
次に、図5に示す温度推定モデル格納部201に格納されている温度推定モデルについて具体的に説明する。
まず、図6は、空調機30が設置されている室内50を表している。本実施形態において、空調機30は、例えば天井カセット型で4方向に風を吹き出すための4つの吹き出し口301~304を備え、当該4つの吹き出し口301~304から吹き出される風の向きを当該吹き出し口毎に制御可能なように構成されているものとする。
図6に示す例では、平面視で略正方形状の室内50の中央付近に空調機30が配置されている。また、空調機30は、空調機30に備えられる吹き出し口301が下側を向き、吹き出し口302が左側を向き、吹き出し口303が上側を向き、吹き出し口304が右側を向くように配置されている。
なお、上記したような空調機30及び当該空調機30に備えられる吹き出し口301~304の室内50における位置は、空調制御装置20内で管理されているものとする。
ここで、上記した図6に示す室内50は、複数の室内ゾーン(領域)に分割される。なお、複数の室内ゾーンは、上記した室内50における空調機30及び吹き出し口301~304の位置に基づいて分割される。室内ゾーンの分割には、例えば室内50に対してボロノイ分割と称される手法が適用されてもよい。
図7は、図6に示す室内50に対してボロノイ分割が行われた結果を示している。ボロノイ分割によれば、吹き出し口301~304のうち最も近い吹き出し口が同じになるような点を同一の室内ゾーンとする処理を室内50に包含される全ての点に対して実行することで、当該室内50が複数の室内ゾーンに分割される。図7に示す例では、室内50は、吹き出し口301に対応する室内ゾーン501、吹き出し口302に対応する室内ゾーン502、吹き出し口303に対応する室内ゾーン503及び吹き出し口304に対応する室内ゾーン504に分割されている。なお、室内ゾーン501~504の室内50における位置(範囲)は、空調制御装置20内で管理されているものとする。
ここでは、ボロノイ分割により室内50が室内ゾーン501~504に分割される場合について説明したが、室内50は、他の手法によって分割されてもよい。また、室内ゾーンは必ずしも吹き出し口301~304の各々に対応していなくてもよく、例えば室内50がより細かな室内ゾーン(つまり、吹き出し口の数よりも多い領域)に分割されてもよい。
ここで、本実施形態における温度推定モデルとは、所定の制御値に基づいて空調機30の運転が制御される場合における、上記した室内ゾーン501~504の各々でのユーザの体感温度を推定するためのモデル式である。このような温度推定モデルによれば、空調機30の運転の制御に応じた体感温度の推定値(つまり、推定体感温度)を得ることができる。
なお、本実施形態においては、説明の便宜上、室内ゾーン501~504のうちの同一の室内ゾーン内の推定体感温度は一様(一定値)であるものとし、当該推定体感温度は空調機30の運転(つまり、制御値)によって定まるものとする。
具体的には、空調機30をA、室内ゾーンをdとすると、当該空調機30の制御値に応じた当該室内ゾーンdの温度推定モデルf(A,d)は、図8に示すように、
f(A,d)=T(A)-0.5F(d)
で表すことが考えられる。ここで、T(A)は、空調機30の設定温度(変数)である。F(d)は、室内ゾーンdに対応する吹き出し口の設定風向き(変数)である。また、本実施形態における設定風向きとして「水平」、「中」及び「下向き」が設定可能であるものとすると、当該設定風向きとして上記した温度推定モデルに与えられる値は、「水平」の場合は0、「中」の場合は1、「下向き」の場合は2とする。なお、設定風向き「水平」は、室内50の天井または床と並行の方向に風が吹き出されることを意味する。設定風向き「下向き」は、室内50の床方向(つまり、下方向)に風が吹き出されることを意味する。設定風向き「中」は、設定風向き「水平」の場合に風が吹き出される方向と、設定風向き「下向き」の場合に風が吹き出される方向との中間の方向に風が吹き出されることを意味する。
上記した温度推定モデル(式)によれば、室内ゾーンdにおける推定体感温度は、空調機30の設定温度T(A)と、当該室内ゾーンdに対応する吹き出し口の設定風向きF(d)により決定される。なお、この温度推定モデルは、空調機30が冷房運転を行う場合を想定しており、吹き出し口の風向きが下向きになるほど当該吹き出し口に対応する室内ゾーンdにおける体感温度が下がることを表現している。
ここで、上記した室内ゾーン501~504をそれぞれd1~d4とし、当該室内ゾーン501~504のうちの室内ゾーン501(d1)及び室内ゾーン503(d3)の体感温度を推定する場合を想定する。
まず、例えば空調機30の設定温度T(A)が25℃であり、室内ゾーン501に対応する吹き出し口301の設定風向きF(d1)が「水平(0)」であるものとすると、室内ゾーン501における推定体感温度は、
f(A,d1)=T(A)-0.5F(d1)=25-0.5×0=25.0(℃)
となる。
一方、空調機30の設定温度T(A)が25℃であり、吹き出し口303の設定風向きF(d3)が「下向き(2)」であるものとすると、室内ゾーン503における推定体感温度は、
f(A,d3)=T(A)-0.5F(d3)=25-0.5×2=24.0(℃)
となる。ここでは、室内ゾーン501及び室内ゾーン503における推定体感温度について説明したが、他の室内ゾーンについても同様である。
なお、上記した温度推定モデルは、一例であり、適宜変更されても構わない。具体的には、例えば空調機30の「効き」が悪い場合、温度推定モデルは、
f(A,d)=T(A)-0.5F(d)+1.0
のように表すことも可能である。このように定数項を加えることで、空調機30の「効き」を温度推定モデルにおいて調節することができる。
ここでは空調機30が冷房運転を行う場合について説明したが、当該空調機30が暖房運転を行う場合、温度推定モデルf(A,d)は、
f(A,d)=T(A)+0.5F(d)
で表すことが考えられる。この温度推定モデルは、吹き出し口の風向きが下向きになるほど当該吹き出し口に対応する室内ゾーンdにおける体感温度が上がることを表現している。
なお、室内ゾーン501~504における体感温度は、外気温や日照、室内のレイアウト、在室者の有無、居室の発熱機器の状況等により異なると考えられる。更に、それぞれの室内ゾーン501~504内においても実際には温度勾配があり、温度が一様ではないと考えられる。このため、これらを考慮したパラメータを追加したより複雑な温度推定モデルを用いて室内ゾーン501~504の各々における体感温度を推定するようにしてもよい。更に、室内50の環境に応じて、例えば室内ゾーン501~504毎に異なる温度推定モデルを用いるような構成とすることも可能である。
本実施形態において用いられる温度推定モデルは、例えば空調機30の制御値(設定温度及び設定風向き)毎に室内50(室内ゾーン501~504)の実際の温度を計測すること等によって予め作成(用意)されて温度推定モデル格納部201に格納されているものとする。
次に、本実施形態に係る空調制御装置20の動作について説明する。本実施形態において、空調制御装置20は、空調機30設置されている室内にいるユーザからログデータを収集する処理(以下、ログデータ収集処理と表記)、当該ログデータに基づいて個人特性モデルを作成する処理(以下、個人特性モデル作成処理と表記)及び当該個人特性モデルを用いて空調機30の制御値を決定する処理(以下、制御値決定処理と表記)を実行する。以下、これらの処理について説明する。
まず、図9のフローチャートを参照して、ログデータ収集処理の処理手順について説明する。
ログデータ収集処理において、空調機30が設置されている室内50にいるユーザ(以下、対象ユーザと表記)は、ユーザ端末10を操作することによって、当該ユーザ端末10上で上記した空調アプリケーションを起動する。
ユーザ端末10上で空調アプリケーションが起動された場合、ユーザ端末10に含まれる表示処理部101は、対象ユーザが感じる空調状態を入力するための画面(以下、空調状態入力画面と表記)を表示する。対象ユーザは、表示処理部101によって表示された空調状態入力画面において、対象ユーザが感じる空調状態を入力することができる。
ここで、図10を参照して、空調状態入力画面において対象ユーザが入力(選択)することができる空調状態の一例について説明する。
ここでは、空調状態入力画面に図10に示す複数のアイコン601~605が表示され、対象ユーザは、当該複数のアイコン601~605の中から1つのアイコンを選択することによって、当該対象ユーザが感じる空調状態を入力することができるものとする。
なお、アイコン601は、対象ユーザが「寒すぎる」と感じる空調状態を表している。アイコン602は、対象ユーザが「寒い(やや寒い)」と感じる空調状態を表している。アイコン603は、対象ユーザが「快適」と感じる空調状態を表している。アイコン604は、対象ユーザが「暑い(やや暑い)」と感じる空調状態を表している。アイコン605は、対象ユーザが「暑すぎる」と感じる空調状態を表している。このようなアイコン601~605によれば、対象ユーザは、当該対象ユーザが感じる空調状態を直感的に入力することができる。
例えば対象ユーザが空調状態入力画面上でアイコン602を選択した場合、ユーザ端末10に含まれる取得部102は、ユーザが「寒い」と感じる空調状態を示す体感情報を取得する。なお、アイコン602以外のアイコンが選択された場合についても同様である。取得部102によって取得された体感情報は、例えば対象ユーザを識別するための識別情報(以下、ユーザID)とともに送信部103によって空調制御装置20に送信される。
なお、図10においては複数のアイコン601~605を用いて対象ユーザが感じる空調状態が入力されるものとして説明したが、本実施形態においては、対象ユーザが感じる空調状態がユーザ端末10において入力されればよく、当該対象ユーザが感じる空調状態は他の手法により入力されてもよい。
また、対象ユーザが感じる空調状態には、空調機30から吹き出される風または室内50の湿気等の当該対象ユーザが感じる他の状態が更に含まれていてもよい。
上記したようにユーザ端末10(送信部103)から送信された体感情報(及びユーザID)は、空調制御装置20に含まれるログデータ取得部202によって取得(受信)される(ステップS1)。
ステップS1の処理が実行されると、ログデータ取得部202は、現在の空調機30の制御値(つまり、体感情報が取得された時点での空調機30の制御値)を取得する(ステップS2)。ステップS2において取得される空調機30の制御値としては主に運転モード(冷房運転または暖房運転等)、設定温度及び設定風向きを想定しているが、当該空調機30の制御値には、例えば吹き出し口301~304から吹き出される風の量(設定風量)等が含まれていてもよい。また、空調機30の制御値は、空調機30から取得されてもよいし、空調機30を操作するためのリモコンから取得されてもよい。また、空調機30の制御値は、BEMS等の他のシステムから取得されてもよい。
次に、ログデータ取得部202は、ステップS2において取得された空調機30の制御値及び上記した温度推定モデル格納部201に格納されている温度推定モデルに基づいて、対象ユーザの推定体感温度を算出する(ステップS3)。
この場合、ログデータ取得部202は、室内50における対象ユーザの位置(を示す位置情報)を取得する。対象ユーザの位置は、上記したようにユーザ端末10としてスマートフォンを使用している場合には、当該スマートフォンが有するGPS機能を利用して取得されてもよいし、室内50に配置された端末から受信されるビーコン信号に基づいて取得されてもよい。更に、赤外線センサ(人感センサ)を用いて対象ユーザの位置を取得する構成としてもよい。なお、対象ユーザの位置は、他のセンサ等を用いて取得してもよい。
一方、例えば室内50がオフィス等であり、デスクの配置等によって対象ユーザの位置が固定されているような場合には、当該固定された位置を対象ユーザの位置として取得するようにしてもよい。なお、対象ユーザの位置が固定されている場合には、対象ユーザを識別するためのユーザIDに対応づけられた当該対象ユーザの位置を空調制御装置20が予め保持していればよい。
更に、例えば室内50を表すマップをユーザ端末10に表示し、当該マップ上で対象ユーザの位置を当該対象ユーザに指定させることによって、当該対象ユーザの位置を取得するようにしてもよい。
ステップS3においては、上記したように取得された対象ユーザの位置に基づいて当該対象ユーザが属する室内ゾーンを特定し、ステップS2において取得された空調機30の制御値(設定温度及び当該室内ゾーンに対応する吹き出し口の設定風向き)を上記した温度推定モデルに適用することによって、対象ユーザの推定体感温度が算出される。
ステップS3の処理が実行されると、ログデータ取得部202は、ステップS1において取得された体感情報、ステップS2において取得された空調機30の制御値及びステップS3において算出された対象ユーザの推定体感温度を含むログデータを取得(生成)する(ステップS4)。
ステップS4において生成されたログデータ(対象ユーザのログデータ)は、上記した対象ユーザを識別するためのユーザID等に対応づけて、ログデータ格納部203に格納される(ステップS5)。
なお、図9に示すログデータ収集処理は、室内50にいる対象ユーザによって当該対象ユーザが感じる空調状態が入力される度に実行される。すなわち、ログデータ格納部203には、1人のユーザに対して複数のログデータが蓄積される。また、空調システムを複数のユーザが利用する場合には、当該複数のユーザの各々のログデータが蓄積される。
ここで、図11は、ログデータ格納部203に格納されたログデータのデータ構造の一例を示す。なお、図11に示すログデータは、空調機30が冷房運転を行っている際に取得された特定のユーザ(例えば、ユーザA)のログデータの一例である。
図11に示すように、ログデータは、日時に対応づけて、体感情報、設定温度、設定風向き及び推定体感温度を含む。
日時は、例えばステップS4においてログデータが取得された日時であるが、ステップS1において体感情報がユーザ端末10から取得された日時等であってもよい。
また、ログデータにおいて、体感情報は、-2~+2の数値によってユーザが感じる空調状態を示すものとする。具体的には、体感情報「-2」は、ユーザが「寒すぎる」と感じる空調状態を示す。体感情報「-1」は、ユーザが「寒い」と感じる空調状態を示す。体感情報「0」は、ユーザが「快適」と感じる空調状態を示す。体感情報「+1」は、ユーザが「暑い」と感じる空調状態を示す。体感情報「+2」は、ユーザが「暑すぎる」と感じる空調状態を示す。
なお、設定温度、設定風向き及び推定体感温度については上記した通りであるため、ここではその詳しい説明を省略する。
図11に示す例では、ログデータ格納部203には、ログデータ203a及び203bが格納されている。
ログデータ203aは、日時「2019/8/2 13:30」に対応づけて、体感情報「0」、設定温度「25(℃)」、設定風向き「水平」及び推定体感温度「25(℃)」を含む。このログデータ203aによれば、当該ログデータ203aが2019年8月2日の13時30分に取得され、この時点でユーザが「快適」と感じていることが示されている。また、ログデータ203aによれば、2019年8月2日の13時30分の時点で、空調機30の運転が設定温度「25℃」及び設定風向き「水平」(を含む制御値)に基づいて制御されており、その際のユーザの推定体感温度が25℃であることを示している。
ログデータ203bは、日時「2019/8/5 16:30」に対応づけて、体感情報「-1」、設定温度「26(℃)」、設定風向き「下向き」及び推定体感温度「25(℃)」を含む。このログデータ203aによれば、当該ログデータ203aが2019年8月5日の16時30分に取得され、この時点でユーザが「寒い」と感じていることが示されている。また、ログデータ203aによれば、2019年8月5日の16時30分の時点で、空調機30の運転が設定温度「26℃」及び設定風向き「下向き」(を含む制御値)に基づいて制御されており、その際のユーザの推定体感温度が25℃であることを示している。
ここでは、ログデータ203a及び203bについてのみ説明したが、ログデータ格納部203に格納される他のログデータについても同様である。なお、図11に示すログデータ203a及び203bは、上記したように例えばユーザAのログデータであり、当該ユーザAを識別するためのユーザID(図示せず)に対応づけられているものとする。上記したように複数のユーザが空調システムを利用する場合には、ログデータ格納部203には、当該ユーザ毎のログデータが格納されている。
次に、図12のフローチャートを参照して、個人特性モデル作成処理の処理手順について説明する。ここでは、上記した図9に示すログデータ収集処理が繰り返し実行されることによって、ログデータ格納部203にはログデータが既に蓄積されているものとする。
なお、個人特性モデル作成処理においては空調システムを利用するユーザ毎に個人特性モデルを作成するが、以下の説明では、当該個人特性モデルの作成の対象となるユーザを便宜的に対象ユーザと称する。
まず、個人特性モデル作成部204は、対象ユーザを識別するためのユーザIDに対応づけてログデータ格納部203に格納されているログデータ(つまり、対象ユーザのログデータ)を、当該ログデータ格納部203から取得する(ステップS11)。
次に、個人特性モデル作成部204は、ステップS11において取得された対象ユーザのログデータに基づいて、対象ユーザの快適温度を決定する(ステップS12)。
ステップS12においては、例えば対象ユーザのログデータの中から体感情報「0(快適)」を含むログデータを抽出し、当該抽出されたログデータに含まれる推定体感温度を対象ユーザの快適温度として決定するものとする。なお、体感情報「0(快適)」を含む複数のログデータが抽出された場合には、当該複数のログデータに含まれる推定体感温度に関する代表値(例えば、平均値または最頻値等)を対象ユーザの快適温度として決定してもよい。ここで説明した対象ユーザの快適温度を決定する処理は一例であり、当該対象ユーザの快適温度は、他の処理によって決定されてもよい。また、対象ユーザの快適温度は、例えば24℃~26℃のように一定の幅を有していてもよい。
また、個人特性モデル作成部204は、ステップS11において取得された対象ユーザのログデータに基づいて、対象ユーザの風に対する好みを決定する(ステップS13)。
ここで、対象ユーザの風に対する好みには、例えば「風が嫌い」、「風が嫌いでもなく好きでもない」及び「風が好き」等が含まれるものとする。この場合、ステップS13においては、対象ユーザのログデータの中から設定風向き「下向き」を含むログデータを抽出し、当該抽出されたログデータのうち体感情報が「0(快適)」でないログデータの割合が第1閾値以上である場合に、対象ユーザの風に対する好みとして「風が嫌い」を決定する。また、体感情報が「0」でないログデータの割合が第1閾値未満であり、かつ、第2閾値以上である場合には、対象ユーザの風に対する好みとして「風が嫌いでもなく好きでもない」を決定する。更に、体感情報が「0」でないログデータの割合が第2閾値未満である場合には、対象ユーザの風に対する好みとして「風が好き」を決定する。なお、第2閾値は、第1閾値よりも小さい値であるものとする。
ここで説明した対象ユーザの風に対する好みを決定する処理は一例であり、当該対象ユーザの風に対する好みは、他の処理によって決定されてもよい。具体的には、対象ユーザの風に対する好みは、例えば設定風向き「下向き」を含むログデータのうち体感情報が「0」であるログデータの割合に基づいて決定されてもよい。更に、対象ユーザの風に対する好みは、体感情報が「0」以外であり、かつ、設定風向きが「下向き」であるログデータの数、または体感情報が「0」であり、かつ、設定風向きが「下向き」であるログデータの数等に基づいて決定されてもよい。また、対象ユーザの風に対する好みは、例えば数値レベルまたは度数(%)で表されるものであってもよい。
次に、個人特性モデル作成部204は、ステップS12において決定された対象ユーザの快適温度及びステップS13において決定された対象ユーザの風に対する好みが定義された個人特性モデルを作成する(ステップS14)。
ここで、上記したステップS11~S14の処理を図11に示すログデータを用いて具体的に説明する。ステップS11において対象ユーザのログデータとして図11に示すログデータ203a及び203bが取得されたものとすると、ログデータ203aによれば対象ユーザが快適と感じている際の推定体感温度は25℃であるため、ステップS12においては対象ユーザの快適温度として25℃が決定される。
一方、ログデータ203bによれば、推定体感温度はログデータ203aと同じであるにもかかわらず、対象ユーザは、設定温度を26℃、設定風向きを下向きとした制御値に基づく空調機30の運転で「寒い」と感じている。この場合、「対象ユーザは風に当たると寒く感じやすい」ことが推定されるため、ステップS13においては対象ユーザの風に対する好みとして「風が嫌い」が決定される。
これによれば、対象ユーザに対しては風をなるべく当てずに推定体感温度が25℃となるような空調機30の制御値に基づいて空調機30の運転を制御することが適切であり、ステップS14においては、快適温度「25℃」及び風に対する好み「風が嫌い」が定義された個人特性モデルが作成されることになる。
再び図12に戻ると、ステップS14において作成された個人特性モデルは、対象ユーザを識別するためのユーザIDに対応づけて、個人特性モデル格納部205に格納される(ステップS15)。
ステップS15の処理が実行されると、空調システムを利用する全てのユーザに対してステップS11~S15の処理が実行されたか否かが判定される(ステップS16)。
全てのユーザに対して処理が実行されていないと判定された場合(ステップS16のNO)、ステップS11に戻って処理が繰り返される。この場合、個人特性モデルが作成されていないユーザを対象ユーザとしてステップS11以降の処理が実行される。
一方、全てのユーザに対して処理が実行されたと判定された場合(ステップS16のYES)、個人特性モデル作成処理は終了される。
このような個人特性モデル作成処理によれば、各ユーザのログデータに基づいて当該ユーザ毎の個人特性モデルを作成することができる。個人特性モデルの作成は、例えば1週間に1度など定期的に定めても良いし、空調システムの管理者によって任意のタイミングで行われてもよい。
なお、図12においては全てのユーザの個人特性モデルが作成されるものとして説明したが、当該個人特性モデルを作成するために必要なログデータは上記したログデータ収集処理が実行されることによってログデータ格納部203に蓄積される。このため、ユーザの空調システムの利用頻度や当該ユーザが感じる空調状態の入力頻度によっては、個人特性モデル作成処理が実行される時点で十分なログデータが蓄積されていない場合がある。この場合、個人特性モデル作成処理は、十分な数のログデータが蓄積されているユーザのみを対象に実行されてもよいし、空調システムの管理者によって指定されたユーザのみを対象に実行されてもよい。
また、上記したように十分な数のログデータが蓄積されていないユーザに対しては、予め用意された複数の個人特性モデルのテンプレートの中から当該ユーザに適したテンプレートを選定する構成としてもよい。
ここで、図13は、個人特性モデルのテンプレートの一例を示す。図13に示す例においては、空調機30が冷房運転を行う場合を想定しており、ユーザが暑さに敏感である(つまり、暑がりである)場合に選定されるテンプレート701、ユーザが暑さ及び寒さに敏感でない(つまり、普通である)場合に選定されるテンプレート702、ユーザが寒さに敏感である(つまり、寒がりである)場合に選定されるテンプレート703が予め用意されている。テンプレート701~703においては、それぞれ異なる快適温度及び風の好みが定義されている。
なお、ユーザに適したテンプレートは、当該ユーザに関するユーザ情報に基づいて選定されればよい。ユーザ情報については、例えば図14に示すような画面(以下、ユーザ情報入力画面と表記)をユーザ端末10に表示し、当該ユーザ情報入力画面に対してユーザに必要事項を入力させることによって取得することができる。なお、図14は、ユーザID「0001」によって識別されるユーザが使用するユーザ端末10に表示されるユーザ情報入力画面の一例を示している。
図14に示す例では、ユーザは、ユーザ情報入力画面において「暑がり」、「普通」及び「寒がり」のうちの1つを選択することができる。このため、例えばユーザが「暑がり」を選択した場合にはテンプレート701、ユーザが「普通」を選択した場合にはテンプレート702、ユーザが「寒がり」を選択した場合にはテンプレート703を選定することができる。
更に、ユーザ情報入力画面においては、図14に示すように「風に当たりたくない」のような風に対する好みを入力させるようにしてもよい。これによれば、上記したようにユーザが「暑がり」を選択した場合にはテンプレート701が選定されるが、ユーザが更に「風に当たりたくない(True)」を入力した場合には、テンプレート701の「風が好き」を「風が嫌い」に変更した個人特性モデルを作成することができる。なお、冷房運転と暖房運転とを区別して、「冷風に当たりたくない」及び「温風に当たりたくない」のような風に対する好みを入力させるようにしてもよい。
また、図14には示されていないが、ユーザの快適温度を直接入力させることによって、当該快適温度が定義された個人特性モデルを作成するようにしてもよい。
なお、ユーザ情報入力画面において例えばユーザの性別、年齢、身長及び体重等をユーザ情報として入力させるようにしてもよい。この場合には、性別、年齢、身長及び体重からユーザが「暑がり」、「普通」及び「寒がり」のいずれに該当するかを推定し、当該推定された結果に基づいてテンプレートを選択するようにしてもよい。更に、全てのユーザからユーザ情報(性別、年齢、身長及び体重等)を取得している場合には、当該ユーザ情報に基づいて、特定のユーザと身体的特徴が類似する他のユーザを特定することができる。この場合には、例えばログデータの数が十分でないユーザの個人特性モデル(ログデータ)として、当該ユーザと身体的特徴が類似する他のユーザの個人特性モデル(ログデータ)を利用することも可能である。
次に、図15のフローチャートを参照して、制御値決定処理の処理手順について説明する。ここでは、上記した図12に示す個人特性モデル作成処理が実行されることによって、個人特性モデル格納部205にはユーザ毎の個人特性モデルが既に格納されているものとする。また、制御値決定処理は、個人特性モデル作成処理が実行された(つまり、各ユーザの個人特性モデルが個人特性モデル格納部205に格納された)後に定期的に実行される。
まず、位置情報取得部206は、空調機30が設置されている室内50にいるユーザ(以下、対象ユーザと表記)の位置を示す位置情報を取得する(ステップS21)。なお、対象ユーザの位置を示す位置情報については上記した図9に示すステップS3において説明した通りであるため、ここではその詳しい説明を省略する。
ここで、ステップS21の処理を実行するためには、対象ユーザが室内50にいることを判別(検出)する必要があるが、当該対象ユーザが室内50にいるか否かは、当該対象ユーザがユーザ端末10を操作することによって設定(登録)されるようにしてもよい。このような設定が行われた際に対象ユーザを識別するためのユーザIDがユーザ端末10から空調制御装置20に送信されることによって、空調制御装置20は、当該ユーザIDに基づいて対象ユーザが室内50にいることを判別することができる。また、上記したようにGPS機能、ビーコン信号及び赤外線センサ等を用いて対象ユーザの位置を示す位置情報を取得する構成である場合には、当該位置情報によって示される対象ユーザの位置に基づいて当該対象ユーザが室内50にいることを判別する構成としてもよい。
ステップS21の処理が実行されると、制御値取得部207は、現在の空調機30の制御値を取得する(ステップS22)。なお、ステップS22の処理は、上記した図9に示すステップS2の処理と同様である。この場合、ステップS22において取得される空調機30の制御値には運転モード、設定温度及び設定風向きが含まれるが、以下においては、当該運転モードが冷房運転(モード)であるものとして説明する。
ステップS22の処理が実行されると、制御値候補生成部208は、対象ユーザを識別するためのユーザIDに対応づけて個人特性モデル格納部205に格納されている個人特性モデル(つまり、対象ユーザの個人特性モデル)を取得する(ステップS23)。
次に、制御値候補生成部208は、ステップS21において取得された位置情報、ステップS22において取得された空調機30の制御値及びステップS23において取得された対象ユーザの個人特性モデルに基づいて、対象ユーザに適した複数の候補制御値を生成する(ステップS23)。
なお、ステップS23において生成される候補制御値とは、対象ユーザの個人特性モデルに定義されている当該対象ユーザの快適温度と温度推定モデル格納部201に格納されている温度推定モデルを用いて算出される当該対象ユーザの推定体感温度(当該対象ユーザが属する室内ゾーンにおける推定体感温度)との差分が小さくなる空調機30の制御値をいう。
ここで、対象ユーザの個人特性モデルに定義されている当該対象ユーザの快適温度が24℃であり、室内50が分割された室内ゾーン501に属する位置に対象ユーザがいる場合を想定する。この場合、上記した冷房運転時に適用される温度推定モデル「f(A,d)=T(A)-0.5F(d)」を用いると、制御値候補生成部208は、設定温度「24℃」及び吹き出し口301の設定風向き「水平」を含む候補制御値と、設定温度「25℃」及び吹き出し口301の設定風向き「下向き」を含む候補制御値と、設定温度「24.5℃」及び吹き出し口301の設定風向き「中」を含む候補制御値との3つの候補制御値が生成される。このような3つの候補制御値であれば、室内ゾーン501における対象ユーザの推定体感温度を24℃(ユーザの快適温度)にすることができる。なお、本実施形態において説明した温度推定モデルによれば、吹き出し口301以外(つまり、対象ユーザがいる室内ゾーン501に対応しない吹き出し口302~304)の設定風向きは、対象ユーザの推定体感温度に影響を与えないため、例えば「水平」等のデフォルト値で構わない。
ここでは、説明の便宜上、室内50に対象ユーザのみがいる場合について説明したが、室内50に複数の対象ユーザがいる場合には、各対象ユーザにおける快適温度と推定体感温度との差分の和が小さくなるような空調機30の制御値(設定温度及び設定風向き)が候補制御値として生成される。なお、対象ユーザが複数の場合には、上記したステップS21及びS23の処理は、当該対象ユーザ毎に実行される。
具体的には、候補制御値として生成される設定温度T
*及び設定風向きF
*は、以下の式(1)を用いて得ることができる。なお、式(1)は、室内50にいる対象ユーザが1人であっても複数であっても適用可能である。
ここで、上記した式(1)において、Kは、室内50にいる対象ユーザ(在室者)k(=1、2、…、K)の集合を示す。S*kは、対象ユーザkの快適温度である。
また、Tは空調機30の設定温度を表し、Fは空調機30に備えられている4つの吹き出し口301~304の各々から吹き出される風の向き(吹き出し口301~304の設定風向き)を表す。すなわち、式(1)において、fk(T,F)は、設定温度T及び設定風向きF(を含む制御値)に基づいて空調機30の運転を制御した場合の対象ユーザの体感温度(対象ユーザkが属する室内ゾーンの温度)を推定するための温度推定モデルに相当する。
更に、△は、設定温度T及び設定風向きFの現在の空調機30の制御値からの変化量を示す。これによれば、式(1)において、現在の空調機30の制御値から激変するような候補制御値(設定温度T*及び設定風向きF*)が得られないようにすることができる。
上記した式(1)によれば、対象ユーザkの快適温度と当該対象ユーザkの推定体感温度との二乗誤差の和に、設定温度T及び設定風向きFの現在の空調機30の制御値からの変化量の二乗値を加算した値が最も0に近くなる、1組あるいは複数組の設定温度Tと設定風向きFを得ることができる。これらの組を含む、当該値が小さい順に予め定められた数の設定温度T及び設定風向きFの組を得ることで、ステップS24において複数の候補制御値を生成することができる。
本実施形態においては、式(1)を用いて複数の候補制御値を生成するものとして説明したが、当該式(1)は一例であり、当該式(1)において例えばエネルギーの効率的な使用(省エネ)を実現するような重み付けをして複数の候補制御値を生成するようにしてもよいし、他の誤差評価式を用いてもよい。すなわち、本実施形態においては、複数の候補制御値を生成可能であれば、ここで説明した以外の手法を用いても構わない。
次に、パラメータ設定部209は、ステップS23において取得された対象ユーザの個人特性モデルに定義されている当該対象ユーザの風に対する好みに基づいて、室内50が分割された室内ゾーン501~504の各々に対してパラメータ(風の制御戦略パラメータ)を設定する(ステップS25)。
ステップS25において設定されるパラメータは室内ゾーン501~504の各々に対して風を当てる程度を表す値であり、例えば風に対する好みが「風が好き」である対象ユーザが多く属している室内ゾーンには高いパラメータ(値)が設定され、風に対する好みが「風が嫌い」である対象ユーザが多く属する室内ゾーンには低いパラメータ(値)が設定される。
具体的には、例えば風に対する好みが「風が好き」である対象ユーザにはパラメータ値として100を割り当て、風に対する好みが「風が嫌いでもなく好きでもない」である対象ユーザにはパラメータ値として50を割り当て、風に対する好みが「風が嫌い」である対象ユーザにはパラメータ値として0を割り当てる。この場合、パラメータ設定部209は、各室内ゾーンに属する対象ユーザに割り当てられたパラメータ値の平均値を算出し、当該平均値を当該室内ゾーンのパラメータとして設定することができる。なお、例えば室内ゾーン毎に対象ユーザの風に対する好みが反映されたパラメータが設定されるのであれば、当該パラメータを設定する処理として、ここで説明した以外の処理が実行されてもよい。
ステップS25の処理が実行されると、制御値決定部210は、ステップS25において室内ゾーン501~504に対して設定されたパラメータに基づいて、ステップS24において生成された複数の候補制御値の中から空調機30の制御値を決定(選択)する(ステップS26)。
ステップS26においては、室内ゾーン501~504に対して設定されたパラメータ(つまり、対象ユーザの風に対する好み)に応じた当該室内ゾーン501~504に対応する吹き出し口301~304の設定風向きを含む候補制御値が空調機30の制御値として決定される。
ステップS26の処理が実行されると、当該ステップS26において決定された空調機30の制御値(設定温度及び設定風向き)が空調制御部211から空調機30に送信されることによって、当該空調機30の運転が当該制御値に基づいて制御される(ステップS27)。
上記した制御値決定処理によれば、個人特性モデルに定義されている対象ユーザの快適温度及び風に対する好みに適した制御値に応じて空調機30の運転を制御することが可能となる。
以下、図16を参照して、上記した制御値決定処理の具体例を簡単に説明する。ここでは、例えば快適温度が25℃であるユーザAが室内50に一人でいる場合について説明する。
この場合、制御値候補生成部208は、ユーザAの推定体感温度が25℃となるような複数の候補制御値を生成する。具体的には、図16の左側に示すように、制御値候補生成部208は、設定温度「26℃」及びユーザAが属する室内ゾーンに対応する吹き出し口の設定風向き「下向き」を含む第1候補制御値と、設定温度「25℃」及び当該吹き出し口の設定風向き「水平」を含む第2候補制御値とを生成する。
一方、図16の右側に示すようなユーザAのログデータが取得されているものとすると、当該ユーザAの風に対する好みが「風が嫌い」であると決定(推定)され、当該ユーザAが属する室内ゾーンに対してパラメータ「0」が設定される。
これによれば、制御値決定部210は、上記した第1及び第2候補制御値のうち、ユーザAの風に対する好み(パラメータ「0」)に合致する第2候補制御値(つまり、ユーザAが属する室内ゾーンに風を当てない制御値)を空調機30の制御値として決定する。
ここでは室内50にユーザAのみがいる場合について説明したが、当該室内50に複数のユーザがいる場合であっても同様である。
以下、図17を参照して、室内50にユーザA~Cがいる場合の制御値決定処理の具体例について説明する。ここでは、図17の左側に示すように、ユーザAが室内ゾーン501に属しており、ユーザBが室内ゾーン503に属しており、ユーザCが室内ゾーン504に属しているものとする。
また、図17において、各ユーザA~Cの近傍に表記されている数値は、当該ユーザA~Cの快適温度を示している。また、図17において、室内ゾーン501~504の近傍に外枠付きで表記されている数値は、当該室内ゾーン501~504の各々における推定体感温度を示している。
なお、図17に示す例では、初期状態として、設定温度「25℃」、吹き出し口301の設定風向き「水平」、吹き出し口302の設定風向き「水平」、吹き出し口303の設定風向き「水平」及び吹き出し口304の設定風向き「水平」を含む制御値に基づいて空調機30の運転(ここでは、冷房運転)が制御されているものとする。この場合、図17に示すユーザA~Cの快適温度と推定体感温度との差によれば、ユーザAは「暑い」と感じており、ユーザBは「暑すぎる」と感じており、ユーザCは「快適」と感じており、空調機30の制御値を変更する必要がある。
ここで、制御値候補生成部208は、図17の右側に示すような第1及び第2候補制御値を生成する。具体的には、第1候補制御値は、設定温度「25℃」、吹き出し口301の設定風向き「下向き」、吹き出し口302の設定風向き「任意」、吹き出し口303の設定風向き「下向き」及び吹き出し口304の設定風向き「水平」を含む。
また、第2候補制御値は、設定温度「24℃」、吹き出し口301の設定風向き「水平」、吹き出し口302の設定風向き「任意」、吹き出し口303の設定風向き「下向き」及び吹き出し口304の設定風向き「水平」を含む。
上記した第1及び第2候補制御値によれば、初期状態と比較して、ユーザA~Cの快適温度と推定体感温度との差を低減し、ユーザA~Cの全体としての快適度を向上させることができる。
なお、吹き出し口302に対応する室内ゾーン502にはユーザがいないため、第1及び第2候補制御値において、当該吹き出し口302の設定風向きは任意の値(風向き)に設定可能である。
ここで、第1候補制御値に基づいて空調機30の運転を制御した場合のユーザAの推定体感温度は、当該ユーザAの快適温度と一致している。同様に、第2候補制御値に基づいて空調機30の運転を制御した場合のユーザAの推定体感温度は、当該ユーザAの快適温度と一致している。
しかしながら、例えばユーザAの風に対する好みが「風が嫌い」である場合において、第1候補制御値を採用した場合、ユーザAが属する室内ゾーン501に対応する吹き出し口301からは下向きに風が吹き出されるため、風がユーザAに当たり、当該ユーザAは、不快と感じる可能性が高い。
このような場合には、制御値決定部210は、吹き出し口301から水平に吹き出されるように、第2候補制御値を空調機30の制御値として決定する。これによれば、吹き出し口301からの風がユーザAに当たることがないため、ユーザAの快適度を向上させることができる。
一方、ユーザAの風に対する好みが「風が好き」である場合には、吹き出し口301からの風がユーザAに当たるように、第1候補制御値を空調機30の制御値として決定すればよい。
なお、室内50に複数のユーザがいる場合において、当該複数のユーザの各々の風に対する好みに合致する候補制御値がない場合が想定され得る。このような場合には、例えば室内ゾーン501~504の中にパラメータ「0」が設定されている室内ゾーンがあれば、当該室内ゾーンに対応する吹き出し口の設定風向きが水平となる候補制御値を優先的に選択するようにすることができる。また、パラメータが「0」である室内ゾーンが複数存在する場合には、室内ゾーン501~504の各々に対して優先度を予め設定しておくことにより、当該優先度の高い室内ゾーンに対応する吹き出し口の設定風向きが水平となる候補制御値を選択するようにしてもよい。
また、制御値決定部210は、上記した式(1)を用いて得ることができる複数の候補制御値(設定温度T
*及び設定風向きF
*の複数の組)の中から、以下の式(2)を用いて空調機30の制御値を決定するようにしてもよい。
なお、上記した式(2)において、Wa,bは、空調機aの室内ゾーンbにおける風向きに関する重み(つまり、パラメータ)を示す。また、式(2)において、Fa,bは、空調機aの室内ゾーンbに対応する吹き出し口の設定風向きを示す。本実施形態においては、このような式(2)を用いることによって、室内50にいる各ユーザの風の好み(パラメータ)に最も合致した1つの制御値を決定(選択)することができる。
上記したように本実施形態においては、ユーザが感じる空調状態を示す体感情報をユーザ端末10から取得し、当該取得された体感情報に基づいて空調機30の制御値を決定する構成により、体感情報から推定されるユーザの好み(ユーザの快適温度及び風に対する好み等)に応じた空調機30の運転(つまり、ユーザの快適度を向上させる空調機30の運転)を実現することができる。
ここで、本実施形態において、空調機30は複数の方向に風を吹き出すための複数の吹き出し口301~304を備えており、空調機30の制御値には当該吹き出し口301~304の各々の風の向き(つまり、設定風向き)が含まれる。この場合、上記した体感情報及びユーザの室内50における位置に基づいて空調機30の制御値を決定する。
具体的には、本実施形態においては、室内50にいるユーザの体感情報、当該体感情報が取得された際の空調機の制御値(設定温度及び設定風向き)及び当該ユーザの推定体感温度を含むログデータを取得し、当該ログデータに基づいてユーザの快適温度及びユーザの風に対する好みが定義された個人特性モデルを作成する。また、本実施形態においては、ユーザの室内50における位置及び個人特性モデルに定義されている快適温度に基づいて複数の候補制御値を生成し、当該複数の候補制御値の中から、個人特性モデルに定義されているユーザの風の好みに基づいて空調機30の制御値を決定する。
本実施形態においては、このような構成により、ユーザのいる位置に影響を与える制御値(当該ユーザが属する室内ゾーンに対応する吹き出し口の設定風向き)をユーザの風に対する好みに基づいて決定することができる。これによれば、室内50にいるユーザが空調機30の制御値の変更等を指示することなく、当該ユーザが室内50にいるだけで、ユーザのログデータから推定された風に対する好みを反映した空調機30の運転を実現することができる。
また、一般にオフィスビル等においては、同一の室内50(同一空調機空間)に複数のユーザがいる場合が多く、当該複数のユーザが快適と感じる制御値をリモコン等で設定することは困難である。
これに対して、本実施形態においては、ユーザ毎に個人のログデータを収集しておくことにより、室内50に複数のユーザがいる場合であっても当該ユーザ毎の好みを総合的に勘案して空調機30の制御値を決定(選択)することが可能であるため、室内50にいるユーザ全体の快適度を確保することができる。
なお、本実施形態においては、ユーザ端末10を介して取得(収集)されたログデータに基づいて作成される個人特性モデルを用いて空調機30の制御値を決定するものとして説明したが、十分な数のログデータが取得されていない場合には、ユーザに関するユーザ情報に基づいて、予め用意されている複数のテンプレート(個人特性モデルのテンプレート)の中から当該ユーザに適した個人特性モデルを選定する。このような構成によれば、ログデータが取得されていないユーザであっても、適切な個人特性モデルを用いて当該ユーザの快適度を向上させる空調機30の制御値を決定することが可能なる。
ここで、本実施形態においては、ログデータ収集処理及び個人特性モデル作成処理が実行された後に制御値決定処理が定期的に実行されるものとして説明したが、例えばユーザ端末10において体感情報が取得される(ユーザが感じる空調情報がユーザ端末10に入力される)度にログデータ収集処理及び個人特性モデル作成処理を繰り返し実行することにより、一旦個人特性モデルが作成された後に再度取得されたログデータに基づいて当該個人特性モデルを更新する構成としてもよい。なお、個人特性モデルを更新することは、当該個人特性モデルに定義されている快適温度及び風に対する好みのうちの少なくとも一方を補正する概念を含んでいてもよい。
以下、図18を参照して、個人特性モデルの更新について具体的に説明する。ここでは、ユーザBの個人特性モデルが更新されるものとして説明する。
図18に示すように、例えば2019年8月3日の時点でユーザBのログデータ203c及び203dがログデータ格納部203に格納(蓄積)されていたものとすると、当該ログデータ203c及び203dからは、例えば快適温度が25.5℃よりも高いことが定義された第1個人特性モデルが作成される。
一方、2019年8月5日にログデータ203eが更にログデータ格納部203に蓄積されたものとすると、当該ログデータ203eによれば、推定体感温度が22℃であっても、風が当たらない(つまり、設定風向きが「水平」である)ことによって、ユーザBが「快適」と感じている。この場合、ログデータ203c~203eからは、快適温度「22℃」及び風に対する好み「風が嫌い」が定義された第2個人特性モデルが作成される。
上記したように第1個人特性モデルを第2個人特性モデルが更新された場合には、風の因子の影響を取り除き、ユーザBの快適温度を補正することが可能となる。
すなわち、本実施形態においては、例えば一旦作成された個人特性モデルを用いて決定された制御値に基づいて空調機30の運転を制御した結果としてユーザから得られるフィードバック(ログデータ)を更に分析し、当該個人特性モデルを更新する(強化学習する)構成とすることにより、当該個人特性モデルの精度が向上し、過去の似た状況でのユーザの体感情報等を考慮した空調機30の運転制御を実現することが可能となる。
また、本実施形態においては1人のユーザに対して1つの個人特性モデルを作成するものとして説明したが、ユーザ端末10において体感情報が取得される(ユーザが感じる空調情報が入力される)度にログデータ収集処理が実行されることにより、ログデータ格納部203には多数のログデータを蓄積することが可能となる。この場合、例えば1人のユーザに対して状況に応じた複数の個人特性モデルを作成するようにしてもよい。
具体的には、例えば朝の時間帯では出社したばかりで暑いため、風を好む傾向にあるが、昼の時間帯では風に当たりたくないと考えるユーザが想定される。この場合には、ログデータ格納部203に格納されている特定のユーザのログデータの中から所定の時間帯(例えば、朝の時間帯、昼の時間帯、夜の時間帯等)に該当する時刻を含むログデータを抽出し、当該ログデータに基づいて当該時間帯に応じた個人特性モデルを作成することができる。このような個人特性モデルを時間帯毎に用意(作成)しておくことで、ユーザが室内50にいる時間帯に適した個人特性モデルを用いて空調機30の制御値を決定することができるため、よりユーザの快適度を向上させることが可能となる。
ここでは、時間帯毎に個人特性モデルを用意しておく場合について説明したが、例えばログデータとしてユーザの位置を取得しておくことで、当該ユーザの室内50における位置毎に個人特性モデルを用意するような構成も可能となる。また、例えば空調機30の種別によって風に対する好みが変化する場合もあるため、室内50(空調機30)毎に個人特性モデルを用意しておくことも可能である。また、例えば設定温度が低いときの冷たい風を苦手とするようなユーザがいることも考えられるため、個人特性モデルは、例えば設定温度毎に作成されてもよい。更に、個人特性モデルは、活動量、外気温または季節(時期)等に基づいて細分化されてもよい。また、個人特性モデルは、ここで説明した以外の観点に基づいて作成されても構わない。
なお、本実施形態においては、空調機30が4方向に風を吹き出すための4つの吹き出し口301~304を備える構成であるものとして説明したが、当該空調機30は、少なくとも1つの吹き出し口を備える構成であればよい。
更に、本実施形態においては空調制御装置20が1つの装置であるものとして説明したが、空調制御装置20は、例えば空調機30に組み込まれていてもよいし、図5に示す各部201~211の各々が分散して配置された複数の装置から構成されていてもよい。また、図5に示す格納部201、203及び205のうちの少なくとも一部は、空調制御装置20とは別の外部のサーバ装置等に配置されていてもよい。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。