(57)【要約】【課題】従来のLegacyライブラリを変更することなく、実行時のスピード低下を防止できるフィールド機器管理装置を実現すること。【解決手段】フィールド機器の機器情報を取得し管理するフィールド機器管理装置において、COM Inprocess Serverがサポートする所定の関数をインターセプトするラウンチ用プログラムを設け、Microsoft Windows上で複数のCOM Inprocess Serverを初期化するのにあたり、COMオブジェクトが別のメモリ空間に作成されることを特徴とするもの。【選択図】図１
2011237906.tif 000002
【特許請求の範囲】
【請求項１】
フィールド機器の機器情報を取得し管理するフィールド機器管理装置において、
COM Inprocess Serverがサポートする所定の関数をインターセプトするラウンチ用プログラムを設け、
Microsoft Windows上で複数のCOM Inprocess Serverを初期化するのにあたり、COMオブジェクトが別のメモリ空間に作成されることを特徴とするフィールド機器管理装置。
【請求項２】
新しいインスタンスを作る関数GetClassObjectがインターセプトされることにより、
１個目の呼び出しの場合は本体ＤＬＬの同名の関数をそのまま呼び出し、２個目以上の呼び出しの場合は本体ＤＬＬをユニークな別の名前でコピーしてコピーと同名の関数を呼び出すことを特徴とする請求項１に記載のフィールド機器管理装置。
【請求項３】
前記コピーした別の名前の本体ＤＬＬ情報をインスタンスの配列に保存することを特徴とする請求項２に記載のフィールド機器管理装置。
【請求項４】
終了時のＣＯＭにおける呼び出しがCanUnloadNow関数に集約されることを特徴とする請求項１から請求項３のいずれかに記載のフィールド機器管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フィールド機器管理装置に関し、詳しくは、フィールド機器の機器情報をMicrosoft Windows（登録商標）により動作するパソコン上で管理する装置の改良に関するものである。
【背景技術】
【０００２】
化学プラントなどのプロセス制御システムを構築するフィールド機器の管理を行う装置の一種に、図５に示すようなフィールド機器管理装置がある。
【０００３】
フィールド機器管理装置１０は、管理対象とするフィールド機器２０と通信経路３０を介して通信を行うとともに、すでに知られているデバイスタイプマネージャ（以下ＤＴＭという）仕様およびデバイスディスクリプション（以下ＤＤという）仕様を用いて、フィールド機器２０の機器情報（機器タグ、シリアル番号などの個体情報、機器パラメータなど）を取得し、パラメータ設定、機器の調整、保全作業などを行う。
【０００４】
図５において、フィールド機器管理装置１０は、入力手段１１、表示手段１２、ユーザーアプリケーション処理手段１３、ＤＤアプリケーション処理手段１４、仮想通信手段１５、ＤＤ１６、ＤＴＭアプリケーション処理手段１７、ＤＴＭ１８および通信手段１９を備えている。なお、通信手段１９は、通信経路３０を介してフィールド機器２０に接続されている。
【０００５】
ＤＤ１６は、フィールド機器２０のパラメータなどの機器情報および機器情報に対するアクセス方法の定義を記述した記述情報１６ａを有する。ＤＴＭ１８は、条件分岐処理などのように、パラメータに対して機器の状態によって異なる情報処理を行う場合、この情報処理を実行するアルゴリズム（プログラム）から構成される。フィールド機器管理装置１０は、フィールド機器２０の機器情報を、これらＤＤ１６およびＤＴＭ１８を用いて取得する。
【０００６】
ＤＤ１６は、スクリプト言語で記述されるため、製造者にとって開発負担を低減できる一方、前述した条件分岐処理などの複雑な処理を行うことは困難である。このため、このような複雑な処理は、ＡｃｔｉｖｅＸ（登録商標）コントロールを利用したＤＴＭ１８を用いて実現している。
【０００７】
フィールド機器管理装置１０が、フィールド機器２０から機器情報を取得する動作について説明する。まず、ユーザーアプリケーション処理手段１３は、入力手段１０（キーボード、マウスなど）を介して、機器情報取得要求信号をユーザー４０から受け取る。
【０００８】
ＤＤ仕様を用いて機器情報を取得する場合、ＤＤアプリケーション処理手段１４が、ユーザーアプリケーション処理手段１３から機器情報取得要求信号を受け取る。ＤＤアプリケーション処理手段１４は、仮想通信手段１５を介してＤＤ１６の記述情報１６ａを読み込む。そして、ＤＤアプリケーション処理手段１４は、記述情報１６ａに記述された定義に従い、ＤＤ１６、通信手段１９および通信経路３０を介してフィールド機器２０と通信を行い、フィールド機器２０から機器情報を取得する。
【０００９】
ユーザーアプリケーション処理手段１３は、ＤＤアプリケーション処理手段１４によって取得された機器情報を受け取り、この機器情報の表示データを表示手段１１（ＣＲＴ、液晶表示器など）に表示させる。
【００１０】
また、ＤＴＭ仕様を用いて機器情報を取得する場合、ＤＴＭアプリケーション処理手段１７が、ユーザーアプリケーション処理手段１３から機器情報取得要求信号を受け取る。ＤＴＭアプリケーション処理手段１７はＤＴＭ１８を起動し、ＤＴＭ１８は、通信手段１９および通信経路３０を介してフィールド機器２０と通信を行い、フィールド機器２０から機器情報を取得する。
【００１１】
そして、ユーザーアプリケーション処理手段１３は、ＤＴＭアプリケーション処理手段１７によって取得された機器情報を受け取り、この機器情報の表示データを表示手段１１に表示させる。
【００１２】
ところで、図５の装置では、以前から、Microsoft Windows上で動作するソフトウェアライブラリが使い続けられている。たとえばフィールド機器のＤＤファイル形式は、１３年以上にわたって互換性が保たれており、ＤＤファイルを電子的に読み出すソフトウェアライブラリＤＤＳ（Device Description Service）も１３年以上使い続けられている。
【００１３】
以前のソフトウェアライブラリは、Ｃ言語をプログラミング言語として作成されたものであり、モダンなプログラミング言語として知られているＣ＋＋言語に比べて、Global変数やStatic変数を多用した構成になっている。図６は、図５の装置におけるこのようなLegacy Libraryの通常利用時の説明図である。
【００１４】
図６において、ＤＤＳのようなソフトウェアライブラリは単一のＤＬＬ（Dynamic Link Library）に収められていて、クライアントプログラムによって単独起動される。
【００１５】
一方、Microsoft Windows上でメジャーなプログラム形式の一種に、ＣＯＭ（Component Object Model）と呼ばれるものがある。前述のＤＴＭは、ＣＯＭを使ってデジタルフィールド技術を使いやすくした規格である。
【００１６】
ＤＤＳのように成熟したLegacyな技術を、ＣＯＭのような新しい技術と融合させる試みが行われている。ＣＯＭを使用するのにあたっては、図７に示すように、複数のInstanceを起動するのが一般的であって、たとえば２つのフィールド機器（ハードウェア）に対して１つずつのCOM Instanceおよび付随するLegacy Libraryが起動される。
【００１７】
この場合に問題となるのは、Legacyライブラリの中にあるGlobal変数やStatic変数と呼ばれるデータ領域である。Global変数やStatic変数は、Ｃ言語（Ｃ＋＋言語）の仕様上、COM Inprocess Server内では共有領域として扱われる。
【００１８】
ところが、Legacyライブラリで使われるGlobal変数やStatic変数は、図６のような単独使用は想定したものであり、共有領域として使われることは想定されていないにもかかわらず、Ｃ言語による開発でも開発工数を下げるために普通に行われている。
【００１９】
ＣＯＭ技術を適用する場合、Global変数やStatic変数がＣＯＭ内で共有領域として扱われると、Legacy Libraryは動作しなくなる。そのため、Legacy LibraryをＣＯＭ化する場合には、次の１）または２）のどちらかを選択する。
１）Legacy Libraryのソースコードを全部書き換えて、Global/Static変数を使わないようなデザインに変える
２）図７のInprocess Serverではなく、図８のようなLocal Serverに変更してＥＸＥを利用することにより、共有領域ができないようにする
【００２０】
特許文献１には、フィールド機器の機器情報を管理するフィールド機器管理装置、フィールド機器管理システム、コンピュータプログラムおよび記録媒体に関し、特に、機器情報管理に関係するアプリケーションを統一する技術が記載されている。
【００２１】
非特許文献１には、デバイスディスクリプション（ＤＤ）仕様、デバイスタイプマネージャ（ＤＴＭ）仕様について説明したフィールド機器管理装置が記載されている。
【先行技術文献】
【特許文献】
【００２２】
【特許文献１】特開２０１０−０２６８４３号公報
【非特許文献】
【００２３】
【非特許文献１】廣岡勲、外３名、「新時代のフィールド機器管理ツールＦｉｅｌｄＭａｔｅ」、横河技報、横河電機株式会社、２００７年５月２０日、Ｖｏｌ．５１  Ｎｏ．２（２００７）  ｐ．４５−４８
【発明の概要】
【発明が解決しようとする課題】
【００２４】
しかし、１）の方法は、根幹部分を根元から作り変えなければならず、非常に大きな工数がかかるとともに、デザイン上そもそも不可能なことも多い。特に、ＤＤＳのようなもともとＣ言語でかなり以前に作られたライブラリは、前述のようにGlobal/Static変数を多用する傾向があり、ＣＯＭ化する場合に大きな困難が生じることになる。
【００２５】
これに対し、２）の方法は、Legacy Libraryそのものは変更をせずにＣＯＭの形式を変えるものであることから工数は比較的少なくて済むものの、実行時のスピード（パフォーマンス）が極端に低下するという大きな問題がある。
【００２６】
本発明は、これらの問題点を解決するものであり、その目的は、従来のLegacyライブラリを変更することなく、実行時のスピード低下を防止できるフィールド機器管理装置を実現することにある。
【課題を解決するための手段】
【００２７】
このような課題を達成する請求項１の発明は、
フィールド機器の機器情報を取得し管理するフィールド機器管理装置において、
COM Inprocess Serverがサポートする所定の関数をインターセプトするラウンチ用プログラムを設け、
Microsoft Windows上で複数のCOM Inprocess Serverを初期化するのにあたり、COMオブジェクトが別のメモリ空間に作成されることを特徴とする。
【００２８】
請求項２の発明は、請求項１に記載のフィールド機器管理装置において、
新しいインスタンスを作る関数GetClassObjectがインターセプトされることにより、
１個目の呼び出しの場合は本体ＤＬＬの同名の関数をそのまま呼び出し、２個目以上の呼び出しの場合は本体ＤＬＬをユニークな別の名前でコピーしてコピーと同名の関数を呼び出すことを特徴とする。
【００２９】
請求項３の発明は、請求項２に記載のフィールド機器管理装置において、
前記コピーした別の名前の本体ＤＬＬ情報をインスタンスの配列に保存することを特徴とする。
【００３０】
請求項４の発明は、請求項１から請求項３のいずれかに記載のフィールド機器管理装置において、
終了時のＣＯＭにおける呼び出しがCanUnloadNow関数に集約されることを特徴とする。
【発明の効果】
【００３１】
このように構成されるフィールド機器管理装置によれば、従来のLegacyライブラリを変更することなく、実行時のスピード低下を防止できる。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施例を示すブロック図である。
【図２】図１の起動時の動作の流れを説明するフローチャートである。
【図３】図１の終了時の動作の流れを説明するフローチャートである。
【図４】図１の主要部の具体例を示すブロック図である。
【図５】従来のフィールド機器管理装置の一例を示すブロック図である。
【図６】図５の装置におけるLegacy Libraryの通常利用時の説明図である。
【図７】図５の装置のLegacy Libraryを複数のCOMInstanceを起動してＤＤＬを利用する時の説明図である。
【図８】図５の装置のLegacy Libraryを複数のCOMInstanceを起動してＥＸＥを利用する時の説明図である。
【発明を実施するための最良の形態】
【００３３】
以下、本発明について、図面を用いて説明する。図１は本発明の一実施例を示すブロック図であり、図８と共通する部分には同一の符号を付けている。図１と図８の相違点は、クライアントプログラムとCOM Local Server1，2との間にラウンチ用プログラムを介在させていることにある。このような構成において、ラウンチ用プログラムは複数のCOMInstanceの起動時および終了時に動作し、クライアントプログラムは複数のCOMInstanceの起動時および終了時以外に動作する。
【００３４】
Microsoft Windows上でCOM Inprocess Serverを複数初期化した場合には、前述図７のようにGlobal/Static変数は全て共有領域に作成される。本発明では、この部分について、Inprocess Serverでありながら、ＣＯＭオブジェクトが別のメモリ空間に作成されるように制御する。
【００３５】
すなわち、本発明では、従来のコードに一切変更を加えずに実現するために、Windowsの以下の特殊性を利用する。
１）COM Inprocess Serverがサポートすべき関数は４つ（GetClassObject,CanUnloadNow, RegisterServer, UnregisterServer）に集約されている
２）別のファイル名のDLLはたとえ同一のDLLでも別のメモリ空間に配置される
【００３６】
まず、COM Inprocess Serverがサポートする４つの関数（GetClassObject, CanUnloadNow, RegisterServer, UnregisterServer）を、すべてラウンチ用プログラムでインターセプトする。なお、以下の説明では、４つの関数のうちRegisterServer, UnregisterServerについては本発明は関係ないため説明を省略するが、従来技術と同じ実装をすればよい。
【００３７】
GetClassObject関数は、新しいインスタンスを作る関数である。この部分をインターセプトし、クライアントプログラムがこの関数を呼んできた際には、図２に示すような処理を実行する。
【００３８】
図２は、図１の起動時の動作の流れを説明するフローチャートである。図２において、クライアントプログラムは、ラウンチ用プログラムの内部に格納されているGetClassObject関数を呼び出す（ステップＳ１）。呼び出されたGetClassObject関数に基づき、新しいInstanceが作成される。そして、新しく作成されたInstanceについて、Firstか否かを判断する（ステップＳ２）。
【００３９】
ラウンチ用プログラムは、新しく作成されたInstanceがFirst（１個目）の場合、本体ＤＬＬ（body.dll）の同名の関数を呼び出しターゲット情報として呼び出し（ステップＳ３）、ラウンチ用プログラム内部の所定の格納領域に格納する。これで従来と同様の動きになる。
【００４０】
新しく作成されたInstanceがFirstではない（２個目以上）場合には、本体ＤＬＬ（body.dll）をたとえばtmpx.dllのようなユニークな別の名前でコピーし（ステップＳ４）、コピーしたＤＬＬファイルの情報を呼び出しターゲット情報として（ステップＳ５）、ラウンチ用プログラム内部の所定の格納領域に格納する。この場合、名前が異なるため、１個目と２個目（３個目以降）のメモリ空間は別のメモリ空間に配置される。
【００４１】
その後、ラウンチ用プログラムは、ステップＳ３およびステップＳ５におけるターゲット情報に基づき、本体ＤＬＬの内部またはコピーされたＤＬＬの内部からGetClassObject関数を呼び出す（ステップＳ６）。
【００４２】
そして、終了処理のために、コピーされたtmpx.dllの情報をラウンチ用プログラムの配列Instance[ ]データ格納部に格納する（ステップＳ７）。なお、この配列Instance[ ]データ格納部には、「本体ＤＬＬを直接使っているかそれともコピーしたものを使っているか」の情報と、「もしコピーを作った場合はそのコピーのときに使ったファイル名」の２つの情報が格納される。
【００４３】
図３は、図１の終了時の動作の流れを説明するフローチャートである。終了時のＣＯＭでは、CanUnloadNow関数に呼び出し処理が集約され、作成したtmpx.dllの消去などが実行される。
【００４４】
図３において、クライアントプログラムは、ラウンチ用プログラムの内部に格納されているCanUnloadNow関数を呼び出す（ステップＳ１）。呼び出されたCanUnloadNow関数は、配列Instance[ ]データ格納部内部をループし（ステップＳ２）、Instance[x]のCanUnloadNow関数を呼び出す（ステップＳ３）。
【００４５】
呼び出したInstance[x]のCanUnloadNow関数について、戻り値がＴＲＵＥか否かを判断する（ステップＳ４）。
【００４６】
戻り値がＴＲＵＥではない場合には、戻り値としてＦＡＬＳＥをセットする（ステップＳ５）。一方、戻り値がＴＲＵＥの場合には、tmpx.dllライブラリを開放して（ステップＳ６）、tmpx.dllファイルを削除する（ステップＳ７）。
【００４７】
これらステップ２からステップ７までの一連の処理をループが終わるまで繰り返して実行する（ステップＳ８）。そして、ループが終わると、このCanUnloadNow関数の戻り値（ＴＲＵＥ／ＦＡＬＳＥ）を返して終了時の一連の動作を終了する（ステップＳ９）。
【００４８】
図４は、図１の主要部分の具体的なブロック図である。図４において、ラウンチ用プログラム１０には、関数格納部１１と、ＤＬＬファイル情報格納部１２と、配列Instance[ ]データ格納部１３と、戻り値管理部１４が設けられている。本体ＤＬＬ２０にも、関数格納部２１が設けられている。
【００４９】
起動時、クライアントプログラムは、前述のように、ラウンチ用プログラム１０の関数格納部１１に格納されているGetClassObject関数を呼び出す。
【００５０】
そして、ラウンチ用プログラムは、新しく作成されたInstanceがFirst（１個目）の場合には、本体ＤＬＬ２０の関数格納部２１からGetClassObject関数を呼び出し、ラウンチ用プログラム１０のＤＬＬファイル情報格納部１２に格納する。
【００５１】
また、ラウンチ用プログラムは、新しく作成されたInstanceがFirstではない（２個目以上）場合には、本体ＤＬＬをユニークな別の名前でコピーし、コピーしたＤＬＬファイルの情報を呼び出しターゲット情報としてラウンチ用プログラム１０のＤＬＬファイル情報格納部１２のInstanceがFirst（１個目）の場合とは別のメモリ空間に格納する。
【００５２】
また、ラウンチ用プログラムは、終了処理のために、コピーされたtmpx.dllの情報をラウンチ用プログラム１０の配列Instance[ ]データ格納部１３に格納する。
本体ＤＬＬ２０のGetClassObject関数格納部２１からGetClassObject関数を呼び出し、ラウンチ用プログラム１０のＤＬＬファイル情報格納部１２に格納する。
【００５３】
終了時、クライアントプログラムは、前述のように、ラウンチ用プログラム１０の関数格納部１１に格納されているCanUnloadNow関数を呼び出す。
【００５４】
呼び出されたCanUnloadNow関数は、配列Instance[ ]データ格納部１３の内部をループして、Instance[x]のCanUnloadNow関数を呼び出す。
【００５５】
戻り値管理部１４は、呼び出したInstance[x]のCanUnloadNow関数について、戻り値がＴＲＵＥか否かを判断する。そして、戻り値がＴＲＵＥではない場合には、戻り値としてＦＡＬＳＥをセットし、戻り値がＴＲＵＥの場合にはＤＬＬファイル情報格納部１２に格納されているtmpx.dllライブラリを開放してtmpx.dllファイルを削除する。
【００５６】
これらにより、Global/Static変数を使用したLegacyライブラリをCOM Inprocess Serverで使用したときでも、単一動作のときと同じ正常動作が実現できる。
【００５７】
ここで、Legacy Libraryには何も加工処理していないのでその工数は０であり、Inprocess Serverで実現されることから実行時スピードが低下することもなく、この２点において従来技術に比べて優れた効果が得られる。
【００５８】
なお、上記実施例では、フィールド機器管理装置の例について説明したが、Global/Static変数を使用したソフトウェアライブラリを含むモジュールを、ＣＯＭに対応させる場合に応用できる。
【００５９】
特に、古いソフトウェアライブラリからGlobal/Static変数を削除しにくい場合や、古いソフトウェアライブラリを.Netに対応させるような場合に有効である。この場合はGlobal/Static変数が問題となることが多いが、本発明を使えばきわめて少ない工数で、古いソフトウェアライブラリを.Netに対応させることができる。また、本体のコードを変更しないため、検証工数も低く抑えることができる。
【００６０】
以上説明したように、本発明によれば、従来のLegacyライブラリを変更することなく、実行時のスピード低下を防止できるフィールド機器管理装置を実現できる。
【符号の説明】
【００６１】
１０  ラウンチ用プログラム
１１  関数格納部
１２  ＤＬＬファイル情報格納部
１３  配列Instance[ ]データ格納部
１４  戻り値管理部
２０  本体ＤＬＬ
２１  関数格納部
【図１】
2011237906.tif 000003
【図２】
2011237906.tif 000004
【図３】
2011237906.tif 000005
【図４】
2011237906.tif 000006
【図５】
2011237906.tif 000007
【図６】
2011237906.tif 000008
【図７】
2011237906.tif 000009
【図８】
2011237906.tif 000010