JP6847598B2 - 運用監視サーバおよび運用監視システム - Google Patents

Description

開示される主題は、移動可能な機器の運用監視技術に関する。

あらゆる機器をインターネットに接続し、種々のサービスを提供するＩｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）技術が普及しつつある。ＩｏＴに対応する機器（ＩｏＴ機器）にはセンサーのように定型処理のみを行う低機能端末から、ロボットのように提供する機能をソフトウェアによって変更できる高機能端末までさまざまな種類の機器が存在する。

インターネットに接続される機器の数が急速に増加する中、これらの機器を用いて何らかの機能を実現する場合、高品質なサービスを実現するためには、アプリケーションプログラム（以下、アプリケーションまたはＡＰＰと記す）の負荷分散および／または応答時間の削減が一つの課題となる。

この課題を解決するには、どのようにアプリケーションを配備するか、および／または、機器に対して、どのように運用機能と監視機能を提供するかの検討が有効である。

関連する技術として、特許文献１は複数のデータセンタ間でアプリケーションを実行する際の負荷分散技術を開示している。

また、特許文献２はＩＰＴＶシステムにおいて、データセンタとエッジサーバのいずれかにコンテンツを配置して配信する技術を公開している。

特開２０１５―１５３３７０号公報 特表２０１３―５１６８５４号公報

ロボットのように移動が可能な機器に関しては、移動前後の滞在場所および／または、稼働時間帯、などの外的条件（状態情報）によって、求められる機能や提供すべき機能が異なる場合がある。従って、負荷分散および／または応答時間の削減について、これらの外的条件（状態情報）を考慮することは有効であるが、先行技術文献では、状態情報を考慮していない。

すなわち、特許文献１ではアプリケーションを実行する対象はデータセンタのサーバが主体であり、サーバの選択基準としてＣＰＵ負荷、通信帯域などの計算機資源のみを考慮している。

特許文献２が公開するＩＰＴＶシステムでは、分散配置の対象がメディアコンテンツであり、それ以外のアプリケーションをデータセンタ、もしくはエッジサーバに配置してサービスを提供することは開示していない。また、上述した外的条件（状態情報）を考慮していない．
従って、状態情報を考慮することにより高品質なサービスを実現する、様々な機器に対するアプリケーションの配備方法、および／または、機器に対する運用機能と監視機能の提供方法が求められている。

一例として開示されるのは、監視対象機器と、監視対象機器からのサービス要求を処理する機能を備えるサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点がネットワークで接続され、拠点のいずれかに設置されている運用監視サーバが監視対象機器の運用を監視する運用監視システムと、運用監視サーバである。

運用監視システムにおいて、監視対象機器は自身の状態情報を、および／または、監視対象機器が設置されている拠点にある第一のサービス要求処理装置は当該拠点の状態情報を、運用監視サーバへ送信し、運用監視サーバは、送信された状態情報を取得し、取得した状態情報に基づき、監視対象機器からのサービス要求を処理する機能を備える複数のサービス要求処理装置のいずれかを選択する、ことを特徴とする。

さらに、監視対象機器と、第一のサービス要求処理装置と、のいずれか一方または両方は、自身のリソース情報を、運用監視サーバへ送信し、運用監視サーバは、送信されたリソース情報を取得し、状態情報と、取得したリソース情報と、に基づき、監視対象機器用のサービス要求処理装置を選択する、ように上記運用監視システムを構成してもよい。

さらに、運用監視サーバは、選択したサービス要求処理装置が、監視対象機器に登録されている現用のサービス要求処理装置とは異なる場合、監視対象機器へ、サービス要求処理装置の変更を通知する、ように上記運用監視システムを構成してもよい。

開示される機器運用監視装置および機器運用監視システムは、高品質なサービスを提供することを可能にする。

一実施形態の機器運用監視システムのブロック図 ロボットの構造を例示するブロック図 ロボットが管理するデータの構造を例示するブロック図 ＡＰＰ制御サーバの構造を例示するブロック図 ＡＰＰ制御サーバが管理するデータの構造を例示するブロック図 中央ＡＰＰ制御サーバの構造を例示するブロック図 中央ＡＰＰ制御サーバが管理するデータの構造を例示するブロック図 運用監視サーバの構造を例示するブロック図 運用監視サーバが管理するデータの構造を例示するブロック図 実施形態のアプリケーション制御処理の一例を説明する時系列図１ 実施形態のアプリケーション制御処理の一例を説明する時系列図２ 実施形態のアプリケーション制御処理の一例を説明する時系列図３ 実施形態のアプリケーション制御処理の一例を説明する時系列図４ 実施形態のアプリケーション制御処理の一例を説明する時系列図５ 実施形態のアプリケーション制御処理の一例を説明する時系列図６ 実施形態のアプリケーション制御処理の一例を説明する時系列図７ 実施形態のアプリケーション制御処理の一例を説明する時系列図８ 実施形態のアプリケーション制御処理の一例を説明する時系列図９ サービス要求処理装置変更の判定方法の一例を説明するフローチャート サービス要求処理装置変更の判定条件の編集画面の一例

図１は本実施例における運用監視システムの構成の一例である。

運用監視システムは機器を設置した拠点を監視対象拠点（１−１〜１−Ｎ）とし、監視対象拠点に設置した監視対象機器を監視する。設置された機器は種々のアプリケーションを通じて利用者へサービスを提供する。

監視対象機器には様々な形態があるが、ここでは、ロボットと呼ぶ２１−１〜２１−Ｎの「自律移動が可能な情報処理装置（以降ロボット２１と総称）を対象として説明する。

ロボット２１は制御端末を含むため、ロボット２１自身の機構制御の他に、サーバと同様にアプリケーションを実行し利用者へサービスを提供することが可能だが、ロボット２１の制御端末はサーバのようにアプリケーションの実行に特化しているわけではない。このため、アプリケーションの実行に利用可能なＣＰＵ、内部記憶（メモリ）や外部記憶（ストレージ）などの計算機資源はサーバほど潤沢ではない。

このため、アプリケーションの実行を外部に設置したサーバに依存する場合もある。この場合、外部に設置したサーバにサービス要求を行い、サーバからサービス処理結果を受け取り利用者にサービスを提供する。サーバの設置個所は、ロボット２１と同じ監視対象拠点に設置する方法と、データセンタまたは監視センタに設置する方法の２通りがある。

