JP2015508523A - モノのインターネットにおけるサービス・インスタンス指向のエネルギー管理のための方法、システム、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】モノのインターネット（ＩｏＴ：Internet of Things）における効率的なサービス・インスタンス指向のエネルギー管理のためのシステムおよび方法を提供すること。【解決手段】本方法は、サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測するための予測するステップと、ターゲット・サービス・インスタンスに対応する必須カバー集合、必須カバー集合におけるセンサの使用履歴データ、および前記センサのエネルギー・パラメータに従って、前記ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択するための選択するステップと、前記時間期間が開始すると、ＯＮセンサ集合におけるセンサはオンにされ、ＯＮセンサ集合におけるこれらのセンサ以外のセンサはオフにされるように、ＩｏＴにおけるセンサに対してＯＮ／ＯＦＦ制御するための制御するステップと、前記時間期間におけるセンサの使用量に従って、センサの使用履歴データを更新するための更新するステップとを含む。【選択図】図７

Description

本発明は、モノのインターネット（ＩｏＴ：Internet of Things）の分野に関する。より詳細には、本発明は、ＩｏＴにおける効率的なサービス・インスタンス指向のエネルギー管理のためのシステムおよび方法に関する。

ＩｏＴは、新世代の情報技術の重要な構成要素であり、その正式名称は、「モノのインターネット（Internet of Things）」である。したがって、ＩｏＴは、その名称が示唆するように、モノ同士が相互にそれを介して接続されるインターネットである。具体的には、ＩｏＴは、インターネットとの組合せで形成される巨大なネットワークであり、ここでは、センサ、無線周波数識別（ＲＦＩＤ）技術、全地球測位システム、赤外線センサ、レーザ・スキャナ、またはガス・センサなどの様々な情報センサ装置を通じて、監視、接続、相互作用を必要とする任意のオブジェクトまたはプロセスがリアル・タイムに獲得され、その音声、光、熱、電気、力学的要素、化学的要素、生物学的要素、位置などの様々な必要情報が獲得される。ＩｏＴの目的は、モノとモノとの間、モノと人間との間、すべてのモノとネットワークとの間の接続を達成して、認識、管理、および制御を促進することである。

ＩｏＴアクセス・ネットワークのほとんどは、ワイヤレスである。場合によっては、様々な情報を獲得するためのセンサが、現場に配置されることさえあり得る。この場合には、センサはその電池によって電力供給され、したがって、その電力容量は制限され、これらのセンサはほとんど移動しない。センサは、その電力を使い果たしたとき、（たとえば、センサが観測気球に、または海底で、または火山クレータに配置される場合の）大自然の現場で、このセンサの電池を手動で交換することは実践的ではないことがある。さらには、センサが非常に安価である場合には、大自然の現場に配置されたセンサを見つけ出して、その電池を交換することはかえって厄介である。したがって、いかにＩｏＴネットワーク全体のエネルギーを維持して、より長い時間動作させるかということは大きな課題になる。

図２は、本発明を実施するように適合されたＩｏＴエネルギー管理サーバのＩｏＴにおける配置位置を示す図である。従来技術では、１つの領域内のセンサに対してエネルギー管理を実行するためのアクセス・ネットワークの層に配置されたアプリケーションが存在する。しかしながら、このレベルには管理に対して制限がある。たとえば、北京市の平均気温を提供するサービスを一例として挙げると、このサービスによって提供される平均気温は、北京市の北部にある領域Ａに物理的に位置する温度センサａの検知値と、北京市の南部にある領域Ｂに物理的に位置する温度センサｂの検知値との平均値に基づいていることが仮定される。エネルギー管理が、アクセス・ネットワークのレベルによりセンサに対して実行されるとき、エネルギー管理パターンは、種々の領域間で異なっていることがあり、かつ管理は通常、関連性がないので、次の場合が起こる可能性がある：温度センサａの電力は、多く残存している一方、温度センサｂの電力は使い果たされている。したがって、北京市の南部の気温は、獲得することができず、北京市の平均気温に関するサービスを提供し続けることは不可能であり、これは、低いサービス品質（ＱｏＳ）につながる。

従来技術は、たとえば、ＩＥＥＥ８０２．１１電力節約モード（ＰＳＭ）を含む。この技術は、デバイスのアイドル・リスニング時間を定期的にスリープ状態にすることによって減少させ、それによって、デバイスは、電力を節約することになる。

加えて、よく知られているセンサＭＡＣ（Ｓ−ＭＡＣ）プロトコルでは、ネットワークにおけるノードは定期的にスリープし、隣接するノードは、スリープ・スケジュールにおいて自動同期するように仮想クラスタを形成する。

上記の従来技術はすべて、特定のネットワーク領域またはネットワーク・プロトコルのために設計されており、提供されるサービス能力の柔軟な組合せをサポートしていない。

発明が解決しようする課題

上記の説明に基づいて、長期間、かなりの程度まで電力を節約しつつ、ＱｏＳ要件を満たすように、ＩｏＴにおいてセンサのＯＮ／ＯＦＦ状態を効率的にスケジューリングできる方法およびシステムを提供することが望ましい。

上記の技術的問題を解決するために、本発明の発明者らは、エネルギー管理が、サービス・インスタンスの観点からは実行すべきであるが、センサの観点からは直接的に実行すべきでないことを提案している。本発明の１つの態様によれば、ＩｏＴにおけるサービス・インスタンス指向のエネルギー管理方法が提供され、このエネルギー管理方法は、サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測するステップと、ターゲット・サービス・インスタンスに対応する必須カバー集合（critical covering set）、必須カバー集合におけるセンサの使用履歴データ、および前記センサのエネルギー・パラメータに従って、前記ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択するステップと、前記時間期間の開始に応答して、ＯＮセンサ集合におけるセンサはオンにされ、ＯＮセンサ集合におけるこれらのセンサ以外のセンサはオフにされるように、ＩｏＴにおけるセンサに対してＯＮ／ＯＦＦ制御するステップとを含む。

