JP2015215870A - 制御システムエンジニアリング装置 - Google Patents

Abstract

【課題】顧客からの信号リストと属性辞書に基づいて、自動的に、標準画面のリストを作成すると共に、各信号を該当する複数の標準画面へ割付ける。
【解決手段】属性辞書記憶部５１には、制御システムの各属性に係わる複数のキーワードが予め登録されている。トークン抽出部５２は、信号リストにおける各信号毎に、その信号名称から、任意のキーワードが含まれるトークンを複数抽出する。画面リスト生成部５３は、抽出された複数のトークンに応じた複数のユーザインタフェース画面（標準画面）のリストを生成する。信号関連付部５４は、上記各信号を、その信号に係わる複数の属性に対応する複数の前記ユーザインタフェース画面に割り当てる。
【選択図】 図８

Description

本発明は、プラント制御システムのユーザインタフェース作成作業の作業効率化、品質向上を実現できる制御システムエンジニアリング装置に関するものである。

プラント制御システムのエンジニアリングは、顧客の設備の一覧である信号リスト及び設備フロー図（P＆I図）を元に仕様書を作成し、ロジックを設計・製作し、その製作されたロジックの妥当性を検証するテストを行い、プラント現場での試運転調整の後、顧客に納入するという流れで進められる。

ロジックの設計・製作は、制御ロジックとユーザインタフェースロジックに大別され、ユーザインタフェースロジックにおいては、信号の属性（各種機器、各種計測信号など）に応じて、各種類毎（保守画面やトレンド画面）に定型化されたユーザインタフェース画面（以下、“標準画面”と記す）が提供されているのが一般的である。この標準画面のエンジニアリングに於いては、これらの標準画面のリストの作成や各標準画面に信号を割り当てる作業をエンジニアが手作業で行うのが一般的である。

また、例えば特許文献１，２，３に記載の従来技術が知られている。
特許文献１には、ＲＡＭ領域へデータを割付けるシステムであって、下記の各構成を備えるシステムが開示されている。

・プログラムの設計書に記述されている情報から変数・定数などのデータ情報を抽出するデータ情報抽出部；
・データ情報に基づいてＲＡＭ領域のアドレスを含むデータテーブルを生成するデータテーブル生成部；
・生成されたデータテーブルを編集するデータテーブル編集部；
・データテーブルにおけるデータ情報のＲＡＭ領域のアドレスの割付を自動的に決定する自動割付部；
また、特許文献２の発明は、前回と同一の割付態様を容易に指定することができる割付処理装置を提供するものである。

特許文献２の発明では、対象物データ格納手段４内には、割付対象物についての画像データや文字データが格納されている。ディスプレイ１上にはグリッド生成手段３で生成されたグリッドが表示される。オペレータは指示入力手段８から対象物の選択と、グリッド内の単位格子の選択を行うと、割付データ生成手段７により、選択された対象物を選択された単位格子内の所定位置に所定の大きさで所定の向きに割り付けることを示す割付データが生成され、割付データ格納手段６内に格納され、その割付状態はディスプレイ１に表示される。個々の割付対象物についての単位格子に対する割付態様は、個別割付情報記憶手段５内に記憶され、次回、同一の割付対象物についての割付作業を行うと、前回の割付態様に基づく割り付けがなされる。

また、特許文献３の発明は、データを一覧表示する際、従来技術である表の形式での一覧表示では取り扱い困難なデータについて、より直感的で分かりやすい外観と操作性を有する一覧表示方法を提供するものである。

特許文献３の発明では、一覧表示画面１０において、一覧表示中の特定項目、例えば行１２に関連するデータが存在する場合に、該項目を立体的な表示とし、その項目側面部分２０に関連するデータを表示することにより、引き出しを引き出すかのような現実世界と相似の視覚的効果および操作感覚を得ることができる。一覧中の目的のデータを参照する際の操作性に優れるという効果がある。

特開平３−２２４０３２号公報 特開平６−２０２３０５号公報 特開２０００−１４８３２７号公報

ここで、プラント監視システムに於ける標準画面の定型は、その監視目的などに応じて複数種類用意されているのが一般的である。具体例としては、プラントの各機器（ポンプやバルブなど）の保守画面、電流や電圧などの計測値を継続的に収集してグラフに表示するトレンド画面等が挙げられる。

これら標準画面は、同一属性の信号をグルーピングして纏めて表示することで、プラント状態の機器毎の操作やプロセスデータの比較分析を容易にしている。通常、一つの信号は複数の属性を持つため、一つの信号が複数の標準画面に割り当てられるのが一般的である。

しかしながら、上述した標準画面作成のエンジニアリングに於いて、この標準画面のリストの作成及びリストされた各標準画面に対する信号の割付作業が、手作業で行われており、エンジニアリング作業の効率低下及び品質低下を招いている。

本発明の課題は、顧客からの信号リストと属性辞書に基づいて、自動的に、標準画面のリストを作成すると共に、各信号を該当する複数の標準画面へ割付けることができる制御システムエンジニアリング装置等を提供することである。

本発明の制御システムエンジニアリング装置は、制御システムの各属性に係わる複数のキーワードが予め登録された属性辞書記憶手段と、顧客側で作成された、任意の制御システムに係わる任意の複数の信号の信号名称が含まれる信号リストを用いて、該信号リストにおける前記各信号毎に、その前記信号名称から、任意の前記キーワードが含まれるトークンを複数抽出するトークン抽出手段と、前記抽出された複数のトークンに応じた複数のユーザインタフェース画面のリストを生成する画面リスト生成手段と、前記各信号を、その信号に係わる複数の属性に対応する複数の前記ユーザインタフェース画面に割り当てる信号関連付手段とを有する。

本発明の制御システムエンジニアリング装置等によれば、顧客からの信号リストと属性辞書に基づいて、自動的に、標準画面のリストを作成すると共に、各信号を該当する複数の標準画面へ割付けることができる。

本例の制御システムエンジニアリング装置の概略機能を示す図である。 属性辞書のデータ構成例を示す図である。 信号リストの具体例を示す図である。 制御システムエンジニアリング装置の処理フローチャート図である。 （ａ）は画面リスト、（ｂ）は信号−画面対応テーブルの具体例である。 本装置による標準画面生成結果例である。 本手法を介して最終的に生成される標準画面の具体例である。 本例の制御システムエンジニアリング装置の機能ブロック図である。 制御支援システムの構成例である。 共有属性辞書マスタの具体例を示す図である。 プラント種別マスタの具体例を示す図である。 図９に示す制御支援システムの処理フローチャート図である。 共有属性辞書マスタの更新処理のフローチャート図である。

図1は、本例の制御システムエンジニアリング装置の概略機能を示す図である。
本例の制御システムエンジニアリング装置１によれば、顧客から受領した信号リスト内に含まれる属性情報を活用し、プラント制御システムのユーザインタフェースエンジニアリング工期を短縮するとともに、品質向上、作業効率化できる。