監視対象拠点（１−１〜１−Ｎ）に設置したサーバをアプリケーション制御サーバ（３−１〜３−Ｎ、以下ＡＰＰ制御サーバ３と記載）、監視拠点である監視センタ６に設置したサーバを中央アプリケーション制御サーバ７（以下中央ＡＰＰ制御サーバ７と記載）と呼ぶ。これらのサーバは、サービス要求処理装置として機能する。

各監視対象拠点１において、ロボット２１とＡＰＰ制御サーバ３は、拠点内ＬＡＮである構内ＬＡＮ（４−１〜４−Ｎ）で接続され、監視センタ６において、運用監視サーバ８と中央ＡＰＰ制御サーバ７は拠点内ＬＡＮ９で接続される。ロボット２１、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は、構内ＬＡＮ４または拠点内ＬＡＮ９と、拠点間ネットワーク５と、を通じて相互に接続される。

各拠点に設置されたロボット２１、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は、機器運用監視システム内の機器、サーバを統括管理する運用監視サーバ８によって制御される。ロボット２１、ＡＰＰ制御サーバ３および中央ＡＰＰ制御サーバ７は、運用監視に必要な種々の情報を運用監視サーバ８に送信する。

次に、システムを構成する各装置について詳しく説明する。

図２はロボット２１の装置構造を示す。ロボット２１は、ロボット制御端末２と、制御対象のカメラ２９１、モータ２９２、マイク２９３、スピーカー２９４、アクチュエータ２９５、各種センサ２９６を含んで構成され、ロボット制御端末２と制御対象の各デバイスは、ロボット制御端末２の外部入出力インターフェース２９を通じて接続される。

ロボット制御端末２はバス２８に接続された制御部（ＣＰＵ）２２、メモリなどの内部記憶装置２６、ハードディスクなどの外部記憶装置２４、及びネットワークインターフェース２０を具備し、ネットワークインターフェース２０、構内ＬＡＮ４および拠点間ネットワーク５を介して通信を行う。

内部記憶装置２６には、ロボット２１の機構、姿勢、移動等を制御するロボット制御アプリケーション２６１を含む。内部記憶装置２６はさらに、ロボット２１自身の制御以外の機能、例えばセンサーによる情報収集や位置推定などの各種アプリケーション（２６２、２６３）を備える。各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。

これらのアプリケーションに加えて、ロボット２１はロボットの状態に関する情報を管理するロボット状態データベース（ＤＢ）２６４、ロボット２１のリソース使用状況を管理するロボットリソースＤＢ２６５、ロボット２１が利用している各種アプリケーションの接続先を管理するＡＰＰ接続先情報ＤＢ２６６を備える。

これらの各データベースは、システムの規模、ロボット制御端末２１の処理性能などに応じて、外部記憶装置２４に格納してもよい。これらのデータベースは内部記憶装置２６にインストールされているロボット制御アプリケーション２６１によって読み書きが行われる。

制御部（ＣＰＵ）２２が内部記憶装置２６に保存されたロボット制御アプリケーション２６１にアクセスすることで、ロボット２１の制御機能が実現される。

図３はロボット２１の内部記憶装置２６に存在する各種のデータベースの構造を表す。ロボット状態ＤＢ２６４はロボット２１自身の状態に関する情報を管理するデータベースであり、ロボット２１が設置されている監視対象拠点１の拠点マップ、場所名、Ｘ座標、Ｙ座標を含む。

拠点マップは設置拠点の形状、広さなど、拠点の物理的構造に関する情報であり、ロボット２１の設置時に情報の初期化が行われる。ロボット２１には自己位置推定機能があり、レーザーレンジファインダ等を用いて周囲の壁と自身の距離を測定することで、監視対象拠点１内の自身の位置（Ｘ座標、Ｙ座標）を判定できる。

拠点マップは拠点の物理的構造の他、場所に関する情報も含む。例えば座標を用いて拠点内の部屋に関する情報を定義することが可能である。

ロボットリソースＤＢ２６５はロボット制御端末２の計算機資源の利用状況を管理するデータベースであり、ロボット２１が設置されている監視対象拠点１の拠点識別子、当該拠点のネットワーク（ＮＷ）帯域、ネットワーク帯域利用率と、ロボット制御端末上で稼働しているアプリケーションのリストである稼働中ＡＰＰリストを含む。稼働中ＡＰＰリストの一項目は、システム内でアプリケーションを一意に特定するＡＰＰ識別子、当該アプリケーションのＣＰＵ使用率と消費ＮＷ帯域を含む。

ＡＰＰ接続先情報ＤＢ２６６は、ロボット２１が利用するアプリケーションのうち外部のサーバで動作しているアプリケーションの接続先を管理するデータベースであり、ＡＰＰ識別子と接続先を含む。例えば、音声認識処理が拠点内のＡＰＰ制御サーバ３で動作している場合、音声認識処理の接続先はＡＰＰ制御サーバ３となる。

図４はＡＰＰ制御サーバ３の装置構造を示す。ＡＰＰ制御サーバ３はバス３８に接続された制御部（ＣＰＵ）３２、メモリなどの内部記憶装置３６、ハードディスクなどの外部記憶装置３４、及びネットワークインターフェース３０を具備し、ネットワークインターフェース３０、構内ＬＡＮ４および拠点間ネットワーク５を介して通信を行う。

内部記憶装置３６には、アプリケーションの実行、起動、停止処理を行うＡＰＰ制御アプリケーション３６１を含む。内部記憶装置３６はさらに、ロボット２１に種々の機能を提供するための各種アプリケーション（３６２、３６３）を備える。

各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。アプリケーションは外部記憶装置３４にインストールされ、制御部（ＣＰＵ）３２によって必要時に起動される。

これらのアプリケーションに加えて、ＡＰＰ制御サーバ３は拠点の基本的な情報を管理する拠点基本情報ＤＢ３６４、拠点の計算機資源の利用状況を管理する拠点リソースＤＢ３６５、拠点の種々の状態を管理する拠点状態ＤＢ３６６、拠点内の全てのロボット２１のＡＰＰ接続状況を管理するロボット接続情報ＤＢ３６７、拠点内の全てのロボット２１の状態を管理するロボット状態ＤＢ３６８、拠点内の全てのロボット２１のリソース利用状況を管理するロボットリソースＤＢ３６９を備える。

