JPH10190707A

JPH10190707A - データの関係特性インタフェース

Info

Publication number: JPH10190707A
Application number: JP9340013A
Authority: JP
Inventors: John C Eidson; ジョン・シー・エイドソン; Clark Nicholson; クラーク・ニコルソン; Gerald Weibel; ジェラルド・ウエイベル; Dennis O'brien; デニス・オブライアン; Jay M Wardle; ジェイ・エム・ワードル; Glenn R Engel; グレン・アール・エンジェル; Der Meulen Ronald Van; ロナルド・バン・デル・ミューレン
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1996-12-11
Filing date: 1997-12-10
Publication date: 1998-07-21
Anticipated expiration: 2017-12-10
Also published as: JP3871420B2; US6167457A; DE19748860A1

Abstract

(57)【要約】【課題】通常エンティティおよび集合エンティティから
なる分散システム中でバインディングを確立することを
可能にする、フレキシブルでありながら短縮された専門
語および方法を提供する。【解決手段】ネットワークへのインタフェースは、通常
はオペレーティング・システム、またはノード・アプリ
ケーション１４_iを実行する環境の一部である、プロト
コル・スタック２０を介している。ネットワークのプロ
トコル・スタック２０と相互作用する通信基礎構造２２
は、プロトコル・スタックを増やし、様々な可能なサー
ビスを提供するサポート・コードである。入力フィルタ
２４は、ＲＣＩとフィルタの組合せによって指定された
抜き出し特性を、バインディングされていないデータに
適用する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、測定および制御の領域
で使用する分散システムを対象とする。詳細には、メッ
セージ・フィルタリングと、自動バインディング(bindi
ng)と、フィールドの符号化、ならびに分散システムの
構築および委託（コミッショニング）に関連したその他
の項目に関する。

【０００２】

【従来の技術】多くの測定および制御アプリケーション
は、遠隔的に配置されたいくつかの変換器、例えばセン
サまたはアクチュエータとともに中央制御装置を使用す
る。これらの変換器はポイント・ツー・ポイント・リン
ク(point to point link)を介して中央制御装置に接続
される。最近では、いくつかのこれらの装置がパケット
・ベース・バスを共有して中央制御装置と通信すること
だけでなく、ピア・ツー・ピア通信を使用した分散動作
も可能にする、いくつかの「フィールド・バス」が現れ
ている。バスは、この共有した媒体を介した通信パター
ンを確立するためにアドレス指定方式を必要とする。こ
れらのアドレス指定方式は、システムの個々のノードま
たは計算エンティティの中のアドレス可能な各エンティ
ティに、「タグ」と呼ばれる識別子を割り当てることに
よって、しばしば実施される。このようなエンティティ
の間での通信パターンは、各パターン中のエレメントを
規定する様々なタグを関連づける、すなわち「バインデ
ィングする」ことによって確立される。

【０００３】１９８９年７月２７日に発行された米国特
許第５，１８７，７８７号にＳｋｅｅｎらによって開示
されたタグ・ベースのバインディングの一例は、「主体
(subject)ベースの」アドレス指定を使用する発行者／
加入者ベースシステムである。主体は、解析可能な階層
構造を有するタグとして規定される。例示すると、「Ｓ
ＦＢ．Ｐ３９．ｔｅｍｐ」というタグは、「temperatur
e at Pier 39 on SanFrancisco Bay」（サンフランシス
コ湾第３９桟橋の温度）を表す。この温度がタグ「ｄｉ
ｓｐｌａｙ＿７．ｒｏｗ２」とともに報知器に表示され
る場合には、これら２つのタグは、規定された手順に従
って「バインディングされて」使用されることになる。
これらのタグ・フィールドは、ストリング形式である。

【０００４】

【発明が解決しようとする課題】タグの名前スペースの
管理は、通信パターンの複雑化とともに増加する。結果
として、単一の構造で数種類の情報を表現するために
は、タグにオーバロードしなければならない。オーバロ
ード状態のタグをバインディングすることにより、計算
可能性は制限される。バインディング「temperature at
Pier 39 on San Francisco Bay」は、温度が報告され
たこと、その測定が第３９桟橋で行われたこと、それが
サンフランシスコ湾に位置することという、３つのデー
タを組み合わせている。システムが、塩分濃度やｐＨな
どのサンフランシスコ湾環境の多種の測定、および第３
９桟橋以外に多数の位置を含む場合には、その結果得ら
れるタグの名前スペースは非常に大きくなることにな
る。

【０００５】もう１つの問題は、タグによって参照され
る値の単位および記憶タイプが、暗黙のうちにバインデ
ィングされることである。１つのサイトでは温度が華氏
の整数で報告され、別の位置ではその値が摂氏の実数で
報告されることもある。バインディングが確立されてい
る場合は、同様の単位および記憶タイプのみがバインデ
ィングされること、または適当な変換動作が提供される
ことを保証するように留意しなければならない。より明
白に表現を規定することが必要である。

【０００６】オーバロード状態のタグは、いくつかのソ
ースからのデータについて計算を行わなければならない
システムには不適である。しばしば、計算不可能な形状
の空間データが、測定中のデータとともにタグにオーバ
ロードされる。システムが、第３９桟橋付近の海岸地区
に沿った温度勾配を計算する必要がある場合には、必要
なバインディングを確立し、必要な空間データを抜き出
すことは困難になる。

