JP2004500631A

JP2004500631A - Highly distributed wide-area data management using a database interface for data source networks

Info

Publication number: JP2004500631A
Application number: JP2001541964A
Authority: JP
Inventors: マイケル　ウィンブラット; ジュリオ　シー　ネイヴァス; カール−ハインツ　マイアー
Original assignee: Siemens Technology to Business Center LLC
Current assignee: Siemens Technology to Business Center LLC
Priority date: 1999-11-30
Filing date: 2000-11-30
Publication date: 2004-01-08
Also published as: CA2392826A1; AU781476B2; WO2001040973A3; IL149915A0; EP1250653A2; AU1807301A; WO2001040973A2

Abstract

データソースのネットワークを伝統的データベーススキーマの観点から提供する方法およびシステムが伝統的データベース照会をネットワークメッセージに変換し、これらのメッセージを関連データを有するデータソースにルーティングする。本発明では、データソースのネットワークインタフェースがメッセージを受け入れ、データソースの出力をメッセージ中の指示に従ってフィルタリングする。そして応答メッセージを照会の起点に送信する。次にこのシステムはこれらの応答メッセージを照会起点で収集し、照会結果を伝統的データベース結果として形成する。A method and system for providing a network of data sources in terms of a traditional database schema translates traditional database queries into network messages and routes these messages to data sources with associated data. In the present invention, the network interface of the data source accepts the message and filters the output of the data source according to the instructions in the message. Then, the response message is transmitted to the starting point of the inquiry. The system then collects these response messages at the query origin and forms the query results as traditional database results.

Description

