JPH10269252A

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

Info

Publication number: JPH10269252A
Application number: JP9075529A
Authority: JP
Inventors: Shigetoshi Samejima; 茂稔鮫嶋; Katsumi Kono; 克己河野; Hiroshi Wataya; 洋綿谷
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-03-27
Filing date: 1997-03-27
Publication date: 1998-10-09
Anticipated expiration: 2017-03-27
Also published as: US6038564A; JP3884821B2; US7333989B1

Abstract

(57)【要約】【課題】データを格納する処理装置や伝送媒体の存在
に係わらず、データ要求元プログラムが必要とするデー
タを収集し、データ統合して提供する。【解決手段】イベント連携データテーブル２３２は発
生するイベントに対応して収集するデータの名称及び収
集データの送信先を格納する。フィルタリング処理２２
２は自処理装置について発生するイベント及び伝送媒体
を介して受信するメッセージイベントに応答してイベン
ト連携データテーブル２３２を参照し自処理装置に格納
されるデータを収集して送信先に送信する。データ統合
管理テーブル２３３は統合されるデータの内訳を収集デ
ータのデータ名称ごとに分けて設定する。データ統合処
理２２４は、他の処理装置から収集データを受信しデー
タ統合管理テーブル２３３の設定に従って収集データを
統合してアプリケーションプログラム２１２に渡す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散処理システム
においてメッセージデータや各処理装置に格納されたデ
ータの集配信方法に係わり、特に複数の処理装置に分散
して格納される情報を収集して集約し、まとまった統合
データを組み立ててアプリケーションプログラムに提供
する分散情報の統合方法及び装置に関するものである。

【０００２】

【従来の技術】アプリケーションプログラムが利用する
データは、メッセージデータとして伝送されたデータも
しくは自処理装置又は他の処理装置のメモリやディスク
に格納されるデータである。アプリケーションプログラ
ムが処理を開始するタイミングは、他のアプリケーショ
ンプログラムからのメッセージ受信によって通知された
時点か、またはアプリケーションプログラムが自らその
時点を監視するものであった。すなわちメッセージを送
信する側のアプリケーションプログラムが受信側アプリ
ケーションプログラムに必要なデータを格納媒体から収
集して受信側の必要なデータ項目を揃えてメッセージデ
ータに載せて送信するか、または受信側のアプリケーシ
ョンプログラムが必要なデータを取得するまで周期的に
照会メッセージを送信し、データの格納媒体によって異
なるアクセス方法を用いて必要なデータを収集する方式
であった。

【０００３】一方アプリケーションプログラムが必要と
するデータ項目を抽出して提供する手段として、例えば
ネットワークコンピューティング（１９９４年６月号）
Ｐ．Ｐ．９−２３「ミドルウェアを使いこなす」に記載
されているリレーショナル・データベース（ＲＤＢ）を
管理するデータベース・マネージメント・システム（Ｄ
ＢＭＳ）がある。このシステムは実データを格納してい
るＲＤＢのテーブルからアプリケーションプログラムが
必要とするデータ項目を条件指定して抽出する機能を有
している。この方法によると、アプリケーションがデー
タを要求したときに要求したデータ項目の抽出作業が行
われ、抽出されたデータがアプリケーションに渡される
というものである。ここでアプリケーションに渡される
データの形式は、アプリケーションプログラムとの間の
インタフェースによって決められており、例えばテキス
ト形式や独自のオブジェクト形式である。このため抽出
されたデータを処理に利用するためにはＤＢＭＳの返し
たデータの形式を判断して書式を適宜変換する必要があ
った。

【０００４】

【発明が解決しようとする課題】アプリケーションプロ
グラムは、何らかのタイミングによってデータを取得
し、取得したデータを用いてその処理を行う。プログラ
ムごとに必要とするデータは異なるため、このタイミン
グや入力データはプログラムごとに決められる。入力さ
れるデータは、処理性能や容量に応じてメモリやディス
クに蓄えられているものか、メッセージの形式で伝送さ
れたものか、これら両者を組合わせたものである転写メ
モリの形式をもったものである。これらのデータは複数
のデータ項目から構成されており、プログラムは複数の
記憶媒体からそれぞれ一部のデータ項目を抽出しかつ複
数のデータ項目を統合して利用する。またデータを収集
するときのトリガとなるイベントの発生は、プログラム
が存在する処理装置で生じる場合もあるが、他の処理装
置で発生することも多い。

【０００５】従来技術によれば、自処理装置又は他の処
理装置に格納されるデータをアプリケーションプログラ
ムが要求しない限りこれを取得することはできなかっ
た。さらに複数の記憶媒体に格納されているデータは、
それぞれ媒体ごとに一部を抽出することしかできなかっ
た。このため処理の起動タイミングとなるメッセージを
送信するアプリケーションプログラム、または処理を行
うアプリケーションプログラムは、タイミングの検知と
通知、データの収集と統合を行う必要があった。タイミ
ングの通知に当っては、イベントを通知する処理をイベ
ント発生側に、このイベントを受信する処理をアプリケ
ーションプログラム側に作成する必要があった。または
アプリケーションプログラムが周期的にポーリングをか
ける等して自らイベントの発生を検知する必要があっ
た。データの収集と統合においても、転写メモリやディ
スクのように記憶媒体ごとに異なるアクセス法を介して
データを取得したり、あるいはイベント発生を検知した
時点でＲＤＢにアクセスし、必要とする最新データを収
集する必要があった。あるいはデータが必要でないとき
も常時データを収集し、データが必要になったときに収
集したデータの中から必要なものを抽出して利用する必
要があった。このためアプリケーションプログラムは、
本来行ないたい処理の他にイベント検知処理やデータ収
集処理のコーディングを備えなければならず、開発工数
が増えるという問題があった。

【０００６】またシステムの性能チューニングや改造を
行なうと、アプリケーションプログラムの配置を変えた
り、データの格納媒体や伝送媒体を変更したりする。ア
プリケーションプログラム自体を改造する場合は、必要
となるデータ項目やイベントが変更されたりする。これ
らの場合も、従来技術によるとアプリケーションプログ
ラムのソースコードを見直して主たる処理部以外のイベ
ント検知部やデータ収集部を修正する必要がある。イベ
ント送信側のプログラムがデータを収集／統合している
場合は、改造対象のプログラムにイベントを送っている
プログラムも見直す必要が生じ、改造における工数も大
きくなる。

【０００７】さらに制御システムにおいてある制御デー
タについてのイベント発生に連動して関連するデータを
収集する場合や異常発生時に関連するデータを収集する
場合があるが、イベント発生時の関係するデータが必要
であるにも係わらず、イベントを検知した後に１つ１つ
データを収集する方法ではデータのリアルタイム性が保
証できないといった問題もあった。特に遠隔地から複数
の伝送媒体を経由してデータを取得する場合には、伝送
路の通信負荷や伝送遅延のためにリアルタイム性の保証
は一層困難である。

【０００８】本発明の目的は、上記問題点を解決し、デ
ータを格納する処理装置の所在場所に係わらず、要求元
の必要とするデータをとり揃えて要求元の必要とするタ
イミングで提供することにある。併せてデータの格納媒
体やデータ収集のために使用する伝送媒体の変更から要
求元のアプリケーションプログラムを独立させることに
ある。

【０００９】

【課題を解決するための手段】本発明は、少なくとも１
台の第１の処理装置によってそれぞれイベントの発生を
トリガとしてあらかじめ設定された収集条件に従って自
処理装置に格納されるデータを収集してデータ要求元の
第２の処理装置へ送信し、第２の処理装置によって受信
した収集データをあらかじめ設定された統合条件に従っ
て統合する分散情報の統合方法を特徴とする。