尚、本例の制御システムエンジニアリング装置１は、例えば汎用のコンピュータ（パソコン、サーバ装置等）で実現される。よって、特に図示しないが、制御システムエンジニアリング装置１は、一般的なコンピュータの構成を有しており、例えばＣＰＵ、記憶部（ハードディスク、メモリ等）、入出力インタフェース（キーボードやディスプレイ等）、通信機能部等を有している。記憶部には予め所定のアプリケーションプログラムが記憶されており、ＣＰＵがこのアプリケーションプログラムを実行することで、以下に説明する制御システムエンジニアリング装置１の各種処理機能（例えば図４の処理等）が実現される。尚、記憶部には、例えば属性辞書２や、取り込んだ信号リスト５等が記憶される。

図１に示すように、プラント等の制御システム３で用いられる上記各ユーザインタフェース画面（保守画面やトレンド画面等の種類に分類でき、基本的には各属性に応じて生成される上記“標準画面”）を、制御システムエンジニアリング装置１が生成する。制御システムエンジニアリング装置１は、顧客から受領した信号リスト５と属性辞書２等に基づいて、上記各標準画面を生成する。

信号リスト５は、顧客側で作成された、上記プラントの制御システム３に係わる任意の複数の信号のリストであり、少なくとも後述する信号名称が含まれる。尚、上述した通り、標準画面は、通常、同一属性の信号をグルーピングして纏めて表示するものであり、また、通常、一つの信号は複数の属性を持つため、一つの信号が複数の標準画面に割り当てられるのが一般的である。信号リスト５の一例を図３に示し後に説明する。

図１に示すように、顧客から受領した信号リスト５が、制御システムエンジニアリング装置１に取り込まれる。制御システムエンジニアリング装置１には、予め、属性辞書２が登録されている。

属性辞書２は、システム開発者等が、予め任意に作成しておくものであり、基本的には、プラント制御システム（その各種信号）の属性に係わる複数のキーワードが、予め登録された辞書である。尚、属性とは、上記のように、例えばプラントに係わる各種機器、各種計測信号等である。各種機器とは、例えば後述する例では、各種ポンプ、各種攪拌機、各種設備等である。計測信号とは、例えば電流値、電圧値、温度値、回転数等の、プラントにおける各種計測値に係わる信号等である。

属性辞書２の一例を図２に示し、後に説明するが、図２の例では、キーワードと当該キーワードに対応する「分類」（標準画面の種類に対応するもの）等が登録されている。標準画面の種類は、ここでは上記保守画面、トレンド画面などとするが、これらの例に限らない。

尚、標準画面とは、例えばプラント制御システムに係わり上記のように定型化されたユーザインタフェース画面であるが、この例に限らない。
制御システムエンジニアリング装置１は、上記信号リスト５の各信号名称に対して、上記属性辞書２の上記キーワードを用いて字句解析を行うことで、各信号名称を複数のトークン（語；字句；文字列；記号；数値等）に分割する。本例では、各信号名称から、任意の上記キーワードが含まれるトークンを複数抽出する。

更に、これら各トークンに含まれるキーワードに対応する上記「分類」に基づいて、各トークンを該当する“標準画面の種類”に振り分ける。本例では、基本的に、上記保守画面、トレンド画面の何れかに振り分ける。これによって、後述する各“標準画面の種類”に係わるリスト（保守画面リスト、トレンド画面リスト）を生成する。つまり、これら各リストは、上記抽出したトークンをリスト化したものと見做せる。例えば保守画面リストには、保守画面に係わるトークンの一覧が格納されることになる。

ここで、上記保守画面リストは、保守画面に係わる各種“属性”のリストと見做してもよい。同様に、上記トレンド画面リストは、トレンド画面に係わる各種“属性”のリストと見做してよい。ここでは、“属性”とは、例えばトレンド画面の場合には後述する電流、電圧、温度、湿度等である。そして、基本的に、各“属性”に対応して標準画面が生成される。例えば、属性“電流”に関して後述する図６に示す標準画面「電流一覧画面」が生成されることになる。

ここで、上記の通り、通常、一つの信号は複数の属性を持つため、一つの信号が複数の標準画面に割り当てられるのが一般的である。そして、各信号の信号名称には、その上記複数の属性を示す各文字列が含まれている場合が多い。更に、“属性を示す文字列”は、顧客側が作成するので予測困難であるが、“属性を示す文字列”に含まれる文字または文字列は、予測可能であり、従ってこれを上記キーワードとして予め登録しておくことも可能となる。この様な現場の状況・実態から本手法が想到されたものである。

本手法でも、最終的には、上記信号リスト５の各信号を、それぞれ、基本的には複数の標準画面に割り当てることになる。これは、上記各トークンを該当する“標準画面の種類”に振り分けた際の記録データ等（後述する）に基づいて、各信号をそれぞれが該当する複数の標準画面に割り当てる。この様にして、上記顧客側で作成された各種信号に応じた各種標準画面を生成する。

但し、本手法で生成するのは、ユーザインタフェースロジックに係わる部分であり、すなわち、その画面の名称や、その画面で表示させる信号の名称等が、割り当てられるものである。これら各種信号名称の信号のデータ等を画面上に表示させる処理等は、上述した制御ロジックで行うことになる（つまり、本手法には直接関係はない）。そして、この様にして完成された標準画面は、制御システム３に転送され、制御システム３の監視モニタ上で表示される。

図２に、上記属性辞書２のデータ構成例を示す。
尚、制御システムエンジニアリング装置１は、例えば不図示の属性辞書作成部を有しており、開発者等は、属性辞書作成部を介して属性辞書２への所望のデータ登録を行う。属性辞書作成部は、図示のキーワード１２、分類１３等を開発者等が任意に入力可能な不図示の画面等を、制御システムエンジニアリング装置１のディスプレイ等に表示する。但し、この例に限らず、上記属性辞書作成部は外部の他のコンピュータ装置が有しており、この装置で作成された属性辞書２を、制御システムエンジニアリング装置１に転送させる構成であってもよい。

図２に示す例では、属性辞書２は、ＮＯ．１１、キーワード１２、分類１３等から成る。尚、図示の説明１４は、単に本説明の為に示しているだけであり、実際のデータ構成には存在しなくてよい。

キーワード１２には、開発者等が任意に決めた様々な語句が格納される。開発者等は、例えば、キーワード１２に、信号リスト５の各信号名称内に出現が予測される文字列を定義する。換言すれば、既に述べた“属性を示す文字列”に含まれる文字または文字列が、定義される。キーワード１２は、任意の数字や文字列をワイルドカード（＊や？）として指定することもできる。これより、図示の「？設備」の場合、信号リスト５の信号名称内に「任意の文字列＋設備」の文字列があった場合には、これを上記“属性を示す文字列”（トークン）として抽出することになる。トークン抽出の具体例については後述する。

