特許 6572330 ロボットアプリケーション管理装置、システム、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6572330

(24)【登録日】2019年8月16日

(45)【発行日】2019年9月4日

(54)【発明の名称】ロボットアプリケーション管理装置、システム、方法及びプログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20190826BHJP

   G06F 9/455 20060101ALI20190826BHJP

   G06F 11/20 20060101ALI20190826BHJP

【ＦＩ】

   G06F9/50 150B

   G06F9/50 150C

   G06F9/455 150

   G06F11/20 630

【請求項の数】19

【全頁数】27

(21)【出願番号】特願2018-11123(P2018-11123)

(22)【出願日】2018年1月26日

(65)【公開番号】特開2019-128863(P2019-128863A)

(43)【公開日】2019年8月1日

【審査請求日】2018年11月6日

【新規性喪失の例外の表示】特許法第３０条第２項適用 ▲１▼発行日 平成２９年８月２５日 ▲２▼刊行物 電子情報通信学会技術研究報告 Ｖｏｌ．１１７ Ｎｏ．１９８ ３７−４２頁 ▲３▼公開者 福田竜也 林康二

【早期審査対象出願】

(73)【特許権者】

【識別番号】391021710

【氏名又は名称】株式会社インテック

(74)【代理人】

【識別番号】230104019

【弁護士】

【氏名又は名称】大野 聖二

(74)【代理人】

【識別番号】100105038

【弁理士】

【氏名又は名称】田中 久子

(74)【代理人】

【識別番号】100131451

【弁理士】

【氏名又は名称】津田 理

(72)【発明者】

【氏名】福田 竜也

(72)【発明者】

【氏名】濱田 緑里

(72)【発明者】

【氏名】林 康二

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開２００９−２８２６５２（ＪＰ，Ａ）

【文献】 寺内 敦，ＩｏＴによる新たな価値創出に向けた研究開発の取り組み，ＮＴＴ技術ジャーナル，一般社団法人電気通信協会，２０１７年 ７月 １日，第29巻,第7号，pp.19-23

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／４５５

Ｇ０６Ｆ １１／２０

(57)【特許請求の範囲】

【請求項1】

複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置であって、
前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、
前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備え、
前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われ、
前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、
前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開することを特徴とするロボットアプリケーション管理装置。

【請求項2】

前記ロボットアプリケーション管理装置と外部ネットワークを介して接続される少なくとも一つのクラウドサービス装置を、前記クラスタを構成する装置群に含めることを特徴とする請求項１に記載のロボットアプリケーション管理装置。

【請求項3】

前記複数の仮想コンテナには、所定以上の処理能力又は記憶容量を要するために該仮想コンテナを実行する装置の選択に別の制約がある第三の種類の仮想コンテナがあり、
前記第三の種類の仮想コンテナと、前記第一及び第二の種類の仮想コンテナとは、疎結合で動作するものであり、
前記配置は、第三の種類の仮想コンテナについては、前記別の制約を満たす装置を選択して行われることを特徴とする請求項１又は２に記載のロボットアプリケーション管理装置。

【請求項4】

前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるための手順を、記憶する手段をさらに備えることを特徴とする請求項１〜３のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項5】

前記クラスタを構成する装置群の各装置がどの制約を満たすものかを示す情報を記憶する手段をさらに備えることを特徴とする請求項１〜４のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項6】

前記複数種類の仮想コンテナのそれぞれが配置される装置が該仮想コンテナの実行可能なプログラムを取得できるように、該実行可能なプログラムを記憶する手段をさらに備えることを特徴とする請求項１〜５のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項7】

前記仮想コンテナの実行可能なプログラムは、前記ロボットアプリケーションを構成するアプリケーションプログラムとオペレーティングシステム（ＯＳ）とがパッケージ化されたものであり、各装置のホストＯＳ上に仮想コンテナごとに分離した空間が形成され、該ホストＯＳからはプロセスとして見えるように実行されるものであることを特徴とする請求項１〜６のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項8】

前記クラスタを構成する装置群のいずれかが動作不良に陥った場合に、該動作不良に陥
った装置で起動されている仮想コンテナを、前記クラスタを構成する他の装置に再配置して起動させることにより、前記ロボットアプリケーションの実行を継続する手段をさらに備え、
前記再配置は、前記実行する装置の選択に制約がある仮想コンテナについては、該制約を満たす装置を選択して行われ、該制約を満たす装置が前記動作不良に陥った装置以外に存在しない場合には、前記ロボットアプリケーションの実行を停止するものであることを特徴とする請求項１〜７のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項9】

前記仮想コンテナが起動されている装置が前記クラスタを構成する装置でなくなった場合に、該仮想コンテナを停止させる手段と、
前記仮想コンテナを停止させるための手順を、記憶する手段とをさらに備えることを特徴とする請求項１〜８のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項10】

前記複数種類の仮想コンテナのそれぞれがどの装置に配置され、起動中であるか停止中であるかを含めどのような状態であるかを示す情報を収集し、ユーザに表示するサービス又は履歴を記憶するサービスの少なくとも一方へ送信する手段をさらに備えることを特徴とする請求項１〜９のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項11】

前記クラスタを構成する各装置における各仮想コンテナが前記ローカルネットワークを介して通信できるように、ネットワーク接続を支援する手段をさらに備え、
該手段の少なくとも一部は、前記複数種類の仮想コンテナのうちの一つが自装置に配置されて起動されることにより備えられることを特徴とする請求項１〜１０のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項12】

前記少なくとも一つのロボット装置は、移動するロボット装置を含み、
前記ローカルネットワークのうち少なくとも前記移動するロボット装置への接続部分は、無線で構成されるものであり、
前記無線接続のためのアクセスポイント機能又はマルチホップ機能の少なくとも一方をさらに備えることを特徴とする請求項１〜１１のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項13】

前記ロボットアプリケーション管理装置が備える手段のうちの少なくとも一部を備える少なくとも１つの副ロボットアプリケーション管理装置を、前記クラスタを構成する装置群に含めることを特徴とする請求項１〜１２のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項14】

前記ローカルエリアネットワークと外部ネットワークとの境界に位置し、
前記ローカルエリアネットワークに接続された各装置を前記外部ネットワークから保護する手段をさらに備えることを特徴とする請求項１〜１３のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項15】

前記ロボットアプリケーションのために物理的環境のデータを入力するセンサをさらに備え、
前記センサを制御する仮想コンテナを、前記複数種類の仮想コンテナのうちの一つとして、自装置に配置して起動させることを特徴とする請求項１〜１４のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項16】

前記クラスタを構成する少なくとも一つの装置における少なくとも一つの仮想コンテナが前記ローカルネットワークを介して前記クラスタを構成しない装置と通信できるように、ネットワーク接続のためのアドレスを付与する手段をさらに備えることを特徴とする請求項１〜１５のいずれか１項に記載のロボットアプリケーション管理装置。

【請求項17】

複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置と、
前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置及び少なくとも一つのコンピュータ装置とを備えるシステムであって、
前記システムの備える装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、
前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備え、
前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われ、
前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、
前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開することを特徴とするシステム。

【請求項18】

複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理方法であって、
前記ロボットアプリケーション管理方法を実行する装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理し、
前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させ、
前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われ、
前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、
前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開することを特徴とするロボットアプリケーション管理方法。

【請求項19】

複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理プログラムであって、
前記ロボットアプリケーション管理プログラムがインストールされる装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理するためのプログラムコードと、
前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるためのプログラムコードとを備え、
前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われ、
前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、
前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開することを特徴とするロボットアプリケーション管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ロボットシステムを分散型計算システムによって実現する技術に関し、特に、当該システムにおいてロボットアプリケーションの管理を行う機構に関する。

【背景技術】

【0002】

近年、サービスロボットのソフトウェアの開発において、ＲＯＳ（Ｒｏｂｏｔ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と呼ばれる分散型計算システムを指向したロボット向けミドルウェアが使われることが、多くなっている。ＲＯＳによって提供されるエコシステム及び豊富なライブラリ群によって、サービスロボットの開発効率は、向上している（例えば、非特許文献１）。

【0003】

一方、分散型計算システムは、元々、コンピュータ・サイエンス分野において、古くから使われている考え方の一つである。システムを構成する複数のコンピュータを束ねて、一つのクラスタとして捉えるための仕組みが、一般的に提供されている。それらは、運用／監視の多くを自動化し、開発を効率的に進め、品質管理コストを下げるための仕組みを内包している。この仕組みは、各種ネットワーク技術や仮想化技術をベースとした様々な技術を組み合わせることにより、実現される（例えば、非特許文献２）。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】銭飛著「ＲＯＳプログラミング」森北出版株式会社（２０１６年３月３０日発行）

