JP3884821B2

JP3884821B2 - 分散情報の統合方法及び装置

Info

Publication number: JP3884821B2
Application number: JP07552997A
Authority: JP
Inventors: 茂稔鮫嶋; 克己河野; 洋綿谷
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-03-27
Filing date: 1997-03-27
Publication date: 2007-02-21
Anticipated expiration: 2017-03-27
Also published as: US6038564A; US7333989B1; JPH10269252A

Description

【０００１】
【発明の属する技術分野】
本発明は、分散処理システムにおいてメッセージデータや各処理装置に格納されたデータの集配信方法に係わり、特に複数の処理装置に分散して格納される情報を収集して集約し、まとまった統合データを組み立ててアプリケーションプログラムに提供する分散情報の統合方法及び装置に関するものである。
【０００２】
【従来の技術】
アプリケーションプログラムが利用するデータは、メッセージデータとして伝送されたデータもしくは自処理装置又は他の処理装置のメモリやディスクに格納されるデータである。アプリケーションプログラムが処理を開始するタイミングは、他のアプリケーションプログラムからのメッセージ受信によって通知された時点か、またはアプリケーションプログラムが自らその時点を監視するものであった。すなわちメッセージを送信する側のアプリケーションプログラムが受信側アプリケーションプログラムに必要なデータを格納媒体から収集して受信側の必要なデータ項目を揃えてメッセージデータに載せて送信するか、または受信側のアプリケーションプログラムが必要なデータを取得するまで周期的に照会メッセージを送信し、データの格納媒体によって異なるアクセス方法を用いて必要なデータを収集する方式であった。
【０００３】
一方アプリケーションプログラムが必要とするデータ項目を抽出して提供する手段として、例えばネットワークコンピューティング（１９９４年６月号）Ｐ．Ｐ．９−２３「ミドルウェアを使いこなす」に記載されているリレーショナル・データベース（ＲＤＢ）を管理するデータベース・マネージメント・システム（ＤＢＭＳ）がある。このシステムは実データを格納しているＲＤＢのテーブルからアプリケーションプログラムが必要とするデータ項目を条件指定して抽出する機能を有している。この方法によると、アプリケーションがデータを要求したときに要求したデータ項目の抽出作業が行われ、抽出されたデータがアプリケーションに渡されるというものである。ここでアプリケーションに渡されるデータの形式は、アプリケーションプログラムとの間のインタフェースによって決められており、例えばテキスト形式や独自のオブジェクト形式である。このため抽出されたデータを処理に利用するためにはＤＢＭＳの返したデータの形式を判断して書式を適宜変換する必要があった。
【０００４】
【発明が解決しようとする課題】
アプリケーションプログラムは、何らかのタイミングによってデータを取得し、取得したデータを用いてその処理を行う。プログラムごとに必要とするデータは異なるため、このタイミングや入力データはプログラムごとに決められる。入力されるデータは、処理性能や容量に応じてメモリやディスクに蓄えられているものか、メッセージの形式で伝送されたものか、これら両者を組合わせたものである転写メモリの形式をもったものである。これらのデータは複数のデータ項目から構成されており、プログラムは複数の記憶媒体からそれぞれ一部のデータ項目を抽出しかつ複数のデータ項目を統合して利用する。またデータを収集するときのトリガとなるイベントの発生は、プログラムが存在する処理装置で生じる場合もあるが、他の処理装置で発生することも多い。
【０００５】
従来技術によれば、自処理装置又は他の処理装置に格納されるデータをアプリケーションプログラムが要求しない限りこれを取得することはできなかった。さらに複数の記憶媒体に格納されているデータは、それぞれ媒体ごとに一部を抽出することしかできなかった。このため処理の起動タイミングとなるメッセージを送信するアプリケーションプログラム、または処理を行うアプリケーションプログラムは、タイミングの検知と通知、データの収集と統合を行う必要があった。タイミングの通知に当っては、イベントを通知する処理をイベント発生側に、このイベントを受信する処理をアプリケーションプログラム側に作成する必要があった。またはアプリケーションプログラムが周期的にポーリングをかける等して自らイベントの発生を検知する必要があった。データの収集と統合においても、転写メモリやディスクのように記憶媒体ごとに異なるアクセス法を介してデータを取得したり、あるいはイベント発生を検知した時点でＲＤＢにアクセスし、必要とする最新データを収集する必要があった。あるいはデータが必要でないときも常時データを収集し、データが必要になったときに収集したデータの中から必要なものを抽出して利用する必要があった。このためアプリケーションプログラムは、本来行ないたい処理の他にイベント検知処理やデータ収集処理のコーディングを備えなければならず、開発工数が増えるという問題があった。
【０００６】
またシステムの性能チューニングや改造を行なうと、アプリケーションプログラムの配置を変えたり、データの格納媒体や伝送媒体を変更したりする。アプリケーションプログラム自体を改造する場合は、必要となるデータ項目やイベントが変更されたりする。これらの場合も、従来技術によるとアプリケーションプログラムのソースコードを見直して主たる処理部以外のイベント検知部やデータ収集部を修正する必要がある。イベント送信側のプログラムがデータを収集／統合している場合は、改造対象のプログラムにイベントを送っているプログラムも見直す必要が生じ、改造における工数も大きくなる。
【０００７】
さらに制御システムにおいてある制御データについてのイベント発生に連動して関連するデータを収集する場合や異常発生時に関連するデータを収集する場合があるが、イベント発生時の関係するデータが必要であるにも係わらず、イベントを検知した後に１つ１つデータを収集する方法ではデータのリアルタイム性が保証できないといった問題もあった。特に遠隔地から複数の伝送媒体を経由してデータを取得する場合には、伝送路の通信負荷や伝送遅延のためにリアルタイム性の保証は一層困難である。
【０００８】
本発明の目的は、上記問題点を解決し、データを格納する処理装置の所在場所に係わらず、要求元の必要とするデータをとり揃えて要求元の必要とするタイミングで提供することにある。併せてデータの格納媒体やデータ収集のために使用する伝送媒体の変更から要求元のアプリケーションプログラムを独立させることにある。
【０００９】
【課題を解決するための手段】
本発明は、少なくとも１台の第１の処理装置によってそれぞれイベントの発生をトリガとしてあらかじめ設定された収集条件に従って自処理装置に格納されるデータを収集してデータ要求元の第２の処理装置へ送信し、第２の処理装置によって受信した収集データをあらかじめ設定された統合条件に従って統合する分散情報の統合方法を特徴とする。
【００１０】
アプリケーションプログラムが必要とするデータは、すべてとり揃えて提供されるので、アプリケーションプログラムが自処理装置又は他処理装置に問い合わせを行ってデータを収集する必要がない。また必要とするデータがすべて揃わず一部のデータが揃った時点でデータを取得することも可能である。アプリケーションプログラムが受け取るデータは、アプリケーションプログラムが指定したデータ形式になっており、データ源の格納媒体やデータ構造、データを格納する処理装置の存在、データ収集のために利用する伝送媒体の存在を意識する必要はない。
【００１１】
【発明の実施の形態】
以下に本発明の実施の形態について図面を用いて詳細に説明する。
【００１２】
図１は、本発明を適用するシステムの構成例を示す図である。システムは、伝送媒体１０１を介して互いにデータの授受を行なう処理装置１１１〜１１３とディスプレイやキーボードを有する端末装置１２１〜１２３とを有する。処理装置１１１〜１１３には端末装置１２１〜１２３が接続されている。ここで端末とは、ディスプレイやキーボード、タッチパネル等のマンマシンインタフェ−スを持ち、このインタフェ−スを介して処理装置上で実行されるプログラムの制御を行ったりプログラムの出力を参照したりする機能を有している。また処理装置１１１〜１１３は主記憶装置（メモリ）のようなデータ記憶媒体を持ち、処理装置１１１〜１１３に接続されている外部記憶装置１３１〜１３３はフロッピーディスクやハードディスク等のデータ記憶媒体を保持している。ただしこれは必須ではなく外部記憶装置を持たない処理装置も可能である。本発明において、処理装置の格納しているデータとは、これら処理装置内の記憶媒体や外部記憶装置に格納されているデータのことをいう。また処理装置１１１は伝送媒体１０２を介して処理装置１１４とデータの授受を行なう。このように処理装置は複数の伝送媒体を接続可能であり、処理装置１１１が仲介することによって処理装置１１４と処理装置１１２，１１３がデータの授受を行うこともできる。
【００１３】
図２は、処理装置１１１〜１１４内のソフトウェア構成を示す図である。アプリケーションプログラム２１１，２１２は、自処理装置または他処理装置に格納されたデータや伝送媒体１０１，１０２を介して受信されるメッセージ中のデータを利用して業務処理を行うプログラムである。データアクセス処理２２１は、自処理装置に格納されたデータへのアクセスを管理するプログラムであり、メモリ、外部記憶装置、転写メモリのように記憶媒体によらずデータのアクセスを可能とする。ここで転写メモリとは、ユーザがメモリに書き込んだ情報のコピーが自動的に別のメモリに転送されて利用可能となるような方式をいう。通信管理２２３は、自処理装置内のプログラム間通信及び伝送媒体１０１，１０２を介する他の処理装置とのメッセージの送受信を管理するプログラムである。データアクセス管理テーブル２３１は、自処理装置に格納されているデータの名称とその属性を格納する。イベント連携データテーブル２３２は、あるイベントに対してどのデータ項目の値を取得してどの要求元に送る必要があるかを設定する。データ統合管理テーブル２３３は、統合される各データの参照元とデータ名を定義し、統合されたデータをアプリケーションプログラム２１１，２１２に渡すときの出力オプションなどを定義する。フィルタリング処理２２２は、自処理装置内の周期タイマ、データ更新によるイベント発生、他処理装置から受信したメッセージによるイベントなどイベントを検知し、イベント連携データテーブル２３２、データアクセス管理テーブル２３１及びデータ統合管理テーブル２３３を参照し、データアクセス処理２２１を介する自処理装置内のデータの取得または統合されたデータの取得を行い、通信管理２２３を介して取得したデータを要求する他処理装置又は自処理装置のデータ統合処理２２４へ送信するプログラムである。データ統合処理２２４は、他処理装置又は自処理装置のフィルタリング処理２２２から送信されたデータを受信し、データ統合管理テーブル２３３及びデータアクセス管理テーブル２３１を参照してデータの統合を行ってから統合されたデータをアプリケーションプログラム２１１，２１２又はフィルタリング処理２２２に渡すプログラムである。状態制御テーブル２３４は、イベント連携データテーブル２３２に設定されるデータの収集及びデータ統合管理テーブル２３３に設定されるデータの統合を開始／終了する条件を設定する。状態制御処理２２５は、メッセージ受信、データ更新などのイベントを検知し、状態制御テーブル２３４を参照してデータ収集又はデータ統合を開始／終了するタイミングを検知し、イベント連携データテーブル２３２及びデータ統合管理テーブル２３３の関連する制御情報を活性化するプログラムである。
【００１４】
図３ａ及び図３ｂは、データ統合管理テーブル２３３のデータ構成を示す図である。アプリケーションプログラムが必要とするデータをまとめたものを以後バスケットと呼ぶ。図３ａ（i）は、バスケット設定テーブル３０１の構成を示す図である。バスケット設定テーブル３０１の各レコードは、バスケット名３１１、収集イベント３１２、収集項目テーブルインデックス３１３、出力オプションインデックス３１４、状態管理テーブルインデックス３１５及び活性状態３１６から構成される。バスケット名３１１はバスケットを識別する名称である。収集イベント３１２は種別と条件から構成される。種別は収集するイベントの種類を示す。例えばイベントがメッセージ受信であることとそのメッセージの内容を示すコード、イベントがデータ更新であることと更新されたデータテーブルの名称、イベントが周期タイマによるものであることとタイマ割り込みの周期を示す。条件はイベントの発生によってデータを収集するときの条件を示す。例えばイベントがメッセージ受信の場合にはメッセージ中のデータ項目の値につける条件、イベントがデータ更新である場合にはデータテーブル中の更新されたデータ項目の名称である。イベントが周期タイマによるものである場合には条件がない。収集項目テーブルインデックス３１３は、収集項目テーブルの格納場所を指すインデックスであり、収集項目テーブルのデータ構成は図３ａ（ii）に示される。出力オプションインデックス３１４は、出力オプションテーブルの格納場所を指すインデックスであり、同テーブルのデータ構成は図３ｂ（iii）に示される。また状態管理テーブルインデックス３１５は、状態管理テーブルの格納場所を指すインデックスであり、同テーブルのデータ構成は図３ｂ（iv）に示される。活性状態３１６はデータ統合処理を行うか否かの状態を示す。
【００１５】
図３ａ（ii）は、収集項目テーブルのデータ構成を示す図である。収集項目テーブルは、イベントの発生に伴って収集するデータ項目と参照元を定義する。収集項目テーブルの各レコードは、バスケット項目名３５１、型（書式）３５２、参照元３５３及び条件３５４から構成される。バスケット項目名３５１は、バスケットを構成する項目として定義するデータ項目名である。型（書式）３５２は、対応するデータ項目の型であり、長整数型、短整数型、文字型などを区別する。参照元３５３はそのデータ項目を取得する元を定義するものであり、ソース名とデータ項目名から構成される。ソース名は参照元のデータ名であり、たとえばイベントがメッセージ受信である場合のそのメッセージの内容コード、処理装置の識別子とデータテーブルの名称、処理装置の識別子と作成されるバスケットのバスケット名３１１などである。データ項目名はソース名で示されるデータ中でその値取得の対象とするデータ項目の名称である。本実施形態では、ソースが特定の処理装置内にある場合にその処理装置の識別子と該処理装置内のデータ名によって指定するが、システム内でソースに一意の名称をつけ、この名称を指定してもよい。条件３５４は参照元３５３で指定するソースから指定のデータ項目の値を取得するときの条件を指定するものであり、ソース名で指定されるデータ中のデータ項目の値と収集イベント３１２で指定したイベントによって受け取るデータ項目の値との大小関係によって記述する。例えば「ソースデータ中のデータ項目”ＩＤ”が受信メッセージ中のデータ項目”バーコード番号”と等しい」等である。
【００１６】
図３ｂ（iii）は、出力オプションを定義するテーブルのデータ構成を示す図である。このテーブルは、収集したデータをアプリケーションプログラムに渡すときに選択可能なオプションを設定する。本テーブルの各レコードは、タイムアウト３７２、データ受渡方法３７３、ＡＮＤ／ＯＲ判定３７４及びデータ要求元３７５から構成される。タイムアウト３７２は、処理装置がバスケットのデータ収集条件となるイベントを検知してから全データを受け取るまでの制限時間を示す。データ受渡方法３７３はイベント型又はデマンド型を指定する。イベント型の場合はデータが揃うか又はタイムアウトしたとき直ちに揃ったデータをプログラムに渡す。デマンド型の場合は揃ったデータを蓄積しておき、プログラムから要求があったときに渡す。ＡＮＤ／ＯＲ判定３７４は、ＡＮＤ型又はＯＲ型を指定する。ＡＮＤ型の場合はデータが揃うとは、バスケットを構成するすべての項目の値を取得するか又はタイムアウトしたこととみなす。ＯＲ型の場合はデータが揃うとは、バスケットを構成するいずれかの項目の値を取得できたこととし、他の構成項目の値はすでに取得している最新の値を用いることとする。データ要求元３７５はデータを渡す先のアプリケーションプログラムの識別子又はフィルタリング処理２２２を示す。
【００１７】
図３ｂ（iv）は、状態管理テーブルのデータ構成を示す図である。状態管理テーブルは、イベント識別子に対応して収集の対象となるデータ項目の収集状態を示す。状態管理テーブルの各レコードは、イベント識別子３９１、バッファインデックス３９２、第１イベント到着時刻３９３および収集判定マップ３９４から構成される。イベント識別子３９１は、ＡＮＤ／ＯＲ判定３７４がＡＮＤ型の場合に何回目のイベントかを示す番号であり、１つのイベントに対して１つ又は複数の処理装置から送られたデータの同期を取るための番号である。バッファインデックス３９２は、各イベント識別子３９１ごとにバスケットの構成項目データを格納するために割り当てられたバッファのアドレスを示す。第１イベント到着時刻３９３は、イベント識別子３９１で示されるイベントを検知した時刻又は該イベント識別子に対応する任意のバスケット構成項目を最初に受信した時刻を格納する。第１イベント到着時刻３９３はタイムアウトか否かを判定するために参照される。収集判定マップ３９４は、バスケットを構成する各項目ごとにデータを取得したか否かをビットマップで示す。なおバスケット構成項目の値がアプリケーションプログラムまたはフィルタリング処理２２２に渡され、バッファを解放する時点で該当するレコードが削除される。またＡＮＤ／ＯＲ判定３７４がＯＲ型の場合には、状態管理テーブルのレコードは１つのみであり、プログラムにデータを渡した後、バッファインデックス３９２の指すバッファ領域を解放しない。
【００１８】
図４は、データアクセス管理テーブル２３１のデータ構成を示す図である。データアクセス管理テーブル２３１は、自処理装置がどのようなデータを管理していてそのデータがどのような構造をもつかを示すテーブルである。ここで自処理装置が管理するデータには、他の処理装置と授受するメッセージデータも含まれる。データアクセス管理テーブル２３１の各エントリは、テーブル名４１１、媒体４１２及びデータ構造インデックス４１３から構成される。テーブル名４１１はデータテーブルの名称を示す。媒体４１２はテーブル名４１１で示されるデータがメッセージか、主記憶（メモリ）に格納されているものか、ディスク上に格納されているものかを示す。データ構造インデックス４１３は該データの構造を定義するテーブルの格納アドレスを示すインデックスである。データ構造を定義するテーブルは、データ項目４３１及び型４３２から構成される。データ項目４３１は当該データを構成するデータ項目の名称、型４３２はその型であり、型（書式）３５２と同じである。
【００１９】
図５は、イベント連携データテーブル２３２のデータ構成を示す図である。イベント連携データテーブル２３２は、イベントが発生したときに自処理装置内のどのデータを収集して送信すべきかを設定するテーブルである。すなわちこのテーブルは、自処理装置に格納されているデータおよび自処理装置で作成されるバスケットが参照元となっている場合のバスケットをまとめたものである。テーブルの図示する１行が１レコードである。イベント連携データテーブル２３２の各レコードは、収集イベント４５１、応答先４５２、データ名４５３、収集データ項目４５４、収集条件４５５及び活性状態４５６から構成される。収集イベント４５１は、データを収集するトリガとなるイベントを設定するものであり、収集イベント３１２と同様の内容である。応答先４５２は、収集したデータ項目の値を送る相手処理装置の識別子を指定する。例えば自処理装置のデータ更新イベントを通知する必要のある処理装置の識別子を指定する。データ名４５３、収集データ項目４５４及び収集条件４５５は、参照元３５３及び条件３５４と同じである。すなわちイベント連携データテーブル２３２は、参照元３５３及び条件３５４を参照元の処理装置についてまとめたものである。活性状態４５６は、対応するレコードに指定されたデータ収集と送信を行うか否かの状態を示す。イベント連携データテーブル２３２は自処理装置が参照元となり得るデータを収集イベントごと、応答先ごとにまとめたものである。
【００２０】
図６（ａ）は、通信管理２２３が処理装置間や処理装置内で送受信するメッセージのデータ構成を示す図である。メッセージは、通信制御のためのメッセージヘッダ７１１と、アプリケーションプログラム２１１、フィルタリング処理２２２及びデータ統合処理２２４が参照するユーザデータ部７１２から構成される。メッセージヘッダ７１１は、通信用の制御コード７２１、宛先識別コード７２２、送信側処理装置を識別するコード７２３及びイベント識別子７２４から構成される。イベント識別子７２４は、処理装置が送信するメッセージを時系列的に識別するための通番であり、例えば処理装置の識別子と該処理装置内の通番の組合せによって表現される。イベント識別子７２４によって同一処理装置かつ同一プログラムが発行するメッセージであっても発生順序を識別できる。宛先識別コード７２２として例えば特開昭５６−１１１３５３号公報に記載されるような内容コードを用いてもよい。ユーザデータ部７１２は、一般に複数のデータ項目から構成され、各データ項目の値を含む。メッセージを受信した処理装置は、データアクセス管理テーブル２３１を参照することによって各データ項目の型を取得し、各データ項目の値を切り出すことが可能である。また通信管理２２３がデータアクセス管理テーブル２３１を参照して各データ項目の型を認識し、自処理装置で処理できるようにデータ項目値のバイトオーダーを変換することも可能である。
【００２１】
図６（ｂ）は、フィルタリング処理２２２が発生したイベントに関連して収集したデータを要求元に送るときのユーザデータ部７１２のデータ構成を示す図である。収集イベント種別７３１は、収集イベント３１２の種別、すなわち収集イベント４５１の種別と同じである。収集イベント識別子７３２は、イベント発生元のイベント識別子を設定する。例えばイベントがメッセージ受信である場合には受信したメッセージのイベント識別子７２４を設定する。イベントが周期タイマによるものである場合には自処理装置内の通番等を設定する。イベントがデータ更新である場合には、更新されたデータを格納している処理装置の処理装置内通番等を設定する。このデータ更新を通知するメッセージ受信をトリガとして関連するデータを収集する処理装置では、この更新データに付けられた収集イベント識別子７３２を指定する。応答先７３３はデータ送信先の相手処理装置の識別子である。ソース名７３４は、参照元のデータ名であり、例えば処理装置の識別子とデータテーブルの名称などである。収集データ項目リスト７３５は、収集したデータ項目名のリストを設定する。収集データ７３６は、収集データ項目リスト７３５の各データ項目に対応してその値を設定する。図６（ｂ）に示すデータ構成は一例であり、同一イベントに関する複数の収集データを相乗りによってまとめて送信したり、複数の応答先への収集データをまとめて送信するためのデータ構成としてもよい。
【００２２】
フィルタリング処理２２２が収集したデータを応答先に送るときのメッセージ以外のフィルタリング処理２２２及びデータ統合処理２２４が受信するメッセージは、メッセージヘッダ７１１又はユーザデータ部７１２の内容によって収集データメッセージと区別される。図６（ｂ）のデータ形式に準じてもよい。例えばイベント識別子７２４と収集イベント識別子７３２が同一内容であるメッセージをデータ収集のトリガとするメッセージとして識別するなどである。また処理装置の特定のポートから受信する制御データ又はメッセージは、ポートの識別子によって特定のメッセージと識別することが可能である。
【００２３】
図７は、フィルタリング処理２２２の処理の流れを示す図である。フィルタリング処理２２２は、イベント発生を待つ（ステップ５０１）。メッセージ受信イベントの場合には、通信管理２２３がメッセージを受信してフィルタリング処理２２２を起動する。自処理装置内のデータ更新イベントの場合には、データアクセス処理２２１やデータ統合処理２２４がフィルタリング処理２２２を起動して更新データを渡す。データ統合処理２２４が更新データを送る場合とは、データを統合したバスケットをフィルタリング処理２２２に渡す場合である。他の処理装置のデータ更新イベントの場合には、通信管理２２３が更新データを含むメッセージを受信してフィルタリング処理２２２を起動する。また自処理装置に直接又は伝送媒体を介して接続される計測器やセンサから送られる制御データの受信もイベント発生となる。周期イベントの場合には、周期タイマによりタイマ割り込みが発生し、フィルタリング処理２２２を起動する（ステップ５５１）。フィルタリング処理２２２がイベントを検知すると、発生したイベントの種別と付随するデータを取得する（ステップ５０２）。次にイベント連携データテーブル２３２を参照して発生したイベントに関連して取得する必要のあるデータ又はバスケットがあるか否かを検索する（ステップ５０３）。すなわち発生したイベントの種別及び付随するデータと収集イベント４５１の収集条件とを突き合わせて両者が合致するレコードがあるか否かを判定する。ただしここで検索の対象とするレコードは、活性状態４５６が活性状態として設定されているレコードである。その結果、放出する（送信する）レコードが見つからない場合（ステップ５０４Ｎ）には、ステップ５０１に戻る。該当するレコードが見つかった場合（ステップ５０４Ｙ）には、そのレコードのデータ名４５３で示されるデータのデータ項目４５４について収集条件４５５を満足するデータ項目値を取得する（ステップ５０５）。収集条件４５５がなければ無条件である。データ取得に当っては、データアクセス管理テーブル２３１を参照して該当するデータの媒体４１２及び該当するデータ項目の型４３２を取得してからデータアクセス処理２２１を起動してデータを取得する。取得するデータがバスケットである場合には、データ統合管理テーブル２３３のバスケット名３１１及びバスケット項目名３５１を参照してその型３５２を取得する。放出すべきデータが複数ある場合にはすべてのデータを同様に取得する。次に取得したデータに基づいて送信データを作成する（ステップ５０６）。応答先７３３には該当するレコードの応答先４５２を、ソース名７３４にはそのデータ名４５３を、収集データ項目リスト７３５には収集データ項目４５４を格納する。イベント識別子７２４にはフィルタリング処理２２２が生成した識別子を格納する。最後に通信管理２２３を介して他の処理装置又は自処理装置内のデータ統合処理２２４へデータを送信し（ステップ５０７）、ステップ５０１に戻る。
【００２４】
図８ａ、図８ｂ及び図８ｃは、データ統合処理２２４の処理の流れを示すフローチャートである。データ統合処理２２４は、他の処理装置又は自処理装置からのデータ到着を待つ（ステップ６０１）。通信管理２２３を介してデータ又はメッセージを受信すると（ステップ６０２）、データ統合管理テーブル２３３を参照して受信したデータを要求しているバスケットがあるか否か判断する（ステップ６０３）。すなわち受信したメッセージが収集データである場合にそのソース名７３４及び収集データ項目リスト７３５のデータ項目名とデータ統合管理テーブル２３３の参照元３５３とを突き合わせて受信したデータをバスケット構成項目とするバスケットが存在するか否か判断する。このとき収集データ７３６の型は、バスケット構成項目の型３５２を参照することによつて得られる。該当するバスケットが存在しない場合（ステップ６０３Ｎ）には、データ統合管理テーブル２３３を参照して受信したデータを収集イベントとするバスケットがあるか否かを判断する（ステップ６２１）。すなわち受信したメッセージの収集イベント種別７３１（及び収集データ７３６）とデータ統合管理テーブル２３３の収集イベント３１２とを突き合わせて収集条件を満足するバスケットが存在するか否かを判断する。このとき収集データ７３６の型は、データアクセス管理テーブル２３１のソース名７３４に対応するデータ名４１１の収集データ項目リスト７３５のデータ項目に対応するデータ項目４３１の型４３２を参照することによって得られる。該当するバスケットが存在するとき、図８ｂ（ii）に示す収集状態の設定または更新を行う（ステップ６０５）。その後ステップ６０１に戻る。該当するバスケットが存在しないときには、ただちにステップ６０１に戻る。受信したデータを要求しているバスケットが存在する場合（ステップ６０３Ｙ）には、該バスケットに必要なデータ項目を受信メッセージから抽出する（ステップ６０４）。すなわち収集データ７３６から少なくとも１つのデータ項目の値を抽出する。その後図８ｂ（ii）に示す状態管理テーブル上の収集状態の設定または更新を行う（ステップ６０５）。なおステップ６０３及びステップ６２１のデータ統合管理テーブル２３３検索に当っては、活性状態３１６が活性状態に設定されているバスケットのみを検索対象とする。この後ステップ６０４で抽出したデータ項目値を当該バスケットの状態管理テーブルインデックス３１５によって指される状態管理テーブルのバッファインデックス３９２の指すバツファ領域の中の当該データ項目値の格納場所に格納する（ステップ６０６）。
【００２５】
次にバスケットの構成項目が揃ったか否かを判断する（ステップ６０７）。データの収集状態は当該バスケットの状態管理テーブル収集判定マツプ３９４を参照することによつて判定される。またデータが揃うときの条件は、当該バスケットの出力オプションを設定するテーブルのＡＮＤ／ＯＲ判定３７４によって決まる。ＡＮＤ／ＯＲ判定３７４がＡＮＤ型の場合には、すべての構成項目を取得したときが揃った時点である。ＡＮＤ／ＯＲ判定３７４がＯＲ型の場合には、いずれか１つの構成項目を取得したときが揃った時点であり、他の構成項目は、過去に取得した構成項目のうちバッファ上にある最新のデータがその値として用いられる。データが揃ったと判断した場合（ステップ６０７Ｙ）には、処理６３２に移り、要求元にデータを渡す。データが揃っていない場合（ステップ６０７Ｎ）には、ステップ６０１に戻る。処理６３２では当該バスケットの出力オプションテーブルを参照してデータ受渡方法３７３がイベント型がデマンド型かを判断する（ステップ６０８）。イベント型の場合（ステップ６０８Ｙ）には、当該バスケットのデータ要求元３７５が指定するアプリケーションプログラム又はフィルタリング処理２２２にデータを渡す（ステップ６０９）。デマンド型の場合（ステップ６０８Ｎ）には、バッファインデックス３９２が指す当該バスケットのバッファ領域の内容をキューに格納する（ステップ６２５）。アプリケーションプログラムはこのキューからデータを取り出すことができる。ステップ６０９及び６２５の処理の後に図８ｂ（iii）に示す状態管理テーブルとバッファの整理を行って（ステップ６１０）、ステップ６０１に戻る。
【００２６】
図８ｂ（ii）は、状態管理テーブルの設定及び更新処理の流れを示すフローチャートである。当該バスケットの状態管理テーブルを検索して受信したメッセージの収集イベント識別子７３２をもつレコードがあるか否か判定する（ステップ６４１）。出力オプションテーブルのＡＮＤ／ＯＲ判定３７４がＡＮＤ型の場合には、イベント識別子３９１によって出力オプションテーブルを検索する。ＯＲ型の場合には出力オプションテーブルはただ１つのレコードをもつのでそのレコードのイベント識別子３９１によって該当するレコードか否かを判定する。該当するレコードが存在しない場合（ステップ６４１Ｙ）には、テーブルにレコードを追加し（ステップ６４２）、そのレコードのイベント識別子３９１に受信したメッセージの収集イベント識別子７３２を追加し、バッファ領域を確保してそのインデックスをバッファインデックス３９２に設定する（ステップ６４３）。またイベントが到着した時刻を第１イベント到着時刻３９３に設定する（ステップ６４４）。その後、収集判定マップ３９４のうち取得したバスケット項目に対応するビットを取得済みに設定する（ステップ６４５）。該当するレコードが存在する場合（ステップ６４１Ｎ）には、ステップ６４５の処理だけを行う。
【００２７】
図８ｂ（iii）は、状態管理テーブルとバッファの整理を行う処理の流れを示すフローチャートである。まず当該バスケットの出力オプションテーブルのＡＮＤ／ＯＲ判定３７４がＡＮＤ型か否かを判定する（ステップ６５１）。ＡＮＤ型の場合（ステップ６５１Ｙ）には、当該バスケットの項目値はすべて不要となるため状態管理テーブルのバッファインデックス３９２によつて指されるバッファ領域をすべて解放し（ステップ６５２）、当該状態管理テーブルのレコードのうち該当するイベント識別子をもつレコード内容をクリアする（ステップ６５３）。ＯＲ型の場合（ステップ６５１Ｎ）には何もしない。
【００２８】
図８ｃ（iv）は、タイムアウト監視処理の流れを示すフローチャートである。本処理のプログラムが周期的に起動されると（ステップ６６１）、データ統合管理テーブル２３３のバスケット設定テーブル３０１に格納されているバスケットのレコードをすべて処理したか否か判定する（ステップ６６２）。まだ未処理のバスケットがあれば（ステップ６６２Ｙ）、ポインタを次のバスケットのレコードに位置づけて（ステップ６６３）、該バスケットの状態管理テーブルのすべてのレコードを処理したか否か判定する（ステップ６６４）。まだ未処理のレコードがあれば（ステップ６６４Ｙ）、ポインタを状態管理テーブルの次のレコードに位置づけて現在時刻を取得し（ステップ６６５）、当該バスケットのタイムアウト設定３７２に照らして現在時刻と第１イベント到着時刻３９３との差がタイムアウトとなったか否か判定する（ステップ６６６）。タイムアウトしたとき（ステップ６６６Ｙ）、図８ａのデータ受渡処理６３２を実行し（ステップ６６７）、ステップ６６４に戻る。当該レコードがタイムアウトしていなければ（ステップ６６６Ｎ）、ステップ６６４に戻る。状態管理テーブルのすべてのレコードを処理したか又はテーブルがクリアされていれば（ステップ６６４Ｎ）、ステップ６６２に戻る。すべてのバスケットの処理を終了したとき（ステップ６６２Ｎ）、タイムアウト監視処理を終了する。タイムアウト監視処理によって他処理装置の障害等によりデータ収集が完了しない状態を監視する。
【００２９】
図９は、状態制御テーブル２３４のデータ構成を示す図である。テーブルの図示する１行が１レコードである。イベント１６１１は、収集イベント３１２及び収集イベント４５１と同様である。開始／終了１６１２は、分散情報統合処理の開始に関するイベントか、終了に関するイベントかを示す。条件回数１６１３は、イベント１６１１が何回検知されたら開始／終了１６１２に示す開始又は終了とするか、その回数を設定する。イベントカウンタ１６１４は、現在の検知回数を示す。制御対象１６１５は、開始／終了制御の対象がバスケットか収集データかを示す。制御対象インデックス１６１６は、制御対象の設定されているレコードへのポインタを示す。バスケットの場合はバスケット設定テーブル３０１のレコードを指し、収集データの場合はイベント連携データテーブル２３２のレコードを指す。
【００３０】
図１０は、状態制御処理２２５の処理の流れを示すフローチャートである。イベントの受信を待ち（ステップ１７０１）、イベントを受信したとき、イベント種別と付随するデータを取得する（ステップ１７０２）。次に状態制御テーブル２３４を検索してこのイベントで状態制御するよう設定されているレコードがあるか否か判定する（ステップ１７０３）。検索はイベント種別と付随データを満足するイベント１６１１をもつレコードを探す処理である。該当するレコードがなければ（ステップ１７０３Ｎ）、ステップ１７０１に戻る。該当するレコードがあれば（ステップ１７０３Ｙ）、そのレコードのイベントカウンタ１６１４に１を加えることによってこれを更新し（ステップ１７０４）、条件回数１６１３と更新されたイベントカウンタ１６１４とを比較する（ステップ１７０５）。両者が等しくない（条件を満たさない）場合（ステップ１７０６Ｎ）には、ステップ１７０３に戻る。条件を満たす場合（ステップ１７０６Ｙ）には、制御対象１６１５及び制御対象インデックス１６１６が指すレコードの活性状態３１６又は活性状態４５６を更新する（ステップ１７０７）。すなわち状態制御テーブル２３４の現在処理中のレコードの開始／終了１６１２が開始を指定していれば、制御対象インデックス１６１６が指すレコードの活性状態３１６又は活性状態４５６を活性状態にする。開始／終了１６１２が終了を指定していれば、制御対象インデックス１６１６が指すレコードの活性状態３１６又は活性状態４５６を非活性状態にする。最後に処理中のレコードのイベントカウンタ１６１４をリセットし（ステップ１７０８）、ステップ１７０３に戻る。状態制御処理２２５によってデータ収集の開始／終了がイベントの発生回数又はデータ収集回数によって制御でき、きめ細かなデータ収集制御が可能である。例えば異常発生イベントに連動して装置状態などのデータを収集し始め、無人運転中の状態トレンドについての情報を収集するといった応用も可能である。
【００３１】
以上説明した方式及び構成を利用して分散情報を統合化する適用例について以下説明する。
【００３２】
図１１は、メッセージ受信をイベントとする適用例を示す図である。システムは共通の伝送媒体に接続された処理装置８０１，８０２及び８０３から構成される。伝送媒体を介してブロードキャストされるメッセージ８３１をトリガイベントとして、処理装置８０２のフィルタリング処理２２２は、その外部記憶装置（ディスク）８１１に格納されているテーブルデータ８２１中のデータを収集し、処理装置８０３のフィルタリング処理２２２は、その内部記憶装置（メモリ）に格納されているテーブルデータ８２２を収集し、それぞれメッセージ８４１及び８４２として処理装置８０１に送信する。処理装置８０１のデータ統合処理２２４は、メッセージ８３１，８４１及び８４２を統合してバスケットを構成するデータ８４３を作成し、アプリケーションプログラム２１１に渡す。
【００３３】
図１２ａ（i）は、メッセージ８３１のユーザデータ部７１２に含まれるデータ項目のリストを示す図である。図１２ａ（ii）は、処理装置８０２が保有するテーブルデータ８２１のデータ構成を示し、各レコードは部品ＩＤをキーとする図示のようなデータ項目から構成される。図１２ａ（iii）は、処理装置８０３が格納するテーブルデータ８２２のデータ構成を示し、ロット番号（ＬｏｔＮｏ．）をキーとする図示のようなデータ項目から構成される。
【００３４】
図１２ｂは、処理装置８０１のデータ統合管理テーブル２３３の設定例を示す図である。データ統合されるバスケットは、レコード９２１及びこれからリンクされるテーブルで定義されている。バスケット名は「生産指示」である。収集するイベントは、宛先識別コード７２２が「ライン進入」であるメッセージ（Ｍｓｇ）のうち部品ＩＤが１０００より大きいものである。収集イベントの収集条件を満足するメッセージを受信したとき及び収集データを受信したとき収集する項目は、収集項目テーブルのレコード９４１〜９４５に設定されている。レコード９４１及び９４２に定義する項目値は収集イベントとなる受信メッセージから取得するデータである。レコード９４３及び９４４に定義する項目値は、処理装置８０２（Ｓ２）の「製造条件」というテーブルデータ８２１のそれぞれ「条件値１」および「条件値２」というデータ項目の値である。ただし「条件値１」は「製造条件」の部品ＩＤが収集イベントメッセージの部品ＩＤに等しいという条件を満たすものであり、「条件値２」は「条件値１」の条件に加えて質基準が収集イベントメッセージの品質基準値より大きいか等しいという条件を満たすものである。同様にレコード９４５に定義する項目値は、処理装置８０３（Ｓ３）の「製造実績」というテーブルデータ８２２の「ロツト実績値」というデータ項目の値である。ただし「ロツト実績値」はテーブルデータ８２２のレコードのうち「ロット番号」が収集イベントメッセージのロット番号に等しいようなレコードのロツト実績値である。各バスケット構成項目は、型（書式）のフィールドに示すように長整数型又は６バイト文字型としてデータ要求元３７５に示すプログラムに渡される。
【００３５】
図１２ｃ（vi）は、処理装置Ｓ２のイベント連携データデータテーブル２３２の設定例を示す図である。レコード９５１及び９５２は、それぞれデータ統合管理テーブル２３３の収集項目テーブルのうち処理装置Ｓ２に関するレコード９４３及び９４４を抽出したものである。収集イベントの収集条件は、処理装置Ｓ１の収集イベントの収集条件と同じである。収集したデータの応答先は、要求元の処理装置Ｓ１である。図１２ｃ（vii）は、処理装置Ｓ３のイベント連携データテーブル２３２の設定例を示す図である。レコード９６１は同様にデータ統合管理テーブル２３３の収集項目テーブルのうち処理装置Ｓ３に関するレコード９４５を抽出したものである。
【００３６】
図１３は、本適用例についてのイベントシーケンスの例を示す図である。図は収集イベントのメッセージ８３１を受信した後の処理装置Ｓ１，Ｓ２及びＳ３の動作を示す。始めにイベント識別子１の「ライン進入」メッセージ１００１が伝送媒体を流れると、処理装置Ｓ１はデータ格納領域を確保し、このメッセージからデータ項目「部品ＩＤ」及び「ロット番号」を取得し、そのデータ格納領域に格納する（１０１１）。同時に処理装置Ｓ２はデータ項目「条件値１」及び「条件値２」の取得を開始し（１０２１）、処理装置Ｓ３はデータ項目「ロット実績値」の取得を開始する（１０３１）。処理装置Ｓ３はデータの取得を終了し、処理装置Ｓ１に対してデータ送信する（１０３２）。処理装置Ｓ１はこのデータを受信し、１０１１で確保したイベント識別子１用のデータ格納領域に格納する。続いてイベント識別子２の「ライン進入」メッセージ１００２が流れ（１００２）、受信した処理装置Ｓ１は、イベント識別子１に対する収集処理は終了していないが、新たにイベント識別子２用のデータ格納領域を確保する（１０１３）。処理装置Ｓ２，Ｓ３ではメッセージ１００２をトリガとするデータ取得を開始する（１０２２，１０３３）。続いて処理装置Ｓ３がイベント識別子１に関連するデータ取得処理を終了し（１０２３）、処理装置Ｓ１に送信する。処理装置Ｓ１はこれを受信し（１０１４）、ＡＮＤ／ＯＲ判定３７４がＡＮＤ型で指定されている場合はデータが揃ったと判断して、アプリケーションプログラム２１１に渡す（１０１７）。以下同様に処理装置Ｓ３の取得データ（１０３４）を受信して確保したデータ格納領域に格納し（１０１５）、処理装置Ｓ２の取得データ（１０２４）を受信して格納し（１０１６）、アプリケーションプログラム２１１に渡す（１０１８）。アプリケーションプログラム２１１がＯＲ型でデータを受けるよう設定されている場合は、１０１１〜１０１６すべての時点で、受信した最新データ項目の値がアプリケーションプログラム２１１に渡される。
【００３７】
以上説明したように、本適用例によれば、アプリケーションプログラム２１１は、メッセージ８３１が発生した時点の処理装置Ｓ２，Ｓ３に分散して格納されているデータを取得できる。アプリケーションプログラム２１１は、データがどの処理装置にどのようなデータ構造によつて格納されているかを意識することなく、必要なデータ項目の値のみを取得できる。またメッセージ８３１の発生に連動するデータのみが渡されるため、不要なデータまで取得して内容判別して取捨選択する必要がない。またデータテーブル８２１及び８２２のデータ構造が変更されてもデータアクセス管理テーブル２３１、データ統合管理テーブル２３３など関連するテーブルの設定値を変更するだけでよく、アプリケーションプログラム２１１のソースコードを見直す必要がない。
【００３８】
図１４は、データ更新をイベントとする適用例を示す図である。システムは共通の伝送媒体に接続された処理装置１１０１（Ｓ１），１１０２（Ｓ３）及び１１０４（Ｓ４）から構成される。処理装置Ｓ３のフィルタリング処理２２２は、データテーブル１１１１の更新をトリガイベントとして、イベント連携データテーブル２３２を参照してデータテーブル１１１１のデータをメッセージ１１２１として他の処理装置Ｓ１及びＳ４へ送信する。処理装置Ｓ４のフィルタリング処理２２２は、このメッセージを他処理装置のデータ更新イベントとして受信し、イベント連携データテーブル２３２を参照してデータテーブル１１１２から関連するデータを収集してメッセージ１１２２を応答先の処理装置Ｓ１へ送信する。処理装置Ｓ１のデータ統合処理２２４は、データ統合管理テーブル２３３を参照して受信したデータを統合してアプリケーションプログラム２１１に渡す。この適用例のように、データテーブル１１１１の更新イベントをトリガとして関連するデータを処理装置Ｓ１へ送ることができる。データテーブル１１１１を更新したプログラムが処理装置Ｓ１へ更新イベントを送ったり、処理装置Ｓ１のアプリケーションプログラム２１１がデータテーブル１１１１の更新を監視したりする必要はなく、必要なデータが到着するのを待っているだけでよく、到着したデータを用いる処理に専念できる。
【００３９】
図１５（ａ）は、処理装置Ｓ１のデータ統合管理テーブル２３３の設定例を示す図である。データ統合されるバスケットは、レコード１２１１及びこれからリンクされるテーブルで定義される。バスケット名は「進捗」である。収集するイベントは、処理装置Ｓ３の「製造実績」というデータテーブル１１１１中のデータ項目「ロット実績値」の更新である。収集イベント及び収集データを受信したとき収集する項目は、収集項目テーブルのレコード１２３１〜１２３３に設定されている。レコード１２３１及び１２３２に定義する項目値は、処理装置Ｓ３の「製造実績」というデータテーブル１１１１中のそれぞれ「ロット番号」及び「ロット実績値」というデータ項目から取得するデータであり、これらの項目値はメッセージ１１２１に含まれている。レコード１２３３に定義する項目値は、処理装置Ｓ４の「製造計画」というデータテーブル１１１２の「計画量」というデータ項目の値である。
【００４０】
図１５（ｂ）は、処理装置Ｓ３のイベント連携データテーブル２３２の設定例を示す図である。レコード１２４１及び１２４２は、それぞれデータ統合管理テーブル２３３の収集項目テーブルのうち処理装置Ｓ３に関するレコード１２３１及び１２３２を抽出したものである。収集したデータの応答先は要求元の処理装置Ｓ１及びＳ４である。図１５（ｃ）は、処理装置Ｓ４のイベント連携データテーブル２３２の設定例を示す図である。レコード１２５１は同様にデータ統合管理テーブル２３３の収集項目テーブルのうち処理装置Ｓ４に関するレコード１２３３を抽出したものである。
【００４１】
以上メッセージをイベントとする場合の適用例及びデータ更新をイベントとする場合の適用例を示した。周期イベントの場合も同様にしてデータの収集が行なわれる。このようにしてイベント連携データテーブル２３２やデータ統合管理テーブル２３３を設定し、複数の処理装置に格納されているデータやメッセージデータを複合的に収集することができる。これらのテーブルの設定によつてアプリケーションプログラム２１１がデータを受け取ることができるため、媒体や処理装置を意識したりデータを逐次問い合わせて収集したり、メッセージやデータテーブルのデータ構造変更によってプログラムを見直しする必要がなくなり、開発の手間が大幅に軽減される。またイベントを検知してからデータを集めるのでなく、イベント発生によって複数の処理装置側が連携して指定したデータを送信してくれるため、リアルタイムのデータを取得でき、処理性能も向上する。
【００４２】
図１６は、データ統合処理を多段に用いる場合の適用例を示す図である。これは処理装置１３０１（Ｓ１）上のアプリケーションプログラム２１１が処理装置１３０２（Ｓ２）〜１３０８（Ｓ８）のデータを収集する場合の適用例である。処理装置Ｓ４のデータテーブル１３１４上のデータ及び処理装置Ｓ３のデータテーブル１３１３がそれぞれメッセージ１３２１，１３２２によって処理装置Ｓ２に送られ、処理装置Ｓ２のデータテーブル１３１２からもデータ項目の値を取得し、処理装置Ｓ２のデータ統合処理２２４によって統合される。収集されたデータをまとめたバスケットが１３４１である。バスケット１３４１は、処理装置Ｓ２のフィルタリング処理２２２に送られ、このバスケットを要求している処理装置Ｓ１にメッセージ１３２５として送られる。一方処理装置Ｓ７のデータテーブル１３１７上のデータ及び処理装置Ｓ８のデータテーブル１３１８上のデータは、転写メモリ１３２６により処理装置Ｓ６のデータテーブル１３１６に周期的に写像されている。このデータが処理装置Ｓ６のフィルタリング処理２２２を介してメッセージ１３２８として処理装置Ｓ１に送られ、バスケット１３４２として収集される。処理装置Ｓ１は、メッセージ１３２５によって処理装置Ｓ２から取得したバスケット１３４１とバスケット１３４２とを統合してバスケット１３４３を作成し、アプリケーションプログラム２１１に渡す。ここでバスケット１３４３はバスケット１３４１及び１３４２から作成されており、バスケットが処理装置内／外で多段に用いられている。処理装置Ｓ１から伝送媒体が直接繋がっていない処理装置Ｓ３，Ｓ４及びＳ７，Ｓ８のデータを通信が可能であれば直接取得するよう設定することも可能ではあるが、本適用例のように構成することによってバスケット１３４１及び１３４２を異なるイベントで収集し、バスケット１３４３で単一のバスケットとしてデータ統合できる。また処理装置Ｓ２〜Ｓ４の情報を処理装置Ｓ２がゲートウェイとして収集することによって処理装置Ｓ１のデータ統合管理テーブル２３３の設定を局所化できる。
【００４３】
図１７（ａ）は、処理装置Ｓ１が保持するデータ統合管理テーブル２３３の設定例を示す図である。レコード１４１１はバスケット１３４３を定義するものである。レコード１４１１は収集イベントの設定がない。すなわちバスケットの構成項目は自処理装置又は他の処理装置から送信されてくるものを受け取るものだけである。バスケット１３４３の構成項目は、収集項目テーブルのレコード１４２１及び１４２２によつて定義される。バスケット１３４３は「Ｎ２状態」というバスケット１３４１と「Ｎ３状態」というバスケット１３４２を統合したものである。バスケット「Ｎ２状態」のソースは、処理装置Ｓ２の「状態バスケット」という名称のバスケットであり、バスケット「Ｎ３状態」のソースは自処理装置のバスケット「Ｎｅｔ３状態」である。レコード１４１２はバスケット１３４２、すなわちバスケット「Ｎｅｔ３状態」を定義する。バスケット「Ｎｅｔ３状態」は処理装置Ｓ６の「状態テーブル」というデータテーブル１３１６が更新されたとき収集されるデータで構成される。バスケット「Ｎｅｔ３状態」の構成項目は、収集項目テーブルのレコード１４３１によって定義される。すなわち処理装置Ｓ６の「状態テーブル」の全項目である。レコード１４２１，１４２２及び１４３１において構成項目の型は、複数のデータ項目の集合である構造体を指定している。
【００４４】
図１７（ｂ）は、処理装置Ｓ２が保持するイベント連携データテーブル２３２の設定例を示す図である。レコード１４４１は、自処理装置の「状態バスケット」という名称のバスケット１３４１が更新されたときその全データ項目を処理装置Ｓ１に送信するよう設定する。ここで「状態バスケット」は、処理装置Ｓ２，Ｓ３及びＳ４から周期、更新等のイベントによって収集したデータを統合したバスケット１３４１であり、その構成項目の詳細は処理装置Ｓ２が保持するデータ統合管理テーブル２３３で定義される。
【００４５】
以上データ収集のいくつかの形態と収集したデータを統合した処理装置がバスケットをすぐにアプリケーションプログラムに渡す場合の適用例を示した。図１８は、プログラムの要求した時点で収集統合したデータを渡す場合のシステム構成を示す図である。処理装置１５０１は、処理装置１５０２及び処理装置１５０３からデータを収集し統合する。統合されたデータは処理装置１５０４のアプリケーションプログラム２１１や処理装置１５０５のアプリケーションプログラム２１１が利用するものである。ここで、処理装置１５０１と処理装置１５０４はそれぞれ伝送媒体１５１１、１５１２と接続しており、伝送媒体１５１１，１５１２はゲートウェイとなる処理装置やＷＡＮにより繋がっている。処理装置１５０５は通信装置１５２２を介して伝送媒体１５１３と繋がり、処理装置１５０１は通信装置１５２１を介して伝送媒体１５１３と繋がっている。伝送媒体１５１３が公衆回線であって通信装置１５２１，１５２２がモデム、伝送媒体１５１３が無線ＬＡＮであって通信装置１５２１，１５２２が無線ＬＡＮインタフェースである場合等である。処理装置１５０５は携帯情報端末などである。この場合、
（ａ）伝送路が不安定
（ｂ）伝送路上の通信負荷や通信性能の制約
（ｃ）処理装置１５０４や１５０５を別の作業に利用中で、処理装置１５０１からのデータを常時受信できない
等の理由で、処理装置１５０１で統合したデータをすぐに送信できない場合、または意図的にすぐには受信せず後から一括して収集した結果を受信したい場合がある。このような場合は本適用例のようにメッセージ１５４１及び１５４２によって処理装置１５０２及び１５０３からデータを収集し、統合してデータ１５４４としてバッファから退避する。このとき処理装置１５０１のデータ統合管理テーブル２３３では、収集したバスケットのデータ受渡方法３７３としてデマンド型を指定する。退避されたデータは、処理装置１５０４や処理装置１５０５が都合のよいときにメッセージとして送信され、各々のアプリケーションプログラム２１１が利用する。
【００４６】
【発明の効果】
以上述べたように本発明によれば、データが存在する処理装置の所在場所に係わらず、アプリケーションプログラムの必要とするデータをとり揃えてアプリケーションの必要とする時点に提供するので、アプリケーションプログラムがデータ収集のための問い合わせを行うなどのコーディングを備える必要がなくプログラム開発が容易になる。またデータ源の格納媒体やデータ構造、データを格納する処理装置、データ収集に利用する伝送媒体を変更してもそれによってアプリケーションプログラムを修正する必要がない。
【００４７】
さらにデータ収集の開始や終了のタイミングを指定したイベントの発生で制御することによって、きめ細かなデータ収集タイミングの制御が可能となる。
【図面の簡単な説明】
【図１】実施形態の分散処理システムのハードウェア構成図である。
【図２】実施形態の分散処理システムのソフトウェア構成図である。
【図３ａ】実施形態のデータ統合管理テーブル２３３のデータ構成を示す図である。
【図３ｂ】実施形態のデータ統合管理テーブル２３３のデータ構成を示す図（続き）である。
【図４】実施形態のデータアクセス管理テーブル２３１のデータ構成を示す図である。
【図５】実施形態のイベント連携データテーブル２３２のデータ構成を示す図である。
【図６】実施形態の送受信メッセージのデータ構成を示す図である。
【図７】実施形態のフィルタリング処理２２２の処理の流れを示すフローチャートである。
【図８ａ】実施形態のデータ統合処理２２４の処理の流れを示すフローチャートである。
【図８ｂ】実施形態のデータ統合処理２２４の処理の流れを示すフローチャート（続き）である。
【図８ｃ】実施形態のデータ統合処理２２４の処理の流れを示すフローチャート（続き）である。
【図９】実施形態の状態制御テーブル２３４のデータ構成を示す図である。
【図１０】実施形態の状態制御処理２２５の処理の流れを示すフローチャートである。
【図１１】メッセージ受信をイベントとする適用例の構成図である。
【図１２ａ】適用例のメッセージ８３１のユーザデータ部７１２に含まれるデータ項目を示す図である。
【図１２ｂ】適用例のデータ統合管理テーブル２３３の設定情報を示す図である。
【図１２ｃ】適用例の処理装置８０２，８０３のイベント連携データテーブル２３２の設定情報を示す図である。
【図１３】適用例についてのイベントシーケンスの例を示す図である。
【図１４】データ更新をイベントとする適用例の構成図である。
【図１５】適用例の処理装置１１０１のデータ統合管理テーブル２３３の設定情報を示す図である。
【図１６】データ統合処理を多段に用いる場合の適用例の構成図である。
【図１７】適用例のデータ統合管理テーブル２３３及びイベント連携データテーブル２３２の設定情報を示す図である。
【図１８】プログラムが要求した時点で統合したデータを渡す場合の例を説明する図である。
【符号の説明】
１１１〜１１４：処理装置、２１１，２１２：アプリケーションプログラム、２２２：フィルタリング処理、２２４：データ統合処理、２２５：状態制御処理、２３２：イベント連携データテーブル、２３３：データ統合管理テーブル、２３４：状態制御テーブル

