JP2018091560A - 空調機器の制御システム - Google Patents

Abstract

【課題】不在期間において空調機を現在の設定のまま使う方が省エネか、消してつけなおす方が省エネかのユーザ判断を容易にする。【解決手段】温度等の環境情報の履歴、空調機の設定情報、天気予報などの外気温予測の情報を用いて、室温及び電力量を予測することで、現在の設定のまま運転するほうが省エネか、消してつけ直すほうが省エネかを自動で判断し、人の在・不在期間の履歴情報を用いることで、今後の不在時間を予測し、その不在期間における省エネ運転方法をユーザに伝える。【選択図】図１３

Description

本発明は、空調機器（特にエアコン）に関し、省エネ運転方法のユーザへのアドバイスや省エネ運転の制御方法に関する。

空調機器は、家庭の電気代の大きな部分を占めるため、省エネ運転の方法についてユーザの関心は高い。例えば、部屋を一時的に不在にするようなケースにおいて、空調機器のつけっぱなしがよいのか、一旦停止をして、帰ってからつけなおすのがよいのか、インターネット等で話題になることが多い。つけっぱなしがよいのか、一旦停止して付け直すのが良いのかは、居住空間の断熱性、室温、設定温度、外気温などの様々な要素により左右されるため一意に決定することはできず、ユーザは判断に困ることになる。

特許文献１記載の発明では、一時的に部屋を不在にする場合、運転中の空調機器を停止した場合と、運転を継続させた場合とでどちらが省エネ運転となるかの分岐点となる分岐点時間を計算し、ユーザに報知する方法を提示している。

特開２０１５−１７８９１７号公報

特許文献１記載の発明では、ユーザがリモコンなどを通じて、明示的にアドバイス要求を行わなければならず、不便である。そのような操作をせずとも適切なタイミング・メッセージで、ユーザに通知することが好ましい。その場合には、現在時刻からの不在時間などを考慮する必要がある。例えば、これから３時間不在にする場合には、１時間であればつけっぱなしがお得という情報が提示されたとしてもユーザにとっては意味がない情報となるため、ユーザのシチュエーションに合わせて適切なメッセージを伝える必要がある。

本開示の一態様に係る空調制御システムは、空調機を制御し、室内の空調を制御する空調制御システムであって、空調機のセンサーから取得される室内温度やエアコン稼動時の電力量・人の在不在情報を蓄積するセンサーデータ蓄積手段と、空調機から取得される空調の設定情報を蓄積する空調情報データ蓄積手段と、環境データ蓄積手段と空調情報データ蓄積手段によって蓄積されたデータを用いて、空調機の空調機の設定に対して室温変化・電力量を予測する室内環境・電力量予測手段と、空調機の設定を変更する指示を行うアプリケーションから構成され、アプリケーションは、在不在情報を用いて、該当の空調機が存在している部屋において、人が通常いる通常在時間帯と人が不在にしている通常不在時間帯を算出し、現在時刻から次に通常在時間帯が始まる時刻までの時間を運転停止時間とし、室内環境・電力量予測手段を用いて、現在の運転設定と同じ設定で運転を継続した場合の連続運転電力量と、現在の運転を停止し運転停止時間後に運転を開始して現在の室温に戻すための断続運転電力量を算出し、連続運転電力量と断続運転電力量の比較結果を表示する。

このように構成することによって、ユーザは不在にする場合に、通常の不在時間に応じた省エネ運転の方法を容易に理解することができ、空調機を省エネに制御することが可能となる。

本発明の実施の形態において提供するサービスの全体像を示す図である。 本発明の実施の形態におけるサービスの類型（自社データセンタ型）を示す図である。 本発明の実施の形態におけるサービスの類型（ＩａａＳ利用型）を示す図である。 本発明の実施の形態におけるサービスの類型（ＰａａＳ利用型）を示す図である。 本発明の実施の形態におけるサービスの類型（ＳａａＳ利用型）を示す図である。 本発明の実施の形態における空調制御システムのシステム構成を説明する図である。 本発明の実施の形態における履歴ＤＢに格納されるデータ構造を説明する図である。 本発明の実施の形態におけるエアコン設定画面を説明する図である。 本発明の実施の形態におけるエアコン設定画面の省エネメッセージを説明する図である。 本発明の実施の形態における空調機の室温及び電力量の履歴と予測値を説明する図である。 本発明の実施の形態における空調機のタイマー設定画面と省エネメッセージを説明する図である。 本発明の実施の形態におけるエアコン設定画面において、タイマー運転を考慮した省エネメッセージを説明する図である。 本発明の実施の形態における在不在履歴に基づいた省エネメッセージを説明する図である。 本発明の実施の形態における省エネメッセージを伝えるとともに制御を行なう場合のエアコン設定画面を説明する図である。 本発明の実施の形態における自動で省エネ方法を判断し制御を行ない、制御後にメッセージを行なう方法を説明する図である。 本発明の実施の形態における制御方法を伝える場合の別例を説明する図である。 本発明の実施の形態における省エネメッセージの表示方法の別形態を説明する図である。 本発明の実施の形態におけるデータ蓄積の処理フローを説明する図である。 本発明の実施の形態における省エネメッセージの表示フローを説明する図である。 本発明の実施の形態における在不在情報を考慮した省エネメッセージの表示フローを説明する図である。 本発明の実施の形態における省エネメッセージの表示をグラフで行なう方法を説明する図である。 本発明の実施の形態における不在時断続運転の予測において、在室までの運転時間を考慮する方法を説明する図である。