【０００７】タグ・ベース・システムは、動的に変化す
る要件にしたがってデータを管理するためのアプリケー
ション・コードおよびバインディングの開発を妨げる可
能性がある。新しい空間位置を導入することは、既存の
タグと矛盾しない名前を確立し、その後にバインディン
グ過程に戻ることを含む。問題は、空間データの表現が
静的かつ不適当であること、およびバインディングの静
的特性の両方にある。同様に、バインディングを動的に
変更して様々なデータを受信すること、例えば、変化し
ている位置の範囲内の全ての位置から温度測定を受信す
ることは困難である。

【０００８】タグ・ベース・アーキテクチャは、正確に
分散した計算エンティティおよび通信エンティティを生
み出すという問題の役には立たない。集合エンティティ
は、単一の構成要素で実行される単一のプログラムや、
通常のまたは短縮されたエンティティまたはアプリケー
ションとして挙動するが、実際には、いくつかの構成要
素で実行され、集合して１つになって現れる、プログラ
ム・フラグメント（fragment：破片）の集合である。集
合中のどのフラグメントが、特定の時間に任意の特定の
バインディングに含まれることになるかを述べること
は、通常は不可能である。これらのエンティティは、こ
れらのタグ・ベース・システムに不適である。

【０００９】必要なのは、通常エンティティおよび集合
エンティティからなる分散システム中でバインディング
を確立することを可能にする、フレキシブルでありなが
ら短縮された専門語(nomenclature)および方法である。
このような専門語および方法が動的な性質を有し、アプ
リケーションの意味の豊かで計算可能な表現を見込んで
おくことがさらに望ましい。

【００１０】

【課題を解決するための手段】本発明は、関係特性イン
タフェース（ＲＣＩ）に基づく分散システム中でバイン
ディングを確立する方法を規定する。ＲＣＩは、通常
は、アンサンブル、メッセージ＿タイプ、変数名といっ
た各フィールドを含む。タイム・スタンプ、単位、位
置、記憶タイプ、値などの任意選択のフィールドを指定
することもできる。フィールドを拡大して、ユーザ定義
フィールド、またはシステムの特性または「環境」変数
によって決まるフィールドを含むようにすることもでき
る。ＲＣＩは、内容に基づくフィルタリングおよび属性
に基づくアドレス指定という、バインディングを確立す
るための２つの方法を見込んでいる。

【００１１】アンサンブル・フィールドは、例えば温度
を分析する全ての計算エンティティなど、特定用途向け
基準による計算エンティティのセットを規定する。メッ
セージ＿タイプ・フィールドは、データ、すなわち「測
定または動作データ」、「セットポイント・データ」、
「イベント」、「管理」に対するアプリケーション意味
モデルを規定する。

【００１２】内容に基づくフィルタリングでは、バイン
ディングは、ＲＣＩを使用して論理制約を規定すること
によって確立される。データの提供側は、提供するデー
タの特性を表す値をＲＣＩの関連するフィールドに移植
する。データの受信側は、通信システムからＲＣＩに適
用された時に、突き合わせ特性に合うセットのみを許可
するフィルタ・パターンを指定する。提供側および受信
側はそれぞれ、ＲＣＩのキャラクタライザおよびフィル
タを動的に修正することができる。このモデルにより、
提供側は、受信側が潜在すること、またはこのデータに
受信側が特定の関心を持っていることを知ることなく、
記述ＲＣＩを備えたデータをポストすることができる。
受信側は、提供側の識別に関わらず、データのＲＣＩに
適用するフィルタを指定することにより、利用可能なデ
ータの領域中で彼ら自身の関心を自由に指定することが
できる。例示すると、提供側は、ＲＣＩフィールド｛ア
ンサンブル＝２、変数名＝「電圧」｝を含むデータに、
ペイロード値＝７、および単位＝「ボルト」をポストす
ることができる。｛アンサンブル＝２、変数名＝＊（任
意）｝のフィルタを備えた受信側、および｛アンサンブ
ル＝２、変数名＝「電圧」｝のフィルタを備えた受信側
ならこれを選択し、これにしたがって動作するが、｛ア
ンサンブル＝３、変数名＝＊｝のフィルタを備えた受信
側はこれを選択せず、これにしたがって動作しない。

【００１３】属性に基づくアドレス指定モデルでは、デ
ータの提供側は、受信側を特徴付けるデータを記述する
ＲＣＩに基づいて、フィルタ・パターンを指定する。こ
のフィルタは、提供側がポストするデータに取り付けら
れる。潜在する全ての受信側は、取り付けられたフィル
タを受信側を記述するＲＣＩに適用し、一致した場合
に、そのデータを受け取り、それにしたがって動作す
る。このモデルにより、提供側は、ＲＣＩフィールドが
規定するターゲットの特性に基づいて、データをターゲ
ットに向けることができる。フィルタおよびＲＣＩのフ
ィールドは、ポストする主データ内容、すなわちデータ
やコマンドなどを任意選択で含むことができる。さら
に、フィルタおよびＲＣＩのフィールドは、動的に変更
することができる。提供側は、そのような任意の受信側
がいるかどうかを知っている場合もあれば知らない場合
もあるが、それでもこの制約を指定することができる。
例示すると、適当なフィルタによって、提供側は更新パ
ラメータを含むデータ、すなわちペイロードをポストす
ることができ、フィルタとＲＣＩの組合せが「Ｆｉｒｍ
ｗａｒｅｒｅｖｉｓｉｏｎ２．３」に関してデータ
を抜き出す全てのエンティティは、このデータに対して
作用することになる。