分類１３には、キーワード１２に対応する分類（機器や計測対象等）が格納される。分類１３は、ユーザが任意に判断して入力している。分類１３は、キーワード１２によって信号名称から検索・抽出されるトークンに係わる“標準画面の種類”（例えば上記保守画面、トレンド画面など）を示すものと見做しても構わないが、この例に限らない。

尚、上記の例に限らず、例えば分類１３には、キーワード１２に対応する標準画面の種類（例えば上記保守画面、トレンド画面など）が、登録されるものであっても構わない。
キーワード１２は、信号リスト５の各信号の信号名称から上記複数のトークンを抽出する為に用いられる。基本的には、１つの信号名称には複数のキーワードが含まれている。換言すれば、その様になるようにキーワード１２を定義している。

また、各トークンには１つのキーワードが含まれることになる。トークンにおいてキーワード以外の文字／数値等は、図２に示す＊や？等のワイルドカードに相当することになる。例えば、図示の“Ｎｏ．＊”の場合、Ｎｏ．とその直後の任意の数値が、トークンとして抽出されることになる。例えば後述する“Ｎｏ．１”や“Ｎｏ．２”等が、トークンとして抽出されることになる。同様に、図示の“？設備”の場合、設備とその直前の任意の文字列が、トークンとして抽出されることになる。例えば、後述する“昇温設備”などが、トークンとして抽出されることになる。

また、上記のように抽出された各トークンを、該当するキーワード１２に対応する分類１３に基づいて、該当する種類のリスト（保守画面リストまたはトレンド画面リスト）に振り分けられる。つまり、そのトークン（属性）に対応する“標準画面の種類”に、当該トークンを分類する。本例では、抽出したトークンを、その分類１３が“機器”である場合には後述する保守画面リストに追加格納し、分類１３が“計測対象”である場合には後述するトレンド画面リストに追加格納する。

尚、Ｎｏ．１１は、各キーワード１２に割り当てられるシリアル番号であり、各キーワード１２のＩＤ等と見做しても構わない。
図３に、信号リスト５の具体例を示す。

尚、本装置１は、例えば不図示の信号リスト取込部を有しており、信号リスト取込部を介して不図示の外部装置や記録媒体から信号リスト５を取り込むようにしてもよいが、この例に限らない。

図３の例の信号リスト５は、Ｎｏ．２１、TAGNo.２２、信号名称２３等から成る。
つまり、各信号毎に、その識別用ＩＤ等であるTAGNo.２２や、任意に決められた名称である信号名称２３等が格納されている。但し、信号名称２３は、信号を簡潔に説明する文字列である場合が多く、信号の属性を示す文字列が含まれている場合が多い。特に、属性は複数ある場合が多く、各属性を示す各文字列が信号名称２３には含まれている場合が多い。本手法は信号名称のこの特性を活用して自動化を行う。詳しくは後述する。尚、Ｎｏ．２１は、各信号名称２３に割り当てられるシリアル番号などである。

図４は、制御システムエンジニアリング装置１の処理フローチャート図である。
本装置１は、信号リスト５から各信号の信号名称２３を読み込む毎に（ステップＳ１１）、この信号名称２３を処理対象として下記のステップＳ１２〜Ｓ１４の処理を実行する。

まず、属性辞書２の上記キーワード１２を用いて、この信号名称２３から複数のトークンを抽出する（信号名称を複数のトークンに分割する）（ステップＳ１２）。上記図２、図３の例の場合、例えば、信号名称「No.1昇温設備原料ポンプ電流」は、「“No.1”、“昇温設備”、“原料ポンプ”、“電流”」の4つのトークンに分割されることになる。

上記ステップＳ１２で切出した各トークンを、その抽出の際に用いられたキーワード１２に対応する分類１３に基づいて、対応する標準画面リストへ分類・格納する（ステップＳ１３）。上記の例では、上記“No.1”と“原料ポンプ”は保守画面リストに分類・格納され、上記“電流”はトレンド画面リストに分類・格納されることになる。一方、分類１３が“−”（なし）である“昇温設備”は、何処にも分類・格納されることはない。

尚、これら標準画面リストは、各“標準画面の種類”毎に、その種類に係わる各種標準画面の名称等の一覧と見做しても構わない。例えば、保守画面に関しては、上記“No.1”や“原料ポンプ”等の標準画面の名称等が、生成されることになる。

更に、上記処理対象の信号名称２３を、当該信号名称に係わる全ての標準画面に関連付ける（ステップＳ１４）。
以上のステップＳ１１〜Ｓ１４の処理を、信号リスト５の行数分（信号名称の数の分）繰り返し実行したら、各画面リストに基づいて標準画面を生成する（ステップＳ１５）。

ここで、標準画面は、上記の例では、保守画面リスト、トレンド画面リストに格納されたものが、作成されることになる。つまり、上記の例では、標準画面は、“No.1”画面、“原料ポンプ”画面、“電流”画面の３種類が、作成されることになる。尚、“No.1”画面と“原料ポンプ”画面は、保守画面の一種であり、“電流”画面はトレンド画面の一種である。

そして、例えば、上記の信号名称「No.1昇温設備原料ポンプ電流」の信号は、“No.1”画面と“原料ポンプ”画面と“電流”画面とに、関連付けられることになる。ここで、上述したように、通常、一つの信号は複数の属性を持つため、一つの信号が複数の標準画面に割り当てられるのが一般的である。本手法では、この割当て（関連付け）を上記のように自動的に行うことができる。

更に、上述したように、各標準画面は、同一属性の信号をグルーピングして纏めて表示することが望ましい。例えば図３の例の場合、“電流”画面に対しては、上記信号名称「No.1昇温設備原料ポンプ電流」の信号だけでなく、信号名称「No.２昇温設備原料ポンプ電流」や信号名称「昇温設備攪拌機電流」の信号も、関連付けられることになる。これより、“電流”画面には、「No.1昇温設備原料ポンプ電流」と「No.２昇温設備原料ポンプ電流」と「昇温設備攪拌機電流」が、纏めて表示されることになる。尚、この場合、同一属性とは“電流”のことである。

ここで、上記ステップＳ１４の処理は、上記の例に限らず、例えば全ての信号名称２３についてステップＳ１２、Ｓ１３の処理を実行した後に、最後に纏めて行うようにしてもよい。また、この場合、ステップＳ１２，Ｓ１３の処理に伴って例えば図５に示すような信号−画面対応テーブル４０を作成しておき、後で纏めてこのテーブル４０を用いてステップＳ１４の処理を実行するようにしてもよい。以下、この処理例について、図５に示す例を用いて説明する。

