JP4750944B2

JP4750944B2 - オブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供するためのシステムと方法ならびにそのシステムと方法を使用した分散制御システム

Info

Publication number: JP4750944B2
Application number: JP2000508056A
Authority: JP
Inventors: ステインマン，ジェスロ・エフ; ハイマー，リチャード・ピイ; カンジ，エム・グラム
Original assignee: ハネウエル・インコーポレーテッド
Priority date: 1997-08-22
Filing date: 1998-08-19
Publication date: 2011-08-17
Anticipated expiration: 2018-08-19
Also published as: US5890155A; DE69803468D1; EP1005673B1; DE69803468T2; WO1999010805A1; JP2001514414A; CA2295536A1; AU9199198A; CN1267377A; EP1005673A1

Description

【０００１】
（発明の技術分野）
本発明は、一般に、計算および処理システムに関し、特に、オブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供する計算および処理システムならびにそれを使用した分散制御システムに関する。
【０００２】
（発明の背景）
自動プロセス制御システムは、たとえば製造設備内で様々なプロセスを制御し監視するために、アルゴリズムまたはソフトウェアで定義可能な多数のプロセス制御ルーチンを含んでいる。制御システムは、全体的にまたは設備の指定された部分内で広い範囲のプロセス要件を満足させるように調整することができる。通常、制御システムは様々なモジュールを含んでおり、各モジュールはそれ自体のプロセッサまたはファームウェアを有しており、通信バスによって互いにリンクされ、その結果分散プロセス制御システムを形成している。システムの分散性質により、設備中の拡張または変更を満足させるためにシステムを増分式に拡大する能力とともに高い性能が得られる。
【０００３】
プロセス制御システムは一般に、ユーザがカスタム制御戦略、例えばソフトウェアで定義可能なプロセス制御ルーチンを作成するために使用できる手段を設けている。完全な制御戦略は、「ブロック」、「パラメータ」、および「接続」と呼ばれるより小さい構成要素から構築される。ブロックはデータおよび基本的な制御計算のアルゴリズムをカプセル化するために使用されるソフトウェア構成であり、パラメータはブロック内の個別のデータへのインタフェースを定義し、接続によってデータがブロックのパラメータ間を流れることができる。
【０００４】
実時間プロセス・コントローラを実現するために使用されるソフトウェアは、異なる設計思想に基づくことができる。１つの思想は、アルゴリズムと基本的な制御アルゴリズムを囲むデータがカプセル化されたオブジェクト内で実装されるオブジェクト指向方法を使用することであり、この思想を使用すると、「ブロック」とはオブジェクトであり、オブジェクトの属性は「パラメータ」を含み、オブジェクトの振る舞いは実装された制御アルゴリズムである。この方法はいくつかの利点を有し、利点の中には、制御アルゴリズムとそのデータを緊密に結合すること、データの所有者としてのアルゴリズムの、データの変更に権限を与える能力、データの所有者としてのアルゴリズムの、要求された状態の変化の有効性についてシステムのユーザに「連絡」する能力が含まれる。
【０００５】
しかし、オブジェクト指向方法は、他の方法より処理オーバーヘッドが多くなる原因となる場合があるという欠点を有する。純粋にオブジェクト指向方法では、ブロック自体の介入がなければブロックのパラメータへのアクセスを外部のアルゴリズムに与えることはできず、そのためにはブロックがサブルーチンを実行し、パラメータを読み込むあるいは書き込むことが必要となる。サブルーチンの実行が適切であり、オーバーヘッドは重要でない場合もあるが、サブルーチンの実行が処理リソースの無駄である場合もある。
【０００６】
したがって、当該技術で要求されているのは、オブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供するめのシステムと方法ならびにそのシステムと方法を使用した分散制御システムであり、そのシステムと方法は、制御ブロックのブロックの設計者が、サブルーチンの実行を通じて、あるいは、ここでは「密接な」アクセスと定義されているそれほどカプセル化されていないがさらに効率のよいアクセス形式を通じてパラメータ・アクセスを選択できる手段を提供しなければならない。
【０００７】
（発明の概要）
本発明の主な目的は、上に論じられた従来技術の欠点に対処するために、アルゴリズム・ブロック設計に融通性を与え、データ転送の効率を高めるための複数のタイプのデータ・アクセスを提供することにある。
【０００８】
上記の主な目的を達成するために、本発明は、オブジェクト指向コントローラ内にカプセル化されたデータ参照を提供するためのシステムと方法ならびにそのシステムまたは方法を使用した分散実時間制御システムを提供する。１つの実施例では、システムは（１）クライアント・アルゴリズム・ブロックが、アドレスに格納されたデータへの直接的なアクセスを得ることができるようにアドレスに対する要求を生成するクライアント・アルゴリズム・ブロックと、（２）その要求を受信し、評価して、（２ａ）サプライヤ・アルゴリズム・ブロックがその要求を許可した場合には、そのアドレスをクライアント・アルゴリズム・ブロックに送り、そのクライアント・アルゴリズム・ブロックがそのデータへの直接的なアクセスを得ることができるようにし、（２ｂ）サプライヤ・アルゴリズム・ブロックがその要求を拒否した場合には、そのアドレスを保留し、クライアント・アルゴリズム・ブロックがそのデータへの間接的なアクセスを得るように強制するサプライヤ・アルゴリズム・ブロックとを含む。
【０００９】
したがって、本発明は複数のタイプのデータ・アクセスを用いる概念を導入する。直接的なアクセスはサプライヤ・アルゴリズム・ブロックがアクセスに含まれる必要がないため一般により早く、間接的なアクセスはサプライヤ・アルゴリズム・ブロックがアクセスを制御するため一般により安全である。
【００１０】
本発明の一実施態様によれば、クライアント・アルゴリズム・ブロックは構成時に要求を生成する。したがって、タイミングの制約が存在する時には、データ交換のための経路を形成する接続は実行時間ではなくシステムが構成される時に決めることができる。もちろん、本発明は構成時における生成に限定されない。
【００１１】
本発明の一実施態様では、サプライヤ・アルゴリズム・ブロックは、クライアント・アルゴリズム・ブロックに強制して、明示的なサブルーチン・コールを通じてデータへの間接的なアクセスを得させる。当業者であれば、従来技術内でデータ・アクセスの独占的な方法を提供した「ゲット（ｇｅｔ）」サブルーチンと「格納する（ｓｔｏｒｅ）」サブルーチンを熟知しているであろう。本発明はさらに、間接的なアクセスの文脈内でこのようなサブルーチンの使用も許可する。
【００１２】
本発明の一実施態様では、サプライヤ・アルゴリズム・ブロックは所定の規則に基づいて各パラメータについての要求を異なったように評価する。これらの規則は、以下の種々の考慮によって刺激されるが、考慮はこれらに限定されるものではない。種々の考慮とは、パラメータが割り当てられた格納セルを有するかまたはアクセス時に計算されるかどうか、そのパラメータについて高速アクセスが重要かどうか、密接なアクセスを許可することがソフトウェアの失敗の可能性を大きく増大させるかどうかなどである。
【００１３】
本発明の一実施態様によれば、データはパラメータに関連し、パラメータは（１）直接的なアクセスがサポートされているかどうか、（２）直接的なアクセスがサポートされている場合には関連するセルの位置、（３）直接的なアクセスがサポートされていない場合にはサーバ・アルゴリズム・ブロックの位置からなる情報グループから選択された少なくとも１つに関連する情報を含む。これらのまた他のタイプの情報はデータがアクセスされる別の方法を識別するために使用される。
【００１４】
本発明の一実施態様によれば、アドレスはクライアント・アルゴリズム・ブロックに関連する持続性ポインタに含まれる。当業者であれば、持続性オブジェクト、すなわちメモリ・アドレスへの持続性ポインタは熟知しているであろう。本発明はアルゴリズム・ブロック間の接続の生成をさらに効率的にするために、ポインタの持続性を使用することができる。
【００１５】
本発明の一実施態様によれば、制御システムは分散実時間プロセス制御システムである。しかし当業者であれば、本発明が提供する複数レベルのデータ・アクセスに、他のオブジェクト指向アプリケーションを使用することを容易に思いつくであろう。
【００１６】
前記は、以下に記述される本発明の詳細な記述を当業者がよりよく理解できるように、本発明の特徴と技術的な利点をかなりおおまかに概略したものである。本発明のさらなる特徴と利点は本発明の請求項の主題を形成する以下に記述される。当業者であれば、概念と開示された具体的な実施形態を、本発明の同じ目的を実施するための変更または他の構成の設計の基礎として容易に使用できることを理解されたい。当業者であればまた、これらの同等の構成が本発明のもっとも広い形の精神と範囲から離れるものではないことが理解されるであろう。
【００１７】
本発明とその利点のさらに完全な理解のために、次に、付随する、同様な数字は同様な部分を示す図面と、以下の詳細な記述を参照する。
【００１８】
（詳細な説明）
本発明のシステムと方法の実施形態の記述を行う前に、本発明が適切に使用されるか実装される計算または処理システム環境を記述すると役立つであろう。まず図１を参照すると、本発明が適切に使用される例としての、分散実時間制御システム（全体的に１００と示される）の機能図が図示されている。
【００１９】
説明のために、プロセス制御システム１００はサーバ１１０とコントローラ・ネットワーク１１１を有するコンピュータ・ネットワークを含む。コントローラ・ネットワーク１１１は、サーバ１１０とプロセス制御コントローラ（全体的に１２１と示される）の間のインタフェースを提供し、コントローラ・ネットワーク１１１は、たとえば、サーバ１１０とプロセス制御コントローラ１２１の間で管理メッセージを、プロセス制御コントローラ１２１どうしの間でピアツーピア・メッセージを運ぶ。プロセス制御コントローラ１２１は、Ｉ／Ｏネットワーク１１２を介して入力／出力（Ｉ／Ｏ）デバイス１２２と通信する。プロセス制御コントローラ１２１は、Ｉ／Ｏデバイス１２２とＩ／Ｏネットワーク１１２を介して、処理センサとアクチュエータ１３０とからのデータを制御し受信するために、ソフトウェアで定義可能なプロセス制御ルーチンを実行するようにされている。当業者であれば、種々の製品の製造に使用される電気的に制御可能なモータ、バルブ、ポンプなど種々のタイプの処理センサとアクチュエータ１３０に熟知しているであろうが、本発明の原理は特定の処理あるいは処理システムに限定されるものではなく、任意のこのようなシステムに使用し、利点を与えることが可能である。
【００２０】
一実施形態では、プロセス制御システム１００はさらに、サーバ１１０と遠隔ワークステーション（全体として１４０と示される）の間にインタフェースを提供するローカル・エリア・ネットワーク（「ＬＡＮ」）１１３を含む。遠隔ワークステーション１４０は、プロセス制御システム１００の動作を制御し監視するためにシステム・オペレータによって使用される。ＬＡＮ１１２とコントローラ・ネットワーク１１１は別のネットワークとして示されているが、同じ場合もある。また、遠隔ワークステーション１４０とプロセス制御コントローラ１２０が同じネットワーク送信媒体を共有する場合もある。当業者であれば、制御システムとオペレータのワークステーションについて別のネットワークを用意すると、分散実時間プロセス制御システムの信頼性を高めることに気づくであろう。たとえば、サーバ１１０からオペレータのワークステーション１４０への処理に関連したデータの配布に関連するＬＡＮ１１２上のネットワーク・トラフィックは、制御ネットワーク１１１を介したサーバ１１０と遠隔プロセス制御コントローラ１２０の間で送信される処理制御情報に干渉しない。
【００２１】
ソフトウェアで定義可能なプロセス制御ルーチンは、サーバ１１０、ワークステーション１４０、プロセス制御コントローラ１２１などの任意のディジタル処理システムによって実行される。図２は本発明の原理を具体化する、ソフトウェアで定義可能なプロセス制御ルーチンを実行するために使用される例としてのディジタル処理システム２００の高レベルの構成図を示す。例としてのディジタル処理システム２００は、マイクロプロセッサ２１０、非揮発性メモリ２２０、ランダム・アクセス・メモリ（「ＲＡＭ」）２３０を含む。ソフトウェアで定義可能なプロセス制御ルーチンを格納するために使用されている非揮発性メモリ２２０は、たとえば、プログラム可能な読込み専用メモリ（ＰＲＯＭ）、フラッシュＲＯＭ、磁気記憶媒体などを含む。非揮発性メモリ２２０内に格納されたソフトウェアで定義可能なプロセス制御ルーチンは、マイクロプロセッサ２１０によって実行される。マイクロプロセッサは、ルーチンが実行される時にプロセス制御ルーチンのすべてあるいは一部を格納するために、また、処理センサとアクチュエータ１３０に関連した処理制御データの格納のためにＲＡＭ２３０を使用している。ディジタル処理システム２００の記述は例としてのものであり、当業者であれば本発明の原理を使用するソフトウェアで定義可能なプロセス制御ルーチンはディジタル処理システム２００用の特定のハードウェア実装に限定されず、すべてのこのようなシステムが以下の請求項の範囲に含まれることを理解されるであろう。
【００２２】
オブジェクト指向プログラミングを使用したプロセス制御コントローラ、つまり、「オブジェクト指向コントローラ」内では、アルゴリズムとそれに関連するデータは「ブロック」と呼ばれるオブジェクトとして実装することができる。ブロック内のデータは、「パラメータ」と呼ばれる、ブロックの名付けられた属性から読み込まれたり、その属性に書き込んだりすることができる。異なるブロックの間のデータの流れは、１つのブロックの出力パラメータから第２のブロックの入力パラメータへの「接続」を確立することによって達成できる。
【００２３】
本発明の原理によれば、２つのブロックの間で接続が確立された時、１つのブロックは「参照」として働く情報を保持する。参照は、２つのブロック間のデータの流れに影響を与えることの目的のために、どのブロック、そのブロックのどのパラメータがアクセスされるべきかを定義する。参照はまた、ブール型あるいは整数型など、参照されるパラメータのデータ型などの記述的な情報を与える。参照は、入力パラメータを有するブロックによって保持され、第２のブロックの出力パラメータを指示することができ、この場合、データの流れは入力パラメータを伴うブロックが、出力パラメータを伴うブロックからデータを「ゲット」または「要求する」、「プル」技術として特徴づけられる。あるいは、参照は、出力パラメータを有するブロックによって保持され、第２のブロックの入力パラメータを指示することができ、この場合、データの流れは、出力パラメータを伴うブロックが第２のブロックの入力パラメータへデータを「格納」する「プッシュ」技術として特徴づけられる。
【００２４】
プロセス制御コントローラ設計が「プル」技術または「プッシュ」技術のどちらを使用しているか、または両方を使用しているかにかかわらず、参照を保持するブロックはここでは「クライアント・アルゴリズム・ブロック」、または簡単に「クライアント」、「クライアント・ブロック」と呼ばれ、一方、参照されるパラメータを保持するブロックはここでは「サプライヤ・アルゴリズム・ブロック」、または簡単に「サプライヤ」、「サプライヤ・ブロック」と呼ばれる。概念的には、クライアントはブロックの間のデータの流れに影響を与えるために、サプライヤ・ブロック上で動作あるいは方法を実行する原因として考えることができる。さらに、この後詳しく記述するように、サプライヤはサプライヤからクライアントへのデータの流れを実装する手続き、たとえばクライアントが所望のデータへ「直接的な」アクセスを得るかまたは「間接的な」アクセスを得るかという手続きを提供する。さらに、データの流れを実装する手続きは、要求されたデータに応答する以上のことを行うことができる。たとえば、手続きはデータへの要求に答える前にデータについての補助的な計算を実行する場合もある。
【００２５】
一実施形態では、参照がクライアントによって受信された時には、参照はコントローラ内のパラメータ・アクセスに直接適合できる内部的な形式に変換されなければならない外部的な形式であり、この変換を与える処理はここでは「バインディング」と呼ばれる。バインディングはブロックがその構成データを受信する設定動作の一部として実行でき、また参照されたブロックとパラメータが参照自体の後存在するようになる場合、ランタイム実行の一部として起動される場合もある。一般に、クライアント・ブロックは、バインディング動作を実行するための十分な情報を有し、クライアント・ブロックは、バインディング動作を自分で実行する場合もあり、または、バインディングに関連したルーチン動作を処理するサポート・エージェントに頼る場合もある。しかしどちらの場合も、この後さらに詳細に記述するように、バインディング処理は最終的にはサプライヤ・ブロック上で２つの手続きのうち１つを実行するという結果になる。すなわちニーズが「ゲット」権限のためにバインディングすることである場合は「ＢｉｎｄＧｅｔ（）」手続きが起動され、ニーズが「格納」権限の場合、「ＢｉｎｄＳｔｏｒｅ（）」手続きが起動される。各バインド要求は参照されるべきパラメータを識別するために十分な情報を含む。
【００２６】
本発明の原理を図示し説明するために、次に本発明の原理を使用したアルゴリズム・ブロックを使用した、例としてのソフトウェアで定義可能なアプリケーション３００の構成図である図３を参照する。アプリケーション３００はサプライヤ・ブロックＳＢ１、ＳＢ２と、クライアント・ブロックＣＢを含む。サプライヤ・ブロックＳＢ１はクライアント・ブロックＣＢの入力パラメータＩＰ１に接続された出力パラメータＯＰ１を有し、クライアント・ブロックＣＢはサプライヤ・ブロックＳＢ２の入力パラメータＩＰ２に接続された出力パラメータＯＰ２を有し、実行時間には、パラメータ間の接続によってデータが矢印の方向に流れる。
【００２７】
特定のアプリケーションでは、アルゴリズム・ブロック、つまりサプライヤ・ブロックＳＢ１、ＳＢ２とクライアント・ブロックＣＢは、任意の所望のソフトウェアで定義可能な処理を具体化する。これは、たとえば入力パラメータＩＰ１、ＩＰ２または出力パラメータＯＰ１、ＯＰ２によって保持されたデータを操作、使用あるいは生成することができるが、本発明の原理はブロックによって実行される特定のアルゴリズムまたは処理に限定されるものではなく、データがブロック間で共有される方法に関連する。したがって、説明のために、クライアント・ブロックＣＢは以下の性質を有するアルゴリズムの集りを含むものと仮定する。（１）入力パラメータＩＰ１はサプライヤ・ブロックＳＢ１の出力パラメータＯＰ１への接続を形成する関連するコネクタを有し、クライアント・ブロックＣＢが実行すると、サプライヤ・ブロックＳＢ１から出力パラメータＯＰ１の値をプル、またはゲットするためにコネクタ参照を使用する。（２）出力パラメータＯＰ２はサプライヤ・ブロックＳＢ１の入力パラメータＩＰ２への接続を形成する関連するコネクタを有し、クライアント・ブロックＣＢが実行すると、サプライヤ・ブロックＳＢ２の出力パラメータＯＰ２から入力パラメータＩＰ２へ値をプッシュ、あるいは格納するためにコネクタ参照を使用する。また、説明のために、サプライヤ・ブロックＳＢ１は出力パラメータＯＰ１について密接なゲット・アクセスをサポートし、サプライヤ・ブロックＳＢ２は入力パラメータＩＰ２について密接な格納アクセスをサポートしていないので、入力パラメータＩＰ２へのデータの書込みは、サプライヤ・ブロックＳＢ２のＳｔｏｒｅ（）サブルーチンによって処理されることが必要であると仮定されている。ここで使用されているように、密接な、または直接的なデータ・アクセスとは、データにアクセスするために使用される従来のサブルーチンの第２のブロックによる実行を必要としないで、第１のブロックが第２のブロックのパラメータによって保持されたデータへのアクセスを得ることができることを意味し、ここで使用されているアクセスという言葉は、ブロックのパラメータによって保持されたデータの書込みまたは格納、および読込みまたはゲットの両方を含む。
【００２８】
次に図４を参照すると、本発明の原理を使用したアルゴリズム・ブロックの設計用として、接続サブシステム・クラス図４００が図示されている。図４００はＢｏｏｃｈ概念内で実行され、当業者であれば参照により本明細書に組み込まれる、Ｂｅｎｊａｍｉｎ／Ｃｕｍｍｉｎｇｓ、１９９４の、「ＯｂｊｅｃｔＯｒｉｅｎｔｅｄＡｎａｌｙｓｉｓａｎｄＤｅｓｉｇｎＷｉｔｈＡｐｐｌｉｃａｔｉｏｎｓ」でＧｒａｄｙＢｏｏｃｈによって記述されたＢｏｏｃｈ概念を熟知しているであろう。図４００は、接続上のデータ転送をサポートするアルゴリズム・ブロックの設計内で使用される構造的な要素やクラスを図示し、ブロック、パラメータ、コネクタは異なるタイプのクラスで、各々の記述と別のクラスとの包含関係は次のように与えられる。ブロック４１０の各インスタンスはオブジェクト指向処理制御戦略の基本的な構成要素を含み、ブロック４１０のデータ要素を形成する１つまたは複数のパラメータ４２０を含む。特定の制御戦略内では、ブロックは１つまたは複数のコネクタ４３０によってともにリンクされている。
【００２９】
上記のように、ブロック・クラスのインスタンスはオブジェクト指向処理制御戦略が構成できる基本的な構成要素を形成する。ブロックはパラメータとコネクタのインスタンスを含み、パラメータはブロックのデータ要素を作り出し、コネクタはブロックが他のブロックのパラメータへの参照データを保持することを可能にする。この後記述されるように、ブロックによって実行される制御アルゴリズムはＥｘｅｃｕｔｅ（）手続きで表現され、例としてのＥｘｅｃｕｔｅ（）手続きは次に記述される。クライアント・ブロックが読込みアクセスのためにＧｅｔ（）手続き、書込みアクセスのためにＳｔｏｒｅ（）手続きを起動した時に、ブロックによって所有されているパラメータへのアクセスが起きる。ＢｉｎｄＧｅｔ（）手続きとＢｉｎｄＳｔｏｒｅ（）手続きはクライアント・ブロックまたはクライアント・ブロックの代理をするエージェントによって呼び出され、バインディング手続きを通じてこれらの独自のコネクタの値を満たす。ＢｉｎｄＧｅｔ（）手続きの特定の実装は、ブロックが密接なゲット・アクセスを許可するパラメータと、ブロックがメソッドの起動によってのみゲット・アクセスを許可するパラメータを決定する。同様に、ＢｉｎｄＳｔｏｒｅ（）手続きの特定の実装は、ブロックが密接な格納アクセスを許可するパラメータと、ブロックがメソッドの起動によってのみ格納アクセスを許可するパラメータを決定する。例としてのソフトウェアで定義可能なアプリケーション３００では、サプライヤ・ブロックＳＢ１、ＳＢ２、クライアント・ブロックＣＢという３つのブロック・クラスのインスタンスがある。本発明の原理を実装するブロック・クラスに使用されるいくつかのサンプル手続きについて例としてのＰＤＬサンプルが下に示され、その中には例としてのＧｅｔ（）、Ｓｔｏｒｅ（）、ＢｉｎｄＧｅｔ（）、ＢｉｎｄＳｔｏｒｅ（）、Ｅｘｅｃｕｔｅ（）の各手続きが含まれている。サンプルの手続きは、高レベルに抽象化されており、各手続きによって実行される処理のタイプを示すことが目的である。当業者であれば、特定のブロックメソッドを実装するために必要な符号はブロックの各タイプによって異なり、以下に提供されるＰＤＬサンプルは例としてのソフトウェアで定義可能なアプリケーション３００内で描かれたブロックに関連していることが分かるであろう。
【００３０】
「パラメータ」クラスのインスタンスは、ブロックのデータ・ベースを作り上げる個別のデータを形成する。オブジェクト指向処理制御戦略では、１つのブロックによって保持されたパラメータ値は接続のエージェンシまたは「コネクタ」クラスを通じて他のブロックによって読み込まれ、書き込まれる。パラメータ値は、工場のスタッフが処理の変化を監視できるようにプロセス制御システム内の人間のインタフェース装置によって読み込まれる場合もある。「パラメータ」クラスは任意の他のクラスをインスタンス化しない。例としてのソフトウェアで定義可能なアプリケーション３００では、パラメータ・クラスは入力パラメータＩＰ１とＩＰ２、出力パラメータＯＰ１とＯＰ２の、４つのインスタンスがある。
【００３１】
本発明の原理によれば「コネクタ」クラスのインスタンスはクライアント・ブロックがサプライヤ・ブロックのパラメータにアクセスできるようにする参照データを保持し、コネクタは「ＤａｔａＴｙｐｅ」「ＰａｒａｍｅｔｅｒＩｄｅｎｔｉｆｉｅｒ」「ｐＣｅｌｌ」「ｐＢｌｏｃｋ」のインスタンスを保持する。例としてのソフトウェアで定義可能なアプリケーション３００では、クライアント・ブロックＣＢの入力パラメータＩＰ１に関連したコネクタと、クライアント・ブロックＣＢの出力パラメータＯＰ２に関連したコネクタという２つのインスタンスのコネクタ・クラスがある。
【００３２】
１つのアプリケーション内では各接続に対して少なくとも１つのコネクタがある。コネクタ内の参照データが出力パラメータを示す時、コネクタを所有するクライアント・ブロックは接続上でデータを「プル」する。コネクタ内の参照データが入力パラメータを示す時、コネクタを所有するクライアント・ブロックは接続上でデータを「プッシュ」する。コネクタは参照を記述するために１つ以上のタイプの情報を保持する。すなわち、参照されたパラメータのデータ型、参照されたパラメータの外部的な形の識別子、参照されたパラメータの内部的な形の識別子を保持する。
【００３３】
本明細書で提供されている例としてのＰＤＬ手続きで使用されているように、外部的な識別子は「ＰａｒａｍｅｔｅｒＩｄｅｎｔｉｆｉｅｒ」と呼ばれるが、本発明の原理はこの識別子について特定のフォーマットに限定されるものではない。たとえばこの識別子が特定のブロック内で特定のパラメータを一意的に示す能力がある限り、識別子はテキストでも数字でもその組合せでもよい。また本明細書で提供されている例としてのＰＤＬ手続きで使用されているように、「ｐＣｅｌｌ」と「ｐＢｌｏｃｋ」は共に内部的な識別子を含む。密接なアクセスがサプライヤ・ブロックによって許可されている場合を除いては、ｐＣｅｌｌは空であり、密接なアクセスが許可されている時は、ｐＣｅｌｌはサプライヤ・ブロック内におけるパラメータの正確なメモリ位置（つまり、アドレス）を示す。ｐＣｅｌｌが空の場合、ｐＢｌｏｃｋは使用されており、これはＧｅｔ（）手続きやＳｔｏｒｅ（）手続きなどの総称的アクセスメソッド（本明細書では「メソッド」アクセスと定義する）がサプライヤ・ブロック上で起動できるように、サプライヤ・ブロック自体のメモリ位置を指示する。「ｐＣｅｌｌ」と「ｐＢｌｏｃｋ」はその名前が示すように「ポインタ」と考えられるが、内部的な参照はたとえば、関連するオフセットを伴うメモリ・ハンドルをポインタの代わりに使用するなど、ポインタ以外の形を取ることもあり、それも本発明の範囲の中である。
【００３４】
本発明はデータの所有者（つまりブロック）が別のブロックによってそのデータへの密接なアクセスを選択的に許可できる手続きを導入する。本明細書ではこれらの手続きは「ＢｉｎｄＧｅｔ（）」、「ＢｉｎｄＳｔｏｒｅ（）」と名付けられている。本発明の原理を示すために、図３に示された例としてのソフトウェアで定義可能なアプリケーション３００について、表１と表２が、それぞれ例としてのＢｉｎｄＧｅｔ（）手続きとＢｉｎｄＳｔｏｒｅ（）手続きについて非常に抽象化されたレベルでＣに似たプログラム設計言語（「ＰＤＬ」）の記述を提供しており、当業者であれば他の特定のソフトウェアで定義可能なアプリケーションについて同等の手続きを容易に思いつくであろう。当業者であればソフトウェアで定義可能な処理の帰納的な要件を記述するＰＤＬの使用を熟知しているであろうが、本発明の原理はこのような手続きを定義するために使用される特定の手続きや特定の符号に限定されるものではない。当業者であれば本発明の原理を実装する多くの同等の手段を容易に考えつくであろうし、このような同等の手段も本明細書内の請求項の範囲内に含まれるものである。
【００３５】
表１に提供された例としてのＢｉｎｄＧｅｔ（）手続きによって図示されたように、ＢｉｎｄＧｅｔ（）はどのパラメータが参照されているのかを識別し、サプライヤ・ブロックＳＢ１がバインディングを要求しているサプライヤ・ブロックＳＢ１のパラメータを決定できるようにする入力引数として、値「ＰａｒａｍｅｔｅｒＩｄｅｎｔｉｆｉｅｒ」を受信する。ＢｉｎｄＧｅｔ（）はそのパラメータについてサポートされているバインディングのタイプを識別するデータを戻し、このデータは例の中では「ＢｏｕｎｄＰａｒａｍｅｔｅｒＲｅｆｅｒｅｎｃｅ」と呼ばれる。ＢｏｕｎｄＰａｒａｍｅｔｅｒＲｅｆｅｒｅｎｃｅ内の情報は最終的にはコネクタ内に格納され、「ｐＣｅｌｌ」と「ｐＢｌｏｃｋ」の値としてクライアント・ブロックＣＢによってインスタンス化される。一実施形態では、ＢｉｎｄＧｅｔ（）手続きはクライアント・ブロックＣＢに対する設定動作の一部としてコールされる。
【００３６】
【表１】

