JP2011237906A

JP2011237906A - フィールド機器管理装置

Info

Publication number: JP2011237906A
Application number: JP2010107129A
Authority: JP
Inventors: Hiroaki Kaneki; 宏明鹿子木
Original assignee: Yokogawa Electric Corp
Current assignee: Yokogawa Electric Corp
Priority date: 2010-05-07
Filing date: 2010-05-07
Publication date: 2011-11-24
Anticipated expiration: 2030-05-07
Also published as: US20110276955A1; US8806467B2; CN102236583A; CN102236583B; EP2397944A1; JP5062499B2; EP2397944B1

Abstract

【課題】従来のLegacyライブラリを変更することなく、実行時のスピード低下を防止できるフィールド機器管理装置を実現すること。
【解決手段】フィールド機器の機器情報を取得し管理するフィールド機器管理装置において、COM Inprocess Serverがサポートする所定の関数をインターセプトするラウンチ用プログラムを設け、Microsoft Windows上で複数のCOM Inprocess Serverを初期化するのにあたり、COMオブジェクトが別のメモリ空間に作成されることを特徴とするもの。
【選択図】図１

Description

本発明は、フィールド機器管理装置に関し、詳しくは、フィールド機器の機器情報を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[ ]データ格納部
１４戻り値管理部
２０本体ＤＬＬ
２１関数格納部

Claims

フィールド機器の機器情報を取得し管理するフィールド機器管理装置において、
COM Inprocess Serverがサポートする所定の関数をインターセプトするラウンチ用プログラムを設け、
Microsoft Windows上で複数のCOM Inprocess Serverを初期化するのにあたり、COMオブジェクトが別のメモリ空間に作成されることを特徴とするフィールド機器管理装置。
新しいインスタンスを作る関数GetClassObjectがインターセプトされることにより、
１個目の呼び出しの場合は本体ＤＬＬの同名の関数をそのまま呼び出し、２個目以上の呼び出しの場合は本体ＤＬＬをユニークな別の名前でコピーしてコピーと同名の関数を呼び出すことを特徴とする請求項１に記載のフィールド機器管理装置。
前記コピーした別の名前の本体ＤＬＬ情報をインスタンスの配列に保存することを特徴とする請求項２に記載のフィールド機器管理装置。
終了時のＣＯＭにおける呼び出しがCanUnloadNow関数に集約されることを特徴とする請求項１から請求項３のいずれかに記載のフィールド機器管理装置。