JP2000099478A

JP2000099478A - 異種環境における分散情報処理システム、対異種システム通信装置、及び分散情報処理方法

Info

Publication number: JP2000099478A
Application number: JP10265362A
Authority: JP
Inventors: Toshibumi Seki; 俊文關; Takashi Moriyasu; 隆守安
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1998-09-18
Filing date: 1998-09-18
Publication date: 2000-04-07

Abstract

(57)【要約】【課題】異種システムの併存稼働環境において、各シ
ステム間のデータの重複を排除して既存のデータ資産を
活用しつつ、柔軟かつ効率的なアプリケーションの構築
および連携を行う。【解決手段】単一のデータアクセス要求を各対象シス
テムが処理可能なデータアクセス要求に変換を行う情報
統合部２と、単一のデータアクセス要求を介して前記各
対象システムに保持されるデータにアクセスする統合ア
プリケーション部１とを具備し、統合アプリケーション
部１は単一のデータアクセス要求を介して各異種システ
ムのデータ構造に透過なアクセスを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、異種環境における
分散情報処理システム、対異種システム通信装置、およ
び異種環境における分散情報処理方法に関する。特に、
複数の異なる種類のシステムがネットワークにより接続
される分散コンピューティング環境において、各システ
ムに分散して存在する情報のデータ構造や存在場所から
透過なアクセスを行うことによって、データの重複を排
除して既存のデータ資産を活用しつつ、柔軟かつ効率的
なアプリケーションの構築および連携を実現するための
技術に関する。

【０００２】

【従来の技術】近年、分散ＯＳ（オペレーティングシス
テム）や各種ネットワーク技術の発達を背景として異機
種システム間のネットワーク接続が進行している。この
各々のシステムはそれぞれ例えば各工場と本社など異な
る場所で、それぞれのユーザーへのサービスを行う。各
々のシステムは単体のコンピュータ、あるいはネットワ
ークを介して複数のコンピュータが連動するように構築
されている。ネットワーク接続の場合の各システム内で
は中央集中制御型、あるいは分散処理型などで処理が行
われる。

【０００３】尚、以下において、各システムとは、それ
ぞれ１つのドメイン（定義域）を構成する。従って、あ
るシステム中のデータ構造、データのネーミングルール
などは、システム内部で閉じている。各システムは、こ
のドメイン内のアプリケーション群、データ群、各種コ
ンピュータ資源を包含する。

【０００４】各システムでは、例えばオンラインまたは
オフラインなど、それぞれ異なる処理形態で処理が行わ
れる。また、同様の処理形態であっても、マルチベンダ
ー環境でそれぞれ異なる機種に実装されている場合も多
い。

【０００５】ここで、各システムが実装されるコンピュ
ータ機種のアーキテクチャやＯＳ・ソフトウエア構成
は、それぞれ異なるのが通常である。従って、各システ
ムは別個独立に構築・稼働され、各システムの処理形態
に適したデータ構造・データモデル・データアクセス手
段によりそれぞれに必要なデータを保有する。

【０００６】一方、システム化の範囲拡大や全体システ
ムの規模拡大に伴い、これら複数の異機種システムに分
散するデータに、必要に応じて同時にアクセスを行いた
いアプリケーション処理の要請が生じた。

【０００７】これらの処理は、具体的にはオフライン系
では複数の異種システムに重複して保持されるデータの
メンテナンスに例示される。オンライン系では複数の異
種システムにそれぞれ散在する関連するデータの監視
（モニタリング）に例示される。

【０００８】以下、従来システムにおけるこれらの場合
の処理手順を具体的に説明する。

【０００９】図２２は、従来技術における上記の異機種
システム間ネットワークのプラントシステムの場合の一
例である。

【００１０】図２２に示すように、オンライン系の制御
系計算機システム１０４は、監視制御の対象とされるプ
ラント内の各機器のノードを有し、各ノードの状態を監
視する。オンラインシステム１０４上には、必要に応
じ、監視アプリケーション１０４ａ、設備管理アプリケ
ーション１０４ｂ、記録アプリケーション１０４ｃ、事
故判定アプリケーション１０４ｄなどの各種アプリケー
ションが構築され、各ノードにアクセスする。一方、オ
フライン系の情報系計算機システム１０６は、プラント
内にある各設備のメンテナンス用の情報をデータベース
などに有し、各設備データの登録・変更などを行う。オ
フラインシステム上には、設備管理アプリケーション１
０６ａ、保守計画アプリケーション１０６ｂなどの各種
アプリケーションが構築され、各設備データにアクセス
する。

【００１１】例えば、監視制御対象となる機器が追加さ
れる場合を想定する。監視対象機器が追加される場合、
オフライン系の設備管理システム１０６には、その追加
設備に対する機器名称、諸元情報、開発メーカー、設置
日、保守予定日などの情報が追加される。一方、その追
加された設備を監視するオンライン系においても監視制
御対象が増えるので、それに対応した情報として機器
名、諸元情報、現在状態等を追加する必要がある。ここ
で、諸元情報とは、各機器の仕様情報、制約条件情報な
どをいう。これらの設備追加処理は、それぞれのシステ
ムに設備管理用のアプリケーションプログラム（１０４
ｂ、１０６ａ）が構築されており、これらが別個独立に
追加処理を行っていた。

【００１２】即ち、従来、図２２に示されるオンライン
システム１０４とオフラインシステム１０６では、同一
の監視制御対象システムに対する情報を、監視対象機器
（設備）をメンテナンスするオフラインシステム１０６
の側でも重複して保持していた。この重複データの一貫
性保証は人間系が行っていた。このため、全体システム
規模が拡大するほど、重複データのメンテナンスは非常
に労力を要するものとなっていた。

【００１３】また、この追加処理の際、同一の機器デー
タに対して、オンライン系システム１０４とオフライン
系システム１０６とで相互に異なる名前付けをしていた
り、異なるデータ構造やモデルを採用している場合が多
い。従って、上記のメンテナンスは、それぞれの機器デ
ータを対応づけた上で行われなければならない。この対
応付けを行った上で一貫性を保持したメンテナンスを行
うことは非常に困難である。従来は、それぞれのシステ
ムでそれぞれの機器データをメンテナンスする設備管理
アプリケーションが独立して構築され、個別にメンテナ
ンスを行っていた。各データの一貫性保持は、それぞれ
の設備管理アプリケーション同士、または人間系などに
より個別に行われていた。

【００１４】また、一般に、オンライン系システム１０
４では高速処理が要求されるため、処理の最適化を考慮
して各機器情報は共用メモリ上に構築したデータモデル
１０４ｅに構築される。一方オフライン系システム１０
６ではデータボリュームや障害対応などを考慮してリレ
ーショナルデータベース１０７等上に構築される。この
ように、同一の処理対象に対する処理であるにも拘わら
ず、機器名称の対応付けやデータ構造等の違いをアプリ
ケーションが意識して保守する必要があった。

【００１５】また、従来の異機種システム間では、それ
ぞれ異なるシステム内に存在する異なるアプリケーショ
ン同士は人間系が介在して連携されていた。この人間系
の処理支援や、複数プログラムの連携動作をプログラム
支援する仕組みとして、ワークフローモデルやアプリケ
ーション・フレームワークの概念が一般に知られてい
る。しかし、これらの概念は、あくまでもある単一のシ
ステム（ドメイン）内部で異なるハードウエア・ソフト
ウエアを含む環境内での処理フローやアプリケーション
構築のための雛型となるモデルを提供しているに過ぎな
い。従って、これらの概念を適用するためには、各計算
機（マシン）が当該モデルを適用可能なプラットフォー
ムを採用している必要がある。かつワークフローモデル
やアプリケーションフレームワークに適合するようにア
プリケーションやデータをモデル化して再構築しなけれ
ばならなかった。即ち、複数の異なる既存のシステム間
にまたがった処理を十分に支援するものではなかった。
さらに、これらの概念は、予め決められた固定的な連携
処理に対応させてアプリケーションやデータをモデル化
するものであるため、予期せぬ事態に対して柔軟に対応
できなかった。

【００１６】

【発明が解決しようとする課題】以上説明したように、
従来の異種システム間のネットワーク接続には以下の問
題点があった。

【００１７】すなわち、異種システム間はネットワーク
レベルでは接続されてネットワーク管理されているもの
の、アプリケーションレベルでは別個独立に構築されて
おり、相互に連携処理が行われていなかった。

【００１８】従って、各異種システムごとに例えば関係
型データベース、オブジェクト指向データベースなど、
固有にデータ処理環境が構築されている。これらを１つ
のデータ構造・モデルに統合することは、全体システム
の再構築を伴い、困難である。

【００１９】従来より、上述の各システムに跨るデータ
を処理するアプリケーションは、ＲＰＣ（Remote Proce
dure Call）などの分散型処理における一般に知られる
技術を用いて、異種システムのデータにアクセスするこ
と自体は可能であった。しかし、第１に、各システムが
保有するデータのデータ構造・ネーミングルール・存在
場所などの相手側システムの実現形態に適合させてデー
タにアクセスする必要があった。換言すれば、各アプリ
ケーションはデータのアクセス先を個別に意識して処理
を行う必要があった。この個別のアクセスは、アプリケ
ーションの処理内容を複雑化させていた。

【００２０】第２に、同一の対象物を示すデータを各異
種システムごとに重複保持する必要があった。このた
め、データの一貫性保持の労力が増大するとともに、デ
ータ量も増大していた。

【００２１】第３に、異種システム間に存在するアプリ
ケーションを連携させて最終的な結果を得る汎用的なプ
ラットフォームが提供されていなかった。このため、人
間系でその連携部分を処理しなくてはならず、ユーザー
の労力が増大するとともに、処理結果の誤りを招いてい
た。