図５（ａ）には、上記標準画面リスト３０（保守画面リスト３０Ａ、トレンド画面リスト３０Ｂ）の具体例を示す。
図示の例の標準画面リスト３０は、画面ＩＤ３１とトークン３２から成る。上記ステップＳ１３の処理の際、上記のように抽出されたトークンがトークン３２に格納されると共に、任意のユニークな画面ＩＤが割り当てられて画面ＩＤ３１に格納される。

ここで、既に述べた通り、保守画面リスト３０Ａには、それに含まれるキーワード１２に対応する分類１３が“機器”であるトークンが、格納されることになる。つまり、図示の“Ｎｏ．１”や“原料ポンプ”等が、格納されることになる。また、トレンド画面リスト３０Ｂには、それに含まれるキーワード１２に対応する分類１３が“計測対象”であるトークンが、格納されることになる。つまり、図示の“電流”や“電圧”等が、格納されることになる。

但し、標準画面リスト３０に既に登録済みのトークンがあれば、そのトークンを新たに格納することはない。但し、この様なトークンも、以下に説明する信号−画面対応テーブル４０の生成の際には用いられる。

更に、上記標準画面リスト３０生成に伴って、図５（ｂ）に示す信号−画面対応テーブル４０も生成する。
信号−画面対応テーブル４０は、例えば、信号ＩＤ４１と画面ＩＤ４２とから成る。

信号ＩＤ４１は、信号リスト５の各信号の識別用ＩＤ等であり、例えば上記Ｎｏ．２１を用いるが、この例に限らず、上記TAGNo.２２等を用いても良い。ここでは、Ｎｏ．２１を用いる例によって説明するものとする。

信号−画面対応テーブル４０には、各信号毎に、その信号に係わる全ての標準画面が登録される。信号−画面対応テーブル４０の生成処理について、以下、説明する。
ここでは、まず、上記信号名称「No.1昇温設備原料ポンプ電流」の信号を例にして説明する。この例では、図５（ａ）に示すように、上記“No.1”、“原料ポンプ”、“電流”が上記画面リスト３０のトークン３２に登録されると共に、各々に対して画面ＩＤ３１として‘１１’、‘１２’、‘２１’が割り当てられる。

これより、信号−画面対応テーブル４０には、図示のように、信号ＩＤ４１が上記「No.1昇温設備原料ポンプ電流」のＮｏ．２１である‘１’に対応させて、画面ＩＤ４２が上記‘１１’、‘１２’、‘２１’である３つのレコードが登録される。

続いて、「No.２昇温設備原料ポンプ電流」を対象とすると、“No.２”、“原料ポンプ”、“電流”の３つのトークンが画面リスト３０への登録対象となるが、既に“原料ポンプ”、“電流”は登録済みであるので、“No.２”のみが新規登録され、画面ＩＤ３１＝‘１３’が割り当てられる。

一方、信号−画面対応テーブル４０への登録に関しては、上記画面リスト３０に登録済みであるか否かは関係なく、上記３つのトークン全てが格納される。つまり、図示のように、信号ＩＤ４１が上記「No.２昇温設備原料ポンプ電流」のＮｏ．２１である‘２’に対応させて、画面ＩＤ４２が上記‘１３’、‘１２’、‘２１’である３つのレコードが登録される。尚、これらのうち‘１２’、‘２１’は、上記標準画面リスト３０から既に登録済みの“原料ポンプ”と“電流”に対応する画面ＩＤ３１を、取得したものである。

上記の処理を全ての信号名称について実行して信号−画面対応テーブル４０が完成したら、この信号−画面対応テーブル４０において、各画面ＩＤ４２を基準にして、該当する信号名称を全て抽出する処理を行う。これは、各標準画面毎に、この標準画面に関連する信号名称を全て抽出する処理と言える。

図５に示す具体例のなかで説明するならば、例えば、画面ＩＤ４２＝‘２１’を例にすると、信号ＩＤ４１＝‘１’と‘２’が抽出されることになる。これは、つまり、“電流”画面に対しては、Ｎｏ．２１が‘１’の信号と‘２’の信号とが関連付けられることになる。つまり、「No.１昇温設備原料ポンプ電流」と「No.２昇温設備原料ポンプ電流」とが関連付けられることになる。但し、図５では省略されているだけであり、更に上記「昇温設備攪拌機電流」も関連付けられるはずである。

また、特に図示しないが、これら「No.１昇温設備原料ポンプ電流」と「No.２昇温設備原料ポンプ電流」は、更に、“原料ポンプ”画面にも関連付けられることになる。また、“原料ポンプ”画面に対しては、更に、「No.１昇温設備原料ポンプ電圧」と「No.２昇温設備原料ポンプ電圧」も、関連付けられることになる。

上記のように、信号名称と標準画面との関連付けは、１対１の関係ではなく、１対多（もしくは多対多）の関係であるので、特に信号や標準画面の種類が多いと、従来では、関係付けを行う作業が煩雑となり、間違いも生じていた。これに対して、本手法では、これを自動化できるので、手間が軽減され、間違いが生じないようになる。

図６に、上記本手法による標準画面の生成結果例を示す。
ここでは、上記“標準画面の種類”（保守画面、トレンド画面）毎にフォルダ分類して、各種類毎の生成された標準画面を記憶している。

すなわち、保守画面に関しては、Ｎｏ１．号機画面、Ｎｏ．２号機画面、原料ポンプ画面、攪拌機画面の４つの標準画面が、生成・格納されることになる。
トレンド画面に関しては、電流一覧画面、電圧一覧画面の２つの標準画面が、生成・格納されることになる。

尚、これらは一例であり、例えばＮｏ１．号機画面や電流一覧画面は、上記トークン“Ｎｏ．１”や“電流”を用いて単純に、Ｎｏ１．画面や電流画面等としてもよい。
また、図６には示していないが、上記各標準画面には例えば図７に示すように該当する信号名称が、割り当てられることになる。

ここで、図７には、図２、図３の例に応じて生成される電流一覧画面の一例を示す。
但し、図７では、電流値がグラフ表示される例を示しているが、これは本手法で生成された電流一覧画面に対して更に何らかの作業を施して電流一覧画面を完成させた後に、制御システム３に転送して、制御システム３で運用中の電流一覧画面の表示例を示している。

上述したように、標準画面は、各種類毎に定型化されたユーザインタフェース画面であり、図６等に示したように電流一覧画面の種類はトレンド画面である。そして、図７に示す例では、トレンド画面の定型は、画面の下側に信号名称一覧を表示すると共に、画面の上側をこれら各信号名称の信号の測定データの表示領域としている。本手法では、これら信号名称一覧の設定を、自動的に行うことができる。図２、図３の例では、図７に示すように、３種類の信号名称が、自動的に割り当てられることになる。

こうして生成された標準画面群は、最終的に制御システム３に転送され、監視画面として動作する。但し、その前に、例えば上記制御ロジックに係わる作業や何等かの他の作業等も行う必要がある。