【０００１】
関連する出願の相互参照
本出願は、共通に所有する米国特許願第６０／１６８４２５号、名称「ＡＳｙｓｔｅｍｆｏｒＣｏｍｍｕｎｉｃａｔｉｎｇｗｉｔｈａＮｅｔｗｏｒｋｏｆＳｅｎｓｏｒｓＴｈｒｏｕｇｈａＤａｔａｂａｓｅＩｎｔｅｒｆａｃｅ」、および第６０／１６８４２６号、名称「ＣｈａｒａｃｔｅｒｉｓｔｉｃＲｏｕｔｉｎｇ」、両方とも１９９９年１１月３９日出願からの優先権を主張する。本出願はまた同日出願の、共通に所有する米特特許願第０９／７２８３８０号、名称「ＣｈａｒａｃｔｅｒｉｓｔｉｃＲｏｕｔｉｎｇ」に関連するものであり、発明者はＪｕｌｉｏＣ．Ｎａｖａｓである。
【０００２】
発明の背景
情報、通信、およびオートメーション工業でのトレンドは、分散ソリューションである。このトレンドの最近の例は、ネットワーク化センサへの提案、およびこのようなデータソースのラージグループが大規模分散情報システム（データソースのネットワークと称される）を形成できるであるという示唆である。刊行物「ＮｅｘｔＣｅｎｔｕｒｙＣｈａｌｌｅｎｇｅｓ：ＭｏｂｉｌｅＮｅｔｗｏｒｋｉｎｇｆｏｒＳｍａｒｔＤｕｓｔ」（ＭｏｎｉＣｏｍｍ１９９９刊行）において著者Ｋａｈｎｅｔａｌ．はデータソースの分散ネットワークの例をセンサのネットワークの形態で論議している。
【０００３】
データソースのネットワークの最初のアイデアは、個別データソース、またはおそらくはデータソースのスモールグループをコンピュータネットワークに接続でき、その際に標準通信プロトコル、例えばインターネットプロトコル（ＩＰ）を使用できるであろうというものである。ネットワーク上の他のデバイスは、データソースにより提供されるデータにアクセスすることができ、これは個別にもまたはアプリケーションに依存してユニットでも可能である。もっとも野心的な提案では、データソースのワイヤレスネットワークがそれらのトポロジーを、それらが配置されているようにダイナミックに定義し、続いてそれらのリンクおよびルーティングスキーマを再定義して、新たなノードおよび欠陥ノードを説明し、電力管理を最適化しようと言うものである。データソースのネットワークの初歩形態はすでにいくつかの工業的プロセスコントロールシステムで使用されており、データソースのネットワークに対する将来的適用は多くの領域で広がることが予想される。
【０００４】
データソースのネットワークを鑑みた現在の問題点は、データソースからのデータをどのように管理するかである。このことは情報テクノロジ（ＩＴ）の世界における現在の技術と対比することができる。情報テクノロジにおいてはデータ管理技術が豊富である。ＩＴワールドでは、データ集合、タイプ指向のデータアクセス、照会最適化、トランザクション管理、データフィルタリング、データ最小化、および他の多数の技術が良好に確立された技術である。従ってメモリ、ディスク、または良好に確立された分散型データベースに常駐するデータに対して、データ管理は良く理解された技術である。しかしデータソースのネットワークはデータ管理に対して困難である。なぜなら、データソースの潜在的多数により送信されるデータは使用されるネットワークまたはデータ管理システムを圧倒することがあるからである。さらにネットワークのデータソースが連続的に、頻繁に変更または更新される情報を提供することもままある。
【０００５】
データソースのプロトタイプネットワークはコンピュータネットワーク世界からのプロトコルを使用する。これはＴＣＰおよびＵＤＰに基づくものであり、データ管理よりは通信に対して開発されたものである。工業システムは別の、しかし類似のプロトコルを使用する。これは例えばモードバスである。これらのプロトコルはメッセージをポイント・ツー・ポイントで転送するメカニズムまたはネットワークのすべてのメンバーにメッセージを同報通信するメカニズムを提供する。しかしこれらのプロトコルはしばしば不適当であり、効率的データ管理をデータソース世界のネットワークに提供するには制限値を有する。従って通信に対して開発されたこれらシステムタイプはより複雑で広大なコンピュータプログラムにおいては問題であり、データソースのネットワークでデータ管理に使用されるシステムをしばしばスクラッチからプログラマおよびシステム管理者により形成し、より洗練されたデータ管理技術を実現しなければならない。このことはＩＴテクノロジで適用することができるが、データソースのネットワークに対しては有効ではない。
【０００６】
制限されたデータ管理に対する１つのアプローチは、工業プロセスコントロールの分野に対して米国特許第５３０１３３９明細書（Ｂｏａｓｓｏｎｎによる）に記載されており、サブシステム間の通信に対するシステムを提供している。このサブシステムではリクエストがデータタイプに基づいて実行される。このようなシステムでは、所定タイプのデータを要求することができるが、要求されたデータの所望値を制約するメカニズムが存在しない。このようなメカニズムは伝統的データベース照会、例えばすべての温度センサに対して華氏１００度より高い温度の読み取りを要求するようなことを実現するにはクリティカルである。Ｂｏａｓｓｏｎにより書かれたシステムには、データサブ処理システムへのデータという観点からのデータベース、データを既述する関連スキーマまたはオブジェクトスキーマ、伝統的照会言語でのリクエストデータのファシリティが欠けている。従ってＢｏａｓｓｏｎのシステムは伝統的データベースのケーパビリティによりずっと下にある制限的データ管理ケーパビリティを提供するだけである。
【０００７】
データ管理の別のアプローチは、工業的プロセスに対するリアルタイム通信システムであり、米国特許第５０９３７８２号（Ｍｕｒａｓａｋｉｅｔａｌ．）に記載されている。ここではアプリケーションがリモートデータソースをデータソースの一部と見なす。このタイプのシステムでは、サブシステムがコントローラとしてリモートデータソースにアクセスし、これを使用し、これらリモート値のデータベースを管理する。このシステムはまず第１に、これらデータベースの更新に係るものである。このスキーマの１つの欠点は、各コントローラがその固有のデータベースを管理しなければならないことであり、このデータベースは所定の参照を各データソースに対して有していなければならない。アクセスデータを必要とする各サブシステムに対して、関連するすべてのデータソースのアドレスが固定的に符号化されなければならない。データベースはまたエラーポイントに集中することがある。このシステムのさらなる欠点は、データがデータソースからローカルデータベースの正当性を維持するために連続的にポーリングされなければならないことである。この種々のデータソースからの連続的ポーリングはネットワークに重いトラフィック負荷をかけることになる。
【０００８】
豊富なデータ管理ツールをデータソースのネットワークに追加する潜在的に有用な技術が分散型データベースコミュニティに見出すことができるが、分散型データベースでの従来の研究はデータソースのネットワークと共に使用するのには不適であるかまたは不完全である。
【０００９】
これら分散型データベース研究のいくつかは、データベースの構造的内容をコンピュータネットワークに拡大することができるように設計されており、単一のデータベースとしてアクセスされる。残念なことに、この研究の大部分は、刊行物「ＰｒｉｎｃｉｐｌｅｓｏｆＤｉｓｔｒｉｂｕｔｅｄＤａｔａｂａｓｅＳｙｓｔｅｍｓ」（Ｍ．Ｏｚｓｕ，Ｐ．Ｖａｌｄｕｒｉｅｚ，Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ，Ｉｎｃ．，ＵｐｐｅｒＳａｄｄｌｅＲｉｖｅｒ，ＮｅｗＪｅｒｓｅｙ，１９９９）に記載のように、公知のデータベースの断片化（データベースフラグメンテーション）に関連する問題に集中しており、この断片化によりデータへの後でのアクセスを最適化する。この技術は特にデータソースワールドのネットワークでは有用でない。なぜなら各データソースは、これが形成するデータを提供するだけであり、従ってどのようにデータを断片化すべきか選択することはできない。
【００１０】
別の分散型データベースアプローチが米国特許第４６３５１８９号（Ｋｅｎｄａｌｌ）、および米国特許第５１７９６６０号（Ｄｅｖａｎｙｅｔａｌ．）に記載されており、伝統的データベース照会を分散型データベース間で分割する機構を提供する。この分散型データベースへデータは時間的に先立て注意深く断片化されていない。しかしこのタイプのシステムはいくつかの理由からデータソースのネットワークには適さない。まず第１に、このアプローチはより伝統的な分散型データベースに関連するものであり、データの特定部分のネットワークロケーションが前もって既知であることが前提とされる。このような前提は、データソースのネットワークの多くのダイナミックな適用において当てはまらない。ここではデータソースをいつでも追加することができるからである。例えばそれぞれがデータソースとワイヤレスリンクの装備された複数の自動車により形成されるデータソースのネットワークを考察してみる。このネットワークはトラフィックモニタリングに使用される。データソースを有する新たな自動車が高速道路に進入し、このネットワークとつながると、この自動車の供給するデータは所望のように照会結果に含まれるべきである。しかしＫｅｎｄａｌｌ＆Ｄｅｖａｎｙｅｔａｌ．による従来のシステムは、データソースのネットワークに追加されるデータソースからのデータ入力に対して照会結果においてダイナミックに関与する機構を提供しない。第２に、Ｋｅｎｄａｌｌ＆Ｄｅｖａｎｙｅｔａｌ．によるシステムは、重要な処理ケーパビリティが各ネットワークノードの常駐していることを前提とする。この前提は、データソースの多くのネットワークに対して当てはまらない。ここではデータソース、アナログ／デジタル変換器およびネットワークインタフェースがネットワークノード全体を構成することがあるからである。類似のアプローチがＢｏｎｎｅｔｅｔａｌ．によって為された（Ｐ．Ｂｏｎｎｅｔ，Ｊ．Ｇｅｈｅｋｅ，Ｔ．Ｍａｙｒ，Ｐ．Ｓｅｓｈａｄｒｉ， ”ＱｕｅｒｙＰｒｏｃｅｓｓｉｎｇｉｎａＤｅｖｉｃｅＤａｔａｂａｓｅＳｙｓｔｅｍ”，ＣｏｒｎｅｌｌＴｅｃｈｎｉｃａｌＲｅｐｏｒｔＴＲ９９−１７７５，Ｏｃｔｏｂｅｒ１９９９参照）。彼らはデータソースのネットワークを特別にアドレシングしようと試みたが、この試みは同じ制限を有している。
【００１１】
従ってより効率的で洗練された照会ケーパビリティを提供するシステムおよび方法または技術が、データソースのネットワークの有効データ管理のために所望される。さらにデータソースシステムのネットワークにより経済的にデータ管理を提供することが所望される。このデータ管理は、各ネットワークノードが高い処理ケーパビリティを有することも、複雑なプログラミングの実現も必要としないようにすべきである。このことは従来のデータベース検索言語ではデータ管理技術を達成するために必要である。またデータソースのネットワークに対するこのようなシステムは、多量のデータ照会が可能であり、ネットワークに重いトラフィック負荷をかけずに通信できるようにすべきである。
【００１２】
発明の要約
上記に論議した問題点および欠点は、本発明により解決される。本発明により、従来の情報テクノロジデータ管理技術を直接データソースのネットワーク内に適用することができる。より詳細には本発明により、ネットワークに論理的に接続されたデバイス上でプログラムを実行することができる。このネットワークはまた論路的にネットワークデータソースを接続し、伝統的データベース照会をネットワーク上で発行し、ネットワークからこの照会の結果をこれがこのデータソースにより形成されたデータに適用されるときに受け取る。
【００１３】
本発明の実施例によれば本発明は、複数のノードを含む分散型データソースネットワークデータベースの情報管理方法を提供する。このノードは照会ノードおよび複数のデータソースを含む。この方法は、分散型データソースネットワークにスキーマを提供するステップ、データベース言語の照会をネットワークの照会ノードに入力するステップ、照会を少なくとも１つのネットワークメッセージに分解するステップ、そしてネットワークメッセージをこの照会に関連するデータソースにだけ伝送するステップを含む。この方法はさらに、ネットワークメッセージをこの照会に関連するデータソースで受信するステップ、応答メッセージをネットワークメッセージに、照会が適合したときに送信するステップ、そして照会結果をデータベース言語で照会ノードに応答メッセージから提供するステップを含む。
【００１４】
別の実施例によれば本発明は、分散型データソースネットワークデータベースの情報管理システムを提供する。このシステムは、ネットワーク、このネットワークに接続された複数のデータソース、そしてこのネットワークに接続された少なくとも１つの照会ノードを含む。このデータソースは情報をスキーマに従って分散型データソースネットワークデータベースに提供することができる。この照会ノードは照会をデータベース言語で受信し、照会を少なくとも１つのネットワークメッセージに分解することができる。このネットワークメッセージはネットワークを介してこの照会に関連するデータソースにだけ伝送される。この照会に関連するデータソースは、ネットワークメッセージに応じて照会が適合するときに応答メッセージをネットワークを介して送信し、照会ノードは照会結果をデータベース言語で応答メッセージから提供する。
【００１５】
本発明のこれら実施例および他の実施例そしてフューチャおよび利点を以下に、図面を参照して詳細に説明する。
【００１６】
図面の簡単な説明
図１は、本発明を使用することのできるネットワークアーキテクチャの例を示す。
【００１７】
図２は、本発明の実施例の一般的機能を説明する図である。
【００１８】
図３は、データベース照会をネットワークメッセージに、本発明の実施例にしたがって変換するための機能を説明する図である。
【００１９】
図４は、受信したネットワークメッセージを本発明の実施例にしたがって処理するネットワークインタフェースの機能を説明する図である。
【００２０】
図５Ａから図５Ｃは、本発明の実施例によるネットワークメッセージの収集と、照会結果のインタプリタのための機能を説明する図である。
【００２１】
実施例の詳細な説明
実施例によれば、本発明は以下のシステムを含む。すなわちこのシステムは、伝統的データベーススキーマの観点からデータソースのネットワークを表し、伝統的データベース照会をネットワークメッセージに変換し、これらのメッセージを、関連するデータを有するこれらのデータソースにルーティングする。本発明においては、データソースのネットワークインタフェースがメッセージを受け入れ、データソースの出力をメッセージの指示に従いフィルタリングし、応答メッセージを照会の起点に送信する。システムはこの応答メッセージを照会起点で収集し、照会結果を伝統的データベースとして形成する。
【００２２】
本発明は以下のシステム及び方法を提供する。すなわちこれらは、データソースのネットワークを複数の分散しているクライアントによって、このデータソースのネットワークが単一のデータベースであるように管理することができる。さらに具体的に言うと本発明は、ネットワークデバイスにおけるプログラムの実行がデータベース照会をこのデバイスのネットワークインタフェースに発行し、ネットワークインフラストラクチャのために照会の結果を計算し、この結果を照会デバイスにリターンする。本発明の実施例は、種々異なるアプリケーションにおける情報管理にとって有用であろう。特定のアプリケーションは、工場設備制御及び工場設備管理のような工業オートメーションにおけるものであり、これについては以下において例示的な対象として説明する。しかしながら他の実施例も論理的管理に有用であろう。この論理的管理は、配送サービスのパッケージ、火及び毒素を追跡する危機管理、高速道路の交通管理、スマートな建築またはスマートな戦場のセキュリティ管理及び他の多数のアプリケーションのようなものである。
【００２３】
以下詳細に説明するが、本発明によって以下の利点が提供される。すなわち、ユーザ又はプログラマがネットワークデータから、構造化照会言語（ＳＱＬ）のような広く知られている情報テクノロジスタンダードに従い、データにアクセスし、またデータを処理することができる。複数のユーザまたはプログラマがネットワークのいかなる場所からも、データソースのデータにアクセスし、またデータを処理することができる。ネットワークトラフィックはポーリングまたは継続的リフレッシュシステムに比べ顕著に低減する。データアクセスに対する中央エラーポイントを有さない。データは常にデータソースからリクエストノードへのダイレクトパスを移動するので、待ち時間は最小である。照会ノードが応答データソースの物理的位置を識別する必要はない。
【００２４】
図１は、本発明を使用することのできるネットワークアーキテクチャの例を示す。当業者はこの図をインターネットワーク１０と理解するであろう。すなわち、ネットワークのコレクションはネットワークルータ１５によって接続されており、このネットワークルータ１５は相互に接続することができる。タームルータはここでは公知のものが使用され、伝統的ルータ、ネットワークスイッチ、ゲートウェイ、ブリッジまたは制御ブリッジング固有のネットワークを含むことができる。また本発明を単一のネットワークにおいて使用することができるが、その価値はインターネットワークにおいて使用するよりも高いものである。各ネットワークを任意の個数のノードに接続することができる。このネットワークアーキテクチャにおいて種々のノード及びルータを接続している線路３５は、この実施例においてはワイヤードコネクションである。本発明を使用することができる他のアーキテクチャはワイヤレスネットワークである。このワイヤレスネットワークは上述の図１のネットワークとは異なり、ネットワークにノード間の直接的なコネクションは存在しないが、むしろデータは、伝送区間があればワイヤレス技術によって最も近いノードに接続されており、また場合によっては僅かに制限された線が設けられている。したがってこの実施例では、線路３５を無線インターネットワークに対する論理コネクションと見なすことができる。さらに、インターネットワークがワイヤレスネットワークとワイヤードネットワークの組み合わせを含む実施例では、線路３５はそれぞれ論理コネクションとワイヤードコネクションである。当業者は、伝送区間及び伝送率を変化する多くのアルゴリズムが帯域幅及び電力消費をより効率的に使用するために存在することを理解するであろう。さらには当業者は、アドホックネットワークと称されるモバイルまたはダイナミックノードのコネクトまたはリコネクトに使用される種々のアルゴリズムが存在することを理解するであろう。そのようなネットワークのアーキテクチャは定まっていない。本発明をいかなるアプローチにも適用することができる。
【００２５】
本発明によれば、ネットワーク上の各ノードはネットワークインタフェ−スを有し、照会をネットワークのデータ消費者ノードから形成することができる。ネットワークノードを、データ作成者２０、データ消費者２５または両方（データ作成者／消費者３０）とすることができる。データ作成者２０の例は、データソース（例えばセンサ）またはデータソースバンク（しばしば分散型Ｉ／Ｏと称される）を含む。データ消費者２５の例は、コントローラ及びモニタシステムを含む。データ作成者／消費者３０であるノードの例はユーザ操作パネルである。本発明の目的のために、１つまたは複数のデータソースに対するネットワークへのインタフェースとして動作するコントローラは単一のノードとみなされており、このノードはデータ作成者／消費者３０の別の例である。ネットワークのノードに、データ消費者ノード、データ作成者ノードまたはデータ作成者／消費者ノードの機能を、適切なソフトウェアが本発明にしたがいノードに組み込まれることによって備えさせることができる。しかしながら、ネットワークの全てのノードは、本発明に従い、本発明が動作するためにソフトウェアを備える必要は無い。
【００２６】
上述したように、ネットワーク上の各ノード（各データソースも含む）はネットワークインタフェースを有し、このネットワークインタフェースはノードが論理的に接続されているネットワーク上で使用されるネットワークプロトコルのタイプに適している。このネットワークインタフェースは、関連する伝統的ネットワークインタフェースプロトコルを含み、その例はイーサネット、ＩＰ、ＴＣＰ、ＵＤＰ、Ｐｒｏｆｉｂｕｓ、デバイスネット及びＩＥＥＥ８０２．１、Ｒｉｃｏｃｈｅｔ、ＧＳＭ、ＣＤＭＡ等のようなワイヤレスプロトコルであるが、しかしながらこれに限定されるものではない。これらのプロトコルはネットワークインタフェースがメッセージをネットワークから受信することを可能にする。付加的に本発明は、データ消費者のネットワークインタフェース及びデータ作成者の（例えばデータソースの）ネットワークインタフェースの拡張部を提供する。例えば各ノードのネットワークインタフェースは、典型的なネットワークプロトコルインタフェースに加えソフトウェアを含み、このソフトウェアは本発明の機能性を提供する。これに関しては以下詳細に説明する。実施例においては、この付加的なソフトウェアは有利には、ノード（例えばデータ消費者ノード、データ作成者ノード、またはデータ作成者／消費者ノード）のネットワークインタフェースに組み込まれている（ＲＯＭのようなメモリに記憶されている）か、ノード（例えばデータ消費者ノードまたはデータ作成者／消費者ノード）に常駐するアプリケーションに組み込まれている。
【００２７】
本発明は、伝統的データベーススキーマの観点からデータソースのネットワークの記述を提供する。このデータベーススキーマでもってネットワーク上のノードは、ネットワーク上のデータソース（例えばデータ作成者２０またはデータ作成者／消費者３０）を「データベース」とみなす。伝統的に、関係型データベースではスキーマはテーブルと解され、各テーブルは複数のコラム（各コラムは関係の属性に対応する）及び複数のロウ（各ロウは組と呼ばれる関係グループに対応する）を有する。オブジェクト指向データベースでは、スキーマは伝統的にオブジェクトクラスのセットと解され、これは汎用的なものから固有のものまでの階層から形成することができる。スキーマを有する関係フィロソフィまたはオブジェクト指向フィロソフィを本発明の枠組みにおいて理解することができる。
【００２８】
データソースのネットワークを関係型データベースとみなすために、テーブルがスキーマに各データソースタイプに対して作成されている。このテーブルの属性は以下のものを含む。すなわち、（１）データソースを提供できる各アウトプットタイプ。（２）データソース（例えば接続されているコンポーネントのＩＤ、所属するサブシステムのＩＤ等）に関する記述情報の属性。及び（３）ＩＤ。この最後のＩＤは、テーブルにリストされている各データソースに対するテーブル内部においてユニークなものである。複数のデータソースタイプが類似しているが僅かに異なるものであれば、これらのデータソースタイプを、タイプ間を区別する別個の属性とマージして単一のテーブルにすることができる。
【００２９】
データソースのネットワークをオブジェクト指向データベースとみなすために、オブジェクトクラスは各データソースタイプに対して規定されている。当業者は以下のことを理解するであろう。すなわち、複数のデータソースタイプが類似しているが僅かに異なるものであれば、これらのデータソースタイプを共通の、より汎用的なクラスのサブクラスと表すことができる。方法はデータソースのデータを検索できる各クラス内に含まれている。例えば１つの方法はデータソースの各出力タイプのためのものである。付加的な方法がデータソース（例えば接続されているコンポーネントのＩＤ、所属しているサブシステムのＩＤ等）に関する記述情報を検索するために含まれている。付加的な方法を、リセット、較正、ダイナミック区間の設定等のようなデータソースの別個の機能にアクセスするために含ませることができる。
【００３０】
上述したように、本発明はスキーマを有するデータソースのネットワークを、関係フィロソフィまたはオブジェクト指向フィロソフィに基づき考察することができる。本発明をより良く理解するために、以下の記述では、関係型データベースフィロソフィに基づき本発明を説明する。オブジェクト指向フィロソフィに基づく本発明の別の実施例もまた本発明の枠内であると解される。さらにデータベースは関係フィロソフィ及びオブジェクト指向フィロソフィの組み合わせを使用するスキーマを有し、このタイプのデータベースもまた本発明の枠内である。
【００３１】
本発明の見地は、データベーススキーマを各ノードにおいて明示的に記憶する必要がないということである。各照会ノードは、テーブル及び要求するデータの属性名だけを識別すれば良く、また全体のスキーマを識別しなくても良い。データベースのスキーマは、システムの動作に基づき暗黙的なものである。これに関しては以下さらに説明する。
【００３２】
スキーマがいったん構成されれば、本発明は通常図２のように動作する。これらの各ステップを以下詳細に説明する。ネットワークの消費者ノード２５または３０は、伝統的データベース照会をステップ１００において発行することができる。実施例によれば、照会は「リフレッシュレート」を特定することができ、このリフレッシュレートは、所定のレートでの瞬時のネットワーク状態に反して、照会が持続すべきでありまた継続的に評価されるということを示す。ステップ１０２では、この照会が照会ノードのネットワークインタフェースによって、各データソースタイプにとって関連する部分、すなわちネットワークメッセージに分解される。各ネットワークメッセージはネットワークを介して、適切なタイプのデータソースにだけルーティングシステムによってルーティングされる（ステップ１０４）。いくつかのケースにおいては、ネットワークルータ１５はまた、データソースタイプに加え、制約条件にも基づいてネットワークメッセージを照会からルーティングすることができる。ステップ１０６では、ネットワークメッセージが適切なデータソースの各ネットワークインタフェースによって受信される。データソースの各ネットワークインタフェースは、照会の制約条件を定期的に照会のリフレッシュレートに従い検査する（帰還線１０７によって示唆されている）。制約条件が満足されていれば、データソースのネットワークインタフェースは照会に応答し（ステップ１０８）、その応答は照会ノードへと戻しルーティングされる。ステップ１１０では、照会ノードのネットワークインタフェースが応答を収集し、継続的にこの応答を照会の満足のために検査する。照会が満足されるたびに、ネットワークインタフェースは関連するデータを照会プログラムまたはユーザに伝える（ステップ１１２）。
【００３３】
照会ノードでの照会のネットワークメッセージへの変換
上述したように、本発明は伝統的データベース照会をネットワークメッセージに変換するためのシステムを提供する。このシステムはデータソースのネットワークに適しており、このネットワークでは各データソースがデータベースレコード（関係モデル）またはオブジェクト例（オブジェクト指向モデル）またはそれらのいくつかの組み合わせと見なされており、またこのネットワークでは上述のスキーマが使用されている。このシステムは、データソースを送信できるように、各データソースのために照会の関連する部分を抽出する。例えば、各データ消費者ノード２５または３０は、そのネットワークインタフェースまたはそのデータ消費者ノード常駐するアプリケーションプログラムに必要なソフトウェア／ファームウェアを含み、このソフトウェア／ファームウェアは伝統的データベース照会をネットワークメッセージに変換する。このネットワークメッセージは適切なデータ作成者ノード２０または３０へと送信すべき照会の関連する部分を含んでいる。このネットワークメッセージソフトウェアは照会の関連する部分を抽出する機能と、ネットワークを介して伝送される典型的なネットワークプロトコルパケットのデータペイロート内に（例えばイーサネットパケットペイロート内など）カプセル化されたメッセージにこの部分を含ませる機能とを含む。
【００３４】
さらに本発明は、実施例に従い、伝統的データベース照会を任意の付加的な仕様で拡大する。照会は「リフレッシュレート」を特定することができ、このリフレッシュレートは照会が連続的なものであるべきであり、所定のレートに更新されるべきものであることを示す。リフレッシュレートが所定であっても、照会は照会制約条件が満足されている場合にのみ応答することを言及しておく。これについては詳細に後述する。
【００３５】
実施形態によれば、各データソースにとっての照会の関連する部分は以下のものである。すなわち（１）：場合によっては空である、制約条件のリスト。このリストに基づきデータソースは情報を送信することを決定する。（２）：リターン値のリスト。このリストは制約条件が満足されている場合にはデータソースをリターンする。（３）：任意的に、リフレッシュレート。このレートでデータソースは情報の送信を再考する。（４）：ユニークなメッセージＩＤ。（５）：照会ノードのアドレス。照会ノードのアドレスは、照会ノードが基本的なネットワークサービスの部分として自動的に提供される場合には排除することができる。これらの部分はネットワークメッセージを、照会と関係している各データソースのために形成する。ネットワークメッセージの正確な構造（例えば上述の照会の関連する部分を含む領域のオーダ及び／又はサイズ）は、たとえそれがシステムで予め決定されていたとしても本発明には重要ではない。ネットワークメッセージは、ネットワークプロトコルパケットを使用して送信することができるか、ネットワークメッセージを複数のセグメントに分解することができ、このセグメントは複数のネットワークプロトコルパケットを使用して送信される。
【００３６】
図３は、ＳＱＬが照会を上述のようなネットワークメッセージに分解するシステムを実施例に従い示したものである。本発明は照会言語としてのＳＱＬに限定されるものではない。ＳＱＬは事実上、関係データベースに対する標準的な照会言語であり、またオブジェクト指向データベースにもますます使用されるようになっている。現時点での主要なデータベース照会言語として、ＳＱＬは本発明の分解技術の適切な例として使用される。さらに上述のように、またここで強調するが、本発明の実施例に従い伝統的データベース照会をネットワークメッセージに分解する記述は、関係データベースのアプローチのコンテキストにおいて述べているが、それに限定されるべきではない。制約条件述語の仕様は大部分の照会言語の有効部分であり、関連する参照テーブル（またはオブジェクト指向のケースでは参照クラス）に基づいた述語の抽出を、本発明に従いこれらの他の照会言語のために行うことができる。さらに他の大部分の照会言語は、ＯＲ表現または副照会を許容し、これらは同様に、以下のＳＱＬに対する記述と同様に処理される。
【００３７】
図３に示したように、本発明の実施例に従って、伝統的データベース照会をノネットワークメッセージに変換するシステムは、必要メッセージを作成することによって始まる。このネットワークメッセージは照会ノードによってネットワークを介して送信される。
【００３８】
ステップ１５０では、１つのメッセージが各テーブルに対して作成される。このテーブルはＯＲ表現の各オペランド内において、すなわち照会または副照会表現のＷＨＥＲＥ節において参照されている。ＯＲ表現のオペランド内では、テーブルのコラムを参照する各述語がメッセージに制約条件として含まれている（ステップ１５２）。次に、ＯＲ表現外で参照されている各テーブルに対してメッセージが作成されるが、このテーブルは副照会表現のＷＨＥＲＥ節の内部にある（ステップ１５４）。まだ別のメッセージには含まれていないが、副照会のＷＨＥＲＥ節内にあるテーブルの複数のコラムに対する全ての参照は、新しいメッセージに制約条件として含まれている（ステップ１５６）。次に、ＯＲ表現及び副照会外のＷＨＥＲＥ節で参照されている各テーブルに対してメッセージが作成される（ステップ１５８）。まだ他のメッセージには含まれていない、このテーブルのコラムを参照する全ての述語は、制約条件としてメッセージに含まれている（ステップ１６０）。
【００３９】
ステップ１６２では、各メッセージにおける各制約条件に対して、この制約条件は１つのデータソースに対する「局地型」、または複数のデータソースを介する「分散型」として規定している。このことは、制約条件において参照されているテーブルの数をカウントすることにより達成される。その数が１である場合には制約条件は「局地型」である。２またはそれ以上である場合には制約条件は「分散型」である。
【００４０】
ステップ１６４では、各メッセージに対してシステムは、メッセージが作成されるテーブルを参照するＳＥＬＥＣＴ表現内の全てのコラムを収集し、このリストにこのテーブルを参照する各コラムを追加し、メッセージの「分散型」制約条件に含まれている。このリストは、メッセージに対する「リターン値」としてメッセージに追加されている。「分散型」制約条件はメッセージの制約条件リストから除去される。
【００４１】
次に各メッセージに対して、リフレッシュレートが照会において特定されていた場合には、リフレッシュレートはメッセージに含まれている（ステップ１６６）。システムはメッセージへのユニークなメッセージＩＤ及び局地型照会ノードのネットワークアドレスを有する（ステップ１６８）。システムは各メッセージを、ネットワークを介して送信する（ステップ１７０）。
【００４２】
したがって、コンテナに基づくＳＥＬＥＣＴ位置の形式である簡単な例示的照会（例えば工場オートメーション環境。ここでは確実な要求が適合しているこれらのコンテナの位置が選択されるよう要求されている）、述語１が「温度＞１００℃」とするＷＨＥＲＥ（述語１）は、述語１を有するネットワークメッセージに変換されて、ユニークなメッセージＩＤ及び照会ノードのネットワークアドレスとともに送信される。
【００４３】
述語２が「圧力＞１００ｐｓｉ」とするＷＨＥＲＥ（述語１及び述語２）の形式の別の例示的照会は、述語１を有するネットワークメッセージ及び述語２を有する他のネットワークメッセージに変換されて、同一のメッセージＩＤ及び照会ノードのネットワークアドレスを有している２つのネットワークメッセージととともに送信される。
【００４４】
述語３が「体積＜２５０立方センチメートル」とするＷＨＥＲＥ（述語１又は述語３）の形式のさらに別の例示的照会は、述語１を有するネットワークメッセージ及び述語３を有する他のネットワークメッセージに変換されて、同一のメッセージＩＤ及び照会ノードのネットワークアドレスを有している２つのネットワークメッセージとともに送信される。
【００４５】
ネットワークメッセージのネットワークを介したルーティング
いったん照会がデータソース関連ネットワークメッセージのコレクションに変換されると、これらのメッセージをデータソースに満足のために送信しなければならない。このことを、データソースアドレスの中央データベースを必要とせずに達成するため、ネットワークルータはどのようにメッセージをメッセージ中に参照されるデータソースタイプに基づいてルーティングするかを理解する必要がある。タイプ指向のメッセージルーティング方法が必要であり、これによりネットワークメッセージは、特定の照会メードに関連するデータソースタイプにだけルーティングされる。
【００４６】
本発明の実施例のタイプ指向メッセージルーティングを実現するのに有利な技術はキャラクタリスティックルーティングであり、これはタイトル「ＣｈａｒａｃｔｅｒｉｓｔｉｃＲｏｕｔｉｎｇ」の同一出願人による米特特許願に詳細に記載されている。キャラクタリスティックルーティングはルーティングプロトコルであり、これによりデータをネットワークにより送信機ノードからノードセットへ、「特性」の任意の混合を使用して多重反射伝送することができる（特性は記述名を特定する多重任意の形態でのノード記述である）。ノードは多重ダイナミック特性を有することができる。キャラクタリスティックルーティングはルーティングを行うために多重特性を使用して高速かつ効率的に最適化されている。これはルーティングテーブルインデクスを、ビットベクトルと圧縮技術を使用して形成することにより行われる。キャラクタリスティックルーティングを参照されるネットワークオブジェクト（例えばデータソース）に対するインデクスとして使用することで、効率的にインデクシング手段が、データソースデータベースの分散型ネットワークからの高速かつ効率的情報検索のために得られる。とりわけキャラクタリスティックルーティングはデータソースに個別にコンタクトする必要性、または所定のマルチキャストグループを、参照に関連するデータソースを参照するために形成する必要性を排除する。キャラクタリスティックルーティングは各ノードに対する特定の特性を表すビットベクトルを提供する。ここではビットベクトル中の各ビット位置が、ノードに対する全体特性集合の外に特定の特性の存在することを表す。キャラクタリスティックルーティングを使用して送信されたネットワークメッセージは、参照で要求された情報を有するデータソースに向けることができる。
【００４７】
択一的に、しかしより非効率的であるが、インターネットプロトコルマルチキャスト（ＩＰマルチキャスト）をメッセージルーティングのために使用し、各データソースタイプを特定のマルチキャストグループに割り当てることができる。ＩＰマルチキャストルーティングに関連するキャラクタリスティックルーティングの利点は、上記の参照特許願に詳細に記載されている。
【００４８】
ネットワークのルータ１５は、特定のタイプ指向メッセージルーティングを実行するように適切に装備される。このタイプ指向メッセージルーティングは特別の実施例で使用することができる。従ってネットワークメッセージは、照会に関連して定義されたタイプに適合するデータ作成者２０または３０にだけルーティングされる。
【００４９】
ネットワークメッセージへのネットワークインタフェース応答
本発明はまた各データソースのネットワークインタフェースの機能を拡張する。これによりデータソースはネットワークメッセージに適切に応答することができる。これについては以下、図４を参照して説明する。とりわけ各データ作成者ノード２０または３０はそのネットワークインタフェースか、またはそのノードに常駐するアプリケーションプログラム中に必要なソフトウエア／ファームウエアを含む。このソフトウエア／ファームウエアは、受信したネットワークメッセージを処理し、照会制約条件が満たされるとき応答メッセージを適切な照会ノードに逆伝送する。応答メッセージは典型的ネットワークプロトコルパケットのデータペイロード（例えばイーサネットパケットペイロード等）にカプセル化される。これはデータ処理ノード２０または３０によりネットワークを介して伝送される。図４に示されているように、上に示した形態のメッセージがステップ２００でデータソースにより受信され、これが照会に関連して定義されたタイプに適合すれば、データソースのネットワークインタフェースはこのメッセージを未解決照会のリストに追加する（例えばバッファに）。
【００５０】
未解決照会のリストにある各ネットワークメッセージに対してデータソースのネットワークインタフェースはメッセージ中の各制約条件を「スタティック」または「ダイナミック」とステップ２０２で特徴付ける。この特徴付けは、制約条件中のコラム参照のすべてを考慮することにより達成される。コラム参照のすべてが「記述的」属性に対するものであれば、制約条件は「スタティック」と見なされる。それ以外の場合、制約条件は「ダイナミック」と見なされる。ネットワークインタフェースはステップ２０４で、先行して特徴付けられた制約条件がメッセージ中の最後の制約条件であるか否かを検出する。否定の場合は、システムはステップ２０２へリターンし、メッセージ中の次の制約条件を特徴付ける。
【００５１】
いったん、メッセージ中の最後の制約条件が特徴付けられれば、データソースのネットワークインタフェースはステップ２０６で、メッセージ中のすべての制約条件が「スタティック」であるか否かを検出する。メッセージ中のすべての制約条件が「スタティック」であると検出されれば、ネットワークインタフェースはステップ２０８で、データソースの瞬時の読み取りを照会制約条件について一度だけ比較する。ステップ２１０で検出されるように瞬時の読み取りが照会制約条件に適合すれば、ネットワークインタフェースは照会ノードに応答メッセージを戻し発行する。この応答メッセージは、処理されたネットワークメッセージ中に特定されたリターン値の瞬時値、制約条件が「スタティック」であったという指示、そして処理されたネットワークメッセージのユニークなメッセージＩＤを含んでいる。応答メッセージは応答ノードのアドレスを含んでおり、照会ノードにアドレシングされる。この応答メッセージはデータソースのネットワークインタフェースによりネットワークを介してルーティングのために照会ノードに戻し伝送される。
【００５２】
検出がステップ２０６で行われ、すべての制約条件が「スタティック」ではなく、少なくとも１つの「ダイナミック」な制約条件が含まれていれば、システムはステップ２１４でリフレッシュレートがネットワークメッセージで特定されたか否かを検出する。リフレッシュレートが特定されていなければ、ネットワークインタフェースはステップ２０８に進み、データソースの瞬時読み取りを照会制約条件について一度だけ比較する。システムは残りのステップ２１０と２１２を、すでに上に説明したように実行する。
【００５３】
検出がステップ２０６と２１４で実行され、メッセージが少なくとも１つの「ダイナミック」な制約条件を含んでおり、リフレッシュレートがネットワークメッセージ中に特定されていれば、ネットワークインタフェースは瞬時データソースを照会制約条件についてステップ２１６で比較する。制約条件がステップ２１８で適合しないと検出されれば、ネットワークインタフェースは（ライン２２０により示されているように）リフレッシュレートが特定された後のステップ２１６へリターンし、瞬時データを照会制約条件について比較する。制約条件がステップ２１８で適合すると検出されれば、ネットワークインタフェースはステップ２２２で照会ノードに応答メッセージを戻し発行する。この応答メッセージは、処理済みネットワークメッセージ中に特定されたリターン値の瞬時値、および処理済みネットワークメッセージのユニークなメッセージＩＤを含んでいる。応答メッセージは照会ノードにアドレシングされる。この応答メッセージはデータソースのネットワークインタフェースによりネットワークを介してルーティングのために照会ノードに戻し伝送される。ステップ２２４で所定のライフタイムパラメータの値（これはオプションとしてネットワークメッセージ中に特定することができる）を越えることが検出されると、ネットワークインタフェースはメッセージの処理を終了する。しかしこの値をステップ２２４で越えていなければ、ネットワークインタフェースはステップ２１６へリターンし、別の比較を特定されたフレッシュレートで行う。次にシステムは、上にすでに説明したようにステップ２１６から継続する。
【００５４】
応答メッセージ処理および照会ノードでの照会結果生成
図５Ａから図５Ｃは、応答メッセージ収集と、照会ノードでの照会結果生成に対する本発明の機能を示す。このシステムは、照会ノードに常駐するクライアントアプリケーションで実行されるソフトウエア、または照会ノードのネットワークインタフェースのメモリに埋め込まれたアプリケーションとすることができる。このシステムは３つの論理スレッドを有しており、実際に別個のスレッドとして実現するか、または単一モノリシックプロセスとするすることができる。
【００５５】
図５Ａに示すように、第１スレッドは応答メッセージをネットワークから収集する。例えば各応答メッセージはネットワークからステップ３００で受信される。次に各応答メッセージは適切なバッファにステップ３０２で配置される。異なるメッセージＩＤによりインデクスされる別個のバッファが、照会ノードにより送信されたオリジナルネットワークメッセージの各々（それぞれが固有のメッセージＩＤを有する）に対して装備される。応答メッセージに格納されたこのメッセージＩＤに基づき、応答が関連のバッファに追加される。タイムスタンプが応答メッセージに追加され、これが受信された時間を指示する。複数の照会が同じノードから発生することもあることに注意されたい。従ってこのスレッドはこのノードからの異なる参照に関連する応答メッセージを受け入れる。
【００５６】
図５Ｂに示された第２スレッドの目的は、システムのタイミング制約条件を強化することである。このスレッドはリプレイライフタイムと呼ばれるタイミングインターバルを有している。このタイミングインターバルにしたがって各応答メッセージはそのバッファから除去される。リプレイライフタイムの値はケースバイケースに基づき決定すべきであるが、合理的なデフォルト値は関連する照会のリフレッシュレートの３倍とすることができる。このスレッドは連続的にすべてのバッファを通してチェックし、リプレイライフタイム単位よりも大きな時間で以前に受信された応答メッセージを探索する。そのようなメッセージが発見されると、これは「スタティック」としてマークされていない限りバッファから削除される。「スタティック」とマークされている場合にはこれは変化しない。とりわけ各バッファに対して各応答メッセージがステップ３３０で走査される。応答メッセージが「スタティック」とマークされているか否かの決定はステップ３３２で行われる。応答メッセージが「スタティック」でなければ、システムは次の応答メッセージの走査をステップ３３０で継続する。応答メッセージが「スタティック」とマークされていれば、次にメッセージタイムスタンプがリプレイライフタイム値より古いか否かがステップ３３４で決定される。否定であれば、システムはバッファ中の次の応答メッセージの走査をステップ３３０で継続する。しかしタイムスタンプメッセージがリプレイライフタイム値より古ければ、この応答メッセージはそのバッファから除去される。従って「スタティック」とマークされた応答メッセージと、所望の閾値を越える所定時間より古い応答メッセージが削除される。
【００５７】
図５Ｃに示された第３スレッドは、この照会ノードから発行されたすべての照会を連続的に評価する。このスレッドは応答メッセージを各バッファにおいて、照会制約条件の満足をチェックするために使用する。この照会制約条件は１つ以上のデータソースからのデータを含んでいる。データベーステクノロジでは、この述語は「ジョイン」と呼ばれる。例えば述語に含まれる照会が「Ａ．ＰａｒｔＩＤ＝Ｂ．ＰａｒｔＩＤ」であり、ＡとＢはソースタイプであれば、この条件はこのスレッドにより、この制約条件を含む、ネットワークメッセージへの応答メッセージが受信されるたびに評価されることとなる。応答メッセージ集合がバッファに存在しており、これが完全に特別照会を満足させる場合には、照会のＳＥＬＥＣＴ節に相当する値はこの照会を発行したプログラムまたはユーザにリターンされる。リターンされた値が照会結果である。
【００５８】
リフレッシュ照会の終了
特別な実施例によれば、リフレッシュレートが特定された照会は終了まで継続される。いずれのノードも照会を、特別の「照会終了」メッセージを（照会で参照されるデータソースタイプに合致する）各データソースに送信することにより終了する。この終了メッセージは終了すべきネットワークメッセージのメッセージＩＤを含む。データソースのネットワークインタフェースは次にこのネットワークメッセージをその未解決照会リストから除去する。オプションとして前に述べたように、ライフタイムを照会に割り当てることができる。これにより各データソースのネットワークインタフェースは自動的に、そのライフタイムの経過したネットワークメッセージを削除する。
【００５９】
照会が終了した時点で、照会ノードはまたこの照会に関連する応答メッセージ（これは依然とそのバッファ内にある）も消去する。消去すべき応答メッセージはまた「スタティック」とマークされた応答メッセージを含むことになる。
【００６０】
宛先ジョインノード
データベースは相互参照情報に対する能力（すなわち「ジョイン」の実行）を提供する。上記の実施例は基本的に、照会ノードにおいて種々の応答メッセージに送信された戻り情報の処理（ジョイニングも含む）を取り扱う。しかし別の実施例では、戻り情報の処理をプログレッシブジョインによりネットワークを通して戻る情報として実行することができる。またはジョイン実行のタスクは特別のノードの委任することができる。このノードは宛先ジョイナと称され、照会されるデータ生成ノードから照会ノードへのアップストリームパスに沿って存在する。そしてこのノードはデータ処理ノードよりも大きな計算能力またはメモリを有する。宛先ジョインノードは計算を分散的に、戻り情報に基づき応答メッセージでこれらが宛先ジョインノードに到着するときに実行する。ジョインの実行に加えて、宛先ジョインノードは平均化等を実行することができる。プログレッシブジョインまたは宛先ジョイナを使用する実施例により、照会ノードでの応答メッセージ処理は低減または簡素化される。なぜなら処理の多くは、照会ノードに送信された戻り情報が以前に処理されたように行われるからである。宛先ジョイナノードは、このシステムがローコスト、低機能性データソース（例えばデータ処理ノード）とハイコスト、高機能性アクティブ素子（例えばデータ生成／消費ノード、または高処理能力および／またはより多くのメモリを備えるデータ生成ノード）との混合を使用する場合に特に有利である。デバイスのこのような混合は例えば、データソースの既存ネットワークをアップグレードするとき、またはコストのかからないシステムが所望される場合に発生する。
【００６１】
上述したように種々の実施例を説明したが、本発明を既述の実施例に制限する必要はない。記述の実施例を、記載の請求項によってのみ限定される本発明の枠組から逸脱することなく変更または修正することができる。
【図面の簡単な説明】
【図１】
本発明を使用することのできるネットワークアーキテクチャの例を示す。
【図２】
本発明の実施例の一般的機能を説明する図である。
【図３】
データベース照会をネットワークメッセージに、本発明の実施例にしたがって変換するための機能を説明する図である。
【図４】
受信したネットワークメッセージを本発明の実施例にしたがって処理するネットワークインタフェースの機能を説明する図である。
【図５】
本発明の実施例によるネットワークメッセージの収集と、照会結果のインタプリタのための機能を説明する図である。[0001]
Cross-reference of related applications
This application discloses a commonly owned U.S. patent application Ser. No. 60 / 168,425, entitled "A System for Communicating with a Network of Sensors Through a Database Interface," and Ser. Claim priority from the application filed on November 39, 2011. This application is also related to commonly-owned U.S. patent application Ser. No. 09 / 728,380, entitled "Characteristic Routing," filed on the same date, filed by Julio C.S. Navas.
[0002]
Background of the Invention
A trend in the information, communications, and automation industry is distributed solutions. Recent examples of this trend are suggestions for networked sensors, and suggestions that large groups of such data sources can form large-scale distributed information systems (referred to as networks of data sources). In the publication "Next Century Challenges: Mobile Networking for Smart Dust" (published by MiniComm 1999), the author Kahn et al. Discusses an example of a distributed network of data sources in the form of a sensor network.
[0003]
The first idea of a network of data sources is that an individual data source, or perhaps a small group of data sources, could be connected to a computer network, while using a standard communication protocol such as the Internet Protocol (IP). is there. Other devices on the network can access the data provided by the data source, which can be individual or in units depending on the application. The most ambitious proposal is that the data source's wireless network dynamically defines their topology as they are located, and then redefines their links and routing schemes to add new nodes and faults. It describes nodes and tries to optimize power management. The rudimentary forms of networks of data sources are already used in some industrial process control systems, and future applications for networks of data sources are expected to expand in many areas.
[0004]
The current problem in view of a network of data sources is how to manage data from the data sources. This can be contrasted with current technology in the information technology (IT) world. In information technology, data management technology is abundant. In the IT world, data aggregation, type-oriented data access, query optimization, transaction management, data filtering, data minimization, and many other techniques are well-established techniques. Thus, for data residing in memory, disks, or well-established distributed databases, data management is a well understood technique. However, a network of data sources is difficult for data management. This is because the data transmitted by the potential majority of data sources can overwhelm the network or data management system used. In addition, the data sources of the network continue to provide information that is continuously changed or updated frequently.
[0005]
The prototype network of data sources uses protocols from the computer network world. It is based on TCP and UDP, and was developed for communications rather than data management. Industrial systems use a different, but similar protocol. This is, for example, a mode bus. These protocols provide a mechanism to transfer messages point-to-point or to broadcast messages to all members of the network. However, these protocols are often inadequate and have limitations in providing efficient data management to networks in the data source world. Therefore, these system types developed for communications are problematic in more complex and vast computer programs, and systems used for data management in networks of data sources are often formed from scratch by programmers and system administrators, More sophisticated data management techniques must be realized. This can be applied in IT technology, but is not valid for a network of data sources.
[0006]
One approach to limited data management is described in US Pat. No. 5,301,339 (by Boassonn) for the field of industrial process control, which provides a system for communication between subsystems. In this subsystem, requests are performed based on data type. In such systems, certain types of data can be requested, but there is no mechanism to constrain the desired value of the requested data. Such a mechanism is critical for implementing traditional database queries, such as requiring all temperature sensors to read temperatures above 100 degrees Fahrenheit. The system written by Boasson lacks a database in terms of data to a data sub-processing system, an associated schema or object schema that describes the data, and a facility for request data in a traditional query language. Thus, Boasson's system only provides the limited data management capabilities that are far below the capabilities of traditional databases.
[0007]
Another approach to data management is a real-time communication system for industrial processes, which is described in US Pat. No. 5,093,782 (Murasaki et al.). Here, the application considers the remote data source as part of the data source. In this type of system, a subsystem accesses a remote data source as a controller and uses it to maintain a database of these remote values. The system is primarily concerned with updating these databases. One disadvantage of this schema is that each controller must manage its own database, which must have a given reference to each data source. For each subsystem requiring access data, the addresses of all relevant data sources must be fixedly encoded. The database may also focus on error points. A further disadvantage of this system is that data must be continuously polled from the data source to maintain the validity of the local database. Continuous polling from these various data sources places a heavy traffic load on the network.
[0008]
Although potentially useful techniques for adding a rich set of data management tools to a network of data sources can be found in the distributed database community, traditional research on distributed databases has been difficult to use with networks of data sources. Inappropriate or incomplete.
[0009]
Some of these distributed database studies are designed to extend the structural content of the database to computer networks and are accessed as a single database. Unfortunately, most of this work has been published in the publication "Principles of Distributed Database Systems" (M. Ozsu, P. Valduriez, Prentice-Hall, Inc., Upper Saddle River, New Jersey, 1992). In particular, it focuses on the problems associated with known database fragmentation (database fragmentation), which optimizes subsequent access to the data. This technique is not particularly useful in data source world networks. Because each data source only provides the data it forms, it is not possible to choose how the data should be fragmented.
[0010]
Another distributed database approach is described in U.S. Pat. No. 4,635,189 (Kendall) and U.S. Pat. No. 5,179,660 (Devany et al.), Which provides a mechanism for splitting traditional database queries between distributed databases. . Data is not carefully fragmented into this distributed database ahead of time. However, this type of system is not suitable for a network of data sources for several reasons. First of all, this approach is related to more traditional distributed databases, where it is assumed that the network location of a particular piece of data is known in advance. Such an assumption does not hold in many dynamic applications of a network of data sources. This is because you can always add a data source here. For example, consider a network of data sources formed by a plurality of vehicles each equipped with a data source and a wireless link. This network is used for traffic monitoring. When a new vehicle with a data source enters the highway and connects to this network, the data it supplies should be included in the query results as desired. However, Kendall & Devany et al. Does not provide a mechanism to dynamically participate in query results for data input from a data source that is added to a network of data sources. Second, Kendall & Devany et al. Assumes that important processing capabilities reside on each network node. This assumption does not hold for many networks of data sources. This is because the data source, the analog / digital converter and the network interface may constitute an entire network node. A similar approach is described by Bonnet et al. (P. Bonnet, J. Geheke, T. Mayr, P. Seshadri, "Query Processing in a Device Database System", Cornell Technical Report TR99-1799, October 1999). They have attempted to specifically address the network of data sources, but this attempt has the same limitations.
[0011]
Accordingly, systems and methods or techniques that provide more efficient and sophisticated query capabilities are desired for effective data management of a network of data sources. It is further desired to provide data management economically through a network of data source systems. This data management should not require that each network node have high processing capabilities or implement complex programming. This is necessary for conventional database search languages to achieve data management techniques. Such a system for a network of data sources should also be able to query large amounts of data and communicate without placing a heavy traffic load on the network.
[0012]
Summary of the Invention
The problems and disadvantages discussed above are solved by the present invention. The present invention allows conventional information technology data management techniques to be applied directly within a network of data sources. More specifically, the present invention allows a program to be executed on a device logically connected to a network. The network also logically connects network data sources, issues traditional database queries over the network, and receives the results of the queries from the network as they are applied to the data formed by the data sources.
[0013]
According to an embodiment of the present invention, the present invention provides a method for managing information of a distributed data source network database including a plurality of nodes. This node includes a query node and multiple data sources. The method includes providing a schema to a distributed data source network, entering a query in a database language into a query node of the network, decomposing the query into at least one network message, and relating the network message to the query. Transmitting only to the data source to be transmitted. The method further includes receiving the network message at a data source associated with the query, sending the response message to the network message when the query matches, and transmitting the query results to the query node in a database language from the response message. Including providing.
[0014]
According to another embodiment, the present invention provides an information management system for a distributed data source network database. The system includes a network, a plurality of data sources connected to the network, and at least one query node connected to the network. This data source can provide information to a distributed data source network database according to a schema. The query node receives the query in a database language and can break the query into at least one network message. The network message is transmitted over the network only to the data source associated with the query. The data source associated with the query sends a response message over the network when the query matches in response to the network message, and the query node provides query results from the response message in a database language.
[0015]
These and other embodiments and features and advantages of the present invention are described in detail below with reference to the drawings.
[0016]
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows an example of a network architecture in which the present invention can be used.
[0017]
FIG. 2 is a diagram illustrating general functions of the embodiment of the present invention.
[0018]
FIG. 3 is a diagram illustrating a function for converting a database query into a network message according to an embodiment of the present invention.
[0019]
FIG. 4 is a diagram illustrating the function of a network interface that processes a received network message according to an embodiment of the present invention.
[0020]
5A to 5C are diagrams illustrating functions for collecting network messages and interpreting query results according to an embodiment of the present invention.
[0021]
Detailed description of the embodiment
According to an embodiment, the present invention includes the following system. That is, the system represents a network of data sources in terms of a traditional database schema, translates traditional database queries into network messages, and routes these messages to those data sources that have associated data. In the present invention, the network interface of the data source accepts the message, filters the output of the data source according to the instructions in the message, and sends a response message to the origin of the query. The system collects this response message at the query origin and formulates the query results as a traditional database.
[0022]
The present invention provides the following systems and methods. That is, they can be managed by a plurality of distributed clients of a network of data sources, such that the network of data sources is a single database. More specifically, the present invention provides that the execution of a program on a network device issues a database query to the network interface of the device, calculates the result of the query for the network infrastructure, and returns the result to the querying device. . Embodiments of the present invention may be useful for information management in different applications. Particular applications are in industrial automation, such as factory equipment control and factory equipment management, which are described below as exemplary objects. However, other embodiments may be useful for logical management. This logical management is such as delivery service packaging, fire and toxin tracking crisis management, highway traffic management, smart building or smart battlefield security management, and many other applications.
[0023]
As described in detail below, the present invention provides the following advantages. That is, a user or programmer can access and process data from network data according to well-known information technology standards such as Structured Query Language (SQL). Multiple users or programmers can access and process data from a data source from anywhere on the network. Network traffic is significantly reduced compared to polling or continuous refresh systems. No central error point for data access. Latency is minimal because data always travels the direct path from the data source to the request node. It is not necessary for the query node to identify the physical location of the response data source.
[0024]
FIG. 1 shows an example of a network architecture in which the present invention can be used. Those skilled in the art will understand this diagram as internetwork 10. That is, the collection of networks is connected by a network router 15, which can be connected to each other. Term routers are used here in the art and may include traditional routers, network switches, gateways, bridges or networks specific to control bridging. Also, while the invention can be used in a single network, its value is higher than in an internetwork. Each network can be connected to any number of nodes. The line 35 connecting the various nodes and routers in this network architecture is a wired connection in this embodiment. Another architecture in which the present invention can be used is a wireless network. This wireless network differs from the network of FIG. 1 above in that there is no direct connection between the nodes in the network, but rather the data is connected to the nearest node by wireless technology, if there is a transmission leg, and In some cases, a slightly restricted line is provided. Therefore, in this embodiment, the line 35 can be regarded as a logical connection to the wireless internetwork. Further, in embodiments where the internetwork includes a combination of wireless and wired networks, lines 35 are logical connections and wired connections, respectively. Those skilled in the art will appreciate that many algorithms for changing transmission intervals and rates exist for more efficient use of bandwidth and power consumption. Furthermore, those skilled in the art will appreciate that there are a variety of algorithms used to connect or reconnect mobile or dynamic nodes, referred to as ad hoc networks. The architecture of such networks has not been determined. The present invention can be applied to any approach.
[0025]
According to the present invention, each node on the network has a network interface, and queries can be formed from data consumer nodes of the network. The network nodes can be data creators 20, data consumers 25, or both (data creators / consumers 30). Examples of data creators 20 include data sources (eg, sensors) or data source banks (often referred to as distributed I / O). Examples of the data consumer 25 include a controller and a monitoring system. An example of a node that is the data creator / consumer 30 is a user operation panel. For the purposes of the present invention, a controller acting as an interface to the network for one or more data sources is considered a single node, which is another example of a data creator / consumer 30. is there. The nodes of the network can be provided with the functions of a data consumer node, a data creator node or a data creator / consumer node by incorporating appropriate software into the node according to the invention. However, not all nodes of the network need to have software in order for the present invention to operate according to the present invention.
[0026]
As described above, each node (including each data source) on the network has a network interface, which is suitable for the type of network protocol used on the network to which the node is logically connected. I have. This network interface includes related traditional network interface protocols, examples of which are Ethernet, IP, TCP, UDP, Profibus, DeviceNet and wireless protocols such as IEEE 802.1, Ricochet, GSM, CDMA, etc. However, it is not limited to this. These protocols allow the network interface to receive messages from the network. Additionally, the present invention provides an extension of the data consumer's network interface and the data creator's (e.g., data source) network interface. For example, the network interface of each node includes software in addition to a typical network protocol interface, which software provides the functionality of the present invention. This will be described in detail below. In embodiments, this additional software is advantageously integrated into the network interface of the node (eg, data consumer node, data creator node, or data creator / consumer node) (such as a ROM). (Stored in memory) or embedded in an application that resides on a node (eg, a data consumer node or data creator / consumer node).
[0027]
The present invention provides a description of a network of data sources in terms of a traditional database schema. With this database schema, nodes on the network consider a data source on the network (eg, data creator 20 or data creator / consumer 30) a “database”. Traditionally, in relational databases, a schema is interpreted as a table, where each table contains multiple columns (each column corresponding to a relational attribute) and multiple rows (each row corresponding to a relational group called a set). Have. In an object-oriented database, a schema is traditionally interpreted as a set of object classes, which can be formed from a hierarchy from generic to specific. Relational or object-oriented philosophy with a schema can be understood in the framework of the present invention.
[0028]
In order to consider the network of data sources as a relational database, tables have been created in the schema for each data source type. The attributes of this table include: That is, (1) each output type that can provide a data source. (2) Attributes of descriptive information about data sources (for example, IDs of connected components, IDs of subsystems to which they belong, etc.) And (3) ID. This last ID is unique within the table for each data source listed in the table. If the data source types are similar but slightly different, they can be merged into a single table with separate attributes that distinguish between the types.
[0029]
In order to view the network of data sources as an object-oriented database, object classes are defined for each data source type. Those skilled in the art will understand the following. That is, if a plurality of data source types are similar but slightly different, then these data source types can be represented as subclasses of a common, more general class. Methods are included in each class that can retrieve data from the data source. For example, one method is for each output type of data source. Additional methods are included for retrieving descriptive information about the data source (e.g., ID of connected component, ID of subsystem to which it belongs, etc.). Additional methods can be included to access separate functions of the data source, such as reset, calibration, setting dynamic intervals, and the like.
[0030]
As described above, the present invention can consider a network of data sources having a schema based on relational or object-oriented philosophy. For a better understanding of the invention, the following description describes the invention based on a relational database philosophy. Other embodiments of the invention based on object-oriented philosophy are also understood to be within the scope of the invention. Further, the database has a schema that uses a combination of relational philosophy and object-oriented philosophy, and this type of database is also within the scope of the present invention.
[0031]
An aspect of the present invention is that the database schema does not need to be explicitly stored at each node. Each query node need only identify the table and the attribute names of the requested data, and need not identify the entire schema. The schema of the database is implicit based on the operation of the system. This is described further below.
[0032]
Once the schema is constructed, the present invention typically operates as in FIG. Each of these steps will be described in detail below. The consumer node 25 or 30 of the network may issue a traditional database query at step 100. According to an embodiment, the query can specify a "refresh rate", which, contrary to the instantaneous network conditions at a given rate, should the query be sustained and evaluated continuously. It indicates that In step 102, the query is broken down by the querying node's network interface into portions relevant to each data source type, ie, network messages. Each network message is routed through the network by the routing system only to the appropriate type of data source (step 104). In some cases, network router 15 may also route network messages from queries based on constraints, in addition to data source types. At step 106, a network message is received by each network interface of the appropriate data source. Each network interface of the data source periodically checks the query constraints according to the query refresh rate (indicated by feedback line 107). If the constraints are satisfied, the data source's network interface responds to the query (step 108) and the response is routed back to the query node. In step 110, the query node's network interface collects the response and continually examines the response for query satisfaction. Each time the query is satisfied, the network interface communicates relevant data to the query program or user (step 112).
[0033]
Converting Queries in Inquiry Nodes to Network Messages
As described above, the present invention provides a system for translating traditional database queries into network messages. The system is suitable for a network of data sources, where each data source is viewed as a database record (relational model) or an example object (object-oriented model) or some combination thereof, and The schema described above is used. The system extracts the relevant portion of the query for each data source so that the data sources can be sent. For example, each data consumer node 25 or 30 includes the software / firmware required for its network interface or application programs resident on that data consumer node, which translates traditional database queries into network messages. This network message contains the relevant portion of the query to be sent to the appropriate data creator node 20 or 30. The network message software has the ability to extract the relevant part of the query and the message encapsulated in a data payload (eg, in an Ethernet packet payload) of a typical network protocol packet transmitted over the network. And a function to include this part.
[0034]
Further, the present invention extends traditional database queries with any additional specifications, according to embodiments. The query can specify a "refresh rate", which indicates that the query should be continuous and should be updated to a predetermined rate. It should be noted that, even if the refresh rate is predetermined, the query will only respond if the query constraint is satisfied. This will be described later in detail.
[0035]
According to an embodiment, the relevant parts of the query for each data source are: That is, (1): a list of constraints, possibly empty. Based on this list, the data source decides to send the information. (2): List of return values. This list returns the data source if the constraints are satisfied. (3): Optionally, a refresh rate. At this rate, the data source will reconsider sending information. (4): unique message ID. (5): Inquiry node address. The address of the querying node can be eliminated if the querying node is automatically provided as part of the basic network service. These parts form a network message for each data source involved in the query. The exact structure of the network message (eg, the order and / or size of the area containing the relevant portion of the query described above) is not important to the present invention, even if it is predetermined in the system. The network message can be sent using network protocol packets or the network message can be broken down into multiple segments, which are sent using multiple network protocol packets.
[0036]
FIG. 3 illustrates, according to an embodiment, a system in which SQL decomposes queries into network messages as described above. The present invention is not limited to SQL as a query language. SQL is, in effect, the standard query language for relational databases, and is increasingly being used for object-oriented databases. As the current primary database query language, SQL is used as a suitable example of the decomposition technique of the present invention. Further, as noted above and emphasized herein, the description of breaking traditional database queries into network messages in accordance with embodiments of the present invention is described in the context of a relational database approach, but should not be limited thereto. Absent. Constraint predicate specifications are a useful part of most query languages, and the extraction of predicates based on the associated lookup tables (or reference classes in the object-oriented case) is performed in accordance with the present invention for these other query languages. Can be done. Yet most other query languages allow OR expressions or subqueries, which are similarly processed as described below for SQL.
[0037]
As shown in FIG. 3, in accordance with an embodiment of the present invention, a system for converting a traditional database query into a network message begins by creating a required message. This network message is sent over the network by the querying node.
[0038]
In step 150, one message is created for each table. This table is referenced within each operand of the OR expression, ie, in the WHERE clause of the query or subquery expression. In the operand of the OR expression, each predicate referring to the column of the table is included in the message as a constraint (step 152). Next, a message is created for each table referenced outside the OR expression, which is inside the WHERE clause of the subquery expression (step 154). All references to the columns of the table that are not yet included in another message but are in the WHERE clause of the subquery are included as constraints in the new message (step 156). Next, a message is created for each table referenced in the OR expression and the WHERE clause outside the subquery (step 158). All predicates that refer to columns of this table that are not yet included in other messages are included in the message as constraints (step 160).
[0039]
In step 162, for each constraint in each message, this constraint is defined as "local" for one data source or "distributed" via multiple data sources. This is achieved by counting the number of tables referenced in the constraint. When the number is 1, the constraint condition is “local type”. If it is two or more, the constraint is "distributed".
[0040]
In step 164, for each message, the system collects all columns in the SELECT expression that refer to the table in which the message is created, adds each column referencing this table to this list, and returns Type "constraints. This list has been added to the message as a "return value" for the message. "Distributed" constraints are removed from the message's constraint list.
[0041]
Then, for each message, if the refresh rate was specified in the query, the refresh rate is included in the message (step 166). The system has a unique message ID to the message and the network address of the local query node (step 168). The system sends each message over the network (step 170).
[0042]
Thus, a simple exemplary query in the form of a SELECT location based on a container (eg a factory automation environment, where the exact location is required to select those container locations that meet the requirements), predicate 1 Is converted to a network message having predicate 1 and sent with a unique message ID and the network address of the querying node.
[0043]
Another exemplary query in the form of a WHERE (Predicate 1 and Predicate 2) where Predicate 2 is “pressure> 100 psi” is translated into a network message with Predicate 1 and another network message with Predicate 2 and the same Sent with the two network messages having the message ID and the network address of the querying node.
[0044]
Yet another exemplary query in the form of a WHERE (predicate 1 or predicate 3) where predicate 3 is “volume <250 cubic centimeters” is translated into a network message with predicate 1 and another network message with predicate 3 Sent with two network messages having the same message ID and the network address of the querying node.
[0045]
Routing network messages through the network
Once the queries have been converted into a collection of data source related network messages, these messages must be sent to the data source for satisfaction. To accomplish this without the need for a central database of data source addresses, network routers need to understand how to route messages based on the data source type referenced in the message. There is a need for a type-oriented message routing method whereby network messages are only routed to the data source type associated with a particular query.
[0046]
An advantageous technique for implementing the type-oriented message routing of an embodiment of the present invention is characteristic routing, which is described in detail in a commonly-owned US patent application entitled "Characteristic Routing". Characteristic routing is a routing protocol that allows data to be multiple-reflected transmitted over a network from a transmitter node to a set of nodes using any mix of "characteristics" (characteristics specify a descriptive name). Node description in multiple arbitrary forms). Nodes can have multiple dynamic characteristics. Characteristic routing is optimized quickly and efficiently using multiple properties to perform the routing. This is done by forming the routing table index using bit vectors and compression techniques. By using characteristic routing as an index for referenced network objects (eg, data sources), an efficient indexing means is obtained for fast and efficient information retrieval from a distributed network of data source databases. . In particular, characteristic routing eliminates the need to contact the data sources individually or to create a given multicast group to refer to the data source associated with the reference. Characteristic routing provides a bit vector that represents certain characteristics for each node. Here, each bit position in the bit vector indicates that a particular property exists outside the overall property set for the node. Network messages sent using characteristic routing can be directed to a data source with the information requested by reference.
[0047]
Alternatively, but less efficiently, Internet Protocol Multicast (IP Multicast) can be used for message routing and each data source type can be assigned to a specific multicast group. The advantages of characteristic routing in connection with IP multicast routing are described in detail in the above referenced patent application.
[0048]
The routers 15 of the network are suitably equipped to perform certain type-oriented message routing. This type-oriented message routing can be used in special embodiments. Thus, network messages are routed only to data creators 20 or 30 that conform to the type defined in connection with the query.
[0049]
Network interface response to network messages
The present invention also extends the functionality of each data source's network interface. This allows the data source to respond appropriately to network messages. This will be described below with reference to FIG. In particular, each data creator node 20 or 30 includes the necessary software / firmware in its network interface or application program resident on that node. The software / firmware processes the received network message and transmits the response message back to the appropriate query node when the query constraint is satisfied. The response message is encapsulated in the data payload of a typical network protocol packet (eg, an Ethernet packet payload, etc.). This is transmitted over the network by the data processing node 20 or 30. As shown in FIG. 4, if a message of the form shown above is received by the data source at step 200, and if it conforms to the type defined in connection with the query, the data source's network interface will To the list of outstanding queries (eg, in a buffer).
[0050]
For each network message in the list of outstanding queries, the network interface of the data source characterizes each constraint in the message as "static" or "dynamic" at step 202. This characterization is achieved by considering all of the column references in the constraints. If all of the column references are to the "descriptive" attribute, the constraint is considered "static". Otherwise, the constraint is considered "dynamic." The network interface detects at step 204 whether the previously characterized constraint is the last constraint in the message. If not, the system returns to step 202 and characterizes the next constraint in the message.
[0051]
Once the last constraint in the message has been characterized, the data source's network interface detects at step 206 whether all constraints in the message are "static." If all constraints in the message are detected as "static", the network interface compares the instantaneous read of the data source once for query constraints at step 208. If the instantaneous read meets the query constraint, as detected in step 210, the network interface returns a response message to the querying node. The response message includes the instantaneous value of the return value specified in the processed network message, an indication that the constraint was "static", and the unique message ID of the processed network message. The response message contains the address of the responding node and is addressed to the querying node. This response message is transmitted back to the inquiring node for routing over the network by the network interface of the data source.
[0052]
If detection is performed in step 206 and all constraints are not "static" and include at least one "dynamic" constraint, the system determines in step 214 whether the refresh rate was specified in the network message. Detect. If the refresh rate has not been specified, the network interface proceeds to step 208 and compares the instantaneous read of the data source only once for query constraints. The system performs the remaining steps 210 and 212 as already described above.
[0053]
If the detection is performed in steps 206 and 214 and the message contains at least one "dynamic" constraint and the refresh rate is specified in the network message, the network interface will query the instantaneous data source for the query constraint. In step 216, the comparison is made. If the constraint is found to be incompatible at step 218, the network interface returns to step 216 after the refresh rate has been determined (as indicated by line 220) and compares the instantaneous data for the query constraint. I do. If the constraint is found to match in step 218, the network interface returns a response message to the querying node in step 222. This response message includes the instantaneous value of the return value specified in the processed network message and the unique message ID of the processed network message. The response message is addressed to a query node. This response message is transmitted back to the inquiring node for routing over the network by the network interface of the data source. If it is detected in step 224 that the value of the predetermined lifetime parameter is exceeded (which can optionally be specified in the network message), the network interface terminates processing of the message. However, if this value is not exceeded in step 224, the network interface returns to step 216 and performs another comparison at the specified fresh rate. The system then continues from step 216 as described above.
[0054]
Response message processing and query result generation in query nodes
5A-5C illustrate the functionality of the present invention for response message collection and query result generation at a query node. The system may be software running on a client application resident on the query node, or an application embedded in the memory of the query node's network interface. This system has three logical threads, which can actually be implemented as separate threads or be a single monolithic process.
[0055]
As shown in FIG. 5A, the first thread collects response messages from the network. For example, each response message is received at step 300 from the network. Each response message is then placed in the appropriate buffer at step 302. A separate buffer, indexed by a different message ID, is provided for each of the original network messages sent by the querying node, each with a unique message ID. Based on this message ID stored in the response message, a response is added to the associated buffer. A time stamp is added to the response message, indicating the time at which it was received. Note that multiple queries may originate from the same node. Thus, the thread will accept response messages related to different references from this node.
[0056]
The purpose of the second thread shown in FIG. 5B is to enforce the timing constraints of the system. This thread has a timing interval called a replay lifetime. According to this timing interval, each response message is removed from its buffer. The value of the replay lifetime should be determined on a case-by-case basis, but a reasonable default value can be three times the refresh rate of the associated query. This thread continuously checks through all buffers and looks for previously received response messages in a time greater than the replay lifetime unit. When such a message is found, it is removed from the buffer unless it is marked as "static". This does not change if it is marked "static". In particular, each response message is scanned at step 330 for each buffer. A determination is made at step 332 as to whether the response message is marked "static." If the response message is not "static," the system continues scanning at step 330 for the next response message. If the response message is marked "static", then it is determined at step 334 whether the message time stamp is older than the replay lifetime value. If not, the system continues scanning at step 330 for the next response message in the buffer. However, if the timestamp message is older than the replay lifetime value, the response message is removed from the buffer. Accordingly, response messages marked "static" and response messages older than a predetermined time exceeding a desired threshold are deleted.
[0057]
The third thread shown in FIG. 5C continuously evaluates all queries issued from this query node. This thread uses the response message in each buffer to check for the satisfaction of query constraints. The query constraint includes data from one or more data sources. In database technology, this predicate is called a "join." For example, if the query contained in the predicate is “A.PartID = B.PartID”, and A and B are source types, the condition is that this thread will receive a response message to the network message containing this constraint, Will be evaluated each time it is done. If a response message set exists in the buffer and completely satisfies the special query, the value corresponding to the SELECT clause of the query is returned to the program or user that issued the query. The returned value is the query result.
[0058]
End of refresh query
According to a particular embodiment, the query for which the refresh rate has been specified continues until termination. Both nodes end the query by sending a special "Query End" message to each data source (which matches the data source type referenced in the query). This end message includes the message ID of the network message to be ended. The data source's network interface then removes this network message from its open query list. Optionally, a lifetime can be assigned to the query, as described above. This causes the network interface of each data source to automatically delete the network message whose lifetime has expired.
[0059]
At the end of the query, the query node also deletes the response message associated with the query, which is still in its buffer. The response message to be deleted will also include the response message marked "static".
[0060]
Destination join node
The database provides the capability for cross-reference information (ie, performing a "join"). The above embodiment basically deals with the processing (including joining) of the return information sent to the various response messages at the query node. However, in another embodiment, the processing of the return information can be performed as a return information over a network by a progressive join. Or the task of performing the join can be delegated to a special node. This node is called the destination joiner and exists along the upstream path from the queried data generation node to the queried node. This node has more computing power or memory than the data processing node. The destination join node performs the computations in a distributed manner, based on the return information, in response messages as they arrive at the destination join node. In addition to performing the join, the destination join node can perform averaging and the like. Embodiments that use progressive or destination joiners reduce or simplify response message processing at the query node. This is because much of the processing is done as if the return information sent to the querying node had been processed previously. The destination joiner node may use a low cost, low functionality data source (eg, a data processing node) and a high cost, high functionality active device (eg, a data generation / consumption node, or high processing power and / or more memory). It is particularly advantageous when using a mixture with a data generation node (comprising). Such a mix of devices occurs, for example, when upgrading an existing network of data sources, or when an inexpensive system is desired.
[0061]
Although various embodiments have been described above, it is not necessary to limit the present invention to the above-described embodiments. The described embodiments may be changed or modified without departing from the framework of the present invention, which is limited only by the claims set forth.
[Brief description of the drawings]
FIG.
1 shows an example of a network architecture in which the present invention can be used.
FIG. 2
FIG. 3 is a diagram illustrating general functions of an embodiment of the present invention.
FIG. 3
FIG. 4 illustrates a function for converting a database query into a network message according to an embodiment of the present invention.
FIG. 4
FIG. 3 is a diagram illustrating a function of a network interface that processes a received network message according to an embodiment of the present invention.
FIG. 5
FIG. 3 is a diagram illustrating functions for collecting network messages and interpreting query results according to an embodiment of the present invention.

