《第1の実施形態》
以下、機器制御ルール運用システムの第1の実施形態について、図1〜図20に基づいて詳細に説明する。
図1(a)は、機器制御ルール運用システム100の構成を概略的に示す図である。この制御ルール運用システム100は、一般家庭などに設置される複数の宅内装置70と、データセンタなどに設置される制御用デバイスの決定装置としての機器制御ルール運用サーバ10と、を備える。これら宅内装置70と機器制御ルール運用サーバ10は、ネットワーク80を介して接続されている。また、機器制御ルール運用サーバ10はインターネット等を介してWebサーバと接続されており、当該Webサーバから情報(例えば、アメダスのデータ)を取得することができるようになっている。
図1(b)には、機器制御ルール運用サーバ10のハードウェア構成が示されている。この図1(b)に示すように、機器制御ルール運用サーバ10は、CPU90、ROM92、RAM94、記憶部(ここではHDD(Hard Disk Drive))96、ネットワークインタフェース97、入出力装置93、及び可搬型記憶媒体用ドライブ99等を備えている。これら機器制御ルール運用サーバ10の構成各部は、バス98に接続されている。機器制御ルール運用サーバ10では、ROM92あるいはHDD96に格納されているプログラム(制御用デバイスの決定プログラム)、或いは可搬型記憶媒体用ドライブ99が可搬型記憶媒体91から読み取ったプログラム(制御用デバイスの決定プログラム)をCPU90が実行することにより、図2の各部の機能が実現される。なお、機器制御ルール運用サーバ10は、ネットワークインタフェース97及びネットワーク(インターネットなど)を介して、宅内装置70やWebサーバと接続されている。
なお、宅内装置70も、図1(b)の機器制御ルール運用サーバ10と同様のハードウェア構成を有しているものとする(ただし、可搬型記憶媒体用ドライブ99など一部構成は省略されていてもよい)。宅内装置70においてもCPUがプログラムを実行することにより、図2に示すデータ収集部72としての機能が実現されている。
図2のデータ収集部72は、収集ルールデータベース(以下、「データベース」を「DB」と表記する)74に基づいて、宅内装置70に宅内ネットワークなどを介して接続された機器やセンサからデータを収集する。ここで、宅内装置70に接続される機器には、エアコン、照明、テレビなどの機器が含まれる。また、宅内装置70に接続されるセンサには、温度センサ、照度センサ、降雨センサなどのセンサが含まれる。収集ルールDB74には、図4に示すような収集ルールが格納されている。なお、収集ルールの具体的内容については後述する。また、本実施形態では、宅内装置70に接続された機器及びセンサを纏めて「デバイス」と呼ぶものとする。
図2に戻り、機器制御ルール運用サーバ10においては、CPU90がプログラムを実行することにより、収集部、推定部、探索部としてのデバイス配置推定部12、取得部としての利用データ分析部14、特定部、決定部、信頼度設定部としての利用データ提供元探索部16、の各機能が実現されている。
デバイス配置推定部12は、デバイスの動作の変化(例えば電源ON,OFF)後にデバイスから出力された出力データを受信する。また、デバイス配置推定部12は、受信した出力データに基づいて、デバイスの動作の変化に応じて変化する他のデバイスを抽出し、動作が変化したデバイスと他のデバイスとを同一空間にあると推定してデバイス配置DB22に登録する。なお、動作が変化したデバイスと、他のデバイスとを同空間にあると推定するのは、他のデバイスは、動作の変化したデバイスの動作による影響を受けていることから、両デバイスは同一空間内に存在していると考えるのが妥当だからである。例えば、エアコンの動作に応じて室温センサの値が変化する場合には、それらエアコンと室温センサが同一空間に存在していると推定することができる。また、照明の点灯によって照度センサの値が変化する場合には、それら照明と照度センサが同一空間に存在していると推定することができる。
利用データ分析部14は、機器制御ルールDB23内で定義されている機器制御ルール(図12参照)の制御実行条件(if)内のデータを抽出する。また、利用データ分析部14は、制御実行条件(if)内のデータとしてありうる値をデータ値DB24より抽出し、制御実行条件(if)内のデータと対応付けて利用データDB25に保存し、管理する。
利用データ提供元探索部16は、機器制御ルールの制御内容(制御対象)(then)において定義されているデバイス種別を抽出し、当該デバイス種別と同一種別のデバイスが存在している空間を特定する。また、利用データ提供元探索部16は、デバイス配置DB22に基づいて、機器制御ルール(図12参照)の制御実行条件(if)内のデータを提供可能なデバイス(制御実行条件(if)に含まれるデバイス種別と同一種別のデバイス)を、特定した空間に近い側から探索・抽出する。そして、利用データ提供元探索部16は、抽出したデバイスを機器制御ルールの運用に用いるデバイスとして決定する。
なお、図2では、機器制御ルール運用サーバ10のHDD96等に格納される各種データベースやテーブルも図示している。各種データベースやテーブルには、図2に示すように、チェックデバイスリスト20、データリスト21、デバイス配置DB22、機器制御ルールDB23、データ値DB24、利用データDB25、及び確信度テーブル(以下、「テーブル」を「TBL」と表記する)26が含まれる。
チェックデバイスリスト20は、図8(a)、図9(a)に示すように、各宅ごと(宅内装置70ごと)に作成されるリストであり、例えば電源がONになったデバイスの「デバイス名」と、その日時を示す「ON Time」とが格納される。
データリスト21は、図8(b)、図9(b)に示すように、各宅ごと(宅内装置70ごと)に作成されるリストであり、データのプロパティ値(末尾の文字列)に数値を含むデータのみを格納する。
デバイス配置DB22は、図10(a)、図10(b)に示すように、各宅ごと(宅内装置70ごと)に作成されるデータベースである。このデバイス配置DB22には、同一の空間に存在していると推定される複数のデバイスの情報(デバイス名、タイムスタンプ、データの種別、各データ種別の出力しうる値など)が空間毎に纏めて格納される。
機器制御ルールDB23には、図12に示すような機器制御ルールが1又は複数格納される。機器制御ルールには、制御実行条件(if)と制御内容(then)が関連付けられている。図12には、空調消費電力削減サービスを提供するためのルールが示されている。図12のルールの概要は、「冷房時、外気温がエアコン設定温度より低ければ、エアコンを停めて、かつ窓を開けるようにユーザに推奨する/自動的に機器制御する」というものである。
データ値DB24は、図13に示すように、各デバイスの出力データの出力範囲や、各デバイスのありうる状態(以下、これらを「ありうる値」と呼ぶ)を定義するデータベースである。データ値DB24には、各デバイスのカタログ値をありうる値として登録しておいてもよいし、デバイスが宅内に設置されるたびにユーザ等がありうる値を手入力してもよい。また、データ値DB24では、ありうる値を、メーカ別に登録することとしてもよい。
利用データDB25は、機器制御ルールごとに、当該ルールの運用に利用するデバイスを揃えるために用いるデータベースである。利用データDB25は、図14、図16、図17に示すようなデータベースである。具体的には、利用データDB25には、機器制御ルールの運用に用いる利用データ、利用データのありうる値、利用データを取得するデバイス(利用デバイス)、利用するデータのプロパティ名、及び利用デバイスの確信度が格納される。
確信度TBL26には、図18に示すように、「空間距離」と「ありうる値」の組み合わせ別に、決定すべき確信度が定義されている。ここで、「確信度」とは、制御内容(制御対象)(then)の制御を行う際に満たすべき制御実施条件(if)を満足しているか否かを判断する際に用いるデータ(デバイス)の信頼度を意味する。
次に、上述した宅内装置70及び機器制御ルール運用サーバ10の各機能の処理について、詳細に説明する。
(データ収集部72の処理)
まず、図3のフローチャートに沿って、宅内装置70のデータ収集部72の処理について説明する。なお、図3の処理の前提として、制御対象となる機器や、制御ルール内に記述された条件を判定するために必要なデータを提供するセンサなどのデバイスは、宅内装置70に対して宅内ネットワーク等を介して予め接続されているものとする。なお、デバイスの中には、宅内ネットワークに直接接続できないデバイスもある。このようなデバイスは、ネットワーク接続のためのアダプタを介して、ネットワーク接続するようにしてもよい。
図3の処理では、まず、ステップS10において、データ収集部72が、宅内のデバイスからデータを収集する。ここで、データ収集部72は、収集ルールDB74に格納されているデバイス毎に定義されている収集ルール(図4参照)に基づいて、データを収集するものとする。例えば、センサ(温度センサや照度センサなど)の場合、データ収集部72は、定期的(10秒おき)にデータを収集するものとする。また、エアコンや照明であれば、データ収集部72は、通常、状態変化時(プロパティ名が「Operation Status」でプロパティ値が「ON」又は「OFF」になったとき)に収集する。また、データ収集部72は、エアコンや照明のプロパティ値が「ON」になった後は、内蔵する温度センサなどの出力データを定期的(10秒おき)に収集するものとする。なお、ステップS10では、データ収集部72は、例えば、特開2002−330135号公報に開示されているように、宅内ネットワーク上のデバイスの発見及びデバイス種別の判定を経て、各デバイスからデータ収集することができる。
図3に戻り、次のステップS12では、データ収集部72が、デバイス毎に、前回値と比較する。次いで、ステップS14では、データ収集部72が、前回値があったか否かを判断する。このステップS14の判断が肯定された場合には、ステップS16に移行する。ステップS16に移行した場合、データ収集部72は、前回値と同値であったか否かを判断する。ここでの判断が肯定された場合には、ステップS10に戻る。一方、ステップS16の判断が否定された場合、すなわち異なる値であった場合には、ステップS18に移行する。
ステップS18に移行すると、データ収集部72は、新データ(ステップS10で収集したデータ)を通知データ(図5、図6参照)として保存する。その後は、ステップS22に移行する。なお、ステップS14において前回値が無かった場合には、ここでの判断が否定され、ステップS20に移行する。そして、ステップS20では、データ収集部72が、デバイス名とデータを通知データとして保存し、ステップS22に移行する。
ステップS20を経て、又はステップS18を経てステップS22に移行すると、データ収集部72は、デバイス配置推定部12に通知データを通知する。その後は、ステップS10に戻る。
図5、図6には、通知データの一例として、Aさん宅の通知データと、Bさん宅の通知データとが示されている。通知データには、デバイス(エアコンや照明などの機器)の動作状態(ON、OFF)や動作モード、機器に内蔵された温度センサなどの出力データ、デバイス(降雨センサ、温度センサ、照度センサなど)の出力データが含まれる。
なお、図3の処理では、通知データが更新されるたびにデータ収集部72がデバイス配置推定部12に通知する場合について説明したが、これに限られるものではない。例えば、データ収集部72は、所定時間毎に(定期的に)デバイス配置推定部12に通知データを通知することとしてもよい。
(デバイス配置推定部12の処理)
次に、機器制御ルール運用サーバ10のデバイス配置推定部12による処理について、図7のフローチャートに沿って、その他図面を適宜参照しつつ説明する。なお、以下においては、データ収集部72からデバイス配置推定部12に対して、図5において矢印で示すデータが通知されるとともに、当該データの下側のデータが順次通知される場合を例に採り説明する。なお、前提として、図8(a)のチェックデバイスリストは空であるものとする。
図7の処理では、まず、ステップS30において、デバイス配置推定部12が、通知データ(例えば、図5)のデータを1つ受信する。ここでは、デバイス配置推定部12が、矢印で示す「08/01 18:00:05 照明S OperationStatus ON」を受信する。
次いで、ステップS32では、デバイス配置推定部12が、受信したデータのプロパティ名が「Operation Status」であり、プロパティ値が「ON」又は「OFF」であるか否かを判断する。ここでの判断が肯定されると、ステップS34に移行する。
ステップS34に移行した場合、デバイス配置推定部12は、データのプロパティ名が「Operation Status」であり、プロパティ値が「ON」であるか否かを判断する。ここでの判断が肯定されると、ステップS36に移行し、デバイス配置推定部12が、チェックデバイスリストに対する登録を行う。この場合、デバイス配置推定部12は、図8(a)に示すように、チェックデバイスリストに、デバイス名(照明S)を登録するとともに、データ(Operation Status ON)の出力日時(08/01 18:00:05)を「On Time」として登録する。その後は、ステップS30に戻る。
ステップS30に戻ると、デバイス配置推定部12は、図5の次のデータ「08/01 18:00:05 照明S IlluminancePercentage 100」を受信する。次いで、ステップS32では、デバイス配置推定部12が、受信したデータのプロパティ名が「Operation Status」であり、プロパティ値が「ON」又は「OFF」であるか否かを判断する。ここでは、ステップS32の判断は否定されるので、ステップS52に移行する。
ステップS52に移行すると、デバイス配置推定部12は、データのプロパティ値に数値が含まれているか否かを判断する。ここでは、データのプロパティ値に数値「100」が含まれているので、判断は肯定され、ステップS54に移行する。
ステップS54に移行すると、デバイス配置推定部12は、データリスト21への登録を行う。この場合、図8(b)において矢印で示すデータが、データリスト21に登録される。その後は、図7のステップS30に戻る。
ステップS30に戻ると、デバイス配置推定部12は、次のデータ「08/01 18:00:13 エアコンX OperationStatus ON」を受信する。この場合、ステップS32の判断が肯定されるとともに、ステップS34の判断も肯定される。そして、ステップS36において、デバイス配置推定部12は、チェックデバイスリストに対する登録を行う。この場合、デバイス配置推定部12は、図8(a)に示すように、チェックデバイスリストに、デバイス名(エアコンX)を登録するとともに、データの出力時刻(08/01 18:00:13)を「On Time」として登録する。その後は、ステップS30に戻る。
ステップS30に戻ると、デバイス配置推定部12は、次のデータ「08/01 18:00:13 エアコンX OperationModeStatus Cooling」を受信する。この場合、ステップS32の判断は否定され、かつ、プロパティ値に数値が含まれていないので、ステップS52の判断も否定され、ステップS56に移行する。
ステップS56では、デバイス配置推定部12が、データに「Found」が含まれているか否かを判断する。ここでの判断が否定されると、そのままステップS30に戻る。
なお、これ以降、デバイス配置推定部12が受信するデータは、図5に示すようにプロパティ値に数値を含むデータとなっている。したがって、デバイス配置推定部12は、ステップS32(否定)、ステップS52(肯定)、ステップS54の繰返しにより、プロパティ値に数値を含むデータをデータリストに繰返し登録する(図8(b))。
その後、上記と同様の処理を繰返し、ステップS30において、デバイス配置推定部12が、例えば、「エアコンX OperationStatus OFF」のデータを受信したとする。この場合、ステップS32(肯定)及びステップS34(否定)を経て、ステップS38に移行することになる。なお、以下においては、動作状態がOFFとなったデバイス名を「デバイス名(1)」と表記するものとする。
ステップS38に移行すると、デバイス配置推定部12は、ON Time(チェックデバイスリスト20の日時)からOFF Time(直近のデータの受信日時)までの間に数値が変化したデバイス名をデータリスト21から抽出・取得する。例えば、図8(b)のデータリスト21では、エアコンXのRoomMeasuredTempの値のみが変化しているので、デバイス名「エアコンX」が取得されることになる。なお、以下においては、ステップS38で取得したデバイス名を「デバイス名(2)」と表記するものとする。
次いで、ステップS40に移行すると、デバイス配置推定部12は、ステップS38で取得したデバイス名(2)の中に、動作状態がOFFであるデバイス名(1)と異なるものがあるか否かを判断する。ここでは、デバイス名(2)とデバイス名(1)とが同一であるので、ステップS40の判断は否定され、ステップS42に移行する。そして、ステップS42に移行すると、デバイス配置推定部12は、チェックデバイスリスト20からデバイス名(1)(=「エアコンX」)を削除し、ステップS30に戻る。なお、上記処理では、エアコンXの動作に対応して変化したデータがエアコンXに内蔵された温度センサの出力データのみであったため、同一空間内にエアコンX以外のデバイスがあることを推定できなかったことになる。
その後、例えば、ステップS30において、デバイス配置推定部12が、「照明S OperationStatus OFF」のデータを受信すると、ステップS32(肯定)及びステップS34(否定)を経て、ステップS38に移行する。なお、この場合のデバイス名(1)は「照明S」となる。
そして、ステップS38に移行すると、デバイス配置推定部12は、デバイス名(2)として、「エアコンX」を取得し、ステップS40に移行する。ステップS40では、デバイス名(2)の中に、デバイス名(1)と異なるものがあるか否かを判断するが、ここでは、デバイス名(2)とデバイス名(1)とが異なるので、ステップS40の判断が肯定され、ステップS44に移行する。
ステップS44では、デバイス配置推定部12が、デバイス名(1)と(2)の全ペア(ここでは1つのペア(エアコンXと照明S))が、デバイス配置DB22(図10(a)参照)の同一空間に既に存在しているか否かを判断する。ここでの判断が否定された場合、すなわち、図10(a)の「空間名(1)」のデータが存在していなかったような場合には、ステップS48に移行する。そして、ステップS48では、デバイス配置推定部12が、全ペア(ここでは1つのペア(エアコンXと照明S))を同一の空間名(空間名(1))とタイムスタンプを付加してデバイス配置DB22に登録する。
次のステップS50では、デバイス配置推定部12が、ON TimeからOFF Timeの間のデータ値の最小値と最大値をデバイス配置DB22に登録する。このステップS48とステップS50の登録が完了したときの状態が、図10(a)に示されている。なお、上記処理によると、照明Sの動作に対応して変化したデータがエアコンXに内蔵された温度センサの出力データであったため、同一空間内に照明SとエアコンXが存在していると推定できたことになる。
以上のように、デバイス配置DB22への登録が完了すると、ステップS42に移行し、デバイス配置推定部12は、チェックデバイスリスト20からデバイス名(1)=「照明S」を削除し、ステップS30に戻る。
なお、ステップS44の判断が肯定された場合、すなわち、デバイス配置DB21に既に同一ペアが登録されていた場合には、ステップS46に移行し、デバイス配置推定部12は、既存のデータのタイムスタンプを更新する。その後は、ステップS50に移行し、デバイス配置推定部12は、デバイス配置DB22のデータ値を更新(変化の最小値と最大値の範囲が、デバイス配置DB22に既に登録されているデータ値の最小値と最大値の範囲を超える場合には、超えた範囲を登録)し、ステップS42に移行する。この場合も、デバイス配置推定部12は、チェックデバイスリスト20からデバイス名(1)を削除し、ステップS30に戻る。
ところで、図6のBさん宅の通知データにおいて矢印で示す「08/01 18:00:30 降雨 RainDetectionStatus Found」のようなデータを、デバイス配置推定部12が受信する場合もある。このような場合には、ステップS32(否定)、ステップS52(否定)を経て、ステップS56に移行する。そして、ステップS56では、デバイス配置推定部12が、プロパティ値に「Found」を含むか否かの判断を行う。ここでの判断が肯定されると、ステップS58に移行し、デバイス配置推定部12は、チェックデバイスリスト20(図9(a)参照)に「降雨」が存在しているか否かを判断する。ここでの判断が否定された場合には、ステップS60において、チェックデバイスリスト20に新たに「降雨」を登録し、ステップS30に戻る。一方、ステップS58の判断が肯定された場合には、ステップS62に移行する。
ステップS62に移行すると、デバイス配置推定部12は、ON Timeから最新時刻(データ受信日時)までの間に変化したデバイス名をデータリストから取得する。
次いで、ステップS64では、デバイス配置推定部12が、最新時刻を「ON Time」としてチェックデバイスリスト20に登録(更新)する。その後は、ステップS40以降の処理が上述したのと同様に実行されることになる。
なお、Bさん宅の通知データ(図6参照)では、デバイス名(1)が「エアコンX」のときに、デバイス名(2)として「エアコンX」、「照明S」、「湿度B」が取得される(ステップS38)。このような場合、ステップS40では、デバイス名(2)にデバイス名(1)と異なるものが存在するので、判断が肯定され、ステップS44に移行する。そして、ステップS44では、デバイス配置推定部12は、デバイス名(1)と(2)の全ペアが同一空間に既に存在しているか否かを判断する。ここでの判断が肯定された場合には、ステップS46において上記と同様の処理を行う。一方、ステップS44の判断が否定された場合には、デバイス配置推定部12は、全ペア(すなわち、デバイス名(1)、(2)の和集合)をデバイス配置DB22に登録する(ステップS48)。また、デバイス配置推定部12は、デバイス配置DB22のデータ値の最小値と最大値を登録する(ステップS50)。このような処理を行うことにより、図10(b)の空間名(1)に示すように、3種類のデバイスを同一空間内に存在するデバイスとして登録することができる。
以上の処理をデバイス配置推定部12が実行することで、デバイス配置DB22には、同一空間内に存在するデバイスを、適宜、登録・更新することが可能となる。なお、図10(b)では、Bさん宅の1つの空間に、「エアコンX」、「照明S」、「湿度B」の各デバイスが存在し、これとは異なる空間(この場合、戸外)に「降雨」、「湿度A」の各デバイスが存在していることを示している。
(利用データ分析部14の処理)
次に、利用データ分析部14の処理について、図11のフローチャートに沿って、その他図面を適宜参照しつつ、詳細に説明する。この図11の処理は、ユーザが機器制御ルールの運用サービスの契約を締結するなどのトリガがあった時点から実行される処理である。
図11の処理では、まず、ステップS70において、利用データ分析部14が、機器制御ルールDB23から機器制御ルールを1つ抽出し(例えば、図12)、その機器制御ルールで定義されている制御実行条件(if)内のデータを抽出する。以下においては、ステップS70において抽出されたデータを、「データ(3)」と表記する。なお、図12の例では、制御実行条件(if)内のデータ(3)として、「エアコン OperationStatus」、「エアコン OperationModeStatus」、「温度(屋外) MeasuredTemp」、「降雨 RainDetectionStatus」が抽出される。
次いで、ステップS72では、利用データ分析部14が、抽出したデータのありうる値をデータ値DB(図13参照)から抽出する。以下においては、ステップS72で抽出されたありうる値を「値(4)」と表記する。
次いで、ステップS74では、利用データ分析部14が、データ(3)と値(4)を対応付けて利用データDB25に登録する。このステップS74の登録が完了した後の利用データDB25の状態が、図14に示されている。
次いで、ステップS76では、利用データ分析部14が、利用データ提供元探索部16に探索通知を行い、ステップS70に戻る。以降、ステップS70〜ステップS76の処理を繰り返すことで、各機器制御ルールに対応する利用データDB25の登録処理が順次行われることになる。
(利用データ提供元探索部16の処理(探索通知受信時又は新規デバイス出現時))
次に、利用データ提供元探索部16が実行する処理について、図15のフローチャートに沿って説明する。なお、図15の処理は、利用データ分析部14から探索通知を受信したとき、又は宅内装置70に新規のデバイスが接続されたときに、利用データ提供元探索部16により実行される処理である。
図15の処理では、まず、ステップS80において、利用データ提供元探索部16が、仮利用データDBを作成する。ここで、「仮利用データDB」とは、図14の利用データDB25を複製したデータベースを意味する。
次いで、ステップS82では、利用データ提供元探索部16は、機器制御ルール内の制御内容(then)内のデバイス(デバイス種別)を抽出する。ここで抽出されたデバイスを、以下においては「デバイス(5)」と表記する。なお、図12の機器制御ルールからは、デバイス(5)として「エアコンX」と「窓」が抽出される。
次いで、ステップS84では、利用データ提供元探索部16は、抽出したデバイス種別(デバイス(5))と同一(同一種別)のデバイスが存在している空間を特定する。この場合、例えば、図10(a)のAさん宅の空間名(1)の空間が特定されたものとする。そして、利用データ提供元探索部16は、特定された空間と同一建屋内(Aさん宅内)にあるデバイスをデバイス配置DB22(図10)から抽出する。ここでは、例えば、Aさん宅内に存在する「エアコンX」及び「照明S」が抽出される。なお、ここで抽出されるデバイスを、以下においては、デバイス(6)と表記するものとする。
次いで、ステップS86では、利用データ提供元探索部16が、デバイス(6)と仮利用データDBのアンド(和集合)を取る。すなわち、仮利用データDBに含まれるデバイス(デバイス種別)と同一の種別のデバイスを抽出する。ここでは、「エアコンX」が、アンドが取れたデバイスとなる。
次いで、ステップS88では、利用データ提供元探索部16が、アンドが取れたデバイス(及びこれに対応するデータ)の確信度を決定する。この場合、利用データ提供元探索部16は、図18に示す確信度TBL26を参照して、空間距離とありうる値に基づいて、確信度を決定する。ここで、「空間距離」には、図18に示すように、「同一空間」、「同一建屋内の異なる空間」、「一定距離以内の異なる建屋内」、「Webデータ」などがある。Aさん宅の例では、「エアコンX」及び「照明S」の空間距離は、ともに「同一空間」となる。また、「ありうる値」は、仮利用データDBにおいてありうる値として定義されている値の範囲と、デバイス配置DB22のデータ値の範囲とから定まり、「範囲内」、「一部範囲外」、「全て範囲外」のいずれかが選択される。例えば、上述した例において、「ありうる値」が「範囲内」であった場合には、確信度が「5」に決定される。図16では、「エアコンX」に対し、確信度=「5」が決定された例が示されている。
図15に戻り、次のステップS90では、利用データ提供元探索部16が、仮利用データDBの利用データに対応する利用デバイスが全て揃ったか否かを判断する。図16のように全ての利用デバイスが揃っていない場合には、ステップS90の判断は否定され、ステップS92に移行する。
ステップS92に移行すると、利用データ提供元探索部16は、一定距離以内の他の家(建屋)にデバイスがあるか否かを判断する。なお、利用データ提供元探索部16は、Aさん宅やBさん宅の位置(住所)を、予め分かっているものとする(図10(a)の住所A、図10(b)の住所B参照)。そして、利用データ提供元探索部16は、各宅の距離を地図データなどを用いて算出するものとする。このステップS92の判断が、肯定された場合には、ステップS94に移行し、利用データ提供元探索部16は、一定距離以内のデバイスを仮利用データDBに登録する。そして、利用データ提供元探索部16は、ステップS96において、登録したデバイスの確信度を、確信度TBL26を参照して決定する。その後は、ステップS90に戻り、利用データ提供元探索部16は、再度、仮利用データDBの利用デバイスが全て揃ったか否かを判断する。ここでの判断が否定された場合には、ステップS92に移行する。
なお、ステップS92の判断が否定された場合には、ステップS98に移行する。ステップS98では、利用データ提供元探索部16は、Web上にAさん宅が含まれる地域の外気温のデータや降雨のデータ(アメダス等のデータ)があるか否かを判断する。ここでの判断が肯定された場合には、ステップS100に移行し、利用データ提供元探索部16は、Webデータを登録する。なお、ステップS100では、利用データ提供元探索部16は、機器制御ルールの運用に用いるデバイスとして、Webサーバを決定したともいえる。そして、利用データ提供元探索部16は、ステップS102において、登録したデータ(Webデータ)の確信度を、確信度TBL26を参照して決定する。その後はステップS90に戻る。
なお、ステップS98の判断が否定された場合には、仮利用データDBの全ての利用デバイスが揃わなかったことを意味する。したがって、この場合には、利用データ提供元探索部16は、ステップS104において、宅内装置70に対してサービス提供をすることができない旨の通知を行い、図15の全処理を終了する。
一方、ステップS90の判断が肯定された場合、すなわち、仮利用データDBの全利用デバイスが揃った場合には、ステップS105に移行する。ステップS105では、利用データ提供元探索部16が、仮利用データDBと利用データDB25(元々あった場合)とで各デバイスの確信度を比較し、確信度の高いデバイスを利用するように、利用データDB25を上書きする。なお、上記では、ステップS105において、確信度に基づいて利用デバイスの上書きを行う場合について説明したが、これに限られるものではない。例えば、利用データ分析部14からの探索通知があった場合には、利用データDB25を全て書き換えるような運用とすることもできる。この場合には、ステップS105の処理に代えて、利用データDB25を仮利用データDBで置き換える処理を行うこととすればよい。
その後、ステップS105の処理が終了すると、ステップS106に移行し、利用データ提供元探索部16は、サービス提供(機器制御ルールの運用サービスの提供)を開始し、図15の全処理を終了する。なお、図16に示すAさん宅のように、利用データDB25の全利用デバイスが揃わなかった場合には、サービス提供不可能通知が宅内装置70に対して出される。一方、図17に示すBさん宅のように、利用データDB25の全利用デバイスが揃った場合には、サービス提供が開始されることになる。
なお、図15の処理は、機器制御ルールDB23に含まれる全ての機器制御ルールに対して行われる処理である。
以上のように、図15の処理を行うことで、機器制御ルールの運用に必要なデバイス(機器、センサ、Webサーバ)を、制御内容(then)に含まれるデバイスが存在する空間に近い側から順に自動で抽出することができる。これにより、機器制御ルールの運用に適切なデバイスを簡易に抽出することが可能である。また、機器制御ルールの運用に必要なデバイスが揃った段階で、各宅のデバイス(エアコンなどの機器)の制御を適切に行うことが可能となる。
(デバイス配置推定部12の処理(デバイス削除処理))
次に、図19に基づいて、デバイス配置推定部12による、デバイス削除処理について説明する。ここで、デバイス配置DB22のある空間に登録されているデバイスであっても、時間の経過に伴ってその空間内には存在しなくなっている場合もある。図19の処理では、このような既に空間内に存在していないデバイスをデバイス配置DB22から削除するための処理である。
図19の処理では、まず、ステップS202において、デバイス配置推定部12が、デバイス配置DB22に一定期間を経過したタイムスタンプが有るか否かを判断する。ここでの判断が否定された場合には、所定時間経過後に再度ステップS202を実行する。一方、ステップS202の判断が肯定された場合には、ステップS204に移行する。
ステップS204に移行すると、デバイス配置推定部12は、過去の通知データの中から、ステップS202においてタイムスタンプが一定時間を経過したと判断されたデバイスの最新データを抽出する。
次いで、ステップS206では、デバイス配置推定部12が、最新データのタイムスタンプが一定期間経過しているか否かを判断する。ここでの判断が否定された場合には、ステップS202に戻るが、肯定された場合には、ステップS208に移行する。
ステップS208に移行すると、デバイス配置推定部12は、デバイス配置DB22からタイムスタンプが一定時間経過しているデバイスを削除する。なお、削除したデバイスが存在していた空間内にデバイスが1つのみ残るような場合には、デバイス配置推定部12は、その空間も削除する。
次いで、ステップS210では、デバイス配置推定部12が、利用データ提供元探索部16に削除デバイスを通知する。その後は、ステップS202に戻り、上述した処理を繰り返す。
以上の処理を行うことで、デバイス配置推定部12は、既に空間内に存在していない可能性の高いデバイスをデバイス配置DB22から削除することが可能である。
(利用データ提供元探索部16の処理(デバイス削除時))
次に、利用データ提供元探索部16が実行するデバイス削除時の処理について、図20のフローチャートに沿って説明する。なお、図20の処理は、前述した図19のステップS210において、デバイス配置推定部12から利用データ提供元探索部16に対して削除デバイスの通知が行われたタイミングで実行される処理である。
なお、図20の処理では、図15とほぼ同様の処理が行われるが、図15のステップS80に代えて、ステップS80’が実行される点、仮利用データDBを用いない点、及び図15のステップS105が省略されている点が異なる。以下、これらの点を中心に図20の処理について説明する。
図20の処理では、まず、ステップS80’において、利用データ提供元探索部16が、宅内装置70から削除通知されたデバイスを、利用データDB25から削除する。
なお、利用データ提供元探索部16は、ステップS80’において削除されたデバイスに代わるデバイスを利用データDB25に補填するために、図20のステップS82以降の処理を実行する。この場合、利用データ提供元探索部16は、同一建屋内→一定距離以内の異なる建屋内→Webデータ、の順に削除されたデバイスに代わるデバイスを探索する。この探索により、利用データDB25の全利用デバイスが揃えば、機器制御ルールの運用が開始されることになる(ステップS106)。一方、探索により全利用デバイスが揃わなければ、サービス提供不可能通知が、宅内装置70に対して通知される(ステップS104)。
これにより、デバイス削除時においても、削除されたデバイスの代わりになるデバイスを利用デバイスとして決定することで、機器制御ルールの運用サービスを継続して行うことが可能である。また、デバイス削除により機器制御ルールの運用ができなくなった場合にも、適切にサービス提供不可能通知を行うことができる。
以上、詳細に説明したように、本実施形態によると、デバイス配置推定部12が、複数種類のデバイスの出力データを受信し(ステップS30)、受信した出力データに基づいて、デバイスのうちの1つ(エアコンや照明などの機器)が所定状態(例えば、電源ONの状態やFoundの状態など)となっている間に出力データが変化した他のデバイスを抽出し(ステップS38)、所定状態であったデバイスと他のデバイスとが同一空間に存在していると推定する(ステップS44〜S50)。そして、利用データ分析部14は、機器制御ルールから制御内容(制御対象)(then)のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する。更に利用データ提供元探索部16は、制御ルールの制御実行条件(if)を定義するデバイス種別と同一種別のデバイスを特定された空間に近い側から抽出し、制御ルールの運用に用いるデバイスとして決定する(図15の処理)。これにより、本実施形態では、人手やGPSなどの機器を用いることなく、同一空間に存在しているデバイスを推定できる。また、推定結果と機器制御ルールとを用い、制御対象のデバイスが存在する空間に近い側から機器制御ルールの運用に用いるデバイス(機器、センサあるいはWebサーバ)を決定することで、機器制御ルールの運用に用いるデバイスを適切かつ自動で決定することができる。
また、本実施形態では、機器制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、各デバイスが存在している空間と、制御内容(then)のデバイスが存在する空間との乖離度(図18における空間距離)、及び制御実行条件を定義するために必要なデバイスの機能と機器制御ルールの運用に用いるデバイスの機能との乖離度(図18のありうる値)に基づいて、各デバイスの出力データの信頼度(確信度)を定める。これにより、確信度の高いデバイスを優先的に利用した機器制御ルールの運用(ステップS105、S106)が可能となる。
また、本実施形態では、利用データDB25の全利用デバイスを揃えることができなかった場合に、利用データ提供元探索部16は、宅内装置70に対して、機器制御ルールの運用ができない旨の通知を行う。これにより、機器制御ルールの運用ができない場合に、ユーザはそのことを認知することが可能となる。
なお、上記第1の実施形態では、確信度を、図18に示す「空間距離」と「ありうる値」に基づいて決定することとしたが、これに限られるものではなく、いずれか一方に基づいて決定することとしてもよい。また、上記2つの要素に基づいて確信度を決定する場合に限らず、その他の要素に基づいて確信度を決定することとしてもよい。
なお、上記第1の実施形態では、同一建屋内のデバイスを同時に抽出することとしているが、これに限られるものではない。利用データ提供元探索部16は、まず同一空間のデバイスを抽出することとし、当該抽出によって全てのデバイスが抽出できなかった場合に、同一建屋内の異なる空間のデバイスを抽出することとしてもよい。
《第2の実施形態》
次に、第2の実施形態について、図21、図22に基づいて説明する。図21は、第2の実施形態に係るデバイス配置推定部12の処理(第1の実施形態における図7から変更した部分のみ)を示すフローチャートである。図21の処理では、図7のステップS44〜S50の代わりに、ステップS120〜S134の処理を実行する。
図21では、図7のステップS40が肯定された場合、すなわち、デバイス名(2)にデバイス名(1)と異なるデバイスが含まれている場合に、ステップS120が実行される。ステップS120では、デバイス配置推定部12が、デバイス名(1)と(2)の各ペアが同空間候補リストに既に存在しているか否かを判断する。ここで、同空間候補リストは、図22に示すようなリストであり、デバイス名(1)と(2)の組み合わせに対し、ペアとなった回数(ペア回数)を登録するためのリストである。
ステップS120の判断が否定された場合、すなわち、同空間候補リストにペアが存在していない場合には、ステップS122において、デバイス配置推定部12が、デバイス名(1)と(2)のペアを同空間候補リストに登録する。また、デバイス配置推定部12は、登録したペアのペア回数を1とする。一方、同空間候補リストにペアが既に存在していた場合には、ステップS120の判断が肯定され、ステップS124に移行する。
ステップS124に移行した場合、デバイス配置推定部12は、デバイス名(1)と(2)のペア回数に1を加算(+1)する。次いで、ステップS126では、デバイス名(1)と(2)のペア回数が、デバイス名(2)が含まれる他のペアにおけるペア回数よりも5以上多いか否かを判断する。ここでの判断が否定された場合には、ステップS42(図7)に移行する。一方、ステップS126の判断が肯定された場合(5以上であった場合)には、ステップS128に移行する。
ステップS128では、デバイス配置推定部12は、デバイス名(2)がデバイス配置DB22に既に存在しているか否かを判断する。ここでの判断が肯定された場合には、ステップS130に移行し、デバイス名(2)が既に存在している空間内に、デバイス名(1)を登録する。その後は、ステップS42(図7)に移行する。一方、ステップS128の判断が否定されると、デバイス配置推定部12は、図7のステップS48、S50と同様、デバイス配置DB22に対し、デバイス名(1)、(2)が存在する新たな空間を登録する(S132、S134)。その後は、ステップS42に移行する。
その他の処理は、第1の実施形態と同様である。
以上説明したように、本第2の実施形態によると、同空間候補リストのペア回数が所定の閾値(上記ではデバイス名(2)が含まれる他のペアのペア回数よりも5以上多い値)を超えた場合に、デバイス配置DB22にペアを登録する。これにより、本第2の実施形態では、デバイスが存在する空間を正確に推定することができる。
なお、上記第2の実施形態では、所定の閾値として、デバイス名(2)が含まれる他のペアのペア回数よりも所定数(例えば5)以上多い値を採用した場合について説明したが、これに限られるものではない。所定の閾値としては、所定値(他のペアを考慮しない値)を用いることとしてもよい。
《第3の実施形態》
次に、第3の実施形態について、図23、図24に基づいて説明する。図23は、第3の実施形態に係るデバイス配置推定部12の処理(第1の実施形態(図7)から変更した部分を太線で示している)を示すフローチャートである。より具体的には、図23の処理では、図7のステップS38、S62の処理の代わりにステップS38’、S62’の処理を実行するとともに、ステップS50の処理の後に、ステップS140、S142の処理を実行する。
ステップS38’(又はステップS62’)では、デバイス配置推定部12は、ON TimeからOFF Time(又は最新時刻)までの間に変化したデバイス名のみならず、変化開始時刻も取得する。
そして、ステップS40、S44〜S50を経て、デバイス配置推定部12により、ペアがデバイス配置DB22に登録(又はタイムスタンプの更新)されると、ステップS140に移行する。
ステップS140では、デバイス配置推定部12は、ON Timeから変化開始時刻までの経過時間と、図24(a)に示す追随性−付加確信度対応リストと、を照合して、付加確信度を取得する。この場合、ON Time(デバイス名(1)がチェックデバイスリストに登録された時刻)から、デバイス名(2)が変化するまでの時間が短いほど(デバイス名(1)の動作に対するデバイス名(2)の反応が早いほど)、付加確信度は高くなる。
次いで、ステップS142では、デバイス配置推定部12が、デバイス名(1)と(2)のペアと、付加確信度と、を対応付けて図24(b)に示すペア−付加確信度対応リストに登録する。
その他のデバイス配置推定部12の処理は、第1の実施形態と同様である。なお、利用データ提供元探索部16は、確信度を決定する際(図15のステップS88、S96、S102)には、図18の確信度TBL26で求められた確信度に、ペア−付加確信度対応リストの値を加算するものとする。
ここで、デバイスが電源ONにされた後、出力データの変化が早く現れた他のデバイスは、電源ONとなっているデバイスと同一空間に存在している可能性が高いと考えられる。したがって、本第3の実施形態では、利用データ提供元探索部16が、ペア−付加確信度対応リストの値を用いて確信度を決定することで、確信度を適切に決定することが可能である。
《第4の実施形態》
次に、第4の実施形態について、図25〜図27に基づいて説明する。図25(a)は、第4の実施形態に係るデバイス配置推定部12の処理(第1の実施形態の図7の処理と並列処理される処理)である。
図25(a)の処理では、まず、ステップS150において、デバイス配置推定部12が、宅内ネットワーク内のデバイス探索を行う。このデバイス探索により1つのデバイスを発見した段階で、次のステップS152に移行する。
次のステップS152では、デバイス配置推定部12が、発見したデバイスが、デバイスリスト内にあるか否かを判定する。ここで、デバイスリストは、図25(b)に示すように、発見したデバイス名と、発見日時が登録されるリストである。このデバイスリストに発見したデバイスがあった場合には、デバイス配置推定部12は、ステップS153において、発見日時を更新した後、ステップS150に戻る。一方、デバイスリストに発見したデバイスが無かった場合には、デバイス配置推定部12は、デバイスリストに、デバイス名と発見日時を登録する。その後は、ステップS150に戻り、デバイス1つずつに対して上記処理を繰り返す。
これに対し、利用データ提供元探索部16では、図26のような処理を実行する。なお、図26の処理は、上述した第1の実施形態の図15の処理のステップS88、S96、S102に代えて、ステップS88’、S96’、S102’を実行する点が異なっている。
図26のステップS88’では、利用データ提供元探索部16は、確信度を決定する際に、確信度TBL26で定まる確信度に、付加確信度を加算する。ここで、付加確信度は、図27に示す新規性−付加確信度対応リストに基づいて決定される。この新規性−付加確信度対応リストでは、図25(b)のデバイスリストの発見日時が現在に近いほど(最近発見されたデバイスであるほど)付加確信度は高くなる。したがって、存在していることを確認した時期が近いデバイスほど、高い付加確信度が、確信度TBL26で定まる確信度に加算されることになる。
なお、ステップS96’、S102’においても、利用データ提供元探索部16は、上記ステップS88’と同様の方法により確信度を決定する。なお、本実施形態では、図20の処理においても、上記と同様の方法により確信度を決定するものとする。
以上説明したように、本第4の実施形態によると、デバイス探索の結果、デバイスが発見された日時に基づいて、確信度を決定するので、確信度を適切に決定することができる。
《第5の実施形態》
次に、第5の実施形態について、図28に基づいて説明する。図28は、第5の実施形態に係る利用データ提供元探索部16の処理を示すフローチャートである。この図28の処理では、第1の実施形態の処理(図15)の処理のステップS84とS86の間に、ステップS85A、85Bの処理を実行する。
ステップS85Aでは、利用データ提供元探索部16は、ステップS84において抽出されたデバイス(6)の中に、同一種類のデバイスが複数あるか否かを判断する。ここでの判断が否定された場合、すなわち、デバイス(6)の中に同一種類のデバイスが1つのみ含まれていた場合には、ステップS86に直接移行する。
一方、ステップS85Aの判断が肯定された場合には、ステップS85Bに移行する。ステップS85Bでは、利用データ提供元探索部16は、同一種類の複数のデバイスのうち、データ値の精度が細かいデバイスを選択する。
ここで、「データ値の精度が細かい」とは、例えば、数値の小数点以下の桁数が多いことを意味するものとする。ただし、これに限られるものではなく、最小値と最大値の間の範囲が大きい場合を「データ値の精度が細かい」としてもよい。また、データ値が文字列の場合には、データ値の個数が多い場合を、「データ値の精度が細かい」場合としてもよい。更に、例えば、デバイスメーカの信頼度(株式評価やホームページアクセス数に基づく換算値等)を利用してデータ値の精度が細かいデバイスを選択してもよい。
なお、ステップS86以降の処理では、利用データ提供元探索部16は、ステップS85Bで選択したデバイスをデバイス(6)として、処理を実行する。
以上のように、本第5の実施形態によると、同一種別のデバイスが複数抽出された場合に、データ値の精度が細かいデバイスを選択することとしているので、機器制御ルールの運用を適切に行うことが可能となる。
なお、上記第1〜第5の実施形態は、適宜組み合わせることが可能である。例えば、利用データ提供元探索部16は、第3の実施形態の付加確信度と、第4の実施形態の付加確信度と、の両方を考慮して確信度を決定するなどしてもよい。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD(Digital Versatile Disc)、CD−ROM(Compact Disc Read Only Memory)などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
なお、以上の説明に関して更に以下の付記を開示する。
(付記1) 複数種類のデバイスの出力データを収集する収集工程と、
前記収集工程で収集した出力データに基づいて、前記複数種類のデバイスのうちの1つが所定状態となっている間に出力データが変化した他のデバイスを抽出し、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定する推定工程と、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得する取得工程と、
前記制御ルールから、前記制御対象のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する特定工程と、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを前記特定工程で特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する決定工程と、をコンピュータが実行することを特徴とする制御用デバイスの決定方法。
(付記2) 前記推定工程では、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記1に記載の制御用デバイスの決定方法。
(付記3) 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める信頼度設定工程を、前記コンピュータが更に実行することを特徴とする付記1又は2に記載の制御用デバイスの決定方法。
(付記4) 前記信頼度設定工程では、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記3に記載の制御用デバイスの決定方法。
(付記5) 前記各デバイスの存在を探索する探索工程を前記コンピュータが更に実行し、
前記信頼度設定工程では、前記探索工程で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記3又は4に記載の制御用デバイスの決定方法。
(付記6) 前記決定工程では、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記1〜5のいずれかに記載の制御用デバイスの決定方法。
(付記7) 複数種類のデバイスの出力データを収集し、
収集した出力データに基づいて、前記複数種類のデバイスのうちの1つが所定状態になっている間に出力データが変化した他のデバイスを抽出するとともに、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定し、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得し、
前記制御ルールから、前記制御対象のデバイス種別を抽出するとともに、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定し、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する、処理をコンピュータに実行させることを特徴とする制御用デバイスの決定プログラム。
(付記8) 前記推定する処理では、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記7に記載の制御用デバイスの決定プログラム。
(付記9) 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める処理を、前記コンピュータに更に実行させることを特徴とする付記7又は8に記載の制御用デバイスの決定プログラム。
(付記10) 前記信頼度を定める処理では、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記9に記載の制御用デバイスの決定プログラム。
(付記11) 前記各デバイスの存在を探索する処理を前記コンピュータが更に実行し、
前記信頼度を定める処理では、前記探索する処理で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記9又は10に記載の制御用デバイスの決定プログラム。
(付記12) 前記決定する処理では、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記7〜11のいずれかに記載の制御用デバイスの決定プログラム。
(付記13) 複数種類のデバイスの出力データを収集する収集部と、
前記収集部が収集した出力データに基づいて、前記複数種類のデバイスのうちの1つが所定状態となっている間に出力データが変化した他のデバイスを抽出し、前記所定状態であったデバイスと前記他のデバイスとが同一空間に存在していると推定する推定部と、
制御対象のデバイス種別と、制御実行条件を定義するデバイス種別とを関連付けた制御ルールを取得する取得部と、
前記制御ルールから、前記制御対象のデバイス種別を抽出し、当該制御対象のデバイス種別と同一種別のデバイスが存在する空間を特定する特定部と、
前記制御ルールの制御実行条件を定義するデバイス種別と同一種別のデバイスを前記特定部で特定された空間に近い側から抽出し、当該抽出したデバイスを前記制御ルールの運用に用いるデバイスとして決定する決定部と、を備える制御用デバイスの決定装置。
(付記14) 前記推定部は、前記抽出した回数が、所定の閾値を超えた場合に、前記所定状態のデバイスと前記他のデバイスとが同一空間に存在していると推定することを特徴とする付記13に記載の制御用デバイスの決定装置。
(付記15) 前記制御ルールの運用に用いるデバイスとして決定された各デバイスに対し、当該各デバイスが存在している空間と前記特定された空間との乖離度、及び前記制御実行条件を定義するために必要なデバイスの機能と前記制御ルールの運用に用いるデバイスの機能との乖離度、の少なくとも一方に基づいて、各デバイスの出力データの信頼度を定める信頼度設定部を、更に備える付記13又は14に記載の制御用デバイスの決定装置。
(付記16) 前記信頼度設定部は、前記デバイスが所定状態となった時点から、前記他のデバイスの出力データが変化するまでの時間に基づいて、前記信頼度を定めることを特徴とする付記15に記載の制御用デバイスの決定装置。
(付記17) 前記各デバイスの存在を探索する探索部を更に備え、
前記信頼度設定部は、前記探索部で各デバイスが発見された日時に基づいて、当該各デバイスの信頼度を定めることを特徴とする付記15又は16に記載の制御用デバイスの決定装置。
(付記18) 前記決定部は、前記制御ルールの運用に用いるデバイスの候補が複数あった場合には、出力データの精度が最も細かいデバイスを前記制御ルールの運用に用いるデバイスとして決定することを特徴とする付記13〜17のいずれかに記載の制御用デバイスの決定装置。