（提供するサービスの全体像）
図１（Ａ）には、本実施の形態にかかるサービスの全体像が示されている。

グループ１００は、例えば企業、団体、家庭等であり、その規模を問わない。グループ１００には、複数の機器１０１である機器Ａ、機器Ｂおよびホームゲートウェイ１０２が存在する。複数の機器１０１には、インターネットと接続可能な機器（例えば、スマートフォン、ＰＣ、ＴＶ等）もあれば、それ自身ではインターネットと接続不可能な機器（例えば、照明、洗濯機、冷蔵庫等）も存在する。それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ１０２を介してインターネットと接続可能となる機器が存在してもよい。またグループ１００には複数の機器１０１を使用するユーザ１０が存在する。

データセンタ運営会社１１０には、クラウドサーバ１１１が存在する。クラウドサーバ１１１とはインターネットを介して様々な機器と連携する仮想化サーバである。主に通常のデータベース管理ツール等で扱うことが困難な巨大なデータ（ビッグデータ）等を管理する。データセンタ運営会社１１０は、データ管理やクラウドサーバ１１１の管理、それらを行うデータセンタの運営等を行っている。データセンタ運営会社１１０が行っている役務については詳細を後述する。ここで、データセンタ運営会社１１０は、データ管理やクラウドサーバ１１１の運営等のみを行っている会社に限らない。例えば複数の機器１０１のうちの一つの機器を開発・製造している機器メーカが、併せてデータ管理やクラウドサーバ１１１の管理等を行っている場合は、機器メーカがデータセンタ運営会社１１０に該当する（図１（Ｂ））。また、データセンタ運営会社１１０は一つの会社に限らない。例えば機器メーカ及び他の管理会社が共同もしくは分担してデータ管理やクラウドサーバ１１１の運営を行っている場合は、両者もしくはいずれか一方がデータセンタ運営会社１１０に該当するものとする（図１（Ｃ））。

サービスプロバイダ１２０は、サーバ１２１を保有している。ここで言うサーバ１２１とは、その規模は問わず例えば、個人用ＰＣ内のメモリ等も含む。また、サービスプロバイダがサーバ１２１を保有していない場合もある。

なお、上記サービスにおいてホームゲートウェイ１０２は必須ではない。例えば、クラウドサーバ１１１が全てのデータ管理を行っている場合等は、ホームゲートウェイ１０２は不要となる。また、家庭内のあらゆる機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。

次に、上記サービスにおける機器のログ情報（操作履歴情報および動作履歴情報）の流れを説明する。

まず、グループ１００の機器Ａ又は機器Ｂは、各ログ情報をデータセンタ運営会社１１０のクラウドサーバ１１１に送信する。クラウドサーバ１１１は機器Ａ又は機器Ｂのログ情報を集積する（図１（ａ））。ここで、ログ情報とは複数の機器１０１の、例えば運転状況や動作日時等を示す情報である。例えば、テレビの視聴履歴やレコーダの録画予約情報、洗濯機の運転日時・洗濯物の量、冷蔵庫の開閉日時・開閉回数などであるが、これらのものに限らずあらゆる機器から取得が可能なすべての情報をいう。ログ情報は、インターネットを介して複数の機器１０１自体から直接クラウドサーバ１１１に提供される場合もある。また複数の機器１０１から一旦ホームゲートウェイ１０２にログ情報が集積され、ホームゲートウェイ１０２からクラウドサーバ１１１に提供されてもよい。

次に、データセンタ運営会社１１０のクラウドサーバ１１１は、集積したログ情報を一定の単位でサービスプロバイダ１２０に提供する。ここで、データセンタ運営会社が集積した情報を整理してサービスプロバイダ１２０に提供することの出来る単位でもよいし、サービスプロバイダ１２０が要求した単位でもよい。一定の単位と記載したが一定でなくてもよく、状況に応じて提供する情報量が変化する場合もある。前記ログ情報は、必要に応じてサービスプロバイダ１２０が保有するサーバ１２１に保存される（図１（ｂ））。そして、サービスプロバイダ１２０は、ログ情報をユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。提供するユーザは、複数の機器１０１を使用するユーザ１０でもよいし、外部のユーザ２０でもよい。ユーザへのサービス提供方法は、例えば、サービスプロバイダから直接ユーザへ提供されてもよい（図１（ｂ）、（ｅ））。また、ユーザへのサービス提供方法は、例えば、データセンタ運営会社１１０のクラウドサーバ１１１を再度経由して、ユーザに提供されてもよい（図１（ｃ）、（ｄ））。また、データセンタ運営会社１１０のクラウドサーバ１１１がログ情報をユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ１２０に提供してもよい。

なお、ユーザ１０とユーザ２０とは、別でも同一でもよい。

（実施の形態１）
図６は、本発明の実施の形態１における空調制御システムの構成を示すブロック図である。

空調システムは、空調機６１０、クラウドサービス６２０から構成される。クラウドサービス６２０のブロックの一部もしくは全ては、データセンタ運営会社のクラウドサーバもしくはサービスプロバイダのサーバのどちらかに属す。

空調機６１０は、室内の空質環境を調整する機器であり、例えば、ルームエアコンである。空調機６１０は、センサー情報取得手段６１１、制御情報取得手段６１２、空調制御手段６１３から構成される。

空調制御手段６１３は、室内の空気の温度や湿度などを調整する制御機構であり、具体的にはエアコンの空調機能であるが、部屋の温度や湿度をコントロールできる制御機構であれば、これに限らない。