Claims

An information management method for a distributed data source network database, the network database including a plurality of nodes,
The plurality of nodes includes a query node and a plurality of data sources,
Providing a schema to the distributed data source network database;
Entering a query into the query node of the network in a database language;
Breaking the query into at least one network message;
Transmitting the network message to a data source associated with the query;
Receiving the network message at a data source associated with the query;
Sending a response message to the network message when a query matches;
Providing query results in the database language to the query node from the response message.
A method comprising:

The disassembling step further comprises:
Collecting at least one constraint and at least one return value from the query;
Forming a network message having the constraint and the return value in the query;
Adding a message ID and a network address of the querying node to the constraints and the return value from the network message.

The network message is an Ethernet packet, an IP packet, a TCP packet, a UDP packet, a Profibus packet, a device net packet, an IEEE 802.11 packet, a Ricochet packet, a GSM format packet, or a CDMA format packet, or a plurality of the packets. Item 7. The method according to Item 1.

The method of claim 1, wherein the schema comprises an association schema, an object-oriented schema, or an object association schema.

5. The method of claim 4, wherein said query language comprises SQL.

The method of claim 1, wherein the transmitting step routes the network message to a data source associated with the query using characteristic routing.

The method of claim 1, wherein the transmitting step routes the network message only to a data source associated with the query using multicast routing.