本発明の別の態様によれば、ＩｏＴにおけるサービス・インスタンス指向のエネルギー管理システムが提供され、このエネルギー管理システムは、サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測するように構成された予測手段と、ターゲット・サービス・インスタンスに対応する必須カバー集合、必須カバー集合におけるセンサの使用履歴データ、および前記センサのエネルギー・パラメータに従って、前記ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択するように構成された選択手段と、前記時間期間の開始に応答して、ＯＮセンサ集合におけるセンサはオンにされ、ＯＮセンサ集合におけるこれらのセンサ以外のセンサはオフにされるように、ＩｏＴにおけるセンサに対してＯＮ／ＯＦＦ制御するように構成された制御手段とを備える。

本発明の方法およびシステムは、いずれのＭＡＣ層プロトコルにも依存しておらず、それらは、より低い層の通信プロトコルに透過的であり、いずれのＭＡＣ層プロトコルとも互換性がある。本発明の方法およびシステムは、提供されるサービス能力の柔軟な組合せをサポートする。加えて、本発明の方法およびシステムは、アプリケーションを実行する際の動的な変化を考慮することが可能である。

本発明それ自体ならびにその実施形態、他の目的および利点は、図面を参照して例示的な実施形態の以下の詳細な説明を読むことによってより良く理解されよう。

本発明の一実施形態を実装するように適合されている例示的なコンピューティング・システム１００を示すブロック図である。 本発明を実装するように適合されているＩｏＴエネルギー管理サーバの、ＩｏＴにおける配置位置を示す図である。 アプリケーションとサービス・インスタンスとの関係を単純な例によって示す図である。 図３の例に基づくサービス・インスタンス状態遷移図である。 図３の例に基づく遷移確率を含むサービス・インスタンス状態遷移図である。 センサとサービス・インスタンスとの配置関係を例示する図である。 本発明の一実施形態によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のための方法を示す流れ図である。 センサとサービス・インスタンスとの配置関係の一例を示す図である。 図８における例に対応する、センサの使用履歴データおよびサービス・インスタンスの実行履歴の一例を示す図である。 図９の例に基づくセンサＯＮ／ＯＦＦ状態遷移図である。 図９の例に基づくサービス・インスタンス状態遷移図である。 本発明の別の実施形態によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のための方法を示す流れ図である。 本発明によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のためのシステムを示す図である。

次に、好ましい方法およびシステムについて、図面を参照して説明する。ここでは、同じ参照符号は、図面において同じ要素を示すために使用される。次の説明では、説明の目的のため、数多くの特定の細部を、システムおよび方法を完全に理解させるなどのために述べる。他の例では、説明を簡略化するために、一般に使用される構造およびデバイスは、ブロック図の形態で示される。本明細書および図面にも教示される利益を有する数多くの修正形態および他の実施形態を当業者なら想到するであろう。そのため、本発明が、開示される特定の実施形態に限定されないこと、ならびに追加の可能な実施形態が、本発明の範囲および例示的な独創的な概念に含まれるべきであることを理解されたい。いくつかの特定の用語が本明細書に使用されるが、それらは、単に概括的な記述的意味において使用されるにすぎず、限定目的のためのものではない。

次の詳解では、非常に多くの具体的な細部が、本発明を十分に理解させるために与えられる。しかしながら、そのような具体的な細部がなくても、本発明を理解するのには影響を受けないことが当業者には明白である。加えて、下記に使用されるいずれの特定の用語も、単に説明の便宜上のためだけにすぎず、したがって、本発明を、そのような用語によって表されるまたは示唆されるあるいはその両方の、任意の特定の用途において使用することのみに限定すべきでないことをさらに認識されたい。

図１は、本発明の実施形態を実装するために適用できる例示的なコンピュータ・システム１００を示している。図１に示されるように、コンピュータ・システム１００は、ＣＰＵ（中央処理装置）１０１、ＲＡＭ（ランダム・アクセス・メモリ）１０２、ＲＯＭ（読取り専用メモリ）１０３、システム・バス１０４、ハード・ドライブ・コントローラ１０５、キーボード・コントローラ１０６、シリアル・インターフェース・コントローラ１０７、パラレル・インターフェース・コントローラ１０８、ディスプレイ・コントローラ１０９、ハード・ドライブ１１０、キーボード１１１、シリアル周辺機器１１２、パラレル周辺機器１１３、およびディスプレイ１１４を含み得る。上記のデバイスの中で、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ハード・ドライブ・コントローラ１０５、キーボード・コントローラ１０６、シリアル・インターフェース・コントローラ１０７、パラレル・インターフェース・コントローラ１０８、およびディスプレイ・コントローラ１０９は、システム・バス１０４に結合されている。ハード・ドライブ１１０は、ハード・ドライブ・コントローラ１０５に結合されている。キーボード１１１は、キーボード・コントローラ１０６に結合されている。シリアル周辺機器１１２は、シリアル・インターフェース・コントローラ１０７に結合されている。パラレル周辺機器１１３は、パラレル・インターフェース・コントローラ１０８に結合されている。また、ディスプレイ１１４は、ディスプレイ・コントローラ１０９に結合されている。図１に示す構造は、本発明に対する何らかの限定ではなく例示目的のためのものにすぎないことを理解されたい。場合によっては、特定の状況に基づいて、いくつかのデバイスがコンピュータ・システム１００に追加されても、またはコンピュータ・システム１００から除外されてもよい。

次の説明では、まず、この開示で使用される主要な用語および概念について述べる。

ＩｏＴにおける種々のセンサは、種々の検知能力を提供する。たとえば、温度センサは、気温を検知することができ、湿度センサは、湿度を検知することができる、等々である。本発明では、これらの検知能力は、アプリケーションに提供すべき数多くの種々のサービス内にパッケージ化される。本発明のサービスは、「３階３０１号室の室温」および「３階３０１号室の湿度」など、アプリケーションに提供され得る基本サービスを示す。つまり、本発明のサービスは、特定のＩｏＴ検知サービスを提供する基本粒度である。アプリケーションに求められているのは、種々のサービスを組み合わせて、特定のアプリケーション・シナリオを具現化することだけである。

