(57)【要約】      （修正有）【課題】アプリケーション要素間の利用関係を把握できる分散アプリケーションシステムを提供する。【解決手段】アプリケーション要素の動作に基づいて、連携の可否を判断するためのインタフェース情報を定義する連携インタフェース定義部と、前記アプリケーション要素の動作に基づいて、連携先アプリケーション要素に対して前記インタフェース情報を送信すると共に、受信した他のアプリケーション要素のインタフェース情報と自己のインタフェース情報とを比較して連携の可否を判断する連携先管理部と、連携可能と判断された場合に、前記アプリケーション要素の動作に基づいて、前記連携先アプリケーション要素とデータを交換するデータ交換部と、を有することを特徴とする分散アプリケーションシステム。【選択図】図１
2006350580.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーション要素が分散配置され、これらアプリケーション要素を連携動作させて構築される分散アプリケーションシステムにおける装置において、
前記アプリケーション要素の動作に基づいて、連携の可否を判断するためのインタフェース情報を定義する連携インタフェース定義部と、
前記アプリケーション要素の動作に基づいて、連携先アプリケーション要素に対して前記インタフェース情報を送信すると共に、受信した他のアプリケーション要素のインタフェース情報と自己のインタフェース情報とを比較して連携の可否を判断する連携先管理部と、
連携可能と判断された場合に、前記アプリケーション要素の動作に基づいて、前記連携先アプリケーション要素とデータを交換するデータ交換部と、
を有することを特徴とする分散アプリケーションシステムにおける装置。
【請求項２】
前記インタフェース情報は、データの型、データの送受信方式およびデータの送受信の方向性であることを特徴とする請求項１に記載の分散アプリケーションシステムにおける装置。
【請求項３】
前記連携先管理部は、前記連携先アプリケーション要素を特定する情報を有する連携先指示部を備えることを特徴とする請求項１または請求項２に記載の分散アプリケーションシステムにおける装置。
【請求項４】
前記連携先管理部は、連携可能と判断した前記連携先アプリケーション要素を登録することを特徴とする請求項１から請求項３のいずれかに記載の分散アプリケーションシステムにおける装置。
【請求項５】
前記連携先管理部は、前記連携先アプリケーション要素に対する連携状態を保存することを特徴とする請求項１から請求項４のいずれかに記載の分散アプリケーションシステムにおける装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に接続された複数の機器にアプリケーション要素を分散配置し、ネットワークを介してアプリケーション要素間で通信を行う分散アプリケーションシステムおける装置に関し、特に、フィールドに存在するセンサ、コントローラ、コンピュータなどの多種多数のフィールド機器上に構築されたアプリケーション要素同士がダイナミックに協調動作する仕組みに関する。
【背景技術】
【０００２】
従来のセンサ、アクチュエータ、コントローラ、コンピュータなどのフィールド機器は、例えばプロセス制御に用いられ、制御点や制御用計測点などの主要な箇所にセンサやアクチュエータを配置し、コントローラやコンピュータにより、目的とする制御が正確に行われるようなシステム設計がなされている。
【０００３】
このような、フィールド機器の分野においても、効率的なリソースの利用を考えると、ソフトウェアを機能に応じて分割（部品化）することが求められる。これにより、ソフトウェアの再利用性が高まり、一部を修正しても全体を構築しなおさずに済むので開発効率が向上する。また、分割したソフトウェアを複数のフィールド機器で役割分担して実行することにより、効率的なリソースの活用が可能となる（例えば、特許文献１参照。）。
【０００４】
【特許文献１】特開２０００−２７８２９７号公報
【０００５】
複数の機器上に分散して存在するアプリケーション要素（以下、ＡＰ要素という。）であるソフトウェア（オブジェクト）を、ネットワークを介して協調動作させることによりアプリケーションを構築する分散アプリケーションシステムに係る技術として、分散オブジェクト技術が知られている。
【０００６】
図９は、分散オブジェクト技術の仕組みを説明する説明図である。
図９において、機能ブロックＡは、ＡＰ要素であって、図示しない機器上に存在するオブジェクトにより実現される一機能を示す。同様に、機能ブロックＢは、ＡＰ要素であって、図示しない同一機器または他の機器上に存在するオブジェクトにより実現される一機能を示す。
【０００７】
分散オブジェクト技術に共通する基本的な仕組みは、機能ブロックＡを提供する場合、機能ブロックＡ側では、まずその機能を関数やメソッドといった単位で特定し、これら関数やメソッドの利用方法を定義したインタフェース定義９１を公開する（公開インタフェース）。機能ブロックＢ側では、この定義情報に基づき、図示しないネットワークを介して関数やメソッドを呼び出す処理を行う代理オブジェクトを生成する。
【０００８】
また、機能ブロックＡ側では、ＡＰ要素の呼び出しに対応する処理を行う代理オブジェクトを生成する。これらの代理オブジェクトを通して関数やメソッドなどのＡＰ要素の呼び出しを行うことで、いずれの側でもローカルな呼び出しと同じように処理することができるようになる。
【０００９】
このような分散オブジェクト技術では、インタフェース定義を公開する側がサーバで、利用する側がクライアントという位置づけとなり、クライアント側はサーバ側に合わせて実装され、実行時には、常にサーバ側が先に存在することが前提となっている。
従って、クライアントとして作成された機能は外部から利用できないし、既に動作しているクライアントに対し、サーバを変更したり追加したりすることは難しい。
【００１０】
図１０は、従来の分散アプリケーションシステムにＡＰ要素を追加する場合を説明する説明図である。なお、以下に記載する機器とは、例えばフィールド機器である。
【００１１】
図１０（ａ）において、図示しない第１の機器に、データを提供するＡＰ要素Ａと、そのデータを利用して何らかの処理を行うＡＰ要素Ｂから構成されるシステムがあり、ＡＰ要素Ａのデータ取得用のインタフェース定義１０１を公開し、それに合わせてＡＰ要素Ｂが実装されているとする。
【００１２】
図１０（ｂ）において、さらに図示しない第２の機器に実装され、第２の機器のデータを提供するＡＰ要素Ｃを追加し、ＡＰ要素Ｂに第２の機器のデータも利用させようとしても、ＡＰ要素Ｂをサーバとして改造しなければならず、そのままではできない。
【００１３】
かといって、図１０（ｃ）のように、ＡＰ要素Ｂをサーバとして最初にＡＰ要素Ｂのインタフェース定義１０２を公開し、それにＡＰ要素Ａが合わせるようにしていたとしても、ＡＰ要素Ｃの追加はできるが、逆にＡＰ要素Ａが提供するデータを、後からＡＰ要素Ｄを追加して別の処理に利用することができないという問題がある。
【００１４】
また、フィールドでのアプリケーションは、センサやアクチュエータなどのデータをやり取りして、監視や保存、日報などへの加工をするといったように、個々のプログラム要素の生存期間が長く、特定の相手との継続的かつ周期的なやり取りとなる傾向があり、双方にとってお互いの状態の変化は重要な関心事である。
【００１５】
例えば、データのやり取りが発生していない間であっても、次回のやり取りに備え、相手の状態変化を検知できることが望まれる。非常事態のアラーム通知のように、データのやり取りは滅多に発生しないが、発生したときには確実に通知したい場合などは特に、利用関係の継続的な把握が重要である。
【００１６】
しかし、上述の分散オブジェクト技術では、不特定多数のクライアントから１回限りのリクエストが送られてくるような場合が多く、これをフィールド機器に適用した分散アプリケーションシステムでは、接続先の継続的な管理や、状態の変化について把握できないという問題があった。
【００１７】
本発明は、このような従来の分散アプリケーションシステムにおける機器が有していた問題を解決しようとするものであり、それぞれのＡＰ要素がインタフェース定義を公開し、その情報に基づいてＡＰ要素同士が接続することにより、アプリケーションの初期構築時だけでなく、運用開始後であっても、動作中のＡＰ要素を止めずにその機能を利用するＡＰ要素を新たに追加でき、データのやり取りが発生していない間も、ＡＰ要素間の利用関係を把握できる分散アプリケーションシステムにおける装置を提供すること目的とする。
【発明の開示】
【課題を解決するための手段】
【００１８】
本発明は次の通りの構成になった分散アプリケーションシステムにおける装置である。
【００１９】
（１）複数のアプリケーション要素が分散配置され、これらアプリケーション要素を連携動作させて構築される分散アプリケーションシステムにおける装置において、
前記アプリケーション要素の動作に基づいて、連携の可否を判断するためのインタフェース情報を定義する連携インタフェース定義部と、
前記アプリケーション要素の動作に基づいて、連携先アプリケーション要素に対して前記インタフェース情報を送信すると共に、受信した他のアプリケーション要素のインタフェース情報と自己のインタフェース情報とを比較して連携の可否を判断する連携先管理部と、
連携可能と判断された場合に、前記アプリケーション要素の動作に基づいて、前記連携先アプリケーション要素とデータを交換するデータ交換部と、
を有することを特徴とする分散アプリケーションシステムにおける装置。
【００２０】
（２）前記インタフェース情報は、データの型、データの送受信方式およびデータの送受信の方向性であることを特徴とする（１）に記載の分散アプリケーションシステムにおける装置。
【００２１】
（３）前記連携先管理部は、前記連携先アプリケーション要素を特定する情報を有する連携先指示部を備えることを特徴とする（１）または（２）に記載の分散アプリケーションシステムにおける装置。
【００２２】
（４）前記連携先管理部は、連携可能と判断した前記連携先アプリケーション要素を登録することを特徴とする（１）から（３）のいずれかに記載の分散アプリケーションシステムにおける装置。
【００２３】
（５）前記連携先管理部は、前記連携先アプリケーション要素に対する連携状態を保存することを特徴とする（１）から（４）のいずれかに記載の分散アプリケーションシステムにおける装置。
【発明の効果】
【００２４】
本発明によれば、以下のような効果がある。
【００２５】
請求項１から請求項３に記載の発明によれば、それぞれのＡＰ要素がインタフェース定義を公開（送受信）し、その情報に基づいてＡＰ要素同士が接続することにより、アプリケーションの初期構築時だけでなく、運用開始後であっても、動作中のＡＰ要素を止めずにその機能を利用するＡＰ要素を新たに追加できる。
【００２６】
請求項４および請求項５に記載の発明によれば、連携先の登録や連携状態の保存により、データのやり取りが発生していない間も、ＡＰ要素間の利用関係を把握できる。
【発明を実施するための最良の形態】
【００２７】
以下図面を用いて本発明を詳細に説明する。
図１は、本発明が適用されるフィールド機器の一例を示す構成図である。
図１に記載したフィールド機器１０は、例えばセンサ、制御機器、コントローラ、コンピュータなどである。
【００２８】
図１において１１はフィールド機器全体を制御するＣＰＵ等の演算制御手段、１２はＡＰ要素が格納等されるハードディスク、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、フラッシュメモリ等の記憶手段、１３はネットワークを介して通信を行なうネットワークカード等の通信手段である。なお、図示しないが、フィールド機器１０は、マンマシンインタフェースである操作手段を具備させてもよく、この場合は、作業者による直接の操作が可能となる。
【００２９】
記憶手段１２の入出力は演算制御手段１１に相互に接続され、通信手段１３の入出力もまた演算制御手段１１に相互に接続される。また、通信手段１３はネットワーク（図示せず。）に接続される。
【００３０】
図２は、本発明が適用されたフィールド機器により構成されるシステムの一例を示す構成図である。
【００３１】
図２において２１，２２，２３はセンサまたはアクチュエータ等、２４，２５はコントローラ、サーバ等、２６は操作コンソールや上位サーバである。これらフィールド機器は、図示しないネットワークを介して相互に接続される。
【００３２】
なお、センサ、アクチュエータの他に、ネットワークには、通信測定器、計測器、記録装置などのフィールド機器も接続される。
【００３３】
このような、フィールド機器およびそのシステムを実施例に用いて本発明を以下に詳細に説明する。
【００３４】
本発明では、他のＡＰ要素と機能的に関わりを持つＡＰ要素があった場合、双方のＡＰ要素がそれぞれインタフェース定義を公開（送受信）する。
ここで、この仕組みによってＡＰ要素同士が接続し動作することを「連携」すると呼び、ＡＰ要素が接続の口として定義するインタフェースを「連携インタフェース定義」と呼ぶ。
【００３５】
連携インタフェース定義では、やり取りされるデータに着目し、以下の３項目のインタフェース情報について規定する。
１データの型（ＡＰ要素ごとに固有）
２データ送受信の方式（イベントタイプ、応答タイプなど）
３データ送受信の方向性（データを送信する側か、受信する側か）
【００３６】
この定義は、各ＡＰ要素がそれぞれ独立に保持するものであり、数値や属性情報などにより構成され、ＡＰ要素独自の形式となっているデータの型と送受信方式が一致し、送受信の方向性が逆のもの同士が連携できる。データの型や送受信方式が一致しなかったり、同じ方向性である場合は、連携できない。
【００３７】
図３は、本発明が適用されたフィールド機器上で動作するＡＰ要素とフレームワーク部の関係を示す説明図である。なお、図３は、ＡＰ要素およびフレームワーク部が動作したときに生成される機能ブロックによる概念的構成を示すものである。
【００３８】
図３において、連携を行うＡＰ要素３，５，７は、その動作に基づいて、それぞれ連携インタフェース定義部３３，５３，７３とＡＰ固有機能部３１，５１，７１とフレームワーク提供部３２，５２，７２から構成される。
【００３９】
図３の３３，５３，７３のように連携インタフェース定義を概念的に図示すると、３３ａがデータの型、３３ｂ，３３ｃがデータの送受信方式と方向性を示し、３３ｂが送信側、３３ｃが受信側である。塗り潰した側が定義された方向性を示す。
【００４０】
ＡＰ固有機能部３１，５１，７１は、ＡＰ固有機能を実装する部分であって、ＡＰ要素ごとに異なる。連携機能に関しては、データ送信側であれば、送信するデータの生成を、データ受信側であれば、受信したデータに対する処理を行う部分を実装する。本実施例では、ＡＰ要素３およびＡＰ要素７がデータ送信側でＡＰ要素５が、データ受信側である。
【００４１】
このＡＰ固有機能部が連携し、フィールド機器の分野であれば、生産管理システムなどのアプリケーションを構成する。
なお、本実施例ではＡＰ要素が３要素の場合について説明するが、ＡＰ要素の数は３つに限るものではない。
【００４２】
また、ＡＰ要素３とＡＰ要素５，７とは異なる機器（フレームワーク部）上に実装されているがこの構成に限定するものではなく、全てのＡＰ要素は異なる機器上に実装されていても良いし、全てのＡＰ要素が同一の機器上に実装されていても良い。
【００４３】
フレームワーク提供部３２，５２，７２は、フレームワーク部４，６２が、その動作に基づいて、提供する部分であって、連携のために必要な基本的な機能が含まれる。
本実施例では、ＡＰ要素３およびフレームワーク部４が第１のフィールド機器に実装され、第２のフィールド機器にＡＰ要素５，７およびブレームワーク部６が実装されるものとする。
【００４４】
フレームワーク提供部３２は、データ交換部３２１と連携先管理部３２２から構成され、フレームワーク提供部５２は、データ交換部５２１と連携先管理部５２２から構成され、フレームワーク提供部７２は、データ交換部７２１と連携先管理部７２２から構成される。
【００４５】
データ交換部３２１，５２１，７２１は、各ＡＰ要素が有する連携インタフェース定義（ＡＰ要素３では３３，ＡＰ要素５では５３，ＡＰ要素７では７３）のそれぞれの規定に従って、連携先管理部３２２，５２２，７２２にて管理されている連携先に対し、データを送受信する部分である。
【００４６】
ＡＰ要素がデータ送信側であれば、連携インタフェース定義で規定された型のデータをＡＰ固有機能部から入手し、連携インタフェース定義で規定された方法で送信する。データ受信側であれば、連携インタフェース定義で規定されたデータを連携インタフェース定義で規定された方法で受信し、ＡＰ固有機能部に受け渡す。
【００４７】
データ送受信の方式のうち、代表的ないくつかのタイプはフレームワーク部４，６で用意するが、ＡＰ要素に固有の方式を拡張して組み込むこともできる。
【００４８】
連携先管理部３２２，５２２，７２２は、データの送受信を行う相手である連携先を管理する部分である。連携先管理部３２２，５２２，７２２は、それぞれ連携先記憶部３２３，５２３，７２３を有し、それぞれの連携先記憶部３２３，５２３，７２３に実行時に実際に連携している（または連携しようとしている）相手についての情報を保存する。この情報は、実際に連携している場合には、例えば機器およびＡＰ要素に予め付けられた識別子などの連携先を特定できる情報であり、待機中であればその旨を示す情報を保存する。
【００４９】
連携先は、連携先管理部３２２，５２２，７２２により、フレームワーク部４，６内の連携先指示部４１，６１，６２に予めＡＰ要素ごとに設定され格納された連携先の設定情報に基づき判断される。
なお、この連携先の設定情報は、例えば機器およびＡＰ要素に予め付けられた識別子などの連携先を特定できる情報であり、ＡＰ要素の実装時に既に設定されていても良いし、ＡＰ要素実装後、作業者が各フィールド機器のマンマシンインタフェースや図２の操作コンソールや上位サーバから設定しても良い。
【００５０】
連携先管理部３２２，５２２，７２２は、連携の可否チェック（連携インタフェース定義同士の適合／不適合）にて連携可能と判断できる相手であれば、それぞれの連携先記憶部３２３，５２３，７２３に複数箇所を登録することができる。また、個々の連携先の登録・削除処理はそれぞれ独立しているため、ある連携先とデータのやり取りを開始している状態でも、別の連携先の登録または削除処理を行うことができる。
【００５１】
なお、フレームワーク部はＡＰ要素に対して上述したデータ交換部や連携先管理部といった機能を提供するミドルウェアに相当し、このようなミドルウェアやＡＰ要素は、図１で示した記憶手段１２に格納され、これらは演算制御手段１１により実行され動作する。
また、上記の連携先記憶部や連携先指示部などへの保存情報も実際には記憶手段１２に格納される。
さらに、異なる機器間でのデータのやり取りは通信手段１３からネットワークを介して行う。
【００５２】
図４は連携の全体的な流れを示すフローチャートである。
図４を用いて各処理ステップ毎に説明する。
【００５３】
（Ｓ１０１）ＡＰ要素が動作し、連携先と連携関係を確立しようとする。
これに際し、連携可否チェックで適合しないなど、連携が許可されず、連携関係の確立に失敗すると、連携処理自体が終了する。ただし、連携先として指定されたＡＰ要素がまだ起動していない場合などは、失敗とは判断せずに待機状態となり、連携先が起動した時点で、連携関係を構築できるかどうか交渉する。
（Ｓ１０２）連携関係の確立に成功すると、双方にお互いが実行時連携先として登録される。
（Ｓ１０３）この状態で、必要に応じてデータの送受信処理を行う。
（Ｓ１０４）その後、ＡＰ要素の停止など、連携関係を継続しがたい事由が発生すると、連携先に対して、自身の状態の変化を通知し、連携関係を解消してもらう。
【００５４】
以上のうち、ポイントとなる次の３つの動作について、さらに図を用いて詳細に説明する。
１連携関係を確立するまでの流れ
２連携関係の解消の流れ
３データ送受信の流れ
【００５５】
図５，図６は、連携関係を確立するまでの流れを説明する説明図である。
図５は、連携関係を確立するまでの流れを、連携関係を構築しようとする二つのＡＰ要素のうち、一方が先に起動して待機状態になるまでを示している。図６は、後からもう一方が起動して確立が完了するまでを示す。例として、データ受信側が先に起動するパターンを記述するが、逆の場合も基本的には同様である。
【００５６】
図５を用いて一方のＡＰ要素（データ受信側）が先に起動するまでの動作を各処理手順に従って説明する。
【００５７】
（Ｓ２０１）データ受信側のＡＰ要素５が起動し、連携を開始すると、まず、連携先管理部５２２が、連携先指示部６１の連携先の設定情報を参照し、連携先を取得する。
（Ｓ２０２）（Ｓ２０１）の工程で取得した連携先に対し、連携先管理部５２２が通信手段を介して自身の連携インタフェース定義をＡＰ要素３に送信すると共にＡＰ要素３からのインタフェース定義の返信を要求し連携関係の確立交渉を行う。
（Ｓ２０３）連携先（ＡＰ要素３）がまだ起動していないため、この連携先に関しては、連携先管理部５２２はひとまず待機状態となる。
【００５８】
図６を用いて他方（データ送信側）のＡＰ要素が後から起動した場合の動作を各処理手順に従って説明する。
【００５９】
（Ｓ３０１）データ受信側のＡＰ要素５は、これから起動しようとしているデータ送信側に対する連携関係について、既に待機状態である。
（Ｓ３０２）データ送信側のＡＰ要素３が起動し、連携を開始すると、連携先管理部３２２が、連携先指定部４１の連携先の設定情報を参照し、連携先を取得する。
この連携先が（Ｓ３０１）の工程で待機状態となっているＡＰ要素５であるとする。
（Ｓ３０３）（Ｓ３０２）の工程で取得した連携先に対し、連携先管理部３２２がデータ交換部３２１を介して連携インタフェース定義をＡＰ要素５に送信すると共にＡＰ要素５からのインタフェース定義の返信を要求し連携関係の確立交渉を行う。
（Ｓ３０４）ＡＰ要素３，５双方の連携先管理部３２２，５２２は、お互いの連携インタフェース定義３３，５３を交換し、自身のそれと照らし合わせて、連携可否チェックを行う。
（Ｓ３０５）双方で連携可否チェックが通れば、連携関係の確立は成功で、お互い、相手を実行時連携先として連携先記憶部３２３，５２３に登録する。連携可否チェックが通らなければ、連携関係の確立は失敗で、連携終了となる。
【００６０】
次に連携関係が確立されている二つのＡＰ要素の間で、連携関係を解消し、連携を終了する場合の流れを説明する。例として、データ送信側に連携関係を継続しがたい事由（ＡＰ要素の停止）が発生し、連携関係を解消するパターンを記述するが、逆の場合も基本的には同様である。
【００６１】
図７は、連携関係の解消の流れを説明する説明図である。
図７を用いて連携関係を解消するまでの動作を各処理手順に従って説明する。
【００６２】
（Ｓ４０１）データ送信側のＡＰ要素３が停止することになり、連携を終了しようとすると、まず、連携管理部３２２が、連携先記憶部３２３から、連携関係を確立済みの連携先を取得する。
（Ｓ４０２）（Ｓ４０１）の工程で取得した連携先に対し、連携先管理部３２２が、自身の状態変化（停止）を通知することで、連携関係の解消を申し出る。
（Ｓ４０３）連携先管理部３２２，５２２が実行時連携先情報を連携先記憶部から削除する。
（Ｓ４０４）停止していないデータ受信側のＡＰ要素５では、データ送信側が再度起動した場合に備え、この連携先に対しては、待機状態に戻る。
【００６３】
次に連携関係が確立されたＡＰ要素の間でのデータ送受信の流れについて説明する。データ送受信の方式には、データ送信側からデータ受信側にデータを送り込むだけの場合（イベントタイプ）や、データ送信側からデータ受信側にデータを送り込むと、それに対してデータ受信側からデータ送信側へ応答を返す場合（応答タイプ）など、いくつか考えられるが、ここでは、イベントタイプを例に記述する。
【００６４】
図８は、ＡＰ要素間のデータ送受信の流れを説明する説明図である。
図８を用いてデータ送受信の動作を各処理手順に従って説明する。
【００６５】
（Ｓ５０１）データ送信側のＡＰ要素３のＡＰ固有機能部３１でデータが生成され、データ送信を開始すると、まず、生成したデータをデータ交換部３２１に渡す。
（Ｓ５０２）データ交換部３２１は、連携先処理部３２２から、その時点で連携関係が確立されている実行時連携先を取得する。
（Ｓ５０３）（Ｓ５０２）の工程で取得した連携先のＡＰ要素５のデータ交換部５２１に対して、データ交換部３２１は、自身の連携インタフェース定義の規定に従って、データ送信処理を行う。
（Ｓ５０４）データ受信側のＡＰ要素５のデータ交換部５２１では、データを受けると、連携先処理部５２２から、その時点で連携関係が確立されている実行時連携先を取得し、送られてきたデータの送信元と照らし合わせる。
（Ｓ５０５）連携先として登録された相手からのデータであることが確認できたら、データ交換部５２１は、自身の連携インタフェース定義の規定に従って、データ受信処理を行う。
（Ｓ５０６）データ交換部５２１は、（Ｓ５０５）の工程で受信したデータを、ＡＰ固有機能部５１に渡して処理をさせる。
【００６６】
以上のように、本発明によれば、ＡＰ要素間でやり取りされるデータの型、送受信方式、送受信の方向性の３項目を連携インタフェース定義として規定し、各ＡＰ要素がこの連携インタフェース定義を公開することにより、データ交換に先立ち、連携関係を構築する。
また、ＡＰ要素は、動作中に自己の連携先の登録や削除ができるので、データのやり取りが発生していない間も、ＡＰ要素間の利用関係を把握できる。
【００６７】
従って、アプリケーションの初期構築時だけでなく、運用開始後であっても、動作中のＡＰ要素を止めずにその機能を利用するＡＰ要素を新たに追加でき、データのやり取りが発生していない間も、ＡＰ要素間の利用関係を把握できる分散アプリケーションシステムを実現できる。
【００６８】
なお、本発明は、上記実施例に限定されることなく、その本質から逸脱しない範囲で更に多くの変更、変形をも含むものである。
【００６９】
例えば、本出願人による特願２００４−３３３２７７に記載の発明に適用してもよい。特願２００４−３３３２７７に記載の発明は、フィールド機器に対する機能（業務：具
体的にはアプリケーションプログラム）の追加が容易で追加された機能（業務）が互いに独立して動作することが可能なフィールド機器及びこれを用いたシステムを実現するものである。
【００７０】
このために、ネットワークに接続されシステムを構成するフィールド機器において、記憶手段と、ネットワークを介して通信を行う通信手段と、実行環境上に主業務を動作させて機器全体を制御すると共に実行環境上に動作機構を動作させる演算制御手段とを備え、動作機構が動作機構上に追加業務を起動させる場合に追加業務にグループ識別子を割り当てると共に追加業務に固有のアドレス空間及び名前空間を割り当てる構成となっている。
【００７１】
固有のアドレス空間および名前空間が割り当てられ、同一のグループ識別子で管理される複数の追加業務の連携を、他のグループ識別子で管理される複数の追加業務の連携から独立した仮想システムとして取り扱うことにより、仮想システム間での干渉等が生じない。
【００７２】
従って、起動された追加業務が互いに干渉することなく独立して動作することが可能になる。また、追加業務の動作に起因して主業務に対して生じる影響を回避させることができる。
【００７３】
このような、フィールド機器に対して、本発明を適用すると、追加された業務システムそのものに対して新たな目的が発生した場合に、動的にＡＰ要素を追加し、既に稼動しているＡＰ要素と連携させることで、業務システムを止めることなく、機能を追加することができる。言わば、重畳された業務自体を成長させることができるようになる。
【００７４】
即ち、追加業務システム自体を複数個、独立して重畳することで、新たな業務要求への対応を可能とした上記構成に、本発明を適用することで、さらに、重畳された個々の業務システムの中でも、柔軟に新たな要求に対応することができるようになる。
【図面の簡単な説明】
【００７５】
【図１】本発明が適用されるフィールド機器の一例を示す構成図である。
【図２】本発明が適用されたフィールド機器により構成されるシステムの一例を示す構成図である。
【図３】本発明が適用されたフィールド機器上で動作するＡＰ要素とフレームワーク部の関係を示す説明図である。
【図４】連携の全体的な流れを示すフローチャートである。
【図５】連携関係を確立するまでの流れを説明する説明図である。
【図６】連携関係を確立するまでの流れを説明する説明図である。
【図７】連携関係の解消の流れを説明する説明図である。ある。
【図８】ＡＰ要素間のデータ送受信の流れを説明する説明図である。
【図９】分散オブジェクト技術の仕組みを説明する説明図である。
【図１０】従来の分散アプリケーションシステムにＡＰ要素を追加する場合を説明する説明図である。
【符号の説明】
【００７６】
３、５、７  アプリケーション要素
４、６  フレームワーク部
１１  演算制御手段
１２  記憶手段
１３  通信手段
２１〜２３  センサ／アクチュエータ
２４、２５  コントローラ／サーバ
２６  操作コンソール／上位サーバ
３３、５３、７３  インタフェース定義部
３１、５１、７１  ＡＰ固有機能部
３２、５２、７２  フレームワーク提供部
４１、６１、６２  連携先指示部
３２１、５２１、７２１  データ交換部
３２２、５２２、７２２  連携先管理部
３２３、５２３、７２３  連携先記憶部
【図１】
2006350580.tif 000003
【図２】
2006350580.tif 000004
【図３】
2006350580.tif 000005
【図４】
2006350580.tif 000006
【図５】
2006350580.tif 000007
【図６】
2006350580.tif 000008
【図７】
2006350580.tif 000009
【図８】
2006350580.tif 000010
【図９】
2006350580.tif 000011
【図１０】
2006350580.tif 000012