JP7074130B2 - 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム - Google Patents

Description

本明細書で開示する技術は、アプリケーション又はアプリケーションに含まれるプログラムを処理する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに関する。

近年の人工知能（ＡＩ）や自動化技術の進歩は目覚ましく、さまざまな産業分野の作業現場に広く浸透してきている。例えば、ロボットは、例えば複数のリンクとリンク間を接続する関節で構成され、モータなどの関節駆動用のアクチュエータを用いて各関節を駆動することによってロボットは動作する。また、自動走行車は、センサにより車両周辺の情報を検出し、自律的な判断で衝突などを回避することができる。

自律型若しくは適応制御型と呼ばれるロボットなどのシステムは、オペレータやマスタ装置からの指示を待つことなく、自律的若しくは適応的に行動制御を行なう。具体的には、ロボットなどの外部環境や内部状態を常時検証（あるいは、評価、モニタリング）し、外部環境又は内部状態の認識結果が所定の遷移条件に適合する動作を順次起動していくことで、現在置かれている状況に適した振舞いを実現する（例えば、特許文献１を参照のこと）。一方で、システムが複雑化することに伴い、１人の開発者によって開発・製造することが困難なため、複数の開発者によって開発されることが一般的になってきている。複数の開発者によって１つのシステムを開発する際には、以下に示すような幾つかの課題がある。

（１）さまざまな機能を持つセンサなどからの入力を受け、さまざまな態様で使用されるシステムの動作を管理するシステムについて、あらゆる事象を考慮して、事前にテストを行なうことが困難になってきている。
（２）複数の開発者の一部は、Ｌｉｎｕｘ（登録商標）オペレーティング・システム（ＯＳ）に代表されるようにオープンソースにおいて長期間にわたって開発されてきたライブラリなどを組み込んでいることがあり、ソフトウェアの品質管理が困難になってきている。
（３）システムの一部は、開発工程・製品動作確認テストの管理や基準などが異なる開発者によって開発される場合もあり得る。このため、万一、動作確認などが異なることに依拠して、製品動作時に動作不良、誤作動、又はセキュリティ上の課題が見つかった場合に、迅速且つ適切に対処することが以前よりも増して求められるようになってきている。

一方、コンピュータ・システムがアプリケーション・プログラムを実行するとき、プロセッサ上で動作するコンピュータ・プロセス（以下、単に「プロセス」とも呼ぶ）が生成され、ＯＳによって管理される。ロボットのように実時間処理の反応速度の性能が重視される複雑なシステムを開発する目的では、スケジュールされた時間に各プロセスを実行することができるように設計されたリアルタイムＯＳ（ＲＴＯＳ）を使うこともできる。近年のＲＴＯＳにおいては、システム上で動作する複数のアプリケーション・プログラムに応じてＯＳが生成し、管理する個々のプロセス間の通信のために、例えばパブリッシャ／サブスクライバ型の通信モデルを利用することができる（例えば、特許文献２を参照のこと）。

このような通信モデルを用いたＯＳでは、それぞれのアプリケーション・プログラムに応じて生成されるプロセスが、事前に特定の相手側アプリケーション・プログラムに応じて生成されるプロセスを知ることなく通信することが可能である。したがって、システムに新しいアプリケーション・プログラムを追加したり、実行時にアプリケーション・プログラムの一部を変更したりすることが比較的容易である。しかしながら、新しく追加され、実行時に変更されるアプリケーション・プログラムについて、あらかじめ実行性能やセキュリティ上の課題についてテストすることが難しくなるという課題もある。

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

本明細書で開示する技術の目的は、アプリケーション・プログラムを追加することが容易な通信方法を持つＯＳを装備し、アプリケーション・プログラム（又はアプリケーション・プログラムから生成されるプロセス）を所定の方法で他のアプリケーション・プログラム（又はプロセス）と分離して管理することができ、分離して管理されたプロセス間の通信方法により、上述した課題を解決することが可能となる情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。

本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
を具備する情報処理装置である。ここで、前記第１のノードは所定の条件を満たす第１のアプリケーションを前記第１のコンテナにインストールして動作するノードである。前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる。

前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する。また、前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、前記起動部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する。

そして、前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、前記第２のノードが、前記第２のトピックからデータを受信する。

また、前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、前記第１のノードが、前記第１のトピックからデータを受信する。

また、本明細書で開示する技術の第２の側面は、
第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
を有する情報処理方法である。

また、本明細書で開示する技術の第３の側面は、
第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータ・プログラムである。

本明細書で開示する技術の第３の側面に係るコンピュータ・プログラムは、コンピュータ上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本明細書で開示する技術の第３の側面に係るコンピュータ・プログラムをコンピュータにインストールすることによって、コンピュータ上では協働的作用が発揮され、第１の側面に係る情報処理装置と同様の作用効果を得ることができる。

本明細書で開示する技術によれば、アプリケーション・プログラムの新規追加や変更が容易な通信方法を持つＯＳを装備し、アプリケーション・プログラム（又はプログラムから生成されるプロセス）を所定の方法で他のアプリケーション・プログラム（又はプロセス）と分離して管理することができ、分離して管理されたプロセス間の通信方法により、上述した課題を解決することが可能な情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。

なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、制御プログラムの開発環境の一例を模式的に示した図である。 図２は、ネットワークを介した制御プログラムの分散開発環境を例示した図である。 図３は、ロボットを開発対象とする制御プログラムの開発環境を例示した図である。 図４は、自動走行車を開発対象とする制御プログラムの開発環境を例示した図である。 図５は、無人航空機（ドローン）を開発対象とする制御プログラムの開発環境を例示した図である。 図６は、自律動作装置１００の実機に搭載されるハードウェア並びにソフトウェアのアーキテクチャーの構成例を示した図である。 図７は、パブリッシャ／サブスクライバ型通信の仕組みを説明するための図である。 図８は、登録申請するアプリケーション・プログラムのソースコードを例示した図である。 図９は、コンテナ・ゲストを起動させるための処理手順を示したフローチャートである。 図１０は、コンテナ・ホスト１０００内にコンテナ・ゲスト１０１０が起動している様子を示した図である。 図１１は、コンテナ・ゲストを起動する際の処理シーケンス例を示した図である。 図１２は、コンテナ・ホストからコンテナ・ゲストへデータ送信を行なうための処理手順を示したフローチャートである。 図１３は、コンテナ・ゲストからコンテナ・ホストへデータ送信を行なうための処理手順を示したフローチャートである。 図１４は、コンテナ・ホストからコンテナ・ゲストへデータ送信を行なうための処理シーケンス例を示した図である。 図１５は、コンテナ・ネットワークの構成例を示した図である。 図１６は、コンテナ間で共有するトピックをコンテナ毎に変更する仕組みを説明するための図である。 図１７は、仕様に適合しない出力をするアプリケーションの停止と再起動を行なう仕組みを説明するための図である。 図１８は、仕様に適合しない出力をするアプリケーションの停止と再起動を行なうための処理シーケンス例を示した図である。 図１９は、アプリケーションを更新中のゲスト・ノードに関連する送受信データを一時的に保存する仕組みを模式的に示した図である。 図２０は、アプリケーションを更新中のゲスト・ノードに関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示した図である。 図２１は、アプリケーションを更新中のゲスト・ノードに関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示した図である。 図２２は、トピック通信量によるスロットリングの仕組みを説明するための図である。 図２３は、トピック通信量によるスロットリングを行なう処理シーケンス例を示した図である。 図２４は、コンテナを用いたグルーピングにより所定の条件を満たさないアプリケーションを隔離する仕組みを説明するための図である。 図２５は、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例を示した図である。 図２６は、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例（コンテナを用いたグルーピングを利用した例）を示した図である。 図２７は、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例を示した図である。 図２８は、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例（コンテナを用いたグルーピングを利用した例）を示した図である。

以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

図１には、制御プログラムの開発環境の一例を模式的に示している。開発環境下には、制御プログラムによる制御対象となる自律動作装置（実機）１００と、この自律動作装置１００における制御プログラムを作成する開発装置２００が配置されている。

ここで、自律動作装置１００は、自律的若しくは適応制御により自らの行動を制御する装置であり、ロボット、無人航空機、自律運転する自動車などさまざまな形態を含むものとする。

自律動作装置１００は、当該システム１００全体の動作を統括的にコントロールする本体部１１０と、複数のモジュール部１２０－１、１２０－２などで構成される。図１では簡素化のため、３つのモジュール部しか描いていないが、４以上のモジュール部で構成される自律動作装置や、２以下のモジュール部しか備えていない自律動作装置も想定される。

１つのモジュール部１２０は、アクチュエータ１２１と、プロセッサ１２２と、メモリ１２３と、センサ１２４と、通信モデム１２５を含んでいる。なお、簡素化のため図示を省略しているが、モジュール部１２０内の各部１２１～１２５は、内部バスにより相互接続されているものとする。

アクチュエータ１２１は、例えば、関節を回転駆動するためのモータや、スピーカ用のドライバなどである。センサ１２４は、関節回転角度や角速度、スピーカの音量などのアクチュエータの出力状態を検出するセンサや、外力やその他の外部環境を検出するセンサなどである。

プロセッサ１２２は、アクチュエータ１２１の駆動制御（モータ・コントローラ）やセンサ１２４からの検出信号の認識処理を始めとするモジュール部１２２内の動作を制御する。メモリ１２３は、アクチュエータの制御情報やセンサの検出値などを格納するためにプロセッサ１２２が使用する。

通信モデム１２５は、当該モジュール部１２０と本体部１１０、又は当該モジュール部１２０と他のモジュール部の間で相互通信を行なうためのハードウェアであり、無線モデム又は有線モデムのいずれでもよい。例えばプロセッサ１２２は、通信モデム１２５を介して、本体部１１０からアクチュエータ１２１の駆動などの命令信号を受信したり、センサ１２４による検出データを本体部１１０に送信したりする。また、モジュール部１２０は、通信モデム１２５を介して、開発装置２００などの外部装置とも通信を行なうことができる。

本体部１１０は、プロセッサ１１１と、メモリ１１２と、通信モデム１１３と、バッテリー１１４と、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート１１５と、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）１１６を含んでいる。なお、簡素化のため図示を省略しているが、本体部１１０内の各部１１１～１１６は、内部バスにより相互接続されているものとする。

プロセッサ１１１は、メモリ１１２に格納されているプログラムに従って、自律動作装置１００全体の動作を統括的にコントロールする。また、バッテリー１１４は、自律動作装置１００の駆動電源であり、本体部１１０並びに各モジュール部１２０に電源を供給する。

通信モデム１１３は、本体部１２０と各モジュール部１２０の間で相互通信を行なうためのハードウェアであり、無線モデム又は有線モデムのいずれでもよい。例えばプロセッサ１１１は、通信モデム１１３を介して、各モジュール部１２０に対してアクチュエータ１２１の駆動などの命令信号を送信したり、各モジュール部１２０内でのセンサ１２２の検出値に基づく認識結果を受信したりする。また、本体部１１０は、通信モデム１１３を介して、開発装置２００などの外部装置とも通信を行なうことができる。

ＵＳＢポート１１５は、ＵＳＢバス（ケーブル）を使って本体部１１０に外部機器を接続するために使用される。本実施形態では、ＵＳＢポート１１５を使って本体部１１０に開発装置２００を接続することを想定している。例えば、開発装置２００上で作成した制御プログラムを、ＵＳＢポート１１５を介して自律動作装置１００にインストールすることができる。なお、ＵＳＢは自律動作装置１００に外部装置を接続するインターフェース規格の一例であり、他のインターフェース規格に則って外部装置を接続するように構成することもできる。

なお、図示を省略したが、本体部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。

開発装置２００は、例えばパーソナル・コンピュータで構成され、コンピュータ本体部２１０と、液晶パネルなどのディスプレイ２２０と、マウスやキーボードなどからなるユーザ・インターフェース（ＵＩ）部２３０を備えている。また、コンピュータ本体部２１０は、プロセッサ２１１、ＧＰＵ（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１２と、メモリ２１３と、ＵＳＢポート２１４と、通信モデム２１５を備えている。但し、ＧＰＵ２１２の機能がプロセッサ２１１内に含まれている構成例も考え得る。また、コンピュータ本体部２１０は、図示した以外のハードウェア構成要素を備えており、各部はバスにより相互接続されている。

開発装置２００上では、ＯＳが動作している。プロセッサ２１１は、所望のアプリケーション・プログラムをメモリ２１２にロードして、ＯＳによって提供される実行環境下でアプリケーション・プログラムを実行することができる。

本実施形態では、アプリケーション・プログラムの１つとして、自律動作装置１００の制御用プログラムを作成するための開発ツール・プログラムを想定している。この開発ツール・プログラムは、当該プログラムの実行に必要なデータとともに開発装置２００のメモリ２１３上に展開されている。

開発ツール・プログラムは、ディスプレイ２２０の画面にプログラム開発用のＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提示する。プログラムの開発者は、このＧＵＩ画面の内容を確認しながら、ユーザ・インターフェース２３０を介してデータやプログラムの入力を行なうことができる。また、開発ツール・プログラムは、作成した制御プログラムに関するコンパイラ、デバッガ、シミュレーション、３Ｄグラフィックス・アニメーションを用いた制御プログラムの動作確認のための機能などを備えているが、開発者はＧＵＩ画面上でこれらの機能の実行指示を行なうことができる。

開発ツール・プログラムを用いて作成される制御プログラムは、自律動作装置１００の実機上の本体部１１０のプロセッサ１１１上で実行されるコントロール・プログラム並びにコントロール・プログラムが使用するパラメータなどのデータと、各モジュール部１２０のプロセッサ１２２においてアクチュエータ１２１の駆動を制御するためのコントロール・プログラム並びにコントロール・プログラムが使用するパラメータなどのデータで構成される。本明細書ではプログラム部分とデータを併せて「制御（コントロール）プログラム」と呼ぶこともある。

開発ツール・プログラムを使って作成された制御プログラムは、メモリ２１３に格納される。また、メモリ２１３上の制御プログラムを、ＵＳＢポート２１４を介して自律動作装置１００側に転送することができる。あるいは、メモリ２１３上の制御プログラムを、通信モデム２１５を介して自律動作装置１００内のモジュール部１２０に転送することができる。

また、開発装置２００上で開発ツール・プログラムを使って作成された制御プログラムを、３Ｄグラフィックス・アニメーションを用いた開発ツール・プログラムやデータ（以下、開発ツール用のプログラムとデータを併せて「開発ツール・プログラム」とも呼ぶ）を利用して、動作の検証や、制御用のデータやプログラムの修正を行なうことができる。一般に、この種の開発ツール・プログラムは、制御プログラムに従って自律動作装置１００の実機動作の３Ｄグラフィックス・アニメーションを生成する機能を備えており、開発者はディスプレイ２２０に表示される３Ｄグラフィックス・アニメーションを利用して、自身が開発した制御プログラムの動作の検証や、データやプログラムの修正を並行して行なうことができる。

