JP7267871B2 - 省電力デバイス管理方法、及び省電力デバイス管理システム - Google Patents

Description

本発明は、省電力デバイス管理方法、及び省電力デバイス管理システムに関する。

センサやデバイスといった「モノ」がインターネットを通じてクラウドやサーバに接続され、情報交換することにより相互に制御するＩｏＴ（Internet of Things）という仕組みがある。ＩｏＴのシステムでは、センサやデバイスの生死監視（死活監視：alive monitoring）や状態監視、設定変更やファームウェアアップデート（以下、「ＦＷアップデート」と略す）といったデバイスの運用管理が求められる。

デバイスの中には、電源に接続されたものだけでなく、電源が得られない場所に設置するため、バッテリ駆動の省電力デバイスも存在する。また、バッテリ駆動のデバイスに対しては、定期的に保守員が派遣され、バッテリ交換を行う。このようなバッテリ駆動のデバイスは、保守員の派遣間隔を伸ばすため、バッテリが長持ちするように、必要な時間帯だけ起動し、その他の時間帯はスリープするといった動きをする。そのため、管理サーバからデバイスの状態確認や設定変更を行おうとしても、デバイスは応答できず、結果として、デバイスの管理ができないことがあるという問題があった。

これに対し、特許文献１では、常時接続でないデバイスに対し、デバイスシャドウを用いて非同期に状態確認、設定変更又はＦＷアップデートを可能とする、といった技術が開示されている。

一方、非同期で設定変更やＦＷアップデートを行う際に、何れの原因でデバイス状態が不明になったのか判断できず、状態不明のデバイスが発生するというリスクを伴う。デバイス状態が不明になる原因として、例えば、まだ起動タイミングが来ていないという原因、起動したが通信状況が悪くて状態通知を出来なかったという原因、或いは、ＦＷアップデートに失敗して故障したという原因があり得る。このような原因のうちのいずれの原因でデバイス状態が不明になったのかは判断できず、予定外に保守員が駆けつけてデバイスの状態を確認する必要があり、故に、高い保守コストを要するという問題が生じる。

US2018/0091391

特許文献１に開示された技術では、バッテリ駆動の省電力デバイスの運用管理において、(A)故障以外の原因（バッテリ残量不足）を回避する技術、及び、(B)状態不明な状況を作らないようにする制御技術が必要となった。本発明は、上記課題を解決するためになされたものであり、その目的とするところは、デバイスのバッテリ残量不足を回避しデバイスの状態不明な期間を短縮するとともに保守員派遣の軽減が可能な省電力デバイス管理方法を提供することにある。

上記課題を解決する本発明は、管理対象のデバイスから、それらデバイスのバッテリ残量を含むステータスを表すステータス情報を収集し、複数のデバイスの各々のオペレーションのスケジュールを表す情報であるオペレーションスケジュール管理情報から、デバイスの今後のオペレーションをデバイス制御部が特定し、複数のデバイスの各々についてバッテリ消費量とオペレーションとの関係を表してリスク情報も含むＫＰＩ管理情報から、デバイスの今後のオペレーションに対応したバッテリ消費量を推定し、推定されたバッテリ消費量と、収集されたステータス情報が表すバッテリ残量とを基に、モデル部がデバイスのバッテリ寿命を予測し、予測されたバッテリ寿命を基に、各デバイスへの保守員派遣の要否及び巡回スケジュールを決定する、というものである。

本発明によれば、バッテリ残量不足の回避及びリスクのあるオペレーションによる状態の不明な期間を短縮するとともに、無駄な保守員派遣を減らして保守コストの軽減が可能な省電力デバイス管理方法を提供できる。

本発明の一実施形態に係る省電力デバイス管理システムを含むシステム全体の概略構成を示すブロック図である。 デバイスの構成を示すブロック図である。 基地局の構成を示すブロック図である。 シャドウサーバの構成を示すブロック図である。 シャドウサーバが保持するデバイスシャドウ管理コレクションの構成を示す説明図である。 シャドウサーバが保持するシャドウ情報取得部の処理の流れを示すフローチャートである。 シャドウサーバが保持するシャドウ情報更新部の処理の流れを示すフローチャートである。 シャドウサーバが保持するシャドウ情報削除部の処理の流れを示すフローチャートである。 デバイス管理サーバの構成を示すブロック図である。 デバイス管理サーバが保持するデバイス管理コレクションの構成を示した説明図である。 デバイス管理サーバが保持するＫＰＩ管理コレクションの構成を示した説明図である。 デバイス管理サーバが保持するオペレーションスケジュール管理コレクションの構成を示した説明図である。 デバイス管理サーバが保持するＦＷアップデート要件管理コレクションの構成を示した説明図である。 デバイス管理サーバが保持するＦＷアップデートスケジュール管理コレクションの構成を示した説明図である。 デバイス管理サーバが保持するモデル部の処理の流れを示すフローチャートである。 デバイス管理サーバが保持するデバイス制御部の処理の流れを示すフローチャートである。 保守管理サーバの構成を示すブロックである。 保守管理サーバが保持する保守員管理コレクションの構成を示した説明図である。 保守管理サーバが保持するデバイス情報管理コレクションの構成を示した説明図である。 保守管理サーバが保持する巡回スケジュール管理コレクションの構成を示した説明図である。 保守管理サーバが保持する保守管理部の処理の流れを示すフローチャートである。

以下、図面を用いて本発明の一実施形態に係る省電力デバイス管理システム及び方法を説明する。なお、以下の説明では、「ｘｘｘコレクション」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよい。従って、「ｘｘｘコレクション」を「ｘｘｘ情報」ということができる。

図１は、省電力デバイス管理システムを含むシステム全体の概略構成を示すブロック図である。図１に示すように、少なくとも一つのデバイス１と、少なくとも一つの基地局２と、シャドウサーバ３と、デバイス管理サーバ４と、保守管理サーバ５とがある。デバイス１と、基地局２とは、無線ネットワーク６で接続されている。また、基地局２と、シャドウサーバ３と、デバイス管理サーバ４と、保守管理サーバ５と、は管理ネットワーク７で接続されている。基地局２は、デバイス１とシャドウサーバ３との間の通信を中継する。ここでは、複数のデバイス１が遠隔地に分散配置され、複数の基地局２により中継された状態を例示している。省電力デバイス管理システム１００は、例えば、シャドウサーバ３、デバイス管理サーバ４及び保守管理サーバ５を含む。省電力デバイス管理システム１００は、１つ以上のコンピュータにより実現されてよい。