本発明による方法およびシステムは、ＩｏＴのアプリケーション・インフラストラクチャ層において具現化される（図２参照）。たとえば、本発明による方法およびシステムは、図２のＩｏＴエネルギー管理サーバにおいて具現化される。ＩｏＴエネルギー管理サーバは、システム全体を最もエネルギー効率の良い状態に保つように物理センサのデューティ・サイクルを制御するために使用される。ＩｏＴアプリケーション・インフラストラクチャは、ＩｏＴアプリケーションの実行をサポートする分散型ミドルウェア・プラットフォームである。アプリケーション・インフラストラクチャ・プラットフォームは、物理センサを管理する能力をサービスとして提供する。たとえば、「３階３０１号室の室温」と「３階３０１号室の湿度」の両方は、アプリケーション・インフラストラクチャによって達成されるサービスの例である。アプリケーション・インフラストラクチャによって達成される様々なサービスを柔軟に組み合わせることで、ＩｏＴアプリケーションは、様々な実践上のシナリオに適したそのアプリケーション・ロジックを形成することができる。各サービスは、北京市の平均気温の上記の例など、種々のネットワーク領域から物理センサの関与を要求することができる。

各サービスについて、そのランタイム・インスタンスは、サービス・インスタンス（ＳＩ）として定義される。サービス・インスタンスは、センサの組合せに基づいて、提供され得るサービスのインスタンスである。アプリケーションが実際にサービスを使用する（呼び出す）とき、このサービスのサービス・インスタンスが、生成され、ＩｏＴにおいて実行され、この実行は、対応するセンサに、動作することを要求する。本発明による方法およびシステムによって行われるエネルギー管理は、センサの代わりにサービス・インスタンスに基づく。そうすることで、次の利点がある：
１． サービスについては、各サービス・インスタンスは、センサの異なる組合せによって達成され得、センサ装置管理の項目は、アプリケーションについてスクリーニングされ、それによって、アプリケーション開発の柔軟性が強化される。
２． センサ装置については、特定のセンサ装置によって提供されるサービスは、センサ装置を管理する際に十分に考慮され得る。それによって、サービスの信頼性が確実になり、そのため、サービス・インスタンスに基づくエネルギー管理パターンは、柔軟性および信頼性を確実にしながら、システム・エネルギー消費を最小限にする。また、特定のセンサ装置によって提供されるサービスは、他のＩｏＴアプリケーション・サポート・プラットフォームに移し替えられ得る。

図３は、アプリケーションとサービス・インスタンスとの関係を単純な例によって示している。図３では、たとえば、サービス・インスタンス１は、３０１号室の室温の検出であり、サービス・インスタンス２は、３０１号室の湿度の検出であり、サービス・インスタンス３は、３０１号室の照明の調整である。図３では、アプリケーション１〜３は、サービス・インスタンス１〜３をそれぞれ使用して、それ自体のアプリケーション・ロジックを形成する。図３の状態遷移を参照して、たとえば、アプリケーション１は、次のアプリケーション・ロジックを反復して実行する：３０１号室の室温を検出し、次いで３０１号室の湿度を検出し、次いで、３０１号室の照明を調整する。アプリケーション２は、たとえば、次のアプリケーション・ロジックを反復して実行する：３０１号室の室温を検出し、次いで３０１号室の照明を調整し、次いで３０１号室の湿度を検出する。アプリケーション３では、次のサービス・インスタンス：３０１号室の室温の検出、３０１号室の湿度の検出、および３０１号室の照明の調整がそれぞれ反復して実行される。図３は、説明を簡略化するために与えられた単なる一例にすぎない。実践に際しては、アプリケーションは、数多くの種々のサービス・インスタンスによって形成される複雑なアプリケーション・ロジックを有し得る。

図３の例に関しては、複数のＩｏＴアプリケーション（アプリケーション１〜３）が同時に実行されるとき、一定の期間内で次の状態のうちの１つが存在する：サービス・インスタンス１、２、３のうちの１つが単独で実行される、サービス・インスタンス（１、２）が実行される、サービス・インスタンス（１、３）が実行される、サービス・インスタンス（２、３）が実行される、サービス・インスタンス（１、２、３）が実行される。

図４は、図３の例に基づくサービス・インスタンス状態遷移図を示している。図４では、７つの状態が存在し、各状態から他の６つの状態のうちの１つに遷移することが起こり得る。アプリケーション１〜３の各々が現れる確率は１／３であり、かつサービス・インスタンスｊがアプリケーションｉ（ｉ＝１〜３）のサービス・インスタンスｋに遷移する確率は同じであると仮定した場合では、図５の遷移確率を含むサービス・インスタンス状態遷移図が得られる。遷移確率を含むサービス・インスタンス状態遷移図は、本発明ではサービス・インスタンス遷移モデルと称する。サービス・インスタンス遷移モデルは、サービス・インスタンスの実行履歴に対するオフラインの学習を通じて得られ、これについては、詳細に後述する。加えて、図５で与えられる確率は、例示にすぎず、本発明に対して限定するものではない。

次に、必須カバー集合の概念を紹介する。必須カバー集合は、サービス・インスタンスに対応し、それは、サービス・インスタンスが基づいているサービスを提供する能力を有する１つまたは複数のセンサの様々な組合せの集合である。図６は、センサとサービス・インスタンスとの配置関係を例示する図である。図６では、１０個のセンサ（丸ドット）と、３つのサービス・インスタンス（四角ドット）とが示されている。これらのセンサは、ＩｏＴの種々の領域内に位置し得る。センサ情報およびサービス・インスタンス情報に従って、オフライン状態で、必須カバー集合を自動的に生成することが可能である。たとえば、センサ情報は、たとえばセンサのカバレッジ（範囲）およびセンサの座標を含むことができ、サービス・インスタンス情報は、たとえばサービス・インスタンスの座標を含むことができる。図６のサービス・インスタンス１を一例として挙げると、センサ情報およびサービス・インスタンス情報に従って、オフライン状態で、サービス・インスタンス１の必須カバー集合Ｓ_１＝｛｛１｝，｛３｝，｛５｝，｛１、３｝，｛１、５｝，｛３、５｝，｛１、３、５｝｝を自動的に生成することが可能である。必須カバー集合内の各組合せ（すなわち、各要素）は、サービス・インスタンスが基づいているサービスを提供する能力を有する。つまり、センサ１、３、または５を単独でオンするだけでなく、センサ（１、３）、（１、５）、（３、５）または（１、３、５）を同時にオンにすると、サービス・インスタンス１が基づいているサービスを提供することができる。