【００１０】アプリケーションプログラムが必要とする
データは、すべてとり揃えて提供されるので、アプリケ
ーションプログラムが自処理装置又は他処理装置に問い
合わせを行ってデータを収集する必要がない。また必要
とするデータがすべて揃わず一部のデータが揃った時点
でデータを取得することも可能である。アプリケーショ
ンプログラムが受け取るデータは、アプリケーションプ
ログラムが指定したデータ形式になっており、データ源
の格納媒体やデータ構造、データを格納する処理装置の
存在、データ収集のために利用する伝送媒体の存在を意
識する必要はない。

【００１１】

【発明の実施の形態】以下に本発明の実施の形態につい
て図面を用いて詳細に説明する。

【００１２】図１は、本発明を適用するシステムの構成
例を示す図である。システムは、伝送媒体１０１を介し
て互いにデータの授受を行なう処理装置１１１〜１１３
とディスプレイやキーボードを有する端末装置１２１〜
１２３とを有する。処理装置１１１〜１１３には端末装
置１２１〜１２３が接続されている。ここで端末とは、
ディスプレイやキーボード、タッチパネル等のマンマシ
ンインタフェ−スを持ち、このインタフェ−スを介して
処理装置上で実行されるプログラムの制御を行ったりプ
ログラムの出力を参照したりする機能を有している。ま
た処理装置１１１〜１１３は主記憶装置（メモリ）のよ
うなデータ記憶媒体を持ち、処理装置１１１〜１１３に
接続されている外部記憶装置１３１〜１３３はフロッピ
ーディスクやハードディスク等のデータ記憶媒体を保持
している。ただしこれは必須ではなく外部記憶装置を持
たない処理装置も可能である。本発明において、処理装
置の格納しているデータとは、これら処理装置内の記憶
媒体や外部記憶装置に格納されているデータのことをい
う。また処理装置１１１は伝送媒体１０２を介して処理
装置１１４とデータの授受を行なう。このように処理装
置は複数の伝送媒体を接続可能であり、処理装置１１１
が仲介することによって処理装置１１４と処理装置１１
２，１１３がデータの授受を行うこともできる。

【００１３】図２は、処理装置１１１〜１１４内のソフ
トウェア構成を示す図である。アプリケーションプログ
ラム２１１，２１２は、自処理装置または他処理装置に
格納されたデータや伝送媒体１０１，１０２を介して受
信されるメッセージ中のデータを利用して業務処理を行
うプログラムである。データアクセス処理２２１は、自
処理装置に格納されたデータへのアクセスを管理するプ
ログラムであり、メモリ、外部記憶装置、転写メモリの
ように記憶媒体によらずデータのアクセスを可能とす
る。ここで転写メモリとは、ユーザがメモリに書き込ん
だ情報のコピーが自動的に別のメモリに転送されて利用
可能となるような方式をいう。通信管理２２３は、自処
理装置内のプログラム間通信及び伝送媒体１０１，１０
２を介する他の処理装置とのメッセージの送受信を管理
するプログラムである。データアクセス管理テーブル２
３１は、自処理装置に格納されているデータの名称とそ
の属性を格納する。イベント連携データテーブル２３２
は、あるイベントに対してどのデータ項目の値を取得し
てどの要求元に送る必要があるかを設定する。データ統
合管理テーブル２３３は、統合される各データの参照元
とデータ名を定義し、統合されたデータをアプリケーシ
ョンプログラム２１１，２１２に渡すときの出力オプシ
ョンなどを定義する。フィルタリング処理２２２は、自
処理装置内の周期タイマ、データ更新によるイベント発
生、他処理装置から受信したメッセージによるイベント
などイベントを検知し、イベント連携データテーブル２
３２、データアクセス管理テーブル２３１及びデータ統
合管理テーブル２３３を参照し、データアクセス処理２
２１を介する自処理装置内のデータの取得または統合さ
れたデータの取得を行い、通信管理２２３を介して取得
したデータを要求する他処理装置又は自処理装置のデー
タ統合処理２２４へ送信するプログラムである。データ
統合処理２２４は、他処理装置又は自処理装置のフィル
タリング処理２２２から送信されたデータを受信し、デ
ータ統合管理テーブル２３３及びデータアクセス管理テ
ーブル２３１を参照してデータの統合を行ってから統合
されたデータをアプリケーションプログラム２１１，２
１２又はフィルタリング処理２２２に渡すプログラムで
ある。状態制御テーブル２３４は、イベント連携データ
テーブル２３２に設定されるデータの収集及びデータ統
合管理テーブル２３３に設定されるデータの統合を開始
／終了する条件を設定する。状態制御処理２２５は、メ
ッセージ受信、データ更新などのイベントを検知し、状
態制御テーブル２３４を参照してデータ収集又はデータ
統合を開始／終了するタイミングを検知し、イベント連
携データテーブル２３２及びデータ統合管理テーブル２
３３の関連する制御情報を活性化するプログラムであ
る。

【００１４】図３ａ及び図３ｂは、データ統合管理テー
ブル２３３のデータ構成を示す図である。アプリケーシ
ョンプログラムが必要とするデータをまとめたものを以
後バスケットと呼ぶ。図３ａ（i）は、バスケット設定
テーブル３０１の構成を示す図である。バスケット設定
テーブル３０１の各レコードは、バスケット名３１１、
収集イベント３１２、収集項目テーブルインデックス３
１３、出力オプションインデックス３１４、状態管理テ
ーブルインデックス３１５及び活性状態３１６から構成
される。バスケット名３１１はバスケットを識別する名
称である。収集イベント３１２は種別と条件から構成さ
れる。種別は収集するイベントの種類を示す。例えばイ
ベントがメッセージ受信であることとそのメッセージの
内容を示すコード、イベントがデータ更新であることと
更新されたデータテーブルの名称、イベントが周期タイ
マによるものであることとタイマ割り込みの周期を示
す。条件はイベントの発生によってデータを収集すると
きの条件を示す。例えばイベントがメッセージ受信の場
合にはメッセージ中のデータ項目の値につける条件、イ
ベントがデータ更新である場合にはデータテーブル中の
更新されたデータ項目の名称である。イベントが周期タ
イマによるものである場合には条件がない。収集項目テ
ーブルインデックス３１３は、収集項目テーブルの格納
場所を指すインデックスであり、収集項目テーブルのデ
ータ構成は図３ａ（ii）に示される。出力オプションイ
ンデックス３１４は、出力オプションテーブルの格納場
所を指すインデックスであり、同テーブルのデータ構成
は図３ｂ（iii）に示される。また状態管理テーブルイ
ンデックス３１５は、状態管理テーブルの格納場所を指
すインデックスであり、同テーブルのデータ構成は図３
ｂ（iv）に示される。活性状態３１６はデータ統合処理
を行うか否かの状態を示す。

【００１５】図３ａ（ii）は、収集項目テーブルのデー
タ構成を示す図である。収集項目テーブルは、イベント
の発生に伴って収集するデータ項目と参照元を定義す
る。収集項目テーブルの各レコードは、バスケット項目
名３５１、型（書式）３５２、参照元３５３及び条件３
５４から構成される。バスケット項目名３５１は、バス
ケットを構成する項目として定義するデータ項目名であ
る。型（書式）３５２は、対応するデータ項目の型であ
り、長整数型、短整数型、文字型などを区別する。参照
元３５３はそのデータ項目を取得する元を定義するもの
であり、ソース名とデータ項目名から構成される。ソー
ス名は参照元のデータ名であり、たとえばイベントがメ
ッセージ受信である場合のそのメッセージの内容コー
ド、処理装置の識別子とデータテーブルの名称、処理装
置の識別子と作成されるバスケットのバスケット名３１
１などである。データ項目名はソース名で示されるデー
タ中でその値取得の対象とするデータ項目の名称であ
る。本実施形態では、ソースが特定の処理装置内にある
場合にその処理装置の識別子と該処理装置内のデータ名
によって指定するが、システム内でソースに一意の名称
をつけ、この名称を指定してもよい。条件３５４は参照
元３５３で指定するソースから指定のデータ項目の値を
取得するときの条件を指定するものであり、ソース名で
指定されるデータ中のデータ項目の値と収集イベント３
１２で指定したイベントによって受け取るデータ項目の
値との大小関係によって記述する。例えば「ソースデー
タ中のデータ項目”ＩＤ”が受信メッセージ中のデータ
項目”バーコード番号”と等しい」等である。