【００３７】
表２に与えられた例としてのＢｉｎｄＳｔｏｒｅ（）手続きによって示されているように、ＢｉｎｄＳｔｏｒｅ（）はバインディングが要求されているパラメータを識別するようにＰａｒａｍｅｔｅｒＩｄｅｎｔｉｆｉｅｒの値を入力引数として受信する。ＢｉｎｄＳｔｏｒｅ（）は最終的にはコネクタ内に格納され、クライアント・ブロックＣＢによってｐＣｅｌｌとｐＢｌｏｃｋの値としてインスタンス化される「ＢｏｕｎｄＰａｒａｍｅｔｅｒＲｅｆｅｒｅｎｃｅ」を戻す。一実施形態では、ＢｉｎｄＳｔｏｒｅ（）手続きはクライアント・ブロックＣＢについて設定動作の一部としてコールされる。
【００３８】
【表２】

【００３９】
説明のために、本発明の原理によれば、バインド要求が、密接なゲット・アクセスが参照されているパラメータについてサポートされているかどうかを評価するためにブロックの設計者によって符号化されているＢｉｎｄＧｅｔ（）手続きへのコールとなると仮定する。密接なアクセスがサポートされている場合、ＢｉｎｄＧｅｔ（）手続きはパラメータが格納されている正しいメモリ・セル（複数可、すなわち、アドレス）の識別を可能にする内部的な形の参照を戻す。アドレス情報は指定されたセルへの直接的な読込みアクセスを実行するために、実行時に使用されるべきアクセスを要求したクライアント・ブロックへ戻される。ブロックの設計者が特定の参照されたパラメータについて密接なアクセスを許可しないようにＢｉｎｄＧｅｔ（）手続きを実装した場合、異なる形の参照が戻され、戻された参照はブロック内のセルではなくブロック自体を示し、サプライヤ・ブロック上で密接なアクセスではなく、Ｇｅｔ（）手続き（つまり「メソッド」アクセス）を起動するようにクライアント・ブロックによって使用される。
【００４０】
「格納」バインド要求の処理は本質的には「ゲット」バインド要求についての処理に類似している。ＢｉｎｄＧｅｔ（）手続き使用とＢｉｎｄＳｔｏｒｅ（）手続き使用の主な相違は、ほとんどのアプリケーションでは、ＢｉｎｄＧｅｔ（）手続きはＢｉｎｄＳｔｏｒｅ（）手続きより好ましくはかなり多くのパラメータについて密接なアクセスをサポートしているということであり、データの読込みは本来データの書込みより安全なので、密接な「ゲット」アクセスは密接な「格納」アクセスよりもより頻繁に許可される。さらに、ほとんどの処理制御戦略では、ゲット動作よりも格納動作が関連する計算を有する方が一般的であり、関連する計算はアクセスがメソッドアクセス、つまりサブルーチンの実行による場合だけに実行でき、密接なアクセスを使用している時は不可能かまたは望ましくないこともある。
【００４１】
本発明の必要な要件は、直接的な（つまり密接な）アクセスを許可する参照とメソッドアクセス（つまりサブルーチンの実行によるアクセス）だけを許可する参照との間の違いを符号化する方法があることであり、クライアント・ブロックまたはクライアント・ブロックによって使用される中間のサービスは、適切な技術によるアクセスを実行するためにこの違いを検出できる必要がある。所望のアクセスの方法を示すために必要な情報を符号化できる方法は多く、本発明の原理は特定の方法に限定されるものではなく、当業者であれば同等の技術を容易に思いつくであろう。選択される方法は部分的には本発明の原理が使用されるべきプロセス制御コントローラ内で使用されるメモリ管理の形式によって異なる。一般に、参照は次の事項を識別できる十分な情報を格納しなければならない。（１）密接なアクセスがサポートされているかどうか。（２）密接なアクセスがサポートされている場合、パラメータ格納セルの位置（つまりメモリ・アドレス）、（３）密接なアクセスがサポートされていない場合、サプライヤ・ブロックの位置（つまりメモリ・アドレス）。
【００４２】
説明のために、アプリケーション内で使用されているメモリ管理思想が、バウンド参照が単純な、持続性なポインタとして格納されているものと仮定する。この仮定の元で、ｐＣｅｌｌとｐＢｌｏｃｋの２つのポインタは参照情報を符号化するために十分である。ｐＣｅｌｌポインタとｐＢｌｏｃｋポインタは、本明細書に「コネクタ」として記載されているような参照オブジェクト内で共に格納できる。表４に示されている例としてのＰＤＬは、これらのポインタがどのように使用できるかを示す。
【００４３】
【表３】