図２は、デバイス１の構成を示すブロック図である。図２に示すように、デバイス１は、メモリ１２と、記憶装置１３と、入力装置１４と、出力装置１５と、無線通信ポート１６と、それらに接続されたＣＰＵ（Central Processing Unit）１１とを備える。このデバイス１は、無線通信ポート１６を通じて、基地局２を経由し、シャドウサーバ３へ自デバイスの状態を送信するほか、同様の経路における逆方向の通信により、設定変更通知を受信も行う。

図３は、基地局２の構成を示すブロック図である。図３に示すように、基地局２は、メモリ２２と、記憶装置２３と、アンテナ２４と、通信ポート２５と、それらに接続されたＣＰＵ２１とを備える。記憶装置２３は、デバイス１と基地局２との間の接続を確立する無線ネットワーク制御部２６と、基地局２と管理用ネットワーク７上の機器との接続を確立するゲートウェイ２７といった機能をＣＰＵ２１に実現させるための一つ以上のコンピュータプログラムを記憶する。当該一つ以上のコンピュータプログラムがメモリ２２にロードされＣＰＵ２１に実行されることで、無線ネットワーク制御部２６及びゲートウェイ２７が実現される。基地局２は、このように構成によって、デバイス１とシャドウサーバ３との間の通信を中継する。

図４は、シャドウサーバ３の構成を示すブロック図である。図４に示すように、シャドウサーバ３は、メモリ３２と、記憶装置３３と、入力装置３４と、出力装置３５と、通信ポート３６と、それらに接続されたＣＰＵ３１とを備える。

記憶装置３３は、データベース３７を格納する。また、記憶装置３３は、シャドウ情報取得部３９と、シャドウ情報更新部４０と、シャドウ情報削除部４１といった機能をＣＰＵ３１に実現させるための一つ以上のコンピュータプログラムを記憶する。当該一つ以上のコンピュータプログラムがメモリ３２にロードされてＣＰＵ３１に実行されることで、シャドウ情報取得部３９、シャドウ情報更新部４０及びシャドウ情報削除部４１が実現される。データベース３７は、デバイスシャドウを管理するための情報を保持するデバイスシャドウ管理コレクション３８を含む。

図５は、デバイスシャドウ管理コレクション３８の構成を示す説明図である。図５に示すように、デバイスシャドウ管理コレクション３８は、一つ又は複数のドキュメント９で構成される。

ドキュメント９は、例えば、デバイス毎のソフトウェアのアップデートを即時実行せずに情報保留して、仮に受け止めておくような仮置きのデータである。例えば、ドキュメント９は、デバイスを識別するデバイスＩＤを保持するdevice_id１６と、デバイスの状態を保持するstate１７と、を含む。state１７は、管理者が指示した値を保持するdesired１８と、デバイスが最後に送信したデバイス状態を保持するreported１９と、を含む。なお、管理者は、バッテリ残量不足と上記アップデートとを配慮して保守員の巡回スケジュールを最終的に意思決定する権能者である。なお、本明細書において、「バッテリ残量不足」とは、バッテリ残量が所定の閾値（例えばゼロ）以下になることを意味する。

図６は、シャドウ情報取得部３９の処理の流れを示すフローチャートである。図６に示すように、シャドウ情報取得部３９は、device_idが指定されたシャドウ情報取得要求を受信する（Ｓ１）。すると、シャドウ情報取得部３９は、デバイスシャドウ管理コレクション３８が保持するドキュメント９のうち、Ｓ１で受信した要求で指定されているdevice_idと一致するdevice_id１６を含むドキュメント９を取得する（Ｓ２）。シャドウ情報取得部３９は、Ｓ１で受信した要求に対する応答として、Ｓ２で取得したドキュメント９の内容を、Ｓ１で受信した要求の送信元へ返す（Ｓ３）。

図７は、シャドウ情報更新部４０の処理の流れを示すフローチャートである。図７に示すように、シャドウ情報更新部４０は、device_idが指定されたシャドウ情報更新要求を受信すると（Ｓ１１）、更新要求の種類を確認する（Ｓ１２）。更新要求の種類が“reported”の場合（Ｓ１２でreported）、シャドウ情報更新部４０は、更新要求に含まれる情報で、対象ドキュメント９（Ｓ１１で受信した要求で指定されているdevice_idと一致するdevice_id１６を含むドキュメント９）のreported１９の内容を更新する（Ｓ１３）。

次に、シャドウ情報更新部４０は、対象ドキュメント９における更新後のreported１９とdesired１８との差分を取得する（Ｓ１４）。差分があれば（Ｓ１５でＹｅｓ）、シャドウ情報更新部４０は、対象ドキュメント９に、Ｓ１４で取得された差分を表す情報である“delta”を追加し、“delta”を応答する（Ｓ１６）。このように応答することで、シャドウ情報更新部４０の処理が終了する。

一方、Ｓ１４の処理で差分が無ければ（Ｓ１５でＮｏ）、シャドウ情報更新部４０は、対象ドキュメント９の内容を応答する（Ｓ１８）。このように応答することで、シャドウ情報更新部４０の処理が終了する。

また、Ｓ１２の処理で更新要求の種類が“desired”の場合（Ｓ１２でdesired）、シャドウ情報更新部４０は、更新要求に含まれる情報で、対象ドキュメント９のdesired１８の内容を更新する（Ｓ１７）。次に、シャドウ情報更新部４０は、更新した対象ドキュメント９の内容を応答する（Ｓ１８）。以上がシャドウ情報更新部４０における処理の説明である。以下、シャドウ情報削除部４１の処理を説明する。