【００２２】以上のように、本発明は、上記の問題点を
解決するためになされたものである。そして、その目的
とするところは、アプリケーションが必要とするデータ
構造を用いて、各異種システムに分散するデータのデー
タ構造や存在場所から透過な統一的アクセスを実現する
ことで、データの重複を排除して既存のデータ資産を活
用しつつ、柔軟かつ効率的なアプリケーション構築を可
能とする異種環境における分散情報処理システムおよび
分散情報処理方法を提供することにある。

【００２３】また、他の目的は、異種システム間に分散
するデータのうち、定期的に監視対象とすべきデータを
キャッシュすることで、各対象システムへのデータアク
セスを不要にして効率的かつ各システムの状態に依存し
ない処理を実現することにある。

【００２４】また、他の目的は、対象各システムでのデ
ータ内容に変更が生じた際に随時上記のキャッシュに通
知されるキャッシュ内容の変更のうち、アプリケーショ
ンに通知すべき変更のみを外部アプリケーションに通知
することにより、各システムの保有するデータと外部ア
プリケーションの有する内部データとの間の一貫性保持
を実現することにある。

【００２５】また、他の目的は、複数の異種システムに
散在するアプリケーションを全体システムの目標に応じ
て柔軟に連携動作させることによって、人間系の判断を
排除して迅速かつ状況に応じた異種システムの連携を実
現することにある。

【００２６】

【課題を解決するための手段】上記の課題を実現するた
めの本発明の第１の特徴は、単一のアプリケーションの
データアクセス要求を各システムに分散して存在するデ
ータの構造に応じたアクセス要求に変換するインターフ
ェースを提供する点にある。

【００２７】この単一のデータアクセス要求は、統合ア
プリケーションから各対象システムに対して送信され
る。

【００２８】尚、ここで統合アプリケーションとは、複
数のシステム間に分散するデータに単一のデータ構造を
介してアクセスするアプリケーションをいう。この分散
するデータは、各システムが共通して保有するデータお
よび各システムしか保有しないデータの双方を含む。各
システム共有データは、それぞれ各システムごとに異な
るデータ構造で実現されていてよい。

【００２９】また、本発明の第２の特徴は、複数のこれ
らの統合アプリケーションを１つの観点から相互に連携
動作させる機能を提供する点にある。この連携動作は、
全体システムの目標に応じて行われる。

【００３０】本発明は、異種環境におけるこれらの２段
階のプラットフォームを提供するものである。

【００３１】かかる機能を実現するために、請求項１の
発明は、異なるデータ体系を有するコンピュータシステ
ム間をネットワークを介して接続した異種環境における
分散情報処理システムであって、単一のデータアクセス
要求を各対象システムが処理可能なデータアクセス要求
に変換を行う情報統合部と、単一のデータアクセス要求
を介して前記各対象システムに保持されるデータにアク
セスする統合アプリケーション部とを具備することを特
徴とするものである。

【００３２】上記構成によれば、統合アプリケーション
は、各対象システムに分散して存在するデータ構造や存
在場所を意識することなく、透過なデータアクセスを行
うことが可能となる。また、同時に各対象システムに分
散するデータの重複をなくしその一貫性を保持すること
が可能となる。

【００３３】また、請求項２の発明は、前記情報統合部
は、前記統合アプリケーション部が用いる第１のデータ
構造と前記各対象システムが有する第２のデータ構造と
の対応付けを示すメタ情報を記憶し、該メタ情報に基づ
き前記変換を行うことにより、統合アプリケーションか
らのデータアクセスに対して各対象システムのデータ構
造の相違を容易に解消することを可能とする。

【００３４】また、請求項３の発明は、前記メタ情報
は、少なくとも、前記第１のデータ構造と前記第２のデ
ータ構造との属性名の対応付けデータ、前記第１のデー
タ構造と前記第２のデータ構造との属性値の対応付けデ
ータ、および前記各対象システムの有する前記属性名の
リストのいずれか１つ以上を含むことにより、統合アプ
リケーションの単一のデータ構造を複数のシステムにそ
れぞれ存在するデータ構造に容易に変換することを可能
とする。

【００３５】また、請求項４の発明は、上記分散情報処
理システムは、さらに、各対象システムを包含する全体
システムの目標に応じて、複数の前記統合アプリケーシ
ョン部を連携動作させる統合アプリケーション連携部を
具備することにより、複数の異種システムを相互に連携
させて動作させることを可能とする。

【００３６】また、請求項５の発明は、前記統合アプリ
ケーション連携部は、前記目標に対応する前記連携処理
における各統合アプリケーション部の処理範囲および／
または処理順序を含む連携情報を記憶する連携情報処理
手段を具備し、前記連携情報処理手段は、前記連携情報
に基づいて、複数の前記統合アプリケーションを連携動
作させることにより、目標に応じた柔軟な組み合わせに
よる連携動作を可能とする。

【００３７】また、請求項６の発明は、前記情報統合部
は、さらに、前記第１のデータ構造の属性名の中で前記
統合アプリケーション部が収集すべき属性名および該属
性名に対応する属性データを統合情報ビューとして記憶
する統合情報ビュー記憶手段を有し、前記統合アプリケ
ーション部からデータアクセス要求されるデータが、前
記統合情報ビューに存在する場合には、該統合情報ビュ
ー中のデータのアクセス結果を前記統合アプリケーショ
ン部に送信することを特徴とする。

【００３８】上記構成によれば、定期的に監視対象とし
たいデータを統合情報ビューとしてキャッシュすること
ができる。つまり、各対象システムへのデータアクセス
に伴う負荷を低減することを可能とする。

【００３９】また、請求項７の発明は、前記情報統合部
は、さらに、各対象システムからのデータ配信要求を、
前記メタ情報に基づいて変換し、該変換後の前記データ
配信要求を、対応する前記統合情報ビュー中の対応する
属性データに反映する配信情報反映手段を具備すること
により、対象システムのデータの変更を随時情報統合ビ
ューに反映することを可能とする。

【００４０】また、請求項８の発明は、前記情報統合部
は、さらに、前記統合情報ビュー中の全部または一部の
属性データの配信を、各対象システムに対して要求する
情報配信要求手段を具備することにより、予め統合アプ
リケーションに通知すべきデータの配信予約を行うこと
を可能とする。

【００４１】また、請求項９の発明は、前記統合情報ビ
ューは、さらに、前記統合アプリケーション部が前記統
合情報ビュー中の各データの通知を必要とするか否かを
示す参照データを含み、前記配信情報反映手段は、各対
象システムから配信される属性データに対応する参照デ
ータが通知を必要とする値を示す場合に、前記配信され
る属性データを前記統合アプリケーション部に送信する
ことにより、統合情報ビューに定義したデータのうち
で、必要なデータのみを選択的に統合アプリケーション
に送信することを可能とする。

【００４２】また、請求項１０の発明は、前記情報統合
部は、さらに、前記各統合アプリケーションの前記各対
象システムに対するアクセス権限を記憶するセキュリテ
ィ管理手段を具備し、送信元の前記統合アプリケーショ
ンが、アクセス要求先の前記対象システムに対する前記
アクセス権限を有する場合に、前記アクセス要求を前記
対象システムに送信することにより、各対象システムに
対するデータアクセス要求を事前にセキュリティチェッ
クし、不正なアクセスを防止することを可能とする。

【００４３】また、請求項１１の発明は、前記情報統合
部は、さらに、前記各対象システム間へのデータ更新要
求の結果に応じて、関連する全ての更新要求が成功であ
る場合に、該更新要求を有効化する情報更新手段を具備
することにより、各対象システム間のデータの一貫性を
保持することを可能とする。

【００４４】また、請求項１２の発明は、異なるデータ
体系を有するコンピュータシステム間をネットワークを
介して接続した異種環境における分散情報処理システム
であって、対象システムごとに設けられ、該対象システ
ムが保持するデータのデータ体系に応じて、前記情報統
合部へのデータ送信を行う対象システム情報処理部と単
一のデータアクセス要求を、各対象システムが処理可能
なデータアクセス要求に変換を行う情報統合部と、単一
のデータアクセス要求を介して前記各対象システムに保
持されるデータにアクセスする統合アプリケーション部
とを具備することを特徴とする。

【００４５】上記構成によれば、統合アプリケーション
は、各対象システムに分散して存在するデータ構造や存
在場所を意識することなく、透過なデータアクセスを行
うことが可能となる。また、同時に各対象システムに分
散するデータの重複をなくしその一貫性を保持すること
が可能となる。

【００４６】また、請求項１３の発明は、異なるデータ
体系を有する複数のコンピュータシステムに対してデー
タアクセスを行う対異種システム通信装置であって、ア
プリケーションが用いる第１のデータ構造と各対象シス
テムが有する第２のデータ構造との対応付けを示すメタ
情報に基づいて、前記アプリケーションからのデータア
クセス要求を各対象システムが処理可能なデータアクセ
ス要求に変換を行う情報統合部を具備することを特徴と
する。

【００４７】上記構成によれば、各対象システムに分散
して存在するデータ構造や存在場所を意識することなく
透過なデータアクセスを行う、アプリケーションに対す
る統一したモデルを提供することが可能となる。

【００４８】さらに、請求項１４の発明に係る方法は、
ネットワークを介して接続された、異なるデータ体系を
有するコンピュータシステム間の処理を行う異種環境に
おける分散情報処理方法であって、各対象システムに保
持されるデータに対する単一の第１のデータアクセス要
求を受信するステップと、前記第１のデータアクセス要
求を各対象システムが処理可能な第２のデータアクセス
要求に変換を行うステップと、前記第２のデータアクセ
ス要求を、前記第１のデータアクセス要求がアクセスす
べきデータが存在する各対象システムに対し、該対象シ
ステムごとに送信するステップとを含むことを特徴とす
る。

【００４９】上記構成によれば、上記構成によれば、統
合アプリケーションは、各対象システムに分散して存在
するデータ構造や存在場所を意識することなく、透過な
データアクセスを行うことが可能となる。また、同時に
各対象システムに分散するデータの重複をなくしその一
貫性を保持することが可能となる。