【００４４】
一般に、コネクタはｐＣｅｌｌとｐＢｌｏｃｋの値の中に保持された内部的な形式の参照と、構成データとして受信することのできる外部的な形式の参照の両方を保持すべきである。参照の２つの形式を有することによって、パラメータ定義が存在する前に参照情報が受信された場合、コネクタは、必要に応じてバインディング手続きを起動することが可能になる。
【００４５】
参照が密接なアクセスをサポートするようにバインディングされている場合、クライアント・ブロックは、所望のアクセスを実行するために参照されたパラメータのデータ型を知っていることが好ましい。クライアント・ブロックは１つ以上の方法でデータ型を知るようになるが、本発明の原理はクライアント・ブロックが参照されたパラメータのデータ型を得る方法に限定されない。以下に記述されるように、データ型情報を得る方法には例として次の２つの方法が含まれる。（１）クライアント・ブロックによって所有された関連するパラメータのデータ型に基づいた暗示的な知識、または（２）参照されたパラメータに関連するコネクタ内のデータ型格納に基づいた明示的な知識。
【００４６】
アクセス・コントローラ・アプリケーション内の接続は、１つのブロックの出力パラメータと第２のブロックの入力パラメータの間でリンケージ（ｌｉｎｋａｇｅ）を確立する。処理制御アプリケーションあるいはその一部によっては、入力パラメータと出力パラメータのデータ型は正確に一致することが求められ、これらのアプリケーションでは、クライアント・ブロックはクライアント・ブロックによって所有されている関連するパラメータのデータ型から、参照されたパラメータのデータ型を推測できる。たとえば「プル」接続では、クライアント・ブロックは参照された出力パラメータのデータ型をその入力パラメータのデータ型から推測でき、「プッシュ」接続では、クライアント・ブロックは参照された入力パラメータのデータ型をその出力パラメータのデータ型から推測できる。他の処理制御アプリケーションの場合、入力パラメータと出力パラメータのデータ型の間の正確な合致は要求されず、クライアント・ブロックによって仮定することもできないので、このようなアプリケーションでは、クライアント・ブロックはなんらかの方法で参照されたパラメータのデータ型を学ばなければならない。参照されたパラメータのデータ型はたとえば、パラメータに関連するコネクタ内でデータ型とアドレス・データを共に格納することによって決定でき、制御戦略の設定時に、コネクタはアドレス情報とデータ型情報の両方を保持するように初期化することができる。
【００４７】
以下の表４に示された例としてのＥｘｅｃｕｔｅ（）手続きによって図示されているように、Ｅｘｅｃｕｔｅ（）はクライアント・ブロックＣＢによって実装される制御アルゴリズムのほとんどを符号化する。クライアント・ブロックＣＢの特定の要件に応じて、制御アルゴリズムの要素はそのブロックのパラメータについてＧｅｔ（）手続きまたはＳｔｏｒｅ（）手続きによって実装される。表４に提供された例としてのＰＤＬ内では、クライアント・ブロックＣＢ内のコネクタ・インスタンスは「ＩＰ１Ｃｏｎｎｅｃｔｏｒ」「ＯＰ２ｃｏｎｎｅｃｔｏｒ」として参照される。例としてのＥｘｅｃｕｔｅ（）手続きは、ＩＰ１ＣｏｎｎｅｃｔｏｒとＯＰ２Ｃｏｎｎｅｃｔｏｒがクライアント・ブロックＣＢについて設定動作の間に使用可能な状態に初期化されていることを仮定しており、また、クライアント・ブロックＣＢは暗示的ではなく明示的なデータ型の決定を使用していることを仮定している。Ｅｘｅｃｕｔｅ（）手続き内で行われる処理は、密接なアクセスＧｅｔ（）コール、Ｓｔｏｒｅ（）コールを含むＩＰ１ＣｏｎｎｅｃｔｏｒとＯＰ２Ｃｏｎｎｅｃｔｏｒに関連するサプライヤ・ブロックへの任意の実行時アクセスを処理する。
【００４８】
【表４】