図８は、シャドウ情報削除部４１の処理の流れを示すフローチャートである。図８に示すように、シャドウ情報削除部４１は、device_idが指定されたシャドウ情報削除要求を受信すると（Ｓ４）、デバイスシャドウ管理コレクション３８が保持するドキュメント９のうち、対象ドキュメント９（Ｓ４で受信した要求で指定されているdevice_idと一致するdevice_id１６を含むドキュメント９）を削除してから（Ｓ５）、応答する（Ｓ６）。

図９は、デバイス管理サーバ４の構成を示すブロック図である。図９に示すように、デバイス管理サーバ４は、メモリ５２と、記憶装置５３と、入力装置５４と、出力装置９０５０と、通信ポート５６と、それらに接続されたＣＰＵ５１とを備える。記憶装置５３は、データベース４３を格納する。また、記憶装置５３は、モデル部４９と、デバイス制御部５０といった機能をＣＰＵ５１に実現させるための一つ以上のコンピュータプログラムを記憶する。当該一つ以上のコンピュータプログラムがメモリ５２にロードされてＣＰＵ５１に実行されることで、モデル部４９及びデバイス制御部５０が実現される。

データベース４３は、デバイス管理コレクション４４と、ＫＰＩ（Key Performance Indicator）管理コレクション４５と、オペレーションスケジュール管理コレクション４６と、ＦＷアップデート要件管理コレクション４７と、ＦＷアップデートスケジュール管理コレクション４８と、を含む。

図１０は、デバイス管理コレクション４４の構成を示した説明図である。図１０に示すように、デバイス管理コレクション４４は、一つ又は複数のドキュメント６０で構成される。ドキュメント６０は、例えば、デバイス毎のソフトウェアのアップデートを実行する段取りを示すデータである。例えば、ドキュメント６０には、デバイスを識別するデバイスＩＤを保持するdevice_id６１と、デバイス情報を保持するdevice_info６２と、バッテリ残量不足予測日時（バッテリ残量が不足すると予測される日時）を保持するbattery_prediction６３とが含まれる。これらを算出するための情報、例えば、図１１の“battery_consumption”６７、その他は、リスク情報として、ＫＰＩ管理コレクション４５にも含まれている。

device_info６２には、デバイスがデータを送信する間隔を保持する“interval”や、デバイスの感受性を保持する“sensitivity”や、バッテリ残容量（％）を保持する“battery”が含まれる。battery_prediction６３には、バッテリ残量不足予測日時を保持する“shortage_time”が含まれる。

図１１は、ＫＰＩ管理コレクション４５の構成を示した説明図である。図１１に示すように、ＫＰＩ管理コレクション４５は、一つ又は複数のドキュメント６５で構成される。ドキュメント６５には、デバイスを識別するＩＤを保持するdevice_id６６と、オペレーション毎のバッテリ消費量を保持するbattery_consumption６７とが含まれる。

battery_consumption６７は、デバイス起動時のバッテリ消費量を保持する”開始日”と、データ転送時のバッテリ消費量を保持する“data_translate”と、ＦＷアップデート時のバッテリ消費量を保持する“ＦＷ_update”とが含まれる。

図１２は、オペレーションスケジュール管理コレクション４６の構成を示した説明図である。図１２に示すように、オペレーションスケジュール管理コレクション４６は、一つ又は複数のドキュメント６９で構成される。ドキュメント６９には、オペレーションのスケジュールの情報が含まれている。オペレーションのスケジュールは、デバイス制御部５０が、巡回スケジュールと、今後の各デバイスのオペレーション予定から、後述する図１６のステップＳ３４，Ｓ３５の条件に基づいて定める。

ドキュメント６９は、例えば、デバイス毎のソフトウェアのアップデートを実行するスケジュールを示すデータである。ドキュメント６９には、例えば、デバイスを識別するＩＤを保持するdevice_id７０と、デバイスに対するオペレーションのスケジュールを保持するoperation_schedule７１とが含まれる。operation_schedule７１には、一つもしくは複数のスケジュールを保持するschedule７２が含まれる。schedule７２には、オペレーションを開始する日時を保持する“time”と、オペレーションの種類を保持する“operation”が含まれる。

なお、ＫＰＩ管理コレクション４５の各ドキュメント６５、及び、オペレーションスケジュール管理コレクション４６の各ドキュメント６９の少なくとも一つに、オペレーション毎のリスクの高さを表す情報が関連付けられてよい。或いは、図示しないが、オペレーション毎のリスクの高さを表すコレクションリスク管理コレクション（不図示）が、省電力デバイス管理システム１００における少なくとも一つのコンピュータに格納されていてもよい。ここでいう「リスク」とは、オペレーションに関してリスクとして定義された任意の事項でよく、「リスクの高さ」もまた、任意の高さでよい。

図１３は、ＦＷアップデート要件管理コレクション４７の構成を示した説明図である。図１３に示すように、ＦＷアップデート要件管理コレクション４７は、一つ又は複数のドキュメント７４で構成される。ドキュメント７４は、例えば、デバイス毎のソフトウェアで実行されるアップデートの実態的内容を示すデータである。ドキュメント７４には、例えば、デバイスを識別するＩＤを保持するdevice_id７５と、ＦＷアップデートの要件を保持するＦＷ_update_requirement７６とが含まれる。

ＦＷ_update_requirement７６は、ＦＷアップデートの実行期間を表し、例えば、アップデートするＦＷのバージョンを保持する“version”と、アップデートイメージを補完するレポジトリのＵＲＬを保持する“repository”と、アップデートイメージ配布開始日時を保持する“start”と、アップデートを行わなければならない最終期日を保持する“deadline”と、を含む。

なお、ＦＷアップデートは、オペレーションの一例である。オペレーション毎に、オペレーション要件コレクションが用意されてよい。当該コレクションは、デバイス毎にドキュメントを有してよい。各ドキュメントが、デバイスを識別するＩＤを保持するdevice_idと、オペレーションの要件を保持するoperation_requirementとを含んでよい。operation_requirementは、オペレーションの実行期間を表し、例えば、オペレーションの開始日時を表す“time”と、オペレーションのデッドラインを表す“deadline”と、を含んでよい。