これらの各データベースは、システムの規模、ＡＰＰ制御サーバ３の処理性能などに応じて、外部記憶装置３４に格納してもよい。これらのデータベースは内部記憶装置３６に読み込まれ、実行されているＡＰＰ制御アプリケーション２６１によって読み書きが行われる。

制御部（ＣＰＵ）３２が内部記憶装置３６に保存されたＡＰＰ制御アプリケーション３６１にアクセスすることで、ＡＰＰ制御サーバ３はアプリケーション制御処理を実行する。

図５はＡＰＰ制御サーバ３の内部記憶装置３６に存在する各種のデータベースの構造を表す。拠点基本情報ＤＢ３６４は監視対象拠点１の基本的な情報を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子と、固定ＡＰＰリストを含む。

固定ＡＰＰリストとはアプリケーションのうち必ず当該管理拠点１に設置されたＡＰＰ制御サーバ３で実行しなければならない、逆に言えばロボット２１や中央ＡＰＰ制御サーバ７で実行してはならないアプリケーションの識別子のリストである。

例えば、雑音に強い音声認識アプリケーションは、拠点の物理的構造に影響を受けるため、拠点内に実行環境がある方が望ましい。拠点基本情報ＤＢはこのようなアプリケーションのリストを保持する。

拠点リソースＤＢ３６５はＡＰＰ制御サーバ３の計算機資源の利用状況を管理するデータベースであり、ＡＰＰ制御サーバ３が設置されている監視対象拠点１の拠点識別子、当該拠点のネットワーク（ＮＷ）帯域、ネットワーク帯域利用率と、ＡＰＰ制御サーバ３上で稼働しているアプリケーションのリストである稼働中ＡＰＰリストを含む。稼働中ＡＰＰリストの一項目は、システム内でアプリケーションを一意に特定するＡＰＰ識別子、当該アプリケーションのＣＰＵ使用率と消費ＮＷ帯域を含む。

拠点状態ＤＢ３６６は拠点の種々の状態を管理するデータベースであり、拠点識別子、拠点マップ、拠点業務スケジュールを含む。拠点識別子と拠点マップは監視対象拠点内の全てのロボット２１と共有される。拠点業務スケジュールは監視対象拠点において実行される業務のスケジュールに関する情報を管理し、場所名、業務の開始時刻、終了時刻と業務内容を含む。

例えば、監視対象拠点１が銀行の場合、応対フロアでは、銀行の営業時間では預金の預け入れ、融資の相談などの通常の銀行業務が行われるが、銀行の営業時間外では応対フロアは不審人物の監視と検出が主な業務となるなど、時間帯によって提供業務が異なる。

ロボット接続情報ＤＢ３６７は監視対象拠点１内のロボット２１のアプリケーション利用状況を管理するデータベースであり、システム内でロボット２１を一意に特定するロボット識別子、ロボット２１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。

ロボット状態ＤＢ３６８は同一拠点に設置されているすべてのロボット２１の状態を管理するデータベースであり、基本的な構造はロボット２１のロボット状態ＤＢ２６４と同様である。

複数のロボット２１の状態を管理するために、ロボット２１のロボット状態ＤＢ２６４に加えてロボット識別子を含む。

ロボットリソースＤＢ３６９は同一拠点に設置されているすべてのロボット２１の計算機資源の利用状況を管理するデータベースであり、基本的な構造はロボット２１のロボットリソースＤＢ２６５と同様である。複数のロボット２１の状態を管理するために、ロボット２１のロボットリソースＤＢ２６５に加えてロボット識別子を含む。

図６は中央ＡＰＰ制御サーバ７の装置構造を示す。中央ＡＰＰ制御サーバ７はバス７８に接続された制御部（ＣＰＵ）７２、メモリなどの内部記憶装置７６、ハードディスクなどの外部記憶装置７４、及びネットワークインターフェース７０を具備し、ネットワークインターフェース７０、拠点内ＬＡＮ９および拠点間ネットワーク５を介して通信を行う。

内部記憶装置７６には、アプリケーションの実行、起動、停止処理を行う中央ＡＰＰ制御アプリケーション７６１を含む。内部記憶装置７６はさらに、ロボット２１に種々の機能を提供するための各種アプリケーション（７６２、７６３）を備える。各種アプリケーションはロボット２１が必要とする機能に応じて複数起動することが可能である。

アプリケーションは外部記憶装置７４にインストールされ、制御部（ＣＰＵ）７２によってシステムの稼働開始時に起動される。これらのアプリケーションに加えて、中央ＡＰＰ制御サーバ７は監視センタの計算機資源の利用状況を管理する拠点リソースＤＢ７６４、拠点のアプリケーションの利用状況を管理するＡＰＰ接続情報ＤＢ７６５、中央ＡＰＰ制御サーバ７に接続する全てのロボット２１のＡＰＰ接続状況を管理するロボット接続情報ＤＢ７６６を備える。

これらの各データベースは、システムの規模、中央ＡＰＰ制御サーバ７の処理性能などに応じて、外部記憶装置７４に格納してもよい。これらのデータベースは内部記憶装置７６にインストールされている中央ＡＰＰ制御アプリケーション７６１によって読み書きが行われる。

制御部（ＣＰＵ）７２が内部記憶装置７６に保存された中央ＡＰＰ制御アプリケーション７６１にアクセスすることで、中央ＡＰＰ制御サーバ７は中央アプリケーション制御処理を実行する。

図７は中央ＡＰＰ制御サーバ７の内部記憶装置７６に存在する各種のデータベースの構造を表す。拠点リソースＤＢ７６４は監視センタ６の計算機資源の利用状況を管理するデータベースであり、ＡＰＰ制御サーバ３の拠点リソースＤＢ３６５と同様の構造を持つ。

ＡＰＰ接続情報ＤＢ７６５は全ての監視対象拠点１のアプリケーション利用状況を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子、監視対象拠点１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。

ロボット接続情報ＤＢ７６６は図１の監視対象拠点２（１−２）のように、ＡＰＰ制御サーバ３の存在しない監視対象拠点のロボット２１のアプリケーション利用状況を管理するデータベースであり、システム内で監視対象拠点１を一意に特定する拠点識別子、ロボット識別子、ロボット２１が利用中のアプリケーションを識別するＡＰＰ識別子、アプリケーションが消費するネットワーク帯域とＣＰＵ使用率を含む。

