JP2011118867A - 遠隔プラグイン装置、ロボットプラグイン実行エンジン装置及びロボットプラグイン実行システム - Google Patents

Abstract

【課題】ロボットの各プラグイン（モジュール）を遠隔地で実行することで、ロボット応用を動的に構成し、多数のコンピューティングリソースを活用する。
【解決手段】ロボット１００にはロボットプラグインを実行するためのロボットプラグイン実行エンジン装置１１０が搭載され、遠隔地コンピュータ２００には多数の遠隔プラグイン装置２１０が搭載される。ロボットプラグインはローカル又は遠隔プラグインになることができ、遠隔プラグインを遠隔地のロボットにローディングして実行するが、遠隔プラグインはロボットプラグイン実行エンジン装置が搭載されたコンピューティングノードとは異なるコンピューティングノードで実行されるプラグインであり、多数の遠隔地コンピュータで実行される各プラグインはロボットプラグイン実行エンジン装置に登録した後、それに相応する各種サービスの提供を受けることができる。
【選択図】図１

Description

本発明はロボットプラグイン技法に関し、更に詳しくは、ロボットの各プラグイン（モジュール）を遠隔地で実行することで、ロボット応用を動的に構成し、多数のコンピューティングリソースを活用するのに適した遠隔プラグイン装置、ロボットプラグイン実行エンジン装置及びロボットプラグイン実行システムに関する。

従来のロボットソフトウェアは各機能を担当するモジュールが静的に結合されて１つの実行プログラムで実体化され、それがロボットに搭載されて実行する構造を有するのが一般的であった。

しかしながら、このような方式はロボットプラットフォームの変更、ロボットモジュールの機能向上及び変更による既存モジュールの交換時には、ロボットプログラム全体を再コンパイルしなければならないという負担があり、各モジュールの開発時に独立的な開発が難しく、ロボットの内部や外部に存在する多数のコンピューティングノードを利用できないため、非効率的であるという短所がある。

このような点を解決するための従来技術の１つとして、ロボットソフトウェアをコンポーネントで構成する方式であって、各モジュールをコンポーネント化してロボットや外部コンピューティングノードで実行する方式が挙げられる。

即ち、コンポーネント技術は遠隔地でロボット応用を構成するモジュール（コンポーネント）を実行することが可能であった。この方式では遠隔地にもロボットモジュールをローディングし、実行できるコンポーネント実行エンジンが設けられ、この遠隔エンジンがコンポーネントをローディングして実行する方式である。

従って、従来のコンポーネント技術はコンポーネント単独では実行できず、その実体化の方式も動的ライブラリ（.ｄｌｌ又は.ｓｏ）の形であった。即ち、この方式はそれぞれのコンピューティングノードにコンポーネント実行エンジンが搭載されなければならない方式である。

また、従来のコンポーネント技術は遠隔地で実行が可能であるものの、コンポーネントエンジンがコンポーネントを活用するために関連情報をプロファイルに正確に記述しなければならなかった。このプロファイル情報には他のコンポーネントとの連結性、コンポーネントインターフェースなど自らの属性を記述した情報が含まれる。従って、開発者はコンポーネント自体の開発と共にプロファイル情報を共に記述しなければならなかった。

従来の他の技術はプラグイン方式を用いたロボットソフトウェアのモジュール化方式である。

このような従来のロボットプラグイン技術はプラグインエンジンが存在するローカル上でのみモジュールをプラグインすることができた。従って、ネットワーク上に存在する各種コンピューティングリソースを効率的に活用するためにロボットプラグイン実行エンジンと他のコンピューティングノードで実行可能なモジュールを支援する必要がある。

米国特許公開第２００８-０１３３０５２号

しかしながら、ロボットソフトウェアをコンポーネントで構成する従来方式は、各コンポーネントが動作するコンピューティングノードに別途のコンポーネント実行エンジンが搭載されなければならないため、コンポーネント単独では実行が不可能である。また、コンポーネント同士の連結やコンポーネントが有するインターフェースを記述するプロファイル情報を共に提供しなければならないため、コンポーネントの開発が容易ではなく、そのため、大部分専用の開発道具を用いなければならないという短所がある。

一方、従来のプラグイン方式は、プラグイン実行エンジンが存在するコンピューティングノード上でのみプラグインが存在しなければならないため、ネットワーク上でプラグインの機能を活用できないという問題がある。

そこで、本発明は上記事情に鑑みてなされたものであって、その目的は、ロボットの各プラグイン（モジュール）を遠隔地で実行することで、ロボット応用を動的に構成し、多数のコンピューティングリソースを活用するのに適した遠隔プラグイン装置、ロボットプラグイン実行エンジン装置及びロボットプラグイン実行システムを提供することにある。

前記目的を達成するために本発明の一観点によれば、各遠隔プラグインの内部に入っている各遠隔オブジェクトを管理するオブジェクト管理者と、前記各遠隔オブジェクトが登録したシンボルをロボットプラグイン実行エンジン装置に登録して管理するシンボルサービス管理者と、前記各遠隔オブジェクトが登録した関数を前記ロボットプラグイン実行エンジン装置に登録して管理する関数サービス管理者と、前記各遠隔オブジェクトが登録した通知関数を前記ロボットプラグイン実行エンジン装置に登録して管理する通知サービス管理者と、前記各遠隔オブジェクトが登録したタイマを前記ロボットプラグイン実行エンジン装置に登録して管理するタイマサービス管理者と、ネットワークを介して前記各管理者と前記ロボットプラグイン実行エンジン装置との通信を担当する連結管理者とを含む遠隔プラグイン装置を提供する。

ここで、本発明の遠隔プラグイン装置内のオブジェクト管理者はロボットプラグイン実行エンジン装置に登録しようとする遠隔オブジェクトが生成される時、生成された遠隔オブジェクトを内部オブジェクトテーブルに格納した後、連結管理者に伝達し、シンボルサービス管理者は特定遠隔オブジェクトが外部に露出させようとするシンボルを登録する時、該当シンボルに対する名前と該当シンボルに対する参照を結合してシンボルテーブルエントリを構成した後、連結管理者に伝達し、関数サービス管理者は特定遠隔オブジェクトが外部に露出させようとする関数を登録する時、関数に対する名前と関数に対する参照を結合して関数テーブルエントリを構成した後、連結管理者に伝達し、通知サービス管理者は特定遠隔オブジェクトが登録しようとする通知サービスのために対象シンボルの名前とコールバックされる関数に対する参照が伝達される時、対象シンボルに対する名前とコールバック関数に対する参照を結合して通知テーブルエントリを構成した後、連結管理者に伝達し、タイマサービス管理者は特定遠隔オブジェクトが登録しようとするタイマサービスのためにコールバックする関数に対する参照と呼び出される周期が伝達される時、タイマ名と関数に対する参照を結合してタイマテーブルエントリを構成した後、連結管理者に伝達する。