図１４は、ＦＷアップデートスケジュール管理コレクション４８の構成を示した説明図である。図１４に示すように、ＦＷアップデートスケジュール管理コレクション４８は、一つ又は複数のドキュメント７８で構成される。ドキュメント７８は、デバイス毎のソフトウェアのアップデートを実行するスケジュールを示すデータである。ドキュメント７８には、例えば、デバイスを識別するＩＤを保持するdevice_id７９とＦＷアップデートのスケジュールを保持するＦＷ_update_schedule８０が含まれる。

ＦＷ_update_schedule８０には、アップデート日時を保持する“time”と、アップデートするＦＷのバージョンを保持する“version”と、アップデートイメージを補完するレポジトリのＵＲＬを保持する“repository”が含まれる。

図１５は、デバイス管理サーバ４が保持するモデル部４９の処理の流れを示すフローチャートである。図１５に示すように、モデル部４９は、デバイス管理コレクション４４が表すデバイス１全てに対して、ステップＳ２１～Ｓ２７のループ処理を実行する。まず、モデル部４９は、デバイス１を１つ選ぶ（Ｓ２１）。ここで選択されたデバイス１を、図１５の説明において「選択デバイス１」という。次に、モデル部４９は、シャドウサーバ３から、選択デバイス１のシャドウ情報を取得するとともに、デバイス管理サーバ４のデバイス管理コレクション４４から、現在のバッテリ残量を取得する（Ｓ２２）。

次に、モデル部４９は、バッテリ残量が５％以上か確認する（Ｓ２３）。なお、５％は、バッテリ残量の閾値の一例である。閾値は、０以上１００以下の範囲の任意の値を採用可能である。バッテリ残量が５％以上ある場合（Ｓ２３がＹｅｓ）、モデル部４９は、選択デバイス１について次のオペレーション（次に予定されるオペレーション）の情報を取得する（Ｓ２４）。具体的には、モデル部４９は、オペレーションスケジュール管理コレクション４６から、選択デバイスとdevice_id７０が一致するドキュメント６９を検索する。モデル部４９は、見つかったドキュメント６９から、次のオペレーションの情報を取得する。

モデル部４９は、選択デバイス１について次のオペレーションが必要とするバッテリ量を、選択デバイス１のバッテリの残容量から引く（Ｓ２５）。具体的には、モデル部４９は、ＫＰＩ管理コレクション４５から、選択デバイス１とdevice_id６６が一致するドキュメント６５を検索する。モデル部４９は、見つかったドキュメント６５のbattery_consumption６７から、オペレーションに対応したバッテリ消費量を取得する。モデル部４９は、取得されたバッテリ消費量を、Ｓ２２で取得したバッテリ残量から引く。ステップＳ２５の後、処理が、バッテリ残量が５％以上あるか確認するステップＳ２３へ戻る。ステップＳ２３の処理でバッテリ残量が５％未満になっていれば（Ｓ２３がＮｏ）、ステップＳ２６へ進む。

ステップＳ２６では、モデル部４９は、Ｓ２４で見つかったドキュメント６９から、最後のオペレーションの予定時刻を取得する。ここで取得された予定時刻を、デバイス管理コレクション４４のうちの、選択デバイスとdevice_id６１が一致するドキュメント６０における、battery_prediction３０の“shortage_time”の値として記録する（Ｓ２６）。上述したステップＳ２２～Ｓ２６の処理をデバイス管理コレクション４４に保持するデバイス全てに対し、ステップＳ２１～Ｓ２７のループ処理を実行する。このようにして、モデル部４９は、デバイス１の過去のオペレーション履歴とバッテリ残量履歴からＫＰＩ管理コレクション４５を更新する。その結果、ＫＰＩ管理コレクション４５の更新に伴って、そこのＫＰＩ管理表に記憶されたデバイス１毎のオペレーションに対するバッテリ消費量及びリスク情報が是正されて高精度化する。以上が、モデル部４９で行う処理の説明である。

図１６は、デバイス管理サーバが保持するデバイス制御部５０の処理の流れを示すフローチャートである。図１６に示すように、デバイス制御部５０は、デバイス管理コレクション４４が表すデバイス１全てに対して、ステップＳ３１～Ｓ３９のループ処理を実行する。まず、デバイス制御部５０は、デバイス１を１つ選ぶ（Ｓ３１）。ここで選択されたデバイス１を、図１６の説明において「選択デバイス１」という。次に、デバイス制御部５０は、保守管理サーバ５から保守員の巡回スケジュールを取得し、選択デバイス１に対して保守員が派遣される日時を、取得された巡回スケジュールから確認する（Ｓ３２）。

次に、デバイス制御部５０は、ＦＷアップデート要件管理コレクション４７から、選択デバイス１と一致するdevice_id７５を含むドキュメント７４を検索し、見つかったドキュメント７４から、ＦＷアップデートの開始時刻及びデッドライン（具体的には、FW_update_requirement７６における“start”及び“deadline”）を確認する（Ｓ３３）。次に、デバイス制御部５０は、保守員派遣日の前日（Ｓ３２で特定された日時の前日）が、Ｓ３３で特定された“start”と“deadline”との期間内に含まれるか確認する（Ｓ３４）。

期間内であった場合には（Ｓ３４がＹｅｓ）、デバイス制御部５０は、選択デバイス１のバッテリ残量がＦＷアップデート分あるかを確認する（Ｓ３５）。具体的には、デバイス制御部５０は、ＫＰＩ管理コレクション４５から、選択デバイス１と一致するdevice_id６６を含むドキュメント６５を検索する。デバイス制御部５０は、見つかったドキュメント６５のbattery_consumption６６から、ＦＷアップデートというオペレーションに対応したバッテリ消費量を取得する。取得されたバッテリ消費量が、選択デバイス１のバッテリ残量以上であれば、ＦＷアップデート分バッテリ残量があるということである。

ＦＷアップデート分バッテリ残量がある場合（Ｓ３５がＹｅｓ）、デバイス制御部５０は、対象ドキュメント７８（ＦＷアップデートスケジュール管理コレクション４８のうち選択デバイス１とdevice_id７９が一致するドキュメント７８）のＦＷ_update_schedule８０における“time”に、保守員の派遣日前日を記録する（Ｓ３６）。また、デバイス制御部５０は、当該ＦＷ_update_schedule８０における“version”と“repository”に、対象ドキュメント７４（ＦＷアップデート要件管理コレクション４７のうち選択デバイス１とdevice_id７５が一致するドキュメント７４）の“version”と“repository”を記録する（Ｓ３６）。