【００１６】図３ｂ（iii）は、出力オプションを定義
するテーブルのデータ構成を示す図である。このテーブ
ルは、収集したデータをアプリケーションプログラムに
渡すときに選択可能なオプションを設定する。本テーブ
ルの各レコードは、タイムアウト３７２、データ受渡方
法３７３、ＡＮＤ／ＯＲ判定３７４及びデータ要求元３
７５から構成される。タイムアウト３７２は、処理装置
がバスケットのデータ収集条件となるイベントを検知し
てから全データを受け取るまでの制限時間を示す。デー
タ受渡方法３７３はイベント型又はデマンド型を指定す
る。イベント型の場合はデータが揃うか又はタイムアウ
トしたとき直ちに揃ったデータをプログラムに渡す。デ
マンド型の場合は揃ったデータを蓄積しておき、プログ
ラムから要求があったときに渡す。ＡＮＤ／ＯＲ判定３
７４は、ＡＮＤ型又はＯＲ型を指定する。ＡＮＤ型の場
合はデータが揃うとは、バスケットを構成するすべての
項目の値を取得するか又はタイムアウトしたこととみな
す。ＯＲ型の場合はデータが揃うとは、バスケットを構
成するいずれかの項目の値を取得できたこととし、他の
構成項目の値はすでに取得している最新の値を用いるこ
ととする。データ要求元３７５はデータを渡す先のアプ
リケーションプログラムの識別子又はフィルタリング処
理２２２を示す。

【００１７】図３ｂ（iv）は、状態管理テーブルのデー
タ構成を示す図である。状態管理テーブルは、イベント
識別子に対応して収集の対象となるデータ項目の収集状
態を示す。状態管理テーブルの各レコードは、イベント
識別子３９１、バッファインデックス３９２、第１イベ
ント到着時刻３９３および収集判定マップ３９４から構
成される。イベント識別子３９１は、ＡＮＤ／ＯＲ判定
３７４がＡＮＤ型の場合に何回目のイベントかを示す番
号であり、１つのイベントに対して１つ又は複数の処理
装置から送られたデータの同期を取るための番号であ
る。バッファインデックス３９２は、各イベント識別子
３９１ごとにバスケットの構成項目データを格納するた
めに割り当てられたバッファのアドレスを示す。第１イ
ベント到着時刻３９３は、イベント識別子３９１で示さ
れるイベントを検知した時刻又は該イベント識別子に対
応する任意のバスケット構成項目を最初に受信した時刻
を格納する。第１イベント到着時刻３９３はタイムアウ
トか否かを判定するために参照される。収集判定マップ
３９４は、バスケットを構成する各項目ごとにデータを
取得したか否かをビットマップで示す。なおバスケット
構成項目の値がアプリケーションプログラムまたはフィ
ルタリング処理２２２に渡され、バッファを解放する時
点で該当するレコードが削除される。またＡＮＤ／ＯＲ
判定３７４がＯＲ型の場合には、状態管理テーブルのレ
コードは１つのみであり、プログラムにデータを渡した
後、バッファインデックス３９２の指すバッファ領域を
解放しない。

【００１８】図４は、データアクセス管理テーブル２３
１のデータ構成を示す図である。データアクセス管理テ
ーブル２３１は、自処理装置がどのようなデータを管理
していてそのデータがどのような構造をもつかを示すテ
ーブルである。ここで自処理装置が管理するデータに
は、他の処理装置と授受するメッセージデータも含まれ
る。データアクセス管理テーブル２３１の各エントリ
は、テーブル名４１１、媒体４１２及びデータ構造イン
デックス４１３から構成される。テーブル名４１１はデ
ータテーブルの名称を示す。媒体４１２はテーブル名４
１１で示されるデータがメッセージか、主記憶（メモ
リ）に格納されているものか、ディスク上に格納されて
いるものかを示す。データ構造インデックス４１３は該
データの構造を定義するテーブルの格納アドレスを示す
インデックスである。データ構造を定義するテーブル
は、データ項目４３１及び型４３２から構成される。デ
ータ項目４３１は当該データを構成するデータ項目の名
称、型４３２はその型であり、型（書式）３５２と同じ
である。

【００１９】図５は、イベント連携データテーブル２３
２のデータ構成を示す図である。イベント連携データテ
ーブル２３２は、イベントが発生したときに自処理装置
内のどのデータを収集して送信すべきかを設定するテー
ブルである。すなわちこのテーブルは、自処理装置に格
納されているデータおよび自処理装置で作成されるバス
ケットが参照元となっている場合のバスケットをまとめ
たものである。テーブルの図示する１行が１レコードで
ある。イベント連携データテーブル２３２の各レコード
は、収集イベント４５１、応答先４５２、データ名４５
３、収集データ項目４５４、収集条件４５５及び活性状
態４５６から構成される。収集イベント４５１は、デー
タを収集するトリガとなるイベントを設定するものであ
り、収集イベント３１２と同様の内容である。応答先４
５２は、収集したデータ項目の値を送る相手処理装置の
識別子を指定する。例えば自処理装置のデータ更新イベ
ントを通知する必要のある処理装置の識別子を指定す
る。データ名４５３、収集データ項目４５４及び収集条
件４５５は、参照元３５３及び条件３５４と同じであ
る。すなわちイベント連携データテーブル２３２は、参
照元３５３及び条件３５４を参照元の処理装置について
まとめたものである。活性状態４５６は、対応するレコ
ードに指定されたデータ収集と送信を行うか否かの状態
を示す。イベント連携データテーブル２３２は自処理装
置が参照元となり得るデータを収集イベントごと、応答
先ごとにまとめたものである。

【００２０】図６（ａ）は、通信管理２２３が処理装置
間や処理装置内で送受信するメッセージのデータ構成を
示す図である。メッセージは、通信制御のためのメッセ
ージヘッダ７１１と、アプリケーションプログラム２１
１、フィルタリング処理２２２及びデータ統合処理２２
４が参照するユーザデータ部７１２から構成される。メ
ッセージヘッダ７１１は、通信用の制御コード７２１、
宛先識別コード７２２、送信側処理装置を識別するコー
ド７２３及びイベント識別子７２４から構成される。イ
ベント識別子７２４は、処理装置が送信するメッセージ
を時系列的に識別するための通番であり、例えば処理装
置の識別子と該処理装置内の通番の組合せによって表現
される。イベント識別子７２４によって同一処理装置か
つ同一プログラムが発行するメッセージであっても発生
順序を識別できる。宛先識別コード７２２として例えば
特開昭５６−１１１３５３号公報に記載されるような内
容コードを用いてもよい。ユーザデータ部７１２は、一
般に複数のデータ項目から構成され、各データ項目の値
を含む。メッセージを受信した処理装置は、データアク
セス管理テーブル２３１を参照することによって各デー
タ項目の型を取得し、各データ項目の値を切り出すこと
が可能である。また通信管理２２３がデータアクセス管
理テーブル２３１を参照して各データ項目の型を認識
し、自処理装置で処理できるようにデータ項目値のバイ
トオーダーを変換することも可能である。