本発明の他の観点によれば、各ローカルプラグインの内部に入っているオブジェクトを管理し、オブジェクトの登録要請がある時、それに相応するオブジェクトプロキシを生成及び登録するオブジェクト管理者と、前記各ローカルプラグインで登録したシンボルを管理し、各シンボルの参照及び変更を担当するシンボルサービス管理者と、前記各ローカルプラグインで登録した関数を管理し、各関数に対する呼び出し及び結果値の返還を担当する関数サービス管理者と、特定イベントが発生する時、該当ローカルプラグインで登録した関数を呼び出す通知サービス管理者と、特定周期別に前記各ローカルプラグインで登録した関数を呼び出すタイマサービス管理者と、ネットワークを介して前記各管理者と遠隔プラグイン装置との通信を担当する連結管理者とを含むロボットプラグイン実行エンジン装置を提供する。

ここで、本発明のロボットプラグイン実行エンジン装置内のオブジェクト管理者は、遠隔プラグイン装置から登録の要請を受けたオブジェクト名と同じ名前を有するオブジェクトプロキシ客体を生成してプロキシとして登録し、シンボルサービス管理者は遠隔プラグイン装置からシンボルの登録要請を受けた該当シンボル名と相応するプロキシオブジェクトの参照を結合してシンボルサービスエントリを構成した後、シンボルサービステーブルに登録し、関数サービス管理者は遠隔プラグイン装置から関数の登録要請を受けた関数名と呼び出される関数名を結合して関数サービスエントリを構成した後、関数サービステーブルに登録し、通知サービス管理者は遠隔プラグイン装置から通知の登録要請を受けた該当シンボル名と呼び出される関数名を結合して通知サービスエントリを構成した後、通知サービステーブルに登録し、タイマサービス管理者は遠隔プラグイン装置からタイマの登録要請を受けたタイマ名と自身が関数を結合してタイマサービスエントリを構成した後、タイマサービステーブルに登録する。

本発明の更に他の観点によれば、各遠隔プラグインの内部に入っている各遠隔オブジェクトを管理し、連結管理者を利用したネットワーク通信を通じて前記各遠隔オブジェクトが登録したシンボル、関数、通知関数、タイマをロボットプラグイン実行エンジンに登録して管理する遠隔プラグインと、各ローカルプラグインの内部に入っているオブジェクトを管理し、連結管理者を利用したネットワーク通信を通じて前記各ローカルプラグインで登録したシンボル、各関数、前記各関数に対する呼び出し及び結果値の返還、前記各関数の呼び出しをサービスする前記ロボットプラグイン実行エンジンを含むロボットプラグイン実行システムを提供する。

本発明はロボット応用プログラムがネットワーク上で散在する各種コンピューティングノードに搭載された遠隔プラグインを動的にプラグイン実行エンジンに連結されるようにすることで、以下のような効果が得られる。

第１に、ネットワークコンピューティング能力の最大化を図ることができる。即ち、ロボットソフトウェアをなす各機能をモジュール別に分け、各機能モジュールをネットワーク上で分散されたコンピューティングノードに割り当てて実行することで、各コンピューティングノードが有しているコンピューティング能力を十分に活用できるだけでなく、ロボット自体の計算要求を減少させることで、ロボットがより効率よくコンピューティングリソースを使用できる。

第２に、ソフトウェアモジュールの独立実行が可能となる。即ち、ロボットソフトウェアを構成する各モジュールをロボット遠隔プラグインで作成し、各遠隔プラグインが独立して実行可能なファイル形式で具体化される。これにより、遠隔地でプラグインを独立して実行するため、別途の実行エンジンを遠隔地で実行しなくても済むという長所がある。これは遠隔地コンピューティングリソース（メモリ、計算能力）に対する要求量を減少させて遠隔地コンピューティングリソースの効率的な使用にも貢献し、使用の便宜性も増大される。

第３に、モジュール開発の単純化が期待される。既存のコンポーネント方式のモジュール支援ではコンポーネントがコンポーネント実行エンジンに搭載されるように各種プロファイル情報を共に記述したが、本発明はこのようなプロファイル情報を不要とするため、開発者はロボット遠隔プラグインモジュールの開発にのみ集中すればよい。従って、開発過程が単純化され、開発の効率性と誤りの可能性を低減できる。

第４に、チーム開発の容易性が増大する。従来のプラグイン方式はローカルでのみプラグインが支援される方式であったため、各プラグインの開発者は同じコンピューティングリソースへ地理的にアクセス可能な場所に集まって開発及びテストを進めなければならなかった。しかしながら、本発明は遠隔地でもソフトウェアモジュールを実行し、このソフトウェアモジュールがロボットに搭載されたプラグイン実行エンジンに接続して相互作用する方式であるため、各モジュールの開発を担当する多数のチームが個別で開発を進めることが可能である。

本発明によってロボットと遠隔地コンピュータがネットワークを介して連結される構造を示すシステム系統図である。 本発明によるロボットプラグイン実行エンジン装置のブロック構成図である。 本発明による遠隔プラグイン装置のブロック構成図である。 本発明による遠隔オブジェクトとオブジェクトプロキシの構造図である。 ロボット遠隔プラグイン装置が内部にあるオブジェクトをロボットで実行中のロボットプラグイン実行エンジン装置に登録する過程を説明する構成図である。 遠隔オブジェクトが外部に露出させようとするシンボルを登録する過程を説明する構成図である。 遠隔オブジェクトが外部に露出させようとする関数を登録する過程を説明する構成図である。 遠隔オブジェクトが通知サービスを登録する過程を説明する構成図である。 遠隔オブジェクトがタイマサービスを登録する過程を説明する構成図である。 各種遠隔プラグイン装置が、各種遠隔プラグイン装置自身が持っている遠隔オブジェクトに対する登録及び初期化が完了した状態における一連の動作を示す図である。 各種遠隔プラグイン装置が、各種遠隔プラグイン装置自身が持っている遠隔オブジェクトに対する登録及び初期化が完了した状態における一連の動作を示す図である。 各種遠隔プラグイン装置が、各種遠隔プラグイン装置自身が持っている遠隔オブジェクトに対する登録及び初期化が完了した状態における一連の動作を示す図である。