【非特許文献2】古賀政純著「Ｄｏｃｋｅｒ実践ガイド」株式会社インプレス（２０１５年１２月２１日発行）

【発明の概要】

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

【0005】

ロボットシステムを複数台のコンピュータで構成して分散型計算システムによって実現することが、一般的になってきているが、ＲＯＳでは、複数台のコンピュータの管理や制御については定義されていない。そのため、ＲＯＳによって無秩序に大量のマシンやプロセス等のリソースが使われたり、ＲＯＳの適用がネットワーク環境（時刻同期、アドレス付与、名前解決等）に依存して制限されたりすることが起こり得る。

【0006】

現状では、そのようなことが起こらないように、ロボットシステムの開発者や管理者が、ロボットシステムを構成する各コンピュータに、手動でログインして、ロボット用のプロセスの実行やメンテナンスを個別に行わざるを得ない。しかも、個々の開発者や管理者によって、ロボットシステムのように実行に物理的な制約のあるアプリケーションを、分散型計算システムにおいてどのように扱うかが変わってくるため、継続的な開発が難しく、プロトタイプの作成と実証実験止まりとなってしまう例が多発している。

【0007】

分散型計算システムの開発と運用／監視と品質管理とを継続的に最適化するための技法は、コンピュータ・サイエンス分野では培われてきているが、その重要な一つである仮想化技術は、従来、ハイパーバイザー型が中心であったため、ロボットシステムでは利用されてこなかった。ハイパーバイザー型の環境下では、ロボットハードウェアを認識できないケースが見られたためである。

【0008】

本発明は、コンピュータ・サイエンス分野における分散型計算システムの開発と運用／監視と品質管理とを継続的に最適化するための技法を、ロボットシステムにおいて活用し、ロボットシステムの開発者や管理者が計算リソースとネットワーク環境の管理や制御を行う煩わしさを、軽減することを目的とする。

【課題を解決するための手段】

【0009】

本発明の原理に従う一つの態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置であって、前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備える。

【0010】

本発明の原理に従う別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置と、前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置及び少なくとも一つのコンピュータ装置とを備えるシステムであって、前記システムの備える装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備える。

【0011】

本発明の原理に従うまた別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理方法であって、前記ロボットアプリケーション管理方法を実行する装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理し、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる。

【0012】

本発明の原理に従うさらに別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理プログラムであって、前記ロボットアプリケーション管理プログラムがインストールされる装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理するためのプログラムコードと、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるためのプログラムコードとを備える。

【0013】

上述した本発明の原理に従う各態様において、前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われる。

【発明の効果】

【0014】

本発明によれば、ロボットシステムの開発者や管理者が計算リソースとネットワーク環境の管理や制御を行う煩わしさを、軽減することができるとともに、例えば、物理的な制約のあるロボットシステムにおいて分散型計算システムのコンピュータリソースを最適に利用することが可能になる。

【図面の簡単な説明】

【0015】

【図1】本発明の一実施形態に係るシステム（以下、「本システム」という）の構成の一例を示す図。

【図2】本システムの構成の別の例を示す図。

【図3】本システムの利用例を示す図。

【図4】本システムの実装例を示す図。

【図5】ロボットアプリケーション管理装置の通信モジュール部及び無線通信基地局提供部の動作の流れの一例を示す図。

【図6】ロボットアプリケーション管理装置の共通情報配信部の動作の流れの一例を示す図。

【図7】ロボットアプリケーション管理装置及び末端コンピュータ装置の郡実行型論理コンテナ用仮想化環境提供部の動作の流れの一例を示す図。

【図8】ロボットアプリケーション管理装置の履歴管理部の動作の流れの一例を示す図。

【図9】本システムにおいて実行する装置の選択に制約のある仮想コンテナの配置を実現するための機構の一例を示す図。

【図10】本システムにおいていずれかの装置が動作不良に陥った場合に対処する動作の一例を示す図。

【図11】本システムにおいて仮想コンテナ技術を導入した装置とそうでない装置とを混在させてロボットシステムを構成するための機構の一例を示す図。

【図12】本システムにおける仮想コンテナの配置例を示す図。

【発明を実施するための形態】

【0016】

以下、本発明の実施の形態について説明するが、以下の説明は、本発明の具体例を示すものであって、本発明の範囲を限定するものではない。

【0017】

上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置と外部ネットワークを介して接続される少なくとも一つのクラウドサービス装置を、前記クラスタを構成する装置群に含めるようにしてもよい。

【0018】

これにより、ローカルエリアネットワーク内でシステムを構成する複数のコンピュータ装置（ロボット装置も、ロボットアプリケーション管理装置も、コンピュータリソースを有する装置である）に加えて、外部ネットワークの向こう側にあるクラウドサービス装置をも束ねて、一つのクラスタとして扱うことが可能になり、コンピュータリソースの最適な利用をさらに進化させることができる。例えば、レスポンスの速さが要求されるような仕事を行う仮想コンテナは、ローカルエリアネットワーク内の装置に配置し、大量のデータを解析するような仕事を行う仮想コンテナは、クラウドサービス装置に配置することが可能である。

【0019】

上述した本発明の原理に従う態様において、前記複数の仮想コンテナには、所定以上の処理能力又は記憶容量を要するために該仮想コンテナを実行する装置の選択に別の制約がある第三の種類の仮想コンテナがあり、前記第三の種類の仮想コンテナと、前記第一及び第二の種類の仮想コンテナとは、疎結合で動作するものであり、前記配置は、第三の種類の仮想コンテナについては、前記別の制約を満たす装置を選択して行われるものであってもよい。

【0020】

これにより、例えば、ロボット装置に搭載されたモータやセンサ等の物理的な要素との直接接続（例えば、ＵＳＢ接続等）を要する仕事を行う仮想コンテナは、そのロボット装置に配置する一方で、特定の性能を有するコンピュータ装置上での動作を要する仕事を行う仮想コンテナは、そのようなコンピュータ装置（例えば、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を有する装置や、潤沢なメモリを有する装置等）に配置することが可能になる。

【0021】

なお、これらの仮想コンテナ間の疎結合は、例えば、ＲＯＳのトピック通信モデルによって、容易に実現することができる。

【0022】

上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるための手順を、記憶する手段をさらに備えるようにしてもよい。

【0023】

これにより、例えば、ロボットシステムを構成する各装置に、手動でログインして個別にプロセスの実行やメンテナンスを行う作業から、ロボットシステムの開発者や管理者を解放することが可能になる。

【0024】

上述した本発明の原理に従う態様において、前記クラスタを構成する装置群の各装置がどの制約を満たすものかを示す情報を記憶する手段をさらに備えるようにしてもよい。

【0025】

これにより、例えば、上述した手順として、実行する装置の選択に制約がある仮想コンテナについては、その制約を満たす装置にその仮想コンテナを配置して起動させるように記述した手順を記憶しておき、その手順を実行する際に、各装置がどの制約を満たすものかを示す情報を参照することによって、仮想コンテナを配置する装置を自動的に選択することが可能になる。

【0026】

上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれが配置される装置が該仮想コンテナの実行可能なプログラムを取得できるように、該実行可能なプログラムを記憶する手段をさらに備えるようにしてもよい。

【0027】

これにより、例えば、上述した手順によって自装置に対して指定された仮想コンテナの実体である実行可能なプログラム（イメージと呼ばれることもある）を、各装置が自動的に入手することが可能になり、ロボットシステムの開発者や管理者が各装置に手動でログインすることなく、各仮想コンテナの配置と起動ができるようになる。

【0028】

上述した本発明の原理に従う態様において、前記仮想コンテナの実行可能なプログラムは、前記ロボットアプリケーションを構成するアプリケーションプログラムとＯＳとがパッケージ化されたものであり、各装置のホストＯＳ上に仮想コンテナごとに分離した空間が形成され、該ホストＯＳからはプロセスとして見えるように実行されるものであるようにしてもよい。

【0029】

このように、本発明の原理に従う態様では、コンテナ型の仮想化技術を、ロボットシステムにおいて利用することが可能になる。

【0030】

なお、仮想コンテナは、既存の仮想コンテナランタイムの技術を利用して実現することができる。仮想コンテナランタイムとは、コンテナ管理ソフトウェア本体であり、ソフトウェアコンテナ内のアプリケーション（これを仮想コンテナと呼ぶ）のデプロイメント（コンピュータに配置して起動させること）を自動化することが可能なものである。本発明の原理に従う態様においては、複数種類の仮想コンテナを連携させながら実行することにより、一つのロボットアプリケーションが実行されるため、一つの仮想コンテナに相当するソフトウェアコンテナ内のアプリケーションは、ロボットアプリケーションの一部の機能を実現するものとなる。

【0031】