必須カバー集合を自動的に生成することに加えて、時には、他の複雑な因子を考慮して、あらかじめ手動で必須カバー集合を設定することも可能である。たとえば、図６の例に関して、次のようにあらかじめ様々な必須カバー集合を設定することが可能である。
Ｓ_１＝｛｛１｝，｛３、５｝｝
Ｓ_２＝｛｛２、４｝，｛２、５｝，｛４、５｝｝
Ｓ_３＝｛｛６｝，｛５、８｝，｛８、９｝｝
Ｓ_{｛１，２｝}＝Ｓ_１×Ｓ_２
Ｓ_{｛２，３｝}＝Ｓ_２×Ｓ_３
Ｓ_{｛１，３｝}＝Ｓ_１×Ｓ_３
Ｓ_{｛１，２，３｝}＝Ｓ_１×Ｓ_２×Ｓ_３
ただし、Ｓ_ｉは、サービス・インスタンスｉの必須カバー集合を示し、Ｓ_{｛１，２｝}は、サービス・インスタンス１および２が同時に実行される条件を満たす必須カバー集合を示し、かつＳ_１×Ｓ_２に等しく、ここで演算子「×」は、Ｓ_１およびＳ_２のカルテシアン積を示す。たとえば、ここで、Ｓ_{｛１，２｝}＝｛｛１、２、４｝，｛１、２、５｝，｛１、４、５｝，｛２、３、４、５｝，｛２、３、５｝，｛３、４、５｝｝である。さらには、Ｓ_{｛２，３｝}、Ｓ_{｛１，３｝}およびＳ_{｛１，２，３｝}の定義は、Ｓ_{｛１，２｝}の定義と同様である。

図７は、本発明の一実施形態によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のための方法を示す流れ図である。このエネルギー管理方法は、ＩｏＴアプリケーション・インフラストラクチャ内のＩｏＴエネルギー管理サーバにおいて実行される。ＩｏＴエネルギー管理サーバは、ＩｏＴ全体に対して集中型エネルギー管理を実行するために使用される。図７の流れ図における処理は、次のステップ、すなわち、
ステップ７１０：予測するステップ、
ステップ７２０：選択するステップ、
ステップ７３０：制御するステップ
を含む。

以下では、図７の本発明のエネルギー管理方法の各ステップについて詳細に説明する。

ステップ７１０：予測するステップ
ステップ７１０では、サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスが予測される。

以下では、本発明のエネルギー管理方法の各ステップの説明は、特定の単純な一例との組合せで行う。図８は、センサとサービス・インスタンスとの配置関係の一例を示す図である。図８では、２つのセンサと１つのサービス・インスタンス、すなわち、センサ１、センサ２とサービス・インスタンス１とが存在する。図８のトポロジーによれば、２つのセンサの各々は、サービス・インスタンス１の実行を個々に満たすことができる。

ステップ７１０のサービス・インスタンス遷移モデルは、サービス・インスタンスの実行履歴に対するオフラインの学習を通じて得られる。図９は、図８の例に対応する、センサの使用履歴データおよびサービス・インスタンスの実行履歴の一例を示す図である。たとえば、本発明のエネルギー管理方法は、図９の決定点において実行される。図９の下層部分には、サービス・インスタンス１の実行履歴が示されている。図９のサービス・インスタンス１の実行履歴によれば、サービス・インスタンス１の状態遷移について次の統計を得ることが可能である：原点と決定点との間に４５時間単位が存在することが仮定され、ここでは、３３時間単位で、サービス・インスタンスが継続実行中であり（すなわち、前の時間単位は実行のためにあり、後続の時間単位も実行のためにある）、４時間単位で、実行から消失までであり、４時間単位で、消失から実行までであり、４時間単位で、継続消失中である。

サービス・インスタンス１の実行履歴の上記の統計によれば、次の時間期間（決定点から開始した所定の時間期間）では、サービス・インスタンス１が継続して実行されることになる確率は、３３／（３３＋４）＝０．８９、サービス・インスタンス１が停止する確率は、４／（３３＋４）＝０．１１、非サービス・インスタンス状態からサービス・インスタンス１の実行へと遷移する確率は、４／（４＋４）＝０．５、非サービス・インスタンス状態を維持する確率は、４／（４＋４）＝０．５であることを推論することが可能である。したがって、図１１に示す状態遷移図が得られる。

図１１は、図９の例に基づくサービス・インスタンス状態遷移図を示している。遷移確率を含むサービス・インスタンス状態遷移図は、ステップ７１０のサービス・インスタンス遷移モデルに対応する。図１１のサービス・インスタンス遷移モデルによれば、サービス・インスタンス１が現在、サービスを受けていると仮定すると（図９参照）、ステップ７１０で、サービスを受けることになる次のサービス・インスタンスが予測される。ランダム選択ポリシ−が、本発明では採用される。ここで、乱数ｒａｎｄ（ｒａｎｄは、［０，１］の範囲の乱数である）が生成され、サービス・インスタンス１から外側へ遷移する確率と比較され、次が得られる：
ｒａｎｄ≦０．８９→サービス・インスタンス１
ｒａｎｄ＞０．８９→該当なし
ただし、「該当なし」は、サービスを受けるサービス・インスタンスがない状態を示す。したがって、生成された乱数によれば、次の時間期間（サイクル）にサービスを受けることになるサービス・インスタンスが予測される。ｒａｎｄ＝０．３と仮定すると、ステップ７１０で、サービス・インスタンス１は、次の時間期間にサービスを受けることになると予測される。

上記では、最も単純な一例が、説明をしやすくするためにのみ与えられているにすぎない。実際には、複数のサービス・インスタンスがＩｏＴにおいて同時に実行されることになる。これらのサービス・インスタンスの実行履歴によれば、図５および図１１のものと同様のサービス・インスタンス状態遷移図をやはり得ることができる。サービス・インスタンスが多ければ多いほど、遷移図もより複雑になる。