【００４９】
表５に提供された例としてのＳｔｏｒｅ（）手続きによって示されているように、例としてのアプリケーション３００内のサプライヤ・ブロックＳＢ２については、サプライヤ・ブロックＳＢ２は入力パラメータＩＰ２について密接な格納アクセスをサポートしていないので、サプライヤ・ブロックＳＢ２はその格納手続きＳｔｏｒｅ（）が、入力パラメータＩＰ２への任意の入力接続についてコールされるように強制する。サプライヤ・ブロックＳＢ２は、入力パラメータＩＰ２が格納されるといつでも一連のアルゴリズムの計算（表５には図示せず）を実行する。例としてのＳｔｏｒｅ（）手続きは入力引数としてＰａｒａｍｅｔｅｒＩｄｅｎｔｉｆｉｅｒと格納されるべき値を受信し、これは引数「ＩｎｐｕｔＶａｌｕｅ」内に渡され、Ｓｔｏｒｅ（）手続きは格納動作が成功したかしないかを示す「状態」値を戻す。
【００５０】
【表５】

【００５１】
サプライヤ・ブロックＳＢ１についてＧｅｔ（）手続きを実行することは、例としてのアプリケーション３００内で描かれた接続によっては刺激されないが、Ｇｅｔ（）手続きの実行はたとえば処理中の表示から発生するサプライヤ・ブロックＳＢ１についてのパラメータ値要求によって刺激される。表６は例としてのＧｅｔ（）手続きを示す。
【００５２】
【表６】