一方、ＦＷアップデート分バッテリ残量が無い場合（Ｓ３５でＮｏ）、デバイス制御部５０は、対象ドキュメント７８におけるＦＷ_update_scheduleの“time”に、バッテリ交換直後の日時を記録する（Ｓ３７）。また、デバイス制御部５０は、当該ＦＷ_update_schedule８０の“version”と“repository”に、対象ドキュメント７４の“version”と“repository”を記録する（Ｓ３７）。

ステップＳ３４の処理で、期間内に含まれない場合（Ｓ３４でＮｏ）、デバイス制御部５０は、対象ドキュメント７８のＦＷ_update_schedule８０における“time”に、期限日（“deadline”）の日時を記録する（Ｓ３８）。また、デバイス制御部５０は、当該ＦＷ_update_schedule８０における“version”と“repository”に、対象ドキュメント７４の“version”と“repository”を記録する（Ｓ３８）。上述したステップＳ３２～Ｓ３８の処理をデバイス管理コレクション４４に保持するデバイス１全てに対し、ステップＳ３１～Ｓ３９のループ処理を実行する。以上が、デバイス制御部５０で行う処理の説明である。

図１７は、保守管理サーバ５の構成を示すブロックである。図１７に示すように、保守管理サーバ５は、メモリ８２と、記憶装置８３と、入力装置８４と、出力装置８５と、通信ポート８６と、それらに接続されたＣＰＵ８１とを備える。記憶装置８３は、データベース８７を格納する。また、記憶装置８３は、保守管理部１０といった機能をＣＰＵ８１に実現させるための一つ以上のコンピュータプログラムを記憶する。当該一つ以上のコンピュータプログラムがメモリ８２にロードされＣＰＵ８１に実行されることで、保守管理部１０が実現される。データベース８７は、保守員管理コレクション８８と、デバイス情報管理コレクション８９と、巡回スケジュール管理コレクション９０と、を含む。

図１８は、保守員管理コレクション８８の構成を示した説明図である。図１８に示すように、保守員管理コレクション８８は、一つ又は複数のドキュメント８で構成される。ドキュメント８は、保守員の割り振りを表すデータである。ドキュメント８には、例えば、保守員派遣日を識別するＩＤを保持するdate５７と、派遣可能な保守員を保持するstaffs１５８とが含まれる。staffs１５８には、一つもしくは複数の保守員の各々を識別する“name”が含まれる。

図１９は、デバイス情報管理コレクション８９の構成を示した説明図である。図１９に示すように、デバイス情報管理コレクション８９は、一つ又は複数のドキュメント９１で構成される。ドキュメント９１は、デバイスの位置で特定するである。ドキュメント９１には、例えば、デバイスを識別するＩＤを保持するdevice_id９２と、デバイス設置場所の位置情報を保持するlocation９３とが含まれるlocation９３には、緯度を保持する“latitude”と経度を保持する“longitude”が含まれる。

図２０は、巡回スケジュール管理コレクション９０の構成を示した説明図である。図２０に示すように、巡回スケジュール管理コレクション９０は、一つ又は複数のドキュメント９５で構成される。ドキュメント９５は、位置で特定されたデバイス毎に保守員を巡回させるスケジュールを表すデータである。ドキュメント９５には、保守員派遣日を保持するdate９６と、一つ又は複数の保守員毎の巡回スケジュールを保持するschedule１９７とが含まれる。

schedule１９７には、派遣する保守員を保持するstaff９８と、一つ又は複数の派遣先のデバイス情報を保持するdevices９９とが含まれる。devices９９には、デバイスを識別するＩＤを保持する“device_id”と、デバイスの位置情報を保持する“location”が含まれる。“location”には、緯度を保持する“latitude”と経度を保持する“longitude”が含まれる。

図２１は、保守管理サーバが保持する保守管理部１０の処理の流れを示すフローチャート図である。図２１に示すように、保守管理部１０は、デバイス情報管理コレクション８９が表すデバイス１全てに対して、ステップＳ４１～Ｓ４８のループ処理を実行する。まず、保守管理部１０は、デバイス１を１つ選ぶ（Ｓ４１）。ここで選択されたデバイス１を、図２１の説明において「選択デバイス１」という。次に、保守管理部１０は、デバイス管理サーバ４から、選択デバイス１のバッテリ残量予測を取得し、“shortage_time”の日程でグルーピングする（Ｓ４２）。すなわち、電池切れして電池交換を必要とする日に、保守員の巡回日が到来しないデバイスを抽出する。

ここから、ステップＳ４３～Ｓ４７のループ処理を上記全ての日程毎に実行する。以下、一つの日程を例に取る（図２１の説明において「対象日程」）。まず、保守管理部１０は、対象ドキュメント９５（巡回スケジュール管理コレクション９０のうち対象日程のドキュメント９５から、巡回日（対象日程））の保守員人数を確認する（Ｓ４４）。次に、保守管理部１０は、当該ドキュメント９５の“location”を用いて、位置情報の近いデバイス１で保守員人数のグループにグルーピングし、それぞれのグループに保守員を割り当てる（Ｓ４５）。ドキュメント９５の“location”によって、複数のデバイス１それぞれの位置情報が緯度（longitude）、経度（latitude）で特定できる。この位置情報に基づいて、効率良く巡回できるように、近いデバイス１で保守員人数のグループにグルーピングする。

保守管理部１０は、対象ドキュメント９５において、date９６が上記グルーピングに使用したshcedule９７に、ステップＳ４５の処理で割り当てた保守員をstaff９８に紐づけて記録する（Ｓ４６）。すなわち、保守管理部１０は、2015年1月15日の保守員Ａさんの巡回スケジュールに、デバイス001番が紐づけられた情報を、ドキュメント９５に記録する（Ｓ４６）。以上が保守管理部１０で行われる処理の説明である。保守管理部１０は、このような処理によって、電池残量の程度が保守員の巡回まで持たせられないデバイス１に対し、電池切れする以前に近くの保守員を巡回させるように決定する。