また、クラスタを構成する複数の装置に対する各仮想コンテナの配置及び起動は、既存の仮想コンテナオーケストレーションツールの技術を利用して実現することができる。仮想コンテナオーケストレーションツールとは、複数のコンピュータ装置（ノードあるいはホストとも呼ばれる）に対する仮想コンテナの設定、構築、配備を自動化することが可能なものであり、これによって、プロセスの死活監視、自動再起動、アップデート配信の簡略化等を実現することも可能である。本発明の原理に従う態様においては、例えば、ラベル等を使って自動配置先につき所定程度の制約を設けることができるツールの技術を利用することが望ましい。

【0032】

上述した仮想コンテナランタイムの技術としては、例えば、Ｄｏｃｋｅｒ社の「Ｄｏｃｋｅｒ」、ＣｏｒｅＯＳ社の「Ｒｋｔ」、Ｌｉｎｕｘ（登録商標） Ｆｏｕｎｄａｔｉｏｎの「ＬＸＣ」、Ｍｉｃｒｏｓｏｆｔ社の「Ｈｙｐｅｒ−Ｖ」等を利用することができる。

【0033】

上述した仮想コンテナオーケストレーションツールの技術としては、例えば、「Ｄｏｃｋｅｒ Ｓｗａｒｍ」（非特許文献２を参照）、「Ｋｕｂｅｒｎｅｔｅｓ」（https://kubernetes.io/を参照）、「Ｒａｎｃｈｅｒ」（https://rancher.com/を参照）、「ｆｌｅｅｔ」（https://coreos.com/fleet/docs/latest/launching-containers-fleet.htmlを参照）等を利用することができる。

【0034】

上述した本発明の原理に従う態様において、前記クラスタを構成する装置群のいずれかが動作不良に陥った場合に、該動作不良に陥った装置で起動されている仮想コンテナを、前記クラスタを構成する他の装置に再配置して起動させることにより、前記ロボットアプリケーションの実行を継続する手段をさらに備え、前記再配置は、前記実行する装置の選択に制約がある仮想コンテナについては、該制約を満たす装置を選択して行われるものであり、該制約を満たす装置が前記動作不良に陥った装置以外に存在しない場合には、前記ロボットアプリケーションの実行を停止するようにしてもよい。

【0035】

これにより、物理的な制約のあるロボットシステムにおいて分散型計算システムのコンピュータリソースを最適に利用しながら、クラスタを構成する一部の装置が動作不良（例えば、コンピュータ装置自体の故障や、ロボット装置のローカルエリアネットワークの通信範囲内からの離脱や、クラウドサービス装置の外部ネットワークを介した通信の途絶等により、当該装置が正常に機能しているという確認がとれなくなった状態）に陥った場合に、その装置上の仮想コンテナが他の装置上に再配置してもよいものであれば自動的にロボットシステムを動作させ続け、再配置不可のものであれば自動的にロボットシステムを停止させることが可能になる。

【0036】

上述した本発明の原理に従う態様において、前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開するようにしてもよい。

【0037】

これにより、例えば、ロボット装置がローカルエリアネットワークの通信範囲内から離脱して、ロボットシステムが停止した場合に、当該ロボット装置が再びローカルエリアネットワークの通信範囲内に入ったら、自動的にロボットシステムを再開するようなことが可能になる。別の例として、ロボット装置が故障して、ロボットシステムが停止した場合に、代わりのロボット装置をローカルエリアネットワークの通信範囲内で立ち上げることにより、自動的にロボットシステムを再開するようなことも可能になる。

【0038】

上述した本発明の原理に従う態様において、前記仮想コンテナが起動されている装置が前記クラスタを構成する装置でなくなった場合に、該仮想コンテナを停止させる手段と、前記仮想コンテナを停止させるための手順を、記憶する手段とをさらに備えるようにしてもよい。

【0039】

これにより、例えば、ある条件が満たされたら仮想コンテナを停止させるということを自動的に行えるようになり、クラスタを構成する一部の装置が動作不良のためにクラスタから外れる場合に、そのクラスタに対応する当該装置上の仮想コンテナを自動的に停止する（さらに仮想コンテナを当該装置から廃棄する）ことによって、安全性を高めることが可能になる。

【0040】

上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれがどの装置に配置され、起動中であるか停止中であるかを含めどのような状態であるかを示す情報を収集し、ユーザに表示するサービス又は履歴を記憶するサービスの少なくとも一方へ送信する手段をさらに備えるようにしてもよい。

【0041】

これにより、例えば、ロボットアプリケーション管理装置にローカルエリアネットワーク又は外部ネットワークを介して接続される端末において、ロボットシステムを構成する各装置の状態が一括して表示され、ロボットシステムの開発者や管理者（ユーザ）の負担を軽減することが可能になる。また、ロボットアプリケーション管理装置にローカルエリアネットワーク又は外部ネットワークを介して接続されるストレージにおいて、ロボットシステムに対して行った制御やロボットシステムの動作の詳細ログを保存しておくことが可能になる。これらの端末やストレージは、クラウドを構成しない装置としてよい。

【0042】

上述した本発明の原理に従う態様において、前記クラスタを構成する各装置における各仮想コンテナが前記ローカルネットワークを介して通信できるように、ネットワーク接続を支援する手段をさらに備え、該手段の少なくとも一部は、前記複数種類の仮想コンテナのうちの一つが自装置に配置されて起動されることにより備えられるものであってもよい。

【0043】

これにより、例えば、ロボットシステムを構成する各装置に、手動でネットワーク接続のための設定（時刻同期、アドレス付与、名前解決等）をする作業から、ロボットシステムの開発者や管理者を解放することが可能になる。この設定が行われた各装置上の仮想コンテナ同士の通信については、仮想コンテナランタイム／仮想コンテナオーケストレーションツールの技術により支援してもよい。

【0044】

上述した本発明の原理に従う態様において、前記少なくとも一つのロボット装置は、移動するロボット装置を含み、前記ローカルネットワークのうち少なくとも前記移動するロボット装置への接続部分は、無線で構成されるものであり、前記無線接続のためのアクセスポイント機能又はマルチホップ機能の少なくとも一方をさらに備えるようにしてもよい。

【0045】

このアクセスポイント機能により、移動ロボットと各種装置（センサやコンピュータ）を相互に接続してロボットシステムを構成することが可能になり、マルチホップ機能により、移動ロボットの移動範囲に合わせてフレキシブルに無線ローカルエリアネットワークを張り巡らせることが可能になる。その結果、移動ロボットは、無線の電波到達範囲を気にせずに、動き回ることができる。

【0046】

上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置が備える手段のうちの少なくとも一部を備える少なくとも１つの副ロボットアプリケーション管理装置を、前記クラスタを構成する装置群に含めるようにしてもよい。

【0047】

これにより、主となるロボットアプリケーション管理装置がダウンしても、副ロボットアプリケーション管理装置が代替することで、ロボットシステムが動作を継続することが可能になる。また、副ロボットアプリケーション管理装置を使って、前述の無線マルチホップ機能を展開することが可能になる。さらに、ロボットシステムを複数動かす場合、主ロボットアプリケーション管理装置は共通とし、前述の無線アクセスポイント機能を有する副ロボットアプリケーション管理装置をロボットシステムごとに設置することで、それぞれのロボット装置が近傍のアクセスポイントを利用して無線通信することが可能になる。

【0048】

上述した本発明の原理に従う態様において、前記前記ロボットアプリケーション管理装置が、ローカルエリアネットワークと外部ネットワークとの境界に位置し、前記ローカルエリアネットワークに接続された各装置を前記外部ネットワークから保護する手段をさらに備えるようにしてもよい。

【0049】

これにより、ロボットシステムのためのローカルエリアネットワークを外部ネットワークから分離して、保護する（例えば、ネットワークアドレストランスレーションや、ファイアウォール等の手段を用いる）ことで、セキュリティを高めることが可能になる。例えば、前述の副ロボットアプリケーション管理装置をロボットシステムごとに設置する場合、複数のロボットシステムに共通の主ロボットアプリケーション管理装置に、このネットワーク分離保護機能を設けるとよい。

【0050】

また、このネットワーク分離保護機能を備えるロボットアプリケーション管理装置と、外部ネットワークの向こう側にあるクラウドサービス装置との間を、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を用いて接続するようにすれば、そこでもセキュリティを確保することが可能になる。もしくは、ＨＴＴＰＳやＭＱＴＴＳのような暗号化通信プロトコルを用いて通信するようにしてもよい。

【0051】

上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置が、前記ロボットアプリケーションのために物理的環境のデータを入力するセンサをさらに備え、前記センサを制御する仮想コンテナを、前記複数種類の仮想コンテナのうちの一つとして、自装置に配置して起動させるものであってもよい。

【0052】