図８は、本例の制御システムエンジニアリング装置１の機能ブロック図である。
本例の制御システムエンジニアリング装置１は、属性辞書記憶部５１、トークン抽出部５２、画面リスト生成部５３、信号関連付部５４を有する。

属性辞書記憶部５１には、制御システムの各属性に係わる複数のキーワードが予め登録されている。属性辞書記憶部５１の一例が上記属性辞書２である。
トークン抽出部５２は、顧客側で作成された、任意の制御システムに係わる任意の複数の信号の信号名称が含まれる上記信号リスト５を用いて、該信号リスト５における各信号毎に、その信号名称から、任意のキーワードが含まれるトークンを複数抽出する。

画面リスト生成部５３は、上記抽出された複数のトークンに応じた複数のユーザインタフェース画面（標準画面）のリストを生成する。一例としては上記標準画面リスト３０を生成するが、この例に限らない。

信号関連付部５４は、上記各信号を、その信号に係わる複数の属性に対応する複数の前記ユーザインタフェース画面に割り当てる。この割当て結果の具体例は、上記図７等で説明している。

上記構成において、例えば、上記画面リスト生成部５３は、上記標準画面リスト３０を生成するだけでなく、更に、上記各信号に対応付けて、その信号に係わる全てのユーザインタフェース画面を登録した信号−画面対応テーブルを生成する。その一例が上記信号−画面対応テーブル４０であるが、この例に限らない。

そして、例えば上記信号関連付部５４は、例えば一例としては上記標準画面リスト３０、上記信号−画面対応テーブル４０等を用いて、上記各信号をその信号に係わる複数の属性に対応する複数の前記ユーザインタフェース画面に割り当てる処理を実行する。これは、例えば上記のように、各ユーザインタフェース画面毎に（その画面ＩＤ４２毎に）、それに対応する信号（信号ＩＤ４１）を全て抽出するものである。各画面ＩＤ４２に対応するトークンは、標準画面リスト３０を参照すれば分かる。

また、例えば、上記のように抽出される各トークンは、任意の属性を示す文字列である。
また、例えば、上記ユーザインタフェース画面は、その定型が複数種類あり、該各種類毎に、上記ユーザインタフェース画面のリストが生成される。

また、例えば、上記定型の種類は、保守画面、トレンド画面などである。
また、例えば、上記属性は、上記制御システムに係わる各種機器、各種計測信号等である。

ここで、本発明は上述した一実施例に限らない。例えば、上記の例では、制御システムエンジニアリング装置１は、予め任意に作成された属性辞書２を用いていた。この為、ユーザは、属性辞書の作成の手間が掛かっていた。更に、ユーザが独自に任意に作成する為、属性辞書２の内容が適切であるとは限らない。あるいは、適切であるにしても、他のユーザの知恵を借りることが出来れば、更に良くなることが期待できる。

また、アプリケーションの製作現場においては、類似のプラントは勿論のこと異種のプラントであっても、設備や機器は重複するものが多く、以ってキーワードが重複する場合が多いのに、その都度手作業で入力するのは、効率面及び品質面で問題である。尚、上記アプリケーションとは、例えば、任意のプラント（プロジェクト）に係わる各種ソフトウェア等であり、その一例が上記標準画面の製作である。

これに対して、以下に説明する制御支援システムでは、この様なユーザの手間を軽減でき、適切な内容の属性辞書を効率的に作成されるようにできる。
図９は、この様な制御支援システムの構成例である。

図示の制御支援システムは、制御システムエンジニアリング装置１’、共有属性辞書管理装置７０等を有する。
ここで、まず、制御システムエンジニアリング装置１’は、上記属性辞書２の代わりに図示の共有属性辞書６１、固有属性辞書６２を用いる点以外は、上記図１の制御システムエンジニアリング装置１と同等の機能を実現するものであり、その説明は省略するものとする。

尚、上記のことから、本発明の制御システムエンジニアリング装置は、属性辞書として例えば上記図２に示す例のような属性辞書２を用いる構成もあれば、属性辞書として例えば図１０、図１１に示す例のような共有属性辞書６１、固有属性辞書６２を用いる構成もある。但し、後者の構成の場合には、更に、共有属性辞書管理装置７０が必要となる。

共有属性辞書管理装置７０は、共有属性辞書マスタ７１、プラント種別マスタ７２を記憶している。共有属性辞書管理装置７０は、また、抽出・提供機能部７３や更新部７４を有する。例えば後述するステップＳ２２，Ｓ２３の処理は、抽出・提供機能部７３が行うが、この例に限らない。また、後述するステップＳ３２，Ｓ３３，Ｓ３４，Ｓ３５の処理は、更新部７４が行うが、この例に限らない。

抽出・提供機能部７３は、例えば、任意の制御システムエンジニアリング装置１’から任意のプラント種別の通知があると、該通知されたプラント種別に対応するキーワードを共有属性辞書マスタ７１から抽出して該抽出結果を通知元の制御システムエンジニアリング装置１’へ送信する。

あるいは、抽出・提供機能部７３は、例えば、上記制御システムエンジニアリング装置１’から通知されたプラント種別に係わる関連プラント種別（例えば、後述する親プラント種別など）を、プラント種別マスタ７２から求めて、通知されたプラント種別に対応するキーワードと該求めた関連プラント種別に対応するキーワードとを共有属性辞書マスタ７１から抽出して、該抽出結果を通知元の制御システムエンジニアリング装置１’へ送信する。

また、更新部７４は、任意の制御システムエンジニアリング装置１’から任意のキーワードとプラント種別の通知があると、該通知されたキーワードが共有属性辞書マスタ７１に未登録である場合には、該通知されたキーワードを共有属性辞書マスタ７１に追加登録する。一方、通知されたキーワードが共有属性辞書マスタ７１に登録済みである場合に、該共有属性辞書マスタ７１における該当キーワードに対応するプラント種別が、上記通知されたプラント種別と異なる場合には、該共有属性辞書マスタ７１における該当キーワードに対応するプラント種別を変更する場合がある。これは、例えば、共有属性辞書マスタ７１における該当キーワードに対応するプラント種別と、上記通知されたプラント種別とに共通の親プラント種別がある場合には、該共有属性辞書マスタ７１における該当キーワードに対応するプラント種別を、該親プラント種別に変更する。

プラント種別マスタ７２は、予め開発者等が任意に作成している。共有属性辞書マスタ７１も、予め開発者等が任意に作成してもよいし、作成しなくてもよいが、何れにしても本例では後述する図１３の処理により、随時、共有属性辞書マスタ７１の内容が更新される。これは、基本的には、任意のユーザが想到した新たなキーワードが追加されるものであるが、この例に限らない。