【００１４】ＲＣＩ中のフィールドは、各フィールドが
明確な意味を有するように、標準的なデータ表現に基づ
くことが好ましい。これらの標準には、一般的な専門
語、および測定および制御アプリケーションでの使用に
基づくフィールドに対するユーザ拡張定義が含まれるこ
とがある。例えば、温度に関連するデータに対するデフ
ォルト変数名は「温度」で標準化され、そのフィールド
は列挙またはストリングを使用して生成されることにな
る。標準により、これらのシステムの構成要素の相互操
作性を最大限にしながら、必要なバインディングを確立
する際の困難は最小限に抑えられる。

【００１５】ＲＣＩは、単一のエンティティと同様に集
合エンティティにも適用することができる。制御システ
ムを形成するセンサおよびアクチュエータの集合は、そ
れ自体を、それ自体のＲＣＩを備えたエンティティと見
なすことができる。この集合に対するＲＣＩの様々な特
性は、実際には、集合の様々なエレメントに帰するが、
ＲＣＩ全体は単一のエンティティとして外界に現れる。

【００１６】

【実施例】図１は、本発明による分散型の測定および制
御システム１０を示す図である。システム１０は、例え
ばマイクロプロセッサなどの計算エレメント１２₁、１
２₂、１２₃、‥‥、１２_Nからなる。これらの計算エレ
メントの多くは、関連した変換器（図示せず）、すなわ
ちセンサまたはアクチュエータを備え、自然界と相互作
用する。各計算エレメントは、特定用途向けコードまた
はノード・アプリケーション１４₁、１４₂、１４₃、１
４₄、‥‥１４_iのフラグメントを少なくとも１つ含み、
これらは対応する計算エレメント上で実行される。ノー
ド・アプリケーションはプロセッサと１対１で対応する
ことができるが、複数で１つのプロセッサを共有する、
または単一のノード・アプリケーションが複数のプロセ
ッサを使用することもできる。各ノード・アプリケーシ
ョンは、１つまたは複数の明確なアプリケーションを表
現する。全てのノード・アプリケーション１４₁、１
４₂、１４₃、１４₄、‥‥１４_iは、ネットワーク１６に
データをポストし、そこからデータを受信する。

【００１７】仮想ノード・アプリケーション１８は、共
通のプロセッサに常駐する場合とそうでない場合とがあ
るノード・アプリケーションの集合である。この集成
は、協働して、完全な計算タスクを形成する。単独で
は、仮想ノード・アプリケーション中の各ノード・アプ
リケーションは、集合中のその他のノード・アプリケー
ションがなければ不完全である場合がある。

【００１８】ノード・アプリケーションおよび仮想ノー
ド・アプリケーションは、ネットワークを介して互いに
通信する。仮想ノード・アプリケーションの場合は、実
際の通信は１つまたは複数の構成要素ノード・アプリケ
ーションを伴う。ただし、仮想ノード・アプリケーショ
ン内における、またはこれを含むバインディングは、静
的である必要はない。

【００１９】複数のノード・アプリケーションの間で共
有されるデータの各項目は、関連したＲＣＩを有する。
ノード・アプリケーションは、ＲＣＩを特徴付ける。こ
の特徴付けを外部ツールによって任意選択でネットワー
クを介して行い、ＲＣＩの特徴付けをノード・アプリケ
ーション内の特定の項目と関連付けることができる。特
徴付けはまた、「インスタレーション」、または特徴付
けを、ノード・アプリケーションが利用できるその他の
データ、例えば関連したセンサやアクチュエータの測定
値や動作パラメータなどに基づくものとする、ノード・
アプリケーションのその他の部分によって割り当てられ
ることもできる。

【００２０】内容に基づくフィルタリングの場合、提供
側のノード・アプリケーションは、ネットワークにデー
タをポストし始める前に、このデータおよび必要な特徴
付けをＲＣＩに提供する。同様に、受信側のノード・ア
プリケーションはデータを受信し、着信したデータに関
連したＲＣＩに適用すべきフィルタ指定を提供する。こ
のフィルタに基づいて、適当なデータがネットワークか
ら抜き出され、受信側に渡される。

【００２１】属性に基づくアドレス指定では、提供側は
ネットワークにこのデータをポストし始める前に、必要
な特徴付けを取り付けられたフィルタに付加的に提供す
る。同様に、受信側は、ネットワークから抜き出して需
要側のノード・アプリケーションに渡す適当なデータを
選択するためにフィルタを適用すべき、必要なＲＣＩ仕
様を提供する。

【００２２】図２は、通常のシステム構成要素１２_Nの
次の水準の詳細を示す図である。ネットワークへのイン
タフェースは、通常はオペレーティング・システム、ま
たはノード・アプリケーション１４_iを実行する環境の
一部である、プロトコル・スタック２０を介している。
通常のプロトコル・スタックは、通信および計算の効率
を高めるために、ハードウェア２０Ａで実施される部分
とファームウェア２０Ｂで実施される部分とを有する。