以下、添付する図面を参照して本発明の好適な実施形態について詳細に説明する。

なお、下記の本発明を説明するにおいて公知となった機能又は構成などに関する具体的な説明が本発明の要旨を不要に曖昧にするおそれがあると判断される場合にはその詳細な説明を省略する。そして、後述する用語は、本発明における機能を考慮して定義されたものであって、これはユーザ、運用者などの意図又は慣例などによって変わり得るのはもちろんである。従って、その定義は本明細書の全般に渡って記述される技術思想に基づいてなされるべきである。

図１は、本発明によってロボットと遠隔地コンピュータがネットワークを介して連結される構造を示すシステム系統図であって、ロボット１００にはロボットプラグインを実行するためのロボットプラグイン実行エンジン装置１１０が搭載され、遠隔地コンピュータ２００には多数の遠隔プラグイン装置２１０が搭載される。

ここで、ロボットプラグインはローカル又は遠隔プラグインになることができ、本発明では遠隔プラグインを遠隔地のロボットにローディングして実行するが、遠隔プラグインはロボットプラグイン実行エンジン装置が搭載されたコンピューティングノードとは異なるコンピューティングノードで実行されるプラグインである。即ち、多数の遠隔地コンピュータで実行される各プラグインはロボットプラグイン実行エンジン装置に登録した後、それに相応する各種サービスの提供を受けることができる。

遠隔地コンピュータ２００の遠隔プラグイン装置２１０ではオブジェクト、シンボルサービス、関数サービス、通知サービス、タイマサービスなどと関連したプラグインをロボットプラグイン実行エンジン装置１１０に搭載し、ロボット１００のロボットプラグイン実行エンジン装置１１０では搭載されたプラグインに相応する各種サービスを遠隔プラグイン装置２１０に提供する。

図２は、本発明によるロボットプラグイン実行エンジン装置のブロック構成図であって、オブジェクト管理者１１１、シンボルサービス管理者１１２、関数サービス管理者１１３、通知サービス管理者１１４、タイマサービス管理者１１５及び連結管理者１１６などを含む。

オブジェクト管理者１１１は、それぞれの遠隔プラグインの内部に入っているオブジェクトを管理するモジュールを意味するものであって、遠隔プラグイン装置２１０からオブジェクトの登録要請がある時、これに相応して生成されるオブジェクトプロキシ客体を登録するなどの機能を行う。

次に、シンボルサービス管理者１１２は各遠隔プラグインで登録したシンボルを管理し、これらのシンボルに対する参照及び変更を担当するサービスモジュールを意味するものであって、遠隔プラグイン装置２１０からシンボルの登録要請がある時、シンボルの名前とプロキシオブジェクトの参照を結合してシンボルサービスエントリを作った後、これをシンボルサービステーブルに登録するなどの機能を行う。

また、関数サービス管理者１１３は、各遠隔プラグインで登録した関数を管理し、これらの関数に対する呼び出し及び結果値の返還を担当するサービスモジュールを意味するものであって、遠隔プラグイン装置２１０から関数の登録要請がある時、伝達を受けた関数名と呼び出される関数名を結合して関数サービスエントリを作った後、これを関数サービステーブルに登録するなどの機能を行う。

そして、通知サービス管理者１１４は特定イベントが発生した時、遠隔プラグインで登録した関数を呼び出すサービスモジュールを意味するものであって、遠隔プラグイン装置２１０から通知の登録要請がある時、伝達を受けたシンボル名と呼び出される関数名を結合して通知サービスエントリを作った後、これを通知サービステーブルに登録するなどの機能を行う。

次に、タイマサービス管理者１１５は特定周期別にローカルプラグインで登録した関数を呼び出す機能を提供するサービスモジュールを意味するものであって、遠隔プラグイン装置２１０から通知の登録要請がある時、タイマ名とコールバックされる関数を結合して作られるタイマサービスエントリをタイマサービステーブルに登録するなどの機能を行う。

最後に、連結管理者１１６は遠隔プラグイン装置２１０との通信を担当するモジュールを意味するものであって、遠隔プラグイン装置２１０からネットワークを介してオブジェクト、シンボルサービス、関数サービス、通知サービス、タイマサービスなどに対する登録要請が受信される時、それと関連したオブジェクトプロキシ客体を生成、或いはオブジェクトに相応するプロキシを探してオブジェクト管理者１１１、シンボルサービス管理者１１２、関数サービス管理者１１３、通知サービス管理者１１４、タイマサービス管理者１１５などに客体への登録を要請するなどの機能を行う。

図３は、本発明によるロボット遠隔プラグイン装置のブロック構成図であって、オブジェクト管理者２１１、シンボルサービス管理者２１２、関数サービス管理者２１３、通知サービス管理者２１４、タイマサービス管理者２１５及び連結管理者２１６などを含むが、各遠隔プラグインは多数のオブジェクト（オブジェクト１、オブジェクト２、．．．オブジェクトＮ）を定義できる。

図３を参照すれば、オブジェクト管理者２１１は、各遠隔プラグイン装置２１０の内部に入っている遠隔オブジェクトを管理するモジュールを意味するものであって、遠隔プラグイン装置２１０の内部にある遠隔オブジェクトをロボットで実行中のロボットプラグイン実行エンジン装置１１０に登録しようとする時、遠隔プラグイン装置２１０でオブジェクトが生成されれば、生成された遠隔オブジェクトを自身の内部テーブルに保管した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０側にオブジェクトの登録を要請するなどの機能を行う。

これに応答して、ロボットプラグイン実行エンジン装置１１０内の連結管理者１１６では登録の要請を受けたオブジェクト名Ａと同じ名前を有するオブジェクトプロキシ客体Ａを生成し、このように生成されたオブジェクトプロキシ客体Ａはロボットプラグイン実行エンジン装置１１０にプロキシとして登録される。