これにより、例えば、ロボット装置に搭載されている（移動しながらセンシングする）センサからの情報と、ロボットアプリケーション管理装置に搭載されている（ロボット装置の移動範囲の環境をセンシングする）センサからの情報と、両方を考慮したロボットシステムの制御が可能になる。前述の副ロボットアプリケーション管理装置をロボットシステムごとに設置する場合、当該副ロボットアプリケーション管理装置に、センサを設けてもよい。

【0053】

上述した本発明の原理に従う態様において、前記クラスタを構成する少なくとも一つの装置における少なくとも一つの仮想コンテナが前記ローカルネットワークを介して前記クラスタを構成しない装置と通信できるように、ネットワーク接続のためのアドレスを付与する手段をさらに備えるようにしてもよい。

【0054】

これにより、仮想コンテナ技術を導入した装置とそうでない装置とを混在させてロボットシステムを構成することができるため、ロボットシステムの開発や管理を部分的な仮想化技術の導入から始めることが可能になる。

【0055】

上述したそれぞれの態様は、異なるカテゴリの態様としたり、組み合わせて別の態様としたり、部分的に抜き出して別の態様としたりすることも可能である。例えば、上記の方法を実行するためにシステムを構成するいずれかの装置にインストールされるプログラム、上記のシステムを構成するロボットアプリケーション管理装置以外の装置、当該装置において実行される方法及びその実行のためのプログラム、既述のいずれのプログラムについても当該プログラムを記憶した記憶媒体等、それぞれが本発明の原理に従う一つの態様となり得る。

【0056】

また、上述した本発明の原理に従う態様は、実行する装置の選択に制約がある仮想コンテナの取り扱いを含んでいるが、これを含まない態様に上記に説明したそれぞれの手段等を付加したものも発明（本発明とは独立した発明）になり得るものである。

【0057】

以下には、例示として、本発明の一実施形態に係るシステム（以下、「本システム」という）について、図面を用いて説明する。以下の例においては、仮想コンテナランタイムとしてＤｏｃｋｅｒを用い、仮想コンテナオーケストレーションツールとしてＤｏｃｋｅｒ Ｓｗａｒｍを用いる。

【0058】

図１に例示された本システムは、ロボット（センサやモータ等の物理的要素）と、ロボットシステムの開発やプログラム実行に必要なネットワーク環境構築支援およびプログラム開発・実行環境をローカルネットワーク（ＬＡＮ６００）で提供することを目的としたエッジコンピュータであるロボットアプリケーション管理装置（主）１００と、その少なくとも一部の機能を重複して担うロボットアプリケーション管理装置（副）２００と、その管理・制御対象となり得る複数コンピュータ資源（末端コンピュータ装置）３００、４００とを含んでいる。

【0059】

末端コンピュータ装置Ａ（３００）は、ロボット接続型であり、センサ３０６と駆動装置３０７を搭載している。末端コンピュータ装置Ｂ（４００）は、コンピュータ単体である。ロボットアプリケーション管理装置と末端コンピュータ装置は、仮想コンテナ技術が導入されている装置であり、それぞれが、群実行型論理コンテナ用仮想化環境提供部１０３、２０３、３０３、４０３を備えており、その上で動作する複数の仮想コンテナが連携して、一つのロボットアプリケーションを実行する（一つのロボットシステムを動作させる）。

【0060】

本システムは、仮想コンテナ技術が導入されていないＬＡＮ６００上のコンピュータ装置５００（例えば、スマートフォンやパソコン等）を収容することも可能である。ＬＡＮ６００とインターネット７００とを接続する機能は、本例では、ロボットアプリケーション管理装置（主）１００が備えている。インターネット７００を介して、仮想コンテナ技術が導入されていないコンピュータ装置（ディスプレイ／ストレージ）８００を本システムに収容することも可能である。

【0061】

インターネット７００は、外部のコンピュータ資源（図１の例ではコンピュータ装置８００）にアクセス可能な通信網であればよく、ＬＴＥ等の携帯電話網、公衆ＷｉＦｉ等でもよい。ロボットアプリケーション管理装置（主）１００は、インターネット接続部１０８（例えば、有線ＬＡＮ接続のためのネットワークインタフェースカード等）を備えており、図３の例に示すように、ブロードバンドルータ１０９を介してインターネット７００に接続することができる。

【0062】

なお、図１の例では、ロボットアプリケーション管理装置（主）１００とディスプレイ／ストレージ８００が、インターネット７００を介して接続されているが、ディスプレイ／ストレージ８００をＬＡＮ６００上に設け、本システムをＬＡＮ内に閉じて構成することも可能である。

【0063】

ロボットアプリケーション管理装置と末端コンピュータ装置と仮想コンテナ技術未導入のコンピュータ装置は、それぞれ、ＬＡＮ６００に接続するための通信モジュール部１０１、２０１、３０１、４０１、５０１を備えている。各通信モジュール部は、有線ネットワークを介して接続可能なものでもよいが、少なくとも移動するロボットに直接接続されるコンピュータ装置３００と他の装置との間については、ＷｉＦｉ等の無線ネットワークを介して接続可能なものとすることが好ましい。ＷｉＦｉは、画像、音声、点群等の大容量データを扱え、屋内に強い点でも現実的な選択肢である。

【0064】

さらに、マルチホップＷｉＦｉアクセスポイント環境を提供するためには、ロボットアプリケーション管理装置（主）１００だけでなくロボットアプリケーション管理装置（副）２００も、無線通信基地局提供部１０２、２０２（例えば、Ｗｉｒｅｌｅｓｓ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ（ＷＤＳ）規格準拠の無線ＬＡＮアダプタ等）を備える。ＷＤＳは、無線ＬＡＮの信号を送受信し、かつ中継することで、通信可能な範囲を広げるための機能をサポートする。これにより、電源さえあれば、移動ロボットが移動する範囲を全てＷｉＦｉネットワークでカバーすることが可能になる。

【0065】

ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３は、仮想コンテナオーケストレーションツールのマネージャ機能（Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ）を含み、操作手順台帳記憶部１０５を参照して、ロボットシステムを構成する装置群をクラスタとして束ねて（クラスタリングして）管理する。管理される側の各装置内の群実行型論理コンテナ用仮想化環境提供部３０３、３０４は、仮想コンテナオーケストレーションツールのエージェント機能（Ｄｏｃｋｅｒ Ｓｗａｒｍ Ａｇｅｎｔ）を含んでいる。

【0066】

ロボットアプリケーション管理装置（副）２００の群実行型論理コンテナ用仮想化環境提供部２０３は、仮想コンテナオーケストレーションツールのマネージャ機能を含み、ロボットアプリケーション管理装置（主）１００と機能分担した上で、操作手順台帳記憶部２０５を参照して、ロボットシステムを構成する装置群の管理を行う。ロボットアプリケーション管理装置のコンピュータ資源を、末端コンピュータ装置のコンピュータ資源と同様にロボットアプリケーションの実行に利用することも可能であり、その場合、群実行型論理コンテナ用仮想化環境提供部１０３、１０４は、仮想コンテナオーケストレーションツールのエージェント機能も含む。

【0067】

ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３は、イメージ台帳記憶部（Ｄｏｃｋｅｒレジストリ）１０４も備えており、ロボットシステムを構成する各装置が動作させる仮想コンテナの実体である実行可能なプログラム（Ｄｏｃｋｅｒイメージ）を管理する。ロボットアプリケーション管理装置（副）２００の群実行型論理コンテナ用仮想化環境提供部２０３が、イメージ台帳の全部又は一部を記憶するようにしてもよい。

【0068】

ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３によって、各仮想コンテナの標準出力・標準エラー出力を一箇所に収集することが可能になると共に、一つのコマンドだけで、設定ファイル（操作手順台帳）に記述されたとおりに、ホストマシン（クラスタを構成する装置）を跨いで複数の仮想コンテナを起動・配置・停止することが可能になる。また、後述するように、ステートレスなアプリケーションとすることで、各サービスのスケールアップ・スケールダウンが容易に行えるようになる。

【0069】

また、ロボットアプリケーション管理装置（主）１００の状態表示部１０７は、群実行型論理コンテナ用仮想化環境提供部１０３の働きにより、ホストマシン（クラスタを構成する装置）を跨いで各仮想コンテナで動いているサービスの稼動状態を一覧として取得することが可能になる。この一覧は、ロボットシステムのユーザ等が、ディスプレイ８００等で確認することができる。

【0070】

このように、ロボットアプリケーション管理装置を設けることで、中央集権的に、複数のホストマシンに分散させた仮想コンテナを扱えるようになる。そのため、運用／監視面での最適化が期待できる。

【0071】

