【発明の詳細な説明】
仮想ロボット
本発明は仮想ロボットに関する、すなわち、例えば、研究所での実験または工
業的生産における自動化されたプロセス・シーケンスなどのロボットおよび自動
式機械を制御する方法およびデバイスに関する。
一般にロボットと呼ばれるデバイスが特殊な制御プログラムによって様々な動
作を実行する自動化されたプロセス・シーケンスは、多くの産業分野や研究所で
用いられている。例えば、ヒトゲノム・プロジェクトでは、ヒトゲノムを分離す
るためにＤＮＡの何回もの製造を実行する必要がある。この所望の目的を達成す
るためには、製造ロボットによって自動式製造を実現する必要がある。
しかしながら、従来、このような自動式デバイスまたはロボットの制御および
／または制御プログラムは、使用されているロボットに合うように個々に調整さ
れ整合されてきた。したがって、既存のロボットの交換または別のタイプのさら
なるロボットを追加することによる自動化の拡張には、既存の制御ソフトウエア
の修正、拡張、さらに極端な場合には、完全な交換が必要となる。
したがって、本発明の課題は、広い範囲の様々なロボットに簡単に整合させる
ことが可能なロボットまたは自動式デバイスを制御するための仮想ロボット(vir
tual robot)を開発することである。
この課題は独立請求項に記載された特徴によって解決される。本発明の好まし
い装置は従属請求項の主題である。
現実機械を制御するための本発明による仮想ロボットは、好ましくは抽象機械
を制御するためのソフトウエアＩＣ「コントローラ」と、現実に制御される機械
の抽象環境を記述するＩＣ「モデル」と、抽象機械の言語を生成および使用する
ためのＩＣ「トランスレータ」と、コントローラの事象によって異なる抽象ロボ
ットの動作を実現するためのＩＣ「ロボット」と、コントローラ事象に依存する
現実のロボットの動作を実現するための「ロボット・デバイス」と、現実機械の
現行の内部状態を表示装置に送出するかまたは現実の動作をシミュレートするＩ
Ｃための「見本」と、を備えている。
ソフトウエアＩＣである「見本」と「ロボット・デバイス」は、ＩＣ「見本」
と「ロボット・デバイス」のインタフェースが定義されている抽象的な基本的ク
ラス「視界」から引き出すことが可能である。さらに、ソフトウエアＩＣ「視界
」を「モデル」は抽出によって、「コントローラ」との簡略化された通信を可能
とする共通インタフェースを受け取ることができる。ＩＣ「トランスレータ」は
、２つのオブジェクト・クラス「文法」と「語彙」を含む混合クラス「言語」か
らなり、クラス「文法」は抽象機械の動作および方法の規則を定義し、一方クラ
ス「語彙」はこの目的のために必要な用語を含んでいる。クラス「モデル」とは
、そのインタフェース上を通過してそのサブクラスまで至るようなものであり、
インタフェースは現実に使用されるロボット環境(world)の抽象モデルを含んで
いる。
制御を実行するために、「トランスレータ」は、操作されるプロセスに関する
情報を包含することになっているデータセットを「コントローラ」から受け取り、
「トランスレータ」はその行の文法と語彙をチェックしてそれをコマンド行とし
て受容し、「トランスレータ」はその行の内容を、自分が利用可能なＩＣ「文法
」と「語彙」の助けを借りて抽象的パラメータに変換し、「次に「トランスレー
タ」はこれらのプログラム・パラメータを「コントローラ」に返送し、そして「
コントローラ」はこのプログラム・パラメータで仮想ロボットのデバイス制御を
開始する。
デバイスの制御にはまた、すべての「視界」のログオン、ＩＣ「モデル」中へ
のプログラム・パラメータのロードおよびＩＣ「モデル」中へのプロセス環境の
セットアップが含まれる。現実ロボットの制御を実行するために、プロセス環境
が適切にセットアップされた後で、クロック・パルス・ゼネレータ「タイマー」
または例えばセンサーのような他の何らかの観察装置が始動される。プロセス環
境の限界がチェックされ、この環境の限界に達しない場合には、問題となってい
るプロセスのステップが実行され、一方、環境の限界に達した場合には、仮想ロ
ボットは終了し、したがって現実ロボットの制御が終了する。
有利には、様々な現実ロボットを起動するためのソフトウエアは、容易に修正
可能なビルディングブロック、すなわち前記のソフトウエアＩＣからなってる。
ソフトウエアのこのオブジェクト指向設計は４つのステップで実行される：
１．関連するオブジェクトを識別する；
２．適切な細分性を持つクラスに対して抽象化する；
３．インタフェースとインヘリタンス階層を規定する；
４．オブジェクト間の中心的関係を規定する。
このようなソフトウエアＩＣを用いることによる特殊な効果は、ソフトウエア
に対する改良がなされている場合、該ソフトウエアＩＣを含んでいるソフトウエ
アはすべて同じように改良されることである。ソフトウエアＩＣの簡単な交換可
能性は、正確に定義されたインタフェースを介して排他的に互いに通信する定義
済み限界のソフトウエアユニットが存在することによって達成される。ＩＣ内の
コードは完全にカプセル化されており、すなわち発生するデータ処理の内部要素
はすべて外部、すなわち他のＩＣからはアクセス不可能である。
本発明の好ましい１態様を以下の図面を参照して説明する。
図１は、クラス「言語」の構造を示し、
図２は、「トランスレータ」と「言語」間の接続を示し、
図３は、クラス「視界」の構造を示し、
図４は、抽象「ロボット」の規定を示し、
図５は、抽象「コントローラ」の「オブザーバ」テンプレートを示し、
図６は、クラス「コントローラ・インタフェース」の定義を示し、
図７は、クラス「モデル」のためのインヘリタンス階層を示し、
図８は、仮想ロボット全体の線図であり、
図９は、ＩＣ「トランスレータ」に関する事象のフローチャートを示し、
図１０は、ＩＣ「トランスレータ」の事象フローチャートを示し、そして
図１１は、詳細の焦点がＩＣ「トランスレータ」である、仮想ロボットの詳
細な事象フローチャートである。
オブジェクト指向プログラミングにおいて、最初のステップは、オペレーティ
ング・ソフトウエアに対する問題記述である。ここでは、外部プロセスがオペレ
ーティング・ソフトウエアを起動し、それに、例えば、実行する予定の動作に関
する情報、すなわち、真空チャンバを制御するソフトウエアの項目、真空ポンプ
の動作時
間、バルブの数、これらの開放に関する時間データなどのプログラムの実行時に
必要とされるパラメータを転送する。これらのデータはプログラム・パラメータ
に変換しなければならない。これは、適切な文法と語賃を有するパーザ(parser)
によって実行される。「文法」という用語はここでは必要な機能を意味し、「語
彙」という用語は必要なデータを意味するものと解釈することができる。操作さ
れているロボットの制御は、特定の時間にロボットに対して発行する必要がある
連続的なコマンドによって実行される。したがって、必要な同期を取ることがで
きるクロックパルスゼネレータ(clock pulse generator)を有する必要がある。
さらに、現行の実行状態に関する状態報告、すなわち画面の出力装置が必要であ
る。加えて、現行のコマンドが制御ソフトウエアからロボットに運搬されるよう
に通信インタフェースが必要である。
オブジェクト指向プログラミングの第２の分析ステップでは、関連のオブジェ
クトは適切な細分性を持つクラス中に抽象化される。操作される予定の個々の機
械またはロボットは一般的な設計にとっては不適切なオブジェクトであるが、そ
の理由は、これらは依存性に対する直接的な記号であるからである。これらは抽
象ロボットまたはより一般的には、タイマー制御式入出力機能に関連する抽象的
な「機械」に取って代わられることになる。オペレーティング・ソフトウエアの
観点からは、この「機械」は所与のパラメータによって制御されるべきオブジェ
クトである。したがって、「コントローラ」という名称を有するソフトウエアＩ
Ｃが第１のオブジェクトとして提供される。ＩＣ「コントローラ」はオペレーテ
ィング・システムのクロックに対するインタフェースを含んでいる。ＩＣ「コン
トローラ」に対する動作を定義するデータは、その抽象的な環境(系)に直接関連
している。例えば、ＡからＢへオブジェクトを移動させるグリッパ・ロボットを
操作する場合、座標データすべてはその感知範囲に関連する。したがって、その
環境は座標とその関連する座標に向かう運動からなる。例えばピペッティング・
ロボットなどの他のロボットにおいては、温度および時問データのみがその制御
にとっては重要である。すなわち、その環境は温度と時間というパラメータで成
り立っている。その結果として、抽象機械「コントローラ」はその環境に関する
抽象的な記述を有しなければならない。したがって、クラス「モデル」が必要で
ある。
監視するためには、使用者は、抽象機械「コントローラ」の内部状態に関連す
る情報を提供されなければならない。これは現在の状態を画面に出力することに
よって行う。そのオブジェクトは単に「画面」と呼んでもよいが、その結果、設
計は不必要に規定され、そしてかなりのポテンシャルを失うことになる。モデル
のデータセットに変更を加えると、画面上の出力は即座に新しい状況に整合させ
なければならない。しかしながら、これは画面についてだけではなく操作中の実
際の機械にも当てはまることである。モデルが変更されると、アプリケーション
の視界も同様に変化する。第３のクラスの一般的な表現形態はしたがって「視界
」と呼ぶことができる。それには、画面出力と機械との直接的な通信の双方が含
まれ、したがってどの場合でも同じ形態の変更である。
「コントローラ」がモデルを変更すると、それに依存するＩＣ「視界」はこの
変更について通知を受ける。
抽象機械「コントローラ」は、ソフトウエアの外部項目からオン・デマンドで
送信された新しい要求について通知を受けなければならない。この情報はキーワ
ードを持った行という形態で与えられる。このキーワードによって直後の情報が
識別される。この情報はクラス「モデル」と等しく機械依存型である。概して、
ここでは、ＩＣ「モデル」に直接に関連する情報すべてが与えられる。したがっ
て、問題となっている抽象機械にとっては、問題となっている要求の文法（機能
）および語彙（データ）の双方を有するトランスレータが必要とされる。第４の
クラスはしたがって「トランスレータ」と定義される。文法および語彙は、この
関連において、最も広い変動を設計に導入する２つの要素である。この状況は、
「言語」という名称を有する第５のオブジェクトによって反映させることが可能
である。
次のタスクとして、クラス間のインタフェースおよびインヘリタンス階層を規
定しなければならない。オブジェクト「コントローラ」、「モデル」および「視
界」は連結を解かれるが、同期させなければならない。オブジェクトに対する変
更は、他のオブジェクトに対して影響を及ぼすが、変更されたオブジェクトにと
って他のオブジェクトを正確に認識する必要はない。これが「オブザーバ・テン
プレート」の定義である。したがってこれら３つのオブジェクトの設計は、「オ
ブザーバ・テンプレート」を基本としている。
「トランスレータ」オブジェクトはプログラムの開始時に使用されるだけであ
る。このオブジェクトは「コントローラ」と正確に同じ時間長にわたって存在す
る必要はない。これによって、送信された情報の評価用の接続をするための簡単
な結合の可能性が提供される。
図１に示した「言語」オブジェクトは、「文法」および「語彙」という要素を
合成したものである。原則として、言語の文法はメソッドとして公式化すること
が可能であり、一方、語彙はそのデータであると解釈することができる。これは
クラスに対する古典的な定義、すなわちデータとそのデータで命令される動作を
組み合わせたものという定義である。しかしながら、このような設計は、この２
つの要素を独立に変更することは不可能であるという制限を課すものである。例
えば、この２つの要素を１つの、そして同じクラスに統合した場合、同じ語彙に
異なる文法を適用することはばかげている。これら２つの要素を別々のクラスと
して解釈し、また、「言語」クラス内のインヘリタンスによってそれらを統合す
るには多くの方法がある。例えば、「言語」オブジェクトは、図１に示すように
、混合クラスの１例として理解できる。したがって、「語彙」オブジェクトに影
響を及ぼすことなく、「文法」オブジェクトを将来的な開発において変更するこ
とが可能である。
図２に「トランスレータ」オブジェクトとその「言語」オブジェクト間の接続
を示す。この接続は、「トランスレータ」オブジェクトが存在する限り、その「
言語」オブジェクトは必要であるという問題に起因している。したがって、結合
は接続としては排除しなければならない。原則として、インヘリタンスまたは集
合化の可能性が残る。インヘリタンスは、関連のオブジェクトを、まるで「系統
樹的に」、互いから生成させることができるようにするためのオブジェクト指向
設計（＝ＯＯＤ）の要素である。集合体はＯＯＤでは合成の要素と見なされ、す
なわち、「このオブジェクトは…からなる」とか「オブジェクトＡは自身が完全
に存在する間にタスクＸのためにオブジェクトＢを用い…」ということになる。
したがって、「トランスレータ」クラスは、図２に示すように、単数の集合体中
で「言語」クラスに接続される。
図３に「視界」オブジェクトのネスティングを示す。２つの視界「画面」と「
ロボット・デバイス」は単純な「複合テンプレート」に従って誘導される。「コ
ント
ローラ」は様々な機械を操作（例えば、真空チャンバの場合における空気の循環
的真空排気）するためのアルゴリズムを実現し、したがって、それは「戦略テン
プレート」の１例である。クラス「視界」は、自身から誘導された具象的なクラ
スのインタフェースが定義された抽象的な基本的クラスである。この設計によっ
て、あらゆる視界に対するインタフェースの一貫性は保証される。「見本」はク
ラスであり、は現在の内部状態を画面上に図形として出力する責任がある例であ
る。クラス「ロボット・デバイス」は個々のインタフェースを、操作する予定の
ロボットの関連のハードウエアに収納する。このクラスは、適用されたクラスに
よってハードウエア依存性という問題を解決するアダプタ・クラスである。この
適用されたクラスには、操作予定のデバイスの名称が与えられる。
最大フレキシビリティを達成するために、クラス・アダプタではなく図４に示す
オブジェクト・アダプタが使用される。したがって、プログラムの実行時間中に
は、単にオブジェクトを交換することによって異なる目標デバイスを操作するこ
とが可能である。上記の「視界」オブジェクト用のこのオブジェクト・アダプタ
は図４に示すオブジェクト構成を用いる。オブジェクト「ＶＣ−デバイス」は操
作予定のすべての他のロボットを表している。
ここに提案されるソフトウエアでは、図５に示した「コントローラ」オブジェ
クトが、本願の中心である。それは、自身に依存するオブジェクトにログオンし
、これによって将来、そのオブジェクトに発生するあらゆる変更を通知する。そ
の場合、なんらかを変更した信号が送出される。関連のクラスは、依存するオブ
ジェクトを照会によって新しい状態に同期させることが可能なインタフェースを
有する。この場合、依存するオブジェクトとは、基礎を成すアプリケーションで
は３つの異なったタイプのロボットを表す「ＣＳＲ」、「ＰＣＲ」および「真空
チャンバ」である。
この依存するオブジェクトは、自分自身に関連する情報を自分で獲得する責任
がある。「コントローラ」オブジェクトは「トランスレータ」オブジェクトから
入手可能なデータを評価し、そして所与のプロトコルを実行する。「コントロー
ラ」はコンピュータのシステム・クロックにアクセスし、そしてインタフェース
を介して後者からタイミングを獲得する。
「コントローラ」クラスは抽象物であり、誘導されたすべてのクラスによって
継
承されるインタフェースを定義する。共通インタフェースを通じて、それから誘
導されたクラスは簡単な方法で交換することが可能である。したがって、個々の
ロボットによって異なる方法は、図５に示すように、「オブザーバ・テンプレー
ト」を基本とするこの提案によって解決される。
図６に示した「モデル」オブジェクトは、問題となっている機械の環境を表す
。「トランスレータ」から得られたデータは、プログラム実行時間の初期のステ
ップで「コントローラ」を介して「モデル」に転送される。したがって、「モデ
ル」は同様にオブザーバであり、そして「オブザーバ」テンプレートの場合のよ
うにログオンされる。「モデル」クラスは抽象的であり、さらに、インヘリタン
スにより、この例では、別々の３つのロボットに対応する「ＰＣＲモデル」、「
ＣＳＲモデル」および「Ｖａｃモデル」を指定するその特殊な機械依存タスクに
分割される。
これらの目的のために、「モデル」は「視界」と同じインタフェースを有する
。「モデル」は、インタフェース上を通過するために、抽象的基本的クラス「視
界」から誘導されることができるが、それは現実を正確に表すものではない。こ
の考えに従うと、その設計はより長い期間にわたって誤りの発生源を含むことに
なる。例えば、基本的クラス「視界」を、それによって異なる「モデル」クラス
を考慮することなくさらに発展させると、好ましくない結果となりかねない。し
たがって、図７に示すように、純粋なインタフェースは「視界」クラスから抽象
化され、分離クラス「コントローラ・インタフェース」が定義され、これに基づ
いてクラス「モデル」と「視界」の双方に対して結果が導き出せる。「コントロ
ーラ・インタフェース」オブジェクトは、「コントローラ」オブジェクトと相互
作用しなければならないすべてのオブジェクトに対してこのインタフェースの一
貫性を保証する。
この抽象化の結果として、インタフェースのさらなる展開は問題とはならない
が、その理由は、修正によって影響されるクラスすべては後者を即座に継承する
からである。したがって要約すると、その結果が、図８に示した仮想ロボットの
オブジェクト・モデルである。この例では、ＰＣＲはピペッティング・ロボット
であり、ＣＲＳはグリッパ・ロボットであり、Ｖａｃすなわち真空チャンバは自
動式真空チャンバである。
図９〜図１１に、システムとそのオブジェクトの動的で外部に対して可視であ
る
動作モードをグラフ形態で示す。アルゴリズムによって規定される内部動作は、
外部的発言を有しない限り考慮されない。事象すべては最初に識別され、その後
で初めてオブジェクトに供給される。したがって、動的モデルの結果として、オ
ブジェクト内で表された設計が効果があるかどうかについてのさらなるチェック
が得られる。例えば、状態図が、「トランスレータ」に焦点を合わせた図９〜図
１１で例示的に実行されたと同じように、各オブジェクトに対して設定される。
「トランスレータ」のためのシナリオ
通常の場合：
「トランスレータ」が操作されるプロセスのための情報を含むことになっている
行を「コントローラ」から受け取る。
「トランスレータ」はその行の文法と語彙をチェックして、その行をコマンド行
として受容する。
「トランスレータ」は、自身にとって利用可能な文法と語彙の助けによってその
行の内容をプログラム関連のパラメータに変換する。
トランスレータはこれらのプログラム・パラメータを「コントローラ」に返送す
る。
極端な場合：
「トランスレータ」は、操作されるプロセス用の情報を含むものとされる行を「
コントローラ」から受け取る。
「トランスレータ」は行の文法と語彙をチェックして、文法に欠陥があるのでそ
の行を容認しない。
「トランスレータ」は「コントローラ」にそのコマンド行は欠陥があることを通
知して終了する。
誤りの入力：
「トランスレータ」は操作されるプロセスのための情報を含むことになっている
行を「コントローラ」から受け取る。
「トランスレータ」は転送された行が無効であることを確認する。
「トランスレータ」は欠陥のある情報行が受け取られたことをコントローラに通
知して終了する。
最後に、図１１は、図９と１０に示す関連事項をプログラム全体に埋め込む詳
細な「トランスレータ」に焦点を合わせた自明の事象フロー・プランである。
これらの図で用いられる表記法は、オブジェクト指向設計では慣用のものであ
り、例えばアーノルド・ヒッカースバーガーによる１９９３年、ハイデルベルグ
のヒューティッヒ出版(Huethig Verlag)の「オブジェクト指向ソフトウエアへの
道」（Der Weg zur objektorientierten Software）に記載されている。DETAILED DESCRIPTION OF THE INVENTION
Virtual robot
The present invention relates to virtual robots, i.e.
Robots and automation, such as automated process sequences in industrial production
Method and device for controlling a mechanical machine
A device generally called a robot is operated in various ways by a special control program.
Automated process sequences that perform the work are used in many industries and laboratories.
Used. For example, the Human Genome Project separates the human genome
Multiple productions of DNA must be performed in order to achieve this. Achieve this desired purpose
For this purpose, it is necessary to realize automatic manufacturing by a manufacturing robot.
However, conventionally, the control and control of such automated devices or robots
And / or the control program is individually adjusted to suit the robot used.
Have been aligned. Therefore, replacing an existing robot or another type of
To extend automation by adding more robots, existing control software
Modifications, extensions and, in extreme cases, complete replacements are required.
Therefore, the task of the present invention is to easily adapt to a wide range of different robots
Virtual robot (vir
tual robot).
This problem is solved by the features described in the independent claims. Preferred of the present invention
The inventive device is the subject of the dependent claims.
The virtual robot according to the invention for controlling a real machine is preferably an abstract machine
Software "controller" for controlling the machine and the machine actually controlled
Generating and using an IC "model" that describes the abstract environment of a computer and the language of an abstract machine
IC for translators and abstract robots that vary depending on controller events
Depends on the IC "robot" to realize the operation of the unit and the controller event
“Robot device” to realize the operation of a real robot and real machine
I to send the current internal state to a display device or simulate real operation
And a "sample" for C.
The "sample" and "robot device" that are software ICs are
Abstract basic tasks that define the interface between
It is possible to pull out from the lath "field of view". In addition, the software IC “Visibility
"Model" can be extracted to enable simplified communication with "Controller"
Can be received. IC "Translator"
A mixed class "language" containing two object classes "grammar" and "vocabulary"
The class "grammar" defines the rules of operation and method of abstract machines, while the class
The "vocabulary" contains the terms needed for this purpose. What is a class "model"?
, Passing over that interface to its subclass,
The interface includes an abstract model of the robot environment (world) actually used
I have.
To perform control, a “translator” is involved in the process being manipulated.
Receive from the "controller" the dataset that is to contain the information,
The "translator" checks the grammar and vocabulary of the line and makes it a command line.
The "translator" accepts the contents of the line and uses the "grammar"
To abstract parameters with the help of "" and "vocabulary"
Returns these program parameters to the controller, and
The controller uses these program parameters to control the device of the virtual robot.
Start.
Controlling the device also involves logging on all "sights" and into IC "models"
Load of program parameters and process environment into IC "model"
Setup included. Process environment to execute the control of the real robot
After the clock is properly set up, the clock pulse generator "timer"
Or some other observation device, such as a sensor, is activated. Process ring
Environmental limits are checked and if this environmental limit is not reached, it is a problem.
Virtual process when the environmental steps are reached.
The bot ends, and the control of the real robot ends.
Advantageously, the software for launching various real robots is easily modified
It consists of possible building blocks, ie the software ICs mentioned above.
This object-oriented design of the software is performed in four steps:
1. Identify related objects;
2. Abstract for classes with appropriate granularity;
3. Define the interface and inheritance hierarchy;
4. Defines central relationships between objects.
The special effect of using such a software IC is
If improvements have been made to the software, the software containing the software IC
A is to be improved in the same way. Easy replacement of software IC
Performance is a definition that communicates exclusively with each other through precisely defined interfaces
This is achieved by the existence of a software unit with a limited margin. In IC
The code is completely encapsulated, that is, the internal elements of the data processing that occur
Are inaccessible externally, ie, from other ICs.
One preferred embodiment of the present invention will be described with reference to the following drawings.
FIG. 1 shows the structure of the class "language",
Figure 2 shows the connection between "Translator" and "Language",
FIG. 3 shows the structure of the class “view”,
FIG. 4 shows the definition of an abstract "robot",
FIG. 5 shows the “observer” template of the abstract “controller”,
FIG. 6 shows the definition of the class “controller interface”,
FIG. 7 shows the inheritance hierarchy for the class “model”;
FIG. 8 is a diagram of the entire virtual robot.
FIG. 9 shows a flow chart of events for the IC "Translator",
FIG. 10 shows the event flow chart of the IC "Translator", and
FIG. 11 shows the details of a virtual robot whose details are focused on an IC “translator”.
It is a detailed event flowchart.
The first step in object-oriented programming is operating
This is a problem description for the operating software. Here, the external process operates
Start the software and add it to the
Information, that is, items of software for controlling the vacuum chamber, vacuum pump
During operation
During the execution of the program, such as the duration, the number of valves and the time data on their opening
Transfer the required parameters. These data are the program parameters
Must be converted to This is a parser with the proper grammar and vocabulary
Performed by The term "grammar" here means the required function,
The term "vocabulary" can be interpreted as meaning the required data. Operation
Robot control must be issued to the robot at a specific time
Executed by successive commands. So you can get the necessary synchronization
It is necessary to have a clock pulse generator that can be used.
In addition, a status report on the current execution status, that is, a screen output device is required.
You. In addition, the current commands are transferred from the control software to the robot.
Requires a communication interface.
In the second analysis step of object-oriented programming, the related object
Objects are abstracted into classes with the appropriate granularity. Individual machines to be operated
Machines or robots are inappropriate objects for general design, but
Because they are direct symbols for dependencies. These are extracted
Abstraction associated with an elephant robot or, more generally, a timer-controlled input / output function
Would be replaced by a simple "machine". Operating software
From a point of view, this "machine" is the object to be controlled by a given parameter.
It is an act. Therefore, software I with the name "controller"
C is provided as the first object. IC "controller" is an operator
Interface to the clocking system clock. IC "Con
The data that defines the behavior for a Troller is directly related to its abstract environment (system)
are doing. For example, a gripper robot that moves an object from A to B
When operating, all coordinate data is related to its sensing range. Therefore,
The environment consists of coordinates and movement towards their associated coordinates. For example, pipetting
In other robots such as robots, only temperature and time data are controlled
Is important to us. That is, the environment is defined by temperature and time parameters.
Standing. As a result, the abstract machine "controller"
Must have an abstract description. So we need a class "model"
is there.
To monitor, the user must be able to relate to the internal state of the abstract machine "controller".
Information must be provided. This is to output the current state to the screen
This is done. The object may simply be called a "screen", but as a result
The meter is unnecessarily defined and loses considerable potential. model
As you make changes to the existing dataset, the on-screen output is immediately adapted to the new situation.
There must be. However, this is not only about the screen, but also during operation.
The same is true for the machines at the moment. When the model changes, the application
Also changes in the same way. A third class of common forms of expression is therefore "Visibility
". It includes both screen output and direct communication with the machine.
Rare and therefore the same form of change in each case.
When the “controller” changes the model, the IC “visibility” that depends on it changes this model.
Be notified about changes.
The abstract machine “controller” is available on demand from external software items.
You must be notified about new requests sent. This information is
It is given in the form of a row with a code. With this keyword, the information immediately after
Be identified. This information is equivalent to the class "model" and is machine dependent. generally,
Here, all the information directly related to the IC "model" is provided. Accordingly
For the abstract machine in question, the grammar (function
) And vocabulary (data) are required. Fourth
Classes are therefore defined as "translators". Grammar and vocabulary
In relation, there are two factors that introduce the widest variation into the design. This situation is
Can be reflected by a fifth object with the name "language"
It is.
The next task is to define the interfaces between classes and the inheritance hierarchy.
Must be specified. Objects "controller", "model" and "view"
The "world" is disconnected, but must be synchronized. Changes to objects
Changes affect other objects, but not changed objects.
It is not necessary to accurately recognize other objects. This is "Observer Ten
Plate ”. Therefore, the design of these three objects is
Buzzer template ".
The "translator" object is only used at the start of the program.
You. This object exists for exactly the same amount of time as the "controller".
Need not be. This makes it easy to make a connection for evaluation of the information sent
New coupling possibilities are provided.
The “language” object shown in FIG. 1 includes elements “grammar” and “vocabulary”.
It is a composite. In principle, the grammar of the language should be formulated as a method
Is possible, while the vocabulary can be interpreted as the data. this is
The classic definition of a class: data and the actions dictated by that data.
It is a definition of a combination. However, such a design is
It imposes the restriction that it is not possible to change one element independently. An example
For example, if you combine these two elements into one and the same class,
Applying different grammars is ridiculous. Separate these two elements into separate classes
And integrate them by inheritance within the "language" class.
There are many ways to do this. For example, the "language" object is as shown in FIG.
, Can be understood as an example of a mixed class. Therefore, the “vocabulary” object has a shadow
The "grammar" object can be changed in future developments without affecting
And it is possible.
Figure 2 shows the connection between the "Translator" object and its "Language" object
Is shown. This connection will keep the "translator" object as long as its "
The "language" object stems from the problem of need. Therefore, join
Must be excluded as a connection. In principle, inheritance or collection
The possibility of merging remains. Inheritance describes related objects as if they were
Object-oriented so that they can be generated from each other
It is an element of design (= OOD). Aggregates are considered elements of composition in OOD,
That is, "This object consists of ..." or "Object A is itself complete.
, While using the object B for the task X ... ".
Therefore, the “translator” class is, as shown in FIG.
Is connected to the "language" class.
FIG. 3 shows the nesting of the “view” object. Two views "screen" and "
The "robot device" is guided according to a simple "composite template". "Ko
Account
Rollers "operate various machines (eg air circulation in the case of vacuum chambers)
Implements an algorithm for dynamic vacuum pumping)
"Plate". The class `` Visibility '' is a concrete class derived from itself.
Is an abstract basic class that defines the interface of With this design
Thus, the consistency of the interface for all views is guaranteed. "Sample"
Is an example that is responsible for outputting the current internal state as a graphic on the screen.
You. The class "robot device" will operate individual interfaces
Store in the related hardware of the robot. This class is
Therefore, it is an adapter class that solves the problem of hardware dependency. this
The applied class is given the name of the device to be operated.
Shown in Figure 4 instead of class adapter to achieve maximum flexibility
Object adapter is used. Therefore, during the execution time of the program
Can operate different target devices simply by swapping objects.
And it is possible. This object adapter for the "view" object above
Uses the object configuration shown in FIG. The object "VC-device" is
It represents all the other robots that will be made.
The software proposed here uses the “controller” object shown in FIG.
Is the heart of the present application. It logs on to objects that depend on itself
, Thereby notifying you of any future changes to the object. So
In the case of, a signal in which something has been changed is transmitted. The related class is
Interface that can synchronize objects to a new state by query
Have. In this case, the dependent object is the underlying application
“CSR”, “PCR” and “Vacuum” represent three different types of robots
Chamber ".
This dependent object is responsible for obtaining its own relevant information
There is. The "controller" object comes from the "translator" object
Evaluate available data and execute given protocol. "control
La ”accesses the computer's system clock and interfaces
Gain timing from the latter via.
The "controller" class is an abstraction, and all derived classes
Succession
Define the interface to be accepted. Through the common interface
Derived classes can be exchanged in a simple way. Therefore, individual
The method that differs depending on the robot is as shown in FIG.
This proposal is based on "G".
The "model" object shown in FIG. 6 represents the environment of the machine in question.
. The data obtained from the “translator” is the initial stage of program execution time.
Transferred to the “model” via the “controller” Therefore, "mode
Is also an observer, and as in the case of the Observer template
You are logged on as follows. The "model" class is abstract, and
In this example, the “PCR model” corresponding to three separate robots, “
Its special machine-dependent tasks that specify "CSR model" and "Vac model"
Divided.
For these purposes, "model" has the same interface as "view"
. The "model" is the abstract base class "visual
It can be derived from the "world", but it does not accurately represent reality. This
According to the idea, the design will include sources of error for a longer period of time.
Become. For example, the basic class "view" and the different "model" classes
Further development without consideration of this may lead to undesirable results. I
Thus, as shown in Figure 7, the pure interface is abstracted from the "view" class.
The separation class “controller interface” is defined and based on this
Results can be derived for both classes "model" and "sight". "Control
Interface object interacts with the controller object.
One of this interfaces for all objects that must act
Guarantee persistence.
As a result of this abstraction, further development of the interface is not a problem
But the reason is that all classes affected by the modification immediately inherit the latter
Because. Therefore, in summary, the result is that of the virtual robot shown in FIG.
It is an object model. In this example, the PCR is a pipetting robot
And the CRS is a gripper robot and the Vac or vacuum chamber is
It is a dynamic vacuum chamber.
Figures 9-11 show the dynamic and external visibility of the system and its objects.
To
The operating mode is shown in graphical form. The internal operation defined by the algorithm is
Not considered unless you have external remarks. All events are identified first, then
Is supplied to the object for the first time. Therefore, as a result of the dynamic model,
Further checks to see if the design represented in the object works
Is obtained. For example, if the state diagram focuses on the "translator", FIG.
It is set for each object in the same way as the example executed in FIG.
Scenario for "Translator"
Normal case:
"Translator" is supposed to contain information for the process being operated on
Receive a row from the "controller".
The "translator" checks the grammar and vocabulary of the line and replaces the line with the command line
Accept as.
"Translators" use their available grammar and vocabulary to help
Converts the contents of a line into program-related parameters.
The translator sends these program parameters back to the "controller"
You.
In extreme cases:
The "translator" replaces the line that is supposed to contain information for the operated process with "
Controller. "
The translator checks the grammar and vocabulary of the line and finds that the grammar is flawed.
Do not tolerate rows.
The "translator" informs the "controller" that the command line is defective.
Know and end.
Incorrect input:
"Translator" is to contain information for the process being operated on
Receive a row from the "controller".
The "translator" verifies that the transferred row is invalid.
The "translator" informs the controller that a defective line of information has been received.
Know and end.
Finally, FIG. 11 shows details of embedding the related items shown in FIGS. 9 and 10 into the entire program.
A self-explanatory event flow plan focused on a detailed "translator".
The notation used in these figures is conventional in object-oriented design.
For example, Heidelberg, 1993, by Arnold Hickersberger.
Huetig Verlag's "Object-Oriented Software
Road "(Der Weg zur objektorientierten Software).
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 カウアー，ゲルハルト
ドイツ連邦共和国 Ｄ―38124 ブラウン
シュヴァイク、マッシャーオーダー ヴェ
ーク １────────────────────────────────────────────────── ───
Continuation of front page
(72) Inventors Kauer and Gerhard
Federal Republic of Germany D-38124 Brown
Schweig, Masher Order V
Talk 1