【００２３】ネットワークのプロトコル・スタック２０
と相互作用する通信基礎構造２２は、プロトコル・スタ
ックを増やし、様々な可能なサービスを提供するサポー
ト・コードである。この構造は、ＣＯＲＢＡまたはＯＬ
Ｅインタフェースを提供する、または所望の通信モデル
を、特定のインスタレーションで必要とされるモデル、
例えばＳＰ−５０などのマルチマスタ・モデルや、ＴＩ
ＢＣＯ社で使用されるような公開／引用モデルにマップ
することができる。さらに、この構造は、プロトコル・
スタックにより、提供側および受信側が使用するポステ
ィングおよびフィルタリング・モデルを対等にする。こ
れは、フィルタをプロトコル・スタックおよびフィルタ
構造にマップすること、ならびに場合によってはパフォ
ーマンスを最大限にするためにフィルタの順序の適応変
化を実施することを含む。この構造は、後に述べるその
他のサービスをサポートする。通信構成管理構造は、規
定されたその他の構造を管理および構成し、ノード・ア
プリケーションおよび外部ツール両方に対して通常のイ
ンタフェースを提供してこれらの機能を実施する。

【００２４】入力フィルタ２４は、ＲＣＩとフィルタの
組合せによって指定された抜き出し特性を、バインディ
ングされていないデータに適用する。基準に合うデータ
のみが、入力ａｐｐ−ｖａｒ構造に渡される。

【００２５】好ましい実施形態では、各ＲＣＩのフィル
タリングの一部は、最初にプロトコル・スタックのハー
ドウェア部分２０Ａに割り当てられ、その後ファームウ
ェア部分２０Ｂに割り当てられる。このようにして割り
当てられるフィルタリングの量は、使用する特定のプロ
トコル・スタックによって決まる。例えば、イーサネッ
トの実装では、通常は、単一のフィルタをハードウェア
で実施することができる。プロトコル・スタック２０お
よび入力フィルタ２４へのＲＣＩフィールドのマッピン
グの詳細については、後に論じる。この割り当ては静的
なものではなく、ノード・アプリケーション１４_iによ
って動的に変更する、またはフィルタリングを適応的に
行ってパフォーマンスを最大限にするように実施するこ
ともできる。

【００２６】通常は入力フィルタ２４からのデータを受
信する入力ａｐｐ−ｖａｒ２６は、複数のノード・アプ
リケーション１４_i間でデータ伝送を行うための、シス
テム全体データ・モデルに基づく任意選択のデータ構造
である。ＲＣＩの多くのフィールドはこのデータ・モデ
ルに含まれ、受信したデータの生成側から割り当てられ
た値は、入力ａｐｐ−ｖａｒのフィールドに現れること
になる。「ａｐｐ−ｖａｒ」により、ノード・アプリケ
ーション１４_iが使用可能な付加的なサポート構造を構
築することができ、それは例えば、ａｐｐ−ｖａｒのタ
イムスタンプ・フィールドでの計算のためのコード、エ
ンティティを規定したノード・アプリケーション１４_i
へのａｐｐ−ｖａｒフィールドの自動割り当てまたは記
憶、等である。ａｐｐ−ｖａｒは、ＲＣＩフィールドに
基づいて、あるいは型付きデータ・モデルが使用されて
いる場合にはメッセージ・タイプに基づいて着信データ
を自動的に妥当な記憶タイプに割り当てるサポート・コ
ードを備えて、データの値フィールド用の特定の記憶タ
イプ向けに構築することができる。さらに、ａｐｐ−ｖ
ａｒは、ノード・アプリケーション１４_iが見える表現
と、ネットワークが見える表現により使用される表現と
の間で、フィールドを自動的に符号化および復号化する
ことができる。その後、入力ａｐｐ−ｖａｒ２６はアク
セス可能になり、関連したノード・アプリケーション１
４_i中で動作をトリガすることができる。

【００２７】外部へのデータは、ノード・アプリケーシ
ョン１４_iから任意選択の出力ａｐｐ−ｖａｒ２８に移
り、その後通信基礎構造２２に移る。入力ａｐｐ−ｖａ
ｒと同様に、出力ａｐｐ−ｖａｒ２８のサポート・コー
ドは、ノード・アプリケーション１４_iによってこのよ
うに構成されている場合には、いくつかのフィールドで
自動的に生成する、例えばタイムスタンプを自動生成す
ることができる。ノード・アプリケーション１４_iはま
た、データに関連したＲＣＩまたはフィルタ（選択した
通信モデルによる）のフィールドを指定することもでき
る。出力ａｐｐ−ｖａｒデータは、その後、通信基礎構
造ブロック２２を介してプロトコル・スタック２０に転
送される。このａｐｐ−ｖａｒの機能は、各ノード・ア
プリケーション１４_iで実施することもでき、この場合
は通信基礎構造２２に直接転送されることになる。

【００２８】図３は、本発明のＲＣＩの実施形態を示す
図である。このインタフェースは、図２に図示した詳細
な機構を使用する図１に示したノード・アプリケーショ
ンまたは仮想ノード・アプリケーション間での通信を確
立するための基礎として使用される。フィールドは、ア
ンサンブル、メッセージ＿タイプ、変数名である。任意
選択のフィールドには、タイムスタンプ、単位、位置、
値が含まれるが、これらに限定されることはない。

