JP2022041339A - 選択プログラム、情報処理装置および制御方法 - Google Patents

選択プログラム、情報処理装置および制御方法 Download PDF

Info

Publication number
JP2022041339A
JP2022041339A JP2020146476A JP2020146476A JP2022041339A JP 2022041339 A JP2022041339 A JP 2022041339A JP 2020146476 A JP2020146476 A JP 2020146476A JP 2020146476 A JP2020146476 A JP 2020146476A JP 2022041339 A JP2022041339 A JP 2022041339A
Authority
JP
Japan
Prior art keywords
terminal
user
user state
unit
state transition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2020146476A
Other languages
English (en)
Inventor
勉 石田
Tsutomu Ishida
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020146476A priority Critical patent/JP2022041339A/ja
Priority to US17/359,837 priority patent/US20220067561A1/en
Publication of JP2022041339A publication Critical patent/JP2022041339A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/011—Arrangements for interaction with the human body, e.g. for user immersion in virtual reality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G06N5/022—Knowledge engineering; Knowledge acquisition
    • G06N5/025—Extracting rules from data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00—Computing arrangements based on specific mathematical models
    • G06N7/01—Probabilistic graphical models, e.g. probabilistic networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2614—HVAC, heating, ventillation, climate control
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/80—Homes; Buildings

Abstract

【課題】エッジ端末の処理能力やリソースに応じて処理の負荷を配分することを課題とする。【解決手段】情報処理装置は、端末に関する識別情報を前記端末から受信し、所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られる前記ユーザ状態推移の複数のパターンである複数のユーザ状態推移パターンから、前記識別情報に応じた数の１以上のユーザ状態推移パターンを選択し、前記１以上のユーザ状態推移パターンを前記端末に送信する、処理を実行させることを特徴とする。【選択図】図１３

Description