The decomposing step collects all predicates from the query, the predicates refer to columns of a table, and form network messages for all of the predicates, where each network message has at least one predicate. The method of claim 1, further comprising: in the query, adding a message ID and a network address of the querying node to the network message.

9. The method of claim 8, wherein a predicate incorporated in each of the messages is selected based on a look-up table.

9. The method of claim 8, wherein the predicate incorporated in each message is selected based on a reference class.

9. The method of claim 8, wherein the predicates incorporated in each of the messages are selected based on an OR expression and their position in a subquery.

Comparing the instantaneous readings for the constraints received in the network message with the data source associated with the query;
The response step includes encapsulating an instantaneous value of the return value specified in the network message, and adding a message ID and a network address of the inquiry node to the response message. the method of.

13. The packet according to claim 12, wherein the response message is an Ethernet packet, an IP packet, a UDP packet, a Profibus packet, a device net packet, an IEEE 802.11 packet, a Ricochet packet, a GSM format packet, a CDMA format packet, or a plurality of the packets. the method of.

The method of claim 2, wherein the constraint is static or dynamic.

The decomposing step comprises collecting all predicates from the query, the predicates refer to classes, and forming network messages for all of the predicates;
The method of claim 1, wherein each network message has at least one predicate in the query and adds a message ID to a network address of the querying node in the network message.