【００２９】詳細には、特定用途向けデータとは対照的
にシステムまたは環境を特徴付ける意味および値を反映
する任意選択のフィールドが許可される。例えば、ＲＣ
Ｉは、現地時間ゾーン、ノードを所有する「部門または
人」、構成要素の改訂年月日、製造番号、時刻、ローカ
ルにログされたデータ量などを表すフィールドを含むこ
とができる。

【００３０】任意のノード・アプリケーションまたは仮
想ノード・アプリケーションによってネットワークにポ
ストされた全てのパケットは、アプリケーション・ヘッ
ダおよびペイロード記録を含む。この実施形態では、内
容に基づくフィルタ・モデルの場合のＲＣＩ、または属
性に基づくアドレス指定モデルの場合のフィルタを、ヘ
ッダとペイロード記録の間で配分する方法を指定しな
い。これは、効率を目的として設計されるべき、実施方
法によって決まる問題である。

【００３１】アンサンブル・フィールドは、多少大きめ
のタスクを協働して実行するノード・アプリケーション
および仮想ノード・アプリケーションのエンティティを
規定する。このエンティティ中の親子関係は、アプリケ
ーションの必要にしたがって確立され、共通の主体や、
共通の機能、または共通の属性などの基準に基づくこと
ができる。例示すると、アンサンブル・フィールドは、
特定の住居(residence)アドレスと関連したノード・ア
プリケーションのエンティティであると規定することが
でき、この場合、アンサンブル・フィールドは、電気計
器など、独自のエンティティとして各住居に存在する構
成要素のＵＵＩＤ(Universally UniqueIDentifier)であ
ることができる。通信基礎構造は、このアンサンブルの
表現を、その下にある通信プロトコルのアドレス構造に
マップする。あるいは、アンサンブル中の親子関係は、
１以上のフィールドの算出機能であることがあり、この
システムがフィルタリングのローカル修正を可能にして
から時間経過とともに変化することができる。例えば、
アンサンブルは、ある範囲で現在温度を測定中の全ての
ノード・アプリケーションを備えることがある。この場
合は、アンサンブル中の親子関係は動的に計算される。

【００３２】メッセージ＿タイプ・フィールドは、アプ
リケーションが定義したパケットの関数的意味の点か
ら、データを分類する。例示すると、データ・パケット
は、測定データを含むもの、何らかのイベントを説明す
るもの、時間同期などの何らかの広域プロトコルに関す
るもの、またはコマンドを含むものとして分類すること
ができる。

【００３３】変数名フィールドは、データ・パケットに
含まれる項目の名前を記述する。変数名は、メッセージ
＿タイプ・フィールドによって決めることができ、例え
ば、時間同期プロトコルは、通常はこの属性によって分
化された異なるデータを実行するいくつかの異なるパケ
ットを有する。イベント・パケットは、イベントの種類
を指定するトークンとしてこの属性を使用する。データ
・パケットは、この名前を使用して、測定した電圧など
の物理量を指定する。変数名フィールドの好ましい実施
形態では、各メッセージ・タイプを表現するためのデフ
ォルトおよび規則を規定する。データ・パケットの場合
は、デフォルトの変数名が、測定した物理量に対するＳ
Ｉで指定された名前と一致したときに、ＲＣＩの最大の
相互操作性および有用性を得ることができる。

【００３４】タイムスタンプ・フィールドは、パケット
を生成する構成要素にローカルなクロックで測定された
時間を示す。時間の割り当ては、メッセージ＿タイプと
は異なる。データ・パケットの場合は、タイムスタンプ
は、データが測定されたローカル時間を表すことにな
る。イベントの場合は、イベントが発生した時間などを
表すことになる。この属性がない場合には、「今」など
のシステム全体に定義された方法で時間を解釈しなけれ
ばならない。

【００３５】単位フィールドは、値フィールドが存在す
る場合に、これを表現する単位を指示する。相互操作性
は、ＳＩなどの標準単位表現をシステム全体で使用して
いるときに向上する。

【００３６】位置フィールドは値に関連する空間位置、
すなわちデータを測定した位置を表すことができる。様
々な表現を使用することができる。所与のアプリケーシ
ョンに対して、一般には１つの表現が計算可能性を促進
し、例えば、地理座標は環境データに適している。

【００３７】値フィールドは、メッセージ＿タイプ・フ
ィールドの内容にしたがって値を示し、例えば、データ
・パケットでは、値は指定された単位の測定値である。
あるいは、値をデータとして解釈しながら、コマンドま
たは要求としても解釈することもできる。解釈の意味
は、メッセージ＿タイプ・フィールドによって示される
ことになる。

【００３８】記憶タイプ・フィールドは、値フィールド
を浮動小数や整数などとして表す記憶タイプを指示す
る。データ・パケット中で記憶タイプ・フィールドが明
白でない場合には、「型付きａｐｐ−ｖａｒ」を規定す
ることによって記憶タイプにしたがって、データ・パケ
ットを暗黙に分類することができる。