本発明は、選択プログラム、情報処理装置および制御方法に関する。
近年、ＩｏＴ（Internet of Things）の進展にともなって、エンドデバイスが生み出すデータの量が増加している。これに伴い、全てのデータの処理やエンドデバイスの制御を情報処理装置（例えばクラウドサーバ）側で行うことが難しくなってきている。そこで、情報処理装置だけでなくエンドデバイスも処理の一端を担うエッジコンピューティングに注目が集まっている。
エッジコンピューティングは、例えば、情報処理装置と、エンドデバイスである複数のエッジ端末とから構成される。情報処理装置と、エッジ端末の双方で分散処理を行うことで、情報処理装置の負荷の低減を図ることができる。
特開平８－０６１７４１号公報 特開２０１８－０３５９５７号公報 特開２０１５－１２２０５５号公報
情報処理装置に接続された複数のエッジ端末は、備えている処理能力や保持できる情報量（リソース）がそれぞれ異なる。このため、エッジコンピューティングにより処理を行う場合、情報処理装置にとって、各エッジ端末の処理能力やリソースに応じて処理の負荷を各エッジ端末に配分できることが好ましい。
本発明の１つの側面では、エッジ端末の処理能力やリソースに応じて処理の負荷を配分することが可能な選択プログラム、情報処理装置および制御方法を提供することを目的とする。
発明の一観点によれば、コンピュータに、端末に関する識別情報を前記端末から受信し、所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られる前記ユーザ状態推移の複数のパターンである複数のユーザ状態推移パターンから、前記識別情報に応じた数の１以上のユーザ状態推移パターンを選択し、前記１以上のユーザ状態推移パターンを前記端末に送信する、処理を実行させることを特徴とする。
一実施形態によれば、エッジ端末の処理能力やリソースに応じて処理の負荷を配分することが可能な、選択プログラム、情報処理装置および制御方法を提供することができる。
図１は、実施例１にかかるシステムの全体構成例を示す図である。 図２は、実施例１にかかるクラウドサーバ１００の機能構成を示す機能ブロック図である。 図３は、特徴ベクトルＤＢ１０３に記憶される情報の例を示す図である。 図４（ａ）は、クラスタ結果ＤＢ１０４に記憶される確率モデルの例である。また、図４（ｂ）は、クラスタ結果ＤＢ１０４に記憶される曜日が対応づけられた確率モデルの例である。 図５は、クラスタ数決定ＤＢ１０５に記憶される情報の例を示す図である。 図６は、制御基準ＤＢ１０６に記憶される情報の例を示す図である。 図７は、スケジュールＤＢ１０７に記憶される情報の例を示す図である。 図８は、実施例１にかかるエッジ端末２００の機能構成を示す機能ブロック図である。 図９（ａ）は、センサ値ＤＢ２０３に記憶される情報の例を示す図である。また、図９（ｂ）は、エッジ端末ログＤＢ２０４に記憶される情報の例を示す図である。 図１０は、実施例１にかかるユーザ端末３００の機能構成を示す機能ブロック図である。 図１１は、制御システムの処理の流れを示すシーケンス図である。 図１２は、確率モデルの選択する処理を説明する図である。 図１３は、ユーザ端末３００に表示される操作画面例を示す図である。 図１４は、クラウドサーバ１００における学習処理を説明する図である。 図１５は、学習データの特徴ベクトルについて説明する図である。 図１６は、確率モデルのクラスタを作成する処理を説明する図である。 図１７は、確率モデルのクラスタから在室確率を特定する処理を説明する図である。 図１８は、エッジ端末２００における予測処理を説明する図である。 図１９は、ユーザの在室確率を算出する処理を説明する図である。 図２０は、ハードウェア構成例を説明する図である。 図２１は、ハードウェア構成例を説明する図である。 図２２は、ハードウェア構成例を説明する図である。
エッジコンピューティングでは、例えば、情報処理装置の負荷の低減を図るため、情報処理装置と複数のエッジ端末の双方による分散処理が実施される。このような分散処理として、例えば、情報処理装置が配信するルールに従って、各エッジ端末が処理を実行する方法が考えられる。この方法によれば、情報処理装置はルールの配信（及び必要に応じてルールの生成）を行えば良いため、情報処理装置の負荷を低減することができる。
このとき、ルールの数を増やすことで、エッジ端末にきめ細かい処理を指示することが可能となり、処理精度を向上させることができる。しかしながら、すべてのエッジ端末に対して一律にルールの数を増やすのは望ましくない場合がある。具体的には、各エッジ端末の処理能力やリソースが異なる場合が考えられる。このような場合、処理能力やリソースが比較的小さいエッジ端末にとっては、多くのルールが負担となり、処理の遅延が発生するといった問題がある。
以下に開示の実施例では、各エッジ端末の処理能力やリソースに応じて処理の負荷を各エッジ端末に配分することが可能な、選択プログラム、情報処理装置および制御方法を説明する。
なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
（実施例１）
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、クラウドサーバ１００と、複数のエッジ端末２００とがネットワークＮを介して相互に通信可能に接続されるシステムである。なお、ネットワークＮには、有線や無線を問わず、インターネットなどの各種通信網を採用することができる。クラウドサーバ１００は、コンピュータおよび情報処理装置の一例である。部屋１～３の各々に備えられているエッジ端末２００は、室内の空調制御を実行する空調機、エアコンの一例である。
［クラウドサーバ１００の機能構成］
次に、図１に示したクラウドサーバ１００の機能構成について説明する。図２は、実施例１にかかるクラウドサーバ１００の機能構成を示す機能ブロック図である。図２に示すように、クラウドサーバ１００は、通信部１０１、記憶部１０２、および制御部１１０を有する。
通信部１０１は、他の装置との間の通信を制御する処理部であり、例えば、通信インタフェースによって実現される。
記憶部１０２は、各種データや、制御部１１０が実行するプログラムを記憶する。例えば、記憶部１０２は、メモリまたはハードディスクなどによって実現される。記憶部１０２は、特徴ベクトルＤＢ１０３、クラスタ結果ＤＢ１０４、クラスタ数決定ＤＢ１０５、制御基準ＤＢ１０６、およびスケジュールＤＢ１０７を記憶する。
特徴ベクトルＤＢ１０３は、学習データを記憶するデータベースである。クラスタ結果ＤＢ１０４は、クラスタ結果を記憶するデータベースである。クラスタ数決定ＤＢ１０５は、エッジ端末２００に配信する学習データの上限数を記憶するデータベースである。制御基準ＤＢ１０６は、エッジ端末２００に対する制御内容が記憶されたデータベースである。スケジュールＤＢ１０７は、エッジ端末２００を制御するスケジュールが記憶されたデータベースである。
制御部１１０は、クラウドサーバ１００全体の処理を司る処理部であり、例えばプロセッサなどにより実現される。制御部１１０は、取得部１１１、生成部１１２、選択部１１３、配信部１１４、処理部１１５を有する。
取得部１１１は、ユーザの状態を示す特徴と、エッジ端末２００の識別情報とを取得する。ユーザの状態を示す特徴は、例えば、ユーザがある単位時間において（例えば一時間ごとの）、在宅をしているか否かを示す情報、またはユーザが睡眠をしているか否かを示す情報である。また、エッジ端末２００の識別情報は、エッジ端末２００の処理能力に紐づけられた情報である。
生成部１１２は、ユーザ状態の推移を示す確率モデルを生成する。これは次のようにして行う。生成部１１２は、取得部１１１が取得した単位時間ごとのユーザの状態を示す特徴を、所定の期間において時系列に結合した情報であるユーザ状態推移情報を生成する（例えば一時間ごとの２４個のユーザの状態を示す特徴を結合して、あるユーザの１日分のユーザ状態推移情報を生成する）。そして、ここで生成されたユーザ状態推移情報を所定の条件でクラスタリングすることによって、複数のクラスタを生成する。次に、各クラスタにおいて、クラスタに含まれる１以上のユーザ状態推移情報に基づいて、当該クラスタを代表するまたは当該クラスタを典型的に示すユーザ状態推移パターンを生成する。本実施例においては、一例として、各クラスタにおいてこのユーザ状態推移パターンを後述するような確率モデルとして構築する。以上をまとめると、生成部１１２は、所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られるユーザ状態推移の複数のパターンである、複数のユーザ状態推移パターンを生成する。
選択部１１３は、確率モデルの数が、取得したエッジ端末２００の識別情報に基づいて設定される上限数を超えるときに、確率モデルのクラスタに用いた特徴の数に基づいて、エッジ端末２００に配信する確率モデルを選択する。具体的には、選択部１１３は、エッジ端末の処理能力が高いほど、エッジ端末２００に配信する確率モデルの数が多くなるように、確率モデルを選択する。また、選択部１１３は、生成した確率モデルの数が上限数を超えるときに、確率モデル毎に確率モデルのクラスタに用いた特徴の数を算出する。そして、選択部１１３は、生成した確率モデルの中から、特徴の数が大きい方から上限数だけの確率モデルを選択する。具体的には、選択部１１３は、前述の複数のユーザ状態推移パターンから、識別情報に応じた数の１以上のユーザ状態推移パターンを選択する。
配信部１１４は、通信部１０１を介して、選択された確率モデルを配信する。具体的には、配信部１１４は、１以上のユーザ状態推移パターンをエッジ端末２００に送信する。
処理部１１５は、エッジ端末２００による予測結果に基づいて、エッジ端末２００に対する制御内容を特定する。
［特徴ベクトルＤＢ１０３に記憶される情報の例］
図３は、特徴ベクトルＤＢ１０３に記憶される情報の例を示す図である。図３に示すように、特徴ベクトルＤＢ１０３は、「日付、特徴ベクトル」を対応づけて記憶する。
図３に示すように、特徴ベクトルは、単位時間の開始から終了に至るまでの期間において、各時刻で、ユーザが在宅しているか、不在であるかを示す情報を有する。例えば、１つの特徴ベクトル（ログ）は、各時刻において複数のラベルを有する。ユーザが在宅している場合は、ラベル「１」を設定する。一方、ユーザが不在であるときには、ラベル「０」を設定する。「２０２０年１月１日は、ｔ１の時刻ではユーザが在宅し、ｔ２の時刻ではユーザが不在で、ｔ３の時刻ではユーザが在宅」であることを示す。
［クラスタ結果ＤＢ１０４に記憶される情報の例］
図４（ａ）および図４（ｂ）は、クラスタ結果ＤＢ１０４に記憶される情報の例を示す図である。図４（ａ）は、クラスタ結果ＤＢ１０４に記憶される確率モデルの例である。図４（ｂ）は、クラスタ結果ＤＢ１０４に記憶される曜日が対応づけられた確率モデルの例である。
図４（ａ）に示すように、クラスタ結果ＤＢ１０４は、「確率モデルＩＤ、時刻、在室確率」を対応づけて記憶する。ここで記憶される「確率モデルＩＤ」は、確率モデルを識別する識別子であり、「時刻」は、基準となる時刻である。また、「在室確率」は、ユーザが存在している確率である。例えば、「確率モデル１は、ｔ１の時刻ではユーザの在室確率が０．８で、ｔ２の時刻ではユーザの在室確率が０．５」であることを示す。
図４（ｂ）に示すように、クラスタ結果ＤＢ１０４は、「確率モデルＩＤ、時刻、在室確率、曜日」を対応づけて記憶する。ここで記憶される「確率モデルＩＤ」は、確率モデルを識別する識別子であり、「時刻」は、基準となる時刻である。また、「在室確率」は、ユーザが存在している確率である。「曜日」は、確率モデルの代表する曜日である。「曜日」は、確率モデルに付与されるラベルの一例であり、測定した場所などの環境情報であってもよい。
［クラスタ数決定ＤＢ１０５に記憶される情報の例］
図５は、クラスタ数決定ＤＢ１０５に記憶される情報の例を示す図である。図５に示すように、クラスタ数決定ＤＢ１０５は、「識別情報、クラスタの上限数」を対応づけて記憶する。ここで、「識別情報」は、エッジ端末２００の型番号を識別する識別子である。また、「識別情報」は、エッジ端末２００の処理能力を示す識別子であってもよい。「クラスタの上限数」は、エッジ端末２００に配信する確率モデルの上限数である。例えば、「型番号がＸ００１のエッジ端末２００に対して、配信できる確率モデルの上限数は１０」であることを示す。
［制御基準ＤＢ１０６に記憶される情報の例］
図６は、制御基準ＤＢ１０６に記憶される情報の例を示す図である。図６に示すように、「不在が予想される」状態と、「在宅が予想される」状態との各々に対し、「時間長、制御内容」を対応づけて記憶する。「時間長」は、ユーザが在室する時間の時間長、または、ユーザが在室しない時間の時間長である。「制御内容」は、エッジ端末２００が実行する処理の内容である。図６の例では、ユーザの不在が予想される時間長が、「３０分以上であるとき」、エッジ端末２００の「省電力モード」を起動するように制御することを示している。
［スケジュールＤＢ１０７に記憶される情報の例］
図７は、スケジュールＤＢ１０７に記憶される情報の例を示す図である。図７に示すように、スケジュールＤＢ１０７は、「日時、予測結果、登録内容」を対応づけて記憶する。ここで記憶される「時刻」は、基準となる時刻である。「予測結果」は、エッジ端末２００によりユーザが存在するか否かを予測した結果である。「登録内容」は、ユーザの指示を受け付けた、エッジ端末２００に対する制御内容である。図７の例では、「１２：００～１５：００までユーザの不在が予想され、エアコンの掃除モードを起動することが登録されている」ことを示す。また、「１５：３０～１６：３０までユーザの在宅が予想され、エアコンの運転開始が登録されている」ことを示す。
［エッジ端末２００の機能構成］
図８は、実施例１にかかるエッジ端末２００の機能構成を示す機能ブロック図である。エッジ端末２００は、通信部２０１、記憶部２０２、および制御部２１０を有する。
通信部２０１は、他の装置との間の通信を制御する処理部であり、例えば、通信インタフェースによって実現される。
記憶部２０２は、各種データや、制御部２１０が実行するプログラムを記憶する。例えば、記憶部２０２は、メモリやハードディスクなどによって実現される。記憶部２０２は、センサ値ＤＢ２０３、およびエッジ端末ログＤＢ２０４を記憶する。
センサ値ＤＢ２０３は、各部屋のセンサにより取得された、ユーザの状態を識別するセンサ値を記憶するデータベースである。例えば、ここで記憶されるセンサ値は、ユーザの状態の他に、温度の時間変化などセンサが測定できる他の観測値を含んでいてもよい。ユーザの状態とは、例えば、部屋の中にユーザがいるか否かを示す情報である。エッジ端末ログＤＢ２０４は、エッジ端末２００の識別情報を記憶するデータベースである。
通信部２０１は、センサデータなどをクラウドサーバ１００に対して出力する。また、通信部２０１は、クラウドサーバ１００により配信された確率モデルなどをクラウドサーバ１００から受信する。さらに、通信部２０１は、確率モデルによる予測結果をクラウドサーバ１００に対して送信する。
制御部２１０は、エッジ端末２００全体の処理を司る。制御部２１０は、例えばプロセッサによって実現される。制御部２１０は、取得部２１１、処理部２１２、および実行部２１３を有する。
取得部２１１は、単位時間の開始から終了に至るまでのユーザの状態を示す、複数の特徴を取得する。例えば、取得部２１１は、０時から２４時までの期間において、ユーザが在室しているか否かを示す特徴を取得する。このとき、単位時間の開始から終了に至るまでのユーザの状態を示す複数の特徴は、クラウドサーバ１００に送信される。
また、取得部２１１は、単位時間の開始から推論の開始時刻に至るまでの、ユーザの状態を示す複数の特徴を取得する。例えば、取得部２１１は、本日の０時から現在までの期間において、ユーザが在室しているか否かを示す特徴を取得する。
処理部２１２は、確率モデルを用いて、推論の開始時刻から単位時間の終了までの期間において、ユーザの状態を予測する。
実行部２１３は、クラウドサーバ１００から配信された制御情報に基づく処理を実行する。
［センサ値ＤＢ２０３に記憶される情報の例］
図９（ａ）は、センサ値ＤＢ２０３に記憶される情報の例を示す図である。図９（ａ）に示すように、センサ値ＤＢ２０３は、「日時、曜日、在室の有無、室温、湿度、外気温」などを対応づけて記憶する。ここで記憶される「日時」は、データが測定された日時である。「曜日」は、データが測定された日の曜日である。「在室の有無」は、ユーザの状態を測定した結果であり、ユーザの存在の有無を測定した結果である。「室温」および「湿度」は、それぞれ、各室内の各センサなどにより測定された室内の温度および湿度であり、「外気温」は、各室の各センサにより測定された室外の温度である。図９（ａ）の例では、３０分ごとのセンサ値を示し、例えば、部屋１について、「２０２０年１月１日の水曜日の０：００では、ユーザが存在することが測定され、室温が２０度、室内の湿度が５５％、外気温が１０度であったこと」を示す。
［エッジ端末ログＤＢ２０４に記憶される情報の例］
図９（ｂ）は、エッジ端末ログＤＢ２０４に記憶される情報の例を示す図である。図９（ｂ）に示すように、エッジ端末ログＤＢ２０４は、「エッジＩＤ、識別情報」を対応づけて記憶する。ここで記憶される「エッジＩＤ」は、エアコンを識別するＩＤであり、「識別情報」は、エッジ端末２００の型番号を識別する識別子である。また、「識別情報」は、エアコンに搭載されたエッジ端末２００の処理能力を示す識別子であってもよい。
［ユーザ端末３００の機能構成］
図１０は、実施例１にかかるユーザ端末３００の機能構成を示す機能ブロック図である。図１０に示すように、ユーザ端末３００は、通信部３０１、制御部３０２、表示部３０３、および入力部３０４を有する。
通信部３０１は、クラウドサーバ１００に対して、ユーザから受け付けた操作内容を出力する。また、通信部３０１は、クラウドサーバ１００から、エッジ端末２００に対する制御内容の候補を受信する。
制御部３０２は、ユーザ端末３００全体の処理を司る。制御部３０２は、例えばプロセッサによって実現される。制御部３０２は、エッジ端末２００に対する制御内容の候補を実行するか否かの確認画像を表示部３０３に表示させる。
表示部３０３は、エッジ端末２００に対する制御内容の候補を実行するか否かの確認画像を表示する。表示部３０３は、例えば、表示装置によって実現される。
入力部３０４は、各種の情報を入力する。入力部３０４は、例えば、キーボード、タッチパネル、またはマウスによって実現される。
［制御システムの処理の流れ］
図１１は、制御システムの処理の流れを示すシーケンス図である。図１１を用いて、制御システムによる、学習データの収集からエッジ端末２００の制御を実行するまでの一連の処理を説明する。
図１１に示すように、クラウドサーバ１００の取得部１１１は、エッジ端末２００から、エッジ端末２００の識別情報と、ユーザの状態を示すセンサ値とを含むデータを取得する。例えば、図９（ａ）に示すように、クラウドサーバ１００の取得部１１１は、エッジ端末２００から、１日の開始から終了に至るまでの期間において、３０分間隔での、「ユーザが在室しているか、または不在であるか」を示す情報と、「曜日」を示す情報とを含むセンサ値を取得する。また、図９（ｂ）に示すように、クラウドサーバ１００は、エッジ端末２００から、端末の型番が「Ｘ００２」を示す識別情報を取得する。（Ｓ１０１）。
クラウドサーバ１００の生成部１１２は、取得されたデータから学習データを生成し、学習データをクラスタリングして確率モデルを生成する。生成部１１２は、「日付」に対応する期間において、所定の間隔ごとの、ユーザの状態を示す特徴ベクトルを有する学習データを作成する。そして、生成部１１２は、学習データを用いて、各時刻でのユーザの状態を示す確率モデルを生成する（Ｓ１０２）。
選択部１１３は、エッジ端末２００に配信する確率モデルを選択する。具体的には、選択部１１３は、エッジ端末２００の識別情報を基に、クラスタ数決定ＤＢ１０５を参照し、識別情報と対応づいたエッジ端末２００に配信する確率モデルの上限数を特定する。そして、選択部１１３は、生成された確率モデルの数が特定された上限数を超えるときに、生成された確率モデルの中からエッジ端末２００に配信する確率モデルを選択する。選択部１１３は、エッジ端末２００の処理能力が高いほど、エッジ端末２００に配信する確率モデルの数が多くなるように、確率モデルを選択する。（Ｓ１０３）。
配信部１１４は、選択された確率モデルをエッジ端末２００に配信する（Ｓ１０４）。
エッジ端末２００の実行部２１３は、配信された確率モデルを用いた予測制御を実行する。例えば、実行部２１３は、予め設定された推論時刻になったときに、センサにより測定されたセンサ値と確率モデルとに基づいて、推論時刻以降において、各時刻でのユーザの状態を予測する（Ｓ１０５）。
エッジ端末２００の処理部２１２は、予測された結果をクラウドサーバ１００に送信する（Ｓ１０６）。
クラウドサーバ１００の処理部１１５は、エッジ端末２００に対する制御内容の候補を特定する。例えば、図７に示すように、処理部１１５は、エッジ端末２００から、「１５：３０に不在から在宅に変わり、１６：３０までの６０分の期間において、在宅していること」の予測結果を受信する。処理部１１５は、図６に示すように、制御基準ＤＢ１０６に記憶される情報を参照して、時間長が６０分である「運転の開始」を制御内容の候補として特定する（Ｓ１０７）。
クラウドサーバ１００の処理部１１５は、ユーザ端末３００に対して、制御内容の候補を実行させるか否かを問い合わせする（Ｓ１０８）。
ユーザ端末３００の入力部３０４は、ユーザからの操作を受け付ける。そして、通信部３０１は、受け付けた操作結果を、クラウドサーバ１００に送信する（Ｓ１０９）。
クラウドサーバ１００の処理部１１５は、操作結果を、スケジュールＤＢ１０７に登録する。例えば、処理部１１５は、図７に示すように、「１５：３０から１６：３０の在宅が予測される期間に対して、運転の開始」の制御情報を更新する（Ｓ１１０）。
クラウドサーバ１００の処理部１１５は、スケジュールＤＢ１０７を参照し、登録された制御情報をエッジ端末２００に配信する。（Ｓ１１１）。
エッジ端末２００の実行部２１３は、制御情報に従って、処理を実行する（Ｓ１１２）。
［確率モデルを選択する処理］
図１２は、確率モデルの選択する処理を説明する図である。ここで、図１２を用いて、クラウドサーバ１００の選択部１１３が、生成された確率モデルの数が上限数を超えるときに、確率モデルの中からエッジ端末２００に配信する確率モデルを選択する処理を説明する。
図１２に示すように、生成部１１２は、確率モデル１、確率モデル２、確率モデル３、確率モデル４の４つの確率モデルを生成したとする。そして、選択部１１３は、エッジ端末２００の識別情報を基に、エッジ端末２００に配信する確率モデルの上限数は３であることを特定したとする。例えば、エッジ端末２００の処理能力が高いほど、確率モデルの上限数が多くなるように特定する。また他の例では、上位モデルのエッジ端末２００を、下位モデルのエッジ端末２００よりも確率モデルの上限数が多くなるように特定する。また、エッジ端末２００に搭載されたＣＰＵのクロック数によって、確率モデルの上限数を特定する。
次いで、選択部１１３は、確率モデルのクラスタに用いた特徴ベクトルの数が多い確率モデルを選択する。具体的には、確率モデル１は、１００個の特徴ベクトルをクラスタリングしたモデルである。また、確率モデル２は、５個の特徴ベクトルをクラスタリングしたモデルである。確率モデル３は、３０個の特徴ベクトルをクラスタリングしたモデルである。そして、確率モデル４は、１０個の特徴ベクトルをクラスタリングしたモデルである。そこで、選択部１１３は、確率モデルのクラスタに用いた特徴ベクトルの数の多い、確率モデル１、確率モデル３、確率モデル４の３つの確率モデルを選択する。
［ユーザ端末の操作画面］
図１３は、ユーザ端末３００に表示される操作画面例を示す図である。図１３に示すように、ユーザ端末３００の表示部３０３は、クラウドサーバ１００の処理部１１５により特定された制御内容の候補を実行するか否かを受け付ける画面を表示する。例えば、表示部３０３は、制御内容の候補として、「今日の１５：３０からエアコンを運転させるか」を表示する。そして、ユーザ端末３００は、制御内容の候補を実行することを受け付ける「ＹＥＳ」の操作ボタンと、制御内容の候補を実行しないことを受け付ける「ＮＯ」の操作ボタンとを表示する。
［クラウドサーバ１００における学習処理］
ここで、図１４を用いて、クラウドサーバ１００における学習処理を説明する。図１４は、図１１のＳ１０２の詳細な処理を示すフローチャートである。
生成部１１２は、学習データを取得する（Ｓ２０１）。
生成部１１２は、学習データの特徴ベクトルを算出する（Ｓ２０２）。
生成部１１２は、特徴ベクトルをクラスタリングする。具体的には、生成部１１２は、特徴ベクトルの間の距離を計算する。そして、生成部１１２は、特徴ベクトルの距離が予め設定した閾値以下の距離の特徴ベクトルを同じクラスタに含ませるようにクラスタリングを行う。距離としては、例えば、ユークリッド距離やコサインに基づく距離等の任意の距離を用いることができる（Ｓ２０３）。
生成部１１２は、クラスタリングされた特徴ベクトルから、確率モデルを生成する。具体的には、生成部１１２は、同一のクラスタに含まれる複数の特徴ベクトルの各々から、クラスタの特徴ベクトルを算出する。そして、生成部１１２は、算出された特徴ベクトルを用いて、確率モデルを生成する（Ｓ２０４）。
生成部１１２は、代表となる曜日が対応づけられた確率モデルを生成する。生成部１１２は、確率モデルのクラスタに含まれる複数の特徴ベクトルの各々に対して、特徴ベクトルを測定した曜日を特定する。そして、生成部１１２は、特定した曜日のなかで最も数の多い曜日を、確率モデルの代表の曜日として設定する。例えば、図４（ｂ）に示すように、確率モデル１は、水曜日が代表の曜日であることが設定される。これは、図９（ａ）に示すように、センサデータに含まれる曜日情報を用いて、確率モデルのクラスタに含まれる複数の特徴ベクトルの各々に対して、特徴ベクトルを測定した曜日を特定する。生成部１１２は、複数の特徴ベクトルの各々の類似度に基づいて複数の特徴ベクトルをクラスタリングすることによって、少なくとも１以上のクラスタを生成する。そして、生成部１１２は、少なくとも１以上のクラスタの中に含まれる特徴ベクトルの各々に対応づけられた曜日の中で、最も数の多い同一種類の曜日を特定し、特定した曜日が対応づけられた確率モデルを生成する。つまり、生成部１１２は、環境情報を設定した曜日が対応付けられた確率モデルを生成する（Ｓ２０５）。
生成部１１２は、確率モデルを出力する。また、生成部１１２は、曜日が対応づけられた確率モデルを出力する（Ｓ２０６）。
［学習データの特徴ベクトル］
ここで、図１５を用いて、学習データの特徴ベクトルについて説明する。特徴ベクトルは、単位時間の開始から終了に至るまでの期間において、各時刻でのユーザの状態を示す情報である。例えば、図１５に示すように、２０２０年１月１日の特徴ベクトルにおいては、午前中の後半は、ユーザは不在であるが、午後の前半は、ユーザは在宅である、ことを示している。また、２０２０年１月２日の特徴ベクトルにおいては、ユーザは終日在宅であることを示している。一方で、２０２０年１月３日の特徴ベクトルにおいては、ユーザは終日不在であることを示している。
［確率モデル］
ここで、図１６および図１７を用いて、確率モデルについて説明する。図１６は、確率モデルのクラスタを作成する処理を説明する図である。図１７は、確率モデルのクラスタから在室確率を特定する処理を説明する図である。
図１６に示すように、生成部１１２は、学習データの複数の特徴ベクトルの各々の距離が近い特徴ベクトルをクラスタリングする。そして、生成部１１２は、クラスタリングしたクラスタから確率モデルを生成する。
このとき、図１６の例では、確率モデル１のクラスタには、特徴ベクトル２と、特徴ベクトル３などが含まれる。そして、確率モデル１は、１００個の特徴ベクトルを有する。また、確率モデル２のクラスタは、特徴ベクトル４と特徴ベクトル５などが含まれる。そして、確率モデル２は、５個の特徴ベクトルを有する。一方で、特徴ベクトル１は、どの確率モデルにも属していない特徴ベクトルである。これは、特徴ベクトル１は、他の特徴ベクトルと距離が離れているために、クラスタリングされなかったためである。
次いで、生成部１１２は、確率モデル１のクラスタに属する１００個の特徴ベクトルの各々を用いて、確率モデル１の特徴ベクトルを算出する。算出した特徴ベクトルは、在室確率を示す。具体的には、生成部１１２は、図１７に示すように、特徴ベクトルの各々の平均により、確率モデルの在室確率を算出する。例えば、特徴ベクトルの８時から８時３０分までの複数のラベルの平均値を、確率モデルの８時から８時３０分までの在室確率とする。また、特徴ベクトルの８時３０分から９時までの複数のラベルの各々の平均値を、８時３０分から９時までの在室確率とする。これにより、生成部１１２は、確率モデル１の各時刻における、ユーザの在室確率を示すパターンを算出する。
［エッジ端末２００における予測処理］
ここで、図１８を用いて、エッジ端末２００における予測処理を説明する。図１８は、図１１のＳ１０５の詳細な処理を示すフローチャートである。エッジ端末２００における予測処理は、必要に応じて、Ｓ３０７およびＳ３０８を省略することができる。すなわち、Ｓ３０６の次の処理はＳ３０９となる。
取得部２１１は、推論時刻までのデータを取得する（Ｓ３０１）。
処理部２１２は、特徴ベクトルを算出する（Ｓ３０２）。
処理部２１２は、推論時刻までの期間において、複数の確率モデルの各々が互いに類似するか否かを判定する。具体的には、処理部２１２は、単位時間の開始から推論時刻までの期間において、クラウドサーバ１００から配信された複数の確率モデルのそれぞれの在室確率が類似するか否かを判定する。例えば、処理部２１２は、複数の確率モデルの各々の在室確率の差分が、予め設定した閾値以上であるか否かにより判定する。処理部２１２が、在室確率が類似しないと判定された場合、Ｓ３０４に移行する（Ｓ３０３：ＮＯ）。一方で、処理部２１２が、在室確率が類似すると判定された場合、Ｓ３０５に移行する（Ｓ３０３：ＹＥＳ）。
処理部２１２は、複数の確率モデルの中から確率モデルを特定する。処理部２１２は、算出した特徴ベクトルと類似する確率モデルを特定する。具体的には、処理部２１２は、クラウドサーバ１００から配信された複数の確率モデルの中から、特徴ベクトルが類似する在室確率を有する確率モデルを特定する（Ｓ３０４）。
処理部２１２は、曜日が各々対応づけられた複数の確率モデルの中から確率モデルを特定する。処理部２１２は、当日の曜日を用いて、確率モデルを特定する。（Ｓ３０５）。
処理部２１２は、特定した確率モデルを用いて、推論時刻以降の当日の在室確率を取得する（Ｓ３０６）。
処理部２１２は、翌日の在室確率を取得する。具体的には、処理部２１２は、クラウドサーバ１００から配信された複数の確率モデルの中から、翌日の曜日に対応づけられた確率モデルを特定する。そして、処理部２１２は、特定された確率モデルを用いて、翌日の在室確率を取得する（Ｓ３０７）。
処理部２１２は、推論時刻から２４時間後までの在室確率を算出する（Ｓ３０８）。
処理部２１２は、ユーザの在室の有無を特定する。具体的には、処理部２１２は、算出した在室確率と、予め設定した閾値との比較結果に基づいて、ユーザの在室の有無を特定する。例えば、処理部２１２は、時刻と、在室確率が閾値（例えば、０．５）を超えている時の時間長を出力する。また、処理部２１２は、時刻と、在室確率が閾値（例えば、０．５）以下の時間長を出力する。（Ｓ３０９）。
［ユーザの在室確率を算出する処理］
ここで、図１９を用いて、処理部２１２がユーザの在室確率を算出する処理について説明する。処理部２１２は、ｔ１から推論時刻であるｔ２までの特徴ベクトルと、複数の確率モデルの各々の在室確率とを比較する。そして、処理部２１２は、複数の確率モデルの中から、ｔ１から推論時刻であるｔ２までの特徴ベクトルと最も類似する在室確率を有する確率モデルを特定する。次いで、処理部２１２は、確率モデルの在室確率を参照し、ｔ２からｔ３の期間の時刻のそれぞれにおける、ユーザの在室確率を予測する。
［ハードウェア］
図２０は、ハードウェア構成例を説明する図である。図２０に示すように、クラウドサーバ１００は、通信装置１００ａ、ＨＤＤ（Hard Disk Drive）１００ｂ、メモリ１００ｃ、およびプロセッサ１００ｄを有する。また、図２０に示した各部は、バス等で相互に接続される。
通信装置１００ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ１００ｂは、図２等に示した機能を動作させるプログラムおよびＤＢを記憶する。
プロセッサ１００ｄは、図２等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１００ｂ等から読み出してメモリ１００ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、クラウドサーバ１００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１００ｄは、取得部１１１、生成部１１２、選択部１１３、配信部１１４、処理部１１５等と同様の機能を有するプログラムをＨＤＤ１００ｂ等から読み出す。そして、プロセッサ１００ｄは、取得部１１１、生成部１１２、選択部１１３、配信部１１４、処理部１１５等と同様の処理を実行するプロセスを実行する。
このようにクラウドサーバ１００は、プログラムを読み出して実行することでデータ生成方法を実行する情報処理装置として動作する。また、クラウドサーバ１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、クラウドサーバ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto-Optical disk）、ＤＶＤ（Digital Versatile Disc）などの、非一時的なコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
図２１は、ハードウェア構成例を説明する図である。図２１に示すように、エッジ端末２００は、通信装置２００ａ、ＨＤＤ２００ｂ、メモリ２００ｃ、およびプロセッサ２００ｄを有する。また、図２１に示した各部は、バス等で相互に接続される。
通信装置２００ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ２００ｂは、図８等に示した機能を動作させるプログラムおよびＤＢを記憶する。
プロセッサ２００ｄは、図８等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ２００ｂ等から読み出してメモリ２００ｃに展開することで、図８等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、エッジ端末２００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ２００ｄは、取得部２１１、処理部２１２、実行部２１３等と同様の機能を有するプログラムをＨＤＤ２００ｂ等から読み出す。そして、プロセッサ２００ｄは、取得部２１１、処理部２１２、実行部２１３等と同様の処理を実行するプロセスを実行する。
このようにエッジ端末２００は、プログラムを読み出して実行することでデータ生成方法を実行する情報処理装置として動作する。また、エッジ端末２００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、エッジ端末２００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
図２２は、ハードウェア構成例を説明する図である。図２２に示すように、ユーザ端末３００は、通信装置３００ａ、ＨＤＤ３００ｂ、メモリ３００ｃ、プロセッサ３００ｄ、表示装置３００ｅ、入力装置３００ｆを有する。また、図２３に示した各部は、バス等で相互に接続される。
通信装置３００ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ３００ｂは、図１０等に示した機能を動作させるプログラムやＤＢを記憶する。
プロセッサ３００ｄは、図１０等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ３００ｂ等から読み出してメモリ３００ｃに展開することで、図１０等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、ユーザ端末３００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ３００ｄは、制御部３０２等と同様の機能を有するプログラムをＨＤＤ３００ｂ等から読み出す。そして、プロセッサ３００ｄは、制御部３０２等と同様の処理を実行するプロセスを実行する。
このようにユーザ端末３００は、プログラムを読み出して実行することでデータ生成方法を実行する情報処理装置として動作する。また、ユーザ端末３００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、ユーザ端末３００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
１００ クラウドサーバ
１０１ 通信部
１０２ 記憶部
１０３ 特徴ベクトルＤＢ
１０４ クラスタ結果ＤＢ
１０５ クラスタ数決定ＤＢ
１０６ 制御基準ＤＢ
１０７ スケジュールＤＢ
１１０ 制御部
１１１ 取得部
１１２ 生成部
１１３ 選択部
１１４ 配信部
１１５ 処理部
２００ エッジ端末
２０１ 通信部
２０２ 記憶部
２０３ センサ値ＤＢ
２０４ エッジ端末ログＤＢ
２１０ 制御部
２１１ 取得部
２１２ 処理部
２１３ 実行部
３００ ユーザ端末
３０１ 通信部
３０２ 制御部
３０３ 表示部
３０４ 入力部