さらに、ロボットアプリケーション管理装置（主）１００が、共通情報配信部１０６（図示しない共通情報台帳記憶部を含む）を備えることにより、ロボットシステムのためにネットワーク環境を構築してもよい。このネットワーク環境の構築の少なくとも一部は、ロボットアプリケーション管理装置（主）１００又はクラスタリングされた他の装置上で、仮想コンテナによって実行することも可能である。

【0072】

そのように行われるネットワーク環境の構築には、例えば、時刻同期（ネットワークタイムプロトコルを用いて、自動時刻合わせを行う）、名前解決（ドメインネームシステムを用いて、ホスト名によるアドレス解決を行う）、アドレス付与（ダイナミックホストコンフィギュレーションプロトコル等を用いて、ＩＰアドレスを自動的に付与する）、ディレクトリサービス（ライトウェイトディレクトリアクセスプロトコル等を用いて、アカウント情報の集中管理を行う）等が含まれ得る。そうすると、ロボットアプリケーション管理装置上の仮想コンテナが実行するネットワークアプリケーションにより、例えば、パブリックなＮＴＰサーバへの接続を制限している企業ネットワークにおいてロボットシステムを構築する場合でも、全コンピュータの時刻合わせ等が自動的に行えることになる。

【0073】

また、ロボットアプリケーション管理装置（主）又は（副）が、センサ２０６を備えてもよい。センサ２０６は、例えば、環境センサ、カメラ等の情報収集デバイスであり、複数備えてもよい。これらのセンサは、それぞれのために動作する仮想コンテナにより制御されるようにすることができ、それらの仮想コンテナが連携することで、センサネットワークを構成することもできる。

【0074】

ロボットアプリケーション管理装置には、他にも、ロボットアプリケーション開発環境を備えるようにしてもよい。また、移動するロボットの位置情報を検出する機構や、地図を配信するサーバ機能を備えるようにしてもよい。

【0075】

上述したロボットアプリケーション管理装置は、ＲＯＳが使われる移動ロボットをメインターゲットとすることが可能である。その際、ＷｉＦｉアクセスポイントとして振る舞うのと渾然一体で、ネットワーク・仮想化技術をベースとした環境も提供することができる。

【0076】

図２に例示された本システムでは、ロボットアプリケーション管理装置（主）１００が、インターネット７００を介して、群実行型論理コンテナ用仮想化環境提供部９０３を備えるクラウドサービス装置（例えば、ＩａａＳ）９００に接続し、クラウドサービス装置９００もロボットシステムを構成する装置群の一つとして、仮想コンテナを動作させる。

【0077】

なお、仮想コンテナ技術を導入していない一般的なクラウドサービス（例えば、ＰａａＳ、ＳａａＳ等）を、インターネット７００を介してロボットアプリケーション管理装置（主）１００に接続し、例えば、履歴管理部１０７が通信モジュール１０１から収集したロボットシステムの制御や動作状態に関する情報の全部又は一部を、クラウドサービスが提供するストレージ８００に保存するようにしてもよい。

【0078】

図２の例では、ロボットアプリケーション管理装置（主）１００は、クラウドサービスとロボットの中間で、エッジ機器として働く。ロボットアプリケーション管理装置（主）１００は、ロボットシステムのためのローカルエリアネットワークを、それ以外のネットワークから分離した環境として構築することができるから、レスポンスの速さや通信のセキュリティが要求されるサービスを動かす仮想コンテナは、ローカルエリアネットワーク内に配置し、それ以外のサービスを動かす仮想コンテナは、クラウドサービス装置に配置する等、コンピュータ資源の最適な配分が可能になる。

【0079】

ロボットアプリケーション管理装置（主）１００のインターネット接続部１０８と、クラウドサービス装置９００のインターネット接続部９０８が、ＶＰＮゲートウェイの機能を有するようにすれば、外部のコンピュータ資源を使っても、通信のセキュリティを確保することが可能である。

【0080】

図２の例では、ロボットアプリケーション管理装置（副）２００を設けていないが、これを設けることも勿論可能である。逆に、図１の例で、ロボットアプリケーション管理装置（副）２００を設けない構成とすることも可能である。

【0081】

図３は、本システムを利用して、ロボット装置１（３００−１）用のロボットシステムＡと、ロボット装置２（３００−２）用のロボットシステムＢとが稼働している例を示している。図中、ＷｉＦｉ（ＡＰ）は無線アクセスポイントを、ＷｉＦｉ（ＣＬ）は無線クライアントを意味する。ロボット装置２は、最近傍のアクセスポイントであるロボットアプリケーション管理装置（副）２００−２と無線通信するが、ロボットアプリケーション管理装置（副）２００−１のマルチホップ機能によって、ＷｉＦｉ電波の到達範囲外であるロボットアプリケーション管理装置（主）１００とも無線通信できるようになっている。

【0082】

ここで、例えば、ロボットシステムＡは、ロボットアプリケーション管理装置（主）１００と、ロボットアプリケーション管理装置（副）２００−１と、ロボット装置３００−１と、図示しないコンピュータ装置４００とで構成し、ロボットシステムＢは、ロボットアプリケーション管理装置（主）１００と、ロボットアプリケーション管理装置（副）２００−２と、ロボット装置３００−２と、図示しないコンピュータ装置４００とで構成するといったこと（つまり、動作対象となるホストマシンをクラスタごとに指定すること）が可能である。

【0083】

ロボットシステムＡとロボットシステムＢが、同じ動作をするサービスロボットである場合も、ロボットシステムＡ用の仮想コンテナ群と、ロボットシステムＢ用の仮想コンテナ群は別々に生成され、例えば、コンピュータ装置４００で同じサービスをする仮想コンテナがロボットシステムＡ用とロボットシステムＢ用に２つ動作するということになる。

【0084】

図４は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合の一例を示している。ロボットアプリケーション管理装置（「ＲＤＢ」と表記することがある）１００／２００とそれ以外のコンピュータ装置４００とロボット装置３００という複数のコンピュータ資源上に、仮想コンテナランタイムである「Ｄｏｃｋｅｒ」と仮想コンテナオーケストレーションツールである「Ｄｏｃｋｅｒ Ｓｗａｒｍ」を用いた仮想コンテナによるクラスタリング環境を構築し、ロボット用仮想コンテナ（図中の「ＲＯＳ Ｃｏｎｔａｉｎｅｒ Ｆｏｒ ＲＤＢ−ＡＰＰＳ」）を動かし、ロボットシステムを構築する。

【0085】

図４の例では、クラスタを構成する複数のコンピュータ装置（ホストマシン）のそれぞれの実行装置は、「Ｄｏｃｋｅｒ」「ＲＤＢ−ＡＰＰＳ」「ＲＯＳ Ｃｏｎｔａｉｎｅｒ Ｆｏｒ ＲＤＢ−ＡＰＰＳ」を含んでいる。「ＲＤＢ−ＡＰＰＳ」は、各種ロボット向けに仮想コンテナを個別操作するために「Ｄｏｃｋｅｒ」の上位層で動作するデーモンである。「Ｄｏｃｋｅｒ」及び「ＲＤＢ−ＡＰＰＳ」がインストールされたホストマシンは、図１〜２で説明した「群実行型論理コンテナ用仮想化環境提供部」を備えることになる。

【0086】

ロボットアプリケーション管理装置として働くコンピュータ装置は、「Ｄｏｃｋｅｒ」及び「ＲＤＢ−ＡＰＰＳ」上に、「ＲＯＳ Ｃｏｎｔａｉｎｅｒ Ｆｏｒ ＲＤＢ−ＡＰＰＳ」として、上述したネットワーク環境の構築を行う（ＮＴＰ、ＤＮＳ、ＤＨＣＰ等の機能を有する）共通情報配信部１０６や、ロボット環境のヘルスチェックを行う機能部や、ロボットの稼働状況に関する情報を収集してディスプレイ／ストレージへ送信する状態表示部／履歴管理部１０７や、ロボットアプリケーション開発環境を提供する機能部等を備えるようにしてもよい。これにより、ロボットアプリケーション管理装置をインターネットとサービスロボットの間に設置するだけで、ロボット専用のローカルエリアネットワークと開発支援環境を構築することが可能になる。

【0087】

各ホストマシンにインストールされる「ＲＤＢ−ＡＰＰＳ」は、上述した機能の他に、ロボットハードウェアのドライバ管理等を担うこともできる。例えば、「ＲＤＢ−ＡＰＰＳ」は、そのホストマシン上で仮想コンテナを起動する際に、その仮想コンテナがモータ（アクチュエータ）や各種センサ等のハードウェアに紐づくものであれば、そのハードウェアのバージョンを指定して、ハードウェアを動かすためのドライバをホストマシン上にセットアップすることができるようにする。これにより、デバイスファイルに直接アクセスするため、ハイパーバイザー型と比べてハードウェアとの接続で問題が起こりづらいというコンテナ型仮想化の利点も生かされる。

【0088】