以上のように、実施例１に係る省電力デバイス管理方法により、（A）故障以外の原因（バッテリ残量不足）の回避や、（B）状態不明な状況を作らないようにする制御が実現でき、無駄な保守員派遣の削減により保守コストを下げることが可能となる。

実施例２に係る省電力デバイス管理システムの構成は、実施例１に係る省電力デバイス管理システム１００の構成とほぼ同様であるが、図９に示したデバイス管理サーバ４のデバイス管理コレクション４４におけるドキュメント６０（図１０）のdevice_info６２に、不図示のpriorityが追加される点が異なる。

実施例２の省電力デバイス管理システムにおいて、デバイス管理者は、ＩｏＴソリューションの要件から、各デバイス１が常に管理されていなければならないか否かを判断し、その優先度からpriority値を定める。例えば、優先度の最高値を５として、優先度の最低値を1とすることができる。図１６に示したデバイス制御部５０の処理では、ステップＳ３１～Ｓ３９のループ処理において、priority値の高いものでグルーピングし、その後、実施例１の省電力デバイス管理システム１００と同様の処理を行う。

実施例２の省電力デバイス管理システムは、重要度の高いＩｏＴソリューションで使用されるデバイス１に対するＦＷアップデートなどのオペレーションを優先的にスケジュールできる。実施例２の省電力デバイス管理システムは、このように優先順位で区別することにより、重要度が低くて止まることが許されるＩｏＴソリューションのデバイス管理に引っ張られて、優先度の高いＩｏＴソリューションのデバイス１がリスクのある状態が長くなるような不具合を回避できる。

実施例３に係る省電力デバイス管理システムの構成は、実施例１に係る省電力デバイス管理システム１００の構成とほぼ同様であるが、図９に示したデバイス管理サーバ４に、ＫＰＩ管理コレクション４５を作成するＫＰＩ管理コレクション作成部（不図示）が追加される点が異なる。ＫＰＩ管理コレクション作成部は、過去のオペレーションスケジュール管理コレクション４６（図１２）において、該当するdevice_id７０のOperation_shcedule７１に対応するoperationをオペレーションとして保持する。

さらに、その時間帯のバッテリ残量をデバイス管理コレクション４４から取得し、当該オペレーションによるバッテリ消費量を算出する。ここで、過去のデータを用いて機械学習などにより、デバイス１毎、オペレーション毎のバッテリ消費量を算出してもよい。実施例３の省電力デバイス管理システムによれば、設置場所の状態によりＫＰＩが変わる場合においても、ＫＰＩの確度を確保できる。

以下、上述の説明を下記のように総括する。
［１］省電力デバイス管理方法は、次の手順を有する。まず、管理対象のデバイス１から、そのバッテリ残量を含むステータスを表すステータス情報を収集する。また、複数のデバイス１の各々のオペレーションのスケジュールを表す情報であるオペレーションスケジュール管理コレクション（情報）４６から、デバイス１の今後のオペレーションを特定する。また、複数のデバイス１の各々についてバッテリ消費量とオペレーションとの関係を表す情報を含むＫＰＩ管理コレクション（情報）４５から、デバイス１の今後のオペレーションに対応したバッテリ消費量を推定する。また、推定されたバッテリ消費量と、収集されたステータス情報が表すバッテリ残量とを基に、デバイス１のバッテリ寿命を予測する。また、予測されたバッテリ寿命を基に、デバイス１への保守員派遣の要否を含む、保守員の巡回スケジュールを決定する。

なお、ＫＰＩ管理コレクション（情報）４５には、あらかじめ定めたＫＰＩ指標として、バッテリ残量不足を回避する方法と、リスクのあるオペレーションによる状態の不明な期間を短縮する方法と、保守員の無駄な派遣を減らして保守コストを軽減する方法と、を決定する判断材料としての各種の指標が含まれている。指標の１つとして、少なくとも、デバイス１毎のオペレーションに対応したバッテリ消費量も含まれる。

また、ステータス情報は、例えば、検出時点におけるデバイス１毎のシステムバージョン、すなわち、アップデートの進捗程度の情報と、バッテリ残量の情報と、を含んでいる。省電力デバイス管理方法では、管理対象のデバイス１からステータス情報を収集し、オペレーションに対応したバッテリ消費量も含まれるＫＰＩ指標を参照して、デバイス１毎の寿命を予測する。

［２］また、上記［１］の省電力デバイス管理方法において、オペレーションスケジュール管理コレクション（情報）４６と巡回スケジュールを用いて、デバイスのバッテリ残量が不足する期間を短縮するオペレーション予定を作成すると良い。このように、作成されたオペレーション予定に従いオペレーションスケジュール管理コレクション（情報）４６を更新するとともに、これらオペレーション予定及び巡回スケジュールを保守員の端末に提供することが好ましい。

つまり、この省電力デバイス管理方法では、モデル部４９の予測結果に基づいて、各デバイス１への保守員派遣の要否及びスケジュールを決定する。このように決定された巡回スケジュールと、今後の各デバイスのオペレーション予定と、に基づいて、デバイス制御部５０が、オペレーションのスケジュールを定める。

［３］また、上記［２］の省電力デバイス管理方法において、オペレーション毎のリスクの高さを表すリスク管理情報を基に、デバイスの今後のオペレーションのうち、リスクの相対的に高いオペレーションの実行日時を、巡回スケジュールが表す保守員派遣日に近づけると良い。これによれば、リスクの高い順のオペレーションを、巡回スケジュールに基づいて保守員が近々に巡回するついでの時に、優先対応するように、オペレーションのスケジュールが策定される。その結果、状態不明な期間を短縮できる。

［４］また、上記［３］の省電力デバイス管理方法において、オペレーション毎の実行期間を表すオペレーション要件情報を基に、巡回スケジュールが表す保守員派遣日の前日が実行期間に属するオペレーションがあるか否かを判断する。判断した結果、保守員派遣日の前日が実行期間に属するオペレーションがあれば、オペレーションの実行日を、保守員派遣日の前日にスケジューリングすると良い。これによれば、オペレーションが実行された翌日に保守員が巡回するので、オペレーションの実行結果に不備があれば、速やかに保守員が対応できる。したがって、状態不明な期間を短縮できる。