また、シンボルサービス管理者２１２は、各遠隔オブジェクトが登録したシンボルをロボットプラグイン実行エンジン装置１１０に登録して管理する役割を果たすモジュールを意味する。即ち、遠隔オブジェクトが外部に露出させようとするシンボルを登録しようとする時、遠隔オブジェクトが登録しようとするシンボル（Ａ.ｓｙｍｂｏｌ_１）とオブジェクト客体を渡せば、シンボルテーブルに該当シンボルに対する名前（Ａ.ｓｙｍｂｏｌ_１）とシンボルに対する参照（Ａ.ｓｙｍｂｏｌ_１）を結合してシンボルテーブルエントリを構成した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０側にシンボルに対する登録を要請するなどの機能を行う。これは各シンボルや関数など遠隔オブジェクトが露出させる全てのエンティティ（ｅｎｔｉｔｙ）がロボットプラグイン実行エンジン装置１１０に登録されなければ他のプラグインで活用できないためである。

これに応答して、ロボットプラグイン実行エンジン装置１１０内の連結管理者１１６ではシンボルの登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体にシンボルの登録を要請し、このようなプロキシオブジェクトは要請を受けたシンボル名とプロキシオブジェクト自身の参照をシンボルサービス管理者１１２に伝達する。その結果、シンボルサービス管理者１１２は、シンボルの名前とプロキシオブジェクトの参照を結合してシンボルサービスエントリを作った後、これをシンボルサービステーブルに登録する。

次に、関数サービス管理者２１３は、各遠隔オブジェクトが登録した関数をロボットプラグイン実行エンジン装置１１０に登録して管理する役割を果たすモジュールを意味するものであって、遠隔オブジェクトが外部に露出させようとする関数を実行エンジン装置１１０に登録しようとする時、遠隔オブジェクトが登録しようとする関数（Ａ.ｆ１）を渡せば、関数テーブルに関数に対する名前（「Ａ.ｆ１」）と関数に対する参照（Ａ.ｆ１）を結合して関数テーブルエントリを構成した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０側に関数に対する登録を要請するなどの機能を行う。

これに応答して、ロボットプラグイン実行エンジン１１０内の連結管理者１１６では関数の登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体に関数登録を要請し、このようなプロキシオブジェクトは要請を受けた関数名とこの関数が呼び出される時に、代わりに呼び出される関数（ｏｎ_ａｎｙ_ｆｕｎｃｔｉｏｎ）を関数サービス管理者１１３に登録要請し、その結果、関数サービス管理者１１３では伝達を受けた関数名（Ａ.ｆ１）と呼び出される関数名（Ａ.ｏｎ_ａｎｙ_ｆｕｎｃｔｉｏｎ）を結合して関数サービスエントリを作った後、これを関数サービステーブルに登録する。

そして、通知サービス管理者２１４は、各遠隔オブジェクトが登録した通知関数をロボットプラグイン実行エンジン装置１１０に登録して管理する役割を果たすモジュールを意味する。ロボットプラグイン実行エンジン装置１１０に登録された特定シンボルが変更される場合、これを通知するためのサービスを提供するが、例えば、シンボルの値が変更される場合、通知サービスに登録された関数を呼び出すサービスである。

まず、遠隔オブジェクトが登録しようとする通知サービスのために対象シンボルの名前とコールバックされる関数に対する参照を通知サービス管理者２１４に伝達すれば、通知サービス管理者２１４は通知テーブルにシンボルに対する名前（「Ｂ.ｓｙｍｂｏｌ_１」）とコールバック関数に対する参照（Ａ.ｏｎ_Ｂ.ｓｙｍｂｏｌ_１_ｃｈａｎｇｅｄ）を結合して通知テーブルエントリを構成した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０側に通知登録を要請するなどの機能を行う。

これに応答して、ロボットプラグイン実行エンジン装置１１０の連結管理者１１６では通知の登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体に通知登録を要請し、プロキシオブジェクトは要請を受けたシンボル名とこのシンボルが変更された時、通知を受けるコールバック関数（ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ）を関数サービス管理者１１３に登録要請する。ここで、ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ関数は該当オブジェクトが登録する全ての通知サービスのために設けられる共通コールバック関数を意味する。即ち、対象シンボルの名前が変更されてもロボットプラグイン実行エンジンに登録されるコールバック関数は同一である。その理由は、この関数を通じて相応する遠隔オブジェクトに要請を伝達する機能のみを行い、実際のコールバック関数の呼び出しは遠隔プラグイン装置で行われるためである。ロボットプラグイン実行エンジン装置１１０の通知サービス管理者１１４は、伝達を受けたシンボル名（Ｂ.ｓｙｍｂｏｌ_１）と呼び出される関数名（Ａ.ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ）を結合して通知サービスエントリを作った後、これを通知サービステーブルに登録する。

また、タイマサービス管理者２１５は、各遠隔オブジェクトが登録したタイマをロボットプラグイン実行エンジン装置１１０に登録して管理する役割を果たすモジュールを意味するものであって、タイマサービスは一定の周期毎にロボットプラグイン実行エンジン装置１１０が遠隔オブジェクトの特定関数を呼び出すサービスである。

まず、遠隔オブジェクトが登録しようとするタイマサービスのためにコールバックされる関数に対する参照（Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１）と呼び出される周期（１秒）をタイマサービス管理者２１５に伝達すれば、タイマサービス管理者２１５はタイマ名（「Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１」）と関数に対する参照（Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１）と結合してタイマテーブルエントリを構成した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０側にタイマサービスの登録を要請するなどの機能を行う。

これに応答して、ロボットプラグイン実行エンジン装置１１０の連結管理者１１６ではこの要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体にタイマサービスの登録を要請し、プロキシオブジェクトは伝達を受けたタイマ名（Ａ.ｔｉｍｅｏｕｔ_１）と自身の関数であるｏｎ_ａｎｙ_ｔｉｍｅｏｕｔを結合してタイマサービスエントリを作った後、これをタイマサービス管理者１１５に登録要請し、タイマサービス管理者１１５はタイマサービスエントリをタイマサービステーブルに登録する。ここで、ｏｎ_ａｎｙ_ｔｉｍｅｏｕｔ関数はオブジェクトが登録する全てのタイマサービスのために設けられる共通コールバック関数である。即ち、対象タイマの名前が変更されてもロボットプラグイン実行エンジン装置１１０に登録されるコールバック関数は同一である。その理由は、この関数を通じて相応する遠隔オブジェクトにタイムアウトを伝達する機能のみ行い、実際のコールバック関数の呼び出しは遠隔プラグイン装置２１０で行われるためである。

そして、連結管理者２１６はネットワークを介して遠隔プラグイン装置２１０とロボットプラグイン実行エンジン装置１１０との通信を担当するモジュールである。