【００５０】また、請求項１５の発明に係る記録媒体
は、ネットワークを介して接続された、異なるデータ体
系を有するコンピュータシステム間の処理を行う異種環
境における分散情報処理プログラムを格納したコンピュ
ータ読み取り可能な記録媒体であって、各対象システム
に保持されるデータに対する単一の第１のデータアクセ
ス要求を受信するステップと、前記第１のデータアクセ
ス要求を各対象システムが処理可能な第２のデータアク
セス要求に変換を行うステップと、前記第２のデータア
クセス要求を、前記第１のデータアクセス要求がアクセ
スすべきデータが存在する各対象システムに対し、該対
象システムごとに送信するステップとを含むことを特徴
とする。

【００５１】上記構成によれば、上記構成によれば、統
合アプリケーションは、各対象システムに分散して存在
するデータ構造や存在場所を意識することなく、透過な
データアクセスを行うことが可能となる。また、同時に
各対象システムに分散するデータの重複をなくしその一
貫性を保持することが可能となる。

【００５２】

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

【００５３】第１の実施形態第１の実施形態は、アプリケーションが必要とするデー
タ構造を、各異種システムに分散するデータのデータ構
造に相互に変換して、各異種システムに分散するデータ
への透過な統一的データアクセスを行う機能を提供する
ものである。

【００５４】以下では、オンライン系の監視制御システ
ムとオフライン系の設備管理システムとを異種接続した
例を用いて説明する。本実施形態の適用される異種接続
の形態はこれに限定されるものではなく、オンライン系
とオフライン系との異種接続や、同系処理をマルチベン
ダー環境で行う異種接続など、あらゆる形態に適用でき
ることは言うまでもない。

【００５５】図１に示すように、第１の実施形態に係る
異種システム連携システムは、複数の異種システム上の
オンライン系システムの情報とオフライン系システムの
情報を区別することなく統合して扱う統合アプリケーシ
ョン部１と、この統合アプリケーション部１に異種シス
テムに分散した情報を１つの情報モデルとして提供する
情報統合部２と、この情報統合部２とネットワーク３を
介して接続され各別のドメインとして監視制御や設備管
理などの処理を行う対象システム情報処理部４と、各シ
ステムの処理対象データ５とにより構成される。

【００５６】統合アプリケーション部１は、複数の異種
システムのデータに透過にアクセスする１または複数の
統合アプリケーションごとに構成される。例えば、図１
に示すように、統合監視アプリケーション１ａ、事故判
定統合アプリケーション１ｂ、統合記録アプリケーショ
ン１ｃ、統合設備管理アプリケーション１ｄなどであ
る。各統合アプリケーションは、図４中の、統合アプリ
ケーション手段１１に対応する。

【００５７】情報統合部２は、各統合アプリケーション
毎にそのプログラムが必要とする情報のみを、必要なシ
ステムの必要な対象システム情報処理部４から取り込ん
で各統合アプリケーションに対して提供する。即ち、情
報統合部２は、統合アプリケーション手段１１に対し
て、異種システムに分散した情報を、単一のデータ構造
を持つ１つの情報モデルとして提供する。また逆に、情
報統合部２に対する更新と、対応するシステムの対応す
る対象システム情報処理部４に対する更新とを一貫性を
保持して行う機構を持つ。本例では、情報統合部２は、
各統合アプリケーションにそれぞれ対応する情報モデル
ごとに構成される。本例では、統合監視情報モデル２
ａ、統合事故判定情報モデル２ｂ、統合記録情報モデル
２ｃ、統合設備管理情報モデル２ｄなどである。

【００５８】尚、ここでモデルとは、データ構造の型の
集合、データ検索の演算子・推論則、および一貫性保持
の規則などの要素の組み合わせである。図１中の各情報
モデルは、それぞれ図４の情報統合部２を構成する。こ
れらの情報モデルは、統合アプリケーション部１（各統
合アプリケーション手段１１）と各対象システムとの間
のインターフェースとして機能する。

【００５９】図４に示すように、データ統合部２は、さ
らに、統合アプリケーションが定期的に監視対象とした
いデータ構造を含んだ統合情報ビューの記憶・管理を行
う統合情報ビュー記憶手段２１と、統合アプリケーショ
ン手段１１からのデータアクセス要求に対して必要とさ
れる処理を起動するインターフェースである要求送受信
手段２２と、各統合アプリケーションの各対象システム
に対するアクセス権限の管理・チェックを行うセキュリ
ティ管理手段２３と、統合アプリケーションの意識する
データ構造・モデルと各システムが処理可能なデータ構
造との間の対応付けを行うメタ情報を管理・記憶するメ
タ情報記憶手段２４と、各対象システムデータ処理部４
からの監視対象データの変更通知に基づき統合情報ビュ
ー上のデータの更新を行う配信情報更新手段２５と、各
対象システムデータ処理部４に対して監視対象データの
配信を要求する情報配信要求手段２６と、要求送受信手
段２２からのデータ検索要求に基づき各対象システムデ
ータ処理部４に対してデータの検索要求を送・受信する
情報問い合わせ手段２７と、要求送受信手段２２からの
データ更新要求に基づき各対象システムデータ処理部４
に対してデータの更新要求を送・受信する情報更新手段
２８とにより構成される。

【００６０】尚、情報統合部２中の各情報モデルと統合
アプリケーション部１中の各統合アプリケーションと
は、図１に示すように個々のプログラムモジュールとし
て実現されてもよい。あるいは、対応する情報モデルと
統合アプリケーションとをまとめて１つのプログラムモ
ジュールとすることもできる。情報モデルは個々の統合
アプリケーションに１対１に対応せずに、複数の統合ア
プリケーションに対して共通の１つの情報モデルとして
もよい。

【００６１】対象システム情報処理部４は、１つのドメ
インとして各々の処理対象とするデータを保有して各種
処理を行う。対象システム情報処理部４は、それぞれの
処理を行うための複数のアプリケーションプログラム
（図示せず）を含んでもよい。

【００６２】図４に示すように、対象システム情報処理
部４は、さらに、情報統合部２に対して各種メッセージ
を送信するメッセージ送信手段４１と、情報統合部２か
らの各種メッセージを受信するメッセージ受信手段４２
と、情報統合部２の各統合情報ビューに対するデータ配
信情報を記憶する配信先記憶手段４３と、配信先記憶手
段４３に記憶された統合情報ビューに関連する情報に対
する変更を検出して通知する変更検出手段４４と、対象
システムのデータを検索して結果をメッセージ送信手段
に出力する検索手段４５と、対象システムのデータを更
新する更新手段４６と、対象システムのデータをモデル
化した情報モデル４７とにより構成される。情報モデル
４７は、対象システムが保有する対象ノードなどの情報
をキャッシュとして保持する。この情報モデル４７を介
して、対象システムが保有する各データがアクセスされ
る。情報モデル４７は、モデル化されたデータモデルな
どの他、関係型データベースの各表、共有メモリ上に展
開されるデータテーブルなど、各処理システムに応じて
異なるデータ構造で実現されていてよい。また、上記変
更検出手段４４など情報モデル４７に対するアクセスを
行う各手段は、情報モデル４７を介さずに直接各ノード
から変更通知を受けてもよい。

【００６３】図１に示すように、本例では、対象システ
ム情報処理部４は、オンライン系の監視制御システムと
オフライン系の設備管理システムとを含む。

【００６４】オンライン系の監視制御システムは、実際
の監視制御対象５ａと各種Ｉ／Ｏ機器を通じて接続され
ている。制御対象設備情報４ａには、接続された監視制
御対象機器毎の現在状態がデータとして保持されてい
る。制御対象設備情報４ａは、各機器毎に設けること
も、複数の機器をまとめて１つのモデルなどとして実現
することもできる。また、制御対象運用情報４ｂは、監
視制御対象を監視制御する人の配置や、組織構造をモデ
ル化したものであり、部署単位や、営業所／支店単位な
ど、組織に対応して持たせることも、複数の組織をまと
めてモデル化することもできる。

【００６５】オフライン系の設備管理システムは、各機
器毎の諸元データや製造元、設置日、保守予定日などの
設備を管理する情報や、設備を操作する際の操作手順等
の制約情報をデータベース５ｂ上に構築している。それ
らデータベースに対するアクセス手段として、設備情報
４ｃや設備操作情報４ｄがある。設備情報４ｃは、設備
情報に関する情報を読み書きするためのインターフェイ
スを持ち、設備操作情報４ｄは操作順序等の操作制約／
ルールを読み書きするためのインターフェイスを持つ。

【００６６】尚、制御対象設備情報４ａ、制御対象運用
情報４ｂ、設備情報４ｃ、設備操作情報４ｄは、例えば
個々のプログラムモジュールとして実現される。４つの
各情報は、図４中の対象システム情報処理部４にそれぞ
れ対応する。

【００６７】次に、第１の実施形態におけるネットワー
ク構成を説明する。

【００６８】図２および図３は、第１の実施形態が対象
とするネットワークを介して接続された複数の異種シス
テムを含むネットワーク構成を示す。

【００６９】図２は、このネットワーク構成の１つの例
である。図２に示すように、オンライン系のネットワー
ク７２は、少なくとも１台の計算機や、少なくとも１台
以上から構成される計算機システムを接続している。こ
れらの計算機は監視制御対象となるシステムとつながっ
て、それぞれ情報を取り込んだり制御している。さらに
オンライン系システム７２は、ExtranetまたはIntranet
などを介してオフライン系のネットワークシステム７３
や、ゲートウエイ７４経由でInternet７１を介して他の
企業や一般利用者の計算機と接続されている。このシス
テム構成において、例えば、オンライン系の処理とオフ
ライン系の処理、オフライン系の処理と他企業の計算機
システムは、ネットワークを介して情報を相互に交換で
きる。