In the information management system of the distributed network of the data source database,
The system has a network, a plurality of data sources, and at least one query node,
The plurality of data sources are connected to the network;
The data source can provide information to the distributed network of data source databases according to a schema;
The at least one query node is connected to the network;
The query node may receive the query in a database language and break the query into at least one network message;
The network message is transmitted over the network to a data source associated with the query;
A data source associated with the query sends a response message over the network in response to the network message if the query matches;
The query node supplies query results in the database language from the response message;
A system characterized in that:

The network message and the response message are an Ethernet packet, an IP packet, a UDP packet, a Profibus packet, a device net packet, an IEEE 802.11 packet, a Ricochet packet, a GSM format packet, or a CDMA format packet, or a plurality of the packets. The system of claim 16.

17. The system of claim 16, wherein the schema comprises an association schema, an object-oriented schema, or an object association schema.

17. The system of claim 16, wherein the query language includes SQL.

17. The system of claim 16, wherein the network message uses characteristic routing and is transmitted over the network only to a data source associated with the query.

20. The system of claim 19, wherein the network message uses multicast routing and is transmitted over the network only to data sources associated with the query.

The data source associated with the query compares the instantaneous readings for the constraints received in the network message, the response message having the instantaneous value of the return value specified in the network message, the message ID and the query 17. The system of claim 16, transmitting the network address of the node.