本発明の発明者らは、エネルギー管理が、サービス・インスタンス指向の方式では実行すべきであるが、センサ指向の方式では直接的には実行すべきでないことを提案している。ここで、その理由は、図８および図９を参照して与えられる。ここで、図８のセンサのＯＮ／ＯＦＦ状態は、ＯＮ：１、ＯＦＦ：０と定義され、それにより、センサの４種類のＯＮ／ＯＦＦ状態（センサ２、センサ１）、すなわち（０，１）、（１，０）、（１，１）、（０，０）が得られる。センサの使用履歴データは、図９の上層部分に示す通りであることが仮定される。同様に、原点と決定点との間に４５時間単位が存在する。また、図から測度は、センサ１は、３２時間単位の総時間でＯＮであり、１３時間単位の総時間でＯＦＦであり、センサ２は、２０時間単位の総時間でＯＮであり、２５時間単位の総時間でＯＦＦであることが仮定される。

図９によれば、センサＯＮ／ＯＦＦ状態の遷移頻度と遷移確率は、次のように得られる：
（０，０）→（０，１）：１回⇒０．５ （１，０）→（０，１）：０回⇒０
（０，０）→（１，０）：１回⇒０．５ （１，０）→（０，０）：０回⇒０
（０，０）→（１，１）：０回⇒０ （１，０）→（１，１）：２回⇒１

（１，１）→（０，１）：２回⇒０．６７ （０，１）→（１，１）：１回⇒０．３３
（１，１）→（０，０）：０回⇒０ （０，１）→（０，０）：２回⇒０．６７
（１，１）→（１，０）：１回⇒０．３３ （０，１）→（１，０）：０回⇒０
ただし、上記の遷移確率は、対応する状態遷移の回数に基づいて計算される。たとえば、（０，０）から生じる状態遷移は、２回起こり、１回は（０，１）に遷移し、１回は（１，０）に遷移する。したがって、対応する遷移確率は、それぞれ０．５である。

こうして、図１０に示すセンサＯＮ／ＯＦＦ状態遷移図が得られる。図１０から分かるように、現在の状態（０，１）においては、決定点で状態（０，０）に遷移することが最も可能性が高く、状態（０，０）においては、センサ１とセンサ２は両方とも、オフにされることになる。しかしながら、一方、図９から分かるように、実際には、サービス・インスタンス１は、決定点の後でもまだ実行される。そのため、センサＯＮ／ＯＦＦ状態遷移図に従って実行されるセンサＯＮ／ＯＦＦ制御は、将来には、サービス・インスタンス１の実行を満たさなくなり、したがって、サービス品質は満足を得ない。

加えて、センサＯＮ／ＯＦＦ状態遷移図に基づく方法の複雑さは、あまりにも大きすぎる。ネットワークがＮ個のセンサおよびＭ個のサービス・インスタンスを合計で有すると仮定すると、センサＯＮ／ＯＦＦ状態遷移図に基づく方法は、２^Ｎの異なる状態を記録しなくてはならず、計算される各状態は、記録するのにＮ個のビットが必要である。それによって、合計Ｎ２^Ｎビットが記憶されなくてはならない。ＩｏＴでは、センサの数Ｎは、概して、数百万もの程度あり、この数は、一般のサーバのストレージ能力をはるかに超えており、これは実施上、実践的ではない。たとえば、Ｎ＝１０００とすると、Ｎ２^Ｎ＝１．３ｅ^３０３バイト。

しかしながら、本発明のサービス・インスタンス遷移モデルに基づく方法では、単に２^Ｍの異なる状態が記録されればよく、Ｍ２^Ｍビットが記憶されることになる。ＩｏＴのシナリオでは、サービス・インスタンスの数は、概して、小さい（たとえば、Ｍ＝１０。これは、たとえば、ある種類のセンサが大量に工場内に配置されるものの、これらは同じ仕事を実行するからである）。そのため、この方法における計算およびストレージの複雑さは、センサＯＮ／ＯＦＦ状態遷移図に基づく方法においてよりもはるかに低い。たとえば、Ｍ＝２０とすると、Ｍ２^Ｍ＝２．６メガバイト。

加えて、本発明のエネルギー管理方法は、リアル・タイムの方式で実行されることも分かる。１つの実施形態では、（たとえば、図１１の）サービス・インスタンス遷移モデルは、サービス・インスタンスの実行履歴に対するオフラインの学習を通じて得られる。この学習は、サービス・インスタンス遷移モデルが定期的に更新されるように、定期的に実行される。たとえば、本発明のシステムまたは方法がオンラインになるように準備ができているとき、または所定のタイミングでもしくは間隔で、サービス・インスタンスの最新の実行履歴を基にして、現在のサービス・インスタンス遷移モデルが学習を通じて得られる。次いで、実行されると、本発明のシステムおよび方法は、このサービス・インスタンス遷移モデルを使用して前記予測を行う。そうすることで、実行中のアプリケーションの動的変化を考慮することができる。たとえば、夜間に実行されるアプリケーションによって使用されるサービス・インスタンスは、昼間に実行されるアプリケーションによって使用されるサービス・インスタンスとはまったく異なっていることがある。

ステップ７２０：選択するステップ
ステップ７２０で、ターゲット・サービス・インスタンスに対応する必須カバー集合、必須カバー集合におけるセンサの使用履歴データ、およびセンサのエネルギー・パラメータによれば、ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合が選択される。

なおも、図８および図９の場合を、説明のための一例として挙げる。上述のように、上記のアルゴリズムによれば、ステップ７１０で、サービス・インスタンス１は、次の時間期間にサービスを受けることになると予測されることが仮定される。サービス・インスタンス１に対応する必須カバー集合は、Ｓ_｛１｝＝｛｛１｝，｛２｝，｛１、２｝｝である。つまり、センサ１およびセンサ２は、サービス・インスタンス１を別々に満足させることも、または互いとの組合せで満足させることもできる。必須カバー集合は、自動的に生成されても、またはあらかじめ設定されてもよい。

次に、ステップ７２０で、１つまたは複数のどのセンサがサービス・インスタンス１を満足するために使用されるかを選択することが必要である。