【００２１】図６（ｂ）は、フィルタリング処理２２２
が発生したイベントに関連して収集したデータを要求元
に送るときのユーザデータ部７１２のデータ構成を示す
図である。収集イベント種別７３１は、収集イベント３
１２の種別、すなわち収集イベント４５１の種別と同じ
である。収集イベント識別子７３２は、イベント発生元
のイベント識別子を設定する。例えばイベントがメッセ
ージ受信である場合には受信したメッセージのイベント
識別子７２４を設定する。イベントが周期タイマによる
ものである場合には自処理装置内の通番等を設定する。
イベントがデータ更新である場合には、更新されたデー
タを格納している処理装置の処理装置内通番等を設定す
る。このデータ更新を通知するメッセージ受信をトリガ
として関連するデータを収集する処理装置では、この更
新データに付けられた収集イベント識別子７３２を指定
する。応答先７３３はデータ送信先の相手処理装置の識
別子である。ソース名７３４は、参照元のデータ名であ
り、例えば処理装置の識別子とデータテーブルの名称な
どである。収集データ項目リスト７３５は、収集したデ
ータ項目名のリストを設定する。収集データ７３６は、
収集データ項目リスト７３５の各データ項目に対応して
その値を設定する。図６（ｂ）に示すデータ構成は一例
であり、同一イベントに関する複数の収集データを相乗
りによってまとめて送信したり、複数の応答先への収集
データをまとめて送信するためのデータ構成としてもよ
い。

【００２２】フィルタリング処理２２２が収集したデー
タを応答先に送るときのメッセージ以外のフィルタリン
グ処理２２２及びデータ統合処理２２４が受信するメッ
セージは、メッセージヘッダ７１１又はユーザデータ部
７１２の内容によって収集データメッセージと区別され
る。図６（ｂ）のデータ形式に準じてもよい。例えばイ
ベント識別子７２４と収集イベント識別子７３２が同一
内容であるメッセージをデータ収集のトリガとするメッ
セージとして識別するなどである。また処理装置の特定
のポートから受信する制御データ又はメッセージは、ポ
ートの識別子によって特定のメッセージと識別すること
が可能である。

【００２３】図７は、フィルタリング処理２２２の処理
の流れを示す図である。フィルタリング処理２２２は、
イベント発生を待つ（ステップ５０１）。メッセージ受
信イベントの場合には、通信管理２２３がメッセージを
受信してフィルタリング処理２２２を起動する。自処理
装置内のデータ更新イベントの場合には、データアクセ
ス処理２２１やデータ統合処理２２４がフィルタリング
処理２２２を起動して更新データを渡す。データ統合処
理２２４が更新データを送る場合とは、データを統合し
たバスケットをフィルタリング処理２２２に渡す場合で
ある。他の処理装置のデータ更新イベントの場合には、
通信管理２２３が更新データを含むメッセージを受信し
てフィルタリング処理２２２を起動する。また自処理装
置に直接又は伝送媒体を介して接続される計測器やセン
サから送られる制御データの受信もイベント発生とな
る。周期イベントの場合には、周期タイマによりタイマ
割り込みが発生し、フィルタリング処理２２２を起動す
る（ステップ５５１）。フィルタリング処理２２２がイ
ベントを検知すると、発生したイベントの種別と付随す
るデータを取得する（ステップ５０２）。次にイベント
連携データテーブル２３２を参照して発生したイベント
に関連して取得する必要のあるデータ又はバスケットが
あるか否かを検索する（ステップ５０３）。すなわち発
生したイベントの種別及び付随するデータと収集イベン
ト４５１の収集条件とを突き合わせて両者が合致するレ
コードがあるか否かを判定する。ただしここで検索の対
象とするレコードは、活性状態４５６が活性状態として
設定されているレコードである。その結果、放出する
（送信する）レコードが見つからない場合（ステップ５
０４Ｎ）には、ステップ５０１に戻る。該当するレコー
ドが見つかった場合（ステップ５０４Ｙ）には、そのレ
コードのデータ名４５３で示されるデータのデータ項目
４５４について収集条件４５５を満足するデータ項目値
を取得する（ステップ５０５）。収集条件４５５がなけ
れば無条件である。データ取得に当っては、データアク
セス管理テーブル２３１を参照して該当するデータの媒
体４１２及び該当するデータ項目の型４３２を取得して
からデータアクセス処理２２１を起動してデータを取得
する。取得するデータがバスケットである場合には、デ
ータ統合管理テーブル２３３のバスケット名３１１及び
バスケット項目名３５１を参照してその型３５２を取得
する。放出すべきデータが複数ある場合にはすべてのデ
ータを同様に取得する。次に取得したデータに基づいて
送信データを作成する（ステップ５０６）。応答先７３
３には該当するレコードの応答先４５２を、ソース名７
３４にはそのデータ名４５３を、収集データ項目リスト
７３５には収集データ項目４５４を格納する。イベント
識別子７２４にはフィルタリング処理２２２が生成した
識別子を格納する。最後に通信管理２２３を介して他の
処理装置又は自処理装置内のデータ統合処理２２４へデ
ータを送信し（ステップ５０７）、ステップ５０１に戻
る。

【００２４】図８ａ、図８ｂ及び図８ｃは、データ統合
処理２２４の処理の流れを示すフローチャートである。
データ統合処理２２４は、他の処理装置又は自処理装置
からのデータ到着を待つ（ステップ６０１）。通信管理
２２３を介してデータ又はメッセージを受信すると（ス
テップ６０２）、データ統合管理テーブル２３３を参照
して受信したデータを要求しているバスケットがあるか
否か判断する（ステップ６０３）。すなわち受信したメ
ッセージが収集データである場合にそのソース名７３４
及び収集データ項目リスト７３５のデータ項目名とデー
タ統合管理テーブル２３３の参照元３５３とを突き合わ
せて受信したデータをバスケット構成項目とするバスケ
ットが存在するか否か判断する。このとき収集データ７
３６の型は、バスケット構成項目の型３５２を参照する
ことによつて得られる。該当するバスケットが存在しな
い場合（ステップ６０３Ｎ）には、データ統合管理テー
ブル２３３を参照して受信したデータを収集イベントと
するバスケットがあるか否かを判断する（ステップ６２
１）。すなわち受信したメッセージの収集イベント種別
７３１（及び収集データ７３６）とデータ統合管理テー
ブル２３３の収集イベント３１２とを突き合わせて収集
条件を満足するバスケットが存在するか否かを判断す
る。このとき収集データ７３６の型は、データアクセス
管理テーブル２３１のソース名７３４に対応するデータ
名４１１の収集データ項目リスト７３５のデータ項目に
対応するデータ項目４３１の型４３２を参照することに
よって得られる。該当するバスケットが存在するとき、
図８ｂ（ii）に示す収集状態の設定または更新を行う
（ステップ６０５）。その後ステップ６０１に戻る。該
当するバスケットが存在しないときには、ただちにステ
ップ６０１に戻る。受信したデータを要求しているバス
ケットが存在する場合（ステップ６０３Ｙ）には、該バ
スケットに必要なデータ項目を受信メッセージから抽出
する（ステップ６０４）。すなわち収集データ７３６か
ら少なくとも１つのデータ項目の値を抽出する。その後
図８ｂ（ii）に示す状態管理テーブル上の収集状態の設
定または更新を行う（ステップ６０５）。なおステップ
６０３及びステップ６２１のデータ統合管理テーブル２
３３検索に当っては、活性状態３１６が活性状態に設定
されているバスケットのみを検索対象とする。この後ス
テップ６０４で抽出したデータ項目値を当該バスケット
の状態管理テーブルインデックス３１５によって指され
る状態管理テーブルのバッファインデックス３９２の指
すバツファ領域の中の当該データ項目値の格納場所に格
納する（ステップ６０６）。