本実施形態では、開発ツール・プログラムが物理エンジンと呼ばれる機能を備えていることを想定している。物理エンジンは、現実の自律動作装置１００の動作を物理法則に基づいて物理現象を演算する機能を持つコンピュータ・プログラムであり、自律動作装置１００が持つ物理的な特性やさらには現実的な外部環境を考慮することによって、現実と同様の動作を生成して、その結果をディスプレイ２２０上に表示する。自律動作装置１００の実機に対し、実機のモータなどの代わりに物理エンジンを使って３Ｄグラフィックス・アニメーション空間中で動作する仮想的な自律動作装置１００のことを仮想機械（３Ｄグラフィックス・アニメーション用のデータを含むコンピュータ・プログラム及びデータ）とも呼ぶ。

例えば、自律動作装置１００がロボットであれば、物理エンジンは、ロボットのアームの各リンクや関節の重量やモーメント、関節駆動用のアクチュエータの特性を考慮しつつ、ロボットを模して造られた仮想機械の制御プログラムの動作において、開発ツール・プログラム上で表現された仮想的な物理環境と仮想機械との物理作用（地面との接地や障害物との衝突など）を物理法則に基づいて計算することによって、あたかもロボットのアクチュエータが実際に駆動しているかのように、仮想機械全体の動作を計算し、ロボットの現実的な動作を仮想機械によって再現した３Ｄグラフィックス・アニメーションをディスプレイ２２０上に表示する。

仮想機械は、物理エンジンと３Ｄグラフィックス・アニメーションを含む開発ツール・プログラム上で動作するようにされた制御プログラム及びデータであり、メモリ２１３に格納されている。望ましくは、実機１００の各モジュール部１２０のプロセッサ１２２で動作する単位で、制御プログラム及びデータがモジュール化されている。仮想機械をあたかも実機のように３Ｄグラフィックス空間上で動作させるために、仮想機械の制御プログラムは、実機１００のプロセッサ（例えば、モータ・コントローラ）１２２の動作に相当する機能を、プログラムの一部として実現する。また、この仮想機械の制御プログラムは、実機１００のモジュール部１２０毎のアクチュエータ１２１（例えば、モータ）に相当する動作を３Ｄグラフィックス・アニメーションで再現する物理エンジン機能を、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）あるいは関数を使って呼び出すようにプログラムされている。さらに物理エンジンにおいて物理計算の際に使用されるデータ（アクチュエータに設定される制御パラメータや、リンクの重量、イナーシャなど）は、制御プログラムとともにメモリ２１３中に格納されており、制御プログラムの実行に伴って、メモリ２１３から読み出され、制御プログラム中で利用される。

また、物理エンジン機能を実現するためのプログラム・モジュールに対して指示を出すためのＡＰＩあるいは関数を、実機すなわち自律動作装置１００側で動作している基本ＯＳが提供するものと同じものとすることにより、開発ツール・プログラムで作成したプログラムを、そのまま実機上のＯＳで動作させることができる。さらに、物理エンジン機能によって実際の物理現象を再現することができるので、開発ツール・プログラムを用いて開発したプログラムを、そのままＵＳＢポート２１４などを介して自律動作装置１００にアップロードして実行させることにより、開発ツール・プログラムで確認した動作を実機上でも実現することができる。

また、開発ツール・プログラムを使って、モジュール部単位に分割して自律動作装置１００の制御プログラムを開発することもできる。この場合も同様に、モジュール部１２０単位で制御プログラムを自律動作装置１００にアップロードすることができる。例えば、モジュール部１２０－１のみハードウェア及び制御プログラムの開発を担当している開発者は、自分の開発装置２００を通信モデム２１５経由で自律動作装置１００の対応するモジュール部１２０－１に接続して、作成したプログラムやデータをモジュール部１２０－１内のメモリ１２３にアップロードすることもできる。

モジュール部１２０単位でハードウェア及びプログラムの開発を複数の開発者又は複数の開発ベンダーで分担することで、分散開発環境下で自律動作装置１００全体の開発を進めることができる。

図２には、ネットワークを介した制御プログラムの分散開発環境を例示している。図２に示す分散開発環境下では、モジュール毎に個別の開発者又は開発ベンダーに開発が委ねられている。但し、図２で言うモジュールは、図１に示した自律動作装置１００のハードウェア構成要素であるモジュール部１２０の他に、自律動作装置１００の制御ソフトウェアのモジュールを指す場合もある。

自律動作装置１００の本体部又はモジュール部単位で制御プログラムの開発を任された各プログラム開発者は、それぞれモジュール開発用コンピュータを用いて、自分が担当する本体部１１０又はモジュール部１２０の制御プログラムを作成する。モジュール開発用コンピュータ上では、例えば上述した開発ツール・プログラムが動作している。各モジュール開発用コンピュータは、ネットワークに接続されている。そして、各プログラム開発者は、それぞれクラウド・サーバ上の共有ストレージ、自分専用のストレージ（すなわち、本体部開発者ストレージ、モジュール部開発者ストレージ）、あるいは専用サーバが備えるストレージにおいて、自己が開発した制御プログラムなどを提供してもよい。また、サーバなどのストレージにアカウントを有する管理者、開発者、顧客、あるいはユーザによって制御プログラムなどが共有されるようにしてもよい。

自律動作装置１００の実機全体の制御プログラム開発を担当若しくは統括する開発者は、ネットワーク経由で本体部１１０及び各モジュール部１２０の制御プログラムの提供を受ける。具体的には、実機全体の開発者が使用する実機プログラム開発用コンピュータは、クラウド・サーバ上の共有ストレージ又は開発者ストレージ、専用サーバ、あるいは各開発者のモジュール開発用コンピュータとの直接通信によって、各々の制御プログラムを受信する。但し、制御プログラムの提供を受けるネットワークは、有線又は無線のいずれで構成されていてもよい。

実機全体の開発者が使用する実機プログラム開発用コンピュータは、図１に示した開発装置２００に相当し、開発ツール・プログラム上で物理エンジンを用いた演算を行ない、且つ、３Ｄグラフィックス・アニメーションにより実機に相当する仮想機械の動作を表示できる機能を備えている。したがって、実機プログラム開発用コンピュータは、本体部１１０及びすべてのモジュール部１２０の制御プログラムを、開発ツール・プログラムが備える物理エンジン機能を利用して、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。

さらに、実機プログラム開発用コンピュータ上では、開発された制御プログラムの実行と並行して、各々の制御プログラムの修正を行なうことができる。したがって、実機１００全体の開発者と各モジュール部１２０を担当する開発者とで、実機１００体の制御プログラムを効率的に共同開発することにもなる。また、実機プログラム開発用コンピュータ上で修正した制御プログラムを、そのモジュール部を担当する開発者に再度提供して、最終的なプログラム製品を完成してもらうことが可能である。例えばクラウド・サーバ上に本体部１１０並びに各モジュール部１２０専用のストレージを配置するなどモジュール部１２０単位で制御プログラムを管理するようにすることで、共同開発を円滑に進めることができる。

実機１００全体の開発者が使用する実機プログラム開発用コンピュータ上で動作が確認・検証された（すなわち、完成した）制御プログラムは、ＵＳＢポート２１４を介して開発装置２００から実機の自律動作装置１００に直接アップロードすることができる。あるいは、有線又は無線で構成されるネットワーク経由で、実機１００全体又はモジュール部１２０毎の制御プログラムを実機１００にアップロードすることもできる。

また、制御プログラムを専用サーバから実機１００へアップロードするという形態も想定される。例えば、ある実機１００のユーザが自分のユーザ端末のユーザ・インターフェース（キーボード、マウス、タッチパネルなど）を介して自分が持つアカウントを用いて専用サーバにログインして、さらに実機１００にダウンロード又はアップロードする制御プログラムを選択して、ダウンロード又はアップロードを実施するようにしてもよい。

図３には、自律動作装置１００の具体例として脚式のロボットを開発対象とする場合の制御プログラムの開発環境を例示している。図３では、単一の開発装置２００を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。

脚式ロボット１００は、本体部１１０と、頭部や左右の脚部に相当するモジュール部１２０を有している。図示を省略するが、本体部１１０と、頭部や左右の脚部などの各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。

なお、脚式ロボット１００は、上肢など図示しないモジュール部をさらに有していてもよい。また、少なくとも一部のモジュール部内のプロセッサやメモリなど機能が本体部と一体となって、本体部のプロセッサによってコントロールされるという実機構成の変形例も考えられる。

本体部は、プロセッサと、メモリと、無線又は有線の通信モデムと、バッテリーと、ＵＳＢポートと、ＧＰＳを備えている。

左右の脚のモジュール部１２０－２及び１２０－３は、アクチュエータとして、股関節や膝関節、足首などの関節駆動用（若しくは、歩行用）のモータ１２１を備え、プロセッサとしてモータの駆動を制御するモータ・コントローラ１２２を備えている。また、センサ１２４として、モータの出力側に発生する外力を検知するトルク・センサや、モータの出力側の回転角度を検出するエンコーダー、足裏部の接地センサなどを備えている。また、頭部のモジュール部１２０－１は、アクチュエータとしての頭部回転用のモータ１２１と、センサとしての周囲を撮像するイメージ・センサ１２４を備えている。

図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の脚式ロボット１００の本体部１１０並びに各モジュール部１２０の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジンの演算を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。

また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、本体部１１０のＵＳＢポート１１５や各モジュール部１２０の通信モデム１２５を介した有線又は無線の通信によって、本体部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、脚式ロボット１００の起動時などに適宜動作するようになっている。

図４には、自律動作装置１００の他の具体例として自動走行車を開発対象とする場合の制御プログラムの開発環境を例示している。自動走行車１００は、自動運転技術が導入された自動車（あるいは、作業用又は輸送用などの無人運転車両）のことであるが、完全自動運転車の他、自動運転モードと手動運転モードを切り替え可能な自動車における自動運転モードで走行中の自動車も含むものとする。図４では、単一の開発装置２００を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。

図４に示す自動走行車１００は、主制御部１１０と、モジュール部としてのトランスミッション制御モジュール部１２０－２並びに室内空調制御モジュール部１２０－１を有している。図示を省略するが、主制御部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バス（ＣＡＮバスなど）が存在する。また、自動走行車１００は、通常、トランスミッション制御モジュール部１２０－２、室内空調制御モジュール部１２０－１以外にも図示しない多くのモジュール部を備えているが、説明の簡素化のため省略する。

主制御部１１０は、プロセッサとしてのＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御装置）１１１と、メモリ１１２と、通信モデム１１３と、ＥＣＵインターフェース１１５と、ＧＰＳ１１６と、バッテリー１１４を備えている。通信モデム１１３は、Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、近距離無線通信などを想定している。また、ＥＣＵインターフェース１１５は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）バス（図示しない）へのインターフェースを想定しており、開発装置２００側とはイーサネット（登録商標）などの通信規格を利用して接続される。

室内空調モジュール部１２０－１は、アクチュエータとしての空調１２１と、プロセッサとしての空調制御ＥＣＵ１２２と、メモリ１２３と、センサとしての室内温度センサ１２４と、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信などの通信モデム１２５を備えている。例えば搭乗者が携帯するスマートフォンなどの情報端末（図示しない）とＢｌｕｅｔｏｏｔｈ（登録商標）通信により接続して、空調を制御することを想定している。

トランスミッション制御モジュール部１２０－２は、アクチュエータとしての駆動輪用モータ１２１と、プロセッサとしてのトランスミッション制御ＥＣＵ１２２と、メモリ１２３と、センサとして速度・加速度センサ１２４や操舵角センサなどを備えている。

なお、図４に示した構成例では、主制御部１１０並びに各モジュール部１２０にＥＣＵが配置されているが、主制御部１１０内のＥＣＵ１１１ですべてのモジュール部１２０を集中管理するように構成することも可能である。

図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の自動走行車１００の主制御部１１０、室内空調制御モジュール部１２０－１、並びにトランスミッション制御モジュール部１２０－２の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジン機能を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。

また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、主制御部１１０のＥＣＵインターフェース１１５や各モジュール部１２０の通信モデムを介した有線又は無線の通信によって、主制御部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、自動走行車１００の起動時などに適宜動作するようになっている。

図５には、自律動作装置１００の他の具体例として無人航空機（ドローン）を開発対象とする場合の制御プログラムの開発環境を例示している。図５では、単一の開発装置を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。

図５に示す無人航空機１００は、主制御部１１０と、モジュール部としてのカメラ制御モジュール部１２０－１並びにプロペラ制御モジュール部１２０－２を有している。図示を省略するが、主制御部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。また、無線航空機１００には、カメラ制御モジュール部１２０－１並びにプロペラ制御モジュール部１２０－２以外のモジュール部が組み込まれていてもよい。

主制御部１１０は、プロセッサ１１１と、メモリ１１２と、通信モデム１１３と、ＵＳＢポート１１５と、ＧＰＳ１１６と、バッテリー１１４を備えている。通信モデム１１３は、Ｗｉ－Ｆｉ、ＬＴＥ、近距離無線通信などの無線モデムを想定しており、操縦者が操作するリモート・コントローラ（図示しない）と通信を行なうようになっている。また、開発装置２００側とはＵＳＢポート１１５を利用して接続され、開発された制御プログラムのアップロードが行なわれる。

カメラ制御モジュール部１２０－１は、センサとしてのカメラ部（イメージ・センサを含む）１２４と、アクチュエータとしてのカメラ部回転用モータ１２１と、プロセッサとしてのモータ・コントローラ１２２と、メモリ１２３と、通信モデム１２５を備えている。カメラ部回転用モータ１２１は、例えば水平方向に３６０度の範囲で回転が可能であり、さらにチルト回転が可能であってもよい。また、通信モデム１２５は、Ｗｉ－Ｆｉ、ＬＴＥ、近距離無線通信などの無線モデムを想定しており、操縦者が操作するリモート・コントローラやスマートフォン（図示しない）からのコマンドに従ってカメラ部１２４の回転や撮影を行なう。

プロペラ制御モジュール部１２０－２は、アクチュエータとして例えば３つのプロペラ（回転用モータを含む）１２１と、プロペラ１２１の回転用モータの制御などを行なうプロセッサ１２２と、メモリ１２３と、センサとしてのプロペラ回転検出センサ１２４を備えている。