必須カバー集合Ｓ_｛１｝におけるセンサ（センサ１およびセンサ２）の使用履歴データは、上述した通りであり、すなわち、センサ１は、３２時間単位の総時間でＯＮであり、１３時間単位の総時間でＯＦＦであり、センサ２は、２０時間単位の総時間でＯＮであり、２５時間単位の総時間でＯＦＦである。たとえば、センサのエネルギー・パラメータは、少なくとも、センサの最初のエネルギー、センサの単位時間ごとに消費されるエネルギー、およびセンサのＯＮ／ＯＦＦの単回操作によって消費されるエネルギーを含む。図８および図９の例では、次のセンサ・エネルギー・パラメータが存在することが仮定される：
・ センサ１のみＯＮである：０．１エネルギー単位（Ｅ）／時間単位が消費される
・ センサ２のみがＯＮである：０．１エネルギー単位／時間単位が消費される
・ 各センサの最初のエネルギーは１０Ｅであり、センサのＯＮ／ＯＦＦ各操作は０．１Ｅエネルギーを消費する
・ センサ１とセンサ２の両方がＯＮであるとき、その各々は、０．１エネルギー単位／単位時間を消費する

図９の上層部分によれば、この統計により次が得られる：決定点までは、センサ１のＯＮ／ＯＦＦ操作は、６回実行され、これにより０．６Ｅエネルギーが消費され、センサ１は、３２時間単位でＯＮであり、これにより３．２Ｅエネルギーが消費され、したがって１０Ｅ−０．６Ｅ−３．２Ｅ＝６．２Ｅエネルギーが残存する；センサ２のＯＮ／ＯＦＦ操作は、４回実行され、これにより０．４Ｅエネルギーが消費され、センサ２は２０時間単位でＯＮであり、これにより２．０Ｅエネルギーが消費され、したがって１０Ｅ−０．４Ｅ−２．０Ｅ＝７．６Ｅエネルギーが残存する。

ステップ７２０での選択は、１つの実施形態において、エネルギー消費率に基づいており、それは、ターゲット・サービス・インスタンスに対応する必須カバー集合、必須カバー集合におけるセンサの使用履歴データ、およびセンサのエネルギー・パラメータに従って計算され、この場合、必須カバー集合における各組合せが選択される。

本発明では、各センサのエネルギー消費率は、

と定義され、ただし、

は、ｉ番目のセンサのエネルギー消費率であり、

は、ｉ番目のセンサのＯＮの総時間であり、Ｔは、総統計時間期間であり、е_ｉは、ｉ番目のセンサのＯＮ／ＯＦＦの単回操作によって消費されるエネルギーであり、Ε_ｉは、ｉ番目のセンサの残存エネルギーであり、γ_１およびγ_２は、設定された重み係数である。

必須カバー集合における各組合せが選択される場合のエネルギー消費率は、

であり、ただし、Ｓは必須カバー集合を示す。

１つの実施形態では、たとえば、パラメータは、次のように設定される：γ_１＝０．２かつγ_２＝０．８。以下では、必須カバー集合における各要素が選択される場合のエネルギー消費率が計算される。

次の時間期間に、センサ１のみが（Ｓ_｛１｝における｛１｝に対応する）サービスを提供する場合、センサ１のエネルギー消費率は、

と計算され、ここでは、現在の状態は（０，１）であり、センサ１は、ＯＮ状態にあり、したがって、センサのＯＮ／ＯＦＦ操作を実行する必要はなく、それによってе_ｉ＝０となり、Ｔは時間単位である。加えて、

は、Ｓ_｛１｝のエネルギー消費率を示す。

次の時間期間に、センサ２のみが（Ｓ_｛１｝における｛２｝に対応する）サービスを提供する場合、センサ２のエネルギー消費率は、

と計算される。

次の時間期間に、センサ１およびセンサ２が（Ｓ_｛１｝における｛１、２｝に対応する）サービスを互いとの組合せで提供する場合、センサ１とセンサ２のエネルギー消費率は、

と計算される。

サービス・インスタンス１を満たすのにステップ７１０における予測に基づいて、センサ１およびセンサ２が同時にＯＦＦであることは不可能であるので、センサ１およびセンサ２が同時にＯＦＦである場合については考慮しない。

次いで、エネルギー消費率に基づいて、ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合が選択される。具体的には、上記の例では、計算された３つのエネルギー消費率が比較され、最小のエネルギー消費率に対応するセンサ集合が選択される。

現在の例では、必須カバー集合Ｓ_｛１｝における要素｛２｝が選択され、すなわち、ＯＮセンサ集合は｛２｝である。つまり、次の時間期間に、センサ２がオンにされるように選択される。

一方、ステップ７１０で次の時間期間にサービスを受けることになると予測されるサービス・インスタンスがないことを仮定する場合、センサはすべて、ステップ７２０で、単にオフにされる。

上記のエネルギー消費率は、単に、本発明において与えられた一例にすぎない。オンにすべきセンサの組合せの選択が同様になされ得るように、センサの様々な組合せを比較するために使用される他の指標（たとえば、ＯＮ／ＯＦＦ操作によって消費されるエネルギーは考慮されない）を当業者なら思い付く可能性もある。

ステップ７３０：制御するステップ
ステップ７３０では、次の時間期間が開始すると、ＯＮ／ＯＦＦ制御がＩｏＴにおけるセンサに対して実行され、ＯＮセンサ集合におけるセンサはオンにされ、ＯＮセンサ集合におけるこれらのセンサ以外のセンサはオフにされる。

たとえば、上記の例によれば、ステップ７３０では、次の時間期間が開始すると（すなわち、図９の決定点で）、ＯＮセンサ集合｛２｝におけるセンサ２はオンにされ、センサ集合｛２｝におけるこのセンサ以外のセンサ、すなわち、センサ１はオフにされる。

図１２は、本発明の別の実施形態によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のための方法を示す流れ図である。図１２の流れ図における処理は、次のステップ：予測するステップ１２１０、選択するステップ１２２０、制御するステップ１２３０、および更新するステップ１２４０を含み、ここでは、ステップ１２１０からステップ１２３０の処理は、図７のステップ７１０からステップ７３０の処理と同様である。

更新するステップ１２４０では、次の時間期間におけるセンサの使用量により、センサの使用履歴データが更新される。つまり、図９の上層部分に説明される方式で、次の時間期間におけるセンサ１とセンサ２の使用履歴データの蓄積が継続される。