図４の例において、「ＲＯＳ Ｃｏｎｔａｉｎｅｒ Ｆｏｒ ＲＤＢ−ＡＰＰＳ」（図１〜２の仮想コンテナ）は、少なくともその一部を、ロボットシステムのユーザの実装によって作成することができる。ロボットアプリケーション管理装置上のＤｏｃｋｅｒレジストリには、「ＲＤＢ−ＡＰＰＳ」に対応した標準の「ＲＯＳ Ｃｏｎｔａｉｎｅｒ」が配置され、ロボットシステムのユーザは、この標準ＲＯＳコンテナをベースに、Ｄｏｃｋｅｒコンテナを中心としたロボットシステム開発を実施することができる。Ｄｏｃｋｅｒレジストリはまた、完全な同一ＲＯＳ環境をいくつでも瞬時に複製することを可能にする。

【0089】

上述したロボットシステム開発においては、ＯＳやミドルウェアのセットアップが完了したＤｏｃｋｅｒコンテナイメージを、Ｄｏｃｋｅｒレジストリに保存しておき、ロボットアプリケーション開発時に、このコンテナイメージを元に差分のみを実装することで、修正作業の効率化が可能になる。また、一つのＤｏｃｋｅｒイメージにつき一つのパッケージとすることで、環境の汚染を防ぐことが可能である。

【0090】

より詳細には、まず、仮想コンテナイメージ台帳記憶部１０４（「Ｄｏｃｋｅｒレジストリ」）に保存されているテンプレートイメージを利用し、テンプレートイメージからの差分のみを、仮想コンテナ作成手順台帳（「Ｄｏｃｋｅｒｆｉｌｅ」とも呼ばれる）に記述する。そして、このＤｏｃｋｅｒｆｉｌｅを用いて、仮想コンテナイメージを作成するコマンドを実行し、新たに作成されたイメージに名前をつけて、Ｄｏｋｅｒレジストリに保存する。

【0091】

クラスタを構成する各コンピュータ装置（ロボットアプリケーション管理装置と、それ以外のローカルエリアネットワーク内に設置されたもしくはクラウド上に設置されたコンピュータ装置）上の各Ｄｏｃｋｅｒコンテナ（図１〜２の仮想コンテナ）は、ロボットアプリケーション管理装置上に常駐するアプリケーションである「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ」（「群実行型論理コンテナ用仮想化環境提供部」１０３／２０３に含まれる）により統合監視される。

【0092】

各コンピュータ装置には、それぞれ役割を明確にするためのラベルが付与され、各コンピュータ装置の「群実行型論理コンテナ用仮想化環境提供部」（各コンピュータ装置に常駐するアプリケーションである「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ａｇｅｎｔ」を含む）が、付与されたラベルを記憶している。「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ」は、各コンピュータ装置に付与されたラベルを参照して、各仮想コンテナの実行に適したラベルを有するコンピュータ装置（「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ａｇｅｎｔ」）を選択し、タスク割当を行う。

【0093】

これにより、各コンピュータ装置（ノード）や各仮想コンテナ（プロセス）の起動・監視、そこから出る標準出力を、ロボットアプリケーション管理装置において一元的に扱うことが可能になる。よって、ロボットシステムのユーザは、関係するコンピュータ装置がどんなに増えても、あたかも１台のように操ることができる。

【0094】

なお、ここでは、ロボットアプリケーション管理装置がマネージャになる例を説明しているが、クラスタを構成する他のコンピュータ装置がマネージャになることも可能である。その場合、各コンピュータ装置がクラスタに参加する際に、自装置が「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎｅｇｅｒ」として働くのか「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ａｇｅｎｔ」として働くのかを選択する。どちらを選択すべきかは、各コンピュータ装置の「郡実行型論理コンテナ用仮想化環境提供部」が記憶している。

【0095】

さらには、ロボットアプリケーション管理装置を介し、ＶＰＮ、ＨＴＴＰＳ、ＭＱＴＴ等の各プロトコルを使って、ロボットに有用なクラウドサービスが利用できる。例えば、ロボット動作に必要なＳａａＳ（Ｖｉｓｉｏｎ ＡＰＩ、Ｖｏｉｃｅ ＡＰＩ、機械学習等のサービス）を利用することが可能になる。

【0096】

上記のクラウドサービスとして提供されるデータ保全性や可用性の高いストレージ８００上に、ｒｏｓｂａｇ等のダンプデータを保存することも可能である。収集したデータから、ロボット動作の管理に必要な各種データを抽出（フィルタリング）して、保存するようにしてもよい。

【0097】

なお、ロボットアプリケーション管理装置は、Ｄｏｃｋｅｒコンテナをベースとしたロボットシステム開発を強制するものではなく、従来のＲＯＳ開発手法を用いる場合であっても、ロボットアプリケーション管理装置の提供する各種ネットワークインフラ機能等の多くの利便性を享受することができる。また、一部機能のみをＤｏｃｋｅｒコンテナ化することも可能であり、ロボットシステムのユーザの都合に応じて使い分けることができる。

【0098】

図５は、ロボットアプリケーション管理装置１００／２００の無線通信基地局提供部１０２／２０２（ＷｉＦｉアクセスポイント）及び通信モジュール部２０１（ＷｉＦｉクライアント）が、図３で例示したように、マルチホップ機能によってＷｉＦｉ電波の到達範囲を拡張していくための動作の流れの一例を示している。

【0099】

図６は、ロボットアプリケーション管理装置１００の共通情報配信部１０６（もしくはネットワーク環境構築を実行する仮想コンテナ）と、ロボットアプリケーション管理装置２００及び末端コンピュータ装置３００／４００の通信モジュール部２０１、３０１、４０１が協働して、クラスタを構成する複数のコンピュータ装置がローカルエリアネットワークを介して通信できるようにするための動作の流れの一例を示している。

【0100】

図７は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合の動作の流れの一例を示している。本例では、ロボットアプリケーション管理装置１００／２００及び末端コンピュータ装置３００／４００／９００の郡実行型論理コンテナ用仮想化環境提供部１０３、２０３、３０３、４０３、９０３が、一つ又は複数のロボットシステムを実現する一つのクラスタを構成し（クラスタを構成する装置群の情報も「郡実行型論理コンテナ用仮想化環境提供部」に記憶されている）、ロボットアプリケーション管理装置１００／２００上でマネージャが動作し、複数のエージェント上の各Ｄｏｃｋｅｒコンテナをｃｒｅａｔｅ（Ｓ７２）もしくはｄｅｓｔｒｏｙ（Ｓ７６）する。

【0101】

各コンピュータ装置上での各Ｄｏｃｋｅｒコンテナのデプロイ（配置及び起動の指示）は、仮想コンテナ操作手順台帳記憶部１０５に記憶された操作手順（例えば、ｙｍｌ記述）を読み込んで、マネージャが行う（Ｓ７１）。この「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ」によって、配下の（同一クラスタに属する）「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ａｇｅｎｔ」のコンピュータ資源が、ホストマシンを超えて監視（プーリング）され、その上で、仮想コンテナの配置が透過的にマネージメントされる（Ｓ７３）。よって、クラスタに属するある装置が離脱したとき（Ｓ７５）、その装置で稼働していた仮想コンテナのうち、他の装置で継続稼働可能なものについては、移動先の装置への再配置及び起動が行われる。その際、移動元の装置で稼働していた仮想コンテナは、停止され、必要に応じて廃棄される。

【0102】

図８は、Ｄｏｃｋｅｒ技術を利用して本システムを実装する場合の、ロボットアプリケーション管理装置１００の履歴管理部１０７の動作の流れの一例を示している。なお、ロボットアプリケーション管理装置１００の状態表示部１０７の動作例については、図７に示されている（Ｓ７４）。

【0103】

本システムでは、仮想コンテナ技術によるクラスタリング環境下で、何らかの制約がある装置（ロボット等）を含んでいた場合でも、コンピュータ資源を最適に利用するための設計指針に合わせた実装を可能にする機能を提供する。

【0104】

図９は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、実行する装置の選択に制約のある仮想コンテナの配置を実現するための機構の一例を示している。

【0105】

「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ」のデフォルトの動き（アプリケーションのデプロイ自動化ツール）では、コンピュータ資源は透過的に扱われるため、仮想コンテナを実行するホストコンピュータは、マネージャが最適と判断したものが選択される。

【0106】

このとき、以下の場合には、該当する仮想コンテナを、デフォルトで選択されるホストコンピュータに配置するのではなく、意図したホストコンピュータに配置する。

【0107】

１．物理的接続（ＵＳＢ接続等）を伴うアプリケーションの仮想コンテナ。

【0108】

２．ＧＰＵが必要であったり潤沢なメモリが必要であったりと、特定機能を有するコンピュータ資源上での動作が必要なアプリケーションの仮想コンテナ。