【００２５】次にバスケットの構成項目が揃ったか否か
を判断する（ステップ６０７）。データの収集状態は当
該バスケットの状態管理テーブル収集判定マツプ３９４
を参照することによつて判定される。またデータが揃う
ときの条件は、当該バスケットの出力オプションを設定
するテーブルのＡＮＤ／ＯＲ判定３７４によって決ま
る。ＡＮＤ／ＯＲ判定３７４がＡＮＤ型の場合には、す
べての構成項目を取得したときが揃った時点である。Ａ
ＮＤ／ＯＲ判定３７４がＯＲ型の場合には、いずれか１
つの構成項目を取得したときが揃った時点であり、他の
構成項目は、過去に取得した構成項目のうちバッファ上
にある最新のデータがその値として用いられる。データ
が揃ったと判断した場合（ステップ６０７Ｙ）には、処
理６３２に移り、要求元にデータを渡す。データが揃っ
ていない場合（ステップ６０７Ｎ）には、ステップ６０
１に戻る。処理６３２では当該バスケットの出力オプシ
ョンテーブルを参照してデータ受渡方法３７３がイベン
ト型がデマンド型かを判断する（ステップ６０８）。イ
ベント型の場合（ステップ６０８Ｙ）には、当該バスケ
ットのデータ要求元３７５が指定するアプリケーション
プログラム又はフィルタリング処理２２２にデータを渡
す（ステップ６０９）。デマンド型の場合（ステップ６
０８Ｎ）には、バッファインデックス３９２が指す当該
バスケットのバッファ領域の内容をキューに格納する
（ステップ６２５）。アプリケーションプログラムはこ
のキューからデータを取り出すことができる。ステップ
６０９及び６２５の処理の後に図８ｂ（iii）に示す状
態管理テーブルとバッファの整理を行って（ステップ６
１０）、ステップ６０１に戻る。

【００２６】図８ｂ（ii）は、状態管理テーブルの設定
及び更新処理の流れを示すフローチャートである。当該
バスケットの状態管理テーブルを検索して受信したメッ
セージの収集イベント識別子７３２をもつレコードがあ
るか否か判定する（ステップ６４１）。出力オプション
テーブルのＡＮＤ／ＯＲ判定３７４がＡＮＤ型の場合に
は、イベント識別子３９１によって出力オプションテー
ブルを検索する。ＯＲ型の場合には出力オプションテー
ブルはただ１つのレコードをもつのでそのレコードのイ
ベント識別子３９１によって該当するレコードか否かを
判定する。該当するレコードが存在しない場合（ステッ
プ６４１Ｙ）には、テーブルにレコードを追加し（ステ
ップ６４２）、そのレコードのイベント識別子３９１に
受信したメッセージの収集イベント識別子７３２を追加
し、バッファ領域を確保してそのインデックスをバッフ
ァインデックス３９２に設定する（ステップ６４３）。
またイベントが到着した時刻を第１イベント到着時刻３
９３に設定する（ステップ６４４）。その後、収集判定
マップ３９４のうち取得したバスケット項目に対応する
ビットを取得済みに設定する（ステップ６４５）。該当
するレコードが存在する場合（ステップ６４１Ｎ）に
は、ステップ６４５の処理だけを行う。

【００２７】図８ｂ（iii）は、状態管理テーブルとバ
ッファの整理を行う処理の流れを示すフローチャートで
ある。まず当該バスケットの出力オプションテーブルの
ＡＮＤ／ＯＲ判定３７４がＡＮＤ型か否かを判定する
（ステップ６５１）。ＡＮＤ型の場合（ステップ６５１
Ｙ）には、当該バスケットの項目値はすべて不要となる
ため状態管理テーブルのバッファインデックス３９２に
よつて指されるバッファ領域をすべて解放し（ステップ
６５２）、当該状態管理テーブルのレコードのうち該当
するイベント識別子をもつレコード内容をクリアする
（ステップ６５３）。ＯＲ型の場合（ステップ６５１
Ｎ）には何もしない。

【００２８】図８ｃ（iv）は、タイムアウト監視処理の
流れを示すフローチャートである。本処理のプログラム
が周期的に起動されると（ステップ６６１）、データ統
合管理テーブル２３３のバスケット設定テーブル３０１
に格納されているバスケットのレコードをすべて処理し
たか否か判定する（ステップ６６２）。まだ未処理のバ
スケットがあれば（ステップ６６２Ｙ）、ポインタを次
のバスケットのレコードに位置づけて（ステップ６６
３）、該バスケットの状態管理テーブルのすべてのレコ
ードを処理したか否か判定する（ステップ６６４）。ま
だ未処理のレコードがあれば（ステップ６６４Ｙ）、ポ
インタを状態管理テーブルの次のレコードに位置づけて
現在時刻を取得し（ステップ６６５）、当該バスケット
のタイムアウト設定３７２に照らして現在時刻と第１イ
ベント到着時刻３９３との差がタイムアウトとなったか
否か判定する（ステップ６６６）。タイムアウトしたと
き（ステップ６６６Ｙ）、図８ａのデータ受渡処理６３
２を実行し（ステップ６６７）、ステップ６６４に戻
る。当該レコードがタイムアウトしていなければ（ステ
ップ６６６Ｎ）、ステップ６６４に戻る。状態管理テー
ブルのすべてのレコードを処理したか又はテーブルがク
リアされていれば（ステップ６６４Ｎ）、ステップ６６
２に戻る。すべてのバスケットの処理を終了したとき
（ステップ６６２Ｎ）、タイムアウト監視処理を終了す
る。タイムアウト監視処理によって他処理装置の障害等
によりデータ収集が完了しない状態を監視する。

【００２９】図９は、状態制御テーブル２３４のデータ
構成を示す図である。テーブルの図示する１行が１レコ
ードである。イベント１６１１は、収集イベント３１２
及び収集イベント４５１と同様である。開始／終了１６
１２は、分散情報統合処理の開始に関するイベントか、
終了に関するイベントかを示す。条件回数１６１３は、
イベント１６１１が何回検知されたら開始／終了１６１
２に示す開始又は終了とするか、その回数を設定する。
イベントカウンタ１６１４は、現在の検知回数を示す。
制御対象１６１５は、開始／終了制御の対象がバスケッ
トか収集データかを示す。制御対象インデックス１６１
６は、制御対象の設定されているレコードへのポインタ
を示す。バスケットの場合はバスケット設定テーブル３
０１のレコードを指し、収集データの場合はイベント連
携データテーブル２３２のレコードを指す。

【００３０】図１０は、状態制御処理２２５の処理の流
れを示すフローチャートである。イベントの受信を待ち
（ステップ１７０１）、イベントを受信したとき、イベ
ント種別と付随するデータを取得する（ステップ１７０
２）。次に状態制御テーブル２３４を検索してこのイベ
ントで状態制御するよう設定されているレコードがある
か否か判定する（ステップ１７０３）。検索はイベント
種別と付随データを満足するイベント１６１１をもつレ
コードを探す処理である。該当するレコードがなければ
（ステップ１７０３Ｎ）、ステップ１７０１に戻る。該
当するレコードがあれば（ステップ１７０３Ｙ）、その
レコードのイベントカウンタ１６１４に１を加えること
によってこれを更新し（ステップ１７０４）、条件回数
１６１３と更新されたイベントカウンタ１６１４とを比
較する（ステップ１７０５）。両者が等しくない（条件
を満たさない）場合（ステップ１７０６Ｎ）には、ステ
ップ１７０３に戻る。条件を満たす場合（ステップ１７
０６Ｙ）には、制御対象１６１５及び制御対象インデッ
クス１６１６が指すレコードの活性状態３１６又は活性
状態４５６を更新する（ステップ１７０７）。すなわち
状態制御テーブル２３４の現在処理中のレコードの開始
／終了１６１２が開始を指定していれば、制御対象イン
デックス１６１６が指すレコードの活性状態３１６又は
活性状態４５６を活性状態にする。開始／終了１６１２
が終了を指定していれば、制御対象インデックス１６１
６が指すレコードの活性状態３１６又は活性状態４５６
を非活性状態にする。最後に処理中のレコードのイベン
トカウンタ１６１４をリセットし（ステップ１７０
８）、ステップ１７０３に戻る。状態制御処理２２５に
よってデータ収集の開始／終了がイベントの発生回数又
はデータ収集回数によって制御でき、きめ細かなデータ
収集制御が可能である。例えば異常発生イベントに連動
して装置状態などのデータを収集し始め、無人運転中の
状態トレンドについての情報を収集するといった応用も
可能である。