A destination join node, wherein the destination join node is connected to the network;
The destination join node receives and processes at least two response messages from the data source associated with the query, forming and transmitting a response message including join information from the at least two response messages;
17. The system of claim 16, wherein the query node provides the query results in the database language from the response message including the join information.

A computer readable program product having computer readable code stored on a computer readable storage medium, comprising:
The computer readable code is capable of receiving a query in a database language and breaking the query into at least one network message;
The network message is transmitted over the network only to a data source associated with the query;
Further, the computer readable code may receive a response message via the network in response to the network message when the query matches, and provide query results from the response message in the database language.
A computer readable program product characterized by the above.

26. The network message is an Ethernet packet, an IP packet, a UDP packet, a Profibus packet, a device net packet, an IEEE 802.11 packet, a Ricochet packet, a GSM format packet, a CDMA format packet, or a plurality of the packets. Computer readable program products.

26. The computer readable program product of claim 25, wherein the network message is transmitted over the network using characteristic routing or multicast routing only to a data source associated with the query.

26. The computer readable program product of claim 25, wherein the computer readable storage medium comprises a computer application program resident on a query node.

26. The computer readable program product of claim 25, wherein the computer readable code is loadable into memory resident at a network interface of a querying node.

A computer readable program product having computer readable code stored on a computer readable storage medium, comprising:
The computer readable code receives a network message having a decomposed query including a constraint and a return value, compares instantaneous values for the return value, and responds to the response message via the network in response to the network message. Sent when the constraints from the decomposed query are met,
A computer readout program product characterized by the above.