図４は、本発明による遠隔オブジェクトとオブジェクトプロキシの構造を示すものであって、遠隔オブジェクト４１０は遠隔地コンピュータ２００に搭載された遠隔プラグイン装置２１０内で定義されて実体化され、オブジェクトプロキシ４２０はロボット１００に搭載されたロボットプラグイン実行エンジン装置１１０で実体化されるが、ここで、遠隔オブジェクト４１０は、登録インターフェース４１２、共通インターフェース４１４、個別インターフェース／個別データ定義部４１６からなる３つの部分の論理領域で構成され、オブジェクトプロキシ４２０は登録インターフェース４２２及び共通インターフェース４２４からなる２つの部分の論理領域で構成される。

まず、遠隔プラグイン装置２１０で登録された各オブジェクトはロボットプラグイン実行エンジン装置１１０でそれに相応するプロキシを生成するようになる。即ち、遠隔オブジェクト４１０とオブジェクトプロキシ４２０は一対で生成されて消滅する。

遠隔プラグイン装置２１０は、登録インターフェース４１２に定義されたオブジェクトに対する生成、削除を担当する関数をプラグインに伝達するが、プラグインがこの関数を呼び出すことで、特定オブジェクトに対する客体を生成又は削除するようになる。

そして、共通インターフェース４１４は、オブジェクトとプラグイン間で予め約束されたインターフェースであって、オブジェクトを初期化するためのＩｎｉｔ()、そして、オブジェクトを活性化するためのＯｎ()、オブジェクトを非活性化するためのＯｆｆ()で構成される。

また、個別インターフェース／個別データ定義部４１６は、個別オブジェクトで定義する部分であって、実際のオブジェクトで行う主要関数及びシンボルはこの部分で定義され、この部分はオブジェクトを開発する開発者が任意に定義できる。

一方、オブジェクトプロキシ４２０の場合には共通インターフェース４２４がオブジェクトを初期化するためのＩｎｉｔ()、そして、オブジェクトを活性化するためのＯｎ()、オブジェクトを非活性化するためのＯｆｆ()以外に多数のインターフェースを追加で含むが、Ｏｎ_ａｎｙ_ｔｉｍｅｏｕｔインターフェースはロボットプラグイン実行エンジン装置１１０でタイマイベントが発生した場合、これを処理するためのインターフェースであり、このインターフェースを介してロボットプラグイン実行エンジン装置１１０で発生したタイマイベントを受け取り、これを遠隔地にある相応する遠隔オブジェクトに伝達する。Ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄインターフェースは、シンボルの値が変更された時に通知を受けるためのインターフェースであって、この関数がロボットプラグイン実行エンジン装置１１０によって呼び出されると、これを再び遠隔地にある遠隔オブジェクトに伝達する役割を果たす。Ｇｅｔ_ｓｙｍｂｏｌ関数はオブジェクトのシンボル値を得るための関数であって、呼び出されれば、これを遠隔地にある遠隔オブジェクトに伝達する役割を果たす。Ｓｅｔ_ｓｙｍｂｏｌ関数はオブジェクトのシンボル値を変更するための関数であって、呼び出されれば、これを遠隔地にある遠隔オブジェクトに伝達する役割を果たす。Ｃａｌｌ_ｆｕｎｃｔｉｏｎ関数はオブジェクトの関数を呼び出すためのインターフェースであって、ロボットプラグイン実行エンジン装置１１０でこの関数を呼び出せば、これを遠隔地の遠隔オブジェクトに伝達する役割を果たす。

図５は、ロボット遠隔プラグイン装置が内部にあるオブジェクトをロボットで実行中のロボットプラグイン実行エンジン装置に登録する過程を説明する構成図である。

図５を参照すれば、遠隔プラグイン装置２１０でオブジェクトＡが生成されれば、オブジェクト管理者２１１に登録を要請する（段階５０２）。これに応答して、オブジェクト管理者２１１は該当オブジェクトＡを自身の内部テーブルに保管した後、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０にオブジェクトの登録を要請し（段階５０４）、連結管理者２１６ではオブジェクトの登録要請をロボットプラグイン実行エンジン装置１１０側に伝達する（段階５０６）。

次に、ロボットプラグイン実行エンジン装置１１０側では連結管理者１１６がオブジェクトの登録要請を受けるが、連結管理者１１６はオブジェクトの登録要請を受けたオブジェクト名Ａと同じ名前を有するオブジェクトプロキシ客体Ａを生成し（段階５０８）、このように生成されたオブジェクトプロキシ客体Ａはオブジェクト管理者１１１に伝達されてロボットプラグイン実行エンジン装置１１０にプロキシとして登録される（段階５１０）。

図６は、遠隔オブジェクトが外部に露出させようとするシンボルを登録する過程を説明する構成図である。

図６を参照すれば、遠隔オブジェクトが登録しようとするシンボル（Ａ.ｓｙｍｂｏｌ_１）とオブジェクト客体をシンボルサービス管理者２１２に渡せば（段階６０２）、シンボルサービス管理者２１２ではシンボルテーブル２２１に該当シンボルに対する名前（Ａ.ｓｙｍｂｏｌ_１）と該当シンボルに対する参照（Ａ.ｓｙｍｂｏｌ_１）を結合してシンボルテーブルエントリを構成する（段階６０４）。その後、シンボルサービス管理者２１２は、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０にシンボルに対する登録を要請し（段階６０６）、連結管理者２１６ではシンボルの登録要請をロボットプラグイン実行エンジン装置１１０側に伝達する（段階６０８）。ここで、各シンボルや関数など遠隔オブジェクトが露出させる全てのエンティティはロボットプラグイン実行エンジン装置１１０に登録されなければ、他のプラグインで活用できない。

次に、シンボルの登録要請を受けたロボットプラグイン実行エンジン装置１１０内の連結管理者１１６は、シンボルの登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体にシンボルの登録を要請する（段階６１０）。その後、プロキシオブジェクトは要請を受けたシンボル名とプロキシオブジェクト自身の参照をシンボルサービス管理者１１２に伝達する（段階６１２）。

これに応答して、シンボルサービス管理者１１２は、該当シンボルの名前とプロキシオブジェクトの参照を結合してシンボルサービスエントリを作った後、シンボルサービステーブル１２１に登録する（段階６１４）。

図７は、遠隔オブジェクトが外部に露出させようとする関数を登録する過程を説明する構成図である。