図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の無人航空機１００の主制御部１１０、カメラ制御モジュール部１２０－１、並びにプロペラ制御モジュール部１２０－２の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジン機能を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。

また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、主制御部１１０や各モジュール部１２０の通信モデムを介した有線又は無線の通信によって、主制御部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、無人航空機１００の起動時などに適宜動作するようになっている。

図６には、自律動作装置１００の実機に搭載されるハードウェア並びにソフトウェアのアーキテクチャーの構成例を示している。

最下層のハードウェアは、実機１００の筐体内に組み込まれている、本体部（若しくは主制御部１１０と複数のモジュール部１２０などの複数のハードウェア・モジュールからなる。また、各ハードウェア・モジュールを２以上の筐体に分散して配置して構成される実機も存在し得る。

ＯＳは、各ハードウェア・モジュールを直接的に制御する。なお、ＯＳではなく、モジュール部１２０内のメモリ１２３にアップロードされた制御プログラムがハードウェア・モジュールを直接的に制御する場合もある（具体的には、プロセッサ１２２が制御プログラムを実行して、アクチュエータ１２１の駆動を制御する）。

図１などに示したように、本体部１１０と複数のモジュール部１２０でハードウェア・アーキテクチャーが構成される自律動作装置１００においては、本体部１１０（のプロセッサ１１１）において当該システム１００全体を制御するメインのＯＳが動作して、各モジュール部１２０内で実行中の制御プログラムを直接的又は間接的に制御するように構成される。

アプリケーション・プログラムの開発者は、システム（例えば、ミドルウェア）が提供するＡＰＩを用いてアプリケーション・プログラムを開発することができる。また、アプリケーション・プログラムの開発者は、システム・コールを利用してＯＳに対して指示を行なうようなプログラムを含めてアプリケーション・プログラムを開発することができる。ここで言うシステム・コールは、システム制御に関わる機能を利用するためのインターフェースである。システム・コールの例として、モジュール部内のプロセッサ（例えば、モータ・コントローラ）のパラメータを変更する、通信モデムにおけるネットワーク・アドレスの設定を行なう、といったものを挙げることができる。

ロボットや自動走行車、無人航空機といった自律動作装置１００上では「認識」、「状況理解」、「行動計画」、「行動制御」に分類される多数のアプリケーション・プログラムが動作することが想定される。

「認識」アプリケーション・プログラムは、ハードウェア層に含まれるカメラやその他のセンサで取得されるセンサ情報を認識処理するアプリケーション・プログラムである。「状況理解」アプリケーション・プログラムは、「認識」アプリケーション・プログラムによる認識結果に基づいて実機が現在置かれている状況を理解するアプリケーション・プログラムである。例えば、カメラで撮像した画像を分析する画像分析アプリケーション・プログラムは、「状況理解」アプリケーション・プログラムの一例である。なお、ＯＳが提供する実行環境下で動作するアプリケーション・プログラムは「プロセス」（あるいは「スレッド」）としてメモリ上で管理され、プロセッサ（ＣＰＵなど）において実行される。

「行動計画」アプリケーション・プログラムは、「状況理解」アプリケーション・プログラムによって理解される、実機が現在置かれている状況に応じて、実機の行動を計画するアプリケーション・プログラムである。例えば、上記の画像分析アプリケーション・プログラムにより実機の周囲画像を分析した結果に応じて実機の移動経路を選択する経路選択アプリケーション・プログラムは、「行動計画」アプリケーション・プログラムの一例である。

また、「行動制御」アプリケーション・プログラムは、「行動計画」アプリケーション・プログラムによって立案された行動計画を実現するための、ハードウェアの行動若しくは動作をコントロールするアプリケーション・プログラムである。例えば、経路選択アプリケーション・プログラムによって逐次選択される経路に従って、実機の進行方向や進行速度をコントロールするアプリケーション・プログラムや、進行方向や進行速度に応じて、ロボットの脚部や自動走行車の駆動輪、ドローンのプロペラの駆動をコントロールするアプリケーション・プログラムなどが「行動制御」アプリケーション・プログラムに相当する。

ロボットや自動走行車、無人航空機といった自律動作装置１００上で行動又は動作を実現する際には、「認識」、「状況理解」、「行動計画」、「行動制御」に分類されるアプリケーション・プログラム間、若しくはプロセス間でデータ通信を行なう必要がある。

他方、自律動作装置１００上で動作する多数のアプリケーション・プログラムを、装置の開発者、又はその開発者から委託を受けた単一のソフトウェア・ベンダーがすべて開発するのは困難であり、少なくとも一部のアプリケーション・プログラムは第三者からの提供を受けるというのが現実的である。また、図２に示したような分散開発環境下で、これら多数のアプリケーション・プログラムが開発されることが想定される。例えば、自動走行車において開発されるアプリケーション・プログラムを、駆動系制御（ＤＳＵなど）のように高い信頼性が要求されるアプリケーション・プログラムと、ユーザに対するサービスに関わるインフォテインメント（オーディオ機器、インターネット接続サービスなど）や車内環境制御（空調制御など）のようにユーザの利便性のために提供される汎用性の高いアプリケーション・プログラムの２種類に大別すると、前者のアプリケーション・プログラムを自社開発する一方、後者のアプリケーション・プログラムは第三者から提供を受けるようにすることができる。

ところが、「認識」、「状況理解」、「行動計画」、「行動制御」という一連のフローの中で、第三者から提供されたアプリケーション・プログラムが、第三者の故意又は過失により誤ったデータを出力すると、システム全体で障害を発生することが懸念される。

そこで、本明細書では、パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、コンテナに所属する構成ユニット（アプリケーション・プログラムなど）又は構成ユニットに含まれるソフトウェアの所属するコンテナ内に通信を制限する技術について、以下で提案する。この技術によれば、構成ユニット開発における独立性を維持しつつ、構成ユニット又は構成ユニットに含まれるソフトウェアの任意のグルーピングが可能である。

また、本明細書では、同一のソースからの情報に対し、構成ユニット毎に割り当てる特性に応じた加工（例えば、構成ユニットのセキュリティ・レベルに合わせて情報を劣化する）を施した上で送信する技術についても、以下で併せて提案する。

また、本明細書では、更新・追加された構成ユニットに含まれるソフトウェアがシステム動作中に誤作動を起こした場合には、その誤作動を検出し、システム動作を継続させながら、誤作動を起こしたソフトウェアを更新・追加する前に動作が保証されていたソフトウェアの動作に切り替える技術についても、以下で併せて提案する。

また、本明細書では、更新中の構成ユニットに関連する送受信データを一時保存し、更新後に一時保存した送受信データから接続を再開することで、構成ユニットや構成ユニットに含まれるソフトウェアを安全に更新・追加する技術についても、以下で併せて提案する。

また、本明細書では、構成ユニットが送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現し、マルチテナント（構成ユニットを複数の業者に提供する場合）においても、各々に均等なネットワーク・リソースを配分する技術についても、以下で併せて提案する。

本実施形態において適用される、パブリッシャ／サブスクライバ型の通信モデルでは、メッセージを作成して送信する送信側のクライアント（プロデューサー）をパブリッシャと呼び、メッセージを受信する側のクライアント（コンシューマー）をサブスクライバと呼ぶ。パブリッシャは、誰に対して送るかは考えず、取り敢えずサーバに対してメッセージを発行する（パブリッシュする）。一方、サブスクライバは、サーバに対してメッセージ購読を申し込む（サブスクライブする）。そして、パブリッシャから送信されたメッセージの種類や属性を参照して、そのメッセージを欲しがっているサブスクライバに対して配信される。パブリッシャとサブスクライバはお互いを意識する必要がなく、また、サブスクライバは自分が必要とするメッセージのみを受け取ることができる。

また、「トピック」と呼ばれる名前付きの論理チャネルを指定する非同期通信を行なう形態を、トピック・ベースのパブリッシャ／サブスクライバ型通信と呼ぶこともできる。パブリッシャから送信されたメッセージは、サーバ（マスタ）内で、トピックという送信先に登録される。そして、サーバは、パブリッシャが送信したメッセージに付与されているトピックと、サブスクライバによって受信登録されているトピックとのマッチングを行ない、そのトピックに対して配信を申し込んだ（すなわち、サブスクライブした）サブスクライバに配信する。なお、１又は複数のパブリッシャからのメッセージを、１つのトピックに登録することができる。また、１又は複数のサブスクライバが同じトピックに登録することができる。サブスクライバは、登録したトピックから、複数のパブリッシャのメッセージを受信することができる。同じトピックに登録した複数のサブスクライバが、そのトピックから同じメッセージを受信することができる。

ここで、本明細書で使用する各用語「コンテナ」、「ノード」、「プロキシ」、「マスタ」、及び「トピック」について説明しておく。

コンテナ：
コンテナは、仮想ＮＩＣ（ネットワーク・インターフェース・カード）によって論理的に分離されるアドレス又は名前空間、あるいは、それぞれのＮＩＣなどによって物理的に分離される名前空間である。コンテナは、ネットワーク・セグメントとして分離されるシステムの管理領域と捉えることもできる。コンテナには、「コンテナ・ホスト」と「コンテナ・ゲスト」の２種類がある。コンテナ・ホストは、信頼性のあるホスト・ノードのみが動作する空間である。一方、コンテナ・ゲストは、ホスト・ノードと分離しておく必要のあるゲスト・ノードのみが動作する空間である。例えば、第三者から提供されるアプリケーション・プログラムやライブラリ・プログラムをホスト・ノードから分離する必要があり、コンテナ・ゲストで動作させる（以下では、「アプリケーション・プログラム」及び「ライブラリ・・プログラム」をそれぞれ単に「アプリケーション」、「ライブラリ」と表記する）。また、動作保証や認証などにおいて信頼性が確保されていないアプリケーションやライブラリをホスト・ノードから分離する必要があり、コンテナ・ゲストで動作させる。なお、本明細書中では、２つのものが各々から独立して存在するという意味で「分離」という用語を主に使うが、「隔離」という用語を使うこともあり、「分離」の意味は「隔離」を含むものとする。

ノード：
ノードは、アプリケーション、若しくは、コンテナ内でアプリケーションが動作するプロセスに相当する（以下、プログラム・コードとしては「アプリケーション」と呼び、システムのプロセッサによって実行されるプロセスとしては「ノード」と呼ぶことにする）。ノードは、自分が帰属するコンテナのマスタに対して、「トピック」と呼ばれる名前付き論理チャネルを指定してサブスクライブ要求又はパブリッシュ要求を送信する。そして、接続可能な相手が見つかる場合（具体的には、マスタにおいて、接続希望相手とのマッチングがとれる場合）には、通信相手のＩＤ情報（プロセスＩＤなど）を取得することにより、パブリッシャ／サブスクライバ型のメッセージング、及び、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）による一方向通信を行なうことができる。ノード（アプリケーション）は、新たなアプリケーションの開発者向けに、アプリケーション名と、アプリケーションが提供するトピック名、あるいはアプリケーションがデータをサブスクライブ又はパブリッシュのいずれを行なうのか、という情報をＡＰＩとして公開する。

ノードは、「ホスト・ノード」と「ゲスト・ノード」に分類することができる。ホスト・ノードは、信頼性があるアプリケーション又はライブラリが、コンテナ・ホスト内で動作するプロセスである。一方、ゲスト・ノードは、第三者から提供されるアプリケーションやライブラリ、あるいは信頼性が確保されていないアプリケーションやライブラリなどが、コンテナ・ゲスト内で動作するプロセスである。以下では、処理フローの説明などにおいて「ホスト・ノード」と言う代わりに「コンテナ・ホスト」を使用し、「ゲスト・ノード」と言う代わりに「コンテナ・ゲスト」と記載することもある。この場合には、処理フローにおいて、「ホスト・ノード」と「ゲスト・ノード」が、それぞれの属する「コンテナ・ホスト」又は「コンテナ・ゲスト」の一部として通信処理などを行っていることに留意されたい。

プロキシ：
プロキシ（プロキシ・ノード）は、以下の項目（ａ）～（ｄ）のマッピング・テーブルを管理する。プロキシの基本機能はノードに順ずるが、コンテナ・ゲストのマスタと通信する場合には、コンテナ・ゲストのアドレスを指定してネットワーク越しの通信を行なう。

（ａ）コンテナ・ホスト内のノード（サブスクライブ・ノード、パブリッシュ（アドバタイズ）・ノード）が指定できるトピック識別子
（ｂ）コンテナ・ゲスト内のノード（サブスクライブ・ノード、パブリッシュ（アドバタイズ）・ノード）が指定できるトピック識別子
（ｃ）コンテナ・ゲストのアドレス（例えば、ＩＰアドレス（一般的には、ＵＲＩ（ＵＲＬ）でもよい））
（ｄ）コンテナ・ゲストの認証状態（ｖｅｒｉｆｉｃａｔｉｏｎ）やセキュリティ・レベル、サブスクライバのプログラム更新処理を行なう間に送受信されるデータ

マスタ：
マスタは、コンテナ内のノードからのサブスクライブ要求並びにパブリッシュ要求を受信し、トピック毎にノードの対応関係（すなわち、サブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードとの対応関係）を管理する。そして、マスタは、同じトピックに関してサブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードが揃った場合は、それぞれのノード（少なくとも、送信側であるパブリッシュ（アドバタイズ）・ノード）に対して、相手（受信側であるサブスクライブ・ノード）のＩＤ（プロセスＩＤ、プログラム名、通信先（ＩＰアドレス、ポートなど）など）を伝え、ノード間（ノードとプロキシ間を含む）のパブリッシャ／サブスクライバ型のメッセージング及びＲＰＣを開始させる。

マスタは、「ホスト・マスタ」と「ゲスト・マスタ」に分類することができる。ホスト・マスタはコンテナ・ホスト内で動作するマスタであり、ゲスト・マスタはコンテナ・ゲスト内で動作するマスタである。

トピック：
トピックは、メッセージをサブスクライブあるいはパブリッシュ（アドバタイズ）するノードで共通の名前付き論理チャネルを持ったデータ用の通信経路を作るために使われる、以下のような名前若しくは識別子（ＩＤ）である。ここで、コンテナ・ゲスト名は、ゲスト・アプリケーションの登録時に作成される。

トピック名（ＩＤ）＝“／”＋名前付き論理チャネル名
コンテナ・ゲスト用のトピック名＝“／”＋コンテナ・ゲスト名＋“／”＋名前付き論理チャネル名

アプリケーション動作環境としてのコンテナの利用
次に、アプリケーションの動作環境としてコンテナを利用する場合について説明する。