センサー情報取得手段６１１は、空調機に搭載されるセンサーを使ってデータを取得する手段である。取得できるセンサーのデータとしては、室内機に設置された温湿度センサーから取得される室内の温度／湿度、室外機などに設置されたセンサーから取得される室外の温度／湿度、赤外線などの人感センサーから取得される人が「いる」「いない」の情報を示す「在不在情報」、エアコン稼動時の電力量を計測する電力センサーから取得される「電力量」などがある。

制御情報取得手段６１２は、空調制御情報を取得する手段である。空調制御情報とは、空調制御手段６１３の制御内容を示し、具体的には、運転ステータス（ＯＮ／ＯＦＦ）、設定モード（冷房／暖房／除湿／自動）、設定温度、風向き、風量などの情報である。

以上が空調機６１０の構成の説明である。

クラウドサービス６２０は、センサー情報格納手段６２１、制御情報格納手段６２２、室内環境・電力量予測手段６２３、空調設定手段６２４、ユーザインターフェース６２５、履歴ＤＢ６２６、外環境予測手段６２７から構成される。

センサー情報格納手段６２１は、空調機６１０のセンサー情報取得手段６１１を通じて取得した温湿度情報や在不在情報や電力情報を履歴ＤＢ６２６に格納する手段である。通信はインターネット等の通信手段を使って行われ、例えば、５分に１回、センサー情報格納手段６２１が、センサー情報取得手段６１１から情報を取得して格納する。また、センサー情報取得手段６１１からセンサー情報格納手段６２１に、定期的に情報をアップロードする方式でも良い。

制御情報格納手段６２２は、空調機６１０の制御情報取得手段６１２を通じて取得した空調制御情報を履歴ＤＢ６２６に格納する手段である。通信はインターネット等の通信手段を使って行われ、例えば、５分に１回、制御情報格納手段６２２が、制御情報取得手段６１２から情報を取得して格納する。また、制御情報取得手段６１２から制御情報格納手段６２２に、定期的に情報をアップロードする方式でも良く、制御が変更されたイベントをトリガーとして、制御情報取得手段６１２が、制御情報格納手段６２２にアップロードする方式でも良い。

履歴ＤＢ６２６は、センサー情報格納手段６２１や制御情報格納手段６２２から受け取った情報を格納するデータベースである。データベースの形式は、ＳＱＬ等のリレーショナルＤＢが一般的であるが、Ｋｅｙ−Ｖａｌｕｅ型などの簡素な関係性でデータを構成するＮｏＳＱＬと呼ばれるＤＢの構成であってもよい。

図７は、履歴ＤＢ６２６のテーブル構造の例を示している。ＩＤは各レコードを識別するユニークなＩＤ、時刻は各情報を取得した時刻、室内温度、室内湿度、室外気温、室外湿度、在・不在情報、電力量は、センサー情報取得手段６１１を通じて取得した情報であり、運転ステータス、運転モード、設定温度、風量、風向は、制御情報取得手段６１２を通じて取得した空調制御情報である。説明を容易にするため、温湿度情報と、空調制御情報を１つのテーブルにまとめているが、別のテーブルとして管理してもよい。また、図７の電力量は、前レコードから現レコードまでの積算電力量（ｗｈ）を示している。

外環境予測手段６２７は、気象情報サーバなどから空調機が存在する該当地域における今後の天候予測情報や天候履歴情報を受け取り、室内環境・電力量予測手段６２３に入力する手段である。

室内環境・電力量予測手段６２３は、履歴ＤＢ６２６を利用して、今後の室内における環境（室温・室内湿度等）を、機械学習により予測する手段である。一般に機械学習は２つのステップに分類される、学習フェーズと識別フェーズとよばれる。学習フェーズは、過去の履歴データなどの訓練データを入力し、データ解析することで、そのデータの関係性を抽出する。そして、次の識別フェーズでは、識別データ（予測を行うための入力パラメータ）を入力し、学習フェーズで抽出したデータの関係性に基づき、予測値を出力する。ここで室内環境・電力量予測手段６２３は、訓練データとして、履歴ＤＢ６２６の履歴データと外環境予測手段６２７から取得した天候履歴情報を入力する。そして、室内環境・電力量予測手段６２３に、「未来の時刻」、「今後の天気予報などの天候予測値」、「空調機の設定情報」を識別データとして、入力する。このようにして、今後の時刻での環境情報（室温・室内湿度）と電力量を予測する。機械学習を行う上では、どのようなデータを訓練データとして入力し、どのようなデータを識別データとして入力するのかが、予測の精度を上げるポイントとなる。学習のアルゴリズムは線形回帰、ニューラルネットワーク、ディープラーニングなど多岐に渡るが、ここでは限定しない。機械学習のクラウド上のサービスとして、Ｇｏｏｇｌｅ社のＰｒｅｄｉｔｉｏｎ ＡＰＩやＭｉｃｒｏｓｏｆｔのＡｚｕｒｅ ＭＬなどがあり、一般に利用されやすくなっており、室内環境・電力量予測手段６２３はそのようなライブラリやＡＰＩを活用するような構成でも良い。

ここで、室内環境・電力量予測手段６２３は、履歴ＤＢ６２６のデータと、外環境予測手段６２７からの天候情報などを訓練データとして学習を行うが、図７の例のように、履歴ＤＢ６２６のデータに、空調機６１０の設定情報を使うことにより、空調機６１０の設定と室温・電力量や天気予報との関係性を抽出することが可能になる。これにより室内環境・電力量予測手段６２３に、エアコンの設定情報を識別データとして入力することで、該当設定に対する室温や電力量予測を高精度に行うことができる。