Claims (5)

  1. コンピュータに、
    端末に関する識別情報を前記端末から受信し、
    所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られる前記ユーザ状態推移の複数のパターンである複数のユーザ状態推移パターンから、前記識別情報に応じた数の１以上のユーザ状態推移パターンを選択し、
    前記１以上のユーザ状態推移パターンを前記端末に送信する、
    処理を実行させることを特徴とする選択プログラム。
  2. 前記選択する処理は、
    前記端末の処理能力が高いほど、前記端末に配信する確率モデルの数が多くなるように、複数の確率モデルの中から確率モデルを選択する、
    処理を含むことを特徴とする請求項１に記載の選択プログラム。
  3. 前記選択する処理は、
    前記複数の確率モデルの数が上限数を超えるときに、前記複数の確率モデルの各々について、特徴の数を算出し、
    前記複数の確率モデルの中から、前記特徴の数が大きい方から前記上限数だけの確率モデルを特定する、処理を含み、
    特定した前記確率モデルを前記端末に配信する、
    処理を更に実行させることを特徴とする請求項２に記載の選択プログラム。
  4. 端末に関する識別情報を前記端末から受信する受信部と、
    所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られる前記ユーザ状態推移の複数のパターンである複数のユーザ状態推移パターンから、前記識別情報に応じた数の１以上のユーザ状態推移パターンを選択する選択部と、
    前記１以上のユーザ状態推移パターンを前記端末に送信する送信部と、
    を有することを特徴とする情報処理装置。
  5. コンピュータに、
    端末に関する識別情報を前記端末から受信し、
    所定の単位時間におけるユーザの状態の時系列な推移であるユーザ状態推移を示す情報をクラスタリングすることによって得られる前記ユーザ状態推移の複数のパターンである複数のユーザ状態推移パターンから、前記識別情報に応じた数の１以上のユーザ状態推移パターンを選択し、
    前記１以上のユーザ状態推移パターンを前記端末に送信する、
    処理を実行させることを特徴とする制御方法。