【００３１】以上説明した方式及び構成を利用して分散
情報を統合化する適用例について以下説明する。

【００３２】図１１は、メッセージ受信をイベントとす
る適用例を示す図である。システムは共通の伝送媒体に
接続された処理装置８０１，８０２及び８０３から構成
される。伝送媒体を介してブロードキャストされるメッ
セージ８３１をトリガイベントとして、処理装置８０２
のフィルタリング処理２２２は、その外部記憶装置（デ
ィスク）８１１に格納されているテーブルデータ８２１
中のデータを収集し、処理装置８０３のフィルタリング
処理２２２は、その内部記憶装置（メモリ）に格納され
ているテーブルデータ８２２を収集し、それぞれメッセ
ージ８４１及び８４２として処理装置８０１に送信す
る。処理装置８０１のデータ統合処理２２４は、メッセ
ージ８３１，８４１及び８４２を統合してバスケットを
構成するデータ８４３を作成し、アプリケーションプロ
グラム２１１に渡す。

【００３３】図１２ａ（i）は、メッセージ８３１のユ
ーザデータ部７１２に含まれるデータ項目のリストを示
す図である。図１２ａ（ii）は、処理装置８０２が保有
するテーブルデータ８２１のデータ構成を示し、各レコ
ードは部品ＩＤをキーとする図示のようなデータ項目か
ら構成される。図１２ａ（iii）は、処理装置８０３が
格納するテーブルデータ８２２のデータ構成を示し、ロ
ット番号（ＬｏｔＮｏ．）をキーとする図示のような
データ項目から構成される。

【００３４】図１２ｂは、処理装置８０１のデータ統合
管理テーブル２３３の設定例を示す図である。データ統
合されるバスケットは、レコード９２１及びこれからリ
ンクされるテーブルで定義されている。バスケット名は
「生産指示」である。収集するイベントは、宛先識別コ
ード７２２が「ライン進入」であるメッセージ（Ｍｓ
ｇ）のうち部品ＩＤが１０００より大きいものである。
収集イベントの収集条件を満足するメッセージを受信し
たとき及び収集データを受信したとき収集する項目は、
収集項目テーブルのレコード９４１〜９４５に設定され
ている。レコード９４１及び９４２に定義する項目値は
収集イベントとなる受信メッセージから取得するデータ
である。レコード９４３及び９４４に定義する項目値
は、処理装置８０２（Ｓ２）の「製造条件」というテー
ブルデータ８２１のそれぞれ「条件値１」および「条件
値２」というデータ項目の値である。ただし「条件値
１」は「製造条件」の部品ＩＤが収集イベントメッセー
ジの部品ＩＤに等しいという条件を満たすものであり、
「条件値２」は「条件値１」の条件に加えて質基準が収
集イベントメッセージの品質基準値より大きいか等しい
という条件を満たすものである。同様にレコード９４５
に定義する項目値は、処理装置８０３（Ｓ３）の「製造
実績」というテーブルデータ８２２の「ロツト実績値」
というデータ項目の値である。ただし「ロツト実績値」
はテーブルデータ８２２のレコードのうち「ロット番
号」が収集イベントメッセージのロット番号に等しいよ
うなレコードのロツト実績値である。各バスケット構成
項目は、型（書式）のフィールドに示すように長整数型
又は６バイト文字型としてデータ要求元３７５に示すプ
ログラムに渡される。

【００３５】図１２ｃ（vi）は、処理装置Ｓ２のイベン
ト連携データデータテーブル２３２の設定例を示す図で
ある。レコード９５１及び９５２は、それぞれデータ統
合管理テーブル２３３の収集項目テーブルのうち処理装
置Ｓ２に関するレコード９４３及び９４４を抽出したも
のである。収集イベントの収集条件は、処理装置Ｓ１の
収集イベントの収集条件と同じである。収集したデータ
の応答先は、要求元の処理装置Ｓ１である。図１２ｃ
（vii）は、処理装置Ｓ３のイベント連携データテーブ
ル２３２の設定例を示す図である。レコード９６１は同
様にデータ統合管理テーブル２３３の収集項目テーブル
のうち処理装置Ｓ３に関するレコード９４５を抽出した
ものである。

【００３６】図１３は、本適用例についてのイベントシ
ーケンスの例を示す図である。図は収集イベントのメッ
セージ８３１を受信した後の処理装置Ｓ１，Ｓ２及びＳ
３の動作を示す。始めにイベント識別子１の「ライン進
入」メッセージ１００１が伝送媒体を流れると、処理装
置Ｓ１はデータ格納領域を確保し、このメッセージから
データ項目「部品ＩＤ」及び「ロット番号」を取得し、
そのデータ格納領域に格納する（１０１１）。同時に処
理装置Ｓ２はデータ項目「条件値１」及び「条件値２」
の取得を開始し（１０２１）、処理装置Ｓ３はデータ項
目「ロット実績値」の取得を開始する（１０３１）。処
理装置Ｓ３はデータの取得を終了し、処理装置Ｓ１に対
してデータ送信する（１０３２）。処理装置Ｓ１はこの
データを受信し、１０１１で確保したイベント識別子１
用のデータ格納領域に格納する。続いてイベント識別子
２の「ライン進入」メッセージ１００２が流れ（１００
２）、受信した処理装置Ｓ１は、イベント識別子１に対
する収集処理は終了していないが、新たにイベント識別
子２用のデータ格納領域を確保する（１０１３）。処理
装置Ｓ２，Ｓ３ではメッセージ１００２をトリガとする
データ取得を開始する（１０２２，１０３３）。続いて
処理装置Ｓ３がイベント識別子１に関連するデータ取得
処理を終了し（１０２３）、処理装置Ｓ１に送信する。
処理装置Ｓ１はこれを受信し（１０１４）、ＡＮＤ／Ｏ
Ｒ判定３７４がＡＮＤ型で指定されている場合はデータ
が揃ったと判断して、アプリケーションプログラム２１
１に渡す（１０１７）。以下同様に処理装置Ｓ３の取得
データ（１０３４）を受信して確保したデータ格納領域
に格納し（１０１５）、処理装置Ｓ２の取得データ（１
０２４）を受信して格納し（１０１６）、アプリケーシ
ョンプログラム２１１に渡す（１０１８）。アプリケー
ションプログラム２１１がＯＲ型でデータを受けるよう
設定されている場合は、１０１１〜１０１６すべての時
点で、受信した最新データ項目の値がアプリケーション
プログラム２１１に渡される。

【００３７】以上説明したように、本適用例によれば、
アプリケーションプログラム２１１は、メッセージ８３
１が発生した時点の処理装置Ｓ２，Ｓ３に分散して格納
されているデータを取得できる。アプリケーションプロ
グラム２１１は、データがどの処理装置にどのようなデ
ータ構造によつて格納されているかを意識することな
く、必要なデータ項目の値のみを取得できる。またメッ
セージ８３１の発生に連動するデータのみが渡されるた
め、不要なデータまで取得して内容判別して取捨選択す
る必要がない。またデータテーブル８２１及び８２２の
データ構造が変更されてもデータアクセス管理テーブル
２３１、データ統合管理テーブル２３３など関連するテ
ーブルの設定値を変更するだけでよく、アプリケーショ
ンプログラム２１１のソースコードを見直す必要がな
い。