ステップ１２４０の後、処理はステップ１２２０に戻り、ステップ１２２０からステップ１２４０は、定期的に実行される。第２の実行からは、各実行中にステップ１２２０において使用されたセンサの使用履歴データは、最後の実行中にステップ１２４０において更新されるセンサの使用履歴データである。

上記では、本発明の独創的概念は、単純な例によって説明されている。しかしながら、本発明は、開示される特定の実施形態、または特定のパラメータ値に限定されない。たとえば、上記のエネルギー消費率は、他の式によって与えられてもよく、γ_１およびγ_２が、たとえば、０．３および０．７にも設定可能、等々である。

図１３は、本発明によるＩｏＴにおけるサービス・インスタンス指向のエネルギー管理のためのシステム１３００を示している。エネルギー管理システム１３００は、予測手段１３１０、選択手段１３２０、および制御手段１３３０を含む。予測手段１３１０は、サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測する。選択手段１３２０は、ターゲット・サービス・インスタンスに対応する必須カバー集合、必須カバー集合におけるセンサの使用履歴データ、およびセンサのエネルギー・パラメータに従って、ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択する。制御手段１３３０は、次の時間期間が開始すると、ＩｏＴにおけるセンサに対してＯＮ／ＯＦＦ制御し、ＯＮセンサ集合におけるセンサはオンにされ、ＯＮセンサ集合におけるこれらのセンサ以外のセンサはオフにされる。

別の実施形態では、エネルギー管理システム１３００は、更新デバイス１３４０をさらに備えることができる。更新デバイス１３４０は、時間期間におけるセンサの使用量に従って、センサの使用履歴データを更新する。

当業者には理解されるであろうように、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として実装可能である。したがって、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書では、「回路」、「モジュール」、もしくは「システム」とすべて概括的に称することもあるソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形を取ってもよい。さらには、本発明の態様は、コンピュータ可読プログラム・コードを実装した１つまたは複数のコンピュータ可読媒体において実装されるコンピュータ・プログラム製品の形態を取ってもよい。

１つまたは複数のコンピュータ可読媒体の任意の組合せを用いてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体であっても、またはコンピュータ可読ストレージ媒体であってもよい。コンピュータ可読ストレージ媒体は、たとえば、電子、磁気、光学、電磁、赤外線、または半導体のシステム、装置、もしくはデバイス、あるいは前述の任意の適切な組合せとすることができるが、これらに限定されない。コンピュータ可読ストレージ媒体のより具体的な例（包括的でないリスト）は、次、すなわち、１つまたは複数のワイヤを含む電気接続部、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、光学ストレージ・デバイス、磁気ストレージ・デバイス、または前述の任意の適切な組合せを含むことになる。ここでは、コンピュータ可読ストレージ媒体は、命令実行システム、装置、もしくはデバイスによって、または命令実行システム、装置、もしくはデバイスに接続して使用されるためのプログラムを含んでいる、あるいは記憶していることが可能な任意の有形媒体であってもよい。

コンピュータ可読信号媒体は、たとえば、ベースバンド内で、または搬送波の一部として、コンピュータ可読プログラム・コードを実装した伝搬データ信号を含むことができる。そのような伝搬信号は、電磁、光学、またはそれらの任意の適切な組合せを含む様々な形態のいずれかを取ってもよいが、これらに限定されない。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ命令実行システム、装置、もしくはデバイスによって、または命令実行システム、装置、もしくはデバイスに接続して使用されるためのプログラムを通信する、伝搬する、あるいは輸送することができる任意のコンピュータ可読媒体であってもよい。

コンピュータ可読媒体に実装されるプログラム・コードは、ワイヤレス、有線、光ファイバ・ケーブル、ＲＦなど、または前述の任意の適切な組合せを含む任意の適切な媒体を使用して伝送可能であるが、これらに限定されない。

本発明の態様に関して動作を遂行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、またはＣ＋＋などのオブジェクト指向のプログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組合せにおいて記述可能である。プログラム・コードは、スタンドアロンのソフトウェア・パッケージとしてユーザのコンピュータに全体的に、ユーザのコンピュータに部分的に、ユーザのコンピュータに部分的にかつリモート・コンピュータに部分的に、またはリモート・コンピュータもしくはサーバに全体的に、実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）、もしくは広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通じて、ユーザのコンピュータに接続されても、またはこの接続が外部コンピュータに対して（たとえば、インターネット・サービス・プロバイダを使用してインターネットを通じて）なされてもよい。

本発明の態様について、本発明の実施形態により方法、装置（システム）およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照して後述する。流れ図またはブロック図あるいはその両方の各ブロック、および流れ図またはブロック図あるいはその両方のブロックの組合せは、コンピュータ・プログラム命令によって実施可能であることは理解されよう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、専用コンピュータ、またはマシンを生み出すための他のプログラマブル・データ処理装置のプロセッサに提供可能であり、したがって、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行する命令は、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定された機能／行為を実施するための手段を創出する。

これらのコンピュータ・プログラム命令はまた、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスを特定の方式で機能するように指図可能なコンピュータ可読媒体に記憶されてもよく、したがって、コンピュータ可読媒体に記憶された命令は、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定された機能／行為を実施する命令を含む製造品を生み出す。

コンピュータ・プログラム命令はまた、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードされて、一連の動作ステップをこのコンピュータ、他のプログラマブル装置、または他のデバイス上で実行させて、コンピュータ実施方法を生み出すことができ、したがって、コンピュータまたは他のプログラマブル装置で実行する命令は、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／行為を実施するための方法を提供する。

図における流れ図およびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示している。この点で、流れ図またはブロック図における各ブロックは、指定された論理機能（複数可）を実施するための１つまたは複数の実行可能な命令を含むコード・モジュール、コード・セグメント、またはコードの一部分を表すことが可能である。いくつかの代替の実装形態では、ブロック内に記された機能は、図の中に記された順序から外れて行われてもよいことにも留意されたい。たとえば、連続して示されている２つのブロックは、実際には、実質的に並行して実行可能であり、またはブロックは、時には、関与する機能に応じて、逆の順序で実行されてもよい。ブロック図または流れ図あるいはその両方の各ブロック、およびブロック図または流れ図あるいはその両方のブロックの組合せは、指定された機能または行為、あるいは専用ハードウェアおよびコンピュータ命令の組合せを実行する専用ハードウェアベースのシステムによって実施可能であることも分かるであろう。