Claims

複数の処理装置が伝送媒体を介して互いに接続され一連の処理を分散して行う分散処理システムにおいて複数の処理装置に分散して格納される情報をいずれかの処理装置によって統合する方法であって、
前記処理装置の備える第１の処理手段が、自処理装置について発生するイベント及び該伝送媒体を介して受信するメッセージイベントに応答して、前記処理装置の備える第１のテーブルであって発生するイベントに対応して収集するデータの名称及び収集データの送信先を格納する第１のテーブルを参照し自処理装置に格納されるデータを収集して該送信先に送信し、
前記処理装置の備える第２の処理手段が、他の処理装置又は前記第１の処理手段から収集データを受信し、前記処理装置の備える第２のテーブルであって統合されるデータの内訳を収集データのデータ名称ごとに分けて設定する第２のテーブルの設定に従って収集データを統合して前記処理装置内の要求元に渡すことを特徴とする分散情報の統合方法。
該要求元は第１の処理手段であることを特徴とする請求項１記載の分散情報の統合方法。
複数の処理装置が伝送媒体を介して互いに接続され一連の処理を分散して行う分散処理システムにおいて複数の処理装置に分散して格納される情報を収集する処理装置であって、
発生するイベントに対応して収集するデータの名称及び収集データの送信先を格納するテーブル手段と、
自処理装置について発生するイベント及び該伝送媒体を介して受信するメッセージイベントに応答して前記テーブル手段を参照し自処理装置に格納されるデータを収集して該送信先の他の処理装置に送信する処理手段とを有し、
前記他の処理装置は、統合されるデータの内訳を収集データのデータ名称ごとに分けて設定するテーブルを有し、前記処理装置から収集データを受信し自処理装置の有する前記テーブルの設定に従って収集データを統合して自処理装置内の要求元に渡すことを特徴とする分散情報を収集する処理装置。
複数の処理装置が伝送媒体を介して互いに接続され一連の処理を分散して行う分散処理システムにおいて複数の処理装置に分散して格納される情報を収集するとともに統合する処理装置であって、
発生するイベントに対応して収集するデータの名称及び収集データの送信先を格納する第１のテーブル手段と、
自処理装置について発生するイベント及び該伝送媒体を介して受信するメッセージイベントに応答して第１のテーブル手段を参照し自処理装置に格納されるデータを収集して該送信先に送信する第１の処理手段と、
統合されるデータの内訳を収集データのデータ名称ごとに分けて設定する第２のテーブル手段と、
他の処理装置又は第１の処理手段から収集データを受信し第２のテーブル手段の設定に従って収集データを統合して処理装置内の要求元に渡す第２の処理手段とを有することを特徴とする分散情報を統合する処理装置。
該要求元は第１の処理手段であることを特徴とする請求項４記載の分散情報を統合する処理装置。
複数の処理装置が伝送媒体を介して互いに接続され一連の処理を分散して行う分散処理システムにおいて複数の処理装置に分散して格納される情報を統合する処理装置であって、
統合されるデータの内訳を収集データのデータ名称ごとに分けて設定するテーブル手段と、
他の処理装置によって収集された収集データを前記他の処理装置から受信し前記テーブル手段の設定に従って収集データを統合して自処理装置内の要求元に渡す処理手段とを有し、
前記他の処理装置は、発生するイベントに対応して収集するデータの名称及び収集データの送信先を格納するテーブルを有し、自処理装置について発生するイベント及び該伝送媒体を介して受信するメッセージイベントに応答して自処理装置の有する前記テーブルを参照し自処理装置に格納されるデータを収集して該送信先の前記処理装置に送信することを特徴とする分散情報を統合する処理装置。