【００３９】好ましい実施形態では、全てのフィールド
は、フィールドの意味、表現、デフォルト値、および非
デフォルトの場合の規則を指定する明確なデータ・モデ
ルを有する。可能なら、これらのデータ・モデルは国際
標準を厳守し、例えば、変数名フィールドは、測定する
物理量に対するデフォルトとしてＳＩで指定された名前
を使用する。同様に、ＳＩ単位は単位フィールドを表す
ことになる。時間は、ＵＴＣ(Utilities Telecommunica
tions Council)などの標準を厳守する。標準が存在しな
い場合には、残りのフィールドが適当に規定されたシス
テム全体データ・モデルを使用する。明確なデータ・モ
デルを使用することにより、その結果生じる構成要素の
相互操作性は向上し、ＲＣＩの有用性は最大限になる。
ＲＣＩが豊かになるので、デフォルトの論理式で、バイ
ンディングの仕様の大部分を十分に確立することができ
る。

【００４０】これらの全てのＲＣＩフィールドは、ノー
ド・アプリケーションまたは仮想ノード・アプリケーシ
ョンからネットワークにポストされたパケットの、アプ
リケーション・ヘッダおよびユーザ・スペース部分を表
す。通信を確立するために、これらのフィールドのサブ
セットを使用して、バインディングまたはマッピングを
規定する。これは、必要ではないが好ましくはマルチキ
ャスト・プロトコルを使用して全てのパケットをポスト
すること、および構成要素中のノード・アプリケーショ
ンまたは仮想ノード・アプリケーションによるパケット
受け入れを、１以上のこれらのフィールドを使用して入
力フィルタを形成することによって指定された論理制約
に基づいて行うことにより実行される。「ポスタ／フィ
ルタ」パラダイムは、データ・パケットをポストするノ
ード・アプリケーション、およびデータ・パケットのサ
ブセットをフィルタするもう１つのノード・アプリケー
ションを備える。

【００４１】好適な実施形態では、１つのフィルタ・フ
ィールドが通信プロトコルのハードウェア・フィルタに
割り当てられ、残りのフィルタ・フィールドは、例えば
さらに高レベルのプロトコル・スタックや図２の入力フ
ィルタに割り当てられる。イーサネットはマルチキャス
ト通信をサポートし、ほとんどのイーサネット・チップ
・セットは、１レベルのハードウェア・フィルタリング
を備える。アンサンブル・フィールドは、協働するノー
ド・アプリケーションのグループを規定するので、スタ
ックの最低レベル、好ましくはハードウェア・フィルタ
に、マップされるまたは割り当てられることが好まし
い。これにより、通常は、最も効率的な第１フィルタが
生じることになる。アンサンブル・フィールドの実際の
表現またはマッピングは、ネットワーク・プロトコルの
アドレス構造によって決まることになる。ハッシングな
どの様々な方法を使用してこのマッピングを実施するこ
とができる。

【００４２】好適な実施形態では、アンサンブル・フィ
ールドは、明確なデータ・モデルおよび表現、詳細には
階層構造を有する。アンサンブルの階層の最高レベル
は、関係を記述するデフォルトの名前、たとえば「同
僚」、「兄弟」、「親」、「子」などを含む。これらの
関係は、アンサンブルが、ノード・アプリケーションの
論理「兄弟」のみを含む、またはノード・アプリケーシ
ョンおよびその「親」のみを含むといったことを示す。
さらに、ユーザ定義のグループ名を使用することもでき
る。アンサンブルの名前スペースを構築することによ
り、システムの構成要素、例えばルータが、この情報を
使用できるようになる。

【００４３】受け入れられるデータの抜き出しは、フィ
ルタの順序とは無関係である。このことにより、ネット
ワーク上の最近のデータの混合に基づいて、最も効率的
（計算サイクルに関して）なフィルタを生成するように
フィルタリング順序を適応させるフィルタを提供するよ
うな方法で、図２の通信基礎構造および通信構成管理ブ
ロックを実施することができる。

【００４４】好適な実施形態では、提供側は指定通りに
それらのデータを自動的にポストし、受信側はネットワ
ークから利用できるデータをフィルタして、興味のある
項目を抜き出す。

【００４５】もう１つの実施形態では、提供側は、アプ
リケーションまたはシステムの定義条件が合うときにの
みそれらのデータをポストする。ポストされないデータ
は、ノード・アプリケーションの設計に従って局所的に
ログされる場合と、または破棄される場合とがあるが、
その決定もまた、アプリケーションまたはシステムの定
義条件に基づいて行うことができる。これらの条件は、
システムまたはノード・アプリケーションが規定する特
性に基づく論理仕様として表されることが好ましく、例
えば、システム定義条件は、「ノード・アプリケーショ
ンの個々の列挙型クラスが少なくとも１つ存在する場合
にポストする」などの親子関係条件になる。ノード・ア
プリケーション定義条件の一例としては、「センサから
の値が規定範囲内にある場合にポストする」がある。こ
のポスティングの条件スタイルは、「条件に基づくポス
ト」と呼ばれる。この条件が、ソースに一致するＲＣＩ
フィルタ・パターンの存在によって証明される、データ
に対する特定の必要の存在を反映する場合には、「要求
に基づくポスト」と呼ばれる。後者の形成は、後述する
需要側データ・サービスを使用して実施することができ
る。