【００７０】図３は、ネットワーク構成の他の例であ
る。図３に示すように、情報系のネットワーク（ＬＡ
Ｎ）８１上の複数の監視制御用の計算機と少なくとも１
つ以上の制御用ＬＡＮ（８２、８３）とが、それぞれの
制御用ネットワークに対応した計算機を介して接続され
た構成とすることができる。制御用のＬＡＮ（８２、８
３）には制御ノードが複数接続される。これら制御ノー
ドの情報は、その制御用ＬＡＮに接続された計算機を介
して情報系のネットワーク８１に接続された監視制御用
の計算機に送信される。

【００７１】尚、図１中では、情報統合部２および統合
アプリケーション部１は、オンライン系システムでもオ
フライン系システムでもなく、これらとネットワークを
介した異なるシステムに配置したが、第１の実施形態は
これに限定されない。データ統合部２および統合アプリ
ケーション部１は、オンライン系のシステム上に存在し
ても、オフライン系のシステム上に存在してもよく、全
体ネットワーク上の任意の場所に配置することができ
る。

【００７２】次に、第１の実施形態における各システム
内の個々の計算機のハードウエア構成を説明する。第１
の実施形態に係る異種間連携処理システムの実施には、
以下で説明する処理を実現するプログラムを作成し、こ
の作成したプログラムをロードすることでこの処理を実
行可能とするネットワーク化されたまたは単一のコンピ
ュータを用いる。このコンピュータには、いわゆる汎用
機、ワークステーション、ＰＣ、ＮＣ（Network Comput
er）等が含まれる。第１の実施形態で用いるコンピュー
タシステムのハードウエアは、各種処理を行うためのＣ
ＰＵと、プログラムメモリ・データメモリなどのメモリ
とを少なくとも備え、さらに必要に応じ、ＦＤ・ＣＤな
どの外部記憶装置と、キーボード・マウスなどの入力装
置と、ディスプレー・プリンタ等の出力装置とを備えて
もよい。

【００７３】尚、上述した異種間連携処理を実現するた
めのプログラムは、各種記録媒体に保存することができ
る。かかる記録媒体を、上記ハードウエアを具備するコ
ンピュータにより読み出し、当該プログラムを実行する
ことにより、本発明が実施できる。ここで記録媒体と
は、例えばメモり・磁気ディスク・光ディスク等、プロ
グラムを記録することができる装置全般を含む。

【００７４】第１の実施形態は上記のように構成されて
おり、以下その処理の流れを、データアクセスのパター
ンに即して順に説明する。

【００７５】（１）データ検索処理まず、統合アプリケーション手段１１の一例である統合
アプリケーションが、必要な情報を検索する場合の例を
示す。図１中の統合監視アプリケーション１ａは、情報
統合部２の統合監視情報モデル２ａに対して、例えば、
プラントシステムにおける「機器名＝弁１０」の現在状
態のデータの検索要求を情報統合部２（統合監視情報モ
デル）の要求送受信手段２２に送信する場合を想定す
る。

【００７６】以下、この検索要求を受信した場合におけ
る情報統合部２の処理を図８および図９のフローチャー
トに従って説明する。

【００７７】Ｓ３０は、この検索要求を要求送受信手段
２２により受信する。Ｓ３２は、統合情報ビュー記憶手
段（図４の２１）上に検索要求の対象データが存在する
か否かを検索・判断する。統合情報ビューの詳細は後述
する。該当データが存在しない場合、要求送受信手段２
２は、情報問い合わせ手段２７に対して要求を転送す
る。

【００７８】情報問い合わせ手段２７では、メタ情報記
憶手段２４に記憶された情報が参照され、統合アプリケ
ーション手段２２からの検索要求が「機器名」、「弁１
０」、「現在状態」についての検索要求のための表現に
変更される。

【００７９】図５乃至図７に示すように、メタ情報記憶
手段２４は、属性名称間の対応付け（図５（ａ）、図５
（ｂ））、属性値（機器名称）間の対応付け（図６）、
各対象システム情報処理部４に含まれる属性リスト（図
７）などを保持する。図５の属性名称間の対応付けと図
６の機器名称間の対応付けは、ともにシステム毎に同一
の機器に対して異なる名前を付けている場合用いられ
る。この対応付けは、例えば、一般に知られるオブジェ
クト指向における継承関係、意味ネットワーク、一対一
の対応関係などの技術を用いて表現することができる。
図５（ａ）および図５（ｂ）中の親（ルート）に位置す
る属性名（「機器名」、「現在状態」）は統合アプリケ
ーション部１１側から要求される抽象的な属性名（上位
の属性名）である。一方、子（枝）に位置する属性名
（「温度計名」、「弁名」、「現在温度」、「開閉状
態」）は各対象システムで認識される具体的属性名であ
る。

【００８０】図６の属性値の対応付けは、各属性値のネ
ーミングルールの記述により示される。

【００８１】図７の各対象システム情報処理部４に含ま
れる属性リストは、検索／更新などの際にどの対象シス
テム情報処理部４と情報交換すれば良いかを判断するた
めの情報である。この属性リストは、例えば、各対象シ
ステム情報処理部４とこれに含まれる属性名リストから
なる表によって構成される。尚、図７の属性名リストに
は、各対象システム情報処理部４の所在場所の情報は含
まれない。第１の実施形態は、一般に知られる分散ＯＳ
（Operating System）等のプラットフォームを利用して
データアクセス要求を各対象システムへ経路指定を行
う。

【００８２】従来においてもこの分散ＯＳなどの技術を
利用して、データのサイト（所在場所）の意識は不要と
することができた。しかし、従来は要求元のアプリケー
ションが各サイトに存在するデータのデータ構造（ある
いはモデル）の意識を必要としていた。第１の実施形態
は上記のメタ情報を用いて各対象システムにおけるデー
タ構造の意識を不要とし、これらから透過なアクセスを
提供する。

【００８３】情報問い合わせ手段２７は、このような関
連情報を適宜参照し、かつ必要に応じて対象システム情
報処理部４に問い合わせを行うことによって、機器名は
「弁名」、弁１０は「Ｂ１０」、現在状態は「開閉状
態」と置換できることを判断する。すなわち、図９のＳ
３４は、弁名と開閉状態という属性をもつ「制御対象設
備情報」に対して、Ｂ１０の開閉状態を検索すればよい
ことを判断する。

【００８４】ここで、情報問い合わせ手段２７が行う属
性名の具体的名称への変換処理の一実現形態を、図８の
フローチャートを用いて具体的に以下説明する。

【００８５】”「機器名＝弁１０」の現在状態”を検索
する場合を想定する。Ｓ１０は、まず検索時の属性名を
取り出す。ここでは、「機器名」、「弁１０」、「現在
状態」がそれぞれ属性名となる。これらの属性名によ
り、図５（ａ），（ｂ）、図６に示すメタ情報記憶手段
２４に記憶された属性名称の関係などを検索する。この
検索により、Ｓ１２は、機器名を「温度計名」と「弁
名」に、弁１０を「Ｂ１０」に、現在状態を「現在温
度」と「開閉状態」にそれぞれ展開（変換）する。

【００８６】これらのうち、弁１０とＢ１０とはともに
属性値である。Ｓ１４は、これら属性値を除外して、検
索対象となる属性名の組み合わせを｛「温度計名」と
「弁名」｝と｛「現在温度」と「開閉状態」｝との組み
合わせとする。即ち、Ｓ１４は、｛温度計名、現在温
度｝、｛温度計名、開閉状態｝、｛弁名、現在温度｝、
｛弁名、開閉状態｝の４つを検索の候補とする。

【００８７】Ｓ１６は、これらの候補のうち、メタ情報
記憶手段２４が保持する対象システムデータと各対象シ
ステムデータが保持する属性リストとの関係に従い、実
際に存在する組み合わせとして｛温度計名、現在温
度｝、｛弁名、開閉状態｝の２つを選択する。

【００８８】Ｓ１８は、まず、｛温度計名、現在温度｝
の組み合わせ、即ち”「温度計名＝Ｂ１０」の現在温
度”を対象システムの制御対象設備情報の中から検索す
る。ここでは該当する項目が存在しないため（Ｓ２
０）、Ｓ２２は次の検索候補が存在するか否かをチェッ
クする。次に、Ｓ１８は、次の組み合わせとして｛弁
名、開閉状態｝の組み合わせ、即ち”「弁名＝Ｂ１０」
の開閉状態”を制御対象設備情報中から検索する。ここ
では該当する項目が存在するため、要求された検索が実
現できる。

【００８９】尚、上記の例では、最初に属性名の組み合
わせが見つかった段階で検索対象を決定したが、本実施
形態における属性名の変換処理はこれに限定されない。
全ての属性名の組み合わせを最後まで調べ、検索対象を
決定してもよい。属性名を展開する際の優先度を予め決
定しておき、この優先度の高い組み合わせから順にチェ
ックすることも可能である。この優先度の与え方は任意
である。例えば、図５（ａ），（ｂ）、図６中の属性名
称の関係上の構造上、親が子より優先度を高く設定して
もよい。子同士では左側ほど優先度を高く設定してもよ
い。

【００９０】検索対象となる対象システム情報処理部が
決定され、上記の属性変換処理が行われた後、図９のＳ
３６は、検索要求のセキュリティ判断を、セキュリティ
管理手段２３を用いて行う。セキュリティ管理手段２３
は、図１０に示すように統合アプリケーション手段１１
毎のアクセス権リストを保持する。このアクセス権リス
トを参照することで、統合監視アプリケーション（図１
の１ａ）は全ての対象システム情報処理部４に対してRe
ad Onlyのアクセス権が許されていることが判断され
る。

【００９１】アクセス権リストで許容された検索要求で
あるので、Ｓ３８は、検索要求メッセージを、対象シス
テム情報処理部４（制御対象設備情報４ａ）に対して送
信する。