図８は運用監視サーバ８の装置構造を示す。運用監視サーバ８はバス８８に接続された制御部（ＣＰＵ）８２、メモリなどの内部記憶装置８６、ハードディスクなどの外部記憶装置８４、及びネットワークインターフェース８０を具備し、ネットワークインターフェース８０、拠点内ＬＡＮ９および拠点間ネットワーク５を介して通信を行う。

内部記憶装置８６には、システム内の全てのロボット２１、ＡＰＰ制御サーバ３の運用監視を統合して行う運用監視アプリケーション８６１を含む。

内部記憶装置８６はさらに、運用監視制御サーバ８はさらに、監視対象拠点（１−１〜１−Ｎ）の基本的な情報を管理する拠点基本情報ＤＢ８６２、監視対象拠点（１−１〜１−Ｎ）の計算機資源の利用状況を管理する拠点リソースＤＢ８６３、監視対象拠点（１−１〜１−Ｎ）の種々の状態を管理する拠点状態ＤＢ８６４、アプリケーションの利用状況に応じてアプリケーションの稼働場所を制御するための条件を管理するアプリケーション情報ＤＢ８６５、システム内のロボット（２１−１〜２１−Ｎ）のアプリケーション利用状況を管理するロボット接続情報ＤＢ８６６、システム内のロボット（２１−１〜２１−Ｎ）の状態を管理するロボット状態ＤＢ８６７、システム内のロボット（２１−１〜２１−Ｎ）のリソース利用状況を管理するロボットリソースＤＢ８６８を備える。

これらの各データベースは、システムの規模、運用監視サーバ８の処理性能などに応じて、外部記憶装置８４に格納してもよい。これらのデータベースは内部記憶装置８６にインストールされている運用監視アプリケーション８６１によって読み書きが行われる。

制御部（ＣＰＵ）８２が内部記憶装置８６に保存された運用監視アプリケーション８６１にアクセスすることで、運用監視サーバ８はシステムの統合管理を実行する。

運用監視サーバ８の内部記憶装置８６に含まれるデータベースのうち、アプリケーション情報ＤＢ８６５以外のデータベースは、ロボット２１、あるいは監視対象拠点１の情報を一元管理するためのデータベースであり、データ構造が一致する同名のデータベースが他のサーバに存在する。

それぞれのデータベースの対応関係は以下の通りである。
・拠点基本情報ＤＢ８６２：ＡＰＰ制御サーバ３の拠点基本情報ＤＢ３６４
・拠点リソースＤＢ８６３：ＡＰＰ制御サーバ３の拠点リソースＤＢ３６５
・拠点状態ＤＢ８６４：ＡＰＰ制御サーバ３の拠点状態ＤＢ３６６
・ロボット接続情報ＤＢ８６６：ＡＰＰ制御サーバ３のロボット接続情報ＤＢ３６７
・ロボット状態ＤＢ８６７：ＡＰＰ制御サーバ３のロボット状態ＤＢ３６８
・ロボットリソースＤＢ：ＡＰＰ制御サーバ３のロボットリソースＤＢ３６９
これらのデータベースの構造に関する説明は割愛し、ここでは図９を用いてアプリケーション情報ＤＢ８６５について説明する。

アプリケーション情報ＤＢ８６５はアプリケーションの実行環境を管理するデータベースである。

本実施例におけるＡＰＰ制御サーバの変更とは、アプリケーションの実行場所をある装置（ロボットまたはサーバ）から他の装置（ロボットまたはサーバ）に変更する処理を指す。具体的には、アプリケーションプログラムを移動しても良いし、複数のサーバの各々が同じ機能を提供するアプリケーションプログラムを格納しておき、アプリケーションプログラムを移動せずに、実行する装置を切り替えても良い。

変更のパターンは下記６通りが存在する
（１）ロボット２１からＡＰＰ制御サーバ３へ変更
（２）ＡＰＰ制御サーバ３からロボット２１へ変更
（３）ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へ変更
（４）中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ変更
（５）ロボット２１から中央ＡＰＰ制御サーバ７へ変更
（６）中央ＡＰＰ制御サーバ７からロボット２１へ変更
上記のサービス要求処理装置として機能する制御サーバの変更規則を管理するデータベースがアプリケーション情報ＤＢ８６５である。アプリケーション情報ＤＢ８６５は変更条件を一意に特定する条件識別子、実行する装置の変更対象となるアプリケーションの識別子、変更種別、変更条件を含む。

変更種別は固定か変更可の２つの値を取り、固定の場合はサービス要求処理装置として機能する制御サーバの変更は適用できない。変更可の場合、変更条件によって変更要否の判定がなされる。変更条件は変更方向、判定条件数と具体的な判定条件を含む。判定条件は１つの条件識別子に対して複数指定することが可能である。変更判定の詳細については後述する。変更方向は上記６パターンのいずれかに該当する。

続いて、本実施例における機器運用監視システムの全体の動作について説明する。

まず図１０の時系列図を用いて、ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更する制御の流れについて説明する。

ロボット２１の計算機資源が限られている場合、多くのアプリケーションはロボット２１の外部で動作する。ロボット２１から見た外部はＡＰＰ制御サーバ３もしくは中央ＡＰＰ制御サーバ７であるため、サービス要求処理装置として機能する制御サーバの変更は、この両者間で発生するケースが多い。

サービス要求処理装置として機能する制御サーバの変更処理は運用監視サーバ８によって制御されるため、ＡＰＰ制御サーバ３と中央ＡＰＰ制御サーバ７は運用監視サーバ８に制御に必要な情報を送信する。

例えば、一つ以上の監視対象拠点にあるＡＰＰ制御サーバ３が自拠点のリソースに関する情報を収集し（Ｓ１−０１）、拠点リソースＤＢ３６５を更新して収集した情報を拠点リソース情報として運用監視サーバ８に送信する（Ｓ１−０４）。送信される拠点リソース情報の内容は、拠点リソースＤＢ３６５の対応する項目の内容と一致する。

拠点リソース情報を送信した後、各ＡＰＰ制御サーバ３は自拠点の拠点状態に関する情報の収集を行い（Ｓ１−０７）、拠点状態ＤＢ３６６を更新して、収集した情報を拠点状態情報として運用監視サーバ８に送信する（Ｓ１−１０）。

なお、各ＡＰＰ制御サーバ３によるＳ１−０１〜Ｓ１−１０の実行順序は上記以外でも良い。