【００４６】好ましい実施形態の通信基礎構造ブロック
もまた、本発明で利用するＲＣＩ、および発行／引用モ
デルまたはポスト／フィルタ・モデルによって可能にな
るサービスの集合を実施する。これらのサービスは任意
選択であるが、何らかのシステムで、特にシステムの管
理および構成を援助するツールを実施する場合には有効
である。サービスは、通常のクライアント・サーバ・モ
デルのネットワークを介して外部からノード・アプリケ
ーションによって呼び出すか、またはこの実施態様によ
るＲＣＩモデルを使用して呼び出すことができる。この
後者のモデルは、各メンバについて個別に呼び出すので
はなく、ＲＣＩが規定した集合として処理される一群の
ノード・アプリケーションのサービスを呼び出す機構を
提供するので、大型システムで特に有効である。同様に
サービス自体が、ノード・アプリケーションと同様の機
構を使用して、ポストすべきデータの提供側となること
も可能である。

【００４７】これらのサービスの好適なセットについ
て、以下に述べる。提供側のデータ・サービスは、デー
タのＲＣＩに基づく現在利用できるデータのリストを保
持する。提供側はこのサービスに登録し、データが存在
することを公示する。このサービスを照会して、潜在的
にはソース(source)など、ある特徴付けを備えたデータ
が存在することを確認することができる。同様に、この
サービスは、更新を利用可能なサービスの集合に自動的
にポストすることもできる。このサービスは、集中させ
る必要はないが、それ自体が分散型の特殊目的ノード・
アプリケーションの集合として現れることができる。

【００４８】受信側のデータ・サービスは、システム中
で現在活動状態にあるＲＣＩフィルタ・パターンのリス
トを保持する。受信側はこのサービスに登録し、特定の
データが必要であることを公示する。このサービスを照
会して、例えば要求側など、ある特徴付けを備えたデー
タを求める要求が存在することを確認することができ
る。同様に、このサービスは更新を集合にポストするこ
とができる。このサービスは、集中させる必要はない
が、それ自体が分散型の特殊目的ノード・アプリケーシ
ョンの集合として現れることができる。

【００４９】マッピング・サービスにより、ＲＣＩフィ
ールドの値を１つの表現から別の表現にマップすること
が可能になる。これにより、包括的に規定されたＲＣＩ
フィールドの値を、ノード・アプリケーションに書き込
むことができる。これらの値は、アプリケーション有意
名にしたがって名前変更することができる。新しいマッ
ピングは、例えばノード・アプリケーションの集合で使
用するアンサンブルの名前変更など、フィルタ中で動作
可能、かつネットワークを介して可視であることが好ま
しい。

【００５０】以上、本発明の実施例について詳述した
が、以下、本発明の各実施態様の例を示す。

【００５１】（実施態様１）アンサンブル・パラメータ
にしたがってデータを規定するアンサンブル・フィール
ドと、機能パラメータにしたがってデータを規定するメ
ッセージ・タイプ・フィールドと、データを識別する変
数名フィールドとを含む、データの関係特性インタフェ
ース。

【００５２】（実施態様２）タイムスタンプ、単位、位
置、値、値記憶タイプ、システム変数、ローカル環境変
数、アプリケーション環境変数、ユーザ定義変数を含む
グループから選択した、少なくとも１つの任意選択のフ
ィールドを含む、実施態様１に記載のデータの関係特性
インタフェース。

【００５３】（実施態様３）アンサンブル・フィールド
が、関係特性インタフェース中の少なくとも１つのその
他のフィールドに対する機能関係を含む、実施態様２に
記載の関係特性インタフェース。

【００５４】（実施態様４）アンサンブル・フィールド
が、兄弟、親、子の関係を示す階層を含むことを特徴と
する、実施態様２に記載の関係特性インタフェース。

【００５５】（実施態様５）通信ネットワークと、個別
に通信ネットワークに接続された、２つの構成要素のう
ち一方が関係特性インタフェースを使用するアプリケー
ションを有し、２つの構成要素のうち他方が関係特性イ
ンタフェースにしたがってデータを選択するためのフィ
ルタリング特性を有する２つの構成要素とを含み、２つ
の構成要素のうちの「ポスト側」がデータをポストし、
２つの構成要素のうちのフィルタリング手段を含む「受
信側」がデータを受信し、フィルタリング手段を使用す
ることによって関係特性インタフェースに加えられたフ
ィルタリング特性にしたがって選択的にデータを受け入
れることを特徴とする、実施態様２に記載のデータの関
係特性インタフェースを使用する情報システム。

【００５６】（実施態様６）フィルタリング手段が、通
信ネットワークに接続するネットワーク・プロトコル・
スタックを含み、関係特性インタフェースおよびフィル
タ特性にしたがって選択的にデータを受信するように動
作することができる、実施態様５に記載のデータの関係
特性インタフェースを使用する情報システム。

【００５７】（実施態様７）フィルタリング手段が、ネ
ットワーク・プロトコル・スタックに接続された通信手
段を含み、関係特性インタフェースおよびフィルタ特性
にしたがってデータを受信してフィルタリングする、実
施態様６に記載のデータの関係特性インタフェースを使
用する情報システム。

【００５８】（実施態様８）フィルタリング手段が、フ
ィルタ特性にしたがってデータを受信するためのフィル
タをさらに含む、実施態様７に記載のデータの関係特性
インタフェースを使用する情報システム。