【００９２】対象システム情報処理部４（制御対象設備
情報４ａ）では、まずＳ４０が、メッセージ受信手段４
２を介して検索要求を受信する。Ｓ４２は、検索手段４
５を用いて情報モデル４７を検索する。尚、検索手段４
５は必ずしも情報モデル４７を検索対象とする必要はな
く、保有するデータや各監視対象のノードを直接検索し
てもよい。情報モデル４７は、１または複数の監視制御
対象ノードをモデル化した情報を保持する。例えば、図
１１に示すように、制御対象設備情報は、「温度計名と
現在温度からなるテーブル」２０２と「弁名と開閉状態
からなるテーブル」２０１の２つのテーブルから構成さ
れる。一方、図１２に示すように、設備情報は「機器
名、諸元データ、製造元、保守日からなるテーブル」２
０３から構成される。尚、第１の実施形態では、いずれ
のモデルもリレーショナル・データベース形式のテーブ
ルでの表現にしているが、第１の実施形態の実現手法は
これに限定されない。それぞれのモデルは、一方がオブ
ジェクト指向データベースであったり、特有のデータ構
造であってもよく、それぞれの対象システムをモデル化
しやすいデータ構造でよい。さらに、各モデル内に異な
るデータ構造による情報が混在してもよい。情報統合部
２からはこの各データ構造の認識は不要である。

【００９３】検索手段４５は、情報モデル４７内の「Ｂ
１０」の「開閉状態」を制御対象設備情報２０１中で検
索し、属性値が「開」状態であることを求める。

【００９４】Ｓ４４は、検索結果を、検索手段４５か
ら、メッセージ送信手段４１を介して、情報問い合わせ
手段２７に送信する。Ｓ４４は、さらに要求送受信手段
２２を介して要求元である統合監視アプリケーション１
１に検索結果を返信する。

【００９５】一方、図９のＳ３２は、対応する統合情報
ビュー記憶手段２１中に、該当データが存在すると判断
した場合は、上記同様にセキュリティ管理手段２３を用
いてセキュリティ判断を行う（Ｓ４６）。アクセス権リ
スト上にアクセス権が存在すれば、Ｓ４８は、統合情報
ビュー記憶手段２１中からデータを検索する。Ｓ４４
は、上記と同様検索結果を要求元である統合監視アプリ
ケーション１１に返信する。尚、Ｓ３６およびＳ４６で
セキュリティエラーとなった場合は、Ｓ４４はセキュリ
ティエラーの結果を要求元である統合監視アプリケーシ
ョン１１に対して返信する。

【００９６】（２）データ更新処理次に、統合アプリケーション手段１１の一例である統合
設備管理アプリケーション１ｄが、設備を追加する場合
の例を示す。図１中の統合設備管理アプリケーション１
ｄは、データ統合部２の統合設備管理情報モデル２ｄに
対して、例えば、プラントシステムにおける「機器名＝
温度計４」の設備の追加要求を送信する場合を想定す
る。

【００９７】以下、この設備追加要求を受信した場合に
おける情報統合部２の処理を図１３のフローチャートに
従って説明する。

【００９８】Ｓ５０は、情報統合部２（統合設備管理情
報モデル２ｄ）の要求送受信手段２２により、設備追加
要求を受信する。要求送受信手段２２は、情報更新手段
２８に受信した設備追加要求を転送する。

【００９９】情報更新手段２８は、メタ情報記憶手段２
４が保持する図５乃至図７のメタ情報を（１）の検索処
理と同様に参照することによって、機器名は「温度計
名」、温度計４は「Ｔ４」と置換できることを判断す
る。同時に、情報更新手段２８は、「機器名」、「温度
計名」という属性をもつ対象システム情報処理部４が
「制御対象設備情報」と「設備情報」であることを判断
する。これらの変換処理により、Ｓ５２は、「制御対象
設備情報」と「設備情報」に対して設備追加処理を行う
ことを決定する。

【０１００】次に、Ｓ５４は、セキュリティ管理手段２
３を用いてセキュリティ判断を行う。セキュリティ管理
手段２３は、図１０に示すように統合アプリケーション
手段毎のアクセス権リストを保持している。図１０を参
照することにより、統合設備管理アプリケーション１ｄ
は制御対象設備情報４ａと設備情報４ｃに対してRead／
Write ＯＫのアクセス権が許されていることがわか
る。従って、Ｓ５６は、設備追加要求メッセージ（更新
要求メッセージ）をこれら２つの対象システムデータ処
理部４（制御対象設備情報４ａと設備情報４ｃ）に対し
て送信する。この際、Ｓ５６は、制御対象設備情報４ａ
に対しては“温度計名＝Ｔ４の追加”を指示する。一
方、設備情報４ｃに対しては“機器名＝温度計４、諸元
データＤＤＤＤ、製造元＝Ａ社、保守日＝未定”を指定
して送信する。

【０１０１】Ｓ５８は、システム対象情報処理部４（制
御対象設備情報４ａ）中のメッセージ受信手段４２を介
して更新要求を受信する。Ｓ６０は、更新手段４６を用
いて情報モデル４７に“温度計名＝Ｔ４”なる情報を追
加する。Ｓ６０は、同様にシステム対象情報処理部４
（設備情報４ｄ）中の情報モデル４７に“機器名＝温度
計４、諸元データ＝ＤＤＤＤ、製造元＝Ａ社、保守日＝
未定”なる情報を追加する。

【０１０２】Ｓ６２は、それぞれの更新手段４６が、更
新処理が正しく行うことができた（ＯＫ）かまたは失敗
した（ＮＧ）かのいずれかのメッセージを、メッセージ
送信手段４１を介して、情報更新手段２８に送信する。
情報更新手段２８は更新要求を行った全ての対象システ
ム情報処理部４から更新処理結果を受信するのを待つ
（Ｓ６４）。Ｓ６６は、全ての更新処理結果を受信した
際に、これらの結果が全てＯＫであるか否かを判定す
る。更新処理結果が全てＯＫであった場合には、Ｓ６８
は、更新要求を行った全ての対象システム情報処理部４
に対して、“ＣＯＭＭＩＴ”要求を送信して各対象シス
テム情報処理部４における更新処理の有効処理を行わせ
る。Ｓ７０は、コミット処理の完了後、正常更新完了を
要求送受信手段２２を介して要求元である統合設備管理
アプリケーション１ｄに返信する。一方、Ｓ６６で更新
処理結果に少なくとも一つでもＮＧが存在した場合、ま
たはＳ６４で一定時間内にメッセージの返信がない場合
は、Ｓ７４は、更新要求を行った全ての対象システム情
報処理部４に対して、“ＡＢＯＲＴ”要求を送信して更
新処理の無効処理を行わせる。Ｓ７６は、アボート処理
完了後、異常終了を要求送受信手段２２を介して要求元
である統合設備管理アプリケーション１ｄに返信する。

【０１０３】尚、Ｓ６２乃至Ｓ７６における各対象シス
テム間でのデータの一貫性保持のためのコミット／アボ
ート処理は、当業者に知られる２相コミットなどの技術
を用いて実現することができる。

【０１０４】他方、図１３中のＳ５４にてセキュリティ
エラーとなった場合は、Ｓ７２はセキュリティエラーの
結果を要求元である統合設備管理アプリケーション１ｄ
に対して返信する。

【０１０５】（３）データモニタリング（監視）処理次に、統合アプリケーション手段１１の一例である統合
監視アプリケーション１ａが、設備の現在状態を諸元デ
ータとともにモニタリング（監視）する場合の例を示
す。図１中の統合監視アプリケーション１ａが、情報統
合部２の統合監視情報モデル２ａに対して、例えば、プ
ラントシステムの状態監視を行う場合を想定する。

【０１０６】この監視を行うために統合監視アプリケー
ション１ａは、「機器名」、「現在状態」、「諸元デー
タ」を表示するための統合情報ビューの作成を要求す
る。図１７は作例された統合情報ビューの一例を示す。

【０１０７】尚、ここで、ビューとは、各システムに保
有されたデータを各アプリケーションごとに制限・変換
・結合したデータアクセスのための仮想的な表をいう。

【０１０８】以下、この統合情報ビューを介して状態監
視を行うためのデータ配信の登録処理を図１４のフロー
チャートに従って説明する。

【０１０９】Ｓ８０は、情報統合部２（統合監視情報モ
デル２ａ）の要求送受信手段２２を介して統合情報ビュ
ー作成の要求を受信する。要求送受信手段２２は、情報
配信要求手段２６に対して統合情報ビュー作成要求を転
送する。

【０１１０】情報配信要求手段２６はメタ情報記憶手段
２４が保持する図５乃至図７のメタ情報を参照すること
によって、機器名は「温度計名」と「弁名」、現在状態
は「現在温度」と「開閉状態」に対応付けられているこ
とを判断する。

【０１１１】Ｓ８２は、この対応付けを参照して、「温
度計名と現在温度」、「弁名と開閉状態」、および「機
器名と諸元データ」という属性をもつ対象システム情報
処理部４は、「制御対象設備情報４ａ」と「設備情報４
ｃ」であることを判断する。Ｓ８２は、これらの情報に
対して配信予約処理を行うことを決定する。

【０１１２】Ｓ８４は、セキュリティ管理手段２３を用
いてセキュリティ判断を行う。セキュリティ管理手段２
３は、図１０に示すように統合アプリケーション手段１
１毎のアクセス権リストを保持する。Ｓ８４は、このア
クセス権リストを参照して、統合監視アプリケーション
１ａは全ての情報モデルに対してRead Onlyのアクセス
権が許されていることを判断する。従って、Ｓ８６は、
配信予約メッセージをこれら２つの対象システム情報処
理部４（制御対象設備情報４ａと設備情報４ｃ）に対し
て送信する。この送信の際、Ｓ８６は、制御対象設備情
報４ａに対して、｛“監視対象＝現在温度”、“配信先
＝統合監視情報モデル／データＡ”、“配信情報＝温度
計名、現在温度”｝および｛“監視対象＝開閉状態”、
“配信先＝統合監視情報モデル／データＢ”、“配信情
報＝弁名、開閉状態”｝を指定する。一方、Ｓ８６は設
備情報４ｃに対して、｛“監視対象＝機器名”、“配信
先＝統合監視情報モデル／データＸ”、“配信情報＝機
器名、諸元データ”｝を指定して送信する。