インターフェース６２５は、ユーザが入力を受け付ける外部インターフェースであり、例えば、ｈｔｔｐ／ｈｔｔｐｓプロトコルで通信する外部Ｉ／Ｆ（ＷｅｂＡＰＩ）である。アプリケーション６３０から受け取ったユーザの空調機に対する設定命令を受け付け、空調設定手段６２４に通知する。また、室内環境・電力量予測手段６２３が出力した今後の室温予測や電力量予測の結果をインターフェース６２５を通じてアプリケーション６３０に伝送したり、履歴ＤＢ６２６に格納される情報をインターフェース６２５を通じてアプリケーション６３０に伝送する。

図８はアプリケーション６３０のＧＵＩの例を示している。図８の例では、「エアコン」は制御対象の空調機を示し、複数の空調機がある場合には、プルダウンから選択できる。現在の状態は、空調機の現在状態を示し、履歴ＤＢ６２６の直近のエアコン設定状態のデータを取得して表示する。「運転」は運転のＯＮ／ＯＦＦ、「モード」は冷房、暖房、除湿などの空調機の設定モード、「温度」は空調機に指定する設定温度、「風量」は空調機が排出する風量の設定、「風向」は空調機が排出する風の向きを示す。「設定」ボタンを押すことで、アプリケーション６３０は、ＧＵＩで設定されたデータを、ｈｔｔｐ／ｈｔｔｐｓプロトコルのフォーマットに変換してインターフェース６２５に通知する。

空調設定手段６２４は、インターフェース６２５で受け取った設定命令を元に、空調制御手段６１３に運転設定を通知する。

本実施の形態において、アプリケーション６３０は、その起動時に、インターフェース６２５を通じ、履歴ＤＢ６２６に格納される該当空調機の状態が運転中の場合に、室内環境・電力量予測手段６２３を用いて、２種類の予測を行う。

１つは、現在の運転設定のまま、稼動した場合の室温と電力量予測を実施する。このように不在時に連続運転を行なうことを不在時連続運転とし、その予測結果を不在時連続運転予測結果とする。図１０に予測結果の例を示している。図１０は、室温・電力量の推移を示し、Ｘ軸が時刻、Ｙ軸が電力量と温度を示す。現在時刻は１１：００であり、１０：２０〜１１：００までは、履歴情報を示し、線が室温の推移、棒グラフが１０分間隔における電力量を示す。１１：００以降は予測結果の推移となる。ここで、現在の運転設定のまま稼動した場合の室温予測結果は点線Ｂ、電力量予測結果は縦線の棒グラフである。

もう１つの予測は、運転停止時間をＸ時間と仮定した場合に、Ｘ時間運転停止後に、再度運転を開始、室温が、現在運転設定のまま連続運転した場合の室温と一致する時刻までの室温・電力量の予測である。このように不在時に停止を行ない、その後つけなおす運転を行なうことを不在時断続運転とし、その予測結果を、不在時断続運転予測結果とする。図１０の例では、２０分運転停止し、２０分後に再度運転を行った場合に、室内温度が、現在運転設定のまま連続運転した場合の室温（点線Ｂ）と一致するまでの電力量（斜め線棒グラフ）と室温（線Ａ）である。運転停止時間は、例えば、１０分から始まり、１０分ずつ増やしていき、繰り返し予測を行う。その上で、不在時断続運転予測結果の電力量が、不在時連続運転予測結果の電力量よりも小さくなった時点で予測を終了する。不在時断続運転予測結果が、不在時連続運転予測結果の電力量よりも大きい最も長い運転停止時間を「境界運転停止時間」とする。

アプリケーション６３０は、この予測結果を受け取り、境界運転停止時間をユーザに伝えるように、図９のように画面に重ねて表示する。例えば、境界運転停止時間が３０分の場合には、「３０分の不在ならつけっぱなしがお得です」というメッセージを伝える。このように構成することによって、ユーザはエアコンのリモコン画面を起動するだけで、不在時間中にどのようにエアコンを制御すべきかが明確に理解できるようになる。

ここで、運転停止時間を特定するための手段として、在・不在の履歴情報を活用するようにしてもよい。図１３の例は、在・不在の履歴を元に、ユーザの通常生活における在・不在期間を示している。通常不在にしていることが多い時間帯を「通常不在時間帯」、通常在が多い時間帯を「通常在時間帯」とする。通常不在・在期間は、例えば、数週間の在・不在履歴を元に、該当時間において、在の割合が多い場合は通常在時間帯、不在の割合が多い場合は通常不在時間帯と算出される。この場合には、現在時刻を基点として、次の通常在時間帯の始まりまでの時間を不在予測時間として予測し、この時間を運転停止時間として算出する。図１３の例では、現在時刻が地点Ａである場合には、次の通常在時間帯の始まりまでの長さＢが、不在予測時間として算出される。これを運転停止時間として、電力量と室温予測を行うことで、図１３のように、「いつもどおりの３０分程度のお出かけならつけっぱなしがお得です」というようにメッセージを行うことができ、ユーザとしてはより簡単で直感的に省エネ設定を判断することができる。