ある自律動作装置１００（例えば、ロボットや自動走行車、無人航空機（ドローン）など）向けに、自律動作装置１００上で動作する他のアプリケーションとともに動作する新たなアプリケーションを開発した開発者は、開発したアプリケーションをサーバに登録する。そして、開発したアプリケーションをコンテナと呼ばれる外部から論理的に分離されるアドレス又は名前空間からなる隔離された空間にインストールして、自律動作装置１００上で動作させることができる。

コンテナにインストールされたアプリケーションは、ノードと呼ばれるプロセスとして動作する。上述したように、コンテナは、コンテナ・ホストとコンテナ・ゲストに分類される。

コンテナ・ホストは、信頼性のあるホスト・ノードのみが動作するように設けられた空間である。例えば、以下に示すような所定の条件を満たすアプリケーションがコンテナ・ホストにインストールされ、ホスト・ノードとして動作する。

・自律動作装置１００本体の開発者によって開発されたアプリケーション
・一定以上のセキュリティ・レベルを持つアプリケーション
・動作検証済みのアプリケーション

また、コンテナ・ゲストは、ホスト・ノードと分離しておく必要があるゲスト・ノードが動作するように設けられた空間である。例えば、上記のホスト・ノードとしての所定の条件を満たさないが、例えば以下に示すような所定の単位でグループ化されたアプリケーションが、コンテナ・ゲストにインストールされ、ホスト・ノードと分離して（コンテナ・ホストから独立して）、ゲスト・ノードとして動作する。コンテナによるグルーピング方法によって、アプリケーション開発における独立性を維持することができる。

・製造委託をしているソフトウェア会社単位のグループ
・第三者が製造したアプリケーション単位のグループ
・セキュリティ・レベルが一定以下のアプリケーションのグループ
・動作未検証のアプリケーションのグループ

上記の所定の条件を満たすアプリケーションをコンテナ・ホストにインストールし、各々がホスト・ノードとして動作することで、まとまりのあるノード間のグループ通信が実現する。すなわち、コンテナ・ホスト内のノード間では、パブリッシャ／サブスクライバ型通信の仕組みを利用してデータの送受信が行なわれる。上述したように、パブリッシャ／サブスクライバ型通信では、ノードは、マスタと呼ばれるプロセスを介して、他のノードと通信することができる。この際、ノード間で通信するための通信経路として、所定のトピック名を指定することができる。トピック名を指定した通信は、名前の付いた通信路を用いた通信に相当する。

パブリッシャ／サブスクライバ型通信の仕組みを利用したデータの送受信方法について、図７を参照しながら説明する。同図において、コンテナ・ホスト７００内に、パブリッシャ７０１及びサブスクライバ７０２となる各ノードと、マスタ７０３が動作している。

まず、送信側であるパブリッシャ７０１は、アドバタイズとして、トピック名“ｂａｒ”と、自分のＩＤとしてホスト名（ｆｏｏ）とポート番号（１２３４）の組み合わせからなる情報“ｆｏｏ：１２３４”を、マスタ７０３に登録する（Ｓ７１０）。

また、受信側であるサブスクライバ７０２は、サブスクライブとして、マスタ７０３に対して、トピック“ｂａｒ”の配信元の情報（ＸＭＬ／ＲＰＣ ＵＲＩ）を要求する（Ｓ７１１）。

マスタ７０３は、トピック“ｂａｒ”に関してサブスクライブ・ノードとパブリッシュ・ノードが揃ったので、サブスクライバ７０２に対して、配信元であるパブリッシャ７０１の情報として、“ｆｏｏ：１２３４”を通知する（Ｓ７１２）。

サブスクライバ７０２は、マスタ７０３からの通知を受けると、パブリッシャ７０１に対して、ＴＣＰソケット通信によるトピック名“ｂａｒ”の購読要求（ｃｏｎｎｅｃｔ（“ｂａｒ”，ＴＣＰ））を送信する（Ｓ７１３）。

これに対し、パブリッシャ７０１は、購読用のＴＣＰサーバのＵＲＩ（ｆｏｏ：２３４５）を通知する（Ｓ７１４）。

そして、サブスクライバ７０２は、購読用のＴＣＰサーバに対して、トピック名“ｂａｒ”の購読のための接続を要求（ｃｏｎｎｅｃｔ（ｆｏｏ：２３４５））する（Ｓ７１５）。

これに応答して、購読用のＴＣＰサーバ（ｆｏｏ：２３４５）からサブスクライバ７０２へ、トピック名“ｂａｒ”のトピックのＴＣＰ／ＩＰによる配信が行なわれる（Ｓ７１６）。

トピック配信には、トピックの名前空間を共有するためのマスタ７０３への通信と、実際のデータ送受信のためのノード（すなわち、パブリッシャ７０１とサブスクライバ７０２）間のＰ２Ｐ通信を通す必要がある、という点に留意されたい。

例えば、コンテナ・ホスト内に、データを提供する機能を持つ第１のノードと、データを利用して処理を行なう第２のノードが動作しているとする。具体的には、第１のノードはカメラの撮像画像を提供するアプリケーションであり、第２のノードは３次元マップを生成するアプリケーションである。

第１のノードは、マスタに対して、「画像」というトピック名を指定して、データ送信（パブリッシュ又はアドバタイズ）の要求を送信する。一方、第２のノードは、マスタに対して、「画像」というトピック名を指定して、データ受信（サブスクライブ）の要求を送信する。ここで、パブリッシュ（又は、アドバタイズ）の要求とサブスクライブの要求は、どちらが先でもよく、また同時でも構わない。

マスタは、同じトピック名「画像」に関してサブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードが揃ったので、パブリッシュ・ノードである第１のノードに対してはサブスクライブ・ノードである第２のノードのＩＤ（又は、名前あるいは送信先情報）を通知し、サブスクライブ・ノードである第２のノードに対してはパブリッシュ・ノードである第１のノードのＩＤ（又は、名前あるいは送信先情報）を通知する。これによって、第１のノードと第２のノードの間では、トピック名「画像」のデータの送受信を行なうことができるようになる。

「画像」のようなトピック名は、システムにインストールされる各アプリケーション（若しくは、コンテナ・ホスト内で動作するホスト・ノード）にとっては、通信用インターフェースの役割を果たす。以下の表１に示すように、アプリケーション毎に関連するトピック名を定義して、言わばインターフェース情報として開発者向けに開示するようにすれば、新たなアプリケーションの開発者は、他のアプリケーションにデータを提供することを前提としたアプリケーションや、他のアプリケーションが提供するデータを受信することで処理を行なうようなアプリケーションの開発が容易になる。

上記の表１のような情報は、例えば、開発者向けの開発ツール・プログラムに関連付けられたデータベースにおいて管理するようにすることができる。このようなデータベースは、開発ツール・プログラムが動作するコンピュータ（例えば、図１中の開発装置２００）の管理下にあるストレージに格納して管理するようにしてもよいし、図２に示したようなネットワーク上に存在するサーバに関連付けられたコンピュータあるいはストレージに格納して管理するようにしてもよい。開発ツール・プログラムは、アプリケーションの開発中のユーザに対して、アプリケーション名を選択することで、関連するトピック名を表示するようにすることができる。

開発ツール・プログラムに関連付けられたデータベースにおいて、アプリケーションで使われるトピック名を管理することにより、アプリケーション用のプログラム開発を効率化することができる。

一例として、プログラムの開発者がプログラム開発環境で、プログラム編集画面上において、キーボードから、以下の文字列を入力しているとする（プログラムの入力途中であるため、「閉じ括弧“）”」が意図的に記載されていないことに留意されたい）。

Ｒｅｇｉｓｔｅｒ＿Ｉｍａｇｅ （“カメラ画像アプリケーション”

開発ツール・プログラムには、表１に示したような情報がデータベース化して管理されている。ここで、「カメラ画像アプリケーション」というアプリケーション名がプログラム編集画面上で入力されているときに、開発ツール・プログラムがデータベースの登録アプリケーション名を認識し、「カメラ画像アプリケーション」という文字列を、例えば下線や色付け、反転するなどの方法によってハイライト表示するようにすることができる。

ここで、ユーザがハイライト表示された「カメラ画像アプリケーション」という文字列を、例えばマウスのようなポインティング・デバイスを用いてクリック（選択）操作したことに応答して、そのアプリケーション名に対して関連付けられた「パブリッシャ（データ送信）用トピック名：画像」などの情報を、文字列「カメラ画像アプリケーション」から至近の位置に表示する。さらに、ユーザがトピック名「画像」が表示された場所を、再度マウスのようなポインティング・デバイスで選択すると、オート・コンプリーションの機能によって、下記のように入力することができ、開発効率を向上させることができる。

Ｒｅｇｉｓｔｅｒ＿Ｉｍａｇｅ （“カメラ画像アプリケーション”、“画像”

開発者によるアプリケーションの登録
次に、コンテナ・ゲストを例として、新規アプリケーション開発者によるアプリケーションの事前登録申請について説明する。

アプリケーションの事前登録申請に際して、まず、所定の事項を記載した登録申請用フォームを、登録申請処理用サーバに送信することにより、登録を完了する必要がある。登録申請用フォームには、少なくとも、新規アプリケーション名とホスト・アプリケーション名を記載する必要がある。他に申請により登録することができる情報としては、例えば、アプリケーションの開発者名（製造者名）、第三者機関が発行する認証情報、セキュリティ・レベル、開発されたアプリケーションの機能説明などが挙げられるが、これらに限定されるものではない。

次に、アプリケーション申請用サーバに対して、開発したアプリケーションの登録申請を行なう。本実施形態では、サーバ上で動作する「プロキシ・マネージャ」というプロセスが、このアプリケーション申請の受信処理を行なうものとして説明する。プロキシ・マネージャへの申請が受理されると、新しいアプリケーションに対して、新規コンテナ名（新規のコンテナ・ゲストの名前）と、公開されたトピック名が割り当てられ、他の登録情報とともにプロキシ・マネージャに関連付けられたデータベースに登録される。申請受理時に割り当てられるトピック名は、コンテナ・ホスト中のアプリケーションとコンテナ・ゲストで動作するアプリケーションに対応するノードが他のアプリケーションに対応したノードとの間でデータ送受信を行なうために、利用することができる。以下の表２には、新しいアプリケーションに対して割り当てられ、データベースに登録される情報を例示している。

コンテナ名は、アプリケーションの申請時にプロキシ・マネージャによって割り当てられるという実施例の他に、コンテナ名を事前に割り当てるようにしてもよい。例えば、開発者が、アプリケーションの開発に先立ち、事前に開発者（製造者）登録を行なうことで、登録された開発者名（製造者名）に対してあらかじめコンテナ名を割り当てるようにしてもよい。コンテナ名が事前に割り当てられている場合には、上記のアプリケーション申請時に、事前に割り当てられたコンテナ名を申請用フォームに記載し、新規登録したアプリケーションとともに関連付けてプロキシ・マネージャに関連付けられたデータベースで管理するようにすることができる。

アプリケーションの開発者は、開発済みのアプリケーション・プログラムを、登録された情報（表２を参照のこと）とともに構築することによって、アプリケーションのソースコード中にある“［登録トピック名］”を、“［コンテナ名］／［登録トピック名］”で置き換えることによって、システム上の所定のコンテナ・ゲストで動作するアプリケーション・プログラムのコードを生成することができる。なお、プログラム開発環境におけるプログラム編集画面上において、キーボードから文字列を入力している際に、開発支援のために、アプリケーション名に対して関連付けられた情報を、入力文字列から至近の位置に表示する例を示したが、このような開発支援も、表２のような登録申請情報が登録されたデータベースの情報を、プログラム開発環境に提供可能にすることによって実現できる。

例えば、図８に示す、登録申請するアプリケーション・プログラムのソースコード中の８行目には、以下のようなコードがある。

ここで、ａｄｖｅｒｔｉｓｅは、このコードが、データ送信を行なうノードとして、“［登録トピック名］”のトピックを指定して、他のノードに対してデータ送信を要求するプログラム上の手続（ｐｒｏｃｅｄｕｒｅ）である。図８に示すアプリケーションが、表２に示す情報が登録されたアプリケーションに対応するプロセスであり、コンテナ・ゲストでゲスト・ノードとして動作する場合、８行目の命令は、このノードがパブリッシュ（データ送信）を行なうことを示している。

この場合の他のノードはサブスクライバ（データ受信）である。よって、表２に示した登録情報のうち、「サブスクライバ（データ受信）用トピック名の項目に対応する、「認識結果」が、"［登録トピック名］"としてプログラムされていることになる。したがって、表２に示した登録情報を用いてプログラムのソースコードを編集し、構築することにより、８行目のコードは以下のように変更されて（"［登録トピック名］"が"／プロキシＡ／認識結果"に書き換えられて）、プログラム・コードを生成する。

このようにして、プロキシ・マネージャに登録したトピックを、新規登録するアプリケーション・プログラムのソースコード中に容易に挿入することができる。すなわち、ユーザ（アプリケーションの開発者）が、登録申請情報の一覧を意識することなく、登録申請情報に基づいて、コンテナ・ゲスト上で動作するアプリケーション・プログラムを構築することができる。

パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、所定の条件を満たさないアプリケーションを、コンテナ・ホスト上で動作するホスト・ノードとは分離して動作させる。これによって、第三者から提供されたような（所定の条件を満たさない）アプリケーション・プログラムから、第三者の故意又は過失により誤ったデータが出力されても、システム全体で障害が発生しないように隔離することができる。

コンテナ・ゲストとプロキシの起動処理
システム（若しくは、ＯＳ）のブート処理では、システム上にはメモリから読み込まれたコンテナ・ホストが設定され、コンテナ・ホスト上には、所定の条件（前述）を満たすアプリケーションがインストールされ、ホスト・ノードとして動作する。言い換えれば、システムの初期状態では、信頼性のあるホスト・ノードが動作するコンテナ・ホストのみが設定されている。

所定の条件を満たさないアプリケーションを、コンテナ・ホスト上で動作するホスト・ノードとは分離して動作させるためには、このようなアプリケーションをインストールするためのコンテナ・ゲストを起動する必要がある。

コンテナ・ゲストの起動は、アプリケーション・ランチャ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｕｎｃｈｅｒ）という役割を持った管理プロセスが実行する。アプリケーション・ランチャは、起動したコンテナ・ゲストへのＩＰアドレスの割り当てなど、コンテナ用の仮想ネットワーク管理も行なう。実際にコンテナの仮想ＮＩＣにＩＰアドレスの値を設定するのはプロキシ・マネージャであるが、各コンテナ・ゲストに割り当てるＩＰアドレスの管理（ＤＨＣＰサーバに類似する処理）はアプリケーション・ランチャが行なう。