中央ＡＰＰ制御サーバ７も同様にリソース情報を収集して（Ｓ１−１３）拠点リソースＤＢ７６４を更新し、拠点リソース情報を運用監視サーバ８に送信する（Ｓ１−１６）。

なお、各ＡＰＰ制御サーバ３による情報送信と、中央ＡＰＰ制御サーバ７による情報送信の実行順序と、は上記以外でも良い。

運用監視サーバ８はＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から収集した拠点リソース情報、拠点状態情報に基づき、サービス要求処理装置の変更が必要なアプリケーションがあるか否か判定する（Ｓ１−１９）。サービス要求処理装置の変更要否判定アルゴリズムについては後述する。

ここで、ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へサービス要求処理装置の変更が必要なアプリケーションが存在すれば、運用監視サーバ８は当該アプリケーションが稼働しているＡＰＰ制御サーバ３を特定し、当該ＡＰＰ制御サーバ３と同じ監視対象拠点１にあるロボット２１に対して、サーバ変更通知メッセージ（以下、サーバ変更通知）を送信し、変更後のサービス要求処理装置を登録させる（Ｓ１−２２）。

サーバ変更通知はアプリケーション識別子とアプリケーションの接続先情報とを含む。アプリケーションの接続先には中央ＡＰＰ制御サーバ７が指定される。

サービス要求処理装置の変更後にＡＰＰ制御サーバ３のリソースが浪費されるのを防ぐため、運用監視サーバ８はＡＰＰ制御サーバ３にＡＰＰ停止通知を送信する（Ｓ１−２５）。ＡＰＰ停止通知を受信したＡＰＰ制御サーバ３は、対象となるアプリケーションの停止処理を行う（Ｓ１−２８）。

サービス要求処理装置の変更通知を受信したロボット２１は、指定されたアプリケーションを利用するときはサービス要求メッセージを中央ＡＰＰ制御サーバ７に送信する（Ｓ１−３１）。中央ＡＰＰ制御サーバ７は、上記アプリケーションを実行して、上記サービス要求を処理して、サービス処理結果をロボット２１に返送する（Ｓ１−３４）。

次に図１１の時系列図を用いて、アプリケーションを実行する装置を中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ変更する制御の流れについて説明する。

サービス要求処理装置の変更処理は運用監視サーバ８によって制御されるため、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は運用監視サーバ８に制御に必要な情報を送信する。情報収集、送信処理に関しては、図１１のステップＳ２−０１〜Ｓ２−１６の処理は図１０のステップＳ１−０１〜Ｓ１−１６と同一であるため、説明を割愛する。

ステップＳ２−１９において、運用監視サーバ８は実行する装置の変更が必要なアプリケーションがあるか否か判定する。ここで、装置の変更が必要なアプリケーションが存在し、変更方向が中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３であったとすると、運用監視サーバ８はサービス要求処理装置の変更を準備するために、変更先のＡＰＰ制御サーバ３にＡＰＰ起動通知を送信する（Ｓ２−２２）。

ＡＰＰ起動通知を受信したＡＰＰ制御サーバ３は、指定されたアプリケーションを起動する（Ｓ２−２５）。運用監視サーバ８はＡＰＰ起動通知の送信後に、サービス要求処理装置の変更対象のＡＰＰ制御サーバ３に関連したロボット２１に対し、サーバ変更通知を送信する（Ｓ２−２８）。

サーバ変更通知には、実行する装置が変更されるＡＰＰ識別子と接続先としてＡＰＰ制御サーバ３が指定される。サーバ変更通知を受信した後は、アプリケーション処理はロボット２１とＡＰＰ制御サーバ３の間で行われる（Ｓ２−３１、Ｓ２−３４）。

アプリケーションの中にはロボット２１で実行されるものがあるため、サービス要求処理装置の変更はロボット２１とＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７の間でも発生しうる。

図１２の時系列図はアプリケーションの実行装置をロボット２１からＡＰＰ制御サーバ３へ変更する場合の処理を示している。この場合、運用監視サーバ８はロボット２１のリソース使用状況および状態を把握する必要がある。

そこで、ロボット２１はリソース情報、状態情報を収集し（Ｓ３−０１、Ｓ３−１０）、これらをＡＰＰ制御サーバ３へ送信する（Ｓ３−０４、Ｓ３−１３）ロボットリソース情報の内容はロボットリソースＤＢ３６９と一致する。また、ロボット状態情報の内容はロボット状態ＤＢ３６８と一致する。

ロボット２１からロボットリソース情報、ロボット状態情報を受信したＡＰＰ制御サーバ３は、これらの情報を運用監視サーバ８に送信する（Ｓ３−０７、Ｓ３−１６）。ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は、図１０のステップＳ１−０１〜Ｓ１−１６と同様の方法で、拠点リソース情報、拠点状態情報を運用監視サーバ８に送信する（Ｓ３−１９〜Ｓ３−３４）。

運用監視サーバ８は収集した各ロボットリソース情報、ロボット状態情報、拠点リソース情報、拠点状態情報に基づき、サービス要求処理装置の変更要否を判定する（Ｓ３−３７）。このケースではアプリケーションを実行する装置をロボット２１からＡＰＰ制御サーバ３へ変更するため、運用監視サーバ８はＡＰＰ制御サーバ３に対し、新たな実行対象となるアプリケーションの起動通知を送信する（Ｓ３−４０）。

ＡＰＰ起動通知は起動対象のアプリケーション識別子を指定する。ＡＰＰ制御サーバ３は指定されたアプリケーションを起動する（Ｓ３−４３）。

その後、運用監視サーバ８はロボット２１に対してサーバ変更通知を送信し（Ｓ３−４６）、対象のアプリケーションがＡＰＰ制御サーバ３で実行中であることをロボット２１に通知する。

ロボット２１は対象のアプリケーションの接続先がＡＰＰ制御サーバ３になるようＡＰＰ接続先情報ＤＢ２６６を更新し、ロボット２１で稼働中の当該アプリケーションを停止する（Ｓ３−４９）。

以降、当該アプリケーションの処理はロボット２１とＡＰＰ制御サーバ３の間でメッセージの送受信を通じて行われる（Ｓ３−５２、Ｓ３−５５）。

ロボット２１を含めたサービス要求処理装置の変更については、図１２のケースのほかに、下記の３つのケースが考えられる。
（１）ＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更
（２）ロボット２１から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更
（３）中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更
図１３はＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更するケースの時系列図である。ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ４−０１〜Ｓ４−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。