【0109】

このように意図したホストコンピュータ上に仮想コンテナを配置するには、図９（ａ）に例示すように、ラベル機能を利用する。「Ｄｏｃｋｅｒ Ｓｗａｒｍ」では、各エージェント（ノード）に、予めラベルを付与しておく（「群実行型論理コンテナ用仮想化環境提供部」に、クラスタセットアップ時に記憶する）。図中では、「environment」というラベル項目に対して「dev，test，prod」というラベルのいずれかが、「storage」というラベル項目に対して「disk，ssd」というラベルのいずれかが付与されている。図示しないが、エッジ機器（上記の特定機能を有するコンピュータ資源としての別の例）であるか否かというラベルが指定される場合もある。

【0110】

そして、アプリケーション実行時には、図９（ｂ）に例示されたｙｍｌ記述を参照して、仮想コンテナがデプロイされる。ｙｍｌ記述には、実行ノードに関するラベルの定義等が記述されており、「service/db/deploy/placement/constraints/node.labels.storage」で指定したラベルと合致するエージェントのみ（この場合「ssd」）が、その仮想コンテナが動作し得るホストマシンとなる。図９（ａ）では、５台存在するエージェントのうち３台がこの条件を満たすホストマシンとなっており、これら３台のうちどれかにのみ「db」というサービスの仮想コンテナがデプロイされる。これによって、動作するホストマシンをコントロールする（特定のノードでのみ動作するようにする）ことが可能となる。

【0111】

ロボットシステムに多く存在する物理的接続の制約の影響範囲を最小限に押さえ込むには、物理的接続の制約がある仮想コンテナを、状態を持たない（ステートレスである）ように作成する（例えば、状態の保持が必要な場合には、仮想コンテナの外部に持たせる等）ことが好ましい。また、ロボットには搭載不可能な（例えば、重量や大容量電源が必要な）コンピュータ資源を分離し、ロボット上のコンピュータ資源の利用は必要最小限に留めることも、ロボットシステムにおける仮想コンテナを作成する際にとるべき設計思想となり得る。

【0112】

図１０は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、クラスタを構成するいずれかの装置（ホストマシン）が動作不良に陥ったら（例えば、「Ｄｏｃｋｅｒ Ｓｗａｒｍ Ｍａｎａｇｅｒ」のハートビートが消失したら）、本システムがそれに対処するためにとる動作の一例を示している。これにより、動作不良に陥ったノードで稼働していた仮想コンテナの再起動、終了オプションの指定、異なるホストマシンでの動作不良に陥ったノードの再起動等が可能になる。

【0113】

まず、動作不良に陥ったノードで稼働していた仮想コンテナについて、定義されているラベルと合致するエージェントが１つしか存在しない場合は（Ｓ９０Ｙｅｓ）、該当のエージェントが回復するまでシステム復帰は不可能である（Ｓ９３）。この場合は、図７における仮想コンテナの停止や廃棄（Ｓ７６）を行うようにしてもよい。

【0114】

但し、この処分対象として割り当てられる仮想コンテナを、状態を持たない（ステートレスな）ものとすることで、エージェントの回復後すぐさま、システムの復帰が実行できる。つまり、「制約に依存する部分」は動作に必要な最小単位で構成すると共に、「制約に依存する部分」と「制約に依存しない部分」は疎結合で動作するという設計指針を守ることにより、少ないダウンタイムでのシステム復帰が可能になる。

【0115】

一方、動作不良に陥ったノードで稼働していた仮想コンテナについて、定義されているラベルと合致するエージェントが２つ以上存在する場合は（Ｓ９０Ｎｏ）、「Ｄｏｃｋｅｒ Ｓｗａｒｍ」の働きにより、当該仮想コンテナはすぐさま、別のエージェント上で起動することができ（Ｓ９１）、ロボットシステムが復帰する（Ｓ９２）。よって、画像処理や動作計画など、どこでも実行できる処理については、どのエージェント上でも動作するようにしておくことで、あるホストマシンがダウンしても、他の既にクラスタを構成しているホストマシンで、プロセスが自動的に再起動されるようになる。

【0116】

但し、見かけ上はすぐに復旧できても、仮想コンテナが状態を持っている（ステートフルな）ものであると、状態がリセットされてしまうことがある。その場合も、状態を仮想コンテナ外部で保持するといった作りとすることで、ダウンタイムのないシステムを実現することが可能である。

【0117】

クラスタを構成するいずれかの装置が、動作不良によりクラスタから離脱することは、それぞれの装置にインストールされる「ＲＤＢ−ＡＰＰＳ」に常駐する機能によって、検出することができる。例えば、末端コンピュータ装置の「ＲＤＢ−ＡＰＰＳ」は、自装置の通信モジュール部を定期的に監視することにより、有効な無線基地局提供部と接続されているかどうかを定期的に確認する。そして、無線基地局との通信が途絶えて一定時間が経過する（通信断が発生する）と、ＲＤＢ−ＡＰＰＳ経由で起動した仮想コンテナ（ロボットアプリケーション）を停止する。

【0118】

一方、ロボットアプリケーション管理装置の「ＲＤＢ−ＡＰＰＳ」は、自装置の無線基地局提供部を定期的に監視することにより、クラスタを構成する装置の一覧（無線経由で接続されている装置の一覧）にある各装置が、有効に接続されているかどうかを定期的に確認する。この一覧は、「ＲＤＢ−ＡＰＰＳ」が記憶しており、定期的な監視結果に基づいて更新する（図１０のＳ９１のように、別の装置がクラスタを構成することになれば、一覧に記憶される装置が変更されることになる）。

【0119】

そして、ロボットアプリケーション管理装置の「ＲＤＢ−ＡＰＰＳ」は、ある装置との通信が途絶えて一定時間が経過する（通信断が発生する）と、例えば、図１０の動作を行う。通信断が発生した装置の代わりに利用可能な装置が存在しなければ、群実行型論理コンテナ用仮想化環境提供部が管理している操作手順台帳に基づき、仮想コンテナ（ロボットアプリケーション）を停止する。その後、上述した定期的な監視により、無線経由で接続されている装置が増加した（通信断が発生した装置もしくはその装置の代わりになる装置が改めて接続してきた）ことを検出して一定時間が経過すると、操作手順台帳に基づき、その接続してきた装置上で、仮想コンテナ（ロボットアプリケーション）を起動させる。

【0120】

ロボットシステムのように「制約があるシステム」の要求を実現しつつコンピュータ資源を最適に利用するための設計指針を要約すると、以下のようになる。

【0121】

Ａ．仮想コンテナオーケストレーションツールによって、ホストマシンを超えてコンピュータ資源がプーリングされており、その上で仮想コンテナの配置がマネージメントされていること。

【0122】

Ｂ．制約があるシステムを、「制約に依存する部分」と「制約に依存しない部分」に分離すること（「制約」とは、仮想コンテナを実行するホストマシンが制限されることを意味する）。

【0123】

Ｃ．「制約に依存する部分」は、動作に必要な最小単位で構成されること。

【0124】

Ｄ．「制約に依存する部分」と「制約に依存しない部分」は疎結合で動作すること（例えば、ＲＯＳのトピック通信モデルを利用する）。

【0125】

この設計指針を実現するための機構とそれに合わせた実装により、コンピュータ資源の一部が利用不可能な状態になっても、他のコンピュータ資源で自動的に代替することが可能になり、システムの一部がダウンしたとしても、他に与える影響を最小限にでき、他のシステムを巻き添えにする連鎖的なダウンを防ぐことができる。また、ダウンした一部のシステムも、条件を満たせば自動的に復旧することができ、制約が及ぼす影響を最小限に押さえ込むことが可能になる。

【0126】

以上では、継続的な開発・運用を実施するネットワークサービスロボット分野に本システムを適用する例を中心に説明したが、本システムは、映像・音声・３Ｄデータ等の大容量のデータを取り扱うＩｏＴ分野や、多機能なＷｉＦｉアクセスポイントとしてのネットワークインフラを提供する分野、クラウドサービスを経由したハードウェア機器のシェアリングエコノミーやそれに伴う課金システム等にも、適用することが可能である。

【0127】

各ホストマシンにインストールされる「ＲＤＢ−ＡＰＰＳ」は、上述した機能の他に、システムに部分的に仮想コンテナ技術を導入するための機能を備えることもできる。これにより、Ｄｏｃｋｅｒの取り扱いに不慣れなユーザでも、コンテナ型仮想化のスモールスタートが可能になり、Ｄｏｃｋｅｒからどうしても認識できない各種ハードウェア接続が必要な場合には、ベアメタル混在環境を許容することが可能になる。

【0128】