図９には、コンテナ・ゲストを起動させるための処理手順をフローチャートの形式で示している。ここでは、システム上には、既にコンテナ・ホストの設定が完了し、コンテナ・ホスト上で１以上のホスト・ノードが起動しており、さらにプロキシ・マネージャが起動していることを想定している。

ユーザ（アプリケーションの開発者など）からコンテナ・ゲストの起動が要求されると、まず、アプリケーション・ランチャは、コンテナ・ゲスト用の仮想ネットワークが作成されているかどうかをチェックする（ステップＳ９０１）。

まだコンテナ・ゲストが読み込まれておらず、コンテナ・ゲスト用のネットワークが作成されていない場合には（ステップＳ９０１のＮｏ）、以下の処理Ｓ９０２－１～Ｓ９０２－２により、コンテナ・ゲスト用の仮想ネットワークを作成する（ステップＳ９０２）。

Ｓ９０２－１）仮想ブリッジを作成する（ｂｒｃｔｌ ａｄｄｒコマンド）。
Ｓ９０２－２）仮想ブリッジにＩＰアドレスなどのネットワーク設定をする（ｉｐ ａｄｄｒコマンド）。

続いて、仮想ブリッジに対して、仮想ブリッジのＩＰアドレスへのアクセス以外の全通信を拒否するファイアウォールを設定する（ｉｐｔａｂｌｅｓコマンド）（ステップＳ９０３）。ステップＳ９０２及びＳ９０３の処理により、コンテナ・ゲストは、他のコンテナ（例えば、コンテナ・ホストや、他のコンテナ・ゲスト）との間で、直接的な通信を行なうことを不可能にさせられる。

コンテナ・ゲスト用の仮想ネットワークが既に作成されている場合（ステップＳ９０１のＹｅｓ）、あるいは、コンテナ・ゲスト用の仮想ネットワークが作成されていない場合であって（ステップＳ９０１のＮｏ）、上記ステップＳ９０２及びＳ９０３の処理を経てコンテナ・ゲスト用の仮想ネットワークが作成された後に、コンテナ・ゲスト用の仮想ＮＩＣを作成するとともに、コンテナ・ホスト側でもコンテナ・ゲスト用の仮想ＮＩＣと対向する仮想ＮＩＣを作成する（ステップＳ９０４）。例えば、コンテナ・ゲスト用の仮想ＮＩＣのＩＰアドレスは、１９２．１６８．９１．０／２４であり、コンテナ・ホスト側でこれに対向する仮想ＮＩＣのＩＰアドレスは１７２．１６．１０．０／１６であるとする。

次いで、以下の処理Ｓ９０５－１～Ｓ９０５－６により、コンテナ・ゲスト用仮想ＮＩＣのネットワーク設定（ステップＳ９０５）を行なう。

Ｓ９０５－１）コンテナ・ゲスト用の仮想ＮＩＣと、コンテナ・ホスト側の対向する仮想ＮＩＣを作成する（ｉｐ ｌｉｎｋコマンド）。
Ｓ９０５－２）コンテナ・ホスト側の対向する仮想ＮＩＣを起動する（ｉｐ ｌｉｎｋコマンド）
Ｓ９０５－３）コンテナ・ホスト側の対向する仮想ＮＩＣを仮想ブリッジに割り当てる（ｉｐ ｌｉｎｋコマンド）。
Ｓ９０５－４）コンテナ・ゲストのネットワーク名前管理ファイルを直接操作するために、コンテナ・ゲストの初期プロセスのネットワーク名前管理ファイルに対して、ｉｐ ｎｅｔｎｓコマンドの操作用ディレクトリにシンボリック・リンクを貼る（ｌｎ －ｓ／ｐｒｏｃ／［コンテナ・ゲスト初期プロセスＩＤ］／ｎｓ／ｎｅｔ ／ｖａｒ／ｒｕｎ／ｎｅｔｎｓ／［コンテナ・ゲスト初期プロセスＩＤ］）。なお、この処理で、コンテナ・ゲストへの仮想ＮＩＣの割り当てが完了する。
Ｓ９０５－５）上記Ｓ９０５－４で作成したシンボリック・リンクに対して、仮想ブリッジを割り当てる（ｉｐ ｌｉｎｋコマンド）。
Ｓ９０５－６）上記Ｓ９０５－４で作成したシンボリック・リンクに対して、ネットワークを設定する（ｉｐ ｎｅｔｎｓコマンド）。

そして、コンテナ・ゲスト用仮想ＮＩＣのコンテナ・ゲストへの割り当てを行ない（ステップＳ９０６）、コンテナ・ホストがコンテナ・ゲストと共有するトピック名を指定して、プロキシ・ノードを起動して（ステップＳ９０７）、本処理を終了する。

プロキシ・マネージャは、プロキシ・ノードのプログラムに引数を指定して、プロキシ・ノードを起動する。引数には、プロキシ・ノードを他のプロキシ・ノードから一意に識別するＩＤ、コンテナ・ホストのＩＰアドレス、コンテナ・ホスト側のホスト・マスタのＩＰアドレス、コンテナ・ホスト側のトピック名、コンテナ・ゲストのＩＰアドレス、コンテナ・ゲスト側のゲスト・マスタのＩＰアドレス、コンテナ・ゲスト側のトピック名、プロキシ・ノードが送受信するデータのキューのサイズ、データ送信を行なうノードを指定する。

プロキシ・マネージャは、事前にデータベースに登録された情報（開発者によるアプリケーションの登録を参照）を使って、プロキシ・ノードを起動する。ネットワーク・セグメントに関する情報と開発者によるアプリケーションの登録時の情報をいずれかのデータベースで紐付けして管理してもよいが、データベース管理しなくても実現できる。但し、この紐付けしたデータベースを管理するのは、各プロキシ・ノードのプロセスではなく、プロキシ・マネージャ又はアプリケーション・ランチャ（アプリケーションを起動するソフトウェア）などである。

図１０には、コンテナ・ホスト１０００内にコンテナ・ゲスト１０１０が起動している様子を示している。コンテナ・ホスト１０００には少なくとも１つのアプリケーションがインストールされたことにより、ホスト・ノード１００４が起動している。

所定の条件を満たさないアプリケーションをシステムにインストールする際、コンテナ・ホスト１０００側で動作するホスト・ノード１００４とは分離して動作させるために、コンテナ・ゲスト１０１０を起動する。そして、アプリケーションはコンテナ・ゲスト１０１０にインストールされ、ゲスト・ノード１０１２として動作する。

アプリケーション・ランチャ１００１は、図９に示した処理手順に従って、コンテナ・ゲスト１０１０の起動と、コンテナ・ゲスト１０１０へのＩＰアドレスの割り当てなどコンテナ用の仮想ネットワーク管理を行なう。また、アプリケーション・ランチャ１００１は、コンテナ・ゲスト１０１０を起動時に、プロキシ・マネージャ１００２を呼び出す。

プロキシ・マネージャ１００２は、コンテナ・ゲスト１０１０の起動時に、プロキシ・ノード１００５を作成する。プロキシ・ノード１００５の起動時に、コンテナ・ホスト１０００側のホスト・マスタ１００３並びにコンテナ・ゲスト１０１０側のゲスト・マスタ１０１１の各々に、コンテナ・ホスト１０００とコンテナ・ゲスト１０１０間で共有するトピック名を指定する。

プロキシ・マネージャ１００２は、例えばプロキシ・ノード１００５の管理ツールである。ユーザは、所定の条件を満たさないアプリケーションをシステムにインストールしたいときに、管理ツールのコンソール画面などを通じて、プロキシ・マネージャ１００２に対して、そのアプリケーションが使用するアプリケーション（ホスト・ノード）と必要なトピックを事前申請する。事前申請によるデータベースの登録情報の一例を、以下の表３に示しておく。これに対し、プロキシ・マネージャ１００２は、事前申請の登録情報に基づいて、コンテナ・ゲスト１０１２が利用するトピック名をデータベース情報から特定する。但し、コンテナ・ゲストが利用するトピック名を、ユーザ自身が事前申請時に指定できるようにしてもよい。

プロキシ・ノード１００５は、以下の項目（ａ）～（ｄ）のマッピング・テーブルをメモリ（キャッシュを含む）あるいは２次記録装置内のデータベースにおいて管理する（前述）。

（ａ）ホスト・ノード１００４が指定できるトピック識別子
（ｂ）ゲスト・ノード１０１２が指定できるトピック識別子
（ｃ）コンテナ・ゲスト１０１０のアドレス
（ｄ）コンテナ・ゲスト１０１０の認証状態（ｖｅｒｉｆｉｃａｔｉｏｎ）やセキュリティ・レベル、サブスクライバのプログラム更新処理を行なう間に送受信されるデータ

図７を参照しながら説明したように、パブリッシャ／サブスクライバ型の通信モデルでは、パブリッシャがマスタにトピックを登録するとともに、サブスクライバがマスタに対してトピックを要求し、マスタにおいてパブリッシャとサブスクライバの対応関係がとれると（すなわち、名前が解決すると）、パブリッシャとサブスクライバ間でのトピック配信が実施される。

図１０に示す仮想ネットワーク空間において、コンテナ・ホスト１０００側では、プロキシ・ノード１００５は、ホスト・ノードとして動作する。したがって、ホスト・ノード１００４とプロキシ・ノード１００５の一方がパブリッシャとなり他方がサブスクライバとなり、ホスト・マスタ１００３においてトピックの対応関係がとれると、ホスト・ノード１００４からプロキシ・ノード１００５へのトピック配信、又は、プロキシ・ノード１００５からホスト・ノード１００４へのトピック配信が実施される。

一方、コンテナ・ゲスト１０１０側では、プロキシ・ノード１００５は、ゲスト・ノードとして動作する。したがって、ゲスト・ノード１０１２とプロキシ・ノード１００５の一方がパブリッシャとなり他方がサブスクライバとなり、ゲスト・マスタ１０１１においてトピックの対応関係がとれると、ゲスト・ノード１０１２からプロキシ・ノード１００５へのトピック配信、又は、プロキシ・ノード１００５からゲスト・ノード１０１２へのトピック配信が実施される。

コンテナ・ホスト１０００とコンテナ・ゲスト１０１０は、仮想ＮＩＣによって論理的に分離したアドレス又は名前空間であり、ホスト・ノード１００４とゲスト・ノード１０１２間で直接的なトピック配信を行なうことはできない。但し、コンテナ・ゲスト１０１０と共有するトピック名を指定してプロキシ・ノード１００５を起動することにより、ホスト・ノード１００４とゲスト・ノード１０１２間で間接的にデータを送信することができる。

ホスト・ノード１００４からゲスト・ノード１０１２へデータを送信する場合、プロキシ・ノード１００５は、コンテナ・ホスト１０００側では、ゲスト・ノード１０１２に対して配信すべきトピック名を、ホスト・マスタ１００３に対して要求する。そして、コンテナ・ホスト１０００側で、ホスト・ノード１００４が、ゲスト・ノード１０１２が要求するトピック名で、ホスト・マスタ１００３にパブリッシャとして登録すると、ホスト・マスタ１００３においてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、ホスト・ノード１００４からプロキシ・ノード１００５へトピック配信が実施される。

続いて、プロキシ・ノード１００５は、ホスト・ノード１００４からトピックを受信したことに応答して、コンテナ・ゲスト１０１０側では、パブリッシャとしてゲスト・マスタ１０１１にトピックを登録すると、ゲスト・マスタ１０１１においてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、プロキシ・ノード１００５からゲスト・ノード１０１２へトピック配信が実施される。

一方、ゲスト・ノード１０１２からホスト・ノード１００４へデータを送信する場合には、プロキシ・ノード１００５は、コンテナ・ゲスト１０１０側では、ゲスト・ノード１０１２がゲスト・マスタ１０１１にパブリッシャとして登録したトピック名を、ゲスト・マスタ１０１１に対して要求する。そして、ゲスト・マスタ１０１１においてパブリッシャとサブスクライバの対応関係がとれると（名前が解決されると）、ゲスト・ノード１０１２からプロキシ・ノード１００５へトピック配信が実施される。

また、プロキシ・ノード１００５は、コンテナ・ホスト１０００側では、ゲスト・マスタ１０１１に対して要求したものと同じトピック名で、ホスト・マスタ１００３に対してパブリッシャとしてトピックを登録する。そして、ホスト・ノード１００４が同じトピック名でサブスクライバとして登録しているとすると、ホスト・マスタ１００３においてパブリッシャとサブスクライバの対応関係がとれるので（名前が解決されるので）、プロキシ・ノード１００５からホスト・ノード１００３へトピック配信が実施される。

なお、コンテナ・ホスト１０００とコンテナ・ゲスト１０１０の名前空間は分離されているので、ホスト・マスタ１００３とゲスト・マスタ１０１１は同じトピック名を使用することができる。但し、例えばコンテナ・ゲスト１０１０内で、コンテナ・ホスト１０００と同じトピックのトピック名に対して、コンテナ・ホスト１０００側の通信相手を識別できるようなプレフィックス（例えば、“／ｈｏｓｔ１”など）などの識別情報を付けることで、トピックの通信相手をコンテナ・ゲスト１０１０側からも識別できるようにすることができる（コンテナ・ホスト１０００側でも同様である）。

プロキシ・マネージャ１００２は、プロキシ・ノード１００５の管理ツールとして、ユーザからの事前申請の登録情報に基づいて、コンテナ・ゲスト１０１２が利用するトピック名をデータベースから特定する。例えば、事前申請するユーザの希望に応じて、コンテナ・ゲスト１０１２側で使用するトピック名にプレフィックスを付けるようにしてもよい。

図１１には、コンテナ・ゲストを起動する際の処理シーケンス例を示している。図示の処理シーケンスは、基本的には、図９に示したフローチャートに従って実行される。

ユーザは、所定の条件を満たさないアプリケーションをシステムにインストールしようとする際、プロキシ・ノードの管理ツールであるプロキシ・マネージャに対して、そのアプリケーションが使用するアプリケーション（ホスト・ノード）と必要なトピックを事前申請する（前述）。

そして、ユーザは、アプリケーション・ランチャに対して、トピック名を指定して、コンテナ・ゲストの起動を要求する（Ｓ１１０１）。ここで言うユーザは、例えば、所定の条件を満たすアプリケーションのインストールを要求するユーザである。

アプリケーション・ランチャは、コンテナ・ゲストを起動する前に、コンテナ・ゲストに割り当てる仮想ネットワークの情報を準備して、プロキシ・マネージャに通知する（Ｓ１１０２）。

プロキシ・マネージャは、システムに対し、コンテナ・ゲスト用の仮想ネットワークの設定を依頼する（Ｓ１１０３）。これに対し、システムは、コンテナ・ゲスト用の仮想ネットワークの設定を完了すると、プロキシ・マネージャに通知する（Ｓ１１０４）。

