(57)【特許請求の範囲】
【請求項１】
関係特性インターフェース（ＲＣＩ）を使用してデータ・バインディングを確立する分散型の測定及び制御システムであって、
通信ネットワークに、前記ＲＣＩに従って１セットのフィールドを含む１セットのデータをパケットに含めてポストする第１の構成要素であって、前記ＲＣＩは、システム中の計算エンティティのグループを規定するアンサンブル・フィールドと、システムの測定及び制御機能を規定するメッセージ＿タイプ・フィールドと、単位タイプを規定する変数名フィールドを含み、前記フィールドのうちの１以上のフィールドは任意指定表現手段を含む、第１の構成要素と、
前記通信ネットワークを介して前記パケットを受信する手段と前記パケットに含まれる前記フィールドにフィルタを適用する手段を備えた第２の構成要素であって、前記フィルタは１セットの前記ＲＣＩに従ったフィルタ・フィールドを含み、前記ＲＣＩは計算エンティティのグループを規定するフィルタ・アンサンブル・フィールドと測定及び制御機能を規定するフィルタ・メッセージ＿タイプ・フィールドと単位のタイプを規定するフィルタ変数名フィールドを含み、１以上のフィルタ・フィールドのいずれかは前記任意指定表現手段を含み、もし前記アンサンブル及びメッセージ＿タイプ及び変数名フィールドのうちで前記任意指定表現手段を含まないフィールドが、対応するフィルタ・アンサンブル及びフィルタ・メッセージ＿タイプ及びフィルタ変数名のうちで前記任意指定表現手段を含まないフィルタ・フィールドと一致すれば、前記データは受け入れられ、そうでなければ受け入れられない、第２の構成要素と
を備えたことを特徴とするシステム。
【請求項２】
前記計算エンティティのグループは、温度を分析する１セットのノード・アプリケーションを備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項３】
前記計算エンティティのグループは、特定の範囲で現在温度を測定中の１セットのノード・アプリケーションを備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項４】
前記計算エンティティのグループは、特定の住居アドレスと関連した１セットのノード・アプリケーションを備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項５】
前記測定及び制御機能は１セットの測定データの通信を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項６】
前記測定及び制御機能は１セットの変換器からのデータの通信を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項７】
前記測定及び制御機能は前記システムのイベントの記述を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項８】
前記測定及び制御機能は時間同期機能を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項９】
前記測定及び制御機能はコマンド解釈機能を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項１０】
前記パケット中の前記フィールドは、前記第２の構成要素により受け入れられるデータを特徴付ける、前記データと前記フィルタ・フィールドを記述することを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項１１】
前記パケット中の前記フィールドは、前記データと前記第２の構成要素を特徴付ける前記フィルタ・フィールドを受信する構成要素を記述することを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項１２】
前記ＲＣＩは、タイム・スタンプ、単位、位置、値、値の記憶タイプ、システム変数、ローカル環境変数、アプリケーション環境変数、及びユーザ定義変数を含むグループから選択された少なくとも一つの任意選択フィールドを含み、前記任意選択フィールドの１以上のいずれかは任意指定表現手段を備えたことを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項１３】
前記フィルタを適用する手段は、通信ネットワークに接続されたネットワーク・プロトコル・スタックを含み、前記パケット中の前記フィールド及び前記フィルタ・フィールドに従って前記データを選択的に受信するよう動作することを特徴とする請求項１記載の分散型の測定及び制御システム。
【請求項１４】
前記ネットワーク・プロトコル・スタックは、前記フィルタ・アンサンブル・フィールドを前記パケットの前記アンサンブル・フィールドに適用するハードウエア部分を含むことを特徴とする請求項１３記載の分散型の測定及び制御システム。
【請求項１５】
前記ネットワーク・プロトコル・スタックの前記ハードウエア部分は、前記グループに関係したマルチキャスト・アドレスを含むことを特徴とする請求項１４記載の分散型の測定及び制御システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、測定および制御の領域で使用する分散システムを対象とする。詳細には、メッセージ・フィルタリングと、自動バインディング(binding)と、フィールドの符号化、ならびに分散システムの構築および委託（コミッショニング）に関連したその他の項目に関する。
【０００２】
【従来の技術】
多くの測定および制御アプリケーションは、遠隔的に配置されたいくつかの変換器、例えばセンサまたはアクチュエータとともに中央制御装置を使用する。これらの変換器はポイント・ツー・ポイント・リンク(point to point link)を介して中央制御装置に接続される。最近では、いくつかのこれらの装置がパケット・ベース・バスを共有して中央制御装置と通信することだけでなく、ピア・ツー・ピア通信を使用した分散動作も可能にする、いくつかの「フィールド・バス」が現れている。バスは、この共有した媒体を介した通信パターンを確立するためにアドレス指定方式を必要とする。これらのアドレス指定方式は、システムの個々のノードまたは計算エンティティの中のアドレス可能な各エンティティに、「タグ」と呼ばれる識別子を割り当てることによって、しばしば実施される。このようなエンティティの間での通信パターンは、各パターン中のエレメントを規定する様々なタグを関連づける、すなわち「バインディングする」ことによって確立される。
【０００３】
１９８９年７月２７日に発行された米国特許第５，１８７，７８７号にＳｋｅｅｎらによって開示されたタグ・ベースのバインディングの一例は、「主体(subject)ベースの」アドレス指定を使用する発行者／加入者ベースシステムである。主体は、解析可能な階層構造を有するタグとして規定される。例示すると、「ＳＦＢ．Ｐ３９．ｔｅｍｐ」というタグは、「temperature at Pier 39 on San Francisco Bay」（サンフランシスコ湾第３９桟橋の温度）を表す。この温度がタグ「ｄｉｓｐｌａｙ＿７．ｒｏｗ２」とともに報知器に表示される場合には、これら２つのタグは、規定された手順に従って「バインディングされて」使用されることになる。これらのタグ・フィールドは、ストリング形式である。
【０００４】
【発明が解決しようとする課題】
タグの名前スペースの管理は、通信パターンの複雑化とともに増加する。結果として、単一の構造で数種類の情報を表現するためには、タグにオーバロードしなければならない。オーバロード状態のタグをバインディングすることにより、計算可能性は制限される。バインディング「temperature at Pier 39 on San Francisco Bay」は、温度が報告されたこと、その測定が第３９桟橋で行われたこと、それがサンフランシスコ湾に位置することという、３つのデータを組み合わせている。システムが、塩分濃度やｐＨなどのサンフランシスコ湾環境の多種の測定、および第３９桟橋以外に多数の位置を含む場合には、その結果得られるタグの名前スペースは非常に大きくなることになる。
【０００５】
もう１つの問題は、タグによって参照される値の単位および記憶タイプが、暗黙のうちにバインディングされることである。１つのサイトでは温度が華氏の整数で報告され、別の位置ではその値が摂氏の実数で報告されることもある。バインディングが確立されている場合は、同様の単位および記憶タイプのみがバインディングされること、または適当な変換動作が提供されることを保証するように留意しなければならない。より明白に表現を規定することが必要である。
【０００６】
オーバロード状態のタグは、いくつかのソースからのデータについて計算を行わなければならないシステムには不適である。しばしば、計算不可能な形状の空間データが、測定中のデータとともにタグにオーバロードされる。システムが、第３９桟橋付近の海岸地区に沿った温度勾配を計算する必要がある場合には、必要なバインディングを確立し、必要な空間データを抜き出すことは困難になる。
【０００７】
タグ・ベース・システムは、動的に変化する要件にしたがってデータを管理するためのアプリケーション・コードおよびバインディングの開発を妨げる可能性がある。新しい空間位置を導入することは、既存のタグと矛盾しない名前を確立し、その後にバインディング過程に戻ることを含む。問題は、空間データの表現が静的かつ不適当であること、およびバインディングの静的特性の両方にある。同様に、バインディングを動的に変更して様々なデータを受信すること、例えば、変化している位置の範囲内の全ての位置から温度測定を受信することは困難である。
【０００８】
タグ・ベース・アーキテクチャは、正確に分散した計算エンティティおよび通信エンティティを生み出すという問題の役には立たない。集合エンティティは、単一の構成要素で実行される単一のプログラムや、通常のまたは短縮されたエンティティまたはアプリケーションとして挙動するが、実際には、いくつかの構成要素で実行され、集合して１つになって現れる、プログラム・フラグメント（fragment：破片）の集合である。集合中のどのフラグメントが、特定の時間に任意の特定のバインディングに含まれることになるかを述べることは、通常は不可能である。これらのエンティティは、これらのタグ・ベース・システムに不適である。
【０００９】
必要なのは、通常エンティティおよび集合エンティティからなる分散システム中でバインディングを確立することを可能にする、フレキシブルでありながら短縮された専門語(nomenclature)および方法である。このような専門語および方法が動的な性質を有し、アプリケーションの意味の豊かで計算可能な表現を見込んでおくことがさらに望ましい。
【００１０】
【課題を解決するための手段】
本発明は、関係特性インタフェース（ＲＣＩ）に基づく分散システム中でバインディングを確立する方法を規定する。ＲＣＩは、通常は、アンサンブル、メッセージ＿タイプ、変数名といった各フィールドを含む。タイム・スタンプ、単位、位置、記憶タイプ、値などの任意選択のフィールドを指定することもできる。フィールドを拡大して、ユーザ定義フィールド、またはシステムの特性または「環境」変数によって決まるフィールドを含むようにすることもできる。ＲＣＩは、内容に基づくフィルタリングおよび属性に基づくアドレス指定という、バインディングを確立するための２つの方法を見込んでいる。
【００１１】
アンサンブル・フィールドは、例えば温度を分析する全ての計算エンティティなど、特定用途向け基準による計算エンティティのセットを規定する。メッセージ＿タイプ・フィールドは、データ、すなわち「測定または動作データ」、「セットポイント・データ」、「イベント」、「管理」に対するアプリケーション意味モデルを規定する。
【００１２】
内容に基づくフィルタリングでは、バインディングは、ＲＣＩを使用して論理制約を規定することによって確立される。データの提供側は、提供するデータの特性を表す値をＲＣＩの関連するフィールドに移植する。データの受信側は、通信システムからＲＣＩに適用された時に、突き合わせ特性に合うセットのみを許可するフィルタ・パターンを指定する。提供側および受信側はそれぞれ、ＲＣＩのキャラクタライザおよびフィルタを動的に修正することができる。このモデルにより、提供側は、受信側が潜在すること、またはこのデータに受信側が特定の関心を持っていることを知ることなく、記述ＲＣＩを備えたデータをポストすることができる。受信側は、提供側の識別に関わらず、データのＲＣＩに適用するフィルタを指定することにより、利用可能なデータの領域中で彼ら自身の関心を自由に指定することができる。例示すると、提供側は、ＲＣＩフィールド｛アンサンブル＝２、変数名＝「電圧」｝を含むデータに、ペイロード値＝７、および単位＝「ボルト」をポストすることができる。｛アンサンブル＝２、変数名＝＊（任意）｝のフィルタを備えた受信側、および｛アンサンブル＝２、変数名＝「電圧」｝のフィルタを備えた受信側ならこれを選択し、これにしたがって動作するが、｛アンサンブル＝３、変数名＝＊｝のフィルタを備えた受信側はこれを選択せず、これにしたがって動作しない。
【００１３】
属性に基づくアドレス指定モデルでは、データの提供側は、受信側を特徴付けるデータを記述するＲＣＩに基づいて、フィルタ・パターンを指定する。このフィルタは、提供側がポストするデータに取り付けられる。潜在する全ての受信側は、取り付けられたフィルタを受信側を記述するＲＣＩに適用し、一致した場合に、そのデータを受け取り、それにしたがって動作する。このモデルにより、提供側は、ＲＣＩフィールドが規定するターゲットの特性に基づいて、データをターゲットに向けることができる。フィルタおよびＲＣＩのフィールドは、ポストする主データ内容、すなわちデータやコマンドなどを任意選択で含むことができる。さらに、フィルタおよびＲＣＩのフィールドは、動的に変更することができる。提供側は、そのような任意の受信側がいるかどうかを知っている場合もあれば知らない場合もあるが、それでもこの制約を指定することができる。例示すると、適当なフィルタによって、提供側は更新パラメータを含むデータ、すなわちペイロードをポストすることができ、フィルタとＲＣＩの組合せが「Ｆｉｒｍｗａｒｅ  ｒｅｖｉｓｉｏｎ  ２．３」に関してデータを抜き出す全てのエンティティは、このデータに対して作用することになる。
【００１４】
ＲＣＩ中のフィールドは、各フィールドが明確な意味を有するように、標準的なデータ表現に基づくことが好ましい。これらの標準には、一般的な専門語、および測定および制御アプリケーションでの使用に基づくフィールドに対するユーザ拡張定義が含まれることがある。例えば、温度に関連するデータに対するデフォルト変数名は「温度」で標準化され、そのフィールドは列挙またはストリングを使用して生成されることになる。標準により、これらのシステムの構成要素の相互操作性を最大限にしながら、必要なバインディングを確立する際の困難は最小限に抑えられる。
【００１５】
ＲＣＩは、単一のエンティティと同様に集合エンティティにも適用することができる。制御システムを形成するセンサおよびアクチュエータの集合は、それ自体を、それ自体のＲＣＩを備えたエンティティと見なすことができる。この集合に対するＲＣＩの様々な特性は、実際には、集合の様々なエレメントに帰するが、ＲＣＩ全体は単一のエンティティとして外界に現れる。
【００１６】
【実施例】
図１は、本発明による分散型の測定および制御システム１０を示す図である。システム１０は、例えばマイクロプロセッサなどの計算エレメント１２1、１２2、１２3、‥‥、１２Nからなる。これらの計算エレメントの多くは、関連した変換器（図示せず）、すなわちセンサまたはアクチュエータを備え、自然界と相互作用する。各計算エレメントは、特定用途向けコードまたはノード・アプリケーション１４1、１４2、１４3、１４4、‥‥１４iのフラグメントを少なくとも１つ含み、これらは対応する計算エレメント上で実行される。ノード・アプリケーションはプロセッサと１対１で対応することができるが、複数で１つのプロセッサを共有する、または単一のノード・アプリケーションが複数のプロセッサを使用することもできる。各ノード・アプリケーションは、１つまたは複数の明確なアプリケーションを表現する。全てのノード・アプリケーション１４1、１４2、１４3、１４4、‥‥１４iは、ネットワーク１６にデータをポストし、そこからデータを受信する。
【００１７】
仮想ノード・アプリケーション１８は、共通のプロセッサに常駐する場合とそうでない場合とがあるノード・アプリケーションの集合である。この集成は、協働して、完全な計算タスクを形成する。単独では、仮想ノード・アプリケーション中の各ノード・アプリケーションは、集合中のその他のノード・アプリケーションがなければ不完全である場合がある。
【００１８】
ノード・アプリケーションおよび仮想ノード・アプリケーションは、ネットワークを介して互いに通信する。仮想ノード・アプリケーションの場合は、実際の通信は１つまたは複数の構成要素ノード・アプリケーションを伴う。ただし、仮想ノード・アプリケーション内における、またはこれを含むバインディングは、静的である必要はない。
【００１９】
複数のノード・アプリケーションの間で共有されるデータの各項目は、関連したＲＣＩを有する。ノード・アプリケーションは、ＲＣＩを特徴付ける。この特徴付けを外部ツールによって任意選択でネットワークを介して行い、ＲＣＩの特徴付けをノード・アプリケーション内の特定の項目と関連付けることができる。特徴付けはまた、「インスタレーション」、または特徴付けを、ノード・アプリケーションが利用できるその他のデータ、例えば関連したセンサやアクチュエータの測定値や動作パラメータなどに基づくものとする、ノード・アプリケーションのその他の部分によって割り当てられることもできる。
【００２０】
内容に基づくフィルタリングの場合、提供側のノード・アプリケーションは、ネットワークにデータをポストし始める前に、このデータおよび必要な特徴付けをＲＣＩに提供する。同様に、受信側のノード・アプリケーションはデータを受信し、着信したデータに関連したＲＣＩに適用すべきフィルタ指定を提供する。このフィルタに基づいて、適当なデータがネットワークから抜き出され、受信側に渡される。
【００２１】
属性に基づくアドレス指定では、提供側はネットワークにこのデータをポストし始める前に、必要な特徴付けを取り付けられたフィルタに付加的に提供する。同様に、受信側は、ネットワークから抜き出して需要側のノード・アプリケーションに渡す適当なデータを選択するためにフィルタを適用すべき、必要なＲＣＩ仕様を提供する。
【００２２】
図２は、通常のシステム構成要素１２Nの次の水準の詳細を示す図である。ネットワークへのインタフェースは、通常はオペレーティング・システム、またはノード・アプリケーション１４iを実行する環境の一部である、プロトコル・スタック２０を介している。通常のプロトコル・スタックは、通信および計算の効率を高めるために、ハードウェア２０Ａで実施される部分とファームウェア２０Ｂで実施される部分とを有する。
【００２３】
ネットワークのプロトコル・スタック２０と相互作用する通信基礎構造２２は、プロトコル・スタックを増やし、様々な可能なサービスを提供するサポート・コードである。この構造は、ＣＯＲＢＡまたはＯＬＥインタフェースを提供する、または所望の通信モデルを、特定のインスタレーションで必要とされるモデル、例えばＳＰ−５０などのマルチマスタ・モデルや、ＴＩＢＣＯ社で使用されるような公開／引用モデルにマップすることができる。さらに、この構造は、プロトコル・スタックにより、提供側および受信側が使用するポスティングおよびフィルタリング・モデルを対等にする。これは、フィルタをプロトコル・スタックおよびフィルタ構造にマップすること、ならびに場合によってはパフォーマンスを最大限にするためにフィルタの順序の適応変化を実施することを含む。この構造は、後に述べるその他のサービスをサポートする。通信構成管理構造は、規定されたその他の構造を管理および構成し、ノード・アプリケーションおよび外部ツール両方に対して通常のインタフェースを提供してこれらの機能を実施する。
【００２４】
入力フィルタ２４は、ＲＣＩとフィルタの組合せによって指定された抜き出し特性を、バインディングされていないデータに適用する。基準に合うデータのみが、入力ａｐｐ−ｖａｒ構造に渡される。
【００２５】
好ましい実施形態では、各ＲＣＩのフィルタリングの一部は、最初にプロトコル・スタックのハードウェア部分２０Ａに割り当てられ、その後ファームウェア部分２０Ｂに割り当てられる。このようにして割り当てられるフィルタリングの量は、使用する特定のプロトコル・スタックによって決まる。例えば、イーサネットの実装では、通常は、単一のフィルタをハードウェアで実施することができる。プロトコル・スタック２０および入力フィルタ２４へのＲＣＩフィールドのマッピングの詳細については、後に論じる。この割り当ては静的なものではなく、ノード・アプリケーション１４iによって動的に変更する、またはフィルタリングを適応的に行ってパフォーマンスを最大限にするように実施することもできる。
【００２６】
通常は入力フィルタ２４からのデータを受信する入力ａｐｐ−ｖａｒ２６は、複数のノード・アプリケーション１４i間でデータ伝送を行うための、システム全体データ・モデルに基づく任意選択のデータ構造である。ＲＣＩの多くのフィールドはこのデータ・モデルに含まれ、受信したデータの生成側から割り当てられた値は、入力ａｐｐ−ｖａｒのフィールドに現れることになる。「ａｐｐ−ｖａｒ」により、ノード・アプリケーション１４iが使用可能な付加的なサポート構造を構築することができ、それは例えば、ａｐｐ−ｖａｒのタイムスタンプ・フィールドでの計算のためのコード、エンティティを規定したノード・アプリケーション１４iへのａｐｐ−ｖａｒフィールドの自動割り当てまたは記憶、等である。ａｐｐ−ｖａｒは、ＲＣＩフィールドに基づいて、あるいは型付きデータ・モデルが使用されている場合にはメッセージ・タイプに基づいて着信データを自動的に妥当な記憶タイプに割り当てるサポート・コードを備えて、データの値フィールド用の特定の記憶タイプ向けに構築することができる。さらに、ａｐｐ−ｖａｒは、ノード・アプリケーション１４iが見える表現と、ネットワークが見える表現により使用される表現との間で、フィールドを自動的に符号化および復号化することができる。その後、入力ａｐｐ−ｖａｒ２６はアクセス可能になり、関連したノード・アプリケーション１４i中で動作をトリガすることができる。
【００２７】
外部へのデータは、ノード・アプリケーション１４iから任意選択の出力ａｐｐ−ｖａｒ２８に移り、その後通信基礎構造２２に移る。入力ａｐｐ−ｖａｒと同様に、出力ａｐｐ−ｖａｒ２８のサポート・コードは、ノード・アプリケーション１４iによってこのように構成されている場合には、いくつかのフィールドで自動的に生成する、例えばタイムスタンプを自動生成することができる。ノード・アプリケーション１４iはまた、データに関連したＲＣＩまたはフィルタ（選択した通信モデルによる）のフィールドを指定することもできる。出力ａｐｐ−ｖａｒデータは、その後、通信基礎構造ブロック２２を介してプロトコル・スタック２０に転送される。このａｐｐ−ｖａｒの機能は、各ノード・アプリケーション１４iで実施することもでき、この場合は通信基礎構造２２に直接転送されることになる。
【００２８】
図３は、本発明のＲＣＩの実施形態を示す図である。このインタフェースは、図２に図示した詳細な機構を使用する図１に示したノード・アプリケーションまたは仮想ノード・アプリケーション間での通信を確立するための基礎として使用される。フィールドは、アンサンブル、メッセージ＿タイプ、変数名である。任意選択のフィールドには、タイムスタンプ、単位、位置、値が含まれるが、これらに限定されることはない。
【００２９】
詳細には、特定用途向けデータとは対照的にシステムまたは環境を特徴付ける意味および値を反映する任意選択のフィールドが許可される。例えば、ＲＣＩは、現地時間ゾーン、ノードを所有する「部門または人」、構成要素の改訂年月日、製造番号、時刻、ローカルにログされたデータ量などを表すフィールドを含むことができる。
【００３０】
任意のノード・アプリケーションまたは仮想ノード・アプリケーションによってネットワークにポストされた全てのパケットは、アプリケーション・ヘッダおよびペイロード記録を含む。この実施形態では、内容に基づくフィルタ・モデルの場合のＲＣＩ、または属性に基づくアドレス指定モデルの場合のフィルタを、ヘッダとペイロード記録の間で配分する方法を指定しない。これは、効率を目的として設計されるべき、実施方法によって決まる問題である。
【００３１】
アンサンブル・フィールドは、多少大きめのタスクを協働して実行するノード・アプリケーションおよび仮想ノード・アプリケーションのエンティティを規定する。このエンティティ中の親子関係は、アプリケーションの必要にしたがって確立され、共通の主体や、共通の機能、または共通の属性などの基準に基づくことができる。例示すると、アンサンブル・フィールドは、特定の住居(residence)アドレスと関連したノード・アプリケーションのエンティティであると規定することができ、この場合、アンサンブル・フィールドは、電気計器など、独自のエンティティとして各住居に存在する構成要素のＵＵＩＤ(Universally Unique IDentifier)であることができる。通信基礎構造は、このアンサンブルの表現を、その下にある通信プロトコルのアドレス構造にマップする。あるいは、アンサンブル中の親子関係は、１以上のフィールドの算出機能であることがあり、このシステムがフィルタリングのローカル修正を可能にしてから時間経過とともに変化することができる。例えば、アンサンブルは、ある範囲で現在温度を測定中の全てのノード・アプリケーションを備えることがある。この場合は、アンサンブル中の親子関係は動的に計算される。
【００３２】
メッセージ＿タイプ・フィールドは、アプリケーションが定義したパケットの関数的意味の点から、データを分類する。例示すると、データ・パケットは、測定データを含むもの、何らかのイベントを説明するもの、時間同期などの何らかの広域プロトコルに関するもの、またはコマンドを含むものとして分類することができる。
【００３３】
変数名フィールドは、データ・パケットに含まれる項目の名前を記述する。変数名は、メッセージ＿タイプ・フィールドによって決めることができ、例えば、時間同期プロトコルは、通常はこの属性によって分化された異なるデータを実行するいくつかの異なるパケットを有する。イベント・パケットは、イベントの種類を指定するトークンとしてこの属性を使用する。データ・パケットは、この名前を使用して、測定した電圧などの物理量を指定する。変数名フィールドの好ましい実施形態では、各メッセージ・タイプを表現するためのデフォルトおよび規則を規定する。データ・パケットの場合は、デフォルトの変数名が、測定した物理量に対するＳＩで指定された名前と一致したときに、ＲＣＩの最大の相互操作性および有用性を得ることができる。
【００３４】
タイムスタンプ・フィールドは、パケットを生成する構成要素にローカルなクロックで測定された時間を示す。時間の割り当ては、メッセージ＿タイプとは異なる。データ・パケットの場合は、タイムスタンプは、データが測定されたローカル時間を表すことになる。イベントの場合は、イベントが発生した時間などを表すことになる。この属性がない場合には、「今」などのシステム全体に定義された方法で時間を解釈しなければならない。
【００３５】
単位フィールドは、値フィールドが存在する場合に、これを表現する単位を指示する。相互操作性は、ＳＩなどの標準単位表現をシステム全体で使用しているときに向上する。
【００３６】
位置フィールドは値に関連する空間位置、すなわちデータを測定した位置を表すことができる。様々な表現を使用することができる。所与のアプリケーションに対して、一般には１つの表現が計算可能性を促進し、例えば、地理座標は環境データに適している。
【００３７】
値フィールドは、メッセージ＿タイプ・フィールドの内容にしたがって値を示し、例えば、データ・パケットでは、値は指定された単位の測定値である。あるいは、値をデータとして解釈しながら、コマンドまたは要求としても解釈することもできる。解釈の意味は、メッセージ＿タイプ・フィールドによって示されることになる。
【００３８】
記憶タイプ・フィールドは、値フィールドを浮動小数や整数などとして表す記憶タイプを指示する。データ・パケット中で記憶タイプ・フィールドが明白でない場合には、「型付きａｐｐ−ｖａｒ」を規定することによって記憶タイプにしたがって、データ・パケットを暗黙に分類することができる。
【００３９】
好ましい実施形態では、全てのフィールドは、フィールドの意味、表現、デフォルト値、および非デフォルトの場合の規則を指定する明確なデータ・モデルを有する。可能なら、これらのデータ・モデルは国際標準を厳守し、例えば、変数名フィールドは、測定する物理量に対するデフォルトとしてＳＩで指定された名前を使用する。同様に、ＳＩ単位は単位フィールドを表すことになる。時間は、ＵＴＣ(Utilities Telecommunications Council)などの標準を厳守する。標準が存在しない場合には、残りのフィールドが適当に規定されたシステム全体データ・モデルを使用する。明確なデータ・モデルを使用することにより、その結果生じる構成要素の相互操作性は向上し、ＲＣＩの有用性は最大限になる。ＲＣＩが豊かになるので、デフォルトの論理式で、バインディングの仕様の大部分を十分に確立することができる。
【００４０】
これらの全てのＲＣＩフィールドは、ノード・アプリケーションまたは仮想ノード・アプリケーションからネットワークにポストされたパケットの、アプリケーション・ヘッダおよびユーザ・スペース部分を表す。通信を確立するために、これらのフィールドのサブセットを使用して、バインディングまたはマッピングを規定する。これは、必要ではないが好ましくはマルチキャスト・プロトコルを使用して全てのパケットをポストすること、および構成要素中のノード・アプリケーションまたは仮想ノード・アプリケーションによるパケット受け入れを、１以上のこれらのフィールドを使用して入力フィルタを形成することによって指定された論理制約に基づいて行うことにより実行される。「ポスタ／フィルタ」パラダイムは、データ・パケットをポストするノード・アプリケーション、およびデータ・パケットのサブセットをフィルタするもう１つのノード・アプリケーションを備える。
【００４１】
好適な実施形態では、１つのフィルタ・フィールドが通信プロトコルのハードウェア・フィルタに割り当てられ、残りのフィルタ・フィールドは、例えばさらに高レベルのプロトコル・スタックや図２の入力フィルタに割り当てられる。イーサネットはマルチキャスト通信をサポートし、ほとんどのイーサネット・チップ・セットは、１レベルのハードウェア・フィルタリングを備える。アンサンブル・フィールドは、協働するノード・アプリケーションのグループを規定するので、スタックの最低レベル、好ましくはハードウェア・フィルタに、マップされるまたは割り当てられることが好ましい。これにより、通常は、最も効率的な第１フィルタが生じることになる。アンサンブル・フィールドの実際の表現またはマッピングは、ネットワーク・プロトコルのアドレス構造によって決まることになる。ハッシングなどの様々な方法を使用してこのマッピングを実施することができる。
【００４２】
好適な実施形態では、アンサンブル・フィールドは、明確なデータ・モデルおよび表現、詳細には階層構造を有する。アンサンブルの階層の最高レベルは、関係を記述するデフォルトの名前、たとえば「同僚」、「兄弟」、「親」、「子」などを含む。これらの関係は、アンサンブルが、ノード・アプリケーションの論理「兄弟」のみを含む、またはノード・アプリケーションおよびその「親」のみを含むといったことを示す。さらに、ユーザ定義のグループ名を使用することもできる。アンサンブルの名前スペースを構築することにより、システムの構成要素、例えばルータが、この情報を使用できるようになる。
【００４３】
受け入れられるデータの抜き出しは、フィルタの順序とは無関係である。このことにより、ネットワーク上の最近のデータの混合に基づいて、最も効率的（計算サイクルに関して）なフィルタを生成するようにフィルタリング順序を適応させるフィルタを提供するような方法で、図２の通信基礎構造および通信構成管理ブロックを実施することができる。
【００４４】
好適な実施形態では、提供側は指定通りにそれらのデータを自動的にポストし、受信側はネットワークから利用できるデータをフィルタして、興味のある項目を抜き出す。
【００４５】
もう１つの実施形態では、提供側は、アプリケーションまたはシステムの定義条件が合うときにのみそれらのデータをポストする。ポストされないデータは、ノード・アプリケーションの設計に従って局所的にログされる場合と、または破棄される場合とがあるが、その決定もまた、アプリケーションまたはシステムの定義条件に基づいて行うことができる。これらの条件は、システムまたはノード・アプリケーションが規定する特性に基づく論理仕様として表されることが好ましく、例えば、システム定義条件は、「ノード・アプリケーションの個々の列挙型クラスが少なくとも１つ存在する場合にポストする」などの親子関係条件になる。ノード・アプリケーション定義条件の一例としては、「センサからの値が規定範囲内にある場合にポストする」がある。このポスティングの条件スタイルは、「条件に基づくポスト」と呼ばれる。この条件が、ソースに一致するＲＣＩフィルタ・パターンの存在によって証明される、データに対する特定の必要の存在を反映する場合には、「要求に基づくポスト」と呼ばれる。後者の形成は、後述する需要側データ・サービスを使用して実施することができる。
【００４６】
好ましい実施形態の通信基礎構造ブロックもまた、本発明で利用するＲＣＩ、および発行／引用モデルまたはポスト／フィルタ・モデルによって可能になるサービスの集合を実施する。これらのサービスは任意選択であるが、何らかのシステムで、特にシステムの管理および構成を援助するツールを実施する場合には有効である。サービスは、通常のクライアント・サーバ・モデルのネットワークを介して外部からノード・アプリケーションによって呼び出すか、またはこの実施態様によるＲＣＩモデルを使用して呼び出すことができる。この後者のモデルは、各メンバについて個別に呼び出すのではなく、ＲＣＩが規定した集合として処理される一群のノード・アプリケーションのサービスを呼び出す機構を提供するので、大型システムで特に有効である。同様にサービス自体が、ノード・アプリケーションと同様の機構を使用して、ポストすべきデータの提供側となることも可能である。
【００４７】
これらのサービスの好適なセットについて、以下に述べる。
提供側のデータ・サービスは、データのＲＣＩに基づく現在利用できるデータのリストを保持する。提供側はこのサービスに登録し、データが存在することを公示する。このサービスを照会して、潜在的にはソース(source)など、ある特徴付けを備えたデータが存在することを確認することができる。同様に、このサービスは、更新を利用可能なサービスの集合に自動的にポストすることもできる。このサービスは、集中させる必要はないが、それ自体が分散型の特殊目的ノード・アプリケーションの集合として現れることができる。
【００４８】
受信側のデータ・サービスは、システム中で現在活動状態にあるＲＣＩフィルタ・パターンのリストを保持する。受信側はこのサービスに登録し、特定のデータが必要であることを公示する。このサービスを照会して、例えば要求側など、ある特徴付けを備えたデータを求める要求が存在することを確認することができる。同様に、このサービスは更新を集合にポストすることができる。このサービスは、集中させる必要はないが、それ自体が分散型の特殊目的ノード・アプリケーションの集合として現れることができる。
【００４９】
マッピング・サービスにより、ＲＣＩフィールドの値を１つの表現から別の表現にマップすることが可能になる。これにより、包括的に規定されたＲＣＩフィールドの値を、ノード・アプリケーションに書き込むことができる。これらの値は、アプリケーション有意名にしたがって名前変更することができる。新しいマッピングは、例えばノード・アプリケーションの集合で使用するアンサンブルの名前変更など、フィルタ中で動作可能、かつネットワークを介して可視であることが好ましい。
【００５０】
以上、本発明の実施例について詳述したが、以下、本発明の各実施態様の例を示す。
【００５１】
（実施態様１）
アンサンブル・パラメータにしたがってデータを規定するアンサンブル・フィールドと、
機能パラメータにしたがってデータを規定するメッセージ・タイプ・フィールドと、
データを識別する変数名フィールドと
を含む、データの関係特性インタフェース。
【００５２】
（実施態様２）
タイムスタンプ、単位、位置、値、値記憶タイプ、システム変数、ローカル環境変数、アプリケーション環境変数、ユーザ定義変数を含むグループから選択した、少なくとも１つの任意選択のフィールドを含む、実施態様１に記載のデータの関係特性インタフェース。
【００５３】
（実施態様３）
アンサンブル・フィールドが、関係特性インタフェース中の少なくとも１つのその他のフィールドに対する機能関係を含む、実施態様２に記載の関係特性インタフェース。
【００５４】
（実施態様４）
アンサンブル・フィールドが、兄弟、親、子の関係を示す階層を含むことを特徴とする、実施態様２に記載の関係特性インタフェース。
【００５５】
（実施態様５）
通信ネットワークと、
個別に通信ネットワークに接続された、２つの構成要素のうち一方が関係特性インタフェースを使用するアプリケーションを有し、２つの構成要素のうち他方が関係特性インタフェースにしたがってデータを選択するためのフィルタリング特性を有する２つの構成要素とを含み、
２つの構成要素のうちの「ポスト側」がデータをポストし、２つの構成要素のうちのフィルタリング手段を含む「受信側」がデータを受信し、フィルタリング手段を使用することによって関係特性インタフェースに加えられたフィルタリング特性にしたがって選択的にデータを受け入れることを特徴とする、
実施態様２に記載のデータの関係特性インタフェースを使用する情報システム。
【００５６】
（実施態様６）
フィルタリング手段が、通信ネットワークに接続するネットワーク・プロトコル・スタックを含み、関係特性インタフェースおよびフィルタ特性にしたがって選択的にデータを受信するように動作することができる、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００５７】
（実施態様７）
フィルタリング手段が、ネットワーク・プロトコル・スタックに接続された通信手段を含み、関係特性インタフェースおよびフィルタ特性にしたがってデータを受信してフィルタリングする、実施態様６に記載のデータの関係特性インタフェースを使用する情報システム。
【００５８】
（実施態様８）
フィルタリング手段が、フィルタ特性にしたがってデータを受信するためのフィルタをさらに含む、実施態様７に記載のデータの関係特性インタフェースを使用する情報システム。
【００５９】
（実施態様９）
フィルタリング手段が、フィルタ特性にしたがって選択されたデータを処理するための入力ａｐｐ−ｖａｒを含む、実施態様７に記載のデータの関係特性インタフェースを使用する情報システム。
【００６０】
（実施態様１０）
フィルタリング手段が、データを処理してポストする出力ａｐｐ−ｖａｒを含む、実施態様７に記載のデータの関係特性インタフェースを使用する情報システム。
【００６１】
（実施態様１１）
関係特性インタフェースの少なくとも１つのフィールドが、そのフィールドのフィルタリングがネットワーク・プロトコル・スタックによって実施されるように、ネットワーク・プロトコル・スタックのアドレス構造にマップされることを特徴とする、実施態様６に記載の情報システム。
【００６２】
（実施態様１２）
このマッピングが、ネットワーク・プロトコル・スタックのマルチキャスト・アドレスに対するものであり、このマルチキャスト・アドレスが、ネットワーク・プロトコル・スタック中で最初に選択されたレベルであることを特徴とする、実施態様１１に記載の情報システム。
【００６３】
（実施態様１３）
アンサンブル・フィールドが、マップすべき関係特性インタフェースのフィールドであることを特徴とする、実施態様１１に記載の情報システム。
【００６４】
（実施態様１４）
２つの構成要素のうちポスト側が関係特性インタフェースを含み、２つの構成要素のうち受信側がフィルタ特性を含むことを特徴とする、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００６５】
（実施態様１５）
２つの構成要素のうちポスト側がフィルタ特性を含み、２つの構成要素のうち受信側が関係特性インタフェースを含むことを特徴とする、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００６６】
（実施態様１６）
アンサンブル・フィールドがフィルタ特性に対応することを特徴とする、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００６７】
（実施態様１７）
対応するフィルタ・フィールドおよび関係特性フィールドの評価順序を動的に選択するフィルタリング手段を含む、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００６８】
（実施態様１８）
関係特性インタフェースのフィールドが動的に変更されることを特徴とする、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００６９】
（実施態様１９）
フィルタのフィールドが動的に変更されることを特徴とする、実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００７０】
（実施態様２０）
データをポストする構成要素が、親子関係、機能性、要求を含むグループから選択された環境パラメータにしたがってデータをポストする、
親子関係がエンティティのクラスを規定し、
機能性がアプリケーションの動作パラメータおよび環境パラメータを規定することを特徴とする、
実施態様５に記載のデータの関係特性インタフェースを使用する情報システム。
【００７１】
（実施態様２１）
アンサンブル・フィールドが、関係特性インタフェース中の少なくとも１つのその他のフィールドに対する機能関係を含む、実施態様５に記載の関係特性インタフェース。
【００７２】
（実施態様２２）
アンサンブル・フィールドが、兄弟、親、子の関係を示す階層を含むことを特徴とする、実施態様５に記載の関係特性インタフェース。
【００７３】
【発明の効果】
以上のように、本発明を用いると、通常エンティティおよび集合エンティティからなる分散システム中でバインディングを確立することを可能となる。
【図面の簡単な説明】
【図１】本発明を使用して構築したシステムを示すブロック・ダイアグラムである。
【図２】本発明のサポートに有効な構成要素内部の好ましい実施形態を示す図である。
【図３】関係特性インタフェースを示す図である。
【符号の説明】
１２N：構成要素
１４i：ノード・アプリケーション
１６：ネットワーク
２０Ａ：プロトコル・スタック・ハードウェア
２０Ｂ：プロトコル・スタック・ファームウェア
２２：通信基礎構造
２４：入力フィルタ
２６：入力ａｐｐ−ｖａｒ
２８：出力ａｐｐ−ｖａｒ
【図１】
0003871420.tif 000002
【図２】
0003871420.tif 000003
【図３】
0003871420.tif 000004