ステップＳ４−３７において、運用監視サーバ８はＡＰＰ制御サーバ３からロボット２１へサービス要求処理装置を変更すると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ４−４０）。

サーバ変更通知を受信したロボット２１は、サービス要求処理装置の変更対象が自身であることを知り、アプリケーション識別子で指定されたアプリケーションを起動する（Ｓ４−４３）。

運用監視サーバ８はＡＰＰ制御サーバ３にＡＰＰ停止通知を送信し（Ｓ４−４６）、ＡＰＰ制御サーバ３は指定されたアプリケーションを停止させる（Ｓ４−４９）。

図１４はロボット２１から中央ＡＰＰ制御サーバ７にサービス要求処理装置を変更させるケースの時系列図である。

本来、ロボット２１の負荷軽減を目的としたときのサービス要求処理装置の変更先は、ロボット２１と同じ監視対象拠点１に設置したＡＰＰ制御サーバ３であることが望ましいが、ＡＰＰ制御サーバ３の処理負荷がきわめて高い場合などに、中央ＡＰＰ制御サーバ７への変更処理を検討する。

ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ５−０１〜Ｓ５−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。

ステップＳ５−３７において、運用監視サーバ８はロボット２１から中央ＡＰＰ制御サーバ７へサービス要求処理装置を変更させると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ５−４０）。

サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先が中央ＡＰＰ制御サーバ７となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを停止させる（Ｓ５−４３）。

以降、当該アプリケーションの処理はロボット２１と中央ＡＰＰ制御サーバ７の間でメッセージの送受信を通じて行われる（Ｓ５−４６、Ｓ５−４９）。

図１５は中央ＡＰＰ制御サーバ７からロボット２１にサービス要求処理装置を変更させるケースの時系列図である。

図１４の状態からロボット２１の処理負荷が下がり、元の状態に復旧するケースが該当する。ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ６−０１〜Ｓ６−３４）は図１２のステップＳ３−０１〜Ｓ３−３４と同様であるため、説明を割愛する。

ステップＳ６−３７において、運用監視サーバ８は中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更すると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ５−４０）。

サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先がロボット２１自身となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを起動する（Ｓ６−４３）。当該アプリケーションの処理はロボット２１が行う。

拠点によっては図１の監視対象拠点２（１−２）のように、ＡＰＰ制御サーバ３がないケースがある。この場合、ロボット２１は中央ＡＰＰ制御サーバ７を通じて運用監視サーバ８へ各種の情報を送信する。図１６はこのような状況において、アプリケーションを実行する装置をロボット２１から中央ＡＰＰ制御サーバ７へ変更する場合の時系列図である。

ロボット２１はリソース情報、状態情報を収集し（Ｓ７−０１、Ｓ７−０７）、これらを中央ＡＰＰ制御サーバ７へ送信する（Ｓ７−０４、Ｓ７−１０）ロボットリソース情報の内容はロボットリソースＤＢ３６９と一致する。また、ロボット状態情報の内容はロボット状態ＤＢ３６８と一致する。

ロボット２１からロボットリソース情報、ロボット状態情報を受信した中央ＡＰＰ制御サーバ７は、これらの情報を運用監視サーバ８に送信する（Ｓ７−０５、Ｓ７−１１）。中央ＡＰＰ制御サーバ７は、図１０のステップＳ１−１３、Ｓ１−１６と同様の方法で、拠点リソース情報を運用監視サーバ８に送信する（Ｓ７−１３〜Ｓ７−１６）。

運用監視サーバ８は収集した各ロボットリソース情報、ロボット状態情報、拠点リソース情報に基づき、サービス要求処理装置の変更要否を判定する（Ｓ７−１９）。このケースではアプリケーションを稼働させる装置を、ロボット２１から中央ＡＰＰ制御サーバ７へ変更するため、運用監視サーバ８はロボット２１に対してサーバ変更通知を送信し（Ｓ７−２２）、対象のアプリケーションが中央ＡＰＰ制御サーバ７で実行中であることをロボット２１に通知する。

ロボット２１は対象のアプリケーションの接続先が中央ＡＰＰ制御サーバ７になるようＡＰＰ接続先情報ＤＢ２６６を更新し、ロボット２１で稼働中の当該アプリケーションを停止する（Ｓ７−２５）。

以降、当該アプリケーションの処理はロボット２１と中央ＡＰＰ制御サーバ７の間でメッセージの送受信を通じて行われる（Ｓ７−２８、Ｓ７−３１）。

図１７は図１６とは逆のケースで、アプリケーションの実行装置を中央ＡＰＰ制御サーバ７からロボット２１へ変更する場合の時系列図である。ロボット２１、中央ＡＰＰ制御サーバ７から各種の情報を収集する処理（Ｓ８−０１〜Ｓ８−１６）は図１６のステップＳ７−０１〜Ｓ７−１６と同様であるため、説明を割愛する。

ステップＳ８−１９において、運用監視サーバ８は中央ＡＰＰ制御サーバ７からロボット２１へサービス要求処理装置を変更させると判断し、サーバ変更通知をロボット２１へ送信する（Ｓ８−２２）。サーバ変更通知を受信したロボット２１は、指定されたアプリケーションの接続先がロボット２１となるようＡＰＰ接続先情報ＤＢ２６６を更新し、指定されたアプリケーションを起動する（Ｓ８−２５）。

監視対象拠点１に複数台のロボット２１が設置されている場合、サービス要求処理装置の変更は各ロボット２１に対して行う。

図１８は監視対象拠点１に２台のロボット１（２１−１）、ロボット２（２１−２）が設置されている場合のサービス要求処理装置変更の判定処理を表す時系列図である。ここでは、ロボット１（２１−１）、ロボット２（２１−２）が最初は同じ場所にあったが、ロボット１（２１−１）が場所を移動した（Ｓ９−０１）ものと想定する。

場所が移動すると、ロボット２１がシステム内で担う役割が変化する。例えば銀行を例にとると、金庫室ではセキュリティ監視が主な業務となるのに対し、顧客応対フロアでは種々の応対業務を行う必要がある。

ロボット２１が拠点に複数存在する場合、各ロボット２１はロボットリソース情報、ロボット状態情報の収集、通知をそれぞれ行う（Ｓ９−０４〜Ｓ９−２６）。