Claims (23)

1. モノのインターネット（ＩｏＴ：Internet of Things）におけるサービス・インスタンス指向のエネルギー管理方法であって、
   サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測するステップと、
   前記ターゲット・サービス・インスタンスに対応する必須カバー集合、前記必須カバー集合におけるセンサの使用履歴データ、および前記センサのエネルギー・パラメータに従って、前記ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択するステップと、
   前記時間期間の開始に応答して、前記ＯＮセンサ集合における前記センサはオンにされ、前記ＯＮセンサ集合における前記センサ以外のセンサはオフにされるように、前記ＩｏＴにおける前記センサに対してＯＮ／ＯＦＦ制御するステップと
   を含むエネルギー管理方法。
2. 前記サービス・インスタンスが、センサの組合せに基づいて提供され得るサービスのインスタンスである、請求項１に記載のエネルギー管理方法。
3. サービス・インスタンスに対応する前記必須カバー集合は、前記サービス・インスタンスが基づいているサービスを提供する能力を有する１つまたは複数のセンサの様々な組合せの集合である、請求項２に記載のエネルギー管理方法。
4. 前記時間期間におけるセンサの使用量に従って、センサの前記使用履歴データを更新するステップをさらに含み、
   前記選択するステップ、前記制御するステップ、および前記更新するステップが、定期的に実行され、第２の実行からは、各実行中に前記選択するステップにおいて使用されるセンサの前記使用履歴データが、最後の実行中に前記更新されるステップにおいて更新されるセンサの前記使用履歴データである、請求項１に記載のエネルギー管理方法。
5. 前記センサの前記エネルギー・パラメータが、少なくとも、前記センサの最初のエネルギー、前記センサの単位時間ごとに消費されるエネルギー、および前記センサのＯＮ／ＯＦＦの単回操作によって消費されるエネルギーを含む、請求項１に記載のエネルギー管理方法。
6. 前記選択は、前記必須カバー集合における各組合せが選択されるとき、前記ターゲット・サービス・インスタンスに対応する前記必須カバー集合、前記必須カバー集合におけるセンサの前記使用履歴データ、および前記センサのエネルギー・パラメータに従って計算されるエネルギー消費率に基づいている、請求項１に記載のエネルギー管理方法。
7. 前記必須カバー集合が、あらかじめ設定される、請求項１に記載のエネルギー管理方法。
8. 前記必須カバー集合が、センサの情報およびサービス・インスタンスの情報に従って、オフライン状態で自動的に生成される、請求項１に記載のエネルギー管理方法。
9. 前記センサが、前記ＩｏＴの種々の領域に位置している、請求項１に記載のエネルギー管理方法。
10. 前記サービス・インスタンス遷移モデルが、サービス・インスタンスの実行履歴に対するオフラインの学習を通じて取得される、請求項１に記載のエネルギー管理方法。
11. 前記学習は、前記サービス・インスタンス遷移モデルが定期的に更新されるように、定期的に実行される、請求項１０に記載のエネルギー管理方法。
12. モノのインターネット（ＩｏＴ：Internet of Things）におけるサービス・インスタンス指向のエネルギー管理システムであって、
    サービス・インスタンス遷移モデルに基づいて、後続の時間期間にサービスを受けることになるターゲット・サービス・インスタンスを予測するように構成された予測手段と、
    前記ターゲット・サービス・インスタンスに対応する必須カバー集合、前記必須カバー集合におけるセンサの使用履歴データ、および前記センサのエネルギー・パラメータに従って、前記ターゲット・サービス・インスタンスが基づいているサービスを提供するために、オンにすべきＯＮセンサ集合を選択するように構成された選択手段と、
    前記時間期間の開始に応答して、前記ＯＮセンサ集合における前記センサはオンにされ、前記ＯＮセンサ集合における前記センサ以外のセンサはオフにされるように、前記ＩｏＴにおける前記センサに対してＯＮ／ＯＦＦ制御するように構成された制御手段と
    を備えるエネルギー管理システム。
13. 前記サービス・インスタンスが、センサの組合せに基づいて提供され得るサービスのインスタンスである、請求項１２に記載のエネルギー管理システム。
14. サービス・インスタンスに対応する前記必須カバー集合は、前記サービス・インスタンスが基づいているサービスを提供する能力を有する１つまたは複数のセンサの様々な組合せの集合である、請求項１３に記載のエネルギー管理システム。
15. 前記センサの前記エネルギー・パラメータが、少なくとも、前記センサの最初のエネルギー、前記センサの単位時間ごとに消費されるエネルギー、および前記センサのＯＮ／ＯＦＦの単回操作によって消費されるエネルギーを含む、請求項１２に記載のエネルギー管理システム。
16. 前記選択手段では、前記必須カバー集合における各組合せが選択されるとき、前記選択が、前記ターゲット・サービス・インスタンスに対応する前記必須カバー集合、前記必須カバー集合におけるセンサの前記使用履歴データ、および前記センサのエネルギー・パラメータに従って計算されるエネルギー消費率に基づいている、請求項１２に記載のエネルギー管理システム。
17. 前記必須カバー集合が、あらかじめ設定される、請求項１２に記載のエネルギー管理システム。
18. 前記必須カバー集合が、センサの情報およびサービス・インスタンスの情報に従って、オフライン状態で自動的に生成される、請求項１２に記載のエネルギー管理システム。
19. 前記センサが、前記ＩｏＴの種々の領域に位置している、請求項１２に記載のエネルギー管理システム。
20. 前記サービス・インスタンス遷移モデルが、サービス・インスタンスの実行履歴に対するオフラインの学習を通じて取得される、請求項１２に記載のエネルギー管理システム。
21. 前記学習は、前記サービス・インスタンス遷移モデルが定期的に更新されるように、定期的に実行される、請求項１９に記載のエネルギー管理システム。
22. 前記時間期間におけるセンサの使用量に従って、センサの前記使用履歴データを更新するように構成された更新手段をさらに備える、請求項１２に記載のエネルギー管理システム。
23. コンピュータにおいて実行されると、請求項１ないし１１のいずれかに記載の方法ステップを実行するように適合されているプログラム・コードを備えるコンピュータ・プログラム。

Images