なお、通常在時間帯・不在時間帯の計算の仕方は、曜日ごとに分けて計算するようにしても良い。月曜日〜日曜日までのそれぞれの曜日の在・不在履歴を使って、計算する。そして、アプリケーション６３０は、現在時刻が何曜日に属するかで、該当曜日の通常在期間・不在期間を使うようにする。このように構成することで、曜日ごとでない場合に比べて、精度が高くなる。

なお、通常在時間帯・不在時間帯の計算の仕方は、平日・休日ごとに分けて計算するようにしても良い。平日と休日の在・不在履歴を使って、平日の通常在・不在期間、休日の通常在・不在期間を計算する。そして、アプリケーション６３０は、現在時刻が平日か休日に属するかで、該当日の通常在時間帯・不在時間帯を使うようにする。このように構成することで、平日・休日で分けない場合に比べて、精度が高くなる。

なお、通常在時間帯・不在時間帯の計算は、スケジューラのイベントの情報を考慮するように構成してもよい。例えば、スケジューラにおいて、「仕事」「外食」「お稽古」のイベントが入力されている場合に、そのイベントとセットで在時間帯・不在時間帯を学習することで、仕事・外食・お稽古のイベントがある場合には不在時間帯が多い、という相関が導き出せ、通常在時間帯・不在時間帯の精度が高くなる。

なお、通常在時間帯・不在時間帯の計算は、スマートフォンのＧＰＳの情報を考慮するように構成しても良い。例えば、ＧＰＳ値を、通常在時間帯と通常不在時間帯と関連させて学習することによって、現在値のＧＰＳの値を使うことで、在・不在の予測精度を高めることができる。

なお、通常在時間帯・不在時間帯の計算の仕方は、季節ごとに分けて計算するようにしても良い。例えば、夏と冬では生活パターンが異なるので、季節ごとに通常在・不在時間帯を計算して、アプリケーション６３０は現在時刻が属する季節に応じて、該当季節の在・不在時間帯を活用するように構成しても良い。

なお、通常在時間帯・不在時間帯の計算は、曜日ごと、平日・休日ごと、季節ごとを例に挙げたが、それぞれの組合せであってもよい。

なお、通常在時間帯・不在時間帯を用いて、ユーザの不在予測時間を算出して、これを運転停止時間とすると説明したが、図２２に示すように、不在後の運転時間を考慮して、運転停止時間を設定するように構成しても良い。運転停止時間を不在予測時間とすると、不在して帰った直後は暑いもしくは寒くなっており、不快な気温を過ごす必要がある。そこで、運転停止期間は、室温予測を行ない元の温度に戻るまでの時間を考慮した運転時間を踏まえて算出する。具体的には、以下のように算出する。まず、運転停止時間を初期値の最小値（例：１０分）とし、現在時刻から該当時間停止した場合の室温を予測する。次に運転停止期間後にエアコンの運転を開始して元の温度が戻るまでの時間（運転時間）を予測する。運転停止時間＋運転時間＜＝不在予測期間であれば、運転停止期間に時間を追加して（例：＋１０分）、再度同じ予測計算を行なう。これを運転停止時間＋運転時間＞不在予測期間になるまで繰り返す。この計算の結果、最も大きい運転停止時間を使ってユーザに、連続運転がお得か、断続運転がお得かの省エネメッセージを伝えるように構成し、断続運転がお得とした場合には、予測結果を用いて、運転停止期間後に空調機の制御を自動で行うことで、ユーザは省エネかつ快適な制御を行うことができる。

以上が本実施の形態における空調制御システムのシステム構成についての説明である。

次に本実施の形態における空調制御システムの処理フローについて説明する。本実施の空調制御システムにおける処理フローは２つに分けられる。１つは「データ蓄積フロー」であり、１つは「空調設定フロー」である。

図１８は「データ蓄積フロー」を示している。

ステップ１８０１にて、空調機６１０は、センサー情報取得手段６１１により温湿度情報や在不在情報や電力情報を取得する。

ステップ１８０２にて、空調機６１０は、制御情報取得手段６１２により、空調機の設定情報を取得する。

ステップ１８０３にて、空調機６１０は、クラウドサービス６２０に対して、ステップ１８０１によって取得した温湿度情報や在不在情報や電力情報や、ステップ１８０２によって取得した制御情報を伝送する。クラウドサービス６２０は、センサー情報格納手段６２１や制御情報格納手段６２２によりセンサー情報や制御情報を受け取り、履歴ＤＢ６２６に登録する。

ステップ１８０４にて、空調機は、一定期間のウェイト（例：５分間）を行い、ステップ１８０１に戻る。

上記データ蓄積フローの処理シーケンスを図１８に示している。ステップ１８０３において空調機６１０とクラウドサービス６２０間でのデータ伝送が行われる。

上記データ蓄積フローは、クラウドサービス６２０との通信経路が確立されていて、電源ＯＮの状態では常に動き続ける。このようにして室内環境・設定情報データをすべてデータベースに登録する。また、図１８ではセンサー情報取得と制御情報取得をシーケンシャルに行ったが、並列に実行してもよい。また、制御情報取得については、定期的にルーチン実行するのではなく、制御が変更されたタイミングで、アップロードするように構成してもよい。

以上が「データ蓄積フロー」の説明である。

次に「アドバイス表示フロー」について説明する。

処理フローについて図１９を参照し説明する。図１９はアドバイス表示フローのフローチャートである。

ステップ１９０１にて、ユーザはアプリケーション６３０を起動する。

ステップ１９０２にて、アプリケーション６３０は、インターフェース６２５を通じて、室内環境・電力量予測手段６２３を利用して、不在時連続運転の予測結果と、不在断続運転の予測結果を取得する。