ＡＰＰ制御サーバ３がロボットリソース情報およびロボット状態情報を運用監視サーバ８に送信する場合（Ｓ９−１４、Ｓ９−２６）は、監視対象拠点内のロボット（２１−１〜２１−Ｎ）の情報を一括して送信する。

ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７は、これまでの処理と同様の方法で拠点リソース情報、拠点状態情報の収集を行い、運用監視サーバ８に送信する（Ｓ９−２８〜Ｓ９−４３）。

サービス要求処理装置の変更判定（Ｓ９−４６）において、ロボット１（２１−１）のあるアプリケーションをＡＰＰ制御サーバ３で稼働させる必要があると判断したとする。

運用監視サーバ８はＡＰＰ制御サーバ３に対し、実行させる装置の変更対象となるアプリケーションの起動通知を送信する（Ｓ９−４９）。ＡＰＰ起動通知は起動対象のアプリケーション識別子を指定する。ＡＰＰ制御サーバ３は指定されたアプリケーションを起動する（Ｓ３−５２）。

その後、運用監視サーバ８はロボット１（２１−１）に対してサーバ変更通知を送信し（Ｓ９−５５）、対象のアプリケーションがＡＰＰ制御サーバ３で実行中であることをロボット１（２１−１）に通知する。ロボット１（２１−１）は対象のアプリケーションの接続先がＡＰＰ制御サーバ３になるようＡＰＰ接続先情報ＤＢ２６６を更新する。

以降、当該アプリケーションの処理はロボット１（２１−１）とＡＰＰ制御サーバ３の間でメッセージの送受信を通じて行われる（Ｓ９−５８、Ｓ９−６１）。

次に、図１９のフローチャートを用いて、運用監視サーバ８におけるサービス要求処理装置の変更判定方法について説明する。

サービス要求処理装置の変更判定は、運用監視サーバ８がロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７から各種の情報を受信した後に行われる（図１２のステップＳ３−３７等）。起動契機としては、上記の各種情報の受信状況をチェックするほか、周期的に判定処理を起動する方法が考えられる。

サービス要求処理装置変更の判定処理は、運用監視サーバ８のアプリケーション情報ＤＢ８６５で管理されているすべての条件識別子に対して行う（Ｆ１−０４）。この処理は、アプリケーション情報ＤＢ８６５からある１つの条件識別子に対応したレコードを取得し、当該レコードに対する判定処理を実行することで実現できる（Ｆ１−０７）。

ここで、当該レコードの判定条件を用いてサービス要求処理装置変更の判定処理を行う（Ｆ１−１０）、全ての判定条件が満たされている場合は、サービス要求処理装置の変更処理を実行する（Ｆ１−１３）。そうでない場合は処理ループの先頭に戻り、別の条件識別子に対応したレコードのサービス要求処理装置変更の判定を行う（Ｆ１−０４、Ｆ１−０７）。

すべての条件識別子に対応したレコードに対して判定処理を完了した（Ｆ１−１６）時点で、サービス要求処理装置変更の要否判定処理は終了する（Ｆ１−１９）。

サービス要求処理装置変更の判定における判定条件には様々なものが考えられる。

図２０は判定条件を設定する判定条件編集画面の一例である。判定条件の設定に必要な項目はアプリケーション名、変更種別、変更方向と変更判定条件である。アプリケーション名はアプリケーションを一意に特定できる必要があり、アプリケーション情報ＤＢ８６５のＡＰＰ識別子として使用される。

変更種別は変更可、もしくは固定の２つから選択する。変更可の場合は、変更の向きを選択して設定する。固定の場合はアプリケーションの配置拠点を設定する。固定を選択した場合、当該アプリケーションは拠点基本情報ＤＢ３６４の固定ＡＰＰリストに登録される。

変更判定条件はサービス要求処理装置の変更条件を決定する項目であり、必要に応じて複数個登録することが可能である。変更判定条件に設定可能な項目としては、ロボット２１、ＡＰＰ制御サーバ３、中央ＡＰＰ制御サーバ７のＣＰＵ使用率、消費ネットワーク帯域、ロボット２１の位置、場所の業務などがあげられる。

判定方法については、数値化可能な条件については以上、以下などの判定を行い、場所や業務内容など、文字列で表現される条件については文字列の内容で判定を行う。

例えば、銀行での顧客応対業務を例にとると、ロボット２１が顧客応対スペースに移動し、主業務として顧客対応を行わなければならなくなった時点で、ロボット２１のＣＰＵ負荷が１０％と低い状態にあっても、当該サービス要求処理装置をＡＰＰ制御サーバ３へ変更する。

逆に、ロボット２１が顧客応対スペースから離脱し、顧客対応をする必要が無くなった場合、当該アプリケーションを使用する確率は低下するため、銀行顧客応対業務が万が一発生しても中央ＡＰＰ制御サーバ７で対処して、ＡＰＰ制御サーバ３の処理負荷を低減できる。

サービス要求処理装置の変更パターンと具体例としては、以下の項目が考えられる。
（１）ＡＰＰ制御サーバ３から中央ＡＰＰ制御サーバ７へ
・ある拠点のＡＰＰの利用率が低いため、中央ＡＰＰ制御サーバ７に集約
・時間帯による客層変化、サービス内容変更によるＡＰＰ利用率低下：夜間の顧客応対業務を中央ＡＰＰ制御サーバ７に集約化
（２）中央ＡＰＰ制御サーバ７からＡＰＰ制御サーバ３へ
・ある拠点から接続されているＡＰＰの利用率が高い
・時間帯による客層変化、サービス内容変更によるＡＰＰ利用率上昇：ビジネスアワーの通常業務をＡＰＰ制御サーバ３で処理
（３）ロボット２１からＡＰＰ制御サーバ３へ
・同一拠点で複数のロボット２１が同一のアプリケーションを実行：ＡＰＰ制御サーバ３にアプリケーションを集約してロボット２１の処理負荷を下げる
（４）ＡＰＰ制御サーバ３からロボット２１へ
・（３）と逆の事象が発生
（５）ロボット２１から中央ＡＰＰ制御サーバ７へ
・ＡＰＰ制御サーバ３がない拠点において、ロボット２１の処理負荷を可能な範囲で低減する
（６）中央ＡＰＰ制御サーバ７からロボット２１へ
・ロボット２１の位置が特定の業務を提供する場所になった場合、応答時間の短縮を狙ってアプリケーションをロボットで実行する
上述した機器運用監視装置および機器運用監視システムは、多数の拠点に存在する種々の機器を統合管理する運用監視サービスへの適用が見込まれる。