ここで、制御システムエンジニアリング装置１’、共有属性辞書管理装置７０は、不図示のネットワークに接続されており、ネットワークを介して相互にデータ送受信可能となっている。また、図では、制御システムエンジニアリング装置１’は１台のみであるが、制御システムエンジニアリング装置１’は基本的に複数台存在するものとする。これは、例えば各ユーザに制御システムエンジニアリング装置１’が割当てられている。各ユーザは、それぞれ、自己が担当するプラント（プロジェクト）に関する上記アプリケーション等を、制御システムエンジニアリング装置１’を用いて開発する。

任意の制御システムエンジニアリング装置１’が、共有属性辞書管理装置７０に対して任意のプラント種別を含む所定の要求を送信すると、抽出・提供機能部７３はこの要求のプラント種別に応じた情報を、共有属性辞書マスタ７１から抽出する。但し、その前に、上記プラント種別を用いてプラント種別マスタ７２を検索して、要求のプラント種別に関連するプラント種別を得るようにしてもよい。この場合には、抽出・提供機能部７３は、上記要求のプラント種別に応じた情報だけでなくその関連プラント種別に応じた情報も、共有属性辞書マスタ７１から抽出する。そして、抽出・提供機能部７３は、上記抽出した情報を、要求元の制御システムエンジニアリング装置１’に返信する。

制御システムエンジニアリング装置１’は、受信した上記抽出情報を、共有属性辞書６１として記憶する。また、制御システムエンジニアリング装置１’毎に、そのユーザによって任意に作成された上記固有属性辞書６２が、記憶されている。そして、上記のように、制御システムエンジニアリング装置１’は、共有属性辞書６１、固有属性辞書６２を用いて、図１の制御システムエンジニアリング装置１と同等の処理を行う。例えば、制御システムエンジニアリング装置１’は、基本的には図４の処理を行うが、そのステップＳ１２の処理の際に、属性辞書２ではなく、共有属性辞書６１と固有属性辞書６２を用いて、トークン抽出を行う。

上記図９の制御システムエンジニアリング装置１’の処理について、以下、具体例を用いて更に詳細に説明する。
図１０に、共有属性辞書マスタ７１の具体例を示す。

図１１に、プラント種別マスタ７２の具体例を示す。
まず、図１０の具体例について説明する。

図１０の例では、共有属性辞書マスタ７１は、Ｎｏ．８１、キーワード８２、分類８３、プラント種別８４の各データ項目を有する。尚、図示の右端に示す「説明」は、本説明の為に示しているだけであり、更に図２における説明１４と同様であるので、ここでは特に説明しない。また、Ｎｏ．８１、キーワード８２、分類８３は、上記図２に示す属性辞書２におけるＮｏ．１１、キーワード１２、分類１３と同様であり、ここでの説明は省略する。プラント種別８４は、キーワード１２に係わるプラントの種別である。つまり、例えば、図示の“？クレーン”は、ゴミ処理のプラントに係わるキーワードであり、“フロキュレータ”は、水処理のプラントに係わるキーワードである。

また、一例として、上記プラント種別８４は、階層的に分類されたものである場合もある。例えば、任意のプラント種別として“水処理”があった場合、これは詳細には“下水処理”や“上水道”等に分類されるものである。これを階層的に管理すると、“水処理”の下層（子）に、“下水処理”や“上水道”があることになる。これは、逆に言えば、“下水処理”や“上水道”の親が、“水処理”ということになる。図１１に示すプラント種別マスタ７２の具体例は、この様な階層的な例に対応したものであるが、この例に限らない。

図１１に示す例のプラント種別マスタ７２は、Ｎｏ．９１、親プラント種別９２、プラント種別９３等のデータ項目を有する。
このマスタ７２には、上記のようにプラント種別が階層的に分類されている場合に対して、各プラント種別９３の“親”となるプラント種別が、親プラント種別９２に登録されている。これより、上記の例に応じて図示のように、例えばプラント種別９３が「下水処理」であれば、その親プラント種別９２は「水処理」となっている。プラント種別９３が「上水道」の場合も、その親プラント種別９２は「水処理」となっている。

但し、上記“親”が登録されるのは一例であり、この例に限らない。基本的には、プラント種別マスタ７２には、任意のプラント種別に何等かの関連がある他のプラント種別が、登録されるものである。これは、予め例えば開発者等が任意に決めて設定しておくものである。

図１２は、図９に示す制御支援システムの処理フローチャート図である。
図示の処理例では、まず、制御システムエンジニアリング装置１’が、共有属性辞書管理装置７０に対して、プラント種別を通知する（ステップＳ２１）。このプラント種別は、例えば制御システムエンジニアリング装置１’においてユーザが、例えば自己がアプリケーション作成担当するプラントの種別を入力したものであるが、この例に限らない。ここでは具体例としてプラント種別「下水処理」が通知されたものとする。基本的には、各ユーザが、任意のプロジェクトに係わるアプリケーションをこれから作成するという状況で、このアプリケーションに係わるプラントの種別が、ステップＳ２１で通知されることになる。

共有属性辞書管理装置７０は、上記通知されたプラント種別を検索ワードとして用いて、プラント種別マスタ７２のプラント種別９３を検索して一致するレコードを探し、この該当レコードの親プラント種別９２を取得する（ステップＳ２２）。上記具体例では「下水処理」を用いて検索することになり、図１１の例の場合、３番目のレコードがヒットし、「水処理」が取得されることになる。

そして、上記通知されたプラント種別と、プラント種別マスタ７２から取得したその親プラント種別とを検索ワードとして用いて、共有属性辞書マスタ７１のプラント種別８４を検索して、該当する（一致する）レコードを全て抽出する（ステップＳ２３）。上記図１０の例の場合、４番目と６番目のレコードが該当することになり、これら２つのレコードを抽出することになる。

但し、この例に限らない。図１２に示す例では更に「共通」も検索ワードとして用いる。これは、図１０に示す例の場合、プラント種別に関係なく共通して用いられるワードも登録されており、この様なキーワードのプラント種別８４は「共通」となっている。これより、上記通知されたプラント種別とその親プラント種別に加えて更に「共通」も検索ワードとして用いる。これより、この例の場合、図１０における１番目、２番目、３番目、７番目、８番目のレコードも、更に抽出されることになる。

尚、抽出するのは、レコードの全データ項目とは限らず、例えばキーワード８２と分類８３だけであっても構わない。
ステップＳ２３では、更に、抽出したレコードを通知元の制御システムエンジニアリング装置１’に返信する。

制御システムエンジニアリング装置１’は、受信した情報（抽出されたレコード）を所定の記憶領域に格納することで、共有属性辞書６１を作成する（ステップＳ２４）。
その後は、例えば制御システムエンジニアリング装置１’のユーザが作成していた、例えば「下水処理」プラントに応じた独自のキーワードが登録されている個別属性辞書６２と、上記作成された共有属性辞書６１とを用いて、上記標準画面の生成等の処理を実行する（ステップＳ２５）。