図７を参照すれば、遠隔オブジェクトが登録しようとする関数（Ａ.ｆ１）を関数サービス管理者２１３に渡せば（段階７０２）、関数サービス管理者２１３は関数テーブル２２２に該当関数に対する名前（「Ａ.ｆ１」）と該当関数に対する参照（Ａ.ｆ１）を結合して関数テーブルエントリを構成する（段階７０４）。その後、関数サービス管理者２１３は、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０に関数に対する登録を要請し（段階７０６）、連結管理者２１６では関数の登録要請をロボットプラグイン実行エンジン装置１１０側に伝達する。

次に、ロボットプラグイン実行エンジン装置１１０側では連結管理者１１６が関数の登録要請を受けるが、連結管理者１１６はオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体に関数の登録を要請する（段階７０８）。

その後、プロキシオブジェクトが要請を受けた関数名とこの関数が呼び出される時に、代わりに呼び出される関数（ｏｎ_ａｎｙ_ｆｕｎｃｔｉｏｎ）を関数サービス管理者１１３に登録要請すれば（段階７１０）、関数サービス管理者１１３は伝達を受けた関数名（Ａ.ｆ１）と呼び出される関数名（Ａ.ｏｎ_ａｎｙ_ｆｕｎｃｔｉｏｎ）を結合して関数サービスエントリを作った後、関数サービステーブル１２２に登録する（段階７１２）。

図８は、遠隔オブジェクトが通知サービスを登録する過程を説明する構成図である。

図８を参照すると、通知サービスはロボットプラグイン実行エンジン装置１１０に登録された特定シンボルが変更される場合、これの通知を受けるサービスであって、該当シンボルの値が変更される場合、通知サービスに登録された関数を呼び出すサービスである。

まず、遠隔オブジェクトが登録しようとする通知サービスのために対象シンボルの名前とコールバックされる関数に対する参照を通知サービス管理者２１４に伝達すれば（段階８０２）、通知サービス管理者２１４は通知テーブル２２３に該当シンボルに対する名前（「Ｂ.ｓｙｍｂｏｌ_１」）とコールバック関数に対する参照（Ａ.ｏｎ_Ｂ.ｓｙｍｂｏｌ_１_ｃｈａｎｇｅｄ）を結合して通知テーブルエントリを構成する（段階８０４）。その後、通知サービス管理者２１４は、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０に通知に対する登録を要請し（段階８０６）、連結管理者２１６では通知の登録要請をロボットプラグイン実行エンジン装置１１０側に伝達する。

次に、ロボットプラグイン実行エンジン装置１１０側では連結管理者１１６が通知の登録要請を受けるが、連結管理者１１６は通知の登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体に通知登録を要請する（段階８０８）。

その後、プロキシオブジェクトは要請を受けたシンボル名とこのシンボルが変更された時、通知を受けるコールバック関数（ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ）を通知サービス管理者１１４に登録要請する（段階８１０）。前述したように、ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ関数は該当オブジェクトが登録する全ての通知サービスのために設けられる共通コールバック関数である。

これに応答して、通知サービス管理者１１４は、伝達を受けたシンボル名（Ｂ.ｓｙｍｂｏｌ_１）と呼び出される関数名（Ａ.ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ）を結合して通知サービスエントリを作った後、これを通知サービステーブルに１２３登録する（段階８１２）。

図９は、遠隔オブジェクトがタイマサービスを登録する過程を説明する構成図である。

図９を参照すれば、タイマサービスは一定の周期毎にロボットプラグイン実行エンジン装置１１０が遠隔オブジェクトの特定関数を呼び出すサービスである。

まず、遠隔オブジェクトが登録しようとするタイマサービスのためにコールバックされる関数に対する参照（Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１）と呼び出される周期（１秒）をタイマサービス管理者２１５に伝達すれば（段階９０２）、タイマサービス管理者２１５はタイマテーブル２２４にタイマ名（「Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１」）と関数に対する参照（Ａ.ｏｎ_ｔｉｍｅｏｕｔ_１）を結合してタイマテーブルエントリを構成する（段階９０４）。その後、タイマサービス管理者２１５は、連結管理者２１６を通じてロボットプラグイン実行エンジン装置１１０にタイマに対する登録を要請し（段階９０６）、連結管理者２１６ではタイマの登録要請をロボットプラグイン実行エンジン装置１１０側に伝達する。

次に、ロボットプラグイン実行エンジン装置１１０側では連結管理者１１６がタイマの登録要請を受けるが、連結管理者１１６はタイマの登録要請を送ったオブジェクトに相応するプロキシを探し（オブジェクトプロキシＡ）、この客体にタイマサービスの登録を要請する（段階９０８）。

その後、プロキシオブジェクトは伝達を受けたタイマ名（Ａ.ｔｉｍｅｏｕｔ_１）と自身の関数であるｏｎ_ａｎｙ_ｔｉｍｅｏｕｔを結合してタイマサービスエントリを作った後、タイマサービス管理者１１５に登録を要請する（段階９１０）。前述したように、ｏｎ_ａｎｙ_ｔｉｍｅｏｕｔ関数は該当オブジェクトが登録する全てのタイマサービスのために設けられる共通コールバック関数である。

これに応答して、タイマサービス管理者１１４はタイマサービスエントリをタイマサービステーブル１２４に登録する（段階９１２）。

図１０Ａから図１０Ｃは、各種遠隔プラグイン装置が自身が持っている遠隔オブジェクトに対する登録及び初期化が完了した状態における一連の動作を示す図である。

図１０Ａから図１０Ｃを参照すると、本例示では２つの遠隔オブジェクト（例えば、障害物検知オブジェクト、障害物回避オブジェクト）が用いられるが、各オブジェクトは互いに異なる遠隔プラグイン装置１２００、１３００に定義されている。また、各遠隔プラグイン装置１２００、１３００は互いに異なるコンピューティングノードで行われる。従って、本例示ではロボットと他の２つのコンピューティングノードを合せて計３個のコンピューティングノードが活用される。

本例示の全体的な流れは障害物検知オブジェクトのｆｉｎｄ_ｏｂｓｔａｃｌｅ関数が一定の周期でロボットプラグイン実行エンジン装置１１００によって呼び出される。このとき、ｆｉｎｄ_ｏｂｓｔａｃｌｅ関数は障害物とロボットとの距離を測定して障害物が存在すると判断されれば、自身のｏｂｓｔａｃｌｅ_ｆｏｕｎｄシンボルにこれを設定する。この設定が変更されれば、このシンボルの値が変更された時、通知を受けると登録した障害物回避オブジェクトのｏｎ_ｏｂｓｔａｃｌｅ_ｆｏｕｎｄ関数が呼び出され、障害物回避のためにａｖｏｉｄ_ｏｂｓｔａｃｌｅ関数を呼び出すようになる。このようなシナリオ上で各段階別の流れを説明すれば、以下の通りである。