ステップ１９０３にて、アプリケーション６３０は、設定画面表示を行う。この画面は具体的には、図８のような画面である。

ステップ１９０４にて、ステップ１９０２にて取得した予測結果に基きアドバイスを行う。この際に、境界運転停止時間に基き、つけっぱなし時がお得な時間情報を含めたメッセージを行う。具体的には、図９のように３０分の不在ならつけっぱなしがお得です、というような情報を表示する。

以上が「アドバイス表示フロー」についての説明である。

次に在・不在情報を活用した場合の「アドバイス表示フロー」について説明する。

処理フローについて図２０を参照し説明する。図２０はアドバイス表示フローのフローチャートである。

ステップ２００１にて、ユーザはアプリケーション６３０を起動する。

ステップ２００２にて、アプリケーション６３０は、インターフェース６２５を通じて、室内環境・電力量予測手段６２３を利用して、不在時連続運転の予測結果と、不在時断続運転の予測結果を取得する。この際に、通常在時間帯・通常不在時間帯を履歴ＤＢ６２６に蓄積される人感センサーの在・不在情報から予測し、現在時刻から次の通常在期間が始まるまでの時間を不在時間として、その不在期間を元に運転停止時間を特定し、不在時運転予測結果と、不在時断続運転予測結果を算出する。

ステップ２００３にて、アプリケーション６３０は、設定画面表示を行う。この画面は具体的には、図８のような画面である。

ステップ２００４にて、ステップ２００２にて取得した予測結果に基きアドバイスを行う。この際に、境界運転停止時間に基き、つけっぱなし時がお得な時間情報を含めたメッセージを行う。具体的には、図１３のようにいつもどおりの３０分の不在ならつけっぱなしがお得です、というような情報を表示する。

以上が「アドバイス表示フロー」についての説明である。

なお、時刻を指定して空調機６１０をタイマー制御するようなケースの場合に、該当時刻までの不在時間を考慮して、つけっぱなしがよいか、そうでないかを示すとともに、制御までを自動で行うようにしてもよい。例えば、図１４左のようなＧＵＩ画面において、つけっぱなしがお得な場合には、「１９時までならお得なつけっぱなしにしておきます」というメッセージを表示し、ＯＫを押すと、つけっぱなしで制御するとしても良い。また、図１４右のようなＧＵＩ画面において、つけっぱなしがお得でない場合には、「１９時までなら一旦オフしてつけなおします」というメッセージを表示して、ＯＫを押すと、一旦ＯＦＦを行い、該当時刻もしくは該当時刻に快適な温度になるように制御を行うようにしてもよい。このようにすれば、ユーザの制御の手間を省くことができる。

なお、メッセージの表示方法としては、運転中の場合には、ＧＵＩの「運転」フィールドをＯＮに設定しておき、ＯＮからＯＦＦに変更したタイミングで表示するようにしてもよい。このようにすることで、不在にするわけではなく、エアコンの他の設定を変更するだけのユーザにとっては、不要なメッセージを見なくてよくなる。

なお、本実施の形態では、メッセージは、スマートフォンを想定したアプリケーション６３０のＧＵＩ画面で表示するとしたが、アプリケーション６３０は、空調機６１０を制御する赤外線などのリモコン上で動くアプリケーションでも問題ない。

なお、メッセージの伝え方としては、音声合成を行い再生するようにしてもよい。このようにすることで、一般的な赤外線リモコンのような表現力が乏しいＵＩでも伝えることができる。

なお、アプリケーション６３０の起動時に予測を行うとしていたが、クラウドサービス６２０側で、例えば１０分周期で毎回計算しておき、結果だけを起動時に伝えるとしても良い。このようにすることで、アプリケーション上で表示するまでの待ち時間を短縮できる。

なお、本実施の形態で、境界運転停止時間を用いて、図９のように表示する場合に、例えば、不在時間のリミットを設けて、そのリミットを越えるときだけ表示するという構成にしてもよい。例えば、リミットを１時間とした場合には、境界運転停止時間が、１時間未満の場合には、メッセージを表示しないようにする。つけっぱなしの方がお得か極端に短ければ、ユーザにとっては意味のない情報となることが多くなってしまうが、このように構成することで、不要な情報をユーザに提示しなくて良くなり、ユーザはわずらわしさを軽減できる。

なお、本実施の形態で、境界運転停止時間を用いて、図９のように表示する場合に、例えば、使っているうちに、ユーザが分かりきっている情報を減らしていくようにしてもよい。例えば、「１０分の不在だったらつけっぱなしがよい」などは、ユーザ自身が学習していくため、メッセージを伝える次第に、分かりきった情報となっていく。つけっぱなしがよいか、そうでない方がよいのかをユーザが迷う境界条件のメッセージだけを表示するように表示の仕方を学習するようにしてもよい。学習の方法としては、メッセージ表示後のユーザの動作にある。「Ｘ分の不在ならつけっぱなしがお得」というメッセージを行った後に、停止するかしないかの操作履歴を元にして、境界条件を明らかにするようにしてもよい。

なお、アプリケーション６３０のＧＵＩにおいて、図１１のように指定時刻からの動作を設定するような構成の場合には、指定時刻までの不在時間を入力として予測した結果をメッセージとして表示するようにしてもよい。その場合図１１のように、１７時までならつけっぱなしがお得です、というメッセージとなり、ユーザは境界運転停止時間を伝えられるよりも分かりやすく理解できる。