［５］また、上記［３］の省電力デバイス管理方法において、オペレーション毎の実行期間を表すオペレーション要件情報を基に、巡回スケジュールが表す保守員派遣日が実行期間外のオペレーションがあるか否かを判断する。判断した結果、保守員派遣日が実行期間外のオペレーションがあれば、オペレーションの実行日をオペレーションの実行期間の最終日にスケジューリングすると良い。これによれば、オペレーション実行日から次回に保守員が巡回する日までの日数を最小にするので、オペレーションの実行結果に不備がある場合、状態不明な状況で継続する日数を少しでも短縮できる。

［６］また、上記［５］の省電力デバイス管理方法において、バッテリ残量とオペレーション種別によって、オペレーションの実現可否をする。判断した結果、オペレーションを実行してもバッテリに余裕のある場合には、保守員の派遣日前日にオペレーションをスケジューリングすると良い。これによれば、オペレーションが実行された翌日に保守員が巡回するので、オペレーションの実行結果に不備があれば、速やかに保守員が対応できる。その結果、信頼性の高い万全の体制を構築することが可能となる。

［７］また、上記［５］の省電力デバイス管理方法において、バッテリ残量とオペレーション種別によって、オペレーションの実現可否を判断する。判断した結果、オペレーションを実行したらバッテリ残量が無くなる場合には、バッテリ交換直後にオペレーションをスケジューリングすると良い。このように、オペレーションを実行したらバッテリ残量が無くなる場合について、ほぼ確実にオペレーションの失敗を予知できる。したがって、バッテリ残量の少ないデバイス１は、オペレーションを見送るように判断することにより、最悪の事態を避けられる。最悪の事態とは、バッテリ残量の少ないデバイス１は、オペレーションの最中にデバイス１の電源を喪失して、オペレーションが失敗することをいう。このような失敗は、単にオペレーションをやり直すだけでは、事態の解決に至らないことがあるので最悪の事態とみなして回避するように判断する。この確実な失敗を回避することで、より信頼度を高められる。

上記［１］～［７］について、図１６ほか各図を用いて上述したとおりである。例えば、各デバイス１への保守員派遣の要否について、ＦＷアップデート分バッテリ残量の有無（Ｓ３５）でデバイス制御部５０が判断する。ここで、ＦＷアップデート分バッテリ残量がある場合（Ｓ３５がＹｅｓ）、デバイス制御部５０は、対象ドキュメント７８（ＦＷアップデートスケジュール管理コレクション４８のうち選択デバイス１とdevice_id７９が一致するドキュメント７８）のＦＷ_update_schedule８０における“time”に、保守員の派遣日を記録する（Ｓ３６）。このように、デバイス制御部５０は、オペレーションのスケジュールを定める。或いは、図１６のステップＳ３４の判定結果次第で、適切なオペレーションの期限日を決定する（Ｓ３８）。

また、モデル部４９がデバイス１からステータス情報を収集し、ＫＰＩ指標を参照することによって、デバイス１毎のバッテリ寿命を予測できる。モデル部４９の予測結果に基づいて、保守管理部１０が各デバイス１への保守員派遣の要否及び巡回スケジュールを決定する。したがって、保守員への適格な行動指針を示すことができるので、上述した課題を解決することが可能である。

デバイス管理サーバ４のデバイス制御部５０（図９、図１６）が、オペレーション予定をオペレーションスケジュール管理コレクション４６に記憶させる。デバイス制御部５０は、リスク情報及び巡回スケジュールを用いて、オペレーションによってデバイス１の状態が不明となる期間を短縮するようにオペレーション予定を作成する。そのように作成されたオペレーション予定及び巡回スケジュールは保守員が閲覧可能であるので、それらに基づいて保守員が保守を行なう。

省電力デバイス管理方法によれば、保守管理部１０（図１７、図２１）が、モデル部４９の予測結果から各デバイス１への保守員派遣の要否及びスケジュールを決定する。これにより、バッテリ残量不足の回避及びリスクのあるオペレーションによる状態の不明な期間を短縮するとともに、無駄な保守員派遣を減らし保守コストを軽減できる。

［８］また、上記［２］の省電力デバイス管理方法において、デバイス１の過去のオペレーション履歴とバッテリ残量履歴からＫＰＩ管理コレクション（情報）４５を更新すると良い。これによれば、ＫＰＩ管理コレクション４５の更新に伴って、そこのＫＰＩ管理表に記憶されたデバイス１毎のオペレーションに対するバッテリ消費量及びリスク情報が是正されて高精度化する。その結果、より信頼性の高い保守体制を構築することが可能となる。

［９］また、上記［３］の省電力デバイス管理方法において、ＩｏＴソリューションの重要度に応じて、デバイスのオペレーションの優先度を設定し、優先度の高いデバイスから優先的にオペレーションのスケジュールを決定すると良い。これによれば、ＩｏＴソリューションの重要度に応じて、合理的な結果が得られる。

［１０］省電力デバイス管理システム１００は、デバイス管理サーバ４と、モデル部４９と、保守管理部１０と、デバイス制御部５０と、を備える。この省電力デバイス管理システム１００によれば、上記［１］の省電力デバイス管理方法と同様の効果が得られる。より詳細には、次のとおりである。デバイス管理サーバ４は、管理対象のデバイス１から、それらデバイス１のバッテリ残量を含むステータスを表すステータス情報を収集する。また、デバイス管理サーバ４は、ＫＰＩ管理コレクション（情報）４５から、デバイス１の今後のオペレーションに対応したバッテリ消費量を推定することが可能である。

ＫＰＩ管理コレクション（情報）４５は、複数のデバイス１の各々についてバッテリ消費量とオペレーションとの関係を表すリスク情報も含む。モデル部４９は、推定されたバッテリ消費量と、収集されたステータス情報が表すバッテリ残量と、よりバッテリ寿命を予測する。保守管理部１０は、予測されたバッテリ寿命を基に、デバイス１へ保守員の派遣の要否及び巡回スケジュールを決定する。

