(57)【要約】【課題】複数のデバイスの制御にかかる負担を軽減させること。【解決手段】同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムにおいて、デバイスエージェントは、異常状態ポリシ情報と対処動作ポリシ情報とを含むデバイスポリシを有し、自デバイスが異常状態ポリシ情報の異常状態に該当する場合に他デバイスへ自デバイスの異常状態を通知し、他デバイスの異常状態の通知に応じて対処動作ポリシ情報の対処動作を自デバイスに実行させる。【選択図】図１
2020027336.tif 000002
【特許請求の範囲】
【請求項１】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムにおいて、
前記デバイスは、デバイスエージェントを備え、
前記デバイスエージェントは、
前記デバイスの異常状態を定める異常状態ポリシ情報と、
他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、
自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、
他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、
デバイスシステム。
【請求項２】
前記デバイスエージェントは、
自己の前記デバイスの生存を一定の周期で他の前記デバイスへ通知し、
他の前記デバイスの生存の通知を一定の周期で取得できない場合に前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、
請求項１に記載のデバイスシステム。
【請求項３】
複数の前記クラスタを管理する管理サーバと、前記管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイと、をさらに備え、
前記管理サーバは、自己の管理下の前記複数の前記クラスタに対して同じ基本デバイスポリシを配布する管理エージェントを備え、
前記ゲートウェイは、前記管理サーバから配布された前記基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェントを備える、
請求項１又は２のいずれか１項に記載のデバイスシステム。
【請求項４】
前記ゲートウェイエージェントは、
自己の管理下の前記クラスタに属する前記複数のデバイスについての異常状態の通知を取得し、取得した通知の異常状態に基づいてデバイスの故障を前記管理サーバへ通知する、
請求項３に記載のデバイスシステム。
【請求項５】
前記管理エージェントは、前記デバイスの故障の通知に基づいて該当するデバイスの所定の発注処理を実行する、
請求項４に記載のデバイスシステム。
【請求項６】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの前記デバイスにおいて、
デバイスエージェントを備え、
前記デバイスエージェントは、
前記デバイスの異常状態を定める異常状態ポリシ情報と、
他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、
自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、
他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、
デバイス。
【請求項７】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの複数の前記クラスタを管理する管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイにおいて、
前記管理サーバの管理下の前記複数の前記クラスタに対して前記管理サーバから配布された同じ基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェント、
を備えるゲートウェイ。
【請求項８】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの制御方法であって、
前記デバイスが備えるデバイスエージェントは、
前記デバイスの異常状態を定める異常状態ポリシ情報と、
他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、
前記デバイスエージェントが、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知する異常状態通知ステップと、
前記デバイスエージェントが、他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる対処動作実行ステップと、
を含むデバイスシステム制御方法。
【請求項９】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの前記デバイスのコンピュータに、
デバイスエージェント機能を実現させるためのコンピュータプログラムであって、
前記デバイスエージェント機能は、
前記デバイスの異常状態を定める異常状態ポリシ情報と、
他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、
自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、
他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、
コンピュータプログラム。
【請求項１０】
同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの複数の前記クラスタを管理する管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイのコンピュータに、
前記管理サーバの管理下の前記複数の前記クラスタに対して前記管理サーバから配布された同じ基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェント機能、
を実現させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスシステム、デバイス、ゲートウェイ、デバイスシステム制御方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
従来のデバイス制御技術として、例えば特許文献１、２に記載の従来技術が知られている。特許文献１の従来技術では、管理者が操作して端末装置から無線通信により指令信号をセンサ制御装置へ送信し、センサ制御装置は、端末装置から受信した指令信号に基づいてガスセンサのセンサ設定条件を変更し、ガスセンサの駆動制御を行う。特許文献２の従来技術では、管理サーバは、一つのデバイスから受信したデバイス設定情報のデバイス設定が変更されている場合に、当該デバイス設定情報に基づいて更新設定情報を作成し、作成した更新設定情報を所定の他のデバイスへ送信して反映させる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−２００５７４号公報
【特許文献２】特開２００６−０９９３００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年、モノのインターネット（Internet of Things：ＩｏＴ）を実現するための多数のデバイスからデータを取得して利用するサービスが検討されている。その多数のデバイスを制御する場合、上述した特許文献１の従来技術では、管理者がデバイス個別にセンサ設定条件の変更指令を行うので、管理者の工数が膨大になったり、人為的ミスが生じたりする等の問題が発生する可能性があった。また、特許文献２の従来技術では、管理サーバが多数のデバイスを集中管理するので、管理サーバの負荷が膨大になったり、デバイスの障害時に迅速な対処ができず、デバイスの稼働停止時間が長期間に及んだりする等の問題が発生する可能性があった。
【０００５】
本発明は、このような事情を考慮してなされたものであり、その目的は、複数のデバイスの制御にかかる負担を軽減させることにある。
【課題を解決するための手段】
【０００６】
（１）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムにおいて、前記デバイスは、デバイスエージェントを備え、前記デバイスエージェントは、前記デバイスの異常状態を定める異常状態ポリシ情報と、他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、デバイスシステムである。
（２）本発明の一態様は、前記デバイスエージェントは、自己の前記デバイスの生存を一定の周期で他の前記デバイスへ通知し、他の前記デバイスの生存の通知を一定の周期で取得できない場合に前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、上記（１）のデバイスシステムである。
（３）本発明の一態様は、複数の前記クラスタを管理する管理サーバと、前記管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイと、をさらに備え、前記管理サーバは、自己の管理下の前記複数の前記クラスタに対して同じ基本デバイスポリシを配布する管理エージェントを備え、前記ゲートウェイは、前記管理サーバから配布された前記基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェントを備える、上記（１）又は（２）のいずれかのデバイスシステムである。
（４）本発明の一態様は、前記ゲートウェイエージェントは、自己の管理下の前記クラスタに属する前記複数のデバイスについての異常状態の通知を取得し、取得した通知の異常状態に基づいてデバイスの故障を前記管理サーバへ通知する、上記（３）のデバイスシステムである。
（５）本発明の一態様は、前記管理エージェントは、前記デバイスの故障の通知に基づいて該当するデバイスの所定の発注処理を実行する、上記（４）のデバイスシステムである。
【０００７】
（６）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの前記デバイスにおいて、デバイスエージェントを備え、前記デバイスエージェントは、前記デバイスの異常状態を定める異常状態ポリシ情報と、他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、デバイスである。
（７）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの複数の前記クラスタを管理する管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイにおいて、前記管理サーバの管理下の前記複数の前記クラスタに対して前記管理サーバから配布された同じ基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェント、を備えるゲートウェイである。
【０００８】
（８）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの制御方法であって、前記デバイスが備えるデバイスエージェントは、前記デバイスの異常状態を定める異常状態ポリシ情報と、他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、前記デバイスエージェントが、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知する異常状態通知ステップと、前記デバイスエージェントが、他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる対処動作実行ステップと、を含むデバイスシステム制御方法である。
【０００９】
（９）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの前記デバイスのコンピュータに、デバイスエージェント機能を実現させるためのコンピュータプログラムであって、前記デバイスエージェント機能は、前記デバイスの異常状態を定める異常状態ポリシ情報と、他の前記デバイスが異常状態である場合の対処動作を定める対処動作ポリシ情報とを含むデバイスポリシを有し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当するか否かを判断し、自己の前記デバイスが前記異常状態ポリシ情報の異常状態に該当する場合に他の前記デバイスへ自己の前記デバイスの異常状態を通知し、他の前記デバイスの異常状態の通知に応じて前記対処動作ポリシ情報の対処動作を自己のデバイスに実行させる、コンピュータプログラムである。
（１０）本発明の一態様は、同じクラスタに属する複数のデバイスが通信により相互に情報を交換するデバイスシステムの複数の前記クラスタを管理する管理サーバ及び自己の管理下の前記クラスタに属する前記複数のデバイスと通信を行うゲートウェイのコンピュータに、前記管理サーバの管理下の前記複数の前記クラスタに対して前記管理サーバから配布された同じ基本デバイスポリシを、自己が管理する前記クラスタに属する前記複数のデバイスの状況に応じて変更し、前記基本デバイスポリシを変更した結果のデバイスポリシを自己の管理下の前記クラスタに属する前記複数のデバイスへ配布するゲートウェイエージェント機能、を実現させるためのコンピュータプログラムである。
【発明の効果】
【００１０】
本発明によれば、複数のデバイスの制御にかかる負担を軽減させることができるという効果が得られる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態に係るデバイスシステムの構成例を示す図である。
【図２】一実施形態に係るデバイスシステム制御方法におけるデバイスポリシ配布段階の手順の例を示すシーケンス図である。
【図３】一実施形態に係るデバイスシステム制御方法におけるデバイス異常状態発生段階の手順の例を示すシーケンス図である。
【図４】一実施形態に係るデバイスシステム制御方法におけるデバイス異常状態発生段階の手順の例を示すシーケンス図である。
【図５】一実施形態に係るデバイスシステム制御方法におけるデバイス故障状態発生段階の手順の例を示すシーケンス図である。
【図６】一実施形態に係るデバイスシステムの実施例の街灯システムを示す説明図である。
【図７】一実施形態に係るデバイスの実施例の街灯装置を示すブロック図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照し、本発明の実施形態について説明する。
図１は、一実施形態に係るデバイスシステムの構成例を示す図である。図１において、デバイスシステム１は、管理サーバ１０と、ＩｏＴゲートウェイ（ＩｏＴＧＷ）１１と、複数のデバイス１３、１４、１５とを備える。図１の例では、３個のデバイス１３、１４、１５が示されている。デバイス１３、１４、１５は、同じクラスタ（デバイス群）３０１に属するデバイスである。デバイス１３、１４、１５には、自己の所属クラスタがクラスタ３０１であることが設定されている。
【００１３】
管理サーバ１０とＩｏＴＧＷ１１とは通信を行う。例えば、管理サーバ１０とＩｏＴＧＷ１１とは、インターネット等の通信ネットワークを介して通信を行う。ＩｏＴＧＷ１１は、自己の管理下のクラスタ３０１に属するデバイス１３、１４、１５と通信を行う。例えば、ＩｏＴＧＷ１１は、有線又は無線のＬＡＮ（Local Area Network）等の通信ネットワークを介して、デバイス１３、１４、１５と通信を行う。
【００１４】
［管理サーバ］
管理サーバ１０は、クラスタ３０１を含む複数のクラスタを管理する。図１には、管理サーバ１０が管理する複数のクラスタのうちクラスタ３０１のみを図示している。管理サーバ１０は、中央管理エージェント１０１と、ブローカ５０１とを備える。管理サーバ１０の機能は、管理サーバ１０が備えるＣＰＵ（Central Processing Unit：中央演算処理装置）がコンピュータプログラムを実行することにより実現される。なお、管理サーバ１０として、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。
【００１５】
中央管理エージェント１０１は、ポリシ管理・配布機能（policy manager）と、発注機能（orderer）とを有する。
【００１６】
ポリシ管理・配布機能は、管理サーバ１０の管理下の複数のクラスタに対して配布する同じ基本デバイスポリシを保持する。ポリシ管理・配布機能は、管理者からの指示に従って、基本デバイスポリシの設定を行う。管理者は、管理端末（admin）を使用して管理サーバ１０にアクセスし、基本デバイスポリシを管理サーバ１０に設定する。ポリシ管理・配布機能は、同じ基本デバイスポリシを、管理サーバ１０が管理する複数のクラスタに各々対応するＩｏＴＧＷへ配布する。
【００１７】
本実施形態の一例として、基本デバイスポリシは、異常状態ポリシ情報と対処動作ポリシ情報とを含む。異常状態ポリシ情報は、デバイスの異常状態を定める情報である。異常状態は、デバイスに不具合が存在する状態である。異常状態は、故障状態を含む状態である。故障状態は、デバイスが自己の生存を一定の周期で他のデバイスに通知することができない状態である。対処動作ポリシ情報は、他のデバイスが異常状態である場合の対処動作を定める情報である。なお、基本デバイスポリシは、さらに、デバイスの通常動作を定める通常動作ポリシ情報を含んでもよい。本実施形態に係るポリシのデータ記述形式として、例えばＹＡＭＬ形式が挙げられる。
【００１８】
発注機能は、管理サーバ１０が管理するクラスタに属するデバイスの故障の通知に基づいて、該当するデバイスの所定の発注処理を実行する。発注処理は、交換用デバイスの発注処理であってもよく、又は、デバイスの修理依頼の発注処理であってもよい。
【００１９】
ブローカ５０１は、管理サーバ１０が通信を行う通信相手との間でメッセージを交換するためのメッセージ交換機能を有する。本実施形態に係るメッセージ交換機能の一例として、ｐｕｂ／ｓｕｂメッセージングモデルを使用する。具体的には、ブローカ５０１は、管理サーバ１０（ｐｕｂ）から通信相手（ｓｕｂ）へ送信するメッセージを保持し、当該メッセージを通信相手（ｓｕｂ）に取得してもらう。また、ブローカ５０１は、通信相手（ｐｕｂ）から管理サーバ１０（ｓｕｂ）へ送信されるメッセージを当該通信相手（ｐｕｂ）から受信して保持する。
【００２０】
ブローカ５０１は、管理サーバ１０が管理する複数のクラスタに各々対応するＩｏＴＧＷとの間で、メッセージの交換を行う。図１の例では、ブローカ５０１は、管理サーバ１０が管理する複数のクラスタのうちクラスタ３０１に対応するＩｏＴＧＷ１１との間で、メッセージの交換を行う。
【００２１】
［ＩｏＴＧＷ］
ＩｏＴＧＷ１１は、ゲートウェイエージェント（ＧＷエージェント）１０２と、ブローカ５０２とを備える。ＩｏＴＧＷ１１の機能は、ＩｏＴＧＷ１１が備えるＣＰＵがコンピュータプログラムを実行することにより実現される。なお、ＩｏＴＧＷ１１として、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。
【００２２】
ＧＷエージェント１０２は、メッセージ管理機能（message manager）と、デバイス管理機能（device manager）と、デバイス状態解析機能（analytics engine）とを有する。
【００２３】
メッセージ管理機能は、ＩｏＴＧＷ１１が通信相手と交換するメッセージの管理を行う。メッセージ管理機能は、管理サーバ１０から配布される基本デバイスポリシを取得する。また、メッセージ管理機能は、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の故障を通知するメッセージを、管理サーバ１０へ送信する。
【００２４】
デバイス管理機能は、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の管理を行う。デバイス管理機能は、管理サーバ１０から配布された基本デバイスポリシを、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の状況に応じて変更し、当該基本デバイスポリシを変更した結果のデバイスポリシをデバイス１３、１４、１５へ配布する。なお、管理サーバ１０から配布された基本デバイスポリシを変更する必要がない場合には、デバイス管理機能は、管理サーバ１０から配布された基本デバイスポリシをそのままデバイスポリシとしてデバイス１３、１４、１５へ配布する。基本デバイスポリシを変更する必要がない場合とは、デバイス１３、１４、１５の状況が基本デバイスポリシに適合している場合や、基本デバイスポリシを変更しないように設定されている場合などである。
【００２５】
また、デバイス管理機能は、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の状態を通知するメッセージを取得する。例えば、デバイス管理機能は、デバイス１３、１４、１５についての異常状態を通知するメッセージを取得する。
【００２６】
デバイス状態解析機能は、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の状態を通知するメッセージに基づいて、デバイス１３、１４、１５の状態について所定の判断を行う。例えば、デバイス状態解析機能は、デバイス１３、１４、１５についての異常状態を通知するメッセージに基づいて、デバイス１３、１４、１５が故障する時期を予測する。また、デバイス状態解析機能は、故障状態のデバイスからデータ（例えば、センサの検出データ）を取得できない場合、故障状態のデバイスの周辺に在る他のデバイスから取得したデータに基づいて、故障状態のデバイスのデータを推定してもよい。
【００２７】
ブローカ５０２は、ＩｏＴＧＷ１１が通信を行う通信相手との間でメッセージを交換するためのメッセージ交換機能を有する。ブローカ５０２は、ＩｏＴＧＷ１１（ｐｕｂ）から通信相手（ｓｕｂ）へ送信するメッセージを保持し、当該メッセージを通信相手（ｓｕｂ）に取得してもらう。また、ブローカ５０２は、通信相手（ｐｕｂ）からＩｏＴＧＷ１１（ｓｕｂ）へ送信されるメッセージを当該通信相手（ｐｕｂ）から受信して保持する。ブローカ５０２は、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５との間で、メッセージの交換を行う。
【００２８】
［デバイス］
デバイスは、同じクラスタに属する他のデバイスとの間で通信により相互に情報を交換する。図１の例では、デバイス１３、１４、１５は、同じクラスタ３０１に属する他のデバイスとの間で通信により相互に情報を交換する。デバイスは、デバイスエージェントを備える。図１の例では、デバイス１３はデバイスエージェント１０３を備え、デバイス１４はデバイスエージェント１０４を備え、デバイス１５はデバイスエージェント１０５を備える。各デバイスエージェント１０３、１０４、１０５は同じ機能を有する。以下、デバイス１３、１４、１５を特に区別しないときはデバイス１ｘと称する。また、デバイスエージェント１０３、１０４、１０５を特に区別しないときはデバイスエージェント１０ｘと称する。
【００２９】
デバイス１ｘの機能は、デバイス１ｘが備えるＣＰＵがコンピュータプログラムを実行することにより実現される。なお、デバイス１ｘとして、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。
【００３０】
デバイスエージェント１０ｘは、ＩｏＴＧＷ１１から配布されたデバイスポリシを、自己のデバイス１ｘのメモリに保持する。デバイスエージェント１０ｘは、自己のデバイス１ｘがデバイスポリシの異常状態ポリシ情報の異常状態に該当するか否かを判断する。例えば、デバイスエージェント１０ｘは、自己のデバイス１ｘのデータ（例えば、センサの検出データ）を取得し、取得したデータに基づいて異常状態ポリシ情報の異常状態に該当するか否かを判断する。例えば、デバイスエージェント１０ｘは、自己のデバイス１ｘのセンサの検出データの値が、異常状態ポリシ情報の異常状態に該当する値（例えば、所定の正常範囲の外）である場合には異常状態ポリシ情報の異常状態に該当すると判断し、一方、異常状態ポリシ情報の異常状態に該当しない値（例えば、所定の正常範囲の内）である場合には異常状態ポリシ情報の異常状態に該当しないと判断する。デバイスエージェント１０ｘは、自己のデバイス１ｘが異常状態ポリシ情報の異常状態に該当する場合に、他のデバイス１ｘへ自己のデバイス１ｘの異常状態を通知するメッセージを送信する。
【００３１】
デバイスエージェント１０ｘは、他のデバイス１ｘの異常状態の通知に応じて、デバイスポリシの対処動作ポリシ情報の対処動作を自己のデバイス１ｘに実行させる。具体的には、デバイスエージェント１０ｘは、他のデバイス１ｘの異常状態の通知に応じて、デバイスポリシの対処動作ポリシ情報の対処動作の設定（例えば、センサの観測方向や検出データの取得タイミング等の変更の設定）を、自己のデバイス１ｘに行う。対処動作の設定が行われたデバイス１ｘは、当該対処動作の設定に従って当該対処動作を行う。
【００３２】
デバイスエージェント１０ｘは、自己のデバイス１ｘの生存を通知するメッセージを、一定の周期で他のデバイス１ｘへ送信する。デバイスエージェント１０ｘは、他のデバイス１ｘの生存を通知するメッセージを一定の周期で取得できない場合に、デバイスポリシの対処動作ポリシ情報の対処動作を自己のデバイス１ｘに実行させる。
【００３３】
各クラスタにはブローカが設けらる。図１の例では、クラスタ３０１に対応するブローカ５０３が設けられる。ブローカ５０３は、クラスタ３０１に属するデバイス１ｘ同士の間でメッセージを交換するためのメッセージ交換機能を有する。ブローカ５０３は、デバイス１ｘ（ｐｕｂ）から他のデバイス１ｘ（ｓｕｂ）へ送信するメッセージを保持し、当該メッセージを他のデバイス１ｘ（ｓｕｂ）に取得してもらう。
【００３４】
次に本実施形態に係るデバイスシステム制御方法を説明する。
【００３５】
［デバイスポリシ配布段階］
図２を参照して、本実施形態に係るデバイスシステム制御方法におけるデバイスポリシ配布段階を説明する。図２は、本実施形態に係るデバイスシステム制御方法におけるデバイスポリシ配布段階の手順の例を示すシーケンス図である。
【００３６】
（ステップＳ１）  管理者は、管理端末（admin）を使用して基本デバイスポリシを管理サーバ１０に設定する。管理サーバ１０の中央管理エージェント１０１は、管理端末（admin）から設定された基本デバイスポリシを保持する。
【００３７】
（ステップＳ２）  中央管理エージェント１０１は、同じ基本デバイスポリシを、管理サーバ１０が管理する複数のクラスタに各々対応するＩｏＴＧＷへ配布する。ここでは、管理サーバ１０が管理するクラスタ３０１に対応するＩｏＴＧＷ１１へ基本デバイスポリシを配布するものを例に挙げて、以下の説明を行う。なお、管理サーバ１０が管理するクラスタ３０１以外の他のクラスタに対応するＩｏＴＧＷへ基本デバイスポリシを配布するものも、以下の説明と同様である。
【００３８】
中央管理エージェント１０１は、基本デバイスポリシ含む基本デバイスポリシ配布メッセージをブローカ５０１へ送信する。ブローカ５０１は、基本デバイスポリシ配布メッセージを保持する。
【００３９】
（ステップＳ３）  ＩｏＴＧＷ１１のＧＷエージェント１０２は、一定の周期でブローカ５０１にアクセスし、自己が取得する対象のメッセージをブローカ５０１から取得するメッセージ取得処理を実行する。ＧＷエージェント１０２は、メッセージ取得処理を実行して、基本デバイスポリシ配布メッセージをブローカ５０１から取得する。ＧＷエージェント１０２は、基本デバイスポリシ配布メッセージに含まれる基本デバイスポリシを保持する。
【００４０】
（ステップＳ４）  ＧＷエージェント１０２は、基本デバイスポリシを、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の状況に応じて変更し、当該基本デバイスポリシを変更した結果のデバイスポリシを保持する。なお、基本デバイスポリシを変更する必要がない場合には、ＧＷエージェント１０２は、基本デバイスポリシをそのままデバイスポリシとして保持する。ＧＷエージェント１０２は、デバイスポリシ含むデバイスポリシ配布メッセージをブローカ５０２へ送信する。ブローカ５０２は、デバイスポリシ配布メッセージを保持する。
【００４１】
（ステップＳ５）  クラスタ３０１に属するデバイス１ｘのデバイスエージェント１０ｘは、一定の周期でブローカ５０２にアクセスし、自己が取得する対象のメッセージをブローカ５０２から取得するメッセージ取得処理を実行する。デバイスエージェント１０ｘは、メッセージ取得処理を実行して、デバイスポリシ配布メッセージをブローカ５０２から取得する。デバイスエージェント１０ｘは、デバイスポリシ配布メッセージに含まれるデバイスポリシを保持する。
【００４２】
（ステップＳ６）  デバイスエージェント１０ｘは、デバイスポリシに基づいて、自己のデバイス１ｘの設定を変更する。これにより、クラスタ３０１に属するデバイス１３、１４、１５には、基本デバイスポリシに基づいた設定が行われる。
【００４３】
上述した本実施形態に係るデバイスシステム制御方法のデバイスポリシ配布段階によれば、ＩｏＴＧＷ１１のＧＷエージェント１０２は、管理サーバ１０から配布された基本デバイスポリシを、ＩｏＴＧＷ１１の管理下のクラスタ３０１に属するデバイス１３、１４、１５の状況に応じて変更し、当該基本デバイスポリシを変更した結果のデバイスポリシをデバイス１３、１４、１５へ配布する。このため、管理サーバ１０は、自己のの管理下の複数のクラスタに対して同じ基本デバイスポリシを配布すればよいので、クラスタ毎に各クラスタに属するデバイスの状況に適合させたデバイスポリシを配布しなくてもよい。これにより、デバイスポリシの配布にかかる負荷を軽減させることができる。
【００４４】
［デバイス異常状態発生段階］
図３、図４を参照して、本実施形態に係るデバイスシステム制御方法におけるデバイス異常状態発生段階を説明する。図３、図４は、本実施形態に係るデバイスシステム制御方法におけるデバイス異常状態発生段階の手順の例を示すシーケンス図である。ここでは、管理サーバ１０が管理するクラスタ３０１に属するデバイス１３に異常状態が発生する場合を例に挙げて、以下の説明を行う。なお、クラスタ３０１に属する他のデバイス１ｘに異常状態が発生する場合も、以下の説明と同様である。
【００４５】
（ステップＳ１０）  デバイス１３のデバイスエージェント１０３は、一定の周期で、デバイスポリシ確認ステップＳ１１を繰り返し実行する。デバイスポリシ確認ステップＳ１１では、デバイスエージェント１０３は、自己のデバイス１２がデバイスポリシの異常状態ポリシ情報の異常状態に該当するか否かを判断する。この判断の結果、異常状態ポリシ情報の異常状態に該当する場合にはステップＳ１２に進み、ステップＳ１１の繰り返し実行を中断し、ステップＳ１３でポリシ違反を認識する。ポリシ違反を認識した後、ステップＳ１４へ進む。一方、デバイスポリシ確認ステップＳ１１の判断の結果、異常状態ポリシ情報の異常状態に該当しない場合には、一定の周期で、デバイスポリシ確認ステップＳ１１を繰り返す。
【００４６】
（ステップＳ１４）  デバイスエージェント１０３は、自己のデバイス１３の異常状態を通知する異常状態通知メッセージを、ブローカ５０３へ送信する。デバイスエージェント１０３は、異常状態ポリシ情報に定められた複数の異常状態及び当該異常状態の識別子（異常状態ＩＤ）が存在する場合、自己のデバイス１３に発生した異常状態を識別する異常状態ＩＤを異常状態通知メッセージに含める。ブローカ５０３は、デバイス１３の異常状態通知メッセージを保持する。
【００４７】
（ステップＳ１５）  クラスタ３０１に属するデバイス１ｘのデバイスエージェント１０ｘは、一定の周期でブローカ５０３にアクセスし、他のデバイス１ｘの状態を通知する状態通知メッセージをブローカ５０３から取得する状態通知メッセージ取得処理を実行する。各デバイス１４、１５のデバイスエージェント１０４、１０５は、状態通知メッセージ取得処理を実行して、ブローカ５０３から状態通知メッセージを取得する。これにより、デバイス１３の異常状態通知メッセージがデバイスエージェント１０４、１０５によってそれぞれ取得される。
【００４８】
次いで、デバイスエージェント１０４、１０５は、ステップＳ１６、Ｓ１７、Ｓ１８を実行する。以下、ステップＳ１６、Ｓ１７、Ｓ１８の処理についてデバイスエージェント１０４を例に挙げて説明するが、デバイスエージェント１０５についても同様である。
【００４９】
（ステップＳ１６）  デバイス１４のデバイスエージェント１０４は、デバイス１３の異常状態通知メッセージに基づいてデバイス１３で発生した異常状態を認識し、デバイスポリシの対処動作ポリシ情報の対処動作を確認する。なお、異常状態通知メッセージが異常状態ＩＤを含む場合、デバイスエージェント１０４は、当該異常状態ＩＤに対応するデバイスポリシの対処動作ポリシ情報の対処動作を確認する。
【００５０】
（ステップＳ１７）  デバイスエージェント１０４は、確認結果の対処動作を自己のデバイス１４に実行させる。具体的には、デバイスエージェント１０４は、当該対処動作の設定を自己のデバイス１４に行う。当該対処動作の設定が行われたデバイス１４は、当該対処動作の設定に従って当該対処動作を行う。なお、デバイスエージェント１０４は、異常状態通知メッセージが異常状態ＩＤを含む場合、対処動作ポリシ情報において当該異常状態ＩＤに関連付けられた対処動作を自己のデバイス１４に実行させる。
【００５１】
（ステップＳ１８）  デバイスエージェント１０４は、自己のデバイス１４に対して行った設定変更の内容（対処動作の設定の内容）を通知する設定変更状態通知メッセージを、ブローカ５０３へ送信する。ブローカ５０３は、デバイス１４の設定変更状態通知メッセージを保持する。
【００５２】
上述のステップＳ１６、Ｓ１７、Ｓ１８の処理によって、ブローカ５０３には、デバイス１４の設定変更状態通知メッセージとデバイス１５の設定変更状態通知メッセージとが保持される。
【００５３】
（ステップＳ１９）  クラスタ３０１に属するデバイス１ｘのデバイスエージェント１０ｘは、状態通知メッセージ取得処理を実行して、ブローカ５０３から、他のデバイス１ｘの設定変更状態通知メッセージを取得する。デバイスエージェント１０ｘは、他のデバイス１ｘの設定変更状態通知メッセージにより、当該他のデバイス１ｘの設定変更の内容（対処動作の設定の内容）を記録する。デバイスエージェント１０ｘは、当該他のデバイス１ｘの設定変更の内容（対処動作の設定の内容）がデバイスポリシの対処動作ポリシ情報の対処動作に該当することを確認する。これにより、デバイスエージェント１０ｘは、対処動作によってデバイス１３の異常状態による不具合が補われたと判断する。
【００５４】
（ステップＳ２０）  デバイス１３のデバイスエージェント１０３は、自己のデバイス１３の異常状態を通知する異常通知メッセージを、ブローカ５０２へ送信する。なお、デバイスエージェント１０３は、異常状態ポリシ情報に定められた複数の異常状態（異常状態ＩＤ）が存在する場合、自己のデバイス１３に発生した異常状態の異常状態ＩＤを異常通知メッセージに含める。ブローカ５０２は、デバイス１３の異常通知メッセージを保持する。
【００５５】
（ステップＳ２１）  ＩｏＴＧＷ１１のＧＷエージェント１０２は、一定の周期でブローカ５０２にアクセスし、クラスタ３０１に属するデバイス１ｘの状態を通知する通知メッセージをブローカ５０２から取得する通知メッセージ取得処理を実行する。ＧＷエージェント１０２は、通知メッセージ取得処理を実行して、ブローカ５０２から、デバイス１３の異常通知メッセージを取得する。
【００５６】
次いで図４においてＧＷエージェント１０２はステップＳ２２を実行する。
（ステップＳ２２）  ＧＷエージェント１０２は、デバイス１３の異常通知メッセージに基づいて、デバイス１３の故障を管理サーバ１０へ通知するか否かを判断する。具体的には、ＧＷエージェント１０２は、デバイス１３の異常通知メッセージで示されるデバイス１３の異常状態に基づいて、デバイス１３が故障する時期を予測する。このデバイス故障時期予測方法は、予め、ＧＷエージェント１０２に設定される。例えば、異常状態に対応する、故障発生までの残り期間又は残り期間の計算式が予めＧＷエージェント１０２に設定される。なお、複数の異常状態（異常状態ＩＤ）が存在する場合、異常状態ＩＤ毎に、故障発生までの残り期間又は残り期間の計算式が予めＧＷエージェント１０２に設定される。
【００５７】
ＧＷエージェント１０２は、デバイス１３が故障する時期を予測した結果、故障発生までの残り期間が所定の閾値未満である場合にデバイス１３の故障を管理サーバ１０へ通知すると判断し、ステップＳ２３へ進む。一方、ＧＷエージェント１０２は、故障発生までの残り期間が所定の閾値以上である場合にデバイス１３の故障を管理サーバ１０へ通知しないと判断し、図４の処理を終了する。
【００５８】
（ステップＳ２３）  ＧＷエージェント１０２は、デバイス１３の故障を通知する故障通知メッセージを、ブローカ５０１へ送信する。ブローカ５０１は、デバイス１３の故障通知メッセージを保持する。
【００５９】
（ステップＳ２４）  管理サーバ１０の中央管理エージェント１０１は、一定の周期でブローカ５０１にアクセスし、クラスタ３０１に属するデバイス１ｘに関する通知メッセージをブローカ５０１から取得する通知メッセージ取得処理を実行する。中央管理エージェント１０１は、通知メッセージ取得処理を実行して、ブローカ５０１から、デバイス１３の故障通知メッセージを取得する。
【００６０】
（ステップＳ２５）  中央管理エージェント１０１は、デバイス１３の故障通知メッセージに基づいて、デバイス１３に該当するデバイスの所定の発注処理を実行する。この発注処理として、例えば、デバイス１３に該当するデバイス発注先へ、デバイス１３と同じ型番の交換用デバイスを注文する発注伝票データを送信する。
【００６１】
上述した本実施形態に係るデバイスシステム制御方法のデバイス異常状態発生段階によれば、クラスタ３０１において、デバイス１ｘのデバイスエージェント１０ｘは、自己のデバイス１ｘがデバイスポリシの異常状態ポリシ情報の異常状態に該当するか否かを判断し、異常状態に該当する場合に他のデバイス１ｘへ自己のデバイス１ｘの異常状態を通知する。また、クラスタ３０１において、デバイス１ｘのデバイスエージェント１０ｘは、他のデバイス１ｘの異常状態の通知に応じてデバイスポリシの対処動作ポリシ情報の対処動作を自己のデバイス１ｘに実行させる。これにより、クラスタ３０１において、あるデバイス１ｘの異常状態の発生時に、他のデバイス１ｘが自律的に対処動作を行うことができるので、デバイスの異常状態の発生時における管理サーバ１０のデバイスの制御にかかる負担を軽減させることができる。
【００６２】
また、異常状態が発生したデバイスと同じクラスタに属する他のデバイスが対処動作を行うことによって、デバイスの異常状態による不具合を補うことができる。
【００６３】
また、管理サーバ１０に故障が通知されたデバイスの交換用デバイスや修理依頼を自動的に発注することができる。これにより、デバイスの稼働停止時間を抑制することができる。
【００６４】
［デバイス故障状態発生段階］
図５を参照して、本実施形態に係るデバイスシステム制御方法におけるデバイス故障状態発生段階を説明する。図５は、本実施形態に係るデバイスシステム制御方法におけるデバイス故障状態発生段階の手順の例を示すシーケンス図である。ここでは、管理サーバ１０が管理するクラスタ３０１に属するデバイス１３に故障状態が発生する場合を例に挙げて、以下の説明を行う。なお、クラスタ３０１に属する他のデバイス１ｘに故障状態が発生する場合も、以下の説明と同様である。
【００６５】
（ステップＳ３１）  クラスタ３０１に属するデバイス１ｘのデバイスエージェント１０ｘは、自己のデバイス１ｘの生存を通知する生存通知メッセージを、一定の周期でブローカ５０３へ送信する。
【００６６】
（ステップＳ３２）  クラスタ３０１に属するデバイス１ｘのデバイスエージェント１０ｘは、一定の周期でブローカ５０３にアクセスし、他のデバイス１ｘの生存通知メッセージをブローカ５０３から取得する生存通知メッセージ取得処理を実行する。デバイス１ｘのデバイスエージェント１０ｘは、生存通知メッセージ取得処理を実行して、他のデバイス１ｘの生存通知メッセージを取得する。デバイス１ｘのデバイスエージェント１０ｘは、クラスタ３０１に属する他の全てのデバイス１ｘの生存通知メッセージを取得できた場合、故障状態が発生したデバイス１ｘが存在しないと判断する。
【００６７】
（ステップＳ３２ａ）  次いで、デバイス１３に故障状態が発生し、デバイス１３が生存通知メッセージを、一定の周期でブローカ５０３へ送信することができなくなる。これにより、各デバイス１４、１５のデバイスエージェント１０４、１０５は、生存通知メッセージ取得処理を実行しても、デバイス１３の生存通知メッセージを取得できない。次いで、デバイスエージェント１０４、１０５は、ステップＳ３３、Ｓ３４、Ｓ３５を実行する。以下、ステップＳ３３、Ｓ３４、Ｓ３５の処理についてデバイスエージェント１０４を例に挙げて説明するが、デバイスエージェント１０５についても同様である。
【００６８】
（ステップＳ３３）  デバイス１４のデバイスエージェント１０４は、デバイス１３の生存通知メッセージを取得できない場合、デバイス１３で発生した故障状態を認識し、デバイスポリシの対処動作ポリシ情報の対処動作を確認する。
【００６９】
（ステップＳ３４）  デバイスエージェント１０４は、デバイスポリシの対処動作ポリシ情報の対処動作を自己のデバイス１４に実行させる。具体的には、デバイスエージェント１０４は、当該対処動作の設定を自己のデバイス１４に行う。当該対処動作の設定が行われたデバイス１４は、当該対処動作の設定に従って当該対処動作を行う。
【００７０】
（ステップＳ３５）  デバイスエージェント１０４は、自己のデバイス１４に対して行った設定変更の内容（対処動作の設定の内容）を通知する設定変更状態通知メッセージを、ブローカ５０３へ送信する。ブローカ５０３は、設定変更状態通知メッセージを保持する。
【００７１】
上述のステップＳ３３、Ｓ３４、Ｓ３５の処理によって、ブローカ５０３には、デバイス１４の設定変更状態通知メッセージとデバイス１５の設定変更状態通知メッセージとが保持される。
【００７２】
（ステップＳ３６）  各デバイス１４、１５のデバイスエージェント１０４、１０５は、状態通知メッセージ取得処理を実行して、ブローカ５０３から、他のデバイス１ｘ（デバイスエージェント１０４はデバイス１５、デバイスエージェント１０５はデバイス１４）の設定変更状態通知メッセージを取得する。デバイスエージェント１０４、１０５は、他のデバイス１ｘの設定変更状態通知メッセージにより、当該他のデバイス１ｘの設定変更の内容（対処動作の設定の内容）を記録する。デバイスエージェント１０４、１０５は、当該他のデバイス１ｘの設定変更の内容（対処動作の設定の内容）がデバイスポリシの対処動作ポリシ情報の対処動作に該当することを確認する。これにより、デバイスエージェント１０４、１０５は、対処動作によってデバイス１３の故障状態による不具合が補われたと判断する。
【００７３】
（ステップＳ３７）  デバイス１５のデバイスエージェント１０５は、デバイス１３の故障状態を通知する故障通知メッセージを、ブローカ５０２へ送信する。ブローカ５０２は、デバイス１３の故障通知メッセージを保持する。なお、図５の例では、デバイス１５のデバイスエージェント１０５がデバイス１３の故障通知メッセージをブローカ５０２へ送信するが、故障通知メッセージをブローカ５０２へ送信するデバイスエージェント１０ｘは予め設定される。
【００７４】
（ステップＳ２１）  ＩｏＴＧＷ１１のＧＷエージェント１０２は、通知メッセージ取得処理を実行して、ブローカ５０２から、デバイス１３の故障通知メッセージを取得する。
【００７５】
次いで図４の処理がＧＷエージェント１０２により実行される。
（ステップＳ２２）  ＧＷエージェント１０２は、デバイス１３の故障通知メッセージに基づいて、デバイス１３に故障状態が発生したことを認識する。
【００７６】
次いでステップＳ２３、Ｓ２４、Ｓ２５が実行される。ステップＳ２３、Ｓ２４、Ｓ２５は、上述したデバイス異常状態発生段階と同じである。
【００７７】
上述した本実施形態に係るデバイスシステム制御方法のデバイス故障状態発生段階によれば、クラスタ３０１において、デバイス１ｘのデバイスエージェント１０ｘは、自己のデバイス１ｘの生存を一定の周期で他のデバイス１ｘへ通知する。また、クラスタ３０１において、デバイス１ｘのデバイスエージェント１０ｘは、他のデバイス１ｘの生存の通知を一定の周期で取得できない場合に、デバイスポリシの対処動作ポリシ情報の対処動作を自己のデバイス１ｘに実行させる。これにより、クラスタ３０１において、あるデバイス１ｘの故障状態の発生時に、他のデバイス１ｘが自律的に対処動作を行うことができるので、デバイスの故障状態の発生時における管理サーバ１０のデバイスの制御にかかる負担を軽減させることができる。
【００７８】
また、故障状態が発生したデバイスと同じクラスタに属する他のデバイスが対処動作を行うことによって、デバイスの故障状態による不具合を補うことができる。
【００７９】
また、管理サーバ１０に故障が通知されたデバイスの交換用デバイスや修理依頼を自動的に発注することができる。これにより、デバイスの稼働停止時間を抑制することができる。
【００８０】
［本実施形態の実施例］
次に図６、図７を参照して、本実施形態の実施例を説明する。本実施例は、本実施形態に係る図１のデバイスシステム１を街の街灯システムに適用する例である。図６は、本実施形態に係るデバイスシステムの実施例の街灯システムを示す説明図である。図７は、本実施形態に係るデバイスの実施例の街灯装置を示すブロック図である。
【００８１】
図６において、駅Ｓｔａに比較的近い場所に、街灯装置１３ａ、１４ａ、１５ａ、１６ａ、１７ａが街路沿いに並べて設置されている。また、駅Ｓｔａから比較的遠い場所に、街灯装置１３ｂ、１４ｂ、１５ｂ、１６ｂが街路沿いに並べて設置されている。街灯装置１３ａ、１４ａ、１５ａ、１６ａ、１７ａは、街灯装置１３ｂ、１４ｂ、１５ｂ、１６ｂよりも短い間隔で設置されている。
【００８２】
街灯装置１３ａ、１４ａ、１５ａ、１６ａ、１７ａと街灯装置１３ｂ、１４ｂ、１５ｂ、１６ｂとは属するクラスタが異なる。街灯装置１３ａ、１４ａ、１５ａ、１６ａ、１７ａは、同じクラスタ３０１ａに属する。街灯装置１３ｂ、１４ｂ、１５ｂ、１６ｂは、同じクラスタ３０１ｂに属する。クラスタ３０１ａ、３０１ｂは同じ管理サーバ１０（図６中に図示せず）の管理下にある。また、クラスタ３０１ａ、３０１ｂは同じＩｏＴＧＷ１１（図６中に図示せず）の管理下にある。
【００８３】
図７に示される街灯装置の構成は、各街灯装置１３ａ−１７ａ、１３ｂ−１６ｂに共通である。以下、街灯装置１３ａ−１７ａを特に区別しないときは街灯装置１ｘａと称し、街灯装置１３ｂ−１６ｂを特に区別しないときは街灯装置１ｘｂと称する。また、街灯装置１ｘａ、１ｘｂを特に区別しないときは街灯装置１ｘと称する。また、クラスタ３０１ａ、３０１ｂを特に区別しないときはクラスタ３０１と称する。
【００８４】
図７において、街灯装置１ｘは、一又は複数のＬＥＤ（light emitting diode）３１と、ＬＥＤコントローラ３２と、デバイスエージェント１０ｘと、無線装置３３と、照度センサ３４と、日照センサ３５とを備える。
【００８５】
ＬＥＤ３１は、街灯として街路を照らす光源である。ＬＥＤ３１は、点灯及び消灯を切り替えることができる。また、ＬＥＤ３１は、発光出力が可変であり、発光出力に応じた明るさで街路を照らすことができる。また、ＬＥＤ３１は、照光方向を変更するための駆動部（図示せず）を備え、駆動部によって街路を照らす方向を変えることができる。
【００８６】
ＬＥＤコントローラ３２は、ＬＥＤ３１を制御する。ＬＥＤコントローラ３２は、ＬＥＤ３１の点灯及び消灯、ＬＥＤ３１が街路を照らす明るさ（ＬＥＤ３１の発光出力）、ＬＥＤ３１が街路を照らす方向（ＬＥＤ３１の照光方向）などを制御する。
【００８７】
デバイスエージェント１０ｘは、本実施形態に係るデバイスエージェントの機能を備え、街灯装置１ｘのデバイスエージェントとして機能する。
【００８８】
無線装置３３は、自己のデバイス１ｘが属するクラスタ３０１を管理するＩｏＴＧＷ１１（図６には図示せず）のブローカ５０２（図６には図示せず）との間で無線により通信を行う。また、無線装置３３は、自己のデバイス１ｘが属するクラスタ３０１に対応するブローカ５０３（図６には図示せず）との間で無線により通信を行う。
【００８９】
照度センサ３４は、自己のデバイス１ｘのＬＥＤ３１が照らす対象の街路周辺の照度を検出するセンサである。日照センサ３５は、自己のデバイス１ｘのＬＥＤ３１が照らす対象の街路周辺への日射の強さを検出するセンサである。一般に、照度センサ３４及び日照センサ３５は、ＬＥＤ３１とは離れた位置に設置される。
【００９０】
次に図６に示される街灯システムに係るデバイスシステム制御方法を説明する。
【００９１】
街灯システムにおいて、デバイスポリシは、上述した図２に係るデバイスポリシ配布段階と同様に、各街灯装置１ｘに配布される。但し、街灯装置１ｘａと街灯装置１ｘｂとは属するクラスタが異なる。このため、街灯装置１ｘａに配布されるデバイスポリシは、クラスタ３０１ａに属する街灯装置１ｘａの状況に適合するように、基本デバイスポリシがＧＷエージェント１０２によって変更されたものである。一方、街灯装置１ｘｂに配布されるデバイスポリシは、クラスタ３０１ｂに属する街灯装置１ｘｂの状況に適合するように、基本デバイスポリシがＧＷエージェント１０２によって変更されたものである。
【００９２】
具体的には、クラスタ３０１ａとクラスタ３０１ｂとでは、街灯装置の設置密度及び設置間隔が異なる。このため、クラスタ３０１ａの街灯装置の設置密度及び設置間隔に応じて基本デバイスポリシがＧＷエージェント１０２によって変更されたデバイスポリシが、クラスタ３０１ａに属する各街灯装置１ｘａへ配布される。一方、クラスタ３０１ｂの街灯装置の設置密度及び設置間隔に応じて基本デバイスポリシがＧＷエージェント１０２によって変更されたデバイスポリシが、クラスタ３０１ｂに属する各街灯装置１ｘｂへ配布される。
【００９３】
次に図３及び図４を参照して、図６に示される街灯システムに係るデバイスシステム制御方法におけるデバイス異常状態発生段階の例を説明する。クラスタ３０１ａに属する街灯装置１３ａに異常状態が発生する場合を例に挙げて、以下の説明を行う。なお、クラスタ３０１ａに属する他の街灯装置１ｘａに異常状態が発生する場合、及び、クラスタ３０１ｂに属する街灯装置１ｘｂに異常状態が発生する場合についても、以下の説明と同様である。
【００９４】
（ステップＳ１０）  街灯装置１３ａのデバイスエージェント１０３は、一定の周期で、デバイスポリシ確認ステップＳ１１を繰り返し実行する。デバイスポリシ確認ステップＳ１１では、デバイスエージェント１０３は、自己の街灯装置１３ａの照度センサ３４の検出値がデバイスポリシの異常状態ポリシ情報の異常状態の判定用閾値未満であるか否かを判断する。この判断の結果、照度センサ３４の検出値が異常状態の判定用閾値未満である場合にはステップＳ１２に進み、ステップＳ１１の繰り返し実行を中断し、ステップＳ１３でポリシ違反を認識する。ポリシ違反を認識した後、ステップＳ１４へ進む。一方、デバイスポリシ確認ステップＳ１１の判断の結果、照度センサ３４の検出値が異常状態の判定用閾値以上である場合には、一定の周期で、デバイスポリシ確認ステップＳ１１を繰り返す。
【００９５】
（ステップＳ１４）  デバイスエージェント１０３は、自己の街灯装置１３ａの異常状態を通知する異常状態通知メッセージを、ブローカ５０３へ送信する。この街灯装置１３ａの異常状態通知メッセージは、街灯装置１３ａが正常に街路を照らせていない異常状態を示すメッセージである。ブローカ５０３は、街灯装置１３ａの異常状態通知メッセージを保持する。
【００９６】
（ステップＳ１５）  クラスタ３０１ａに属する街灯装置１ｘａのデバイスエージェント１０ｘは、一定の周期で状態通知メッセージ取得処理を実行して、ブローカ５０３から状態通知メッセージを取得する。これにより、街灯装置１３ａの異常状態通知メッセージが街灯装置１４ａ−１７ａのデバイスエージェント１０ｘによってそれぞれ取得される。
【００９７】
次いで、各街灯装置１４ａ−１７ａのデバイスエージェント１０ｘは、ステップＳ１６、Ｓ１７、Ｓ１８を実行する。以下、ステップＳ１６、Ｓ１７、Ｓ１８の処理について街灯装置１４ａのデバイスエージェント１０４を例に挙げて説明するが、他の各街灯装置１５ａ−１７ａのデバイスエージェント１０ｘについても同様である。
【００９８】
（ステップＳ１６）  街灯装置１４ａのデバイスエージェント１０４は、街灯装置１３ａの異常状態通知メッセージに基づいて、街灯装置１３ａが正常に街路を照らせていない異常状態を認識し、デバイスポリシの対処動作ポリシ情報の該当する対処動作を確認する。
【００９９】
（ステップＳ１７）  街灯装置１４ａのデバイスエージェント１０４は、確認結果の対処動作を自己の街灯装置１４ａに実行させる。具体的には、デバイスエージェント１０４は、当該対処動作の設定を自己の街灯装置１４ａのＬＥＤコントローラ３２に行う。当該対処動作の設定が行われたＬＥＤコントローラ３２は、当該対処動作の設定に従ってＬＥＤ３１を制御する。
【０１００】
ここでの対処動作の一例として、街灯装置１４ａは、街灯装置１３ａに隣接しているので、街灯装置１４ａのＬＥＤ３１の発光出力を上げ、さらに、街灯装置１４ａのＬＥＤ３１の照光方向を街灯装置１３ａの方向へ所定量だけずらす。これにより、街灯装置１３ａが正常に街路を照らせていないことによる街路への照度不足を補うことができる。
【０１０１】
なお、ここでの街灯装置１５ａにおける対処動作の一例として、街灯装置１５ａは、街灯装置１３ａに隣接していないが、街灯装置１４ａに隣接しているので、街灯装置１４ａのＬＥＤ３１の発光出力を上げ、さらに、街灯装置１４ａのＬＥＤ３１の照光方向を街灯装置１３ａの方向へ所定量だけずらす。これにより、街灯装置１４ａが街灯装置１３ａの不具合による街路への照度不足を補うことによって生じる、街灯装置１４ａによる街路への照度の減少、を補うことができる。また、街灯装置１６ａ、１７ａについても、街灯装置１５ａと同様の対処動作を行う。
【０１０２】
（ステップＳ１８）  街灯装置１４ａのデバイスエージェント１０４は、自己の街灯装置１４ａに対して行った設定変更の内容（対処動作の設定の内容）を通知する設定変更状態通知メッセージを、ブローカ５０３へ送信する。ブローカ５０３は、街灯装置１４ａの設定変更状態通知メッセージを保持する。
【０１０３】
上述のステップＳ１６、Ｓ１７、Ｓ１８の処理によって、ブローカ５０３には、各街灯装置１４ａ、１５ａ、１６ａ、１７ａの設定変更状態通知メッセージが保持される。
【０１０４】
（ステップＳ１９）  クラスタ３０１ａに属する街灯装置１ｘａのデバイスエージェント１０ｘは、状態通知メッセージ取得処理を実行して、ブローカ５０３から、他の街灯装置１ｘａの設定変更状態通知メッセージを取得する。街灯装置１ｘａのデバイスエージェント１０ｘは、他の街灯装置１ｘａの設定変更状態通知メッセージにより、当該他の街灯装置１ｘａの設定変更の内容（対処動作の設定の内容）を記録する。街灯装置１ｘａのデバイスエージェント１０ｘは、当該他の街灯装置１ｘａの設定変更の内容（対処動作の設定の内容）がデバイスポリシの対処動作ポリシ情報の対処動作に該当することを確認する。これにより、街灯装置１ｘａのデバイスエージェント１０ｘは、対処動作によってクラスタ３０１ａに関する街路への照度がほぼ正常状態に補われたと判断する。
【０１０５】
（ステップＳ２０）  街灯装置１３ａのデバイスエージェント１０３は、自己の街灯装置１３ａの異常状態を通知する異常通知メッセージを、ブローカ５０２へ送信する。この街灯装置１３ａの異常通知メッセージは、街灯装置１３ａが正常に街路を照らせていない異常状態を示すと共に、対処動作によって街路への照度がほぼ正常状態に補われたことを示すメッセージである。ブローカ５０２は、街灯装置１３ａの異常通知メッセージを保持する。
【０１０６】
（ステップＳ２１）  ＩｏＴＧＷ１１のＧＷエージェント１０２は、一定の周期で通知メッセージ取得処理を実行して、ブローカ５０２から、街灯装置１３ａの異常通知メッセージを取得する。
【０１０７】
次いで図４に示されるステップＳ２２、Ｓ２３、Ｓ２４、Ｓ２５が、上述したデバイスシステム１の場合と同様に実行される。
【０１０８】
なお、街灯システムに係るデバイス故障状態発生段階は、上述した図５に示されるデバイスシステム１と同様である。
【０１０９】
上述した街灯システムによれば、街灯装置に不具合が生じた場合、当該街灯装置と同じクラスタに属する他の街灯装置が自律的に対処動作を行うことによって、当該クラスタに関する街路への照度を自動的にほぼ正常状態に補うことができる。
【０１１０】
なお、上述した実施例では、本実施形態を街灯システムに適用したが、本実施形態は各種のシステムに適用できる。例えば、大気や騒音や河川の水位等の環境状況を監視する環境監視システム、各種の気象データを観測する気象観測システム、道路の交通量や渋滞等の交通状況を監視する交通監視システム、建物や街等の監視カメラシステム、電気やガスや水道等の使用量計測システム、建物や街等の警備システムなどに、本実施形態を適用してもよい。
【０１１１】
以上説明したように本実施形態によれば、例えば街灯システム等のデバイスシステムにおいて、複数のデバイスの制御にかかる負担を軽減させることができるという効果が得られる。また、以下に示すような効果が得られる。
【０１１２】
（１）本実施形態によれば、各デバイスのデバイスエージェントがデバイスポリシ基づいて自律的に動作の設定や設定変更を行うことができるので、管理者が一つ一つのデバイスに対して動作の設定や設定変更を行う負担を軽減することが可能になる。これにより、デバイスシステムにおける管理コストの削減を図ることができる。
【０１１３】
（２）本実施形態によれば、デバイスに異常状態や故障状態が発生して当該デバイスが属するクラスタに関する不具合（例えば、街灯装置の異常状態や故障状態の発生によるクラスタ担当の街路への照度不足）が生じた場合に、クラスタ内の他のデバイスによる対処動作によって、自動的に、クラスタに関する不具合をほぼ正常状態に補うことができる。これにより、デバイスに異常状態や故障状態が発生した場合にその都度、管理者が復旧作業を行う負担を軽減することが可能になる。また、デバイスシステムにおけるサービスダウンやサービス低下となる期間の短縮や障害対応コストの削減などの効果が得られる。
【０１１４】
（３）本実施形態によれば、デバイスシステムの制御構成は、中央管理エージェントとＧＷエージェントとデバイスエージェントから成る３層構造になっているので、各エージェントの改修や機能追加等の変更作業において相互の影響を受けづらい。このため、各エージェントの変更を柔軟に実行することができる。
【０１１５】
（４）本実施形態によれば、中央管理エージェントがデバイスを直接制御しなくてもよいので、管理サーバのリソースを増強しなくてもデバイスの増設に対応することができる。これにより、管理サーバのコスト削減に寄与することができる。
【０１１６】
（５）本実施形態によれば、中央管理エージェントの発注機能によって、故障通知があったデバイスの交換用デバイスや修理依頼の発注処理を自動的に行うことができる。これにより、不具合のデバイスの復旧時期を早めることができる。
【０１１７】
（６）本実施形態によれば、デバイスエージェントは、異常状態通知メッセージの取得ありや生存通知メッセージの取得なし等のイベントをトリガとして自己のデバイスの動作の設定を変更するので、省電力化に寄与することができる。
【０１１８】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【０１１９】
例えば、上述した各装置の機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０１２０】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【０１２１】
１…デバイスシステム、１０…管理サーバ、１１…ＩｏＴゲートウェイ、１３，１４，１５…デバイス、１０１…中央管理エージェント、１０２…ＧＷエージェント、１０３，１０４，１０５…デバイスエージェント、５０１，５０２，５０３…ブローカ、１３ａ−１７ａ，１３ｂ−１６ｂ…街灯装置、３１…ＬＥＤ、３２…ＬＥＤコントローラ、３３…無線装置、３４…照度センサ、３５…日照センサ
【図１】
2020027336.tif 000003
【図２】
2020027336.tif 000004
【図３】
2020027336.tif 000005
【図４】
2020027336.tif 000006
【図５】
2020027336.tif 000007
【図６】
2020027336.tif 000008
【図７】
2020027336.tif 000009