なお、アプリケーション６３０のＧＵＩにおいて、すでにタイマー設定がされている場合には、リモコン画面において、次のＯＮタイマーまでの時刻を不在時間として、予測した結果をメッセージとして表示するようにしてもよい。例えば、図１２のＧＵＩでは、画面下部に、次のタイマー設定（この例では、８／１４ １７：００）が表示されているが、その時刻までを不在時間として、つけっぱなしがお得か、どうかを判定してメッセージを表示している。この場合も図１１と同様に、１７時までならつけっぱなしがお得です、というメッセージとなり、ユーザは境界運転停止時間を伝えられるよりも分かりやすく理解できる。

なお、時刻を指定して空調機６１０をタイマー制御するようなケースの場合に、該当期間までの不在時間を考慮して、不在時連続運転が省エネか、不在時断続運転が省エネかを示すとともに、制御までを自動で行うようにしてもよい。例えば、図１４左のようなＧＵＩ画面において、不在時連続運転がお得な場合には、「１９時までならお得なつけっぱなしにしておきます」というメッセージを表示し、ＯＫを押すと、不在時連続運転で制御するとしても良い。また、図１４右のようなＧＵＩ画面において、不在時断続運転がお得の場合には、「１９時までなら一旦オフしてつけなおします」というメッセージを表示して、ＯＫを押すと、一旦ＯＦＦを行い、該当時刻もしくは該当時刻に快適な温度になるように制御を行うようにしてもよい。このようにすれば、ユーザの制御の手間を省くことができる。

なお、時刻を指定して空調機６１０をタイマー制御するようなケースの場合に、該当期間までの不在時間を考慮して、不在時連続運転が省エネか、不在時断続運転が省エネかを計算し、省エネになる方で制御するように構成し、結果を制御後に伝えるようにしてもよい。図１５はそのＧＵＩの例を示している。図１５左の画面において、帰宅時刻を１９時にしてＯＫを押した場合に、クラウドサービス６２０側で、室内環境・電力量予測手段６２３を用いて、つけっぱなしがよいか、一旦ＯＦＦして付け直すのが良いのかを計算し、お得な方で制御を行う。そして、帰宅時にアプリを確認したときの画面が図１５右であり、このときに「１９時までならお得な着けっぱなしにしておきました」という形で報告するようにしてもよい。なお、制御方法の結果のフィードバックは、このとおりだけでなく、図１６のように設定温度の推移などの詳細な制御方法を提示するように構成してもよい。

なお、本実施の形態では、アプリケーション６３０のＧＵＩにおいて、省エネ運転方法をメッセージとしてアドバイス表示するとしたが、アプリケーションを経由せずに自動で制御しても良い。例えば、現在の空調機の機能としてオートオフ機能がある。オートオフ機能は、人感センサーなどで人の不在を検知したら不在時の制御を停止もしくは省エネ運転にするという機能である。しかし、一方で、ちょっとした退出や外出で部屋からでていった場合に、すぐに消されてしまうなどの課題がある。そこで、在不在情報の通常在時間帯、通常不在時間帯を活用する。現在時刻において、人が不在であり、かつ通常不在時間帯であれば、その次の通常在時間帯まで不在である可能性が高いため、不在時連続運転が省エネか、不在時断続運転が省エネかを予測して求め、その結果に基づき制御を行なうように構成しても良い。

なお、図１５での最も省エネ効率の高い運転の決定方法として、つけっぱなしか、一旦ＯＦＦしてつけなおすか、だけでなく、「設定温度を変化（上げたり、下げたり）させて運転」、「指定時刻への温度推移を徐々に温度を上げる・下げる」等の制御パターンを用意して、最も効率の良いものを選ぶように構成してもよい。

なお、不在時連続運転が省エネか、不在時断続運転が省エネかのアドバイス情報を表示する場合に、どれくらいお得になるのかを電気代に換算して表示するようにしてもよい。例えば、つけっぱなしの方が１０円お得です、など。このようにすることで、ユーザはより効果を実感することができる。

なお、図１７に示すように、室温予測・電力予測の機能を利用して、設定を変更した場合の電力量のお得度合いを画面に表示するように構成しても良い。図１７の場合には、現在の状態が図１７左のようになっている場合に、設定温度を２５度から２６度に変更すると、その際に２５度設定の場合の今後１時間の電力量と、２６度設定の場合の今後１時間の電力量を予測し、その差を金額換算して、画面にメッセージとして表示するように構成してもよい。このように構成することで、ユーザはどのように設定したら効果的な省エネ運転ができるかを直感的に判断することができる。設定温度だけでなく、風量、風向など空調機の設定すべてにおいて、同様に電力量効果を計算・表示するように構成してもよい。

なお、本実施の形態では、アプリケーション６３０のプッシュ通知でメッセージを伝えるようにしてもよい。プッシュ通知とは、Ａｎｄｒｏｉｄ／ｉＯＳなどのスマートフォンのアプリケーションのプラットフォームで利用可能な機能であり、アプリケーションがバックグラウンドや終了していても、サーバからのプッシュにより該当アプリケーションのメッセージとして、表示できる機能である。この機能を利用することで、例えば、ユーザがお出かけするタイミングで、「いつもどおりの３時間以上のお出かけなら切った方が良い」といったアドバイスを行なうことができ、ユーザが設定を忘れることなく制御することができる。