【０１１３】Ｓ８８は、システム対象情報処理部４（制
御対象設備情報４ａ）中のメッセージ受信手段４２を介
して配信予約メッセージを受信する。Ｓ９０は、配信先
記憶手段４３に配信先予約情報を登録する。図１５に配
信先予約情報の一例を示す。Ｓ８８は同様に、システム
対象情報処理部４（設備情報４ｃ）に対して、“監視対
象＝機器名”、“配信先＝統合監視情報モデル／データ
Ｘ”、“配信情報＝機器名、諸元データ”｝を配信先予
約情報として登録する。

【０１１４】尚、異なる対象システム情報処理部４に対
するそれぞれの配信先予約処理が正しく行うことができ
た（ＯＫ）か、失敗した（ＮＧ）かの確認処理を、上記
のコミット／アボート処理を利用して実現することもで
きる。ここでは確認処理の説明を省略する。

【０１１５】上記の配信予約（登録）処理でさらに統合
情報ビュー記憶手段２１に初期値情報を送信する必要が
ある場合を説明する。この場合は、メッセージ受信手段
４２が検索手段４５に、該当情報を検索して配信情報更
新手段２５に送信するように指示することで、統合情報
ビューへの初期値の送信が可能となる。

【０１１６】他方図１４におけるＳ８４にて、セキュリ
ティエラーとなった場合は、Ｓ９２は、セキュリティエ
ラーの結果を要求元である統合監視アプリケーション１
ａに対して返信する。

【０１１７】次に監視対象である情報が更新された場合
の処理の流れについて、図１６のフローチャートを用い
て説明する。

【０１１８】上記のように、温度計の現在温度の属性値
は、定期的に測定して統合情報ビュー記憶手段２１に登
録したい情報である。一方、弁の開閉状態の属性値はそ
の変化が生じたときのみ統合情報ビュー記憶手段２１に
登録されればよい。各対象システムにおいて、温度計の
現在温度は、対象システム情報処理部４内の情報モデル
４７中で定期的に更新される。一方、弁の開閉状態は操
作をしたときなどの変化が生じたときのみ情報モデル４
７中で更新される。即ち、それぞれの属性値の更新は、
統合情報ビューに通知すべきタイミングおよび頻度を異
にすることが理解される。

【０１１９】図１６に示すように、Ｓ１００は、変更検
出手段４４を用いてこれらの情報モデル４７の変更を検
出する。あるいは、変更検出手段４４は、直接各制御ノ
ードから変更通知を受信して変更を検出した後、情報モ
デル４７の該当する値を読み出してもよい。Ｓ１０２
は、この検出された変更が、配信先記憶手段４３に記憶
された監視対象の変化であるか否かを判断する。Ｓ１０
２は、変更が監視対象であった場合には、配信先記憶手
段４３を検索して登録された配信先を求める。Ｓ１０４
は、変更された情報に対応する配信先へ配信情報をメッ
セージ送信手段４１を介して送信する。ここで、現在温
度のような時系列なデータを定周期に測定する場合に
は、変更検出手段４４は定期的に情報モデル４７より属
性値を取り出し、配信先記憶手段４３に登録された配信
先を求めて、この配信先へ配信情報をメッセージ送信手
段４１を介して送信してもよい。

【０１２０】配信先記憶手段４３に図１５に示す情報が
登録されている場合を説明する。図１５に示す配信先リ
ストは、統合アプリケーション側からの要求時に作成さ
れる。例えば温度計の定期的な現在温度測定結果は、統
合監視情報ビューのデータＡと統合記録情報ビューのデ
ータＡ宛てに、「温度計名と現在温度」の情報を送信す
る。一方、弁の開閉状態が変化した場合は、統合監視情
報ビューのデータＢと統合操作情報ビューのデータＣ宛
てに、「弁名と開閉状態」の情報を送る。

【０１２１】尚、変化検出時のみ通知する情報か、定周
期で通知すべき情報かを監視対象ごとに区別する情報を
示す項目を、図１５の配信先記憶手段に付加してもよ
い。この情報区分を変更検出手段４４が参照することに
より、情報配信の動作タイミングを決定することができ
る。

【０１２２】次に、Ｓ１０６は、配信情報更新手段２５
を介して、データ統合部２中の各々の統合情報ビュー
（統合監視情報ビュー、統合記録情報ビュー、統合操作
情報ビュー）に対する更新情報を受信する。

【０１２３】Ｓ１０８は、この更新情報を、統合情報ビ
ュー記憶手段２１に対する受信情報として登録する。こ
の際、統合情報ビュー記憶手段２１には、「機器名」、
「現在状態」、「諸元データ」なる統合情報ビューが形
成されている。このため、Ｓ１０８では、受信した情報
をこれらの統合情報ビューの形式に対応付ける必要があ
る。この対応付けは、メタ情報記憶手段２３が保持する
図５乃至図７のメタ情報を参照することによって得られ
る。すなわち、温度計名と弁名は「機器名」に、現在温
度と開閉状態は「現在状態」に対応付く。一方、温度計
名称「Ｔ＊」は「温度計＊」に、弁名称「Ｂ＊」は「弁
＊」に対応付くことが理解される。この対応付けに従
い、Ｓ１０８は、受信情報を機器名、現在状態などに変
換して変換後の情報を統合情報ビュー記憶手段２１に登
録する。設備情報４ｃの諸元データが変更された場合
も、上記と同様に処理される。上記の処理により、例え
ば図１７に示すような統合情報ビューが形成される。

【０１２４】これらの統合情報ビューの更新と同時に、
配信情報更新手段２５はさらに、対応する統合アプリケ
ーション手段１１に対して、情報の更新を要求送受信手
段２２を介して伝えることができる。この更新情報の受
信によって、統合アプリケーション手段１１は、温度計
の値の変化や弁の開閉状態に変化があったことを認識す
ることができる。この更新情報の具体的な伝え方は、変
化が検出された機器名とその現在状態を伝える方法およ
び変化があったイベント情報のみを伝える方法など各レ
ベルでの伝達が可能である。後者の方法によれば、状態
変化を伝えられた統合アプリケーション手段１１は、さ
らに要求送受信手段２２を介して統合情報ビュー記憶手
段２１に登録されている情報を検索することとなる。

【０１２５】上記の統合情報ビューは、イベントドリブ
ンタイプの情報収集に効率的である。また、この統合情
報ビューは、各対象システムへのデータ送受信のオーバ
ーヘッドを不要にし、かつ対象システムの稼働とは無関
係なデータアクセスを可能とする。従って、統合アプリ
ケーション手段１１から高いアクセス頻度のデータを選
択した場合ほど有効であることが理解される。

【０１２６】尚、統合情報ビュー記憶手段２１の情報に
対しては、上述したように監視対象の全機器の状態変化
の際に、この状態変化が定期的あるいはイベント的に登
録される。ここで、統合監視アプリケーション１ａがあ
る時点で監視している情報は、上記の統合情報ビューに
登録されたデータのうちの一部である場合がある。以
下、この場合における統合監視アプリケーション１ａへ
の状態の伝達について説明する。

【０１２７】例えば温度計はプラント全体で１００個設
置されていて、ある時点で監視していた温度計が１０個
だけであるといった場合を想定する。かかる場合には、
監視している１０個の温度計情報だけを統合監視アプリ
ケーション１ａに伝える方が効率的であることが理解さ
れる。その他の情報については、統合情報ビュー記憶手
段２１に登録するのみで処理を終えることが望ましい。

【０１２８】この区別を実現するため、例えば図１８に
示すように、統合情報ビュー記憶手段２１で保持する統
合情報ビューの属性に、統合アプリケーション手段１１
が現在当該状態変化を必要としているか否かの情報を付
加することができる。図１８中のアプリ参照の属性がこ
の情報に対応する。図１８中で、アプリ参照の属性が
「ＯＮ」の情報は統合アプリケーション手段１１への通
知を必要としている情報で、「ＯＦＦ」の情報は通知不
要な情報であることを示している。このアプリ参照情報
の値（ＯＮまたはＯＦＦ）は、例えば統合監視アプリケ
ーション１ａで監視している情報が変化する都度、統合
情報ビュー記憶手段２１に要求送受信手段２２を介して
通知され更新される。

【０１２９】上記のように、統合情報ビュー記憶手段２
１に統合アプリケーション手段１１が現在通知を必要と
しているか否かを示す情報を付加することにより、Ｓ１
１０は、配信情報更新手段２５を介してこのアプリ参照
属性を参照し、通知の要否を判断することができる。Ｓ
１１２はここで、通知が必要とされているときのみ要求
元統合アプリケーション手段１１に更新情報をスルーで
通知する。一方、通知不要の場合は更新情報の通知を行
わない。但し、例えば事故発生のような状態変化や、温
度計の現在温度が規定範囲を逸脱したような場合には、
必ず統合アプリケーション手段に通知可能とすべく、図
１８に示すアプリ参照の属性欄には通知の条件を含めて
もよい。このように、統合アプリケーション手段１１へ
の通知の要否を区別することによって、データの送受信
に伴う負荷を減少させることができる。

【０１３０】第１の実施形態によれば、以下のような効
果が得られる。

【０１３１】すなわち、情報統合部２が、各情報モデル
ごとにメタ情報を介して統合アプリケーションから要求
されるデータ構造と各対象システムが処理可能なデータ
構造との間で変換処理を行う。これによって、機器名称
の違いやデータ構造の違いを意識することなく、さらに
関連する情報がどのシステムに存在し、どのシステムを
操作しなければならないかといった管理・保守操作が容
易になる。また、従来においては、例えば諸元データの
ような情報を異なるシステムで重複して保持する必要が
あったが、この重複保持が不要となりデータの一貫性保
持も容易となる。さらに、監視対象とすべき情報を統合
情報ビューとして情報統合部２に保持し、各対象システ
ム情報処理部４の配信先記憶手段４３に記憶することに
より、変更検出手段４４を介してモニタリングすること
ができる。これによって、効率よく、異種システムに分
散する情報の監視を行うことができる。