（１）タイマサービス管理者１１０２によってｄｅｔｅｃｔｏｒ.ｔｉｍｅ_ｏｕｔ１タイマが１秒毎にタイムアウトされる。このとき、このタイマと連結されたｄｅｔｅｃｔｏｒ.ｏｎ_ａｎｙ_ｔｉｍｅｏｕｔコールバック関数が１秒毎に呼び出されて障害物検知オブジェクトプロキシ１１２０に伝達される。

（２）、（３）ｄｅｔｅｃｔｏｒ.ｏｎ_ａｎｙ_ｔｉｍｅｏｕｔ関数の呼び出しを受けた障害物検知オブジェクトプロキシ１１２０は、これを連結管理者１１０８、１２０６を通じて障害物検知オブジェクトに伝送する。

（４）遠隔プラグイン装置１２００の連結管理者１２０６は、タイマサービス管理者１２０２にｄｅｔｅｃｔｏｒ.ｔｉｍｅ_ｏｕｔ１がタイムアウトされたことを知らせる。

（５）タイマサービス管理者１２０２は、ｄｅｔｅｃｔｏｒ.ｔｉｍｅ_ｏｕｔ１タイマに該当するコールバック関数（ｄｅｔｅｃｔｏｒ.ｆｉｎｄ_ｏｂｓｔａｃｌｅ）を呼び出す。

（６）障害物検知オブジェクトは、ｆｉｎｄ_ｏｂｓｔａｃｌｅ関数で障害物との距離を計算した後、障害物があると判断されれば、ｄｅｔｅｃｔｏｒ.ｏｂｓｔａｃｌｅシンボルの値を変更するようにシンボルサービス管理者１２０４に要請する。

（７）、（８）シンボルサービス管理者１２０４は該当シンボルの値を変更するために、ロボットプラグイン実行エンジン装置１１００側に該当シンボルの値を変更するよう要請するが、このような要請は連結管理者１２０６を通じてロボットプラグイン実行エンジン装置１１００側に伝達される。

（９）シンボル値の変更を要請されたロボットプラグイン実行エンジン装置１１００側の連結管理者１１０８は、シンボルサービス管理者１１０４に該当値を変更するよう要請する。

（１０）シンボルサービス管理者１１０４は該当変数の値を変更した後、該当シンボルに通知サービスが登録されているか通知サービス管理者１１０６にサービスを要請する。

（１１）通知サービス管理者１１０６は、ｄｅｔｅｃｔｏｒ.ｏｂｓｔａｃｌｅ_ｆｏｕｎｄというシンボル名に該当する通知コールバックが登録されているか調べる。ここでは、ａｖｏｉｄｅｒ.ｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄというコールバック関数が登録されているため、該当関数を呼び出す。このとき、該当シンボル名（ｄｅｔｅｃｔｏｒ.ｏｂｓｔａｃｌｅ_ｆｏｕｎｄ）をパラメータとして伝達する。

（１２）、（１３）障害物回避オブジェクトプロキシ１２２は、連結管理者１１１０を通じて呼び出しを受けたｏｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄ関数で自身と相応する遠隔オブジェクトである障害物回避オブジェクトに連結管理者１１１０を通じてこの事実を通報する。

（１４）遠隔プラグイン装置１３００側の連結管理者１３０４はシンボル値の通知サービスの要請を受け、該当シンボル名（ｄｅｔｅｃｔｏｒ.ｏｂｓｔａｃｌｅ_ｆｏｕｎｄ）を通知サービス管理者１３０２に伝達する。

（１５）通知サービス管理者１３０２は該当シンボル名（ｄｅｔｅｃｔｏｒ.ｏｂｓｔａｃｌｅ_ｆｏｕｎｄ）をもってこのシンボルに登録されたコールバック関数であるａｖｏｉｄｅｒ.ａｖｏｉｄ_ｏｂｓｔａｃｌｅ関数を呼び出す。この関数の呼び出しを受けたａｖｏｉｄｅｒ障害物回避オブジェクトはａｖｏｉｄ_ｏｂｓｔａｃｌｅ関数を呼び出して障害物を回避する。

（１６）１秒毎に（２）〜（１５）過程を繰り返し行うことで、ロボットプラグイン実行エンジン装置１１００は障害物が現れる度に障害物回避プロセスを起動させる。

以上の説明では、本発明の好適な実施形態を提示して説明したが、本発明は必ずしもこれに限定されるものではなく、本発明の属する技術分野において通常の知識を有する者であれば、本発明の技術的思想から逸脱しない範囲内で様々な置換、変形及び変更が可能であることが容易に分かる。

１００ ロボット
１１０ ロボットプラグイン実行エンジン装置
１１１、２１１ オブジェクト管理者
１１２、２１１ シンボルサービス管理者
１１３、２１３ 関数サービス管理者
１１４、２１４ 通知サービス管理者
１１５、２１５ タイマサービス管理者
１１６、２１６ 連結管理者

Claims (17)

1. 各遠隔プラグインの内部に入っている各遠隔オブジェクトを管理するオブジェクト管理者と、
   前記各遠隔オブジェクトが登録したシンボルをロボットプラグイン実行エンジン装置に登録して管理するシンボルサービス管理者と、
   前記各遠隔オブジェクトが登録した関数を前記ロボットプラグイン実行エンジン装置に登録して管理する関数サービス管理者と、
   前記各遠隔オブジェクトが登録した通知関数を前記ロボットプラグイン実行エンジン装置に登録して管理する通知サービス管理者と、
   前記各遠隔オブジェクトが登録したタイマを前記ロボットプラグイン実行エンジン装置に登録して管理するタイマサービス管理者と、
   ネットワークを介して前記各管理者と前記ロボットプラグイン実行エンジン装置との通信を担当する連結管理者と
   を含む遠隔プラグイン装置。
2. 前記オブジェクト管理者は、
   前記ロボットプラグイン実行エンジン装置に登録しようとする遠隔オブジェクトが生成される時、前記生成された遠隔オブジェクトを内部オブジェクトテーブルに格納した後、前記連結管理者に伝達することを特徴とする請求項１に記載の遠隔プラグイン装置。