次いで、プロキシ・マネージャは、ユーザが事前申請してデータベースに情報登録されたトピック名でコンテナ・ホスト側と通信可能となるように、プロキシ・ノードを指定された個数分だけ作成する（Ｓ１１０５）。図１１では、簡素化のため、プロキシ・ノードを１個だけ描いている。そして、プロキシ・ノードは、起動すると、プロキシ・マネージャに通知する（Ｓ１１０６）。プロキシ・ノードを起動する際、コンテナ・ゲストと共有するトピック名を、コンテナ・ホスト側でも指定する。

プロキシ・マネージャは、アプリケーション・ランチャに、コンテナ・ゲストの仮想ネットワークの設定が完了したこと、及び、プロキシ・ノードの起動が完了したことを、アプリケーション・ランチャに通知する（Ｓ１１０７）。

アプリケーション・ランチャは、プロキシ・マネージャから通知を受け取ると、コンテナ・ゲストを起動する。そして、所定の条件を満たさないアプリケーションがコンテナ・ゲストにインストールされ、ゲスト・ノードとして動作する（Ｓ１１０８）。

コンテナ・ホスト側では、プロキシ・ノードは、ホスト・ノードとして動作する。ホスト・ノードとプロキシ・ノードの一方がパブリッシャとなり他方がサブスクライバとなり、ホスト・ノードからプロキシ・ノードへのトピック配信、又は、プロキシ・ノードからホスト・ノードへのトピック配信が実施される。

一方、コンテナ・ゲスト側では、プロキシ・ノードは、ゲスト・ノードとして動作する。ゲスト・ノードとプロキシ・ノードの一方がパブリッシャとなり他方がサブスクライバとなり、ゲスト・ノードからプロキシ・ノードへのトピック配信、又は、プロキシ・ノードからゲスト・ノードへのトピック配信が実施される。

コンテナ・ホストとコンテナ・ゲストは、仮想ＮＩＣによって論理的に分離したアドレス又は名前空間であり、ホスト・ノードとゲスト・ノード間で直接的なトピック配信を行なうことはできない。但し、コンテナ・ゲストと共有するトピック名を指定してプロキシ・ノードを起動することにより、ホスト・ノードとゲスト・ノード間で間接的にデータを送信することができる。

例えば、コンテナ・ホスト側で動作する「カメラ画像アプリケーション」に対応するホスト・ノードから、コンテナ・ゲスト側で動作する「画像認識アプリケーション」に対応するゲスト・ノードに対して、画像データを送りたい場合がある。プロキシ・ノードは、コンテナ・ホスト側では、ゲスト・ノードに対して配信すべきトピック名「画像」を、ホスト・マスタに対して要求する。そして、「カメラ画像アプリケーション」に対応するホスト・ノードが、ホスト・マスタに対し、トピック名「画像」でパブリッシャとして登録すると、ホスト・マスタにおいてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、ホスト・ノードからプロキシ・ノードへトピック配信が実施される。

コンテナ・ゲスト側では、「画像認識アプリケーション」に対応するゲスト・ノードが、ゲスト・マスタに対し、トピック名「画像」を要求するサブスクライバとして登録している。プロキシ・ノードは、ホスト・ノードからトピック「画像」を受信したことに応答して、コンテナ・ゲスト側では、パブリッシャとしてゲスト・マスタにトピック「画像」を登録すると、ゲスト・マスタにおいてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、プロキシ・ノードからゲスト・ノードへトピック「画像」の配信が実施される。

なお、上記では、便宜上、コンテナ・ホスト側でのトピック配信、コンテナ・ゲスト側でのトピック配信の順で説明したが、コンテナ・ホストとコンテナ・ゲストは並列して動作しているので、ホスト・ノードとゲスト・ノード間のデータ通信がどこから始まるかは任意である。

また、コンテナ・ホストとコンテナ・ゲストの名前空間は分離されているので、ホスト・マスタとゲスト・マスタは同じトピック名を使用することができる。但し、例えばコンテナ・ゲスト内で、コンテナ・ホストと同じトピックのトピック名に対して、コンテナ・ホスト側の通信相手を識別できるようなプレフィックス（例えば、“／ｈｏｓｔ１”など）を付けることで、トピックの通信相手をコンテナ・ゲスト側からも識別できるようにすることができる（コンテナ・ホスト側でも同様である）。

図１２には、コンテナ・ホストのホスト・ノードからコンテナ・ゲストのゲスト・ノードへデータ送信を行なうための処理手順をフローチャートの形式で示している。

コンテナ・ホストのホスト・ノードは、プロキシ・ノードが提供するコンテナ・ホスト側の「トピック」に接続する（すなわち、ホスト・マスタに対してパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１２０１）。

そして、ホスト・ノードは、プロキシ・ノードが提供するコンテナ・ホスト側のトピックにデータを送信（パブリッシュ）する（ステップＳ１２０２）。

これに対し、プロキシ・ノードは、自分が提供するコンテナ・ホスト側（ホスト・マスタ）のトピックのデータを受信（サブスクライブ）する（ステップＳ１２０３）。

プロキシ・ノードは、コンテナ・ホストに紐付けられた仮想ネットワーク、すなわちコンテナ・ゲスト側（ゲスト・マスタ）でも、対応するトピックを作成する（すなわち、ゲスト・マスタに対してトピックのパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１２０４）。

そして、プロキシ・ノードは、作成したトピックに、コンテナ・ホスト側でホスト・ノードから受信したデータを送信（パブリッシュ）する（ステップＳ１２０５）。

これに対し、ゲスト・ノードは、コンテナ・ゲスト側（ゲスト・マスタ）でプロキシ・ノードが作成したトピックからデータを受信（サブスクライブ）して（ステップＳ１２０６）、ホスト・ノードからの送信データを受け取ることができる。

また、図１３には、コンテナ・ゲストのゲスト・ノードからコンテナ・ホストのホスト・ノードへデータ送信を行なうための処理手順をフローチャートの形式で示している。

コンテナ・ゲストのゲスト・ノードは、プロキシ・ノードが提供するコンテナ・ゲスト側の「トピック」に接続する（すなわち、ゲスト・マスタに対してパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１３０１）。

そして、ゲスト・ノードは、プロキシ・ノードが提供するコンテナ・ゲスト側のトピックにデータを送信（パブリッシュ）する（ステップＳ１３０２）。

これに対し、プロキシ・ノードは、自分が提供するコンテナ・ゲスト側（ゲスト・マスタ）のトピックのデータを受信（サブスクライブ）する（ステップＳ１３０３）。

プロキシ・ノードは、コンテナ・ゲストに紐付けられた仮想ネットワーク、すなわちコンテナ・ホスト側（ホスト・マスタ）でも、対応するトピックを作成する（すなわち、ホスト・マスタに対してトピックのパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１３０４）。

そして、プロキシ・ノードは、作成したトピックに、コンテナ・ゲスト側でゲスト・ノードから受信したデータを送信（パブリッシュ）する（ステップＳ１３０５）。

これに対し、ホスト・ノードは、コンテナ・ホスト側（ホスト・マスタ）でプロキシ・ノードが作成したトピックからデータを受信（サブスクライブ）して（ステップＳ１３０６）、ゲスト・ノードからの送信データを受け取ることができる。

図１４には、コンテナ・ホスト側（図示しないホスト・ノード）からコンテナ・ゲスト側（図示しないゲスト・ノード）へデータ送信を行なうための処理シーケンス例を示している。

プロキシ・ノードは、プロキシ・マネージャに事前登録されたコンテナ・ゲスト側のトピック名で、自分の仮想ネットワーク情報をゲスト・マスタに登録する（Ｓ１４０１）。

また、パブリッシャであるコンテナ・ホスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないホスト・ノード）は、プロキシ・マネージャに事前登録されたコンテナ・ホスト側のトピック名で、自分の仮想ネットワーク情報をホスト・マスタに登録する（Ｓ１４０２）。

一方、サブスクライバであるコンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）は、プロキシ・マネージャに事前登録されたコンテナ・ゲスト側のトピック名がゲスト・マスタに登録されるまで、待機する。そして、コンテナ・ゲストは、ゲスト・マスタに所望のトピック名が登録されたことを確認できると、プロキシ・ノードの仮想ネットワーク情報を、ゲスト・マスタから取得する（Ｓ１４０３）。

また、プロキシ・ノードは、プロキシ・マネージャに事前登録されたコンテナ・ホスト側のトピック名がホスト・マスタに登録されるまで、待機する。そして、プロキシ・ノードは、ホスト・マスタに所望のトピック名が登録されたことを確認できると、パブリッシャとなるコンテナ・ホストの仮想ネットワーク情報を、ホスト・マスタから取得する（Ｓ１４０４）。

そして、サブスクライバであるコンテナ・ゲストは、ゲスト・マスタから取得したプロキシ・ノードの仮想ネットワーク情報に基づいて、プロキシ・ノードへ接続する（Ｓ１４０５）。この結果、プロキシ・ノードと、サブスクライバであるコンテナ・ゲストとの通信路が完成する。

続いて、プロキシ・ノードは、ホスト・マスタから取得したホスト・ノードの仮想ネットワーク情報に基づいて、コンテナ・ホストへ接続する（Ｓ１４０６）。この結果、パブリッシャであるコンテナ・ホストとプロキシ・ノードとの通信路が完成する。

コンテナ・ホスト側では、パブリッシャであるコンテナ・ホストが、プロキシ・ノードへ、トピックのデータを送信する（Ｓ１４０７）。

また、コンテナ・ゲスト側では、プロキシ・ノードから、サブスクライバであるコンテナ・ゲストへ、トピックのデータを送信する（Ｓ１４０８）。

なお、コンテナ・ゲスト側（ゲスト・ノード）からコンテナ・ホスト側（ホスト・ノード）へデータ送信を行なう処理シーケンスについては図示を省略するが、同様の手順により実施できることを理解されたい。

ここまで説明してきたように、各アプリケーションを、種別に応じて（例えば、所定の条件を満たすか否かに応じて、あるいは、条件を適合するレベルに応じて）、仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングすることができる。コンテナ毎に仮想ネットワークが作成され、各コンテナ（コンテナ・ゲスト）は外部（コンテナ・ホスト）から遮断される。また、各コンテナには仮想ＮＩＣが割り当てられ、コンテナ・ホスト側には対向する仮想ＮＩＣが作成される。

図１５には、仮想ＮＩＣを用いたコンテナ・ネットワーク１５００の構成例を示している。図示のコンテナ・ネットワーク１５００には、複数のコンテナ・グループ１５１０、１５２０などが形成され、各コンテナ・グループ１５１０、１５２０などの内には１以上のコンテナ（コンテナ・ゲスト）が起動している。例えば、コンテナ・グループ１５１０内ではコンテナ１５１１及びコンテナ１５１２が起動し、コンテナ・グループ１５２０内ではコンテナ１５２１が起動している。コンテナは、例えば図９に示した処理手順に従って起動されるものとする。

各コンテナには仮想ＮＩＣが割り当てられ、コンテナ・ホスト側の対向する仮想ＮＩＣと通信することができる。図１５に示す例では、コンテナ・グループ１５１０内では、コンテナ１５１１には仮想ＮＩＣ１５１１´が割り当てられるとともに、コンテナ１５１１には仮想ＮＩＣ１５１２´が割り当てられる。また、コンテナ・グループ１５２０内では、コンテナ１５２１に仮想ＮＩＣ１５２１´替わりらてられる。また、コンテナ・ホスト側には、各コンテナの仮想ＮＩＣと対向する仮想ＮＩＣ１５０１が作成されている。コンテナ・ホスト側の仮想ＮＩＣ１５０１と各コンテナ・グループ内のコンテナ毎の仮想ＮＩＣ１５１１´、１５１２´、１５２１´、…とは、コンテナ・グループ毎に作成された仮想ブリッジ１５０１－ａ、１５０１－ｂなどを介して通信することができる。

コンテナ・グループ１５１０、１５２０、…は、例えばアプリケーションの開発者（ソフトウェア・ベンダ）毎に割り当てられる。したがって、１つのコンテナ・グループは、（同一の開発者により開発されるなど）条件が揃ったアプリケーションをインストールして、ノードとして動作させるためのコンテナの集合からなる。

図１５中、通信許可範囲を点線で囲って示している。コンテナ・グループ内では、各コンテナで動作するノード間は、互いのコンテナに割り当てられた仮想ＮＩＣによって通信することができる。例えば、コンテナ１５１１で動作するノードとコンテナ１５１２で動作するノードは、各々に割り当てられた仮想ＮＩＣ１５１１´及び１５１２´によって通信可能である。他方、別のコンテナ・グループに属するコンテナで動作するノード間は、サブネットが分かれているため、通信することができない。例えば、コンテナ１５１２で動作するノードと、コンテナ１５２１で動作するノード間は、各々に割り当てられた仮想ＮＩＣ１５１２´及び１５２１´で通信することは不可能である。

例えば、パケット・フィルタリング及びネットワーク・アドレス変換 （ＮＡＴ） 機能の設定を操作するｉｐｔａｂｌｅｓコマンドなどを利用して、上記のような通信許可範囲の制限を実現することができる。

各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、同一のソースからの情報に対し、アプリケーション毎に割り当てる特性に応じた加工を施した上で送信することができる。例えば、送信先となるアプリケーション毎のセキュリティ・レベルに併せて情報を劣化させる。具体的には、コンテナ間で共有するトピックをコンテナ毎に変更することにより、実現することができる。コンテナ毎に共有トピックを変更する例について、図１６を参照しながら説明する。

図１６では、カメラ画像アプリケーションから画像認識アプリケーションへ画像を配信することを想定しており、共有するトピック名を「画像」とする。

コンテナ・ホスト１６００側には、所定の条件を満たすカメラ画像アプリケーション（ＡＰＰ１）及び画像認識アプリケーション（ＡＰＰ２）がインストールされて、それぞれノード１６０１及びノード１６０２として動作している。

また、第三者から提供された、認証済みの画像認識アプリケーション（ＡＰＰ３）が、コンテナ・ゲスト（認証済みコンテナ）１６１０にインストールされて、ゲスト・ノード（認証済みノード）１６１１として動作している。認証済みコンテナ１６１０は、プロキシ・ノード１６１２を介して、ノード１６０１とトピック「画像」を共有している。

さらに、他の第三者から提供された、未認証の画像認識アプリケーション（ＡＰＰ４）が、コンテナ・ゲスト（未認証コンテナ）１６２０にインストールされて、ゲスト・ノード（未認証ノード）１６２１として動作している。なお、各コンテナ・ゲスト１６１０、１６２０は、例えば図９に示した処理手順に従って起動されているものとする。未認証コンテナ１６２１は、プロキシ・ノード１６２２を介して、ノード１６０１とトピック「画像」を共有している。