１：監視対象拠点
２１：ロボット
３：ＡＰＰ制御サーバ
４：構内ＬＡＮ
５：ネットワーク
６：監視センタ
７：中央ＡＰＰ制御サーバ
８：運用監視サーバ

Claims (8)

1. 運用監視サーバであって、
   自律移動可能な情報処理装置と、前記自律移動可能な情報処理装置からのサービス要求を処理するサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点のいずれかに設置され、
   前記自律移動可能な情報処理装置及び前記自律移動可能な情報処理装置が設置されている拠点それぞれの状態情報を取得し、
   前記自律移動可能な情報処理装置の状態情報は、前記自律移動可能な情報処理装置の現在位置情報を含み、
   前記自律移動可能な情報処理装置が設置されている拠点の状態情報は、前記自律移動可能な情報処理装置が設置されている拠点のマップ情報並びに前記自律移動可能な情報処理装置が設置されている拠点内での業務の場所及び時間の情報を含み、
   前記自律移動可能な情報処理装置、前記自律移動可能な情報処理装置が設置されている拠点、及び前記運用監視サーバが設置されている拠点それぞれのリソース情報を取得し、
   前記自律移動可能な情報処理装置のリソース情報は、前記自律移動可能な情報処理装置のリソース使用状況の情報を含み、
   前記自律移動可能な情報処理装置が設置されている拠点のリソース情報は、前記自律移動可能な情報処理装置が設置されている拠点のリソース使用状況の情報を含み、
   前記運用監視サーバが設置されている拠点のリソース情報は、前記運用監視サーバが設置されている拠点のリソース使用状況の情報を含み、
   取得した前記状態情報及び前記リソース情報に基づき、前記自律移動可能な情報処理装置からのサービス要求を処理するサービス要求処理装置として、前記自律移動可能な情報処理装置が設置されている拠点にある第一のサービス要求処理装置、または、前記運用監視サーバが設置されている拠点に設置されている第二のサービス要求処理装置のいずれかを選択し、
   前記自律移動可能な情報処理装置の状態情報及びリソース情報、並びに、前記自律移動可能な情報処理装置が設置されている拠点の状態情報及びリソース情報を、前記第一のサービス要求処理装置を介して取得する
   ことを特徴とする運用監視サーバ。
2. 請求項１に記載の運用監視サーバであって、
   選択した前記サービス要求処理装置が、前記自律移動可能な情報処理装置に登録されている現用のサービス要求処理装置とは異なる場合、前記自律移動可能な情報処理装置へ、現用のサービス要求処理装置の変更を通知する
   ことを特徴とする運用監視サーバ。
3. 請求項２に記載の運用監視サーバであって、
   前記変更の通知後に、前記現用のサービス要求処理装置に対して、当該サービス要求処理装置において実行中の、前記サービス要求の処理の停止を指示する
   ことを特徴とする運用監視サーバ。
4. 請求項２または３に記載の運用監視サーバであって、
   前記変更の通知前に、前記変更後のサービス要求処理装置において、前記サービス要求の処理の起動を指示する
   ことを特徴とする運用監視サーバ。
5. 自律移動可能な情報処理装置と、前記自律移動可能な情報処理装置からのサービス要求を処理するサービス要求処理装置と、のいずれか一方または両方が設置されている複数の拠点がネットワークで接続され、前記複数の拠点のいずれかに設置されている運用監視サーバが前記自律移動可能な情報処理装の運用を監視する運用監視システムであって、
   前記自律移動可能な情報処理装置が設置されている拠点にある第一のサービス要求処理装置は、前記自律移動可能な情報処理装置から取得した前記自律移動可能な情報処理装置の状態情報及びリソース情報、並びに、前記自律移動可能な情報処理装置が設置されている拠点の状態情報及びリソース情報を、前記運用監視サーバへ送信し、
   前記運用監視サーバが設置されている拠点の第二のサービス要求処理装置は、前記運用監視サーバが設置されている拠点のリソース情報を、前記運用監視サーバへ送信し、
   前記自律移動可能な情報処理装置の状態情報は、前記自律移動可能な情報処理装置の現在位置情報を含み、
   前記自律移動可能な情報処理装置が設置されている拠点の状態情報は、前記自律移動可能な情報処理装置が設置されている拠点のマップ情報並びに前記自律移動可能な情報処理装置が設置されている拠点内での業務の場所及び時間の情報を含み、
   前記自律移動可能な情報処理装置のリソース情報は、前記自律移動可能な情報処理装置のリソース使用状況の情報を含み、
   前記自律移動可能な情報処理装置が設置されている拠点のリソース情報は、前記自律移動可能な情報処理装置が設置されている拠点のリソース使用状況の情報を含み、
   前記運用監視サーバが設置されている拠点のリソース情報は、前記運用監視サーバが設置されている拠点のリソース使用状況の情報を含み、
   前記運用監視サーバは、
   前記第一のサービス要求処理装置及び前記第二のサービス要求処理装置から受信した前記状態情報及び前記リソース情報に基づき、前記自律移動可能な情報処理装置からのサービス要求を処理するサービス要求処理装置として、前記第一のサービス要求処理装置、または、前記第二のサービス要求処理装置のいずれかを選択する
   ことを特徴とする運用監視システム。
6. 請求項５に記載の運用監視システムであって、
   前記運用監視サーバは、
   選択した前記サービス要求処理装置が、前記自律移動可能な情報処理装置に登録されている現用のサービス要求処理装置とは異なる場合、前記自律移動可能な情報処理装置へ、現用のサービス要求処理装置の変更を通知する
   ことを特徴とする運用監視システム。
7. 請求項６に記載の運用監視システムであって、
   前記運用監視サーバは、
   前記変更の通知後に、前記現用のサービス要求処理装置に対して、当該サービス要求処理装置において実行中の、前記サービス要求の処理の停止を指示する
   ことを特徴とする運用監視システム。
8. 請求項６または７に記載の運用監視システムであって、
   前記運用監視サーバは、
   前記変更の通知前に、前記変更後のサービス要求処理装置において、前記サービス要求の処理の起動を指示する
   ことを特徴とする運用監視システム。

Images