3. 前記シンボルサービス管理者は、
   特定遠隔オブジェクトが外部に露出させようとするシンボルを登録する時、該当シンボルに対する名前と前記該当シンボルに対する参照を結合してシンボルテーブルエントリを構成した後、前記連結管理者に伝達することを特徴とする請求項１に記載の遠隔プラグイン装置。
4. 前記関数サービス管理者は、
   特定遠隔オブジェクトが外部に露出させようとする関数を登録する時、該当関数に対する名前と前記該当関数に対する参照を結合して関数テーブルエントリを構成した後、前記連結管理者に伝達することを特徴とする請求項１に記載の遠隔プラグイン装置。
5. 前記通知サービス管理者は、
   特定遠隔オブジェクトが登録しようとする通知サービスのために対象シンボルの名前とコールバックされる関数に対する参照が伝達される時、前記対象シンボルに対する名前とコールバック関数に対する参照を結合して通知テーブルエントリを構成した後、前記連結管理者に伝達することを特徴とする請求項１に記載の遠隔プラグイン装置。
6. 前記タイマサービス管理者は、
   特定遠隔オブジェクトが登録しようとするタイマサービスのためにコールバックする関数に対する参照と呼び出される周期が伝達される時、前記タイマ名と関数に対する参照を結合してタイマテーブルエントリを構成した後、前記連結管理者に伝達することを特徴とする請求項１に記載の遠隔プラグイン装置。
7. 前記各遠隔オブジェクトは、
   各オブジェクトに対する生成、削除を定義する登録インターフェースと、
   各オブジェクトとプラグイン間で予め約束されたインターフェースを提供する共通インターフェースと、
   実際にオブジェクトで行う主要関数及びシンボルを定義する個別インターフェース／個別データ定義部と
   を含むことを特徴とする請求項１〜６の何れか１項に記載の遠隔プラグイン装置。
8. 前記共通インターフェースは、
   オブジェクトを初期化するためのＩｎｉｔ()、オブジェクトを活性化するためのＯｎ()、オブジェクトを非活性化するためのＯｆｆ()で構成されることを特徴とする請求項７に記載の遠隔プラグイン装置。
9. 各ローカルプラグインの内部に入っているオブジェクトを管理し、オブジェクトの登録要請がある時、それに相応するオブジェクトプロキシを生成及び登録するオブジェクト管理者と、
   前記各ローカルプラグインで登録したシンボルを管理し、各シンボルの参照及び変更を担当するシンボルサービス管理者と、
   前記各ローカルプラグインで登録した関数を管理し、各関数に対する呼び出し及び結果値の返還を担当する関数サービス管理者と、
   特定イベントが発生する時、該当ローカルプラグインで登録した関数を呼び出す通知サービス管理者と、
   特定周期別に前記各ローカルプラグインで登録した関数を呼び出すタイマサービス管理者と、
   ネットワークを介して前記各管理者と遠隔プラグイン装置との通信を担当する連結管理者と
   を含むロボットプラグイン実行エンジン装置。
10. 前記オブジェクト管理者は、
    前記遠隔プラグイン装置から登録の要請を受けた該当オブジェクト名と同じ名前を有するオブジェクトプロキシ客体を生成してプロキシとして登録することを特徴とする請求項９に記載のロボットプラグイン実行エンジン装置。
11. 前記シンボルサービス管理者は、
    前記遠隔プラグイン装置からシンボルの登録要請を受けた該当シンボル名と相応するプロキシオブジェクトの参照を結合してシンボルサービスエントリを構成した後、シンボルサービステーブルに登録することを特徴とする請求項９に記載のロボットプラグイン実行エンジン装置。
12. 前記関数サービス管理者は、
    前記遠隔プラグイン装置から関数の登録要請を受けた該当関数名と呼び出される関数名を結合して関数サービスエントリを構成した後、関数サービステーブルに登録することを特徴とする請求項９に記載のロボットプラグイン実行エンジン装置。
13. 前記通知サービス管理者は、
    前記遠隔プラグイン装置から通知の登録要請を受けた該当シンボル名と呼び出される関数名を結合して通知サービスエントリを構成した後、通知サービステーブルに登録することを特徴とする請求項９に記載のロボットプラグイン実行エンジン装置。
14. 前記タイマサービス管理者は、
    前記遠隔プラグイン装置からタイマの登録要請を受けた該当タイマ名と自身の関数を結合してタイマサービスエントリを構成した後、タイマサービステーブルに登録することを特徴とする請求項９に記載のロボットプラグイン実行エンジン装置。
15. 前記オブジェクトプロキシは、
    各オブジェクトに対する生成、削除を定義する登録インターフェースと、
    各オブジェクトとプラグイン間で予め約束されたインターフェースを提供する共通インターフェースと
    を含むことを特徴とする請求項９〜１４の何れか１項に記載のロボットプラグイン実行エンジン装置。
16. 前記共通インターフェース部は、
    オブジェクトを初期化するためのＩｎｉｔ()、オブジェクトを活性化するためのＯｎ()、オブジェクトを非活性化するためのＯｆｆ()、前記ロボットプラグイン実行エンジン装置でタイマイベントが発生した場合、これを処理するためのＯｎ_ａｎｙ_ｔｉｍｅｏｕｔインターフェース、シンボルの値が変更された時、通知を受けるためのＯｎ_ａｎｙ_ｓｙｍｂｏｌ_ｃｈａｎｇｅｄインターフェース、オブジェクトのシンボル値を得るためのインターフェースを提供するＧｅｔ_ｓｙｍｂｏｌ関数、オブジェクトのシンボル値を変更するためのインターフェースを提供するＳｅｔ_ｓｙｍｂｏｌ関数、オブジェクトの関数を呼び出すためのインターフェースを提供するＣａｌｌ_ｆｕｎｃｔｉｏｎ関数で構成されることを特徴とする請求項１５に記載のロボットプラグイン実行エンジン装置。
17. 各遠隔プラグインの内部に入っている各遠隔オブジェクトを管理し、連結管理者を利用したネットワーク通信を通じて前記各遠隔オブジェクトが登録したシンボル、関数、通知関数、タイマをロボットプラグイン実行エンジンに登録して管理する遠隔プラグインと、
    各ローカルプラグインの内部に入っているオブジェクトを管理し、連結管理者を利用したネットワーク通信を通じて前記各ローカルプラグインで登録したシンボル、各関数、前記各関数に対する呼び出し及び結果値の返還、前記各関数の呼び出しをサービスする前記ロボットプラグイン実行エンジンと
    を備えるロボットプラグイン実行システム。

Images