コンテナ・ホスト１６００で動作するノード１６０２は、セキュリティ・レベルが高いことが想定される。そこで、カメラ画像アプリケーションが動作するノード１６０１と、画像認識アプリケーションが動作する１６０２とはトピック「／高解像度画像」を共有し、ノード１６０１は、カメラ画像アプリケーションが取得した高解像度の画像をそのままノード１６０２に送信する。

一方、認証済みコンテナ１６１０で動作する認証済みノード１６１１は、中程度のセキュリティ・レベルである。そこで、セキュリティ・レベルに合わせて、ノード１６０１と認証済みノード１６１１で共有するトピックを「／高解像度画像」から「／中解像度画像」に変更する。例えば、プロキシ・マネージャ（図１６では図示しない）がプロキシ・ノード１６１２を起動するときに、コンテナ・ホスト１６００と認証済みコンテナ１６１０間で共有するトピック名を「／中解像度画像」に指定する。その結果、ノード１６０１は、元の高解像度画像の解像度を低下する加工を施して、プロキシ・ノード１６１２からのトピックの要求に対して中解像度画像を送信し、認証済みノード１６１１には中解像度画像が届くことになる。

また、未認証コンテナ１６２０で動作する認証済みノード１６２１は、セキュリティ・レベルが低い。そこで、セキュリティ・レベルに合わせて、ノード１６０１と未認証ノード１６２１で共有するトピックを「／高解像度画像」から「／低解像度画像」に変更する。例えば、プロキシ・マネージャ（図１６では図示しない）がプロキシ・ノード１６２２を起動するときに、コンテナ・ホスト１６００と未認証コンテナ１６２０間で共有するトピック名を「／低解像度画像」に指定する。その結果、ノード１６０１は、元の高解像度画像の解像度を劣化する加工を施して、プロキシ・ノード１６２２からのトピックの要求に対して低解像度画像を送信し、未認証ノード１６２１には低解像度画像が届くことになる。

図１６に示した、コンテナのセキュリティ・レベルに応じた共有トピックの変形例を、以下の表４にまとめておく。

各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、更新又は追加されたアプリケーションがシステム動作中に誤動作を起こした場合に、その誤動作を検出して、そのアプリケーションの停止と再起動を行なうことができる。

想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。そして、プロキシ・ノードは、例えば更新又は追加されたアプリケーションをインストールして動作するゲスト・ノードから受信したデータに異常値を検出すると、コンテナ・ホスト側でホスト・ノードにはデータを送信せず、アプリケーションの停止を指示する。

図１７には、コンテナを用いてアプリケーションをグルーピングする方法を利用して、仕様に適合しない出力をするアプリケーションの停止と再起動を行なう仕組みを図解している。

コンテナ・ホスト１７１０と、コンテナ・ゲスト１７２０がそれぞれの実行環境で起動している。また、各コンテナの動作を監視する監視フレームワーク（ＦＷ）１７４０が、その実行環境で動作している。

コンテナ・ホスト１７１０側では、所定の条件を満たすアプリケーションをインストールして、ホスト・ノード１７１１が動作している。一方、コンテナ・ゲスト１７２０側では、所定の条件を満たさないアプリケーションをインストールして、ゲスト・ノード１７２１が動作している。また、コンテナ・ホスト１７１０側では、コンテナ・ゲスト１７２０側と共有するトピック“Ｔｏｐｉｃ１”を指定するプロキシ・ノード１７１２が起動している。

コンテナ・ゲスト１７２０側で、ゲスト・ノード１７２１がＴｏｐｉｃ１のデータをパブリッシュするとともに、プロキシ・ノード１７１２がサブスクライブする。このとき、プロキシ・ノード１７１２は、ゲスト・ノード１７２１から受信したデータに異常値を検出すると、監視フレームワーク１７４０に異常を通知する。

監視フレームワーク１７４０は、コンテナ・ゲスト１７２０の異常、又は、コンテナ・ゲスト１７２０で動作するゲスト・ノード１７２１の異常を検知すると、ゲスト・ノード１７２１を停止させるとともに、他のコンテナ・ゲスト１７３０側で動作するゲスト・ノード１７３１に瞬時に切り替える。

コンテナ・ゲスト１７３０は、コンテナ・ゲスト１７２０とは実装が異なる実行環境で起動したコンテナであり、又は、ゲスト・ノード１７３１は、ゲスト・ノード１７２１よりも古い、安定したバージョンのアプリケーションをコンテナ・ゲスト１７３０にインストールして動作するノードである。

図１８には、仕様に適合しない出力をするアプリケーションの停止と再起動を行なうための処理シーケンス例を示している。

まず、コンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）が、パブリッシャとして、プロキシ・ノードへデータ送信する（Ｓ１８０１）。

プロキシ・ノードは、コンテナ・ゲストから送信されたデータが、あらかじめ規定された出力値の仕様範囲内かどうかをチェックする。そして、出力値の仕様範囲外であることを検知すると、プロキシ・ノードは、監視フレームワークに対し、パブリッシャであるコンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）の異常を通知する（Ｓ１８０２）。

監視フレームワークは、プロキシ・ノードからの異常通知に応答して、異常を起こしたパブリッシャであるコンテナ・ゲスト（ゲスト・ノード）の停止を指示する（Ｓ１８０３）。

また、監視フレームワークは、異常を起こしたコンテナ・ゲストとは異なる実行環境でコンテナ・ゲストを起動し、そのコンテナ・ゲスト内に、異常を起こしたコンテナ・ゲストのアプリケーションとは同じであるが、古いバージョンで安定したアプリケーションをインストールして、コンテナ・ゲストを安定化パブリッシャとして動作させる（Ｓ１８０４）。

各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、更新中のアプリケーションに関連する送受信データを一時的に保存し、更新後に一時保存した送受信データから接続を再開することで、アプリケーションやアプリケーションに含まれるプログラムを安全に更新又は追加することができる。

想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。プロキシ・ノードは、例えば、パブリッシャとしてデータを送信中のゲスト・ノードに関連するアプリケーションを更新する際には、パブリッシャからの送信データを一時的に保存し、更新完了後にゲスト・ノードはプロキシ・ノードに再接続して、データ送信を再開する。また、プロキシ・ノードは、例えばサブスクライバとして接続しているゲスト・ノードにデータを送信中にアプリケーションを更新する際には、受信データを一時的に保存し、更新完了後にプロキシ・ノードはゲスト・ノードへのデータ送信を再開する。

図１９には、アプリケーションを更新中のゲスト・ノードに関連する送受信データを一時的に保存する仕組みを模式的に示している。同図では、コンテナ・ホスト１９００側では、コンテナ・ゲスト１９１０と共有するトピック名を指定してプロキシ・ノード１９０２が起動され、パブリッシャとしてのホスト・ノード１９０１が送信したデータをプロキシ・ノード１９０２が受信し、コンテナ・ゲスト１９１０側ではプロキシ・ノード１９０２からサブスクライバとしてのゲスト・ノード１９１１に転送することを想定している。また、アプリケーションやアプリケーションに含まれるプログラムを更新又は追加することにより、更新前のゲスト・ノード１９１１は、ゲスト・ノード１９１２に更新されるものとする。

アプリケーション・アップデータ１９０３は、アプリケーションのアップデートを管理する役割を持つ管理プロセスである。アプリケーション・アップデータ１９０３は、サブスクライバであるゲスト・ノード１９１１に関連するプログラムを更新する前に、プロキシ・ノード１９０２が提供するキューに、パブリッシャであるホスト・ノード１９０１から送信されたデータを一時的に保存するように、プロキシ・ノード１９０２に指示を出す。これによって、サブスクライバが終了するなどの状態変化が発生しても、パブリッシャであるホスト・ノード１９０１から送信されたデータはプロキシ・ノード１９０２に保持される。

続いて、アプリケーション・アップデータ１９０３は、サブスクライバであるゲスト・ノード１９１１に関連するプログラムを更新する。そして、アプリケーション・アップデータ１９０３は、プログラムの更新が完了すると、プロキシ・ノード１９０２に対してプログラム更新完了を通知する。

プロキシ・ノード１９０２は、アプリケーション・アップデータ１９０３からプログラムの更新完了の通知を受け取ると、一時的に保存しておいたパブリッシャ（ホスト・ノード１９０１）からの送信データの最初から、サブスクライバ（更新後のゲスト・ノード１９１２）へのデータ送信を再開する。

図２０には、アプリケーションを更新中のコンテナ・ゲスト（更新対象のゲスト・ノードを含む）に関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示している。但し、同図は、更新中のコンテナ・ゲスト（更新対象のゲスト・ノード）がパブリッシャとして動作する場合の処理シーケンス例を示している。

ユーザが、パブリッシャとして動作中のコンテナ・ゲスト（更新前のゲスト・ノード）に関連するプログラムの更新を要求する（Ｓ２００１）。

アプリケーション・アップデータは、ユーザからの更新要求に応答して、プロキシ・ノードに対し、更新前のパブリッシャであるコンテナ・ゲスト（更新対象のゲスト・ノード）への通信接続を一時的に保存するように指示する（Ｓ２００２）。プロキシ・ノードは、アプリケーション・アップデータからの指示に応答して、コンテナ・ゲスト（更新対象のゲスト・ノード）から送信（パブリッシュ）されるデータを一時的に保存する。

その後、アプリケーション・アップデータは、パブリッシャであるコンテナ・ゲスト内の更新対象のゲスト・ノードに関連するプログラムの更新を実施する（Ｓ２００３）。ここで、プログラムは、特定のディレクトリにバージョン毎に保存され、実際の更新処理は、新しいプログラムを起動するだけの処理を指すものとする。

そして、パブリッシャであるコンテナ・ゲストに関連するプログラム（更新されるゲスト・ノードに対応する）の更新処理が完了すると、アプリケーション・アップデータは、プロキシ・ノードに対して更新完了を通知する（Ｓ２００４）。

パブリッシャ（コンテナ・ゲスト内の更新後のゲスト・ノード）は、プロキシ・ノードへ再接続し、データの転送（パブリッシュ）を再開する（Ｓ２００５）。また、プロキシ・ノードは、一時的に保存しておいたデータから、コンテナ・ホスト内のホスト・ノード（図示しない）へのデータ送信を再開する。

また、図２１には、アプリケーションを更新中のコンテナ・ゲスト（更新対象のゲスト・ノードを含む）に関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する他の処理シーケンス例を示している。但し、同図は、更新中のコンテナ・ゲスト（更新対象のゲスト・ノード）がサブスクライバとして動作する場合の処理シーケンス例を示している。

ユーザが、サブスクライバとして動作中のコンテナ・ゲスト（更新前のゲスト・ノード）に関連するプログラムの更新を要求する（Ｓ２１０１）。

アプリケーション・アップデータは、ユーザからの更新要求に応答して、プロキシ・ノードに対し、更新前のサブスクライバであるコンテナ・ゲスト（更新前のゲスト・ノード）への通信接続及び更新中に受信したデータを一時的に保存するように指示する（Ｓ２１０２）。プロキシ・ノードは、アプリケーション・アップデータからの指示に応答して、コンテナ・ホスト内のホスト・ノード（図示しない）から送信（パブリッシュ）され、コンテナ・ゲスト（更新対象のゲスト・ノード）に転送すべきデータを一時的に保存する。

その後、アプリケーション・アップデータは、サブスクライバ（コンテナ・ゲスト内の更新対象のゲスト・ノード）に関連するプログラムの更新を実施する（Ｓ２１０３）。ここで、プログラムは、特定のディレクトリにバージョン毎に保存され、実際の更新処理は、新しいプログラムを起動するだけの処理を指すものとする。

そして、サブスクライバ（コンテナ・ゲスト（ゲスト・ノード））に関連するプログラムの更新処理が完了すると、アプリケーション・アップデータは、プロキシ・ノードに対して更新完了を通知する（Ｓ２１０４）。

プロキシ・ノードは、サブスクライバ（コンテナ・ゲストに含まれる更新対象となるゲスト・ノード）の更新中に一時的に保存したデータから、サブスクライバ（コンテナ・ゲスト内の更新後のゲスト・ノード）へのデータ送信を再開する（Ｓ２１０５）。また、プロキシ・ノードは、一時的に保存しておいたデータから、コンテナ・ゲスト（更新後のゲスト・ノード）へのデータ転送を再開する。

各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、コンテナ間で送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現することができる。

想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。プロキシ・ノードが通信量を制御することによって、各コンテナに対して均等なネットワーク・リソースを割り当てることができる。

コンテナ環境の複数業者での利用時（マルチテナント）に、ネットワーク流量制限（ネットワーク層レベルの制限）に加えて、トピック数での論理レベルの流量制限（アプリケーション層レベルの制限）を実現することができる。

また、各コンテナのアプリケーション特性に合わせたトピック数での制限を実現することができる。例えば、プロキシ・マネージャは、プロキシ・ノードを起動する際に、アプリケーションのインストールを要求するユーザに応じて（若しくは、起動したコンテナ・ゲストにインストールするアプリケーションの特性や、アプリケーションの開発者の属性などに応じて）、ゲスト・ノードに対して課す通信量の制限（例えば、一定時間内で送信トピック数又は送信パケット量など）を、プロキシ・サーバに設定する。複数業者のアプリケーションをインストールするために、複数のプロキシ・ノード及び複数のコンテナ・ゲストを起動する際には、各プロキシ・ノードには対応するアプリケーションに応じた通信量の制限を設定する。

図２２には、トピック通信量によるスロットリングの仕組みを図解している。同図において、コンテナ・ゲスト２２１０側のゲスト・ノード２２１１（パブリッシャ）から、コンテナ・ホスト２２００側のホスト・ノード２２０１（サブスクライバ）へのデータ通信量を、プロキシ・ノード２２０２において制限している。

また、図２３には、トピック通信量によるスロットリングを行なう処理シーケンス例を示している。

パブリッシャとして動作するコンテナ・ゲストは、プロキシ・ノードへ，データを送信する（Ｓ２３０１）。

プロキシ・ノードは、一定時間内で送信トピック数又は送信パケット量に対する通信量の制限を課しており、通信量制限を超えてコンテナ・ゲストからデータ通信が行なわれたときには、送信元のゲスト・ノードに通知する（Ｓ２３０２）。

コンテナを用いたグルーピングにより、所定の条件を満たさないアプリケーションを隔離する仕組みについて、図２４を参照しながら詳細に説明する。