【００５９】（実施態様９）フィルタリング手段が、フ
ィルタ特性にしたがって選択されたデータを処理するた
めの入力ａｐｐ−ｖａｒを含む、実施態様７に記載のデ
ータの関係特性インタフェースを使用する情報システ
ム。

【００６０】（実施態様１０）フィルタリング手段が、
データを処理してポストする出力ａｐｐ−ｖａｒを含
む、実施態様７に記載のデータの関係特性インタフェー
スを使用する情報システム。

【００６１】（実施態様１１）関係特性インタフェース
の少なくとも１つのフィールドが、そのフィールドのフ
ィルタリングがネットワーク・プロトコル・スタックに
よって実施されるように、ネットワーク・プロトコル・
スタックのアドレス構造にマップされることを特徴とす
る、実施態様６に記載の情報システム。

【００６２】（実施態様１２）このマッピングが、ネッ
トワーク・プロトコル・スタックのマルチキャスト・ア
ドレスに対するものであり、このマルチキャスト・アド
レスが、ネットワーク・プロトコル・スタック中で最初
に選択されたレベルであることを特徴とする、実施態様
１１に記載の情報システム。

【００６３】（実施態様１３）アンサンブル・フィール
ドが、マップすべき関係特性インタフェースのフィール
ドであることを特徴とする、実施態様１１に記載の情報
システム。

【００６４】（実施態様１４）２つの構成要素のうちポ
スト側が関係特性インタフェースを含み、２つの構成要
素のうち受信側がフィルタ特性を含むことを特徴とす
る、実施態様５に記載のデータの関係特性インタフェー
スを使用する情報システム。

【００６５】（実施態様１５）２つの構成要素のうちポ
スト側がフィルタ特性を含み、２つの構成要素のうち受
信側が関係特性インタフェースを含むことを特徴とす
る、実施態様５に記載のデータの関係特性インタフェー
スを使用する情報システム。

【００６６】（実施態様１６）アンサンブル・フィール
ドがフィルタ特性に対応することを特徴とする、実施態
様５に記載のデータの関係特性インタフェースを使用す
る情報システム。

【００６７】（実施態様１７）対応するフィルタ・フィ
ールドおよび関係特性フィールドの評価順序を動的に選
択するフィルタリング手段を含む、実施態様５に記載の
データの関係特性インタフェースを使用する情報システ
ム。

【００６８】（実施態様１８）関係特性インタフェース
のフィールドが動的に変更されることを特徴とする、実
施態様５に記載のデータの関係特性インタフェースを使
用する情報システム。

【００６９】（実施態様１９）フィルタのフィールドが
動的に変更されることを特徴とする、実施態様５に記載
のデータの関係特性インタフェースを使用する情報シス
テム。

【００７０】（実施態様２０）データをポストする構成
要素が、親子関係、機能性、要求を含むグループから選
択された環境パラメータにしたがってデータをポストす
る、親子関係がエンティティのクラスを規定し、機能性
がアプリケーションの動作パラメータおよび環境パラメ
ータを規定することを特徴とする、実施態様５に記載の
データの関係特性インタフェースを使用する情報システ
ム。

【００７１】（実施態様２１）アンサンブル・フィール
ドが、関係特性インタフェース中の少なくとも１つのそ
の他のフィールドに対する機能関係を含む、実施態様５
に記載の関係特性インタフェース。

【００７２】（実施態様２２）アンサンブル・フィール
ドが、兄弟、親、子の関係を示す階層を含むことを特徴
とする、実施態様５に記載の関係特性インタフェース。

【００７３】

【発明の効果】以上のように、本発明を用いると、通常
エンティティおよび集合エンティティからなる分散シス
テム中でバインディングを確立することを可能となる。

【図面の簡単な説明】

【図１】本発明を使用して構築したシステムを示すブロ
ック・ダイアグラムである。

【図２】本発明のサポートに有効な構成要素内部の好ま
しい実施形態を示す図である。

【図３】関係特性インタフェースを示す図である。

【符号の説明】

１２_N：構成要素１４_i：ノード・アプリケーション１６：ネットワーク２０Ａ：プロトコル・スタック・ハードウェア２０Ｂ：プロトコル・スタック・ファームウェア２２：通信基礎構造２４：入力フィルタ２６：入力ａｐｐ−ｖａｒ２８：出力ａｐｐ−ｖａｒ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ジェラルド・ウエイベルアメリカ合衆国ワシントン州サウスイースト・エベレット 108ス・ストリート 3917 (72)発明者デニス・オブライアンアメリカ合衆国ワシントン州ノースイースト・マリースビル 44ス・ストリート 7615 (72)発明者ジェイ・エム・ワードルアメリカ合衆国ワシントン州シアトルノース・48ス・ストリート 1023 (72)発明者グレン・アール・エンジェルアメリカ合衆国ワシントン州レイク・スティーブンスタナー・ロード 3530 (72)発明者ロナルド・バン・デル・ミューレンアメリカ合衆国ワシントン州エベレットサパー・ヒル・ロード 8600

Claims

【特許請求の範囲】

【請求項１】アンサンブル・パラメータにしたがってデ
ータを規定するアンサンブル・フィールドと、機能パラメータにしたがってデータを規定するメッセー
ジ・タイプ・フィールドと、データを識別する変数名フィールドとを含む、データの
関係特性インタフェース。