(57)【要約】【課題】監視対象機器を活用したサービスにおいて、アプリケーションの実行箇所を監視対象機器、監視対象機器設置拠点と監視拠点の３カ所から選択し、システム性能を最大化する。【解決手段】監視対象機器と、監視対象機器からのサービス要求を処理する機能を備えるサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点がネットワークで接続され、拠点のいずれかに設置されている運用監視サーバが監視対象機器の運用を監視する運用監視システムであって、監視対象機器は自身の状態情報を、および／または、監視対象機器が設置されている拠点にある第一のサービス要求処理装置は当該拠点の状態情報を、運用監視サーバへ送信し、運用監視サーバは、送信された状態情報を取得し、取得した状態情報に基づき、監視対象機器からのサービス要求を処理する機能を備える複数のサービス要求処理装置のいずれかを選択する。【選択図】  図１
2018005431.tif 000002
【特許請求の範囲】
【請求項１】
監視対象機器と、前記監視対象機器が設置されている拠点と、のいずれか一方または両方の状態情報を取得し、
取得した前記状態情報に基づき、前記監視対象機器からのサービス要求を処理する機能を備える複数のサービス要求処理装置のいずれかを選択する
ことを特徴とする運用監視サーバ。
【請求項２】
請求項１に記載の運用監視サーバであって、
前記監視対象機器と、第一の前記サービス要求処理装置が設置されている前記拠点と、のいずれか一方または両方のリソース情報を取得し、
前記状態情報と、取得した前記リソース情報と、に基づき、前記監視対象機器用のサービス要求処理装置を選択する
ことを特徴とする運用監視サーバ。
【請求項３】
請求項１に記載の運用監視サーバであって、
前記拠点は、前記監視対象機器が設置されている拠点と、前記監視対象機器が設置されていない拠点と、のいずれかである
ことを特徴とする運用監視サーバ。
【請求項４】
請求項１に記載の運用監視サーバであって、
選択した前記サービス要求処理装置が、前記監視対象機器に登録されている現用のサービス要求処理装置とは異なる場合、前記監視対象機器へ、サービス要求処理装置の変更を通知する
ことを特徴とする運用監視サーバ。
【請求項５】
請求項１に記載の運用監視サーバであって、
前記変更の通知後に、現用のサービス要求処理装置に対して、当該装置において実行中の、前記サービス要求を処理する前記機能の停止を指示する
ことを特徴とする運用監視サーバ。
【請求項６】
請求項１に記載の運用監視サーバであって、
変更の通知前に、変更後のサービス要求処理装置において、前記サービス要求を処理する前記機能の起動を指示する
ことを特徴とする運用監視サーバ。
【請求項７】
請求項２に記載の運用監視サーバであって、
前記監視対象機器の前記状態情報と前記リソース情報とを、ネットワークにより前記監視対象機器と接続された前記第一のサービス要求処理装置を介して取得する
ことを特徴とする運用監視サーバ。
【請求項８】
請求項１に記載の運用監視サーバであって、
前記拠点の状態情報を、ネットワークにより前記監視対象機器と接続された前記第一のサービス要求処理装置から取得する
ことを特徴とする運用監視サーバ。
【請求項９】
請求項１に記載の運用監視サーバであって、
現用または変更後の前記サービス要求処理装置は、前記監視対象機器と、ネットワークにより前記監視対象機器と接続された前記第一のサービス要求処理装置と、ネットワークにより前記運用監視サーバと接続された第二の前記サービス要求処理装置と、のいずれかである
ことを特徴とする運用監視サーバ。
【請求項１０】
監視対象機器と、前記監視対象機器からのサービス要求を処理する機能を備えるサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点がネットワークで接続され、前記拠点のいずれかに設置されている運用監視サーバが前記監視対象機器の運用を監視する運用監視システムであって、
前記監視対象機器は自身の状態情報を、および／または、前記監視対象機器が設置されている拠点にある第一の前記サービス要求処理装置は当該拠点の状態情報を、前記運用監視サーバへ送信し、
前記運用監視サーバは、
送信された前記状態情報を取得し、
取得した前記状態情報に基づき、前記監視対象機器からのサービス要求を処理する機能を備える複数のサービス要求処理装置のいずれかを選択する
ことを特徴とする運用監視システム。
【請求項１１】
請求項１０に記載の運用監視システムであって、
前記監視対象機器と、前記第一のサービス要求処理装置と、のいずれか一方または両方は、自身のリソース情報を、前記運用監視サーバへ送信し、
前記運用監視サーバは、
送信された前記リソース情報を取得し、
前記状態情報と、取得した前記リソース情報と、に基づき、前記監視対象機器用のサービス要求処理装置を選択する
ことを特徴とする運用監視システム。
【請求項１２】
請求項１０に記載の運用監視システムであって、
前記拠点は、前記監視対象機器が設置されている拠点と、前記監視対象機器が設置されていない拠点と、のいずれかである
ことを特徴とする運用監視システム。
【請求項１３】
請求項１０に記載の運用監視システムであって、
前記運用監視サーバは、
選択した前記サービス要求処理装置が、前記監視対象機器に登録されている現用のサービス要求処理装置とは異なる場合、前記監視対象機器へ、サービス要求処理装置の変更を通知する
ことを特徴とする運用監視システム。
【請求項１４】
請求項１０に記載の運用監視システムであって、
前記運用監視サーバは、
前記変更の通知後に、現用のサービス要求処理装置に対して、当該装置において実行中の、前記サービス要求を処理する前記機能の停止を指示する
ことを特徴とする運用監視システム。
【請求項１５】
請求項１０に記載の運用監視システムであって、
前記運用監視サーバは、
変更の通知前に、変更後のサービス要求処理装置において、前記サービス要求を処理する前記機能の起動を指示する
ことを特徴とする運用監視システム。
【請求項１６】
請求項１１に記載の運用監視システムであって、
前記監視対象機器は、前記状態情報と前記リソース情報とを、ネットワークにより接続された拠点内の前記第一のサービス要求処理装置へ送信し、
前記拠点内の第一のサービス要求処理装置は、受信した前記状態情報と前記リソース情報とを、前記運用監視サーバへ送信し、
前記運用監視サーバは、
前記拠点内の第一のサービス要求処理装置から、前記監視対象機器の前記状態情報と前記リソース情報とを受信する
ことを特徴とする運用監視システム。
【請求項１７】
請求項１０に記載の運用監視システムであって、
ネットワークにより前記監視対象機器と接続された前記第一のサービス要求処理装置は、前記拠点の状態情報を前記運用監視サーバへ送信し、
前記運用監視サーバは、
前記拠点の状態情報を、前記拠点内の前記第一のサービス要求処理装置から受信する
ことを特徴とする運用監視システム。
【請求項１８】
請求項１０に記載の運用監視システムであって、
現用または変更後の前記サービス要求処理装置は、前記監視対象機器と、ネットワークにより前記監視対象機器と接続された前記第一のサービス要求処理装置と、ネットワークにより前記運用監視サーバと接続された第二の前記サービス要求処理装置と、のいずれかである
ことを特徴とする運用監視システム。
【発明の詳細な説明】
【技術分野】
【０００１】
開示される主題は、移動可能な機器の運用監視技術に関する。
【背景技術】
【０００２】
あらゆる機器をインターネットに接続し、種々のサービスを提供するＩｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ（ＩｏＴ）技術が普及しつつある。ＩｏＴに対応する機器（ＩｏＴ機器）にはセンサーのように定型処理のみを行う低機能端末から、ロボットのように提供する機能をソフトウェアによって変更できる高機能端末までさまざまな種類の機器が存在する。
【０００３】
インターネットに接続される機器の数が急速に増加する中、これらの機器を用いて何らかの機能を実現する場合、高品質なサービスを実現するためには、アプリケーションプログラム（以下、アプリケーションまたはＡＰＰと記す）の負荷分散および／または応答時間の削減が一つの課題となる。
【０００４】
この課題を解決するには、どのようにアプリケーションを配備するか、および／または、機器に対して、どのように運用機能と監視機能を提供するかの検討が有効である。
【０００５】
関連する技術として、特許文献１は複数のデータセンタ間でアプリケーションを実行する際の負荷分散技術を開示している。
【０００６】
また、特許文献２はＩＰＴＶシステムにおいて、データセンタとエッジサーバのいずれかにコンテンツを配置して配信する技術を公開している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１５―１５３３７０号公報
【特許文献２】特表２０１３―５１６８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ロボットのように移動が可能な機器に関しては、移動前後の滞在場所および／または、稼働時間帯、などの外的条件（状態情報）によって、求められる機能や提供すべき機能が異なる場合がある。従って、負荷分散および／または応答時間の削減について、これらの外的条件（状態情報）を考慮することは有効であるが、先行技術文献では、状態情報を考慮していない。
【０００９】
すなわち、特許文献１ではアプリケーションを実行する対象はデータセンタのサーバが主体であり、サーバの選択基準としてＣＰＵ負荷、通信帯域などの計算機資源のみを考慮している。
【００１０】
特許文献２が公開するＩＰＴＶシステムでは、分散配置の対象がメディアコンテンツであり、それ以外のアプリケーションをデータセンタ、もしくはエッジサーバに配置してサービスを提供することは開示していない。また、上述した外的条件（状態情報）を考慮していない．
従って、状態情報を考慮することにより高品質なサービスを実現する、様々な機器に対するアプリケーションの配備方法、および／または、機器に対する運用機能と監視機能の提供方法が求められている。
【課題を解決するための手段】
【００１１】
一例として開示されるのは、監視対象機器と、監視対象機器からのサービス要求を処理する機能を備えるサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点がネットワークで接続され、拠点のいずれかに設置されている運用監視サーバが監視対象機器の運用を監視する運用監視システムと、運用監視サーバである。
【００１２】
運用監視システムにおいて、監視対象機器は自身の状態情報を、および／または、監視対象機器が設置されている拠点にある第一のサービス要求処理装置は当該拠点の状態情報を、運用監視サーバへ送信し、運用監視サーバは、送信された状態情報を取得し、取得した状態情報に基づき、監視対象機器からのサービス要求を処理する機能を備える複数のサービス要求処理装置のいずれかを選択する、ことを特徴とする。
【００１３】
さらに、監視対象機器と、第一のサービス要求処理装置と、のいずれか一方または両方は、自身のリソース情報を、運用監視サーバへ送信し、運用監視サーバは、送信されたリソース情報を取得し、状態情報と、取得したリソース情報と、に基づき、監視対象機器用のサービス要求処理装置を選択する、ように上記運用監視システムを構成してもよい。
【００１４】
さらに、運用監視サーバは、選択したサービス要求処理装置が、監視対象機器に登録されている現用のサービス要求処理装置とは異なる場合、監視対象機器へ、サービス要求処理装置の変更を通知する、ように上記運用監視システムを構成してもよい。
【発明の効果】
【００１５】
開示される機器運用監視装置および機器運用監視システムは、高品質なサービスを提供することを可能にする。
【図面の簡単な説明】
【００１６】
【図１】一実施形態の機器運用監視システムのブロック図
【図２】ロボットの構造を例示するブロック図
【図３】ロボットが管理するデータの構造を例示するブロック図
【図４】ＡＰＰ制御サーバの構造を例示するブロック図
【図５】ＡＰＰ制御サーバが管理するデータの構造を例示するブロック図
【図６】中央ＡＰＰ制御サーバの構造を例示するブロック図
【図７】中央ＡＰＰ制御サーバが管理するデータの構造を例示するブロック図
【図８】運用監視サーバの構造を例示するブロック図
【図９】運用監視サーバが管理するデータの構造を例示するブロック図
【図１０】実施形態のアプリケーション制御処理の一例を説明する時系列図１
【図１１】実施形態のアプリケーション制御処理の一例を説明する時系列図２
【図１２】実施形態のアプリケーション制御処理の一例を説明する時系列図３
【図１３】実施形態のアプリケーション制御処理の一例を説明する時系列図４
【図１４】実施形態のアプリケーション制御処理の一例を説明する時系列図５
【図１５】実施形態のアプリケーション制御処理の一例を説明する時系列図６
【図１６】実施形態のアプリケーション制御処理の一例を説明する時系列図７
【図１７】実施形態のアプリケーション制御処理の一例を説明する時系列図８
【図１８】実施形態のアプリケーション制御処理の一例を説明する時系列図９
【図１９】サービス要求処理装置変更の判定方法の一例を説明するフローチャート
【図２０】サービス要求処理装置変更の判定条件の編集画面の一例
【発明を実施するための形態】
【００１７】
図１は本実施例における運用監視システムの構成の一例である。
【００１８】
運用監視システムは機器を設置した拠点を監視対象拠点（１−１〜１−Ｎ）とし、監視対象拠点に設置した監視対象機器を監視する。設置された機器は種々のアプリケーションを通じて利用者へサービスを提供する。
【００１９】
監視対象機器には様々な形態があるが、ここでは、ロボットと呼ぶ２１−１〜２１−Ｎの「自律移動が可能な情報処理装置（以降ロボット２１と総称）を対象として説明する。
【００２０】
ロボット２１は制御端末を含むため、ロボット２１自身の機構制御の他に、サーバと同様にアプリケーションを実行し利用者へサービスを提供することが可能だが、ロボット２１の制御端末はサーバのようにアプリケーションの実行に特化しているわけではない。このため、アプリケーションの実行に利用可能なＣＰＵ、内部記憶（メモリ）や外部記憶（ストレージ）などの計算機資源はサーバほど潤沢ではない。
【００２１】
このため、アプリケーションの実行を外部に設置したサーバに依存する場合もある。この場合、外部に設置したサーバにサービス要求を行い、サーバからサービス処理結果を受け取り利用者にサービスを提供する。サーバの設置個所は、ロボット２１と同じ監視対象拠点に設置する方法と、データセンタまたは監視センタに設置する方法の２通りがある。
【００２２】
監視対象拠点（１−１〜１−Ｎ）に設置したサーバをアプリケーション制御サーバ（３−１〜３−Ｎ、以下ＡＰＰ制御サーバ３と記載）、監視拠点である監視センタ６に設置したサーバを中央アプリケーション制御サーバ７（以下中央ＡＰＰ制御サーバ７と記載）と呼ぶ。これらのサーバは、サービス要求処理装置として機能する。
【００２３】
各監視対象拠点１において、ロボット２１とＡＰＰ制御サーバ３は、拠点内ＬＡＮである構内ＬＡＮ（４−１〜４−Ｎ）で接続され、監視センタ６において、運用監視サーバ８と中央ＡＰＰ制御サーバ７は拠点内ＬＡＮ９で接続される。ロボット２１、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は、構内ＬＡＮ４または拠点内ＬＡＮ９と、拠点間ネットワーク５と、を通じて相互に接続される。
【００２４】
各拠点に設置されたロボット２１、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は、機器運用監視システム内の機器、サーバを統括管理する運用監視サーバ８によって制御される。ロボット２１、ＡＰＰ制御サーバ３および中央ＡＰＰ制御サーバ７は、運用監視に必要な種々の情報を運用監視サーバ８に送信する。
【００２５】
次に、システムを構成する各装置について詳しく説明する。
【００２６】
図２はロボット２１の装置構造を示す。ロボット２１は、ロボット制御端末２と、制御対象のカメラ２９１、モータ２９２、マイク２９３、スピーカー２９４、アクチュエータ２９５、各種センサ２９６を含んで構成され、ロボット制御端末２と制御対象の各デバイスは、ロボット制御端末２の外部入出力インターフェース２９を通じて接続される。
【００２７】
ロボット制御端末２はバス２８に接続された制御部（ＣＰＵ）２２、メモリなどの内部記憶装置２６、ハードディスクなどの外部記憶装置２４、及びネットワークインターフェース２０を具備し、ネットワークインターフェース２０、構内ＬＡＮ４および拠点間ネットワーク５を介して通信を行う。
【００２８】
内部記憶装置２６には、ロボット２１の機構、姿勢、移動等を制御するロボット制御アプリケーション２６１を含む。内部記憶装置２６はさらに、ロボット２１自身の制御以外の機能、例えばセンサーによる情報収集や位置推定などの各種アプリケーション（２６２、２６３）を備える。各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。
【００２９】
これらのアプリケーションに加えて、ロボット２１はロボットの状態に関する情報を管理するロボット状態データベース（ＤＢ）２６４、ロボット２１のリソース使用状況を管理するロボットリソースＤＢ２６５、ロボット２１が利用している各種アプリケーションの接続先を管理するＡＰＰ接続先情報ＤＢ２６６を備える。
【００３０】
これらの各データベースは、システムの規模、ロボット制御端末２１の処理性能などに応じて、外部記憶装置２４に格納してもよい。これらのデータベースは内部記憶装置２６にインストールされているロボット制御アプリケーション２６１によって読み書きが行われる。
【００３１】
制御部（ＣＰＵ）２２が内部記憶装置２６に保存されたロボット制御アプリケーション２６１にアクセスすることで、ロボット２１の制御機能が実現される。
【００３２】
図３はロボット２１の内部記憶装置２６に存在する各種のデータベースの構造を表す。ロボット状態ＤＢ２６４はロボット２１自身の状態に関する情報を管理するデータベースであり、ロボット２１が設置されている監視対象拠点１の拠点マップ、場所名、Ｘ座標、Ｙ座標を含む。
【００３３】
拠点マップは設置拠点の形状、広さなど、拠点の物理的構造に関する情報であり、ロボット２１の設置時に情報の初期化が行われる。ロボット２１には自己位置推定機能があり、レーザーレンジファインダ等を用いて周囲の壁と自身の距離を測定することで、監視対象拠点１内の自身の位置（Ｘ座標、Ｙ座標）を判定できる。
【００３４】
拠点マップは拠点の物理的構造の他、場所に関する情報も含む。例えば座標を用いて拠点内の部屋に関する情報を定義することが可能である。
【００３５】
ロボットリソースＤＢ２６５はロボット制御端末２の計算機資源の利用状況を管理するデータベースであり、ロボット２１が設置されている監視対象拠点１の拠点識別子、当該拠点のネットワーク（ＮＷ）帯域、ネットワーク帯域利用率と、ロボット制御端末上で稼働しているアプリケーションのリストである稼働中ＡＰＰリストを含む。稼働中ＡＰＰリストの一項目は、システム内でアプリケーションを一意に特定するＡＰＰ識別子、当該アプリケーションのＣＰＵ使用率と消費ＮＷ帯域を含む。
【００３６】
ＡＰＰ接続先情報ＤＢ２６６は、ロボット２１が利用するアプリケーションのうち外部のサーバで動作しているアプリケーションの接続先を管理するデータベースであり、ＡＰＰ識別子と接続先を含む。例えば、音声認識処理が拠点内のＡＰＰ制御サーバ３で動作している場合、音声認識処理の接続先はＡＰＰ制御サーバ３となる。
【００３７】
図４はＡＰＰ制御サーバ３の装置構造を示す。ＡＰＰ制御サーバ３はバス３８に接続された制御部（ＣＰＵ）３２、メモリなどの内部記憶装置３６、ハードディスクなどの外部記憶装置３４、及びネットワークインターフェース３０を具備し、ネットワークインターフェース３０、構内ＬＡＮ４および拠点間ネットワーク５を介して通信を行う。
【００３８】
内部記憶装置３６には、アプリケーションの実行、起動、停止処理を行うＡＰＰ制御アプリケーション３６１を含む。内部記憶装置３６はさらに、ロボット２１に種々の機能を提供するための各種アプリケーション（３６２、３６３）を備える。
【００３９】
各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。アプリケーションは外部記憶装置３４にインストールされ、制御部（ＣＰＵ）３２によって必要時に起動される。
【００４０】
これらのアプリケーションに加えて、ＡＰＰ制御サーバ３は拠点の基本的な情報を管理する拠点基本情報ＤＢ３６４、拠点の計算機資源の利用状況を管理する拠点リソースＤＢ３６５、拠点の種々の状態を管理する拠点状態ＤＢ３６６、拠点内の全てのロボット２１のＡＰＰ接続状況を管理するロボット接続情報ＤＢ３６７、拠点内の全てのロボット２１の状態を管理するロボット状態ＤＢ３６８、拠点内の全てのロボット２１のリソース利用状況を管理するロボットリソースＤＢ３６９を備える。
【００４１】
これらの各データベースは、システムの規模、ＡＰＰ制御サーバ３の処理性能などに応じて、外部記憶装置３４に格納してもよい。これらのデータベースは内部記憶装置３６に読み込まれ、実行されているＡＰＰ制御アプリケーション２６１によって読み書きが行われる。
【００４２】
制御部（ＣＰＵ）３２が内部記憶装置３６に保存されたＡＰＰ制御アプリケーション３６１にアクセスすることで、ＡＰＰ制御サーバ３はアプリケーション制御処理を実行する。
【００４３】
図５はＡＰＰ制御サーバ３の内部記憶装置３６に存在する各種のデータベースの構造を表す。拠点基本情報ＤＢ３６４は監視対象拠点１の基本的な情報を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子と、固定ＡＰＰリストを含む。
【００４４】
固定ＡＰＰリストとはアプリケーションのうち必ず当該管理拠点１に設置されたＡＰＰ制御サーバ３で実行しなければならない、逆に言えばロボット２１や中央ＡＰＰ制御サーバ７で実行してはならないアプリケーションの識別子のリストである。
【００４５】
例えば、雑音に強い音声認識アプリケーションは、拠点の物理的構造に影響を受けるため、拠点内に実行環境がある方が望ましい。拠点基本情報ＤＢはこのようなアプリケーションのリストを保持する。
【００４６】
拠点リソースＤＢ３６５はＡＰＰ制御サーバ３の計算機資源の利用状況を管理するデータベースであり、ＡＰＰ制御サーバ３が設置されている監視対象拠点１の拠点識別子、当該拠点のネットワーク（ＮＷ）帯域、ネットワーク帯域利用率と、ＡＰＰ制御サーバ３上で稼働しているアプリケーションのリストである稼働中ＡＰＰリストを含む。稼働中ＡＰＰリストの一項目は、システム内でアプリケーションを一意に特定するＡＰＰ識別子、当該アプリケーションのＣＰＵ使用率と消費ＮＷ帯域を含む。
【００４７】
拠点状態ＤＢ３６６は拠点の種々の状態を管理するデータベースであり、拠点識別子、拠点マップ、拠点業務スケジュールを含む。拠点識別子と拠点マップは監視対象拠点内の全てのロボット２１と共有される。拠点業務スケジュールは監視対象拠点において実行される業務のスケジュールに関する情報を管理し、場所名、業務の開始時刻、終了時刻と業務内容を含む。
【００４８】
例えば、監視対象拠点１が銀行の場合、応対フロアでは、銀行の営業時間では預金の預け入れ、融資の相談などの通常の銀行業務が行われるが、銀行の営業時間外では応対フロアは不審人物の監視と検出が主な業務となるなど、時間帯によって提供業務が異なる。
【００４９】
ロボット接続情報ＤＢ３６７は監視対象拠点１内のロボット２１のアプリケーション利用状況を管理するデータベースであり、システム内でロボット２１を一意に特定するロボット識別子、ロボット２１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。
【００５０】
ロボット状態ＤＢ３６８は同一拠点に設置されているすべてのロボット２１の状態を管理するデータベースであり、基本的な構造はロボット２１のロボット状態ＤＢ２６４と同様である。
【００５１】
複数のロボット２１の状態を管理するために、ロボット２１のロボット状態ＤＢ２６４に加えてロボット識別子を含む。
【００５２】
ロボットリソースＤＢ３６９は同一拠点に設置されているすべてのロボット２１の計算機資源の利用状況を管理するデータベースであり、基本的な構造はロボット２１のロボットリソースＤＢ２６５と同様である。複数のロボット２１の状態を管理するために、ロボット２１のロボットリソースＤＢ２６５に加えてロボット識別子を含む。
【００５３】
図６は中央ＡＰＰ制御サーバ７の装置構造を示す。中央ＡＰＰ制御サーバ７はバス７８に接続された制御部（ＣＰＵ）７２、メモリなどの内部記憶装置７６、ハードディスクなどの外部記憶装置７４、及びネットワークインターフェース７０を具備し、ネットワークインターフェース７０、拠点内ＬＡＮ９および拠点間ネットワーク５を介して通信を行う。
【００５４】
内部記憶装置７６には、アプリケーションの実行、起動、停止処理を行う中央ＡＰＰ制御アプリケーション７６１を含む。内部記憶装置７６はさらに、ロボット２１に種々の機能を提供するための各種アプリケーション（７６２、７６３）を備える。各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。
【００５５】
アプリケーションは外部記憶装置７４にインストールされ、制御部（ＣＰＵ）７２によってシステムの稼働開始時に起動される。これらのアプリケーションに加えて、中央ＡＰＰ制御サーバ７は監視センタの計算機資源の利用状況を管理する拠点リソースＤＢ７６４、拠点のアプリケーションの利用状況を管理するＡＰＰ接続情報ＤＢ７６５、中央ＡＰＰ制御サーバ７に接続する全てのロボット２１のＡＰＰ接続状況を管理するロボット接続情報ＤＢ７６６を備える。
【００５６】
これらの各データベースは、システムの規模、中央ＡＰＰ制御サーバ７の処理性能などに応じて、外部記憶装置７４に格納してもよい。これらのデータベースは内部記憶装置７６にインストールされている中央ＡＰＰ制御アプリケーション７６１によって読み書きが行われる。
【００５７】
制御部（ＣＰＵ）７２が内部記憶装置７６に保存された中央ＡＰＰ制御アプリケーション７６１にアクセスすることで、中央ＡＰＰ制御サーバ７は中央アプリケーション制御処理を実行する。
【００５８】
図７は中央ＡＰＰ制御サーバ７の内部記憶装置７６に存在する各種のデータベースの構造を表す。拠点リソースＤＢ７６４は監視センタ６の計算機資源の利用状況を管理するデータベースであり、ＡＰＰ制御サーバ３の拠点リソースＤＢ３６５と同様の構造を持つ。
【００５９】
ＡＰＰ接続情報ＤＢ７６５は全ての監視対象拠点１のアプリケーション利用状況を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子、監視対象拠点１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。
【００６０】
ロボット接続情報ＤＢ７６６は図１の監視対象拠点２（１−２）のように、ＡＰＰ制御サーバ３の存在しない監視対象拠点のロボット２１のアプリケーション利用状況を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子、ロボット識別子、ロボット２１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。
【００６１】
図８は運用監視サーバ８の装置構造を示す。運用監視サーバ８はバス８８に接続された制御部（ＣＰＵ）８２、メモリなどの内部記憶装置８６、ハードディスクなどの外部記憶装置８４、及びネットワークインターフェース８０を具備し、ネットワークインターフェース８０、拠点内ＬＡＮ９および拠点間ネットワーク５を介して通信を行う。
【００６２】
内部記憶装置８６には、システム内の全てのロボット２１、ＡＰＰ制御サーバ３の運用監視を統合して行う運用監視アプリケーション８６１を含む。
【００６３】
内部記憶装置８６はさらに、運用監視制御サーバ８はさらに、監視対象拠点（１−１〜１−Ｎ）の基本的な情報を管理する拠点基本情報ＤＢ８６２、監視対象拠点（１−１〜１−Ｎ）の計算機資源の利用状況を管理する拠点リソースＤＢ８６３、監視対象拠点（１−１〜１−Ｎ）の種々の状態を管理する拠点状態ＤＢ８６４、アプリケーションの利用状況に応じてアプリケーションの稼働場所を制御するための条件を管理するアプリケーション情報ＤＢ８６５、システム内のロボット（２１−１〜２１−Ｎ）のアプリケーション利用状況を管理するロボット接続情報ＤＢ８６６、システム内のロボット（２１−１〜２１−Ｎ）の状態を管理するロボット状態ＤＢ８６７、システム内のロボット（２１−１〜２１−Ｎ）のリソース利用状況を管理するロボットリソースＤＢ８６８を備える。
【００６４】
これらの各データベースは、システムの規模、運用監視サーバ８の処理性能などに応じて、外部記憶装置８４に格納してもよい。これらのデータベースは内部記憶装置８６にインストールされている運用監視アプリケーション８６１によって読み書きが行われる。
【００６５】
制御部（ＣＰＵ）８２が内部記憶装置８６に保存された運用監視アプリケーション８６１にアクセスすることで、運用監視サーバ８はシステムの統合管理を実行する。
【００６６】
運用監視サーバ８の内部記憶装置８６に含まれるデータベースのうち、アプリケーション情報ＤＢ８６５以外のデータベースは、ロボット２１、あるいは監視対象拠点１の情報を一元管理するためのデータベースであり、データ構造が一致する同名のデータベースが他のサーバに存在する。
【００６７】
それぞれのデータベースの対応関係は以下の通りである。
・拠点基本情報ＤＢ８６２：ＡＰＰ制御サーバ３の拠点基本情報ＤＢ３６４
・拠点リソースＤＢ８６３：ＡＰＰ制御サーバ３の拠点リソースＤＢ３６５
・拠点状態ＤＢ８６４：ＡＰＰ制御サーバ３の拠点状態ＤＢ３６６
・ロボット接続情報ＤＢ８６６：ＡＰＰ制御サーバ３のロボット接続情報ＤＢ３６７
・ロボット状態ＤＢ８６７：ＡＰＰ制御サーバ３のロボット状態ＤＢ３６８
・ロボットリソースＤＢ：ＡＰＰ制御サーバ３のロボットリソースＤＢ３６９
これらのデータベースの構造に関する説明は割愛し、ここでは図９を用いてアプリケーション情報ＤＢ８６５について説明する。
【００６８】
アプリケーション情報ＤＢ８６５はアプリケーションの実行環境を管理するデータベースである。
【００６９】
本実施例におけるＡＰＰ制御サーバの変更とは、アプリケーションの実行場所をある装置（ロボットまたはサーバ）から他の装置（ロボットまたはサーバ）に変更する処理を指す。具体的には、アプリケーションプログラムを移動しても良いし、複数のサーバの各々が同じ機能を提供するアプリケーションプログラムを格納しておき、アプリケーションプログラムを移動せずに、実行する装置を切り替えても良い。
【００７０】
変更のパターンは下記６通りが存在する
（１）ロボット２１からＡＰＰ制御サーバ３へ変更
（２）ＡＰＰ制御サーバ３からロボット２１へ変更
（３）ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へ変更
（４）中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ変更
（５）ロボット２１から中央ＡＰＰ制御サーバ７へ変更
（６）中央ＡＰＰ制御サーバ７からロボット２１へ変更
上記のサービス要求処理装置として機能する制御サーバの変更規則を管理するデータベースがアプリケーション情報ＤＢ８６５である。アプリケーション情報ＤＢ８６５は変更条件を一意に特定する条件識別子、実行する装置の変更対象となるアプリケーションの識別子、変更種別、変更条件を含む。
【００７１】
変更種別は固定か変更可の２つの値を取り、固定の場合はサービス要求処理装置として機能する制御サーバの変更は適用できない。変更可の場合、変更条件によって変更要否の判定がなされる。変更条件は変更方向、判定条件数と具体的な判定条件を含む。判定条件は１つの条件識別子に対して複数指定することが可能である。変更判定の詳細については後述する。変更方向は上記６パターンのいずれかに該当する。
【００７２】
続いて、本実施例における機器運用監視システムの全体の動作について説明する。
【００７３】
まず図１０の時系列図を用いて、ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更する制御の流れについて説明する。
【００７４】
ロボット２１の計算機資源が限られている場合、多くのアプリケーションはロボット２１の外部で動作する。ロボット２１から見た外部はＡＰＰ制御サーバ３もしくは中央ＡＰＰ制御サーバ７であるため、サービス要求処理装置として機能する制御サーバの変更は、この両者間で発生するケースが多い。
【００７５】
サービス要求処理装置として機能する制御サーバの変更処理は運用監視サーバ８によって制御されるため、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は運用監視サーバ８に制御に必要な情報を送信する。
【００７６】
例えば、一つ以上の監視対象拠点にあるＡＰＰ制御サーバ３が自拠点のリソースに関する情報を収集し（Ｓ１−０１）、拠点リソースＤＢ３６５を更新して収集した情報を拠点リソース情報として運用監視サーバ８に送信する（Ｓ１−０４）。送信される拠点リソース情報の内容は、拠点リソースＤＢ３６５の対応する項目の内容と一致する。
【００７７】
拠点リソース情報を送信した後、各ＡＰＰ制御サーバ３は自拠点の拠点状態に関する情報の収集を行い（Ｓ１−０７）、拠点状態ＤＢ３６６を更新して、収集した情報を拠点状態情報として運用監視サーバ８に送信する（Ｓ１−１０）。
【００７８】
なお、各ＡＰＰ制御サーバ３によるＳ１−０１〜Ｓ１−１０の実行順序は上記以外でも良い。
【００７９】
中央ＡＰＰ制御サーバ７も同様にリソース情報を収集して（Ｓ１−１３）拠点リソースＤＢ７６４を更新し、拠点リソース情報を運用監視サーバ８に送信する（Ｓ１−１６）。
【００８０】
なお、各ＡＰＰ制御サーバ３による情報送信と、中央ＡＰＰ制御サーバ７による情報送信の実行順序と、は上記以外でも良い。
【００８１】
運用監視サーバ８はＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から収集した拠点リソース情報、拠点状態情報に基づき、サービス要求処理装置の変更が必要なアプリケーションがあるか否か判定する（Ｓ１−１９）。サービス要求処理装置の変更要否判定アルゴリズムについては後述する。
【００８２】
ここで、ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へサービス要求処理装置の変更が必要なアプリケーションが存在すれば、運用監視サーバ８は当該アプリケーションが稼働しているＡＰＰ制御サーバ３を特定し、当該ＡＰＰ制御サーバ３と同じ監視対象拠点１にあるロボット２１に対して、サーバ変更通知メッセージ（以下、サーバ変更通知）を送信し、変更後のサービス要求処理装置を登録させる（Ｓ１−２２）。
【００８３】
サーバ変更通知はアプリケーション識別子とアプリケーションの接続先情報とを含む。アプリケーションの接続先には中央ＡＰＰ制御サーバ７が指定される。
【００８４】
サービス要求処理装置の変更後にＡＰＰ制御サーバ３のリソースが浪費されるのを防ぐため、運用監視サーバ８はＡＰＰ制御サーバ３にＡＰＰ停止通知を送信する（Ｓ１−２５）。ＡＰＰ停止通知を受信したＡＰＰ制御サーバ３は、対象となるアプリケーションの停止処理を行う（Ｓ１−２８）。
【００８５】
サービス要求処理装置の変更通知を受信したロボット２１は、指定されたアプリケーションを利用するときはサービス要求メッセージを中央ＡＰＰ制御サーバ７に送信する（Ｓ１−３１）。中央ＡＰＰ制御サーバ７は、上記アプリケーションを実行して、上記サービス要求を処理して、サービス処理結果をロボット２１に返送する（Ｓ１−３４）。
【００８６】
次に図１１の時系列図を用いて、アプリケーションを実行する装置を中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ変更する制御の流れについて説明する。
【００８７】
サービス要求処理装置の変更処理は運用監視サーバ８によって制御されるため、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は運用監視サーバ８に制御に必要な情報を送信する。情報収集、送信処理に関しては、図１１のステップＳ２−０１〜Ｓ２−１６の処理は図１０のステップＳ１−０１〜Ｓ１−１６と同一であるため、説明を割愛する。
【００８８】
ステップＳ２−１９において、運用監視サーバ８は実行する装置の変更が必要なアプリケーションがあるか否か判定する。ここで、装置の変更が必要なアプリケーションが存在し、変更方向が中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３であったとすると、運用監視サーバ８はサービス要求処理装置の変更を準備するために、変更先のＡＰＰ制御サーバ３にＡＰＰ起動通知を送信する（Ｓ２−２２）。
【００８９】
ＡＰＰ起動通知を受信したＡＰＰ制御サーバ３は、指定されたアプリケーションを起動する（Ｓ２−２５）。運用監視サーバ８はＡＰＰ起動通知の送信後に、サービス要求処理装置の変更対象のＡＰＰ制御サーバ３に関連したロボット２１に対し、サーバ変更通知を送信する（Ｓ２−２８）。
【００９０】
サーバ変更通知には、実行する装置が変更されるＡＰＰ識別子と接続先としてＡＰＰ制御サーバ３が指定される。サーバ変更通知を受信した後は、アプリケーション処理はロボット２１とＡＰＰ制御サーバ３の間で行われる（Ｓ２−３１、Ｓ２−３４）。
【００９１】
アプリケーションの中にはロボット２１で実行されるものがあるため、サービス要求処理装置の変更はロボット２１とＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７の間でも発生しうる。
【００９２】
図１２の時系列図はアプリケーションの実行装置をロボット２１からＡＰＰ制御サーバ３へ変更する場合の処理を示している。この場合、運用監視サーバ８はロボット２１のリソース使用状況および状態を把握する必要がある。
【００９３】
そこで、ロボット２１はリソース情報、状態情報を収集し（Ｓ３−０１、Ｓ３−１０）、これらをＡＰＰ制御サーバ３へ送信する（Ｓ３−０４、Ｓ３−１３）ロボットリソース情報の内容はロボットリソースＤＢ３６９と一致する。また、ロボット状態情報の内容はロボット状態ＤＢ３６８と一致する。
【００９４】
ロボット２１からロボットリソース情報、ロボット状態情報を受信したＡＰＰ制御サーバ３は、これらの情報を運用監視サーバ８に送信する（Ｓ３−０７、Ｓ３−１６）。ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は、図１０のステップＳ１−０１〜Ｓ１−１６と同様の方法で、拠点リソース情報、拠点状態情報を運用監視サーバ８に送信する（Ｓ３−１９〜Ｓ３−３４）。
【００９５】
運用監視サーバ８は収集した各ロボットリソース情報、ロボット状態情報、拠点リソース情報、拠点状態情報に基づき、サービス要求処理装置の変更要否を判定する（Ｓ３−３７）。このケースではアプリケーションを実行する装置をロボット２１からＡＰＰ制御サーバ３へ変更するため、運用監視サーバ８はＡＰＰ制御サーバ３に対し、新たな実行対象となるアプリケーションの起動通知を送信する（Ｓ３−４０）。
【００９６】
ＡＰＰ起動通知は起動対象のアプリケーション識別子を指定する。ＡＰＰ制御サーバ３は指定されたアプリケーションを起動する（Ｓ３−４３）。
【００９７】
その後、運用監視サーバ８はロボット２１に対してサーバ変更通知を送信し（Ｓ３−４６）、対象のアプリケーションがＡＰＰ制御サーバ３で実行中であることをロボット２１に通知する。
【００９８】
ロボット２１は対象のアプリケーションの接続先がＡＰＰ制御サーバ３になるようＡＰＰ接続先情報ＤＢ２６６を更新し、ロボット２１で稼働中の当該アプリケーションを停止する（Ｓ３−４９）。
【００９９】
以降、当該アプリケーションの処理はロボット２１とＡＰＰ制御サーバ３の間でメッセージの送受信を通じて行われる（Ｓ３−５２、Ｓ３−５５）。
【０１００】
ロボット２１を含めたサービス要求処理装置の変更については、図１２のケースのほかに、下記の３つのケースが考えられる。
（１）ＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更
（２）ロボット２１から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更
（３）中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更
図１３はＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更するケースの時系列図である。ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ４−０１〜Ｓ４−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。
【０１０１】
ステップＳ４−３７において、運用監視サーバ８はＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更すると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ４−４０）。
【０１０２】
サーバ変更通知を受信したロボット２１は、サービス要求処理装置の変更対象が自身であることを知り、アプリケーション識別子で指定されたアプリケーションを起動する（Ｓ４−４３）。
【０１０３】
運用監視サーバ８はＡＰＰ制御サーバ３にＡＰＰ停止通知を送信し（Ｓ４−４６）、ＡＰＰ制御サーバ３は指定されたアプリケーションを停止させる（Ｓ４−４９）。
【０１０４】
図１４はロボット２１から中央ＡＰＰ制御サーバ７にサービス要求処理装置を変更させるケースの時系列図である。
【０１０５】
本来、ロボット２１の負荷軽減を目的としたときのサービス要求処理装置の変更先は、ロボット２１と同じ監視対象拠点１に設置したＡＰＰ制御サーバ３であることが望ましいが、ＡＰＰ制御サーバ３の処理負荷がきわめて高い場合などに、中央ＡＰＰ制御サーバ７への変更処理を検討する。
【０１０６】
ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ５−０１〜Ｓ５−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。
【０１０７】
ステップＳ５−３７において、運用監視サーバ８はロボット２１から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更させると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ５−４０）。
【０１０８】
サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先が中央ＡＰＰ制御サーバ７となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを停止させる（Ｓ５−４３）。
【０１０９】
以降、当該アプリケーションの処理はロボット２１と中央ＡＰＰ制御サーバ７の間でメッセージの送受信を通じて行われる（Ｓ５−４６、Ｓ５−４９）。
【０１１０】
図１５は中央ＡＰＰ制御サーバ７からロボット２１にサービス要求処理装置を変更させるケースの時系列図である。
【０１１１】
図１４の状態からロボット２１の処理負荷が下がり、元の状態に復旧するケースが該当する。ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ６−０１〜Ｓ６−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。
【０１１２】
ステップＳ６−３７において、運用監視サーバ８は中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更すると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ５−４０）。
【０１１３】
サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先がロボット２１自身となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを起動する（Ｓ６−４３）。当該アプリケーションの処理はロボット２１が行う。
【０１１４】
拠点によっては図１の監視対象拠点２（１−２）のように、ＡＰＰ制御サーバ３がないケースがある。この場合、ロボット２１は中央ＡＰＰ制御サーバ７を通じて運用監視サーバ８へ各種の情報を送信する。図１６はこのような状況において、アプリケーションを実行する装置をロボット２１から中央ＡＰＰ制御サーバ７へ変更する場合の時系列図である。
【０１１５】
ロボット２１はリソース情報、状態情報を収集し（Ｓ７−０１、Ｓ７−０７）、これらを中央ＡＰＰ制御サーバ７へ送信する（Ｓ７−０４、Ｓ７−１０）ロボットリソース情報の内容はロボットリソースＤＢ３６９と一致する。また、ロボット状態情報の内容はロボット状態ＤＢ３６８と一致する。
【０１１６】
ロボット２１からロボットリソース情報、ロボット状態情報を受信した中央ＡＰＰ制御サーバ７は、これらの情報を運用監視サーバ８に送信する（Ｓ７−０５、Ｓ７−１１）。中央ＡＰＰ制御サーバ７は、図１０のステップＳ１−１３、Ｓ１−１６と同様の方法で、拠点リソース情報を運用監視サーバ８に送信する（Ｓ７−１３〜Ｓ７−１６）。
【０１１７】
運用監視サーバ８は収集した各ロボットリソース情報、ロボット状態情報、拠点リソース情報に基づき、サービス要求処理装置の変更要否を判定する（Ｓ７−１９）。このケースではアプリケーションを稼働させる装置を、ロボット２１から中央ＡＰＰ制御サーバ７へ変更するため、運用監視サーバ８はロボット２１に対してサーバ変更通知を送信し（Ｓ７−２２）、対象のアプリケーションが中央ＡＰＰ制御サーバ７で実行中であることをロボット２１に通知する。
【０１１８】
ロボット２１は対象のアプリケーションの接続先が中央ＡＰＰ制御サーバ７になるようＡＰＰ接続先情報ＤＢ２６６を更新し、ロボット２１で稼働中の当該アプリケーションを停止する（Ｓ７−２５）。
【０１１９】
以降、当該アプリケーションの処理はロボット２１と中央ＡＰＰ制御サーバ７の間でメッセージの送受信を通じて行われる（Ｓ７−２８、Ｓ７−３１）。
【０１２０】
図１７は図１６とは逆のケースで、アプリケーションの実行装置を中央ＡＰＰ制御サーバ７からロボット２１へ変更する場合の時系列図である。ロボット２１、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ８−０１〜Ｓ８−１６）は図１６のステップＳ７−０１〜Ｓ７−１６と同様であるため、説明を割愛する。
【０１２１】
ステップＳ８−１９において、運用監視サーバ８は中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更させると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ８−２２）。サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先がロボット２１となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを起動する（Ｓ８−２５）。
【０１２２】
監視対象拠点１に複数台のロボット２１が設置されている場合、サービス要求処理装置の変更は各ロボット２１に対して行う。
【０１２３】
図１８は監視対象拠点１に２台のロボット１（２１−１）、ロボット２（２１−２）が設置されている場合のサービス要求処理装置変更の判定処理を表す時系列図である。ここでは、ロボット１（２１−１）、ロボット２（２１−２）が最初は同じ場所にあったが、ロボット１（２１−１）が場所を移動した（Ｓ９−０１）ものと想定する。
【０１２４】
場所が移動すると、ロボット２１がシステム内で担う役割が変化する。例えば銀行を例にとると、金庫室ではセキュリティ監視が主な業務となるのに対し、顧客応対フロアでは種々の応対業務を行う必要がある。
【０１２５】
ロボット２１が拠点に複数存在する場合、各ロボット２１はロボットリソース情報、ロボット状態情報の収集、通知をそれぞれ行う（Ｓ９−０４〜Ｓ９−２６）。
【０１２６】
ＡＰＰ制御サーバ３がロボットリソース情報およびロボット状態情報を運用監視サーバ８に送信する場合（Ｓ９−１４、Ｓ９−２６）は、監視対象拠点内のロボット（２１−１〜２１−Ｎ）の情報を一括して送信する。
【０１２７】
ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は、これまでの処理と同様の方法で拠点リソース情報、拠点状態情報の収集を行い、運用監視サーバ８に送信する（Ｓ９−２８〜Ｓ９−４３）。
【０１２８】
サービス要求処理装置の変更判定（Ｓ９−４６）において、ロボット１（２１−１）のあるアプリケーションをＡＰＰ制御サーバ３で稼働させる必要があると判断したとする。
【０１２９】
運用監視サーバ８はＡＰＰ制御サーバ３に対し、実行させる装置の変更対象となるアプリケーションの起動通知を送信する（Ｓ９−４９）。ＡＰＰ起動通知は起動対象のアプリケーション識別子を指定する。ＡＰＰ制御サーバ３は指定されたアプリケーションを起動する（Ｓ３−５２）。
【０１３０】
その後、運用監視サーバ８はロボット１（２１−１）に対してサーバ変更通知を送信し（Ｓ９−５５）、対象のアプリケーションがＡＰＰ制御サーバ３で実行中であることをロボット１（２１−１）に通知する。ロボット１（２１−１）は対象のアプリケーションの接続先がＡＰＰ制御サーバ３になるようＡＰＰ接続先情報ＤＢ２６６を更新する。
【０１３１】
以降、当該アプリケーションの処理はロボット１（２１−１）とＡＰＰ制御サーバ３の間でメッセージの送受信を通じて行われる（Ｓ９−５８、Ｓ９−６１）。
【０１３２】
次に、図１９のフローチャートを用いて、運用監視サーバ８におけるサービス要求処理装置の変更判定方法について説明する。
【０１３３】
サービス要求処理装置の変更判定は、運用監視サーバ８がロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を受信した後に行われる（図１２のステップＳ３−３７等）。起動契機としては、上記の各種情報の受信状況をチェックするほか、周期的に判定処理を起動する方法が考えられる。
【０１３４】
サービス要求処理装置変更の判定処理は、運用監視サーバ８のアプリケーション情報ＤＢ８６５で管理されているすべての条件識別子に対して行う（Ｆ１−０４）。この処理は、アプリケーション情報ＤＢ８６５からある１つの条件識別子に対応したレコードを取得し、当該レコードに対する判定処理を実行することで実現できる（Ｆ１−０７）。
【０１３５】
ここで、当該レコードの判定条件を用いてサービス要求処理装置変更の判定処理を行う（Ｆ１−１０）、全ての判定条件が満たされている場合は、サービス要求処理装置の変更処理を実行する（Ｆ１−１３）。そうでない場合は処理ループの先頭に戻り、別の条件識別子に対応したレコードのサービス要求処理装置変更の判定を行う（Ｆ１−０４、Ｆ１−０７）。
【０１３６】
すべての条件識別子に対応したレコードに対して判定処理を完了した（Ｆ１−１６）時点で、サービス要求処理装置変更の要否判定処理は終了する（Ｆ１−１９）。
【０１３７】
サービス要求処理装置変更の判定における判定条件には様々なものが考えられる。
【０１３８】
図２０は判定条件を設定する判定条件編集画面の一例である。判定条件の設定に必要な項目はアプリケーション名、変更種別、変更方向と変更判定条件である。アプリケーション名はアプリケーションを一意に特定できる必要があり、アプリケーション情報ＤＢ８６５のＡＰＰ識別子として使用される。
【０１３９】
変更種別は変更可、もしくは固定の２つから選択する。変更可の場合は、変更の向きを選択して設定する。固定の場合はアプリケーションの配置拠点を設定する。固定を選択した場合、当該アプリケーションは拠点基本情報ＤＢ３６４の固定ＡＰＰリストに登録される。
【０１４０】
変更判定条件はサービス要求処理装置の変更条件を決定する項目であり、必要に応じて複数個登録することが可能である。変更判定条件に設定可能な項目としては、ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７のＣＰＵ使用率、消費ネットワーク帯域、ロボット２１の位置、場所の業務などがあげられる。
【０１４１】
判定方法については、数値化可能な条件については以上、以下などの判定を行い、場所や業務内容など、文字列で表現される条件については文字列の内容で判定を行う。
【０１４２】
例えば、銀行での顧客応対業務を例にとると、ロボット２１が顧客応対スペースに移動し、主業務として顧客対応を行わなければならなくなった時点で、ロボット２１のＣＰＵ負荷が１０％と低い状態にあっても、当該サービス要求処理装置をＡＰＰ制御サーバ３へ変更する。
【０１４３】
逆に、ロボット２１が顧客応対スペースから離脱し、顧客対応をする必要が無くなった場合、当該アプリケーションを使用する確率は低下するため、銀行顧客応対業務が万が一発生しても中央ＡＰＰ制御サーバ７で対処して、ＡＰＰ制御サーバ３の処理負荷を低減できる。
【０１４４】
サービス要求処理装置の変更パターンと具体例としては、以下の項目が考えられる。
（１）ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へ
・ある拠点のＡＰＰの利用率が低いため、中央ＡＰＰ制御サーバ７に集約
・時間帯による客層変化、サービス内容変更によるＡＰＰ利用率低下：夜間の顧客応対業務を中央ＡＰＰ制御サーバ７に集約化
（２）中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ
・ある拠点から接続されているＡＰＰの利用率が高い
・時間帯による客層変化、サービス内容変更によるＡＰＰ利用率上昇：ビジネスアワーの通常業務をＡＰＰ制御サーバ３で処理
（３）ロボット２１からＡＰＰ制御サーバ３へ
・同一拠点で複数のロボット２１が同一のアプリケーションを実行：ＡＰＰ制御サーバ３にアプリケーションを集約してロボット２１の処理負荷を下げる
（４）ＡＰＰ制御サーバ３からロボット２１へ
・（３）と逆の事象が発生
（５）ロボット２１から中央ＡＰＰ制御サーバ７へ
・ＡＰＰ制御サーバ３がない拠点において、ロボット２１の処理負荷を可能な範囲で低減する
（６）中央ＡＰＰ制御サーバ７からロボット２１へ
・ロボット２１の位置が特定の業務を提供する場所になった場合、応答時間の短縮を狙ってアプリケーションをロボットで実行する
上述した機器運用監視装置および機器運用監視システムは、多数の拠点に存在する種々の機器を統合管理する運用監視サービスへの適用が見込まれる。
【符号の説明】
【０１４５】
１：監視対象拠点
２１：ロボット
３：ＡＰＰ制御サーバ
４：構内ＬＡＮ
５：ネットワーク
６：監視センタ
７：中央ＡＰＰ制御サーバ
８：運用監視サーバ
【図１】
2018005431.tif 000003
【図２】
2018005431.tif 000004
【図３】
2018005431.tif 000005
【図４】
2018005431.tif 000006
【図５】
2018005431.tif 000007
【図６】
2018005431.tif 000008
【図７】
2018005431.tif 000009
【図８】
2018005431.tif 000010
【図９】
2018005431.tif 000011
【図１０】
2018005431.tif 000012
【図１１】
2018005431.tif 000013
【図１２】
2018005431.tif 000014
【図１３】
2018005431.tif 000015
【図１４】
2018005431.tif 000016
【図１５】
2018005431.tif 000017
【図１６】
2018005431.tif 000018
【図１７】
2018005431.tif 000019
【図１８】
2018005431.tif 000020
【図１９】
2018005431.tif 000021
【図２０】
2018005431.tif 000022