図２４において、コンテナ・ホスト２４００側では、データ送信用のアプリケーションがインストールされ、ホスト・ノード２４０１（パブリッシャ）として動作するとともに、データ受信用のアプリケーションがインストールされ、ホスト・ノード２４０２として動作している。

コンテナ・ゲスト２４１０を起動する前の処理として、コンテナ・ゲスト２４１０内のゲスト・マスタ２４１１に、データ送信用のホスト・ノード２４０１を対象とするプロキシ・ノード２４０３（パブリッシャ）のトピック名と、データ受信用のホスト・ノード２４０２を対象とするプロキシ・ノード２４０４（サブスクライバ）のトピック名を、登録する。

起動したコンテナ・ゲスト２４１０は、仮想ＮＩＣによって論理的に分離されるアドレス又は名前空間である。コンテナ・ゲスト２４１０内には、第三者から提供されたような、所定の条件を満たさないアプリケーションがインストールされ、ゲスト・ノード２４１２として動作している。ここでは、ゲスト・ノード２４１２は、プロキシ・ノード２４０３と同じトピック名でサブスクライバとしてゲスト・マスタ２４１１に登録されるとともに、プロキシ・ノード２４０４と同じトピック名でパブリッシャとしてゲスト・マスタ２４１１に登録されているものとする。

コンテナ・ゲスト２４１０は仮想ＮＩＣによって論理的に分離されるアドレス又は名前空間であり、したがって、コンテナ・ゲスト２４１０は、コンテナ・ホスト２４００から隔離されている。ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録したコンテナ・ゲスト２４１０側のトピックを経由して、コンテナ・ゲスト２４１０外、すなわちコンテナ・ホスト２４００側とデータを送受信することができる。

ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録されたプロキシ・ノード２４０３から、ホスト・ノード２４０１の送信データを受信することはできるが、コンテナ・ホスト２４００で動作する（ゲスト・マスタ２４１１に登録されていない）ホスト・ノード２４０５からデータを受信することはできない。

また、ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録されたプロキシ・ノード２４０４に対してデータを送信することによって、プロキシ・ノード２４０４を介してホスト・ノード２４０２にデータを送信することはできるが、コンテナ・ホスト２４００で動作する（ゲスト・マスタ２４１１に登録されていない）ホスト・ノード２４０５へデータを送信することはできない。

また、ゲスト・ノード２４１２からのデータ受信用に起動されたプロキシ・ノード２４０４は、ゲスト・ノード２４１２からの受信データが、アプリケーションにあらかじめ規定された出力値の仕様範囲内かどうかをチェックする。そして、実施例５で説明したように、出力値の仕様範囲外であることを検知すると、ゲスト・ノード２４１２の停止や、古い、安定したバージョンのアプリケーションからゲスト・ノードを再起動するといった対応処理を実施する。

図６を参照しながら既に説明したように、ロボットや自動走行車、無人航空機といった自律動作装置１００上では「認識」、「状況理解」、「行動計画」、「行動制御」に分類される多数のアプリケーション・プログラムが動作する。

図２５には、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例を示している。同図において、認識系アプリケーションから取得したデータを、状況理解系アプリケーションである「Ｉｎｐｕｔ Ａｄａｐｔｅｒ」経由で、独自のアルゴリズムを持つ画像分析アプリケーション「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」に入力する。

「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」が所定の条件を満たし、正常な動作を行なうことが保証されていれば、適切な画像解析結果を行動計画系のアプリケーション「Ｐａｔｈ ｐｌａｎｎｅｒ」に出力し、「Ｐａｔｈ ｐｌａｎｎｅｒ」はロボットが稼働する経路を適切に選択することができる。ところが、「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」が所定の条件を満たさず、プログラムの悪意若しくは何らかのバグによって不適切な画像解析結果を「Ｐａｔｈ ｐｌａｎｎｅｒ」に出力した場合には、「Ｐａｔｈ ｐｌａｎｎｅｒ」はロボットが稼働する経路を適切に選択することができなくなる。

そこで、図２６に示すように、コンテナを用いたグルーピングを導入する。具体的には、参照番号２６０１で示すコンテナ・ゲストを起動し、所定の条件を満たさない「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」をこのコンテナ・ゲスト２６０１内にインストールして、外部から隔離したノードとして動作させる。また、「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」の入力側と出力側には、それぞれ参照番号２６０２、２６０３で示すプロキシ・ノードを準備して、「Ｉｎｐｕｔ Ａｄａｐｔｅｒ」と「Ｐａｔｈ ｐｌａｎｎｅｒ」に送受信されるデータを制限することにより、不適切な画像解析結果を「Ｐａｔｈ ｐｌａｎｎｅｒ」に出力しないようにする。プロキシ・ノード２６０３は、「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」から受信したデータがあらかじめ規定された出力値の仕様範囲外である場合には、実施例３（図１７）で示した監視フレームワークを利用して、「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」のノードを停止させるようにしてもよい。また、プロキシ・ノード２６０３は、監視フレームワークを利用して、「Ｉｍａｇｅ Ａｎａｌｙｚｅｒ」のノードを、同等の機能を持つ別のノードを含むコンテナに切り替えるようにしてもよい。

図２７には、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例を示している。同図において、状況理解系アプリケーションである「場に付与された交通ルール」と「空間・状態」が出力するデータを、「交通可能場所判断アプリケーション」に入力する。

「交通可能場所判断アプリケーション」が所定の条件を満たし、正常な動作を行なうことが保証されていれば、適切な交通場所の判断結果を行動計画系のアプリケーション「Ｂｅｈａｖｉｏｒ ｐｌａｎ」に出力し、「Ｂｅｈａｖｉｏｒ ｐｌａｎ」は自動走行車への適切な動作計画を作成することができる。ところが、「交通可能場所判断アプリケーション」が所定の条件を満たさず、プログラムの悪意若しくは何らかのバグによって不適切な判断結果を「Ｂｅｈａｖｉｏｒ ｐｌａｎ」に出力した場合、「Ｂｅｈａｖｉｏｒ ｐｌａｎ」は自動運転車への適切な動作計画を作成することができなくなる。

そこで、図２８に示すように、コンテナを用いたグルーピングを導入する。具体的には、参照番号２８０１で示すコンテナ・ゲストを起動し、所定の条件を満たさない「交通可能場所判断アプリケーション」をこのコンテナ・ゲスト２６０１内にインストールして、外部から隔離したノードとして動作させる。また、「交通可能場所判断アプリケーション」の入力側と出力側には、それぞれ参照番号２８０２、２８０３、２８０４で示すプロキシ・ノードを準備して、「場に付与された交通ルール」と「空間・状態」と「Ｂｅｈａｖｉｏｒ ｐｌａｎ」に送受信されるデータを制限することにより、不適切な交通可能場所の判断結果を「Ｂｅｈａｖｉｏｒ ｐｌａｎ」に出力しないようにする。プロキシ・ノード２８０４は、実施例３（図１７）で示した監視フレームワークを利用して、「交通可能場所判断アプリケーション」から受信したデータがあらかじめ規定された出力値の仕様範囲外である場合には、「交通可能場所判断アプリケーション」のノードを停止させるようにしてもよい。また、プロキシ・ノード２８０４は、監視フレームワークを利用して、「交通可能場所判断アプリケーション」のノードを、同等の機能を持つ別のノードを含むコンテナに切り替えるようにしてもよい。

このように、本明細書で開示する技術によれば、パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、コンテナに所属する構成ユニット（アプリケーションなど）又は構成ユニットに含まれるソフトウェアの所属するコンテナ内に通信を制限することができる。この技術によれば、構成ユニット開発における独立性を維持しつつ、構成ユニット又は構成ユニットに含まれるソフトウェアの任意のグルーピングが可能である。

また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、同一のソースからの情報に対し、構成ユニット毎に割り当てる特性に応じた加工（例えば、構成ユニットのセキュリティ・レベルに合わせて情報を劣化する）を施した上で送信することができる。

また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、更新・追加された構成ユニットに含まれるソフトウェアがシステム動作中に誤作動などを起こした場合には、その誤作動を検出し、システム動作を継続させながら、誤作動などを起こしたソフトウェアを更新・追加する前に動作が保証されていたソフトウェアの動作に切り替えることができる。

また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、更新中の構成ユニットに関連する送受信データを一時保存し、更新後に一時保存した送受信データから接続を再開することで、構成ユニットや構成ユニットに含まれるソフトウェアを安全に更新・追加することができる。

また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、構成ユニットが送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現し、マルチテナント（構成ユニットを複数の業者に提供する場合）においても、各々に均等なネットワーク・リソースを配分することができる。

以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書で開示する技術は、自律的若しくは適応的な行動を実現するアプリケーション・プログラムをインストールして動作する、ロボットや自動走行車、無人航空機（ドローン）などの自律動作装置に適用することができる。また、自律動作装置には限定されず、アプリケーション又はアプリケーションに含まれるソフトウェアをインストールするさまざまなタイプの情報処理装置や、パブリッシャ／サブスクライバ型の通信モデルに基づいてプロセス間通信を実施するさまざまタイプの情報処理装置に対しても、同様に本明細書で開示する技術を適用することができる。

要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
を具備する情報処理装置。
（２）前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する、
上記（１）に記載の情報処理装置。
（３）前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、
前記起動部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する、
上記（２）に記載の情報処理装置。
（４）前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、
前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、
前記第２のノードが、前記第２のトピックからデータを受信する、
上記（３）に記載の情報処理装置。
（５）前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、
前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、
前記第１のノードが、前記第１のトピックからデータを受信する、
上記（３）又は（４）のいずれかに記載の情報処理装置。
（６）前記第１のノードは所定の条件を満たす第１のアプリケーションを前記第１のコンテナにインストールして動作するノードであり、
前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる、
上記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）前記所定の条件は、アプリケーションの開発者、アプリケーションのセキュリティ・レベル、アプリケーションの動作検証のうち少なくとも１つを含む、
上記（６）に記載の情報処理装置。
（８）前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第２のノードとして動作するアプリケーションの特性に応じた加工を行なう、
上記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
上記（１）乃至（７）のいずれかに記載の情報処理装置。
（１０）前記第２のノードの動作を監視する監視部をさらに備える、
上記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）前記プロキシ・ノードは、前記第２のノードから受信したデータをチェックし、異常を検出したときに前記監視部に通知する、
上記（１０）に記載の情報処理装置。
（１２）前記監視部は、異常が検出された前記第２のノードを停止させる、
上記（１０）又は（１１）のいずれかに記載の情報処理装置。
（１３）前記監視部は、前記第２のノードよりも安定したアプリケーションを再起動して第３ノードを動作させる、
上記（１２）に記載の情報処理装置。
（１４）前記第２のノードとして動作するアプリケーションの更新を行なうアプリケーション更新部をさらに備え、
前記アプリケーション更新部は、前記プロキシ・ノードは、前記アプリケーションを更新中に前記第２のノードとの送受信データを保存し、前記アプリケーションの更新後に前記保存した送受信データから前記第２のノードとの接続を再開する、
上記（１）乃至（１３）のいずれかに記載の情報処理装置。
（１５）前記プロキシ・ノードは、前記第２のノードからの通信量の制限を課す、
上記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）前記プロキシ・ノードは、前記第２のノードが前記制限を超えたデータ送信を行なったときには、前記第２のノードに通知する、
上記（１５）に記載の情報処理装置。
（１７）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
を有する情報処理方法。
（１８）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータ・プログラム。

１００…自律動作装置（実機）
１１０…本体部
１１１…プロセッサ、１１２…メモリ、１１３…通信モデム
１１４…バッテリー、１１５…ＵＳＢポート、１１６…ＧＰＳ
１２０…モジュール部
１２１…アクチュエータ、１２２…プロセッサ
１２３…メモリ、１２４…センサ、１２５…通信モデム
２００…開発装置、２１０…コンピュータ本体部
２１１…プロセッサ、２１２…ＧＰＵ
２１３…メモリ、２１４…ＵＳＢポート、２１５…通信モデム
２２０…ディスプレイ、２３０…ユーザ・インターフェース

Claims (17)

1. 第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
   前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
   を具備し、
   前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
   情報処理装置。
2. 前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する、
   請求項１に記載の情報処理装置。
3. 前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、
   前記プロキシ管理部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する、
   請求項２に記載の情報処理装置。
4. 前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、
   前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、
   前記第２のノードが、前記第２のトピックからデータを受信する、
   請求項３に記載の情報処理装置。
5. 前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、
   前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、
   前記第１のノードが、前記第１のトピックからデータを受信する、
   請求項３に記載の情報処理装置。
6. 前記第１のノードは、所定の条件を満たす第１のアプリケーションが前記第１のコンテナにインストールされ実行されたものであり、
   前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる、
   請求項１に記載の情報処理装置。
7. 前記所定の条件は、アプリケーションの開発者、アプリケーションのセキュリティ・レベル、アプリケーションの動作検証のうち少なくとも１つに関する条件を含む、
   請求項６に記載の情報処理装置。
8. 前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第２のノードとして動作するアプリケーションの特性に応じた加工を行なう、
   請求項１に記載の情報処理装置。
9. 前記第２のノードの動作を監視する監視部をさらに備える、
   請求項１に記載の情報処理装置。
10. 前記プロキシ・ノードは、前記第２のノードから受信したデータをチェックし、異常を検出したときに前記監視部に通知する、
    請求項９に記載の情報処理装置。
11. 前記監視部は、異常が検出された前記第２のノードを停止させる、
    請求項９に記載の情報処理装置。
12. 前記監視部は、前記第２のノードを起動する際にインストールしたものと同じアプリケーションの異常を起こさないバージョンをインストールして第３のノードを動作させる、
    請求項１１に記載の情報処理装置。
13. 前記第２のノードとして動作するアプリケーションの更新を行なうアプリケーション更新部をさらに備え、
    前記アプリケーション更新部は、前記プロキシ・ノードは、前記アプリケーションを更新中に前記第２のノードとの送受信データを保存し、前記アプリケーションの更新後に前記保存した送受信データから前記第２のノードとの接続を再開する、
    請求項１に記載の情報処理装置。
14. 前記プロキシ・ノードは、前記第２のノードからの通信量の制限を課す、
    請求項１に記載の情報処理装置。
15. 前記プロキシ・ノードは、前記第２のノードが前記制限を超えたデータ送信を行なったときには、前記第２のノードに通知する、
    請求項１４に記載の情報処理装置。
16. 情報処理装置が備える起動部が、第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
    前記情報処理装置が備えるプロキシ管理部が、前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
    を有し、
    前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
    情報処理方法。
17. 第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
    前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
    としてコンピュータを機能させるようにコンピュータ可読形式で記述され、
    前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
    コンピュータ・プログラム。

Images