なお、本実施の形態では、言葉による省エネメッセージを説明したが、図２１に示すようなグラフ表示を行なうように構成しても良い。図２１の例では、実線で示される現在時刻のラインよりも左側は履歴データを示し、右側は予測結果を示している。室温・外気温・設定温度・電力量（もしくは電気代）などの情報を表示し、この場合の境界運転停止時間を点線で表すような構成にするとユーザは分かりやすい。また、そのグラフの下にあるように在・不在履歴を元にした通常在時間帯と不在時間帯を表示するようにすると、境界運転停止時間との関係が分かりやすい。また、設定温度などを下げたり上げたりした場合に、予測結果を計算し直して表示するようにすると、ユーザはどのように制御すると省エネにできるかを直感的にわかりやすくなる。

なお、本実施の形態においては、室内の温度を元に、省エネ性の判断を行ったが、湿度の情報を考慮するように構成してもよい。例えば、人の快適性の指数として不快指数があり、この指数は室温と湿度によって決定される。部屋の室温に加えて、湿度も予測して、入室時刻での不快指数を同じにすることを目標値として、不在時連続運転が省エネか、不在時断続運転が省エネかの予測を行なうように構成しても良い。

以上が本実施の形態における空調制御システムの説明である。

上記態様において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記態様において説明された技術が実現される類型はこれに限られるものでない。

（サービスの類型１：自社データセンタ型）
図２は、サービスの類型１（自社データセンタ型）を示す。本類型は、サービスプロバイダ１２０がグループ１００から情報を取得し、ユーザに対してサービスを提供する類型である。本類型では、サービスプロバイダ１２０が、データセンタ運営会社の機能を有している。即ち、サービスプロバイダが、ビッグデータの管理をするクラウドサーバ１１１を保有している。従って、データセンタ運営会社は存在しない。

本類型では、サービスプロバイダ１２０は、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、ＯＳ（２０２）及びアプリケーション（２０１）を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

（サービスの類型２：ＩａａＳ利用型）
図３は、サービスの類型２（ＩａａＳ利用型）を示す。ここでＩａａＳとはインフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築および稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０がデータセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、ＯＳ（２０２）及びアプリケーション（２０１）を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

（サービスの類型３：ＰａａＳ利用型）
図４は、サービスの類型３（ＰａａＳ利用型）を示す。ここでＰａａＳとはプラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、ＯＳ（２０２）を管理し、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、アプリケーション（２０１）を管理する。サービスプロバイダ１２０は、データセンタ運営会社が管理するＯＳ（２０２）及びサービスプロバイダ１２０が管理するアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

（サービスの類型４：ＳａａＳ利用型）
図５は、サービスの類型４（ＳａａＳ利用型）を示す。ここでＳａａＳとはソフトウェア・アズ・ア・サービスの略である。例えばデータセンタ（クラウドサーバ）を保有しているプラットフォーム提供者が提供するアプリケーションを、データセンタ（クラウドサーバ）を保有していない会社・個人（利用者）がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。

本類型では、データセンタ運営会社１１０は、アプリケーション（２０１）を管理し、ＯＳ（２０２）を管理し、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

以上いずれの類型においても、サービスプロバイダ１２０がサービス提供行為を行ったものとする。また例えば、サービスプロバイダ若しくはデータセンタ運営会社は、ＯＳ、アプリケーション若しくはビックデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。

本発明の一態様に係る空調制御システムは、空調機の制御を省エネ効率高く行うことが可能となる。故に本発明にかかる空調制御システムは、生活家電産業において高い利用可能性を持つ。

１０、２０ ユーザ
１００ グループ
１０１ 機器
１０２ ホームゲートウェイ
１１０ データセンタ運営会社
１１１ クラウドサーバ
１２０ サービスプロバイダ
１２１ サーバ
２０１ アプリケーション
２０２ ＯＳ
２０３ データセンタ（クラウドサーバ）
２０４ ユーザ
６１０ 空調機
６１１ センサー情報取得手段
６１２ 制御情報取得手段
６１３ 空調制御手段
６２０ クラウドサービス
６２１ センサー情報格納手段
６２２ 制御情報格納手段
６２３ 室内環境・電力量予測手段
６２４ 空調設定手段
６２５ インターフェース
６２６ 履歴ＤＢ
６２７ 外環境予測手段
６３０ アプリケーション

Claims (1)

1. 空調機を制御し、室内の空調を制御する空調制御システムであって、
   前記空調機のセンサーから取得される室内温度やエアコン稼動時の電力量・人の在不在情報を蓄積するセンサーデータ蓄積手段と、
   前記空調機から取得される空調の設定情報を蓄積する空調情報データ蓄積手段と、
   前記環境データ蓄積手段と前記空調情報データ蓄積手段によって蓄積されたデータを用いて、
   前記空調機の設定に対して室温変化・電力量を予測する室内環境・電力量予測手段と、
   前記空調機の設定を変更する指示を行うアプリケーションから構成され、
   前記アプリケーションは、前記在不在情報を用いて、該当の空調機が存在している部屋において、
   人が通常いる通常在時間帯と人が不在にしている通常不在時間帯を算出し、
   現在時刻から次に通常在時間帯が始まる時刻までの時間を運転停止時間とし、
   前記室内環境・電力量予測手段を用いて、
   現在の運転設定と同じ設定で運転を継続した場合の連続運転電力量と
   運転を停止し、前記運転停止時間後に運転を開始して現在の室温に戻すための断続運転電力量を算出し、
   前記連続運転電力量と前記断続運転電力量の比較結果を表示することを特徴とする空調制御システム。

Images