JP2020146476A 2020-09-01 2020-09-01 選択プログラム、情報処理装置および制御方法 Pending JP2022041339A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020146476A JP2022041339A (ja) 2020-09-01 2020-09-01 選択プログラム、情報処理装置および制御方法
US17/359,837 US20220067561A1 (en) 2020-09-01 2021-06-28 Storage medium, information processing device, and control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020146476A JP2022041339A (ja) 2020-09-01 2020-09-01 選択プログラム、情報処理装置および制御方法

Publications (1)

Publication Number Publication Date
JP2022041339A true JP2022041339A (ja) 2022-03-11

Family

ID=80358660

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020146476A Pending JP2022041339A (ja) 2020-09-01 2020-09-01 選択プログラム、情報処理装置および制御方法

Country Status (2)

Country Link
US (1) US20220067561A1 (ja)
JP (1) JP2022041339A (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7904097B2 (en) * 2005-12-07 2011-03-08 Ekahau Oy Location determination techniques
JP5495014B2 (ja) * 2009-09-09 2014-05-21 ソニー株式会社 データ処理装置、データ処理方法、およびプログラム
US20140359637A1 (en) * 2013-06-03 2014-12-04 Microsoft Corporation Task continuance across devices
US20180129959A1 (en) * 2016-11-10 2018-05-10 General Electric Company Methods and systems for programmatically selecting predictive model parameters

Also Published As

Publication number Publication date
US20220067561A1 (en) 2022-03-03

Similar Documents

Publication Publication Date Title
US20200334574A1 (en) Machine learning device, machine learning method, and storage medium
CN109783028B (zh) I/o调度的优化方法、装置、存储介质及智能终端
US20160077538A1 (en) Load forecasting for residential sector demand response
EP2469676A1 (en) Demand-prediction device, program, and recording medium
JP7279445B2 (ja) 予測方法、予測プログラムおよび情報処理装置
CN108958828B (zh) 应用程序预加载方法、装置、存储介质及终端
US7664671B2 (en) Methods and systems for profile-based forecasting with dynamic profile selection
JP7342833B2 (ja) 制御装置、コントローラ、制御システム、制御方法、および制御プログラム
US11480623B2 (en) Apparatus and method for predicting a remaining battery life in a device
CN112529301A (zh) 用电量预测方法、设备及存储介质
CN111623486B (zh) 开机时间的确定方法和装置、存储介质及电子装置
CN112346738A (zh) 智能灰度发布方法、装置、电子设备及存储介质
CN113206774A (zh) 一种基于室内定位信息的智能家居设备的控制方法及装置
WO2021038759A1 (ja) モデル選択方法、モデル選択プログラムおよび情報処理装置
JP2022041339A (ja) 選択プログラム、情報処理装置および制御方法
CN101142559A (zh) 对计算机控制的处理进行监视
Trabelsi et al. Leveraging evolutionary algorithms for dynamic multi-objective optimization scheduling of multi-tenant smart home appliances
JP2019082895A (ja) 訪問時刻決定装置
CN117154844A (zh) 储能系统的能源供应控制方法及装置
CN112053022A (zh) 计划制定系统及其方法
CN110086835B (zh) 应用程序管控方法、终端、服务器及系统
CN114442697B (zh) 一种温度控制方法、设备、介质及产品
CN109062396B (zh) 用于控制设备的方法和装置
CN115307274A (zh) 控制空调系统的主机的方法、设备和存储介质
CN114358350A (zh) 会议预定模型的使用方法、装置、设备及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230608

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20230801

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20230801