30. The computer readable program product of claim 29, wherein the computer readable code is loadable into a memory resident on a data source network interface.

Data source hardware, a network interface including a memory and a controller, and a data source having computer readable code stored in said memory.
The computer readable code receives a network message having a decomposed query including a constraint and a return value, compares an instantaneous value for the return value, and responds to the network message in response to the network message over a network. Send when the constraints from the decomposed query are met,
A data source characterized by that:

The network interface is provided for receiving the network message and transmitting the response message,
The network message and the response message are an Ethernet packet, an IP packet, a UDP packet, a Profibus packet, a device net packet, an IEEE 802.11 packet, a Ricochet packet, a GSM format packet, or a CDMA format packet, or a plurality of the packets. 32. The data source according to claim 31.

At a destination join node having a network interface including a memory and a controller, and computer readable code stored in the memory,
The computer readable code receives at least two response messages;
Each response message has a response to the network message with the decomposed query including the constraints and the return value;
Further, the computer readable code processes the response message and provides and sends a join response message over the network in response to the network message when the constraints from the decomposed query are met.
A destination join node, characterized in that:

The method of claim 1, wherein the source comprises a sensor node.

17. The system of claim 16, wherein said data source comprises a sensor node.

The computer-readable program product of claim 24, wherein the data source comprises a sensor node.

The computer readable program product of claim 30, wherein the data source comprises a sensor node.

32. The data source of claim 31, wherein said data source comprises a sensor node and said data source hardware comprises sensor node hardware.