図１１は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、本システムにおいて仮想コンテナ技術を導入した装置とそうでない装置とを混在させてシステムを構成するための機構の一例を示している。仮想コンテナ間の連携をするだけでよい仮想コンテナＢの場合は、その仮想コンテナＢを起動する際に、Ｄｏｃｋｅｒ用のプライベートＩＰアドレス（ｅｔｈ０：199.0.2.3）を割り当て、その仮想コンテナＢが配置されているノードのホストＯＳのＩＰアドレス（203.0.113.5）に変換することにより、ローカルエリアネットワークを介した通信を行う。

【0129】

これに対し、仮想コンテナ技術が導入されていない装置との連携が求められる仮想コンテナＡの場合は、その仮想コンテナＡを起動する際に、Ｄｏｃｋｅｒ用のプライベートＩＰアドレス（ｅｔｈ０：192.0.2.6）を割り当てるのに加えて、仮想コンテナＡが配置されているノードのホストＯＳと同じＬＡＮセグメントの未割当のＩＰアドレス（ｅｔｈ１：203.0.113.7）を割り当てる。ｅｔｈ０は、割り当てられたＩＰアドレスを仮想コンテナＡが配置されているノードのホストＯＳのＩＰアドレス（203.0.113.5）に変換して、ＬＡＮを介した通信を行うが、ｅｔｈ１は、割り当てられたＩＰアドレスをそのまま使って、当該ＬＡＮセグメントのデバイス（図１〜２のコンピュータ装置５００）と通信する。

【0130】

上述した機構の実現のためには、例えば、「ＲＤＢ−ＡＰＰＳ」が、自装置上に配置された仮想コンテナの起動を（Ｓｗａｒｍにより自動的に起動されたかユーザにより手動で起動されたかを問わず、また、ロボットアプリケーションの実行開始時に配置されて起動されたか実行中に別の装置から再配置されて起動されたかを問わず）検知するためのアプリケーションを含んでおり、この検知と連動して、以下の処理を実行する。

【0131】

まず、仮想コンテナに付与されたフラグを参照して、ホストＯＳと同じＬＡＮセグメントのＩＰアドレスを割り付けるべき（すなわち、仮想コンテナ技術未導入の装置との連携が求められる仮想コンテナである）か否かを判別する。

【0132】

そして、割り付けるべき場合は、起動した仮想コンテナに、Ｄｏｃｋｅｒ用の仮想インタフェース（ｅｔｈ０）以外の仮想インターフェイス（ｅｔｈ＊）を割り付け、起動した仮想コンテナのホスト名をハッシュして生成した物理アドレス（ＭＡＣアドレス）を割り付け、この物理アドレスと仮想コンテナのホスト名を使ってＤＨＣＰサーバやルータに対してＩＰアドレスの発行を要求し、発行されたＩＰアドレスを仮想インターフェイス（ｅｔｈ＊）に割り付ける。ＩＰアドレスを割り付けた後に、ＬＡＮやＷＡＮへの疎通確認を実施するようにしてもよい。

【0133】

図１２は、複数カメラを搭載した画像検査用移動ロボット（自律走行によって任意の場所に移動して高解像度画像を撮影し、画像解析によって実世界の分析を実施するロボットであり、ここでは「実ロボット」という）に対して、Ｄｏｃｋｅｒの技術を利用して本システムを構築した一例を示している。

【0134】

図１２の例における分散計算システムは、ロボットアプリケーション管理装置（「ＲＤＢ」）と他３台のコンピュータによって構成される。他３台とは、実ロボットに搭載された低消費電力の「Ｃｏｍｐｕｔｅｒ＿Ａ」及び「Ｃｏｍｐｕｔｅｒ＿Ｂ」と、高性能ＣＰＵが動作して計算に特化した「Ｈｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒ」である。各コンピュータは、ＲＤＢによって提供されるＷｉＦｉネットワークによって相互に接続されている。

【0135】

また、各コンピュータには、ロボット向けにコンテナを個別操作するためのデーモン（「ＲＤＢ−ＡＰＰＳ」）が導入されており、各コンピュータ上では，Ｄｏｃｋｅｒコンテナ（「ＲＯＳ Ｃｏｎｔａｉｎｅｒ Ｆｏｒ ＲＤＢ−ＡＰＰＳ」）が稼働する。このＤｏｃｋｅｒコンテナは、標準ＲＯＳコンテナをベースに、ＲＯＳアプリケーションがノード単位でインテグレートされたものである。そして、インテグレートされたＤｏｃｋｅｒコンテナの集合によって、ロボットサービスが提供される。

【0136】

Ｃｏｍｐｕｔｅｒ＿Ａには、ＵＳＢカメラと、移動ロボットと、スピーカーやマイク等のオーディオ機器とが接続されている。これらの物理的接続があるデバイスをＤｏｃｋｅｒコンテナから制御するために、その制御を行う仮想コンテナを、図１２の例では、「Ｄｏｃｋｅｒ Ｃｏｍｐｏｓｅ」を利用して実装している。これは、「Ｄｏｃｋｅｒ Ｓｗａｒｍ」を利用して、コンテナ起動時に指定されるラベル「docker-compose.yml」に応じて実行ノードを選択する機能により実装してもよい。

【0137】

このＣｏｍｐｕｔｅｒ＿Ａ上でデプロイされる仮想コンテナには、例えば、レーザ測距装置（イーサネット（登録商標）接続）動作用コンテナ「urg_node」、複数カメラ（USB接続）動作用コンテナ「usb_cam」、スピーカー・マイク（オーディオジャック接続）コンテナ「audio_common」、移動ロボット（USB接続）ドライバーコンテナ「turtlebot_bringup」がある。「urg_node」は、別のコンピュータに配置して起動してもよい仮想コンテナであるが、「usb_cam」と「audio_common」と「turtlebot_bringup」は、物理的接続があるデバイスを制御する仮想コンテナであるためＣｏｍｐｕｔｅｒ＿Ａに配置して起動する必要がある。

【0138】

実ロボットに搭載される別のコンピュータ資源であるＣｏｍｐｕｔｅｒ＿Ｂ上でデプロイされる仮想コンテナには、例えば、画面（シリアルバス接続）制御用コンテナ「ros_eye」がある。

【0139】

実ロボットとは別の場所に設けられるコンピュータ資源であるＨｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒにデプロイされる仮想コンテナには、例えば、移動ロボットの経路探索計算用コンテナ「amcl」、Ｃｏｍｐｕｔｅｒ＿Ａ上の「usb_cam」により撮影した動画をＨＴＭＬ５に変換するためのコンテナ「web_video_server」、移動ロボットの現在地から充電器までの経路の計算用コンテナ「kobuki_auto_docking」、ＨＴＭＬ５でＲＯＳを扱うためのコンテナ「roswww」及び「ros_bridge_server」、Ｃｏｍｐｕｔｅｒ＿Ａ上の「usb_cam」の画像を圧縮するためのコンテナ「image_transport」、移動ロボットの姿勢（クオタニオン）を計算・公表するためのコンテナ「robot_pose_publisher」、音声合成用のコンテナ「bridge_ojtalk_audio」がある。

【0140】

本例では、物理的接続の制約がある仮想コンテナを、状態を持たない（ステートレスである）ように作成するという観点から、「usb_cam」コンテナが撮影した内容の保存等は、「web_video_server」やimage_transport」等の別のコンテナが実行するようにしており、これらの別のコンテナは、物理的接続の制約がないため、Ｃｏｍｐｕｔｅｒ＿Ａ上ではなく、Ｈｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒにデプロイされている。

【0141】

それ自体もコンピュータ資源であるＲＤＢ上でデプロイされる仮想コンテナには、例えば、ＲＯＳ参加ノードのアドレス解決を行うためのコンテナ「roscore」がある。ＲＤＢのＣＰＵ、メモリ、ディスク等のスペックは、ＲＤＢ上で動作させるＤｏｃｋｅｒコンテナのサービスによって増減すればよく、ＲＤＢに高度な計算を実行させたい場合は、よりスペックの高いコンピュータや、ＧＰＵを搭載したコンピュータを利用するようにすればよい。

【0142】

また、ＲＤＢが、例えば、気温センサと気圧センサと湿度センサとを備えていてもよく、その場合、気温センサを制御するためのＤｏｃｋｅｒコンテナと、気圧センサを制御するためのＤｏｃｋｅｒコンテナと、湿度センサを制御するためのＤｏｃｋｅｒコンテナとが、物理的接続があるデバイスを制御する仮想コンテナであるためＲＤＢに配置して起動する必要があるものとして、ＲＤＢ上にデプロイされることになる。

【0143】

以上、本発明の実施の形態について説明したが、上述の実施形態を当業者が種々に変形、改良、応用等して実施できることは勿論であり、そのような形態も本発明の範囲に含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】