上記のように、作成された共有属性辞書６１と、主にそのユーザがアプリケーション作成担当するプラント（プロジェクト）固有のキーワードが登録された個別属性辞書６２とを合わせて、上記図１の実施例における属性辞書２の代わりとして活用する。つまり、標準画面生成処理に関して、上記辞書６１，６２を用いて、信号リストの各信号名称からトークンを抽出する。尚、この様な処理を、属性辞書検索サービスと呼ぶものとする。

尚、上述した例に限らず、例えば作成された共有属性辞書６１だけを用いて属性辞書検索サービス等を行うようにしてもよい。共有属性辞書６１は、上記のようにユーザが任意のプラント種別を指定するだけで、自動的に、このプラント種別やその関連プラント種別に係わるキーワード等が抽出されて作成されるものである。よって、属性辞書作成の手間が軽減される。更に、後述する図１３の処理が各制御システムエンジニアリング装置１’で実行されることで、各ユーザがそれぞれ想到するキーワードがマスタ７１に登録されることになり、適切なキーワードが抽出されて共有属性辞書６１が作成される可能性が高まることになる。つまり、他者の知恵を借りることができ、適切なキーワードを含む共有属性辞書６１が作成されることが期待できる。

また、任意のときに（随時）図１３の処理を行って、共有属性辞書マスタ７１の更新を行うようにする。
図１３は、共有属性辞書マスタの更新処理のフローチャート図である。

図１３の処理例では、任意のときに任意の制御システムエンジニアリング装置１’において、そのユーザの指示などに応じて、そのときの個別属性辞書６２の登録データ（キーワード等）を一覧表示する。そして、ユーザに、任意の１以上のキーワードを選択させ、選択されたキーワードを全て共有属性辞書管理装置７０に通知する（ステップＳ３１）。その際、プラント種別や分類も一緒に通知するようにしてもよい。プラント種別は、基本的に、そのユーザが担当するプラントの種別であり、ユーザが入力するものであってもよいし、予め登録されていてもよい。

尚、個別属性辞書６２には、例えば、そのユーザ等が担当するプラントに応じた独自のキーワードが当該ユーザによって任意に登録されており、その中には当該制御システムエンジニアリング装置１’（プラント）でしか使用されないような独特なキーワードもあれば、他のユーザ（他のプラント）でも使用するかもしれないキーワードもあるかもしれない。基本的には、ユーザが「他のユーザ（他のプラント）でも使用するかもしれない」と考えるキーワードを、選択してもらうようにする。尚、個別属性辞書６２のデータ構成は、図２と同様であってよく、特に具体例等は示さないものとする。

共有属性辞書管理装置７０は、上記通知されたキーワードそれぞれを用いて、共有属性辞書マスタ７１のキーワード８２を検索して（ステップＳ３２）、ヒットするか否かを判定する（ステップＳ３３）。すなわち、そのキーワードが既に登録済みであるか否かを判定する。

ヒットしなかった場合（ステップＳ３３，ＮＯ）、すなわちそのキーワードが未登録である場合には、そのキーワードを上記通知されたプラント種別や分類と共に、共有属性辞書マスタ７１に新規レコードとして追加登録する（ステップＳ３４）。

一方、ヒットした場合には（ステップＳ３３，ＹＥＳ）、そのキーワードは既に登録されているので、何も行わなくてもよいが、本例ではステップＳ３５の処理を行う。
ステップＳ３５の処理は、まず、ヒットしたレコードにおけるプラント種別８４が、上記通知されたプラント種別と同じであるか否かをチェックし、同じであれば何も処理を行わない。一方、同じではない場合には、ヒットしたレコードにおけるプラント種別８４を、現在のプラント種別の親となるプラント種別に変更する。親プラント種別は、プラント種別マスタ７２を参照して判別する。

尚、上記現在のプラント種別の親となるプラント種別は、例えば、現在のプラント種別８４と上記通知されたプラント種別とに共通の親プラントであり、例えば、ヒットしたレコードにおけるプラント種別８４が「上水道」であり、通知されたプラント種別が「下水処理」であった場合、このレコードのプラント種別８４は両者に共通する親プラントである「水処理」に変更されることになる。これによって、図１２の処理において、通知されたプラント種別が「上水道」の場合も「下水処理」の場合も、上記のことから「水処理」に応じたキーワードも抽出されることになる。つまり、例えば、が「上水道」、「下水処理」それぞれについて同じキーワードを登録する場合に比べて、登録されるデータ量が少なくて済むようになる。

尚、上記共通の親プラントが無い場合には、例えば、通知されたキーワードを通知されたプラント種別や分類と共に、共有属性辞書マスタ７１に新規レコードとして追加登録するようにしてもよい。但し、この例に限らない。

上記のように、任意のユーザが自己の担当プラントに係わり想到したキーワードを、共有属性辞書マスタ７１に登録させることで、他のユーザが利用できるようにすることもできる。特に上述した処理例では上記担当プラントと同じ又は関連するプラント種別の担当者は、上記ステップＳ２３で上記他ユーザが想到したキーワードも抽出されるはずであり、他者が想到したキーワードを有効に利用できる可能性が高いと考えられる。

また、上記登録処理の際、登録しようとする固別属性辞書６２のキーワードが、共有属性辞書マスタ７１上に既に存在する場合に、どのプラント種別に存在するかによって、場合によっては上記のようにそのキーワードに対応するプラント種別階層を弾力的に見直し（例えば、“親”のプラント種別に変更する）、辞書の再利用が最適に実施されるようにする。また、これにより、例えば、辞書の容量を減らすことができる。

以上のように、本手法を適用することにより、制御システムエンジニアリングにおいて、ユーザインタフェースの自動生成時の属性辞書の管理を適切に行うことで、自動割付率を向上させ、ユーザインタフェースロジックの作成プロセスの効率向上による工期短縮及びコスト削減、さらには制御システムの品質向上が可能となる。特に、共有属性辞書管理装置７０を設けたことにより、アプリケーションの作成都度、エンジニア（ユーザ）による手入力で作成する必要であった属性辞書を、自動的に作成できるようにし、更にエンジニア間でキーワードを共有して利用できるようにすることができる。エンジニアは、プラント種別を指定するだけで、自プロジェクトに応じた共有属性辞書６１が、自動的に生成されて、これを利用することができる。

また、本手法によれば、複数エンジニアによる同一プロジェクトの並列作業時の共有作業を容易にできるようにすることもできる。逆に、アプリケーション固有の属性辞書のキーワードの共有属性辞書マスタ７１への登録時は、共有属性辞書管理装置７０側で共有属性辞書マスタ７１とマージ処理（図１３の処理）を行うことで、管理を効率化するとともに、階層分類を行い属性辞書の検索ヒット率向上を図った。

属性辞書作成作業を、共有属性辞書の活用により最小限にすることで、エンジニアリング作業の効率向上による工期短縮及びコスト削減、さらには制御システムの品質向上が実現できる。