【００５３】
まとめとして、上記の本発明は、オブジェクト指向ソフトウェア設計を使用するプロセス制御コントローラ内で処理のオーバーヘッドを削減するための手段を提供する。使用されている方法はクライアント・ブロックが参照されているパラメータについて密接なアドレス・データを要求する構成時間においてバインディング処理を設定することであり、サプライヤ・ブロックは要求を評価し、密接なアクセスを許可するかしないかを決定する。サプライヤ・ブロックが密接なデータ・アクセスを許可することを決定した場合、サプライヤ・ブロックはクライアント・ブロックにデータのアドレスを提供し、許可することを決定しなかった場合、サプライヤ・ブロックは密接なアクセスを否定し、実行時にクライアントブロックに対して明示的なサブルーチンを通じてデータにアクセスすることを強制する。
【００５４】
以前のプロセス制御コントローラ設計は、カプセル化されたオブジェクトとして制御アルゴリズムとデータを実装してきた。アルゴリズムの主な部分はたとえばＥｘｅｃｕｔｅ（）関数で表現され、パラメータ・データへのアクセスは上記に示されたようにＧｅｔ（）とＳｔｏｒｅ（）などのデータの所有者の関数を通じて制御された。しかし以前のコントローラ設計は、たとえばＧｅｔ（）／Ｓｔｏｒｅ（）実行を通じた間接的な、または「密接」なアクセスを通じた直接的なパラメータへのアクセスを許可していなかった。本発明は要求されたデータを所有するブロックがそこへのアクセスを制御する能力を失うことなく直接的および間接的なアクセスの方法を提供し、データ・パラメータを所有するブロックは各パラメータについて密接なアクセスが許可されているかどうかを決定でき、それによって各パラメータについて密接な読込みアクセスと密接な書込みアクセスについて独立して決定できるようにする。
【００５５】
上記から、本発明は、オブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供するためのシステムと方法ならびにそのシステムまたは方法を使用した分散実時間プロセス制御システムを提供することが明らかである。一実施形態では、システムは（１）クライアント・アルゴリズム・ブロックがあるアドレスに格納されたデータへの直接的なアクセスを得ることができるように前記アドレスに対する要求を生成するクライアント・アルゴリズム・ブロックと、（２）その要求を受信し、評価するサプライヤ・アルゴリズム・ブロックと、（２ａ）サプライヤ・アルゴリズム・ブロックがその要求を許可した場合には、そのアドレスをクライアント・アルゴリズム・ブロックに送り、クライアント・アルゴリズム・ブロックが前記データへの直接的なアクセスを得ることができるようにし、（２ｂ）サプライヤ・アルゴリズム・ブロックがその要求を拒否した場合には、そのアドレスを保留し、そのクライアント・アルゴリズム・ブロックがそのデータへの間接的なアクセスを得るように強制するサプライヤ・アルゴリズム・ブロックを含む。本発明を使用するとブロックの設計者は特定の処理制御アプリケーションの設計についてより制御できるようになり、必要であれば、ブロックの設計者は密接なアクセスを拒否し、特定のパラメータについてデータの読込みまたは書込みがサブルーチンの実行あるいは「メソッド」アクセスを通過するように強制することもできる。あるいは、サブルーチンの実行が望ましくなく、読込みアクセスまたは書込みアクセスの効率を上げることがより重要な場合、設計者は密接なアクセスを許可できる。
【００５６】
本発明とその利点が詳細に記述されたが、当業者であれば本発明のもっとも広い精神と範囲から離れることなく本発明についてさまざまな変更、代替、代替実施形態が作りだせることを理解されるであろう。
【図面の簡単な説明】
【図１】本発明が適切に使用できる、例としての、分散実時間プロセス制御システムの機能図である。
【図２】本発明の原理を具体化する、ソフトウェアで定義可能なプロセス制御ルーチンを実行するために使用される、例としてのディジタル処理システムの高レベルな構成図である。
【図３】本発明の原理を使用したアルゴリズム・ブロックを使用した、例としてのソフトウェアで定義可能なアプリケーションの構成図である。
【図４】本発明の原理を使用したアルゴリズム・ブロックの設計について接続サブシステム・クラス図を示した図である。