【０１３２】第２の実施形態以下、本発明の第２の実施形態について、第１の実施形
態と異なる点についてのみ、図面を用いて詳細に説明す
る。

【０１３３】第２の実施形態は、第１の実施形態におけ
る各統合アプリケーションを全体システムの観点から連
携動作させる機能を提供するものである。尚、ここで連
携とは、各アプリケーションが相互に連絡を取り合って
一つの動作を実現することをいう。

【０１３４】図１９に示すように、第２の実施形態に係
る異種間連携処理システムは、第１の実施形態の統合ア
プリケーション部１に替わり、あるいはこれに付加して
統合アプリケーション連携部６を備えて構成される。

【０１３５】統合アプリケーション連携部６は、各統合
アプリケーションを包含した連携型統合アプリケーショ
ンを有する。

【０１３６】図２０に示すように、統合アプリケーショ
ン連携手段６０は、統合アプリケーション手段１１と１
対１に対応する。統合アプリケーション連携手段６０
は、それぞれの統合アプリケーション手段１１を包含す
る形態で実現される。即ち、各統合アプリケーション手
段１１に対して、他統合アプリケーション手段と連携す
る為の手段を追加させる事によって統合アプリケーショ
ン連携手段６０が実現する。この統合アプリケーション
連携手段６０を持つ統合アプリケーション手段１１を、
以下連携型統合アプリケーション手段と称する。

【０１３７】図１９に示すように、第１の実施形態と同
じ例を用いる場合、各統合アプリケーション（１ａ、１
ｂ、１ｃ、１ｄ）に対応してそれぞれ連携型統合アプリ
ケーション（１ａ’、１ｂ’、１ｃ’、１ｄ’）が備え
られる。これら連携型統合アプリケーションは、後述す
るように相互に連携動作する。図１９中で、各統合アプ
リケーションと連携型統合アプリケーションとの差分の
部分（例えば１ａ’−１ａ）は、各統合アプリケーショ
ンを連携動作させるエンジン部分に相当する。

【０１３８】図２０に示すように、各々の連携型統合ア
プリケーション手段はさらに、他の連携型統合アプリケ
ーション手段と連携動作するための知識等を含む連携情
報処理手段６２と、システム全体としてどのような制御
を行うか等の全体目標に相当する情報を保持する目標情
報記憶手段６３と、他の統合アプリケーション手段と通
信するための通信機構６１とを備える。

【０１３９】尚、第２の実施形態のネットワーク構成は
第１の実施形態と同様であるため説明を省略する。

【０１４０】第２の実施形態に係る異種間連携処理シス
テムは上記のように構成されており、以下その連携処理
の流れにつき説明する。

【０１４１】目標情報記憶手段６３が保持するシステム
全体目標は、複数の異種システムを全体として把握した
場合に、どのように動作させたいか、を記述する。具体
的には、例えば第１には「機器故障検出から保守までの
ワークフローを作成せよ」などの全体ワークフロー形成
を行うという目標情報、第２には「利益最大」・「処理
時間最短」等の全体システムの最適化に関する目標情報
などが記述される。

【０１４２】これらの目標情報は、複数の統合アプリケ
ーション手段１１を統括するアプリケーション（図示せ
ず）によって、全体システム内に存在する全ての統合ア
プリケーション手段１１に一般に知られる同報（ブロー
ドキャスト）通信技術などを用いて通知される。あるい
は、これらの全体情報は、少なくとも１つ以上の関連す
る統合アプリケーション手段１１にマルチキャスト通信
によって通知される。同時に、これらの目標情報は、通
信機構６１を経て、統合アプリケーション連携手段６０
中の目標情報記憶手段６３に登録される。

【０１４３】連携情報処理手段６２には、各統合アプリ
ケーションが全体システム中で自分が処理可能な範囲・
制約条件など、連携処理に応じた手続き・知識が連携情
報として登録されている。

【０１４４】以下、まず第１に、目標情報がワークフロ
ー作成の場合の処理内容を説明する。個々の統合アプリ
ケーション手段１１は全体システム中で自身が処理を行
える範囲を把握している。図２１に示すように、この処
理可能範囲の情報は、連携情報処理手段６２が通信機構
６１を介して他の統合アプリケーション手段１１との間
で情報交換される。この情報交換により、統合アプリケ
ーション連携手段６０は、一連の処理フローを求める。

【０１４５】例えば、機器故障検出から保守までのワー
クフローを求める場合を想定すると、「監視」→「事故
判定」→「運転方策切り替え（代替運転モードへ）」→
「設備管理（保守部品の調達、保守）」→「運転方策切
り替え（正常運転モードへ）」のように、関連する統合
アプリケーション手段１１間の処理フローを決めること
ができる。このような自身の行える範囲や、他統合アプ
リケーション手段との間の役割分担に関する情報は、連
携情報処理手段６２に保持されている。但し、連携情報
処理手段６２は、システム全体に関する情報は含んでお
らず、個々の統合アプリケーション手段１１に関連する
情報のみが保持されている。上記のように生成されたワ
ークフローは、連携情報処理手段６２に保持される。例
えば機器故障が発生した場合は、保持されているワーク
フローに沿って各統合アプリケーション手段を連携動作
させることができる。

【０１４６】また、事前にこのようなワークフローが生
成されていなくてもよい。統合事故判定アプリケーショ
ン１ｂ’が、事故検出時に、関連する統合アプリケーシ
ョン手段群に対して目標情報として「保守までの一連動
作を実施」と通知すれば、上記同様の処理フローに沿っ
て、順次必要な統合アプリケーション手段１１を動作さ
せることができることは言うまでもない。逆に、予め保
守作業用のワークフローを連携情報処理手段６２に記憶
させておくことも可能である。

【０１４７】また、第２に、目標情報として利益最大や
処理時間最短を指定された場合の処理内容を説明する。

【０１４８】統合アプリケーション連携手段６０は、複
数の選択可能な処理（即ち処理に対応する統合アプリケ
ーション）の中から目標として与えられた指示に最も適
した統合アプリケーション手段１１を選択する。例え
ば、保守作業についての目標情報が「処理時間最短」で
示された場合、連携型統合アプリケーション中の連携情
報処理手段６２は自身が指定された保守作業を行うこと
ができるか否か判断する。

【０１４９】この指定された保守作業を行うことができ
る場合は、図２１に示すように、自身の処理予想時間を
通信機構６１を介して他の連携型統合アプリケーション
手段と交換し合う。連携情報処理手段６２は、通信機構
６１を介して他の連携型統合アプリケーション手段から
受信した処理予想時間が自身の処理予想時間より短けれ
ば、自身が保守作業を行うことを放棄する。また、例え
ば一定時間自身の処理予想時間より短い処理予想時間を
受信しない場合には、自身が最も短い時間で保守作業が
可能であるとみなして該当保守作業を実施してもよい。

【０１５０】また、上記のワークフロー作成と利益最大
等の目標を組み合わせることにより、目的に最も添った
処理を状況に応じて決定することができる。

【０１５１】第２の実施形態によれば、さらに以下のよ
うな効果が得られる。

【０１５２】すなわち、複数の異なるシステム間にまた
がった連携処理を、人間の判断を介在させずに迅速に行
うことが可能となる。これにより、予め決められた固定
的な連携処理だけではなく、予期せぬ事態に対しても状
況に応じて臨機応変に異種システムを跨って関連すべき
複数プログラムを連携させ、事態に柔軟に対応して最適
の処理結果を得ることが可能となる。

【０１５３】

【発明の効果】以上説明したように、本発明によれば、
以下に記載されるような効果を奏する。

【０１５４】即ち、本発明においては、異種システム間
に分散するデータにアクセスする統合アプリケーション
の単一のアクセス要求を各異種システムが処理可能なデ
ータアクセス要求に変換する機能を提供する。

【０１５５】このデータ構造変換機能により、各異種シ
ステムに分散するデータのデータ構造や存在場所から透
過な統一的アクセスを行うことができる。また、複数の
異なるシステム間に分散するデータの重複を無くしその
一貫性を保つとともに、アプリケーションに必要とする
データ構造を提供することができる。この提供されたデ
ータ構造に対してアプリケーションが操作することによ
り、実際のデータがどのシステムに存在し、どのような
データ構造で構築されているかを意識する必要がなくな
る。このため、異なるシステムに跨って保持する必要が
ある情報を必要に応じ、統一的に１つのデータのごとく
扱うことが可能となる。また、各アプリケーションを、
個別の各異種システム上で構築する必要がなくなり、ネ
ットワーク上の任意のシステム上に構築することが可能
となる。従って、既存のデータ資産を活用しつつ、柔軟
かつ効率的なアプリケーション構築が可能となる。

【０１５６】また、異種システム間に跨って存在するデ
ータのうち、定期的に監視対象とすべく選択したデータ
を統合情報ビューとしてキャッシュしてこのキャッシュ
されたデータにアクセスすることで、各対象システムへ
のデータアクセスを不要にすることができる。従って、
効率的かつ各システムの状態に依存しない、可用性の高
い処理を行うことが可能となる。

【０１５７】また、予め統合アプリケーションに通知す
べきデータを配信予約しておき、任意のタイミングで統
合情報ビューに反映することで、対象各システムでのデ
ータ内容に変更が生じた際に随時上記のキャッシュに通
知されるキャッシュ内容の変更のうち、アプリケーショ
ンに通知すべき変更のみを外部アプリケーションに通知
することができる。従って、各システムの保有するデー
タと外部アプリケーションの有する内部データとの間の
一貫性保持を容易に行うことが可能となる。