以上説明したように、本手法により、制御システムエンジニアリングにおいて、ユーザインタフェースロジックの作成プロセス（標準画面の作成など）の効率向上による工期短縮及びコスト削減、さらには制御システムの品質向上が可能になる。

本手法により、制御システムエンジニアリングにおいて、従来では手作業で行われていた、標準画面の一覧リストの作成及びリストされた各標準画面に対する信号の割付作業が、信号リスト５等から自動生成することができるので、エンジニアリング作業の効率向上による工期短縮及びコスト削減、さらには制御システムの品質向上が実現できる。

更に、上記処理における特にトークン抽出に用いられる属性辞書を、他のユーザ（エンジニア）が想到したキーワードも利用して自動的に適切なものが生成されるようにすることもできる。

１ 制御システムエンジニアリング装置
２ 属性辞書
３ 制御システム
５ 信号リスト
１１ ＮＯ．
１２ キーワード
１３ 分類
２１ Ｎｏ．
２２ TAGNo.
２３ 信号名称
３０ 標準画面リスト
３１ 画面ＩＤ
３２ トークン
４０ 信号−画面対応テーブル
４１ 信号ＩＤ
４２ 画面ＩＤ
５１ 属性辞書記憶部
５２ トークン抽出部
５３ 画面リスト生成部
５４ 信号関連付部
１’ 制御システムエンジニアリング装置
６１ 共有属性辞書
６２ 固有属性辞書
７０ 共有属性辞書管理装置
７１ 共有属性辞書マスタ
７２ プラント種別マスタ
７３ 抽出・提供機能部
８１ Ｎｏ．
８２ キーワード
８３ 分類
８４ プラント種別
９１ Ｎｏ．
９２ 親プラント種別
９３ プラント種別

Claims (12)

1. 制御システムの各属性に係わる複数のキーワードが登録された属性辞書を記憶する属性辞書記憶手段と、
   顧客側で作成された、任意の制御システムに係わる任意の複数の信号の信号名称が含まれる信号リストを用いて、該信号リストにおける前記各信号毎に、その前記信号名称から、任意の前記キーワードが含まれるトークンを複数抽出するトークン抽出手段と、
   前記抽出された複数のトークンに応じた複数のユーザインタフェース画面のリストを生成する画面リスト生成手段と、
   前記各信号を、その信号に係わる複数の属性に対応する複数の前記ユーザインタフェース画面に割り当てる信号関連付手段と、
   を有することを特徴とする制御システムエンジニアリング装置。
2. 前記画面リスト生成手段は、更に、前記各信号に対応付けて、その信号に係わる全ての前記ユーザインタフェース画面を登録した信号−画面対応テーブルを生成し、
   前記信号関連付手段は、前記リストと該信号−画面対応テーブルを用いて前記割り当てを行うことを特徴とする請求項１記載の制御システムエンジニアリング装置。
3. 前記抽出される各トークンは、任意の前記属性を示す文字列であることを特徴とする請求項１または２記載の制御システムエンジニアリング装置。
4. 前記ユーザインタフェース画面は、その定型が複数種類あり、該各種類毎に、前記ユーザインタフェース画面のリストが生成されることを特徴とする請求項１〜３の何れかに記載の制御システムエンジニアリング装置。
5. 前記定型の種類は、保守画面、トレンド画面であることを特徴とする請求項４記載の制御システムエンジニアリング装置。
6. 前記属性は、前記制御システムに係わる各種機器、各種計測信号であることを特徴とする請求項１〜５の何れかに記載の制御システムエンジニアリング装置。
7. 請求項１の制御システムエンジニアリング装置と、共有属性辞書管理装置とを有する制御支援システムであって、
   前記共有属性辞書管理装置は、
   制御システムの各属性に係わる複数のキーワードが、それぞれ、そのキーワードが係わるプラント種別と共に登録された共有属性辞書マスタと、
   任意の前記制御システムエンジニアリング装置から任意のプラント種別の通知があると、該通知されたプラント種別に対応するキーワードを前記共有属性辞書マスタから抽出して該抽出結果を通知元の制御システムエンジニアリング装置へ送信する抽出・提供手段とを有し、
   前記制御システムエンジニアリング装置は、前記抽出結果を前記属性辞書の一種である共有属性辞書として前記属性辞書記憶手段に記憶し、
   前記トークン抽出手段は、該共有属性辞書のキーワードを用いて前記トークン抽出を行うことを特徴とする制御支援システム。
8. 前記共有属性辞書管理装置は、
   前記プラント種別毎に、そのプラント種別に関連するプラント種別である関連プラント種別が、予め登録されたプラント種別マスタを更に有し、
   前記抽出・提供手段は、前記制御システムエンジニアリング装置から通知されたプラント種別に係わる前記関連プラント種別を、前記プラント種別マスタから求めて、前記通知されたプラント種別に対応するキーワードと該求めた関連プラント種別に対応するキーワードとを前記共有属性辞書マスタから抽出して、該抽出結果を通知元の制御システムエンジニアリング装置へ送信することを特徴とする請求項７記載の制御支援システム。
9. 前記属性辞書記憶手段には、前記属性辞書の一種として、前記制御システムエンジニアリング装置のユーザによって任意に登録された、任意のプラントに係わる独自のキーワードを含む固有属性辞書が、更に記憶されており、
   前記トークン抽出手段は、前記共有属性辞書のキーワードだけでなく該固有属性辞書のキーワードも更に用いて、前記トークン抽出を行うことを特徴とする請求項７または８記載の制御支援システム。
10. 前記制御システムエンジニアリング装置は、
    前記固有属性辞書のキーワードを前記共有属性辞書管理装置に通知する通知手段を更に有し、
    前記共有属性辞書管理装置は、
    該通知されたキーワードが前記共有属性辞書マスタに未登録である場合には、該通知されたキーワードを共有属性辞書マスタに追加登録する共有属性辞書マスタ更新手段を更に有することを特徴とする請求項７または８記載の制御支援システム。
11. 前記通知手段は、前記キーワードと共にプラント種別も通知し、
    前記共有属性辞書管理装置の前記共有属性辞書マスタ更新手段は、
    前記通知手段より通知されたキーワードが前記共有属性辞書マスタに登録済みである場合に、該共有属性辞書マスタにおける該当キーワードに対応するプラント種別が、前記通知されたプラント種別と異なる場合には、該共有属性辞書マスタにおける該当キーワードに対応するプラント種別を変更する場合があることを特徴とする請求項１０記載の制御支援システム。
12. 前記共有属性辞書マスタ更新手段は、該共有属性辞書マスタにおける該当キーワードに対応するプラント種別と、前記通知されたプラント種別とに共通の親プラント種別がある場合には、該共有属性辞書マスタにおける該当キーワードに対応するプラント種別を、該親プラント種別に変更することを特徴とする請求項１１記載の制御支援システム。