Claims

オブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供するためのシステムであって、
前記オブジェクト指向コントローラは、
オブジェクトとして前記システム内に実装されたクライアント・アルゴリズム・ブロックおよびサプライヤ・アルゴリズム・ブロックを含み、
前記クライアント・アルゴリズム・ブロックを実行して、あるアドレスに格納されたデータへの直接的なアクセスを可能にする前記アドレスに対する要求を生成させ、
前記サプライヤ・アルゴリズム・ブロックを実行して、前記要求を受信させ、評価させ、
前記要求を許可する場合には、前記アドレスをコネクタに格納することにより前記クライアント・アルゴリズム・ブロックに送り、前記クライアント・アルゴリズム・ブロックの前記データへの直接的なアクセスを可能にし、そして
前記要求を拒否する場合には、前記アドレスを保留し、前記クライアント・アルゴリズム・ブロックの前記データへの間接的なアクセスを強制する
システム。
前記クライアント・アルゴリズム・ブロックによりコンフィグレーション時に前記要求を生成する請求項１に記載のシステム。
前記サプライヤ・アルゴリズム・ブロックが前記クライアント・アルゴリズム・ブロックに明示的なサブルーチン・コールを通じて前記データへの間接的なアクセスを得ることを強制する請求項１に記載のシステム。
前記サプライヤ・アルゴリズム・ブロックにより前記サプライヤ・アルゴリズム・ブロックに関連する所定の規則に基づいて前記要求を評価する請求項１に記載のシステム。
前記データがパラメータに関連し、前記パラメータが、
直接的なアクセスがサポートされているかどうか、
直接的なアクセスがサポートされている場合には関連するセルの位置、
直接的なアクセスがサポートされていない場合には前記サプライヤ・アルゴリズム・ブロックの位置、
からなる情報グループから選択された少なくとも１つに関連する情報を含む請求項１に記載のシステム。
前記アドレスが前記クライアント・アルゴリズム・ブロックに関連する持続性ポインタに含まれる請求項１に記載のシステム。
前記オブジェクト指向コントローラが分散実時間プロセス制御システムである請求項１に記載のシステム。
オブジェクトとしてシステム内に実装されるクライアント・アルゴリズム・ブロックおよびサプライヤ・アルゴリズム・ブロックを含むオブジェクト指向コントローラ内でカプセル化されかつ能率的なデータ参照を提供するために実施される方法であって、
前記クライアント・アルゴリズム・ブロックを実行して、あるアドレスに格納されたデータへの直接的なアクセスを可能にする前記アドレスへの要求を生成させるステップと、
前記サプライヤ・アルゴリズム・ブロックを実行して、前記要求を受信させ、評価させるステップと、
前記要求を許可する場合には、前記アドレスをコネクタに格納することにより前記クライアント・アルゴリズム・ブロックに送り、前記クライアント・アルゴリズム・ブロックの前記データへの直接的なアクセスを可能にするステップと、そして
前記要求を拒否する場合には、前記アドレスを保留し、前記クライアント・アルゴリズム・ブロックの前記データへの間接的なアクセスを強制するステップと
を含む方法。
前記生成のステップがコンフィグレーション時に実行される請求項８に記載の方法。
前記受信のステップが、
前記サプライヤ・アルゴリズム・ブロックにより前記要求を拒否する場合に、前記クライアント・アルゴリズム・ブロックに明示的なサブルーチン・コールを通じて前記データへの間接的なアクセスを得るように強制するステップを含む請求項８に記載の方法。
前記受信のステップが、
前記サプライヤ・アルゴリズム・ブロックに関連する所定の規則に基づいて前記要求を評価するステップを含む請求項８に記載の方法。
前記データがパラメータに関連し、前記パラメータが、
直接的なアクセスがサポートされているかどうか、
直接的なアクセスがサポートされている場合には関連するセルの位置、
直接的なアクセスがサポートされていない場合には前記サプライヤ・アルゴリズム・ブロックの位置、
からなる情報グループから選択された少なくとも１つに関連する情報を含む請求項８に記載の方法。
前記アドレスが前記クライアント・アルゴリズム・ブロックに関連する持続性ポインタに含まれる請求項８に記載の方法。
前記オブジェクト指向コントローラが分散実時間プロセス制御システムである請求項８に記載の方法。
分散実時間プロセス制御システムであって、
複数のセンサおよび制御可能なデバイスと、そして
前記複数のセンサおよび前記制御可能なデバイスに関連し、オブジェクト指向コントローラとして動作可能なデータ処理・格納回路と
を含み、
前記データ処理・格納回路は、
オブジェクトとしてシステム内に実装されたクライアント・アルゴリズム・ブロックおよびサプライヤ・アルゴリズム・ブロック内に配置されたソフトウェア命令のシーケンスを実行することにより、
前記クライアント・アルゴリズム・ブロックに、あるアドレスに格納されたデータへの直接的なアクセスを可能にする前記アドレスに対する要求を生成させ、
前記サプライヤ・アルゴリズム・ブロックに、前記要求を受信させ、評価させ、
前記要求を許可する場合には、前記アドレスをコネクタに格納することにより前記クライアント・アルゴリズム・ブロックに送り、前記クライアント・アルゴリズム・ブロックの前記データへの直接的なアクセスを可能にし、そして
前記要求を拒否する場合には、前記アドレスを保留し、前記クライアント・アルゴリズム・ブロックの前記データへの間接的なアクセスを強制する
システム。
前記クライアント・アルゴリズム・ブロックによりコンフィグレーション時に前記要求を生成する請求項１５に記載のシステム。
前記サプライヤ・アルゴリズム・ブロックにより前記クライアント・アルゴリズム・ブロックに明示的なサブルーチン・コールを通じて前記データへの間接的なアクセスを強制する請求項１５に記載のシステム。
前記サプライヤ・アルゴリズム・ブロックにより前記サプライヤ・アルゴリズム・ブロックに関連する所定の規則に基づいて前記要求を評価する請求項１５に記載のシステム。
前記データがパラメータに関連し、前記パラメータが、
直接的なアクセスがサポートされているかどうか、
直接的なアクセスがサポートされている場合には関連するセルの位置、
直接的なアクセスがサポートされていない場合には前記サプライヤ・アルゴリズム・ブロックの位置、
からなる情報グループから選択された少なくとも１つに関連する情報を含む請求項１５に記載のシステム。
前記アドレスが前記クライアント・アルゴリズム・ブロックに関連する持続性ポインタに含まれる請求項１５に記載のシステム。