【００３８】図１４は、データ更新をイベントとする適
用例を示す図である。システムは共通の伝送媒体に接続
された処理装置１１０１（Ｓ１），１１０２（Ｓ３）及
び１１０４（Ｓ４）から構成される。処理装置Ｓ３のフ
ィルタリング処理２２２は、データテーブル１１１１の
更新をトリガイベントとして、イベント連携データテー
ブル２３２を参照してデータテーブル１１１１のデータ
をメッセージ１１２１として他の処理装置Ｓ１及びＳ４
へ送信する。処理装置Ｓ４のフィルタリング処理２２２
は、このメッセージを他処理装置のデータ更新イベント
として受信し、イベント連携データテーブル２３２を参
照してデータテーブル１１１２から関連するデータを収
集してメッセージ１１２２を応答先の処理装置Ｓ１へ送
信する。処理装置Ｓ１のデータ統合処理２２４は、デー
タ統合管理テーブル２３３を参照して受信したデータを
統合してアプリケーションプログラム２１１に渡す。こ
の適用例のように、データテーブル１１１１の更新イベ
ントをトリガとして関連するデータを処理装置Ｓ１へ送
ることができる。データテーブル１１１１を更新したプ
ログラムが処理装置Ｓ１へ更新イベントを送ったり、処
理装置Ｓ１のアプリケーションプログラム２１１がデー
タテーブル１１１１の更新を監視したりする必要はな
く、必要なデータが到着するのを待っているだけでよ
く、到着したデータを用いる処理に専念できる。

【００３９】図１５（ａ）は、処理装置Ｓ１のデータ統
合管理テーブル２３３の設定例を示す図である。データ
統合されるバスケットは、レコード１２１１及びこれか
らリンクされるテーブルで定義される。バスケット名は
「進捗」である。収集するイベントは、処理装置Ｓ３の
「製造実績」というデータテーブル１１１１中のデータ
項目「ロット実績値」の更新である。収集イベント及び
収集データを受信したとき収集する項目は、収集項目テ
ーブルのレコード１２３１〜１２３３に設定されてい
る。レコード１２３１及び１２３２に定義する項目値
は、処理装置Ｓ３の「製造実績」というデータテーブル
１１１１中のそれぞれ「ロット番号」及び「ロット実績
値」というデータ項目から取得するデータであり、これ
らの項目値はメッセージ１１２１に含まれている。レコ
ード１２３３に定義する項目値は、処理装置Ｓ４の「製
造計画」というデータテーブル１１１２の「計画量」と
いうデータ項目の値である。

【００４０】図１５（ｂ）は、処理装置Ｓ３のイベント
連携データテーブル２３２の設定例を示す図である。レ
コード１２４１及び１２４２は、それぞれデータ統合管
理テーブル２３３の収集項目テーブルのうち処理装置Ｓ
３に関するレコード１２３１及び１２３２を抽出したも
のである。収集したデータの応答先は要求元の処理装置
Ｓ１及びＳ４である。図１５（ｃ）は、処理装置Ｓ４の
イベント連携データテーブル２３２の設定例を示す図で
ある。レコード１２５１は同様にデータ統合管理テーブ
ル２３３の収集項目テーブルのうち処理装置Ｓ４に関す
るレコード１２３３を抽出したものである。

【００４１】以上メッセージをイベントとする場合の適
用例及びデータ更新をイベントとする場合の適用例を示
した。周期イベントの場合も同様にしてデータの収集が
行なわれる。このようにしてイベント連携データテーブ
ル２３２やデータ統合管理テーブル２３３を設定し、複
数の処理装置に格納されているデータやメッセージデー
タを複合的に収集することができる。これらのテーブル
の設定によつてアプリケーションプログラム２１１がデ
ータを受け取ることができるため、媒体や処理装置を意
識したりデータを逐次問い合わせて収集したり、メッセ
ージやデータテーブルのデータ構造変更によってプログ
ラムを見直しする必要がなくなり、開発の手間が大幅に
軽減される。またイベントを検知してからデータを集め
るのでなく、イベント発生によって複数の処理装置側が
連携して指定したデータを送信してくれるため、リアル
タイムのデータを取得でき、処理性能も向上する。

【００４２】図１６は、データ統合処理を多段に用いる
場合の適用例を示す図である。これは処理装置１３０１
（Ｓ１）上のアプリケーションプログラム２１１が処理
装置１３０２（Ｓ２）〜１３０８（Ｓ８）のデータを収
集する場合の適用例である。処理装置Ｓ４のデータテー
ブル１３１４上のデータ及び処理装置Ｓ３のデータテー
ブル１３１３がそれぞれメッセージ１３２１，１３２２
によって処理装置Ｓ２に送られ、処理装置Ｓ２のデータ
テーブル１３１２からもデータ項目の値を取得し、処理
装置Ｓ２のデータ統合処理２２４によって統合される。
収集されたデータをまとめたバスケットが１３４１であ
る。バスケット１３４１は、処理装置Ｓ２のフィルタリ
ング処理２２２に送られ、このバスケットを要求してい
る処理装置Ｓ１にメッセージ１３２５として送られる。
一方処理装置Ｓ７のデータテーブル１３１７上のデータ
及び処理装置Ｓ８のデータテーブル１３１８上のデータ
は、転写メモリ１３２６により処理装置Ｓ６のデータテ
ーブル１３１６に周期的に写像されている。このデータ
が処理装置Ｓ６のフィルタリング処理２２２を介してメ
ッセージ１３２８として処理装置Ｓ１に送られ、バスケ
ット１３４２として収集される。処理装置Ｓ１は、メッ
セージ１３２５によって処理装置Ｓ２から取得したバス
ケット１３４１とバスケット１３４２とを統合してバス
ケット１３４３を作成し、アプリケーションプログラム
２１１に渡す。ここでバスケット１３４３はバスケット
１３４１及び１３４２から作成されており、バスケット
が処理装置内／外で多段に用いられている。処理装置Ｓ
１から伝送媒体が直接繋がっていない処理装置Ｓ３，Ｓ
４及びＳ７，Ｓ８のデータを通信が可能であれば直接取
得するよう設定することも可能ではあるが、本適用例の
ように構成することによってバスケット１３４１及び１
３４２を異なるイベントで収集し、バスケット１３４３
で単一のバスケットとしてデータ統合できる。また処理
装置Ｓ２〜Ｓ４の情報を処理装置Ｓ２がゲートウェイと
して収集することによって処理装置Ｓ１のデータ統合管
理テーブル２３３の設定を局所化できる。

【００４３】図１７（ａ）は、処理装置Ｓ１が保持する
データ統合管理テーブル２３３の設定例を示す図であ
る。レコード１４１１はバスケット１３４３を定義する
ものである。レコード１４１１は収集イベントの設定が
ない。すなわちバスケットの構成項目は自処理装置又は
他の処理装置から送信されてくるものを受け取るものだ
けである。バスケット１３４３の構成項目は、収集項目
テーブルのレコード１４２１及び１４２２によつて定義
される。バスケット１３４３は「Ｎ２状態」というバス
ケット１３４１と「Ｎ３状態」というバスケット１３４
２を統合したものである。バスケット「Ｎ２状態」のソ
ースは、処理装置Ｓ２の「状態バスケット」という名称
のバスケットであり、バスケット「Ｎ３状態」のソース
は自処理装置のバスケット「Ｎｅｔ３状態」である。レ
コード１４１２はバスケット１３４２、すなわちバスケ
ット「Ｎｅｔ３状態」を定義する。バスケット「Ｎｅｔ
３状態」は処理装置Ｓ６の「状態テーブル」というデー
タテーブル１３１６が更新されたとき収集されるデータ
で構成される。バスケット「Ｎｅｔ３状態」の構成項目
は、収集項目テーブルのレコード１４３１によって定義
される。すなわち処理装置Ｓ６の「状態テーブル」の全
項目である。レコード１４２１，１４２２及び１４３１
において構成項目の型は、複数のデータ項目の集合であ
る構造体を指定している。

【００４４】図１７（ｂ）は、処理装置Ｓ２が保持する
イベント連携データテーブル２３２の設定例を示す図で
ある。レコード１４４１は、自処理装置の「状態バスケ
ット」という名称のバスケット１３４１が更新されたと
きその全データ項目を処理装置Ｓ１に送信するよう設定
する。ここで「状態バスケット」は、処理装置Ｓ２，Ｓ
３及びＳ４から周期、更新等のイベントによって収集し
たデータを統合したバスケット１３４１であり、その構
成項目の詳細は処理装置Ｓ２が保持するデータ統合管理
テーブル２３３で定義される。