デバイス制御部５０は、巡回スケジュールと、オペレーションスケジュール管理コレクション（情報）４６から、デバイス１の今後のオペレーションを特定する。巡回スケジュールは、保守管理部1０が決定する。オペレーションスケジュール管理コレクション（情報）４６は、デバイス１の今後のオペレーションを特定する。今後のオペレーションとは、複数のデバイス１の各々のオペレーションのスケジュールを表す情報をいう。

［１１］また、上記［１０］の省電力デバイス管理システム１００において、デバイス管理サーバ４は、オペレーション予定を記憶させるオペレーションスケジュール管理コレクション（情報）４６をさらに備えていると良い。これによれば、上記［２］と同様の効果が得られる。すなわち、図９に示すように、デバイス制御部５０が、リスク情報及び巡回スケジュールを用いて、オペレーションによりデバイスの状態が不明となる期間を短縮するようにオペレーション予定を作成する。このように作成されたオペレーション予定及び巡回スケジュールは、オペレーションスケジュール管理コレクション（情報）４６に更新して記憶されるとともに保守員の閲覧に供される。

１ デバイス、１０ 保守管理部、４９ モデル部、４５ ＫＰＩ管理コレクション（情報）、４６ オペレーションスケジュール管理コレクション（情報）、５０ デバイス制御部

Claims (10)

1. 管理対象のデバイスから、当該デバイスのバッテリ残量を含むステータスを表すステータス情報を収集し、
   複数の前記デバイスの各々のオペレーションのスケジュールを表す情報であるオペレーションスケジュール管理情報から、前記デバイスの今後のオペレーションを特定し、
   複数の前記デバイスの各々についてバッテリ消費量とオペレーションとの関係を表す情報を含むＫＰＩ管理情報から、前記デバイスの前記今後のオペレーションに対応したバッテリ消費量を推定し、
   前記推定されたバッテリ消費量と、前記収集されたステータス情報が表すバッテリ残量とを基に、前記デバイスのバッテリ寿命を予測し、
   前記予測されたバッテリ寿命を基に、前記デバイスへの保守員派遣の要否を含む、保守員の巡回スケジュールを決定し、
   オペレーション毎のリスクの高さを表すリスク管理情報を基に、前記デバイスの前記今後のオペレーションのうち、リスクの相対的に高いオペレーションの実行日時を、前記巡回スケジュールが表す保守員派遣日に近づける、
   省電力デバイス管理方法。
2. 前記オペレーションスケジュール管理情報と前記巡回スケジュールを用いて、前記デバイスのバッテリ残量が不足する期間を短縮するオペレーション予定を作成し、当該オペレーション予定に従い前記オペレーションスケジュール管理情報を更新し、
   前記オペレーション予定及び前記巡回スケジュールを保守員の端末に提供する、
   請求項１に記載の省電力デバイス管理方法。
3. オペレーション毎の実行期間を表すオペレーション要件情報を基に、前記巡回スケジュールが表す保守員派遣日の前日が実行期間に属するオペレーションがあるか否かを判断し、
   保守員派遣日の前日が実行期間に属するオペレーションがあれば、当該オペレーションの実行日を、前記保守員派遣日の前日にスケジューリングする、
   請求項１に記載の省電力デバイス管理方法。
4. オペレーション毎の実行期間を表すオペレーション要件情報を基に、前記巡回スケジュールが表す保守員派遣日が実行期間外のオペレーションがあるか否かを判断し、
   保守員派遣日が実行期間外のオペレーションがあれば、当該オペレーションの実行日を当該オペレーションの実行期間の最終日にスケジューリングする、
   請求項１に記載の省電力デバイス管理方法。
5. バッテリ残量とオペレーション種別によって、オペレーションの実現可否を判断し、オペレーションを実行してもバッテリに余裕のある場合には、保守員の派遣日前日にオペレーションをスケジューリングする、
   請求項４に記載の省電力デバイス管理方法。
6. バッテリ残量とオペレーション種別によって、オペレーションの実現可否を判断し、オペレーションを実行したらバッテリ残量が無くなる場合には、バッテリ交換直後にオペレーションをスケジューリングする、
   請求項４に記載の省電力デバイス管理方法。
7. 前記デバイスの過去のオペレーション履歴とバッテリ残量履歴からＫＰＩ管理情報を更新する、
   請求項２に記載の省電力デバイス管理方法。
8. ＩｏＴソリューションの重要度に応じて、前記デバイスのオペレーションの優先度を設定し、優先度の高い前記デバイスから優先的にオペレーションのスケジュールを決定する、
   請求項１に記載の省電力デバイス管理方法。
9. 管理対象のデバイスから、当該デバイスのバッテリ残量を含むステータスを表すステータス情報を収集し、複数の前記デバイスの各々についてバッテリ消費量とオペレーションとの関係を表してリスク情報も含むＫＰＩ管理情報から、前記デバイスの今後のオペレーションに対応したバッテリ消費量を推定することが可能なデバイス管理サーバと、
   前記推定された前記バッテリ消費量と、前記収集されたステータス情報が表すバッテリ残量と、よりバッテリ寿命を予測するモデル部と、
   予測された前記バッテリ寿命を基に、前記デバイスへ保守員の派遣の要否及び巡回スケジュールを決定する保守管理部と、
   該保守管理部が決定した前記巡回スケジュールと、複数の前記デバイスの各々のオペレーションのスケジュールを表す情報であるオペレーションスケジュール管理情報から、前記デバイスの今後のオペレーションを特定するデバイス制御部と、
   を備え、
   前記デバイス制御部は、オペレーション毎のリスクの高さを表すリスク管理情報を基に、前記デバイスの前記今後のオペレーションのうち、リスクの相対的に高いオペレーションの実行日時を、前記巡回スケジュールが表す保守員派遣日に近づける、
   省電力デバイス管理システム。
10. 前記デバイス管理サーバは、
    前記デバイス制御部が、前記リスク情報及び前記巡回スケジュールを用いて、オペレーションにより前記デバイスの状態が不明となる期間を短縮するように作成したオペレーション予定を記憶させるオペレーションスケジュール管理情報をさらに備え、
    作成された前記オペレーション予定及び前記巡回スケジュールは前記保守員の閲覧に供される、
    請求項９に記載の省電力デバイス管理システム。
    

Images