【０１５８】さらに、複数の統合アプリケーションの連
携機能を提供することで、異種システムに散在するアプ
リケーションを全体システムの目標に応じて柔軟に連携
動作させることができる。従って、人間系の判断を排除
して予期せぬ事象に対しても、迅速かつ状況に応じた異
種システムの活用が可能となる。

【０１５９】このように、本発明を用いれば、異種シス
テムの併存稼働環境において、各異種システムのデータ
構造に透過なアクセスが実現され、既存のデータ資産を
活用しつつ、柔軟かつ効率的なアプリケーションの構築
および連携が可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係る異種環境におけ
る分散情報処理システムのシステム構成を示す図であ
る。

【図２】異種システムからなるネットワーク構成の一例
を示す図である。

【図３】異種システムからなるネットワーク構成の他の
一例を示す図である。

【図４】本発明の第１の実施形態に係る分散情報処理シ
ステムの機能構成を示すブロック図である。

【図５】メタ情報記憶手段が保持する属性名の関係の一
例を示す図である。

【図６】メタ情報記憶手段が保持する属性値（機器名
称）の関係の一例を示す図である。

【図７】メタ情報記憶手段が保持する対象システム情報
と属性名リストとの関係の一例を示す図である。

【図８】第１の実施形態における属性名の対象システム
での具体的名称への変換処理アルゴリズムを示すフロー
チャートである。

【図９】第１の実施形態におけるデータ検索処理アルゴ
リズムを示すフローチャートである。

【図１０】セキュリティ管理手段が保持するアクセス権
リストの一例を示す図である。

【図１１】対象システム情報処理手段が保持する制御対
象設備情報の一例を示す図である。

【図１２】対象システム情報処理手段が保持する設備情
報の一例を示す図である。

【図１３】第１の実施形態におけるデータ更新処理アル
ゴリズムを示すフローチャートである。

【図１４】第１の実施形態における配信登録処理アルゴ
リズムを示すフローチャートである。

【図１５】配信先記憶手段が保持する配信先リストの一
例を示す図である。

【図１６】第１の実施形態における配信先リストに登録
された情報モデルの変更の際の変更情報の配信処理アル
ゴリズムを示すフローチャートである。

【図１７】統合情報ビュー記憶手段が保持する統合情報
ビューの一例を示す図である。

【図１８】統合情報ビュー保持手段が保持する統合情報
ビューの他の一例を示す図である。

【図１９】本発明の第２の実施形態に係る異種環境にお
ける分散情報処理システムのシステム構成を示す図であ
る。

【図２０】本発明の第２の実施形態に係る分散情報処理
システムの機能構成を示すブロック図である。

【図２１】本発明の第２の実施形態における複数の統合
アプリケーションの連携処理を説明する図である。

【図２２】従来技術における異種環境での分散情報処理
システムのシステム構成を示す図である。

【符号の説明】

１統合アプリケーション部２情報統合部３ネットワーク４対象システム情報処理部５処理対象データ６統合アプリケーション連携部１１統合アプリケーション手段２１統合情報ビュー記憶手段２２要求送受信手段２３セキュリティ管理手段２４メタ情報記憶手段２５配信情報更新手段２６情報配信要求手段２７情報問い合わせ手段２８情報更新手段４１メッセージ送信手段４２メッセージ受信手段４３配信先記憶手段４４変更検出手段４５検索手段４６更新手段４７情報モデル６０統合アプリケーション連携手段６１通信機構６２連携情報処理手段６３目標情報記憶手段

Claims

【特許請求の範囲】

【請求項１】異なるデータ体系を有するコンピュータ
システム間をネットワークを介して接続した異種環境に
おける分散情報処理システムであって、単一のデータアクセス要求を各対象システムが処理可能
なデータアクセス要求に変換を行う情報統合部と、単一のデータアクセス要求を介して前記各対象システム
に保持されるデータにアクセスする統合アプリケーショ
ン部とを具備することを特徴とする分散情報処理システ
ム。
【請求項２】前記情報統合部は、前記統合アプリケー
ション部が用いる第１のデータ構造と前記各対象システ
ムが有する第２のデータ構造との対応付けを示すメタ情
報を記憶し、該メタ情報に基づき前記変換を行うことを特徴とする請
求項１に記載の分散情報処理システム。
【請求項３】前記メタ情報は、少なくとも、前記第１のデータ構造と前記第２のデータ構造との属性
名の対応付けデータ、前記第１のデータ構造と前記第２
のデータ構造との属性値の対応付けデータ、および前記
各対象システムの有する前記属性名のリストのいずれか
１つ以上を含むことを特徴とする請求項２に記載の分散
情報処理システム。
【請求項４】上記分散情報処理システムは、さらに、各対象システムを包含する全体システムの目標に応じ
て、複数の前記統合アプリケーション部を連携動作させ
る統合アプリケーション連携部を具備することを特徴と
する請求項１乃至３のいずれか記載の分散情報処理シス
テム。
【請求項５】前記統合アプリケーション連携部は、前記目標に対応する前記連携処理における各統合アプリ
ケーション部の処理範囲および／または処理順序を含む
連携情報を記憶する連携情報処理手段を具備し、前記連携情報処理手段は、前記連携情報に基づいて、複
数の前記統合アプリケーションを連携動作させることを
特徴とする請求項４に記載の分散情報処理システム。
【請求項６】前記情報統合部は、さらに、前記第１のデータ構造の属性名の中で前記統合アプリケ
ーション部が収集すべき属性名および該属性名に対応す
る属性データを統合情報ビューとして記憶する統合情報
ビュー記憶手段を有し、前記統合アプリケーション部からデータアクセス要求さ
れるデータが、前記統合情報ビューに存在する場合に
は、該統合情報ビュー中のデータのアクセス結果を前記
統合アプリケーション部に送信することを特徴とする請
求項１乃至５のいずれか記載の分散情報処理システム。
【請求項７】前記情報統合部は、さらに、各対象システムからのデータ配信要求を、前記メタ情報
に基づいて変換し、該変換後の前記データ配信要求を、対応する前記統合情
報ビュー中の対応する属性データに反映する配信情報反
映手段を具備することを特徴とする請求項６に記載の分
散情報処理システム。
【請求項８】前記情報統合部は、さらに、前記統合情報ビュー中の全部または一部の属性データの
配信を、各対象システムに対して要求する情報配信要求
手段を具備することを特徴とする請求項７に記載の分散
情報処理システム。
【請求項９】前記統合情報ビューは、さらに、前記統合アプリケーション部が前記統合情報ビュー中の
各データの通知を必要とするか否かを示す参照データを
含み、前記配信情報反映手段は、各対象システムから配信され
る属性データに対応する参照データが通知を必要とする
値を示す場合に、前記配信される属性データを前記統合
アプリケーション部に送信することを特徴とする請求項
７または８に記載の分散情報処理システム。
【請求項１０】前記情報統合部は、さらに、前記各統合アプリケーションの前記各対象システムに対
するアクセス権限を記憶するセキュリティ管理手段を具
備し、送信元の前記統合アプリケーションが、アクセス要求先
の前記対象システムに対する前記アクセス権限を有する
場合に、前記アクセス要求を前記対象システムに送信す
ることを特徴とする請求項１乃至９のいずれか記載の分
散情報処理システム。
【請求項１１】前記情報統合部は、さらに、前記各対象システム間へのデータ更新要求の結果に応じ
て、関連する全ての更新要求が成功である場合に、該更
新要求を有効化する情報更新手段を具備することを特徴
とする請求項１乃至１０のいずれか記載の分散情報処理
システム。
【請求項１２】異なるデータ体系を有するコンピュー
タシステム間をネットワークを介して接続した異種環境
における分散情報処理システムであって、対象システムごとに設けられ、該対象システムが保持す
るデータのデータ体系に応じて、前記情報統合部へのデ
ータ送信を行う対象システム情報処理部と単一のデータ
アクセス要求を、各対象システムが処理可能なデータア
クセス要求に変換を行う情報統合部と、単一のデータアクセス要求を介して前記各対象システム
に保持されるデータにアクセスする統合アプリケーショ
ン部と、を具備することを特徴とする分散情報処理システム。
【請求項１３】異なるデータ体系を有する複数のコン
ピュータシステムに対してデータアクセスを行う対異種
システム通信装置であって、アプリケーションが用いる第１のデータ構造と各対象シ
ステムが有する第２のデータ構造との対応付けを示すメ
タ情報に基づいて、前記アプリケーションからのデータ
アクセス要求を各対象システムが処理可能なデータアク
セス要求に変換を行う情報統合部を具備することを特徴
とする対異種システム通信装置。
【請求項１４】ネットワークを介して接続された、異
なるデータ体系を有するコンピュータシステム間の処理
を行う異種環境における分散情報処理方法であって、各対象システムに保持されるデータに対する単一の第１
のデータアクセス要求を受信するステップと、前記第１のデータアクセス要求を各対象システムが処理
可能な第２のデータアクセス要求に変換を行うステップ
と、前記第２のデータアクセス要求を、前記第１のデータア
クセス要求がアクセスすべきデータが存在する各対象シ
ステムに対し、該対象システムごとに送信するステップ
とを含むことを特徴とする分散情報処理方法。
【請求項１５】ネットワークを介して接続された、異
なるデータ体系を有するコンピュータシステム間の処理
を行う異種環境における分散情報処理プログラムを格納
したコンピュータ読み取り可能な記録媒体であって、各対象システムに保持されるデータに対する単一の第１
のデータアクセス要求を受信するステップと、前記第１のデータアクセス要求を各対象システムが処理
可能な第２のデータアクセス要求に変換を行うステップ
と、前記第２のデータアクセス要求を、前記第１のデータア
クセス要求がアクセスすべきデータが存在する各対象シ
ステムに対し、該対象システムごとに送信するステップ
とを含むことを特徴とする分散情報処理プログラムを格
納したコンピュータ読み取り可能な記録媒体。