【００４５】以上データ収集のいくつかの形態と収集し
たデータを統合した処理装置がバスケットをすぐにアプ
リケーションプログラムに渡す場合の適用例を示した。
図１８は、プログラムの要求した時点で収集統合したデ
ータを渡す場合のシステム構成を示す図である。処理装
置１５０１は、処理装置１５０２及び処理装置１５０３
からデータを収集し統合する。統合されたデータは処理
装置１５０４のアプリケーションプログラム２１１や処
理装置１５０５のアプリケーションプログラム２１１が
利用するものである。ここで、処理装置１５０１と処理
装置１５０４はそれぞれ伝送媒体１５１１、１５１２と
接続しており、伝送媒体１５１１，１５１２はゲートウ
ェイとなる処理装置やＷＡＮにより繋がっている。処理
装置１５０５は通信装置１５２２を介して伝送媒体１５
１３と繋がり、処理装置１５０１は通信装置１５２１を
介して伝送媒体１５１３と繋がっている。伝送媒体１５
１３が公衆回線であって通信装置１５２１，１５２２が
モデム、伝送媒体１５１３が無線ＬＡＮであって通信装
置１５２１，１５２２が無線ＬＡＮインタフェースであ
る場合等である。処理装置１５０５は携帯情報端末など
である。この場合、（ａ）伝送路が不安定（ｂ）伝送路上の通信負荷や通信性能の制約（ｃ）処理装置１５０４や１５０５を別の作業に利用中
で、処理装置１５０１からのデータを常時受信できない等の理由で、処理装置１５０１で統合したデータをすぐ
に送信できない場合、または意図的にすぐには受信せず
後から一括して収集した結果を受信したい場合がある。
このような場合は本適用例のようにメッセージ１５４１
及び１５４２によって処理装置１５０２及び１５０３か
らデータを収集し、統合してデータ１５４４としてバッ
ファから退避する。このとき処理装置１５０１のデータ
統合管理テーブル２３３では、収集したバスケットのデ
ータ受渡方法３７３としてデマンド型を指定する。退避
されたデータは、処理装置１５０４や処理装置１５０５
が都合のよいときにメッセージとして送信され、各々の
アプリケーションプログラム２１１が利用する。

【００４６】

【発明の効果】以上述べたように本発明によれば、デー
タが存在する処理装置の所在場所に係わらず、アプリケ
ーションプログラムの必要とするデータをとり揃えてア
プリケーションの必要とする時点に提供するので、アプ
リケーションプログラムがデータ収集のための問い合わ
せを行うなどのコーディングを備える必要がなくプログ
ラム開発が容易になる。またデータ源の格納媒体やデー
タ構造、データを格納する処理装置、データ収集に利用
する伝送媒体を変更してもそれによってアプリケーショ
ンプログラムを修正する必要がない。

【００４７】さらにデータ収集の開始や終了のタイミン
グを指定したイベントの発生で制御することによって、
きめ細かなデータ収集タイミングの制御が可能となる。

【図面の簡単な説明】

【図１】実施形態の分散処理システムのハードウェア構
成図である。

【図２】実施形態の分散処理システムのソフトウェア構
成図である。

【図３ａ】実施形態のデータ統合管理テーブル２３３の
データ構成を示す図である。

【図３ｂ】実施形態のデータ統合管理テーブル２３３の
データ構成を示す図（続き）である。

【図４】実施形態のデータアクセス管理テーブル２３１
のデータ構成を示す図である。

【図５】実施形態のイベント連携データテーブル２３２
のデータ構成を示す図である。

【図６】実施形態の送受信メッセージのデータ構成を示
す図である。

【図７】実施形態のフィルタリング処理２２２の処理の
流れを示すフローチャートである。

【図８ａ】実施形態のデータ統合処理２２４の処理の流
れを示すフローチャートである。

【図８ｂ】実施形態のデータ統合処理２２４の処理の流
れを示すフローチャート（続き）である。

【図８ｃ】実施形態のデータ統合処理２２４の処理の流
れを示すフローチャート（続き）である。

【図９】実施形態の状態制御テーブル２３４のデータ構
成を示す図である。

【図１０】実施形態の状態制御処理２２５の処理の流れ
を示すフローチャートである。

【図１１】メッセージ受信をイベントとする適用例の構
成図である。

【図１２ａ】適用例のメッセージ８３１のユーザデータ
部７１２に含まれるデータ項目を示す図である。

【図１２ｂ】適用例のデータ統合管理テーブル２３３の
設定情報を示す図である。

【図１２ｃ】適用例の処理装置８０２，８０３のイベン
ト連携データテーブル２３２の設定情報を示す図であ
る。

【図１３】適用例についてのイベントシーケンスの例を
示す図である。

【図１４】データ更新をイベントとする適用例の構成図
である。

【図１５】適用例の処理装置１１０１のデータ統合管理
テーブル２３３の設定情報を示す図である。

【図１６】データ統合処理を多段に用いる場合の適用例
の構成図である。

【図１７】適用例のデータ統合管理テーブル２３３及び
イベント連携データテーブル２３２の設定情報を示す図
である。

【図１８】プログラムが要求した時点で統合したデータ
を渡す場合の例を説明する図である。

【符号の説明】

１１１〜１１４：処理装置、２１１，２１２：アプリケ
ーションプログラム、２２２：フィルタリング処理、２
２４：データ統合処理、２２５：状態制御処理、２３
２：イベント連携データテーブル、２３３：データ統合
管理テーブル、２３４：状態制御テーブル

Claims

【特許請求の範囲】

【請求項１】複数の処理装置が伝送媒体を介して互いに
接続され一連の処理を分散して行う分散処理システムに
おいて複数の処理装置に分散して格納される情報をいず
れかの処理装置によって統合する方法であって、少なくとも１台の第１の処理装置によってそれぞれイベ
ントの発生をトリガとしてあらかじめ設定された収集条
件に従って自処理装置に格納されるデータを収集してデ
ータ要求元の第２の処理装置へ送信し、第２の処理装置によって受信した収集データをあらかじ
め設定された統合条件に従って統合することを特徴とす
る分散情報の統合方法。
【請求項２】該イベントの発生はあらかじめ定めたデー
タを有するメッセージの受信、第１の処理装置内で生じ
たあらかじめ設定したデータの更新及び第１の処理装置
内で生じた周期タイマのタイマ割り込みのうちの１つで
あることを特徴とする請求項１記載の分散情報の統合方
法。
【請求項３】複数の第１の処理装置が各々独立して実行
する複数のデータ収集処理のうち１つのデータ収集処理
を第２の処理装置によって行い、第２の処理装置によっ
て実行するデータ統合のための収集データの１つとする
ことを特徴とする請求項１記載の分散情報の統合方法。
【請求項４】複数の処理装置が伝送媒体を介して互いに
接続され一連の処理を分散して行う分散処理システムに
おいて複数の処理装置に分散して格納される情報を収集
するとともに統合する処理装置であって、発生するイベントに対応して収集するデータの名称及び
収集データの送信先を格納する第１のテーブル手段と、自処理装置について発生するイベント及び該伝送媒体を
介して受信するメッセージイベントに応答して第１のテ
ーブル手段を参照し自処理装置に格納されるデータを収
集して該送信先に送信する第１の処理手段と、統合されるデータの内訳を収集データのデータ名称ごと
に分けて設定する第２のテーブル手段と、他の処理装置又は第１の処理手段から収集データを受信
し第２のテーブル手段の設定に従って収集データを統合
して処理装置内の要求元に渡す第２の処理手段とを有す
ることを特徴とする分散情報を統合する処理装置。
【請求項５】該要求元は第１の処理手段であることを特
徴とする請求項４記載の分散情報を統合する処理装置。