(57)【要約】【課題】  複数のＩ／Ｆに同時に対応し、ＦＡ機器の新規機器の投入及びバージョンアップに伴うＩ／Ｆのアップデータを簡単にすることができるＦＡ機器インタフェース統合化装置を得る。【解決手段】  Ｉ／Ｆ０２にＩ／Ｆ定義１２を供給するＩ／Ｆ定義生成部２６と、Ｉ／Ｆ０２とＩ／Ｆ０４間に配置されるデータ変換装置０３に変換ルール１３を供給する変換プロファイル生成部と、Ｉ／Ｆの入出力の検証を行うＩ／Ｆ検証部２４を有するプロファイル情報維持管理装置２１により参照され、Ｉ／Ｆ定義情報３９と、機器情報４０と、アプリケーション情報４１と、動作連係情報４２と、検証情報４３と、変換情報４４とを管理する共用情報管理装置２７を備え、ＦＡ機器０９の設置や更新に対応できるようにした。【選択図】図１
2005251120.tif 000002
【特許請求の範囲】
【請求項１】
ＦＡ機器とアプリケーションとを接続するネットワーク上に配置され、データ構造を含む第一の定義にしたがって動作する第一のＩ／Ｆ（インタフェース）、上記ネットワーク上に配置され、上記第一の定義とは異なる第二の定義にしたがって動作する第二のＩ／Ｆ、上記第一のＩ／Ｆ及び第二のＩ／Ｆのそれぞれのデータ構造を相互に変換する変換ルールを有するデータ変換装置、上記第一のＩ／Ｆの第一の定義及び上記第二のＩ／Ｆの第二の定義を生成するＩ／Ｆ定義生成部、及び上記第一の定義及び上記第二の定義に基づき、上記データ変換装置の変換ルールを生成する変換プロファイル生成部を備えたことを特徴とするＦＡ機器インタフェース統合化装置。
【請求項２】
上記第一のＩ／Ｆの第一のデータ構造は、 バイナリ構造依存機種依存構造であり、上記第二のＩ／Ｆの第二のデータ構造は、バイナリ構造非依存機種依存構造であることを特徴とする請求項１記載のＦＡ機器インタフェース統合化装置。
【請求項３】
ＦＡ機器とアプリケーションとを接続するネットワーク上に配置され、バイナリ構造依存機種依存構造の第一のデータ構造を含む第一の定義にしたがって動作する第一のＩ／Ｆ、上記ネットワーク上に配置され、バイナリ構造非依存機種依存構造の第二のデータ構造を含む第二の定義にしたがって動作する第二のＩ／Ｆ、上記第一のデータ構造及び第二のデータ構造を相互に変換する変換ルールを有する第一のデータ変換装置、上記ＦＡ機器のデータ構造及び上記第一のデータ構造を相互に変換する変換ルールを有する第二のデータ変換装置、上記第一のＩ／Ｆの第一の定義及び上記第二のＩ／Ｆの第二の定義を生成するＩ／Ｆ定義生成部、上記第一の定義及び上記第二の定義に基づき、上記第一のデータ変換装置の変換ルールを生成すると共に、上記ＦＡ機器のデータ構造及び上記第一の定義に基づき、上記第二のデータ変換装置の変換ルールを生成する変換プロファイル生成部を備えたことを特徴とするＦＡ機器インタフェース統合化装置。
【請求項４】
上記Ｉ／Ｆの定義をデータベース化したＩ／Ｆ定義情報を備え、上記Ｉ／Ｆ定義情報では、各Ｉ／Ｆの定義が複数に分割されてＩ／Ｆ定義アイテムとして管理され、上記各Ｉ／Ｆ定義アイテムは、関連付けられて管理され、上記Ｉ／Ｆ定義生成部によるＩ／Ｆの定義の生成に用いられることを特徴とする請求項１〜請求項３のいずれかに記載のＦＡ機器インタフェース統合化装置。
【請求項５】
上記Ｉ／Ｆのデータ入出力の検証を行うＩ／Ｆ検証手段を備えたことを特徴とする請求項１〜請求項４のいずれかに記載のＦＡ機器インタフェース統合化装置。
【請求項６】
上記変換ルールによる個々のデータ変換の種別に対応した変換用モジュールを有する変換用モジュールライブラリを備え、上記変換プロファイル生成部は、上記変換用モジュールライブラリの変換用モジュールを用いて上記変換ルールを生成することを特徴とする請求項１〜請求項５のいずれかに記載のＦＡ機器インタフェース統合化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＦＡ機器とソフトウェアを結びつけるインタフェース（Ｉ／Ｆ）を統合化するＦＡ機器インタフェース統合化装置に関するものである。
【背景技術】
【０００２】
従来の技術を示す特許文献１は、プログラマブルロジックコントローラ（ＰＬＣ）を加える際の手間が少ない制御システムを実現することを目的としたもので、ここでは、ＰＬＣはネットワークを介して接続されている。
この特許文献１では、制御用ホストコンピュータの共通ネットワークインタフェース部は、ＰＬＣへのデータを共通ネットワークを介してグラフィック操作パネルへ送出する。グラフィック操作パネルは、プロトコル変換を行った後、専用ネットワークを介してＰＬＣに転送する。ＰＬＣの機種に拘らず、制御用ホストコンピュータが共通プロトコルで通信することにより、複数機種の混在した制御システムを実現することができる。この際、共通ネットワークの通信プロトコルと専用ネットワークの通信プロトコルを相互変換するための情報は、プロトコル変換用記憶部において保存される。
このプロトコル変換用記憶部は、専用ネットワークで伝送されるデータのフォーマットを示すデータ転送フォーマットと両ネットワークで伝送されるコマンドコード間の対応関係を示すコマンド変換テーブルによる情報を保持し、これを利用した変換を行う。
【０００３】
特許文献１以前のＳ／Ｗ（ソフトウエア）や機器は、個別のＩ／Ｆ（インタフェース）に適合させるために、個々の変換用のモジュールを用意する必要があり、それぞれのＩ／Ｆに併せてＳ／Ｗや機器の設計者は、変換モジュールをプログラミングする必要があった。特許文献１は、上述するように変換モジュールをグラフィック操作パネルという形で提供する。この変換モジュールにより、共用ネットワークへの集約を図ることが可能となり、効率的にシステム構築が可能となった。
【０００４】
【特許文献１】特開２０００−１３８７２５号公報（段落番号００２４〜００６６、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１では、変換モジュールのプログラミングに関する労力が不要となる反面、プロトコル変換用記憶部内のデータ構築、つまり、コマンド変換テーブルに記載される両コード間の対応関係は、別途入力、管理することが必要という問題があった。
このデータ構築には、なお多くの手間が掛かる。特に複数のＩ／Ｆに同時に対応する必要がある場合など、新規機器の投入や、バージョンアップに伴うＩ／Ｆのアップデートなど、煩雑な作業が予想される。
【０００６】
この発明は、上述のような課題を解決するためになされたものであり、複数のＩ／Ｆに同時に対応し、ＦＡ機器の新規機器の投入及びバージョンアップに伴うＩ／Ｆのアップデータを簡単にすることができるＦＡ機器インタフェース統合化装置を得ることを目的にしている。
【課題を解決するための手段】
【０００７】
この発明に係わるＦＡ機器インタフェース統合化装置においては、ＦＡ機器とアプリケーションとを接続するネットワーク上に配置され、データ構造を含む第一の定義にしたがって動作する第一のＩ／Ｆ、ネットワーク上に配置され、第一の定義とは異なる第二の定義にしたがって動作する第二のＩ／Ｆ、第一のＩ／Ｆ及び第二のＩ／Ｆのそれぞれのデータ構造を相互に変換する変換ルールを有するデータ変換装置、第一のＩ／Ｆの第一の定義及び第二のＩ／Ｆの第二の定義を生成するＩ／Ｆ定義生成部、及び第一の定義及び第二の定義に基づき、データ変換装置の変換ルールを生成する変換プロファイル生成部を備えたものである。
【発明の効果】
【０００８】
この発明は、以上説明したように、ＦＡ機器とアプリケーションとを接続するネットワーク上に配置され、データ構造を含む第一の定義にしたがって動作する第一のＩ／Ｆ、ネットワーク上に配置され、第一の定義とは異なる第二の定義にしたがって動作する第二のＩ／Ｆ、第一のＩ／Ｆ及び第二のＩ／Ｆのそれぞれのデータ構造を相互に変換する変換ルールを有するデータ変換装置、第一のＩ／Ｆの第一の定義及び第二のＩ／Ｆの第二の定義を生成するＩ／Ｆ定義生成部、及び第一の定義及び第二の定義に基づき、データ変換装置の変換ルールを生成する変換プロファイル生成部を備えたので、ＦＡ機器とアプリケーション間のＩ／ＦのＩ／Ｆ定義の生成及びＩ／Ｆ間の変換ルールの生成を行い、ＦＡ機器の機種変更や機能更新の際の変換ルールやＩ／Ｆの維持管理を容易にすることができる。
【発明を実施するための最良の形態】
【０００９】
実施の形態１．
図１は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置を示す構成図である。
図１において、ＦＡ機器Ｉ／Ｆ統合化装置は、ＦＡ機器０１とアプリケーション０９の間に存在するＩ／Ｆ間に配置されるデータ変換装置０３、データ変換装置０６（第一のデータ変換装置）、データ変換装置０８（第二のデータ変換装置）と、データ変換装置０３、０６、０８に変換ルール１３、１６、１８を入力するための複数のプロファイル情報維持管理装置２１、４５と、共用情報管理装置２７とから構成される。
Ｉ／Ｆ０２、Ｉ／Ｆ０４、Ｉ／Ｆ０５（第二のＩ／Ｆ）、Ｉ／Ｆ０７（第一のＩ／Ｆ）が、ＦＡ機器０１とアプリケーション０９の間に配置され、それぞれＩ／Ｆ定義１２、Ｉ／Ｆ定義１４、Ｉ／Ｆ定義１５（第二の定義）、Ｉ／Ｆ定義１７（第一の定義）にしたがって動作する。
【００１０】
共用情報管理装置２７は、主に６つの情報が管理され、それぞれの情報管理部が存在する。この６つは、Ｉ／Ｆ定義情報管理部３３、変換情報管理部３８、動作連係情報管理部３６、機器情報管理部３４、アプリケーション情報管理部３５及び検証情報管理部３７である。この他、検索機能２８、検証機能２９、入力部３０、表示部３１、データ操作部３２を有すると共に、Ｉ／Ｆ定義情報管理部３３によって管理されるＩ／Ｆ定義情報３９、機器情報管理部３４によって管理される機器情報４０、アプリケーション情報管理部３５によって管理されるアプリケーション情報４１、動作連係情報管理部３６によって管理される動作連係情報４２、検証情報管理部３７によって管理される検証情報４３、及び変換情報管理部３８によって管理される変換情報４４を有している。
プロファイル情報維持管理装置２１、４５は、共用情報管理装置２７が管理するこれらの情報を用い、既存の情報を組み合わせ、所望の変換ルールやＩ／Ｆを構築する。
【００１１】
次に、共用情報管理装置２７を構成する各情報管理部の機能について説明する。
Ｉ／Ｆ定義情報管理部３３では、このＦＡ機器Ｉ／Ｆ統合化装置で取り扱うＩ／Ｆの定義情報を維持管理する。Ｉ／Ｆの名称や型などの情報が定義される。管理されるＩ／Ｆ定義は、実施の形態１では、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式により定義される。
変換情報管理部３８では、Ｉ／Ｆ間の変換ルールにおいて、単に置き換えではない、融合や分離など、データの内容の変更に伴う変換の際に用いられる変換モジュールを維持管理する。指定された変換の種別に応じて、これらの変換モジュールを呼び出し、呼び出された変換モジュールは、データの変換実行時にデータ変換装置から呼び出されて利用される。
動作連係情報管理部３６は、複数のＩ／Ｆ定義間の関係についての情報を維持管理する。ここでの関係／連係とは、複数のＩ／Ｆの定義が、何らかの関係を持って用いられることを前提としている場合の、関係を記述したものである。
機器情報管理部３４及びアプリケーション情報管理部３５は、それぞれ、機器、アプリケーションの属性情報を維持管理する。機器の名称や、メーカ名などである。
検証情報管理部３７は、変換データを用いる上で必要となる条件や制限についての情報、および検証関連のモジュールを維持管理する機能を有する。
【００１２】
一方、プロファイル情報維持管理装置２１、４５は、主に３つの機能、Ｉ／Ｆ定義生成、Ｉ／Ｆ検証、変換プロファイル生成の機能を有する。それぞれ、Ｉ／Ｆ定義生成部２６、５０、Ｉ／Ｆ検証部２４、４８、変換プロファイル生成部２５、４９によって上述の機能が提供される。この他、入力（編集）部２２、４６と、表示部２３、４７を有する。
【００１３】
図２は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＩ／Ｆ定義を生成する手順を示すフローチャートである。
図３は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のバイナリ構造非依存機種依存Ｉ／Ｆを生成する手順を示すフローチャートである。
図４は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のバイナリ構造非依存機種依存Ｉ／Ｆ及びバイナリ構造依存機種依存Ｉ／Ｆ間の変換データを生成する手順を示すフローチャートである。
図５は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のアプリケーション側からみたＩ／Ｆを生成する手順を示すフローチャートである。
【００１４】
図６は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＩ／Ｆ定義を示す図であり、各構成要素間を接続する線は、要素間の参照関係を指し示す１例を示したものである。
図６において、共有Ｉ／Ｆセット情報５１、５２、５８、６６、６７、及び変換／参照ノード情報５７が示されている。共有Ｉ／Ｆセット情報５１、５２、５８、６６、６７の内、特に共有Ｉ／Ｆセット情報５１、５２は、アプリケーション用の共有Ｉ／Ｆセット情報であり、共有Ｉ／Ｆセット情報６６、６７は、機器用の共有Ｉ／Ｆセット情報である。
ここで、共有Ｉ／Ｆセット情報とは、ある目的に添って集められたＩ／Ｆ群の集まりを表わすものである。また、変換／参照ノード情報とは、複数のサブＩ／Ｆ間の変換と参照に関わる情報を保持するための情報を集めたものである。
共有Ｉ／Ｆセット情報内には、サブＩ／Ｆ５４、５５、５６、５９、６８がある。サブＩ／Ｆとは、共有Ｉ／ＦセットのＩ／Ｆ群の部分集合である。
また、変換／参照ノード情報内には、サブＩ／Ｆ６０、６１がある。変換／参照ノード情報の内部には、さらに、変換情報６２、検証用情報６３、参照関係情報６４、包含情報６５がある。
変換情報６２とは、複数のサブＩ／Ｆ間の変換の種別を定義した情報である。検証用情報６３は、サブＩ／Ｆ間の変換に伴い、入力データの妥当性や、データ間の整合性のチェックを行うための情報である。参照関係情報６４は、サブＩ／Ｆや変換／参照ノード情報が、他の、いずれのサブＩ／Ｆや変換／参照ノード情報を参照しているのかを記述するための情報である。包含情報６５は、サブＩ／Ｆや変換／参照ノード情報が、他の、いずれのサブＩ／Ｆや変換／参照ノード情報を包含しているのかを記述するための情報である。
【００１５】
図７は、この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＦＡ機器のデータ構造を示す図である。
図７において、コントローラ（Ｃｏｎｔｒｏｌｌｅｒ）は、データ構造全体を表わすルートノードである。ユニット（Ｕｎｉｔ）は、データの一塊を表現するためのタグである。メモリ上ではブロックやブロック内で取り扱うワード情報がある。いずれも、１つのデータの塊として取り扱うことができる。この情報の塊を表現するタグである。実際にこのタグが、どのデータの塊を表現しているのかは、メンバタグのＴｙｐｅで指定する。
ユニットｓ（Ｕｎｉｔｓ）は、複数のＵｎｉｔの塊を取り扱うためのタグである。このＵｎｉｔｓと上述のＵｎｉｔを交互に重ねることにより、全体の階層構造を表現する。Ｕｎｉｔ同様に実際のデータの内容は、Ｔｙｐｅによる。
レングス（Ｌｅｎｇｔｈ）は、ＵｎｉｔもしくはＵｎｉｔｓが、メモリ上で、どれだけの領域を確保しているのかを表現するためのタグである。この単位は、Ｌｅｎｇｔｈの属性であるＴｙｐｅＯｆＶａｌｕｅで表わす。
ナンバー（ＮｕｍｂｅｒＯｆＣｈｉｌｄｒｅｎ）は、下位のＵｎｉｔｓもしくはＵｎｉｔの個数である。
タイプ（Ｔｙｐｅ）は、Ｕｎｉｔ、もしくはＵｎｉｔが実際にメモリ構造においてどのタイプの領域を表現しているのかを表現するためのタグ情報であり、Ｂｌｏｃｋ、Ｂｌｏｃｋｓ、Ｗｏｒｄ、Ｂｉｔｓ、Ｂｉｔがある。
オフセット（ＯｆｆｓｅｔＩｎＰａｒｅｎｔ）は、親のＵｎｉｔもしくはＵｎｉｔ内で、自分がどの位置から格納されているのかを表現する。単位についてはＬｅｎｇｔｈと同様である。
値（Ｖａｌｕｅ）は、実際に値を格納するためのタグである。
【００１６】
次に、Ｉ／Ｆ定義情報管理部３３で管理されるＩ／Ｆ定義情報について説明する。
実施の形態１において、アプリケーション０１とＦＡ機器０９は、複数のＩ／Ｆを介してデータ交換を行う。各Ｉ／Ｆは、データ交換の共通の場であり、データ交換の枠組みである。Ｉ／Ｆ定義情報３９は、このデータ交換の場を定義するための情報である。
Ｉ／Ｆ定義情報３９は、Ｉ／Ｆ定義情報管理部３３において分割細分化され、管理される。ここで行われる分割は、いくつかの樹状に構成されるネットワーク状に連係される形で分割される。これらの分割された連係関係を構成するアイテムは、２つの種類のものから構成される。
１つは、単一のデータを管理するアイテムであり、もう１つは前者のアイテムを複数束ねるためのアイテムである。このように分割された単位を、ここで仮にＩ／Ｆ定義アイテムと称することにする。実際にＦＡ機器０９とアプリケーション０１の間で用いられるＩ／Ｆは、このＩ／Ｆ定義アイテムを複数組み合わせ、定義することになる。
【００１７】
次に、この複数の組み合わせについて、以下に説明する。
ＦＡ機器０９は、特定の目的に応じて組み合わせて用いられることが多い。特定の目的とは、例えばＮＣや組み立て装置などである。これらの多くの装置は、複数の機器を含む。これらの装置の内部に含まれる機器を用いる場合、装置側でどのような制御を行うかといった視点で、制御に係わる信号名等の用語が用いられることが多い。一方で、含まれる機器そのものは、含まれる装置を前提として作成されたものだけではないことが多い。従って、この場合、装置側で取り扱う用語によらない、機器を製作する側で策定した用語を用いたものが、すでに存在していることが多い。
【００１８】
また、組み合わせは、次の観点からも取り扱われる。
ある複数種類の機器があるとすると、それぞれの機器におけるＩ／Ｆの定義は、その異なる種類に応じて、内容が異なることは、ごく通常のことである。しかし、その異なる度合いは、一定ではない。この度合いは、様々な要因による。例えば、その機器の機能や目的、動作の方法、起動停止の方法などである。いくつかの機器におけるＩ／Ｆの一部は、他器のＩ／Ｆの一部と同一である場合もあり、また、他の機器のＩ／Ｆとはまったく異なる場合もある。
また、この一部の同一性についても、様々な場合がある。例えば、そのＩ／Ｆの一部が一見異なる場合においても、機能や役割から見ると（例えば、起動停止など）、まったく同一なものとして取り扱うことが望ましい部分も存在する。この場合は、それらの機能に係わるＩ／Ｆ上の定義は、いくつかの同一のアイテムを含むものとして取り扱うことが自然である。
Ｉ／Ｆを定義する要素であるＩ／Ｆ定義アイテムは、以上述べたような性質を自然に表わすことのできるデータ管理方式とすべきである。
【００１９】
これらの、組み合わせを示したものが図６である。
あるＩ／Ｆの定義は、複数のＩ／Ｆの定義から構成されている。先に取り上げたＩ／Ｆアイテム定義は、このＩ／Ｆの定義に用いられる１つの構成要素である。
例えば、共有Ｉ／Ｆセット情報５８に含まれるサブＩ／Ｆ５９であり、共有Ｉ／Ｆセット情報／機器用６７に含まれるサブＩ／Ｆ６８であり、共有Ｉ／Ｆセット情報／アプリ用５３に含まれるサブＩ／Ｆ５４である。このＩ／Ｆの定義は、既存のものだけではなく、必要に応じて、Ｉ／Ｆを組み合わせて作成する。作成したＩ／Ｆの定義は、共用情報管理装置２７の入力部３０より定義情報を入力し、Ｉ／Ｆ定義情報管理部３３において管理する
【００２０】
共用情報管理装置２７内のＩ／Ｆ情報管理部３３において管理されたＩ／Ｆの定義は、必要に応じて、データ操作部３２において、データを取り出し、これらのＩ／Ｆを組み合わせることにより、新たなＩ／Ｆ定義を作成することができる。
登録されたＩ／Ｆの定義は、新たなＩ／Ｆアイテム定義として、さらに別のＩ／Ｆの定義に用いる。
このように作成され、再利用することのできるＩ／Ｆ定義やＩ／Ｆアイテム定義には、以下の４つの情報を個々のＩ／Ｆアイテムに与える。
（１）履歴関係（各定義の変更履歴上の前後関係を管理）
（２）依存関係（Ｉ／Ｆ定義内のＩ／Ｆアイテム定義間の依存関係、意味的な依存関係）
（３）参照関係（Ｉ／Ｆアイテムの参照関係から来る依存関係について）
（４）包含関係（Ｉ／Ｆ定義やＩ／Ｆ定義アイテムが含むＩ／Ｆ定義アイテムとの関係）
【００２１】
次に（１）の履歴関係について説明する。
この履歴関係で説明する履歴とは、あるＩ／Ｆアイテム定義を生成する際に、どのような既存のＩ／Ｆアイテムをベースに作成したのかを記録するための情報である。
Ｉ／Ｆ定義アイテムやＩ／Ｆ定義が、ある既存のものをベースに作成された場合、既存の定義と、新規に作成した定義との間で結ばれる関係である。定義されるＩ／Ｆは、共用情報管理装置２７内のＩ／Ｆ定義情報管理部３３内で管理されるが、この中でＩ／Ｆは、全て一意の番号等の識別子を付けて保存されている。Ｉ／Ｆの定義内は、ＸＭＬで階層的にタグ管理され、履歴関係を示すタグ位置に、対象となるＩ／Ｆの識別子の値を格納することにより、この情報を格納する。
【００２２】
次に、（２）の依存関係について説明する。
この依存関係は、Ｉ／Ｆアイテム定義間と定義との間に存在する意味上の依存関係を表わしたものである。用途や意味から見て、切り離すことのできない定義間には、この関係を属性情報としてつけておく。
これは次のように行われる。依存関係は、依存関係の種別を表わす依存関係種別情報を用いて属性付けされる。この依存関係種別情報は、Ｉ／Ｆ定義情報管理部３３が、Ｉ／Ｆ定義情報３９とは別に管理する。依存関係種別情報に管理される、それぞれの依存関係種別情報のアイテムは、Ｉ／Ｆ定義アイテムを管理する場合と同様に、依存関係種別情報内で一意に識別できる識別子により管理される。依存関係種別は、いくつかのデフォルトの依存関係が用意されている。ここでは３つの関係種別をデフォルトとして用いるシステムを考えた。仮にここで、それらの関係種別をレベル１、レベル２、レベル３との名称をつけて用いることとする。
レベル１は、Ｉ／Ｆアイテム間の依存関係が最も強い場合である。常にそれらのアイテムは、同一Ｉ／Ｆ内で用いる必要があり、再利用する場合においても、これらを１組として用いる必要があることを示すものである。この依存は相互に持つ。次にレベル２である。このレベル２は、片方向からの依存性を示すものである。親側と子側に分け、親側のＩ／Ｆは、単独で用いることが可能であるが、子側のＩ／Ｆアイテムは、常に親側と共に用いる必要があることを示している。レベル３は、より緩やかな依存関係のレベルを示す。目的に応じては、共に利用することが多いが、必須ではない場合を示す。また、これらのデフォルトで用意された依存関係種別情報のほかに、ユーザ定義の依存関係種別情報の登録も可能である。
このように登録管理された種別情報は、識別子を用いて利用される。識別子は、Ｉ／Ｆ定義情報３９で管理され、それぞれのＩ／Ｆアイテムへの属性情報として付加される。
【００２３】
次に、参照関係について説明する。
（３）の参照関係は、Ｉ／Ｆアイテムの内で一部を利用して再定義されている場合に付けられる関係である。１つのＩ／Ｆアイテムを新たに定義する際に、既存のＩ／Ｆアイテムの定義を用いて再定義する場合である。この再定義されたアイテムは、再定義元のアイテムとは別のアイテムであるが、再定義される元となったアイテムの性質をそのまま再利用する。また、元となったアイテムが更新された場合、更新結果は参照先まで伝播させる。（（１）の履歴関係も参照関係の１つの種類としてみることができるが、履歴関係は、参照先が変更された場合には影響波及がなされないのが特徴である。）これらの参照元のＩ／Ｆ定義アイテムの識別子を、参照先のＩ／Ｆ定義アイテムに対して、参照元情報として属性として付加させる。この属性情報は（１）の場合と同様にＩ／Ｆの定義内はＸＭＬで階層的にタグ管理されているので、参照関係を示すタグ位置に、対象となるＩ／Ｆの識別子の値を格納することにより、この情報を格納する。
【００２４】
（４）の包含関係は、Ｉ／Ｆ間において、Ｉ／Ｆそのものを包含して別途Ｉ／Ｆ定義がなされている場合の関係を表現する場合に定義するものである。参照関係とは異なり、新たに定義される際に用いられる既存のアイテムは、そのまま取り込むことになる。新たな再定義は行われないことを特徴として持つ。この情報も、先に述べた参照関係と同様に、包含関係を示すタグ位置に対象となるＩ／Ｆの識別子の値を格納することにより、この情報を格納する。
以上の関係をＩ／Ｆ間の関係として属性情報として与える。
【００２５】
以上のように管理されるＩ／Ｆ定義やＩ／Ｆアイテム定義の個々の情報は、それぞれのＩ／Ｆをノードとし、上記の属性情報に対応する関係をノード間のリンクとした形でのネットワーク状の情報群を形成する。
これらのネットワーク状に形成される情報群を辿り、各アイテム上に管理される情報を集約し、後に説明する検証情報や変換情報を生成する。Ｉ／Ｆ定義情報管理部３３においては、このようなＩ／Ｆ定義アイテム及びＩ／Ｆ定義間の連係として、Ｉ／Ｆ全体の情報を管理する。新たなＩ／Ｆ定義の追加や変更は、必要な属性値を与えたアイテムを付け加えるだけでよく、利用する場合は、全てこれらのノード間の連係を辿ることにより連係を保つことが可能となる。
【００２６】
以下に、実際にこれらの情報を用いて、ＦＡ機器０９とアプリケーション０１との間を取り持つＩ／ＦのためのＩ／Ｆ定義及びＩ／Ｆ間のデータ変換を行うための変換ルールを生成する過程について説明する。
図１のＩ／Ｆ０４、０５は、同一のＩ／Ｆを用いており、Ｉ／Ｆ定義１４、１５は、同じ内容のＩ／Ｆ定義である。ここで、Ｉ／Ｆ０４とアプリケーション０１との間、及びＩ／Ｆ０５とＦＡ機器０９との間をそれぞれ取り持つ、Ｉ／Ｆおよびデータ変換装置のためのＩ／Ｆ定義及び変換ルールの生成手順を考える。具体的には、Ｉ／Ｆ定義は、Ｉ／Ｆ定義１７、１２であり、また、変換ルールは、変換ルール１８、１６、１３であり、これらを生成対象とする。
ここで、データ変換ルール及びデータ変換装置は、その性質から２つに分けられる。１つは、ＦＡ機器０９から直接変換を行い、Ｉ／Ｆを上位のミドルウェアに提供する部分であり、他方は、それ以外のＩ／Ｆ間の変換を行う部分である。前者は、図１において、Ｉ／Ｆ０７に対応するＩ／Ｆ定義１７、およびデータ変換装置０８に対応する変換ルール１８の部分であり、後者は、同様に図１において、データ変換装置０６に対応する変換ルール１６、同じくＩ／Ｆ０５に対応するＩ／Ｆ定義１５（Ｉ／Ｆ０４に対応するＩ／Ｆ定義１４）、データ変換装置０３に対応する変換ルール１３、Ｉ／Ｆ０２に対応するＩ／Ｆ定義１２である。
ここで、説明の便宜上、２つに分けた先のＩ／Ｆ０７を、バイナリ構造に直接対応したＩ／Ｆ０７と称することにし、それ以外を、バイナリ構造に依存しない機種依存のＩ／Ｆと称することにする。
【００２７】
まず、ここで、バイナリ構造に直接対応したＩ／Ｆを理解するために、ＦＡ機器０９の機器内で取り扱うデータについて説明する。
数多くのＦＡ機器０９内では、取り扱うデータは、メモリ上に保存される。また、いくつかのＦＡ機器０９は、データアクセスのためのミドルウェアが、それぞれの機器毎に用意されており、このミドルウェアを介してソフトウェアは、データにアクセスを行う。しかし、実際には、全ての、個々のデータに対してミドルウェアが用意されていることは、まれであり、特に各ＦＡ機器０９におけるパラメータデータの操作に関しては、その多くがメモリ上に配置されているデータに直接アクセスするように指定されている。
これは、ＦＡ機器０９が多用な機種やバージョン毎に異なるパラメータを取り扱わなければならず、その大量なパラメータの種類に応じたミドルウェアを用意することは、多大なプログラムコストが掛かるため、行われてこなかったという理由によるものである。
【００２８】
しかし、一方でミドルウェアを利用して、プログラムを作成する側から見ると、不都合なことも多い。例えば、多用な機種やバージョンごとに異なるパラメータの取り扱い方法を、ミドルウェアのメモリ配置に係わる仕様書を見ながら、アクセス用のプログラムを作成しなければならないなど、固有のプログラムを作成しなければならないという問題があった。この際に用いる、バイナリ構造に依存したデータ構造を取り決めるための情報は、ＦＡ機器０９を利用するソフトウェア側からみると、本来必要としない情報である。たまたま、メモリ上に配置されているデータをアクセスするために便宜上必要となった情報である。
従って、これらの情報は、２次的に必要とする情報として、切り分けて管理する必要がある。図１における、バイナリ構造に依存しないＩ／Ｆ０７は、ソフトウェア側から見て、よりＦＡ機器０９の操作上、本来必要とする情報の意味的な関係に従って整理したデータ構造及び、データ構造に対応したＩ／Ｆとし、２次的に必要とする情報については、変換ルールとしてユーザから隠蔽することが望ましい。
【００２９】
この２次的な情報は、以下の性質を持っている。
バイナリ上のデータの配置は、典型的な配置においては、ヘッダとボディに分割されている。ボディの部分には、データの内容など、ヘッダ部分で修飾された対象となる情報が記載される。ヘッダの部分には、ボディの部分に記載された情報を説明するための情報が記載される。
ここで、ヘッダ内に記載される情報には、以下の内容を含めることができる。
（ａ）情報を識別するために用いる番号などの識別子や名称
（ｂ）情報が記載されているメモリ上の範囲、大きさ
（ｃ）記載される情報の種別（データなのか、複合した情報なのかなど）
（ｄ）他のヘッダで記載されている情報との関係、前後関係
（ｅ）データを利用するためのライブラリや関数の利用情報
ボディとヘッダを組み合わせた塊を、仮にここでブロックと称することにする。このブロックは、再帰的にボディ内に配置することも可能であり、全体を入れ子状に構成することができる。一般に、このボディ内に配置されるブロックは、その種別に応じて実装形態が異なる。例えば、メモリ上のワードの配列や、ワード内のビット列などの実装形態があげられる。これらの異なる実装形態に対応する配置情報は、従来、構造を説明する仕様書の形で提供されていた。その仕様書上の説明は、上記のワード列やビット列を直接図示したもので通常行われる。
以上、バイナリ構造に直接対応したＩ／Ｆを理解するために、ＦＡ機器０９の機器内で取り扱われるデータについて説明した。
【００３０】
以上、説明した配置情報は、実施の形態１においては、具体的な種別からは切り離した形で、統一した形で再帰的に表現される。すなわち、図７に示すように種別に拠らないブロック状の構造を再帰的に呼び出す形式とした。これにより、様々な構造に対応可能な表記法とすることができる。
【００３１】
次に、変換情報管理部３８について説明する。
変換情報管理部３８は、変換情報４４、変換種別情報および変換用モジュールライブラリを保持、管理している。変換情報４４は、Ｉ／Ｆアイテム間の変換情報を管理する。このＩ／Ｆアイテム間の変換情報には、以下の項目が含まれる。
（１）アイテム間の対応情報（変換元と変換先のＩ／Ｆ定義アイテムの識別子）
（２）変換の種別（変換ライブラリ内のライブラリ識別子）
この（１）アイテム間の対応情報は、変換を行う対象となるＩ／Ｆアイテムの対応関係を記載した情報である。（Ｉ／Ｆは複数のＩ／Ｆアイテムから構成され、Ｉ／Ｆアイテムは一意に識別するための識別情報が付加される点については先に述べたとおり。）（１）アイテム間の対応情報は、この識別情報の対応関係を記載するものであり、この対応関係に従い、データ変換装置は、Ｉ／Ｆ間のデータ交換を行うアイテムの特定を行う。また、このＩ／Ｆアイテム間の変換情報そのものも、変換情報管理部３８内で一意に、各アイテムを特定することのできる識別子により管理されており、この識別子を用いて、他の情報内から必要に応じて、特定の情報を取り出す。
【００３２】
また、変換の種別情報は、データ交換を行う際に、実際にどのようなデータの加工を行うのかを指定するための情報である。単なる置き換えの場合は、そのまま、対応するアイテム内のデータをコピーすることになり、複数のアイテムから、単一のアイテムへの対応関係においては、データの合成を行い、また、単一のアイテムから複数のアイテムへの対応関係においては、データの分割を行う。これらの合成や分割は、その具体的な内容に応じた種別の指定が行われる。
分割や合成機能は、変換情報管理部３８の変換用モジュールライブラリから呼び出される。変換用モジュールライブラリ内には、個々の変換の種別に対応した変換用モジュールが保持され、必要に応じて呼び出すことができる。この変換用モジュールライブラリは、同じ内容のものが、プロファイル情報維持管理装置２１、４５にも存在し、変換プロファイル生成部２５、４９において変換ルールを生成する際に、変換ルール内の変換の種別に応じた変換用のモジュールを、データの変換を実現するデータ変換装置０３、０６、０８に格納するようにする。
【００３３】
このように、データ変換装置０３、０６、０８は、変換の種別に従い、変換情報管理部３８から対応する変換用のモジュールを、プロファイル情報維持管理装置２１、４５を経由して、得ることができる。
指定された領域のデータを取り込み、変換結果を対応するＩ／Ｆの領域に書き戻し、データ交換の際のデータ変換を実施する。この変換用モジュールの実現においては、ＤＬＬ（Ｄｙｎａｍｉｃ  Ｌｉｎｋ  Ｌｉｂｒａｒｙ）等を用い、指定された種別に応じて呼び出すことにより実現することも可能である。
【００３４】
次に、機器情報管理部３４およびアプリケーション情報管理部３５について説明する。
機器情報管理部３４及びアプリケーション情報管理部３５は、それぞれ、機器情報４０、アプリケーション情報４１を持ち、その中でＦＡ機器０９とアプリケーション０１に係わる情報を管理している。
機器情報４０では、ＦＡ機器０９の名称、用途、型、メーカ名等の情報を管理し、同様にアプリケーション情報４１では、アプリケーション０１の名称、用途、型、適用範囲、バージョン情報などを管理する。これらの情報は、他の情報の管理方法と同様に、個別の情報を特定できるように識別子を添付した形でテーブル上に管理される。他の情報からは、この識別子を通して、リンクされ、必要に応じて取り出される。Ｉ／Ｆ定義情報管理部３３で管理されているＩ／Ｆ定義情報３９の各アイテムは、これらの機器情報４０をリンク情報として保持し、検索時に利用する。
【００３５】
次に、検証情報管理部３７について説明する。
検証情報管理部３７は、検証情報４３、検証種別情報及び検証用モジュールライブラリを保持管理している。この形態は、変換情報管理部３８と類似した形で実装される。
検証情報４３には、Ｉ／Ｆアイテム定義における検証に係わる情報を管理し、以下の項目を含む。
（１）検証に係わるＩ／Ｆアイテム定義の情報（検証に係わるＩ／Ｆ定義アイテムの識別子）
（２）検証の種別（検証ライブラリ内のライブラリ識別子）
（１）検証に係わるＩ／Ｆアイテム定義の情報は、検証を行う対象となるＩ／Ｆ定義アイテムの関係を記載した情報である。検証の種別は、検証を行う際に、検証用のライブラリモジュールを呼び出すためのリンク情報である。
【００３６】
次に、検索機能２８について説明する。検索機能２８は、各情報管理部から、指定した条件に一致したアイテムを検索、獲得するための機能である。各情報管理部内のアイテムは、一意に特定するための識別子が添付されている。Ｉ／Ｆ定義情報管理部３３におけるＩ／Ｆ定義情報３９内のＩ／Ｆアイテム定義情報には、関連する検証情報４３や機器情報４０、アプリケーション情報４１などの識別子が属性値として添付される。検索機能２８で指定された用語やアイテムから、まず、その検索用語を含んだ情報管理部のアイテムを特定し、さらに、この情報アイテムの識別子を含んだ、Ｉ／Ｆ定義情報管理部３３内のＩ／Ｆアイテム定義情報を獲得する。
【００３７】
次に、ＦＡ機器０９に対応したＩ／Ｆ定義を、Ｉ／Ｆ定義情報管理部３３に新規に生成し、登録する過程を説明する。この過程を図２に示す。
まず、実現方法の指定（ステップＳ０１）を行う。ここで既存機器の情報を利用するか否かを指定し、その結果に従い、手順を選択する（ステップＳ０２）。既存機器の情報利用を選択した場合、次に既存機器の検索（ステップＳ０３）を行う。ここでは、既存機器の検索からカスタマイズ生成をおこなう。新規に登録しようとする機器の属性を用い、既存の機器から近いものを検索する。検索の際に用いる属性は、機器の種別、機種、用途、メーカ等があげられる。
次に、検索した既存機器からＩ／Ｆを得る（ステップＳ０４）。次に、対応するメモリ構造と比較を行う（ステップＳ０５）。この際、近い機種の場合、メモリ構造においても再利用可能な部分は、大きい場合が多いので、まず、基本構造の確認と比較を行う。基本構造とは、メモリ上のブロックの切り分け方法やヘッダ領域等の共通領域の範囲などが相当する。ステップＳ０６で、基本構造が、同一の構造である場合は、その部分については、そのまま再利用することになる。基本構造が同じ場合、既存メモリ構造へのマッピングと考えることが可能である。比較した内容と仕様情報を用いてマッピングの調整、変更を行う（ステップＳ０７）。ここでは、アイテムの対応関係付けと、項目の追加削除を行い、登録（ステップＳ０８）を行う。
ステップＳ０６で、ＮＯの場合、メモリマップの基本構造を新たに指定し、各データ構造及び名称、その他属性の指定を行った後、登録（ステップＳ０８）する。
【００３８】
次に、バイナリ構造非依存機種依存Ｉ／Ｆ０５の生成手順を、図３により説明する。なお、バイナリ構造依存機種依存構造という場合、この中での構造は、データ構造を意味する。機種依存構造とは、機種の違い毎に異なるデータ構造であることを示す。同じくバイナリ構造依存構造とは、バイナリ構造によるデータ構造であることを指し示す。ここで、機種とは、例えばシーケンサを対象にした場合、同じメーカ、もしくは異なるメーカが提供する製品種別や型、製品群のシリーズなどをさす。バイナリ構造とはバイナリデータのメモリ上の配置情報に関わるデータ構造を指す。バイナリ構造非依存とは、バイナリ構造によらないデータ構造であることを示す。
【００３９】
図３において、まず、実現方法の選択を行う（ステップＳ１３）。ここでは、既存機器をベースにカスタマイズするのか否かを指定する。既存機器の情報を利用する場合は、次に既存機器の選択を行う（ステップＳ１５）。既存機器のＩ／Ｆからカスタマイズ生成することになる。検索した既存機器からＩ／Ｆを得る（ステップＳ１６）。次に、得たＩ／Ｆアイテムをベースに編集するか否かを選択する（ステップＳ１７）。機器の既存Ｉ／Ｆアイテムをベースに編集をする場合、Ｉ／Ｆの履歴関係が成立するため、既存アイテムをベースに作成した旨をリンク情報として登録する（ステップＳ１８）。
次に、バイナリ構造依存機種依存Ｉ／Ｆ定義内Ｉ／Ｆアイテム属性の利用の有無を選択する。つまり、下位のＩ／Ｆアイテムの属性を利用するか否かの選択である。利用する場合、下位の対応する属性の獲得を行い、登録を行う（ステップＳ２０）。もし領域全て編集済みであった場合は、登録される（ステップＳ２２）が、領域にまだ未編集の部分がある場合は、ステップＳ１７から再度実施する。
また、ステップＳ１９において、ＮＯであった場合、独自に属性の編集と登録を行う。その後、変換対象であるバイナリ構造依存機種依存Ｉ／Ｆ上の対応アイテムを指定する。この際、変換の種別も合わせて指定する。一方、ステップＳ１７で、ＮＯであった場合、既存Ｉ／Ｆのアイテム利用について選択する。これは、先に検索した既存機器以外のＩ／Ｆアイテムをベースに編集をするか否かを問うものであり、利用する場合は、Ｉ／Ｆアイテムを個別に検索を行い、検索したＩ／Ｆアイテムをベースにした旨をリンク情報として登録した後、登録時に変更した属性と変更せずにそのまま利用した属性の定義情報に、その旨を定義情報の属性として登録し、変更分は編集する。また、ステップＳ２７でＮＯの場合、新規Ｉ／Ｆアイテムとして編集をする場合となり、新規アイテムとしての属性情報を定義情報の属性として登録する。
一方、ステップＳ１４で、ＮＯの場合、新規Ｉ／Ｆアイテムの生成となり、Ｉ／Ｆアイテムの追加（ステップＳ２３）、生成したＩ／Ｆアイテムの編集（ステップＳ２４）を経て、登録（ステップＳ２２）を行う。編集の際には、各アイテムの属性を指定する。この属性としては、名称（表示名称）、初期値、種別、制限、利用（機器に関連する情報もしくは機器に関連する情報へのリンク情報）などが上げられる。
【００４０】
次に、バイナリ構造非依存機種依存Ｉ／Ｆ０５及びバイナリ構造依存機種依存Ｉ／Ｆ０７間の変換データの生成の手順について、図４に基づき説明する。
まず、Ｉ／Ｆ編集の確認を行う（ステップＳ３２）。Ｉ／Ｆが既に定義されているのかを確認する。ステップＳ３２で、Ｉ／Ｆ編集が確認されなかった場合は、Ｉ／Ｆの編集（ステップＳ３９）を行う。これについては、図３及び図２が該当する。
次に、Ｉ／Ｆ間の対応関係の確認を行う（ステップＳ３３）。ＮＯの場合、未対応であるＩ／Ｆアイテムの編集や関連アイテムの検索を行う（ステップＳ４０）。次に、変換の種別を指定する（ステップＳ４１）。このような過程を経て、Ｉ／Ｆ間の対応関係を取った後、Ｉ／Ｆ間のリンク情報の抽出を行う（ステップＳ３４）。ここでのリンク情報とは、Ｉ／Ｆアイテム間の連係情報であり、動作連係情報管理部３６で管理される連係情報である。
これらの情報を用い、対応関係の生成（ステップＳ３５）や登録（ステップＳ３６）を行った後に、ＸＭＬ形式の対応関係一覧として、変換データの出力を行い（ステップＳ３７）、登録を行う（ステップＳ３８）。
【００４１】
次に、アプリケーション側から見た変換ルールとＩ／Ｆの生成について説明する。
新たなＳ／Ｗを追加する場合、Ｓ／Ｗに直接対応したＩ／Ｆを生成する必要がある。既存のＳ／Ｗで利用されているものを再利用もしくは、既存の分割されたＩ／Ｆをキーワードや機能から収集し、組み合わせることとなる。
【００４２】
Ｉ／Ｆの生成手順を図５に基づき説明する。
まず、実現方法の選択を行う（ステップＳ４２）。ここでは、既存Ｓ／Ｗをベースにカスタマイズするのか否かを指定する。既存Ｓ／Ｗの情報を利用する場合は、次に既存Ｓ／Ｗの選択を行う（ステップＳ４４）。既存Ｓ／ＷのＩ／Ｆからカスタマイズ生成することになる。検索した既存Ｓ／ＷからＩ／Ｆを得る（ステップＳ４５）。次に、得たＩ／Ｆアイテムをベースに編集するか否かを選択する（ステップＳ４６）。Ｓ／Ｗの既存Ｉ／Ｆアイテムをベースに編集をする場合、Ｉ／Ｆの履歴関係が成立するため、既存アイテムをベースに作成した旨をリンク情報として登録する（ステップＳ４７）。
【００４３】
次に、Ｉ／Ｆ定義内Ｉ／Ｆアイテム属性の利用の有無を選択する。つまり、下位のＩ／Ｆアイテムの属性を利用するか否かの選択である。利用する場合、下位の対応する属性の獲得を行い、登録を行う（ステップＳ４９）。もし領域全て編集済みであった場合は、登録される（ステップＳ５０）が、領域にまだ未編集の部分がある場合は、ステップＳ４６から再度実施する。また、ステップＳ４８において、ＮＯであった場合、独自に属性の編集と登録を行う。その後、変換対象であるＩ／Ｆ上の対応アイテムを指定する。この際、変換の種別も合わせて指定する。一方、ステップＳ４６で、ＮＯであった場合、既存Ｉ／Ｆのアイテム利用について選択する。これは、先に検索した既存Ｓ／Ｗ以外のＩ／Ｆアイテムをベースに編集をするか否かを問うものであり、利用する場合は「Ｉ／Ｆアイテム」を個別に検索を行い、検索した「Ｉ／Ｆアイテム」をベースにした旨をリンク情報として登録した後、登録時に変更した属性と変更せずにそのまま利用した属性の定義情報にその旨を定義情報の属性として登録し、変更分は編集する。
【００４４】
また、ステップＳ５６で、ＮＯの場合、新規Ｉ／Ｆアイテムとして編集をする場合となり、新規アイテムとしての属性情報を定義情報の属性として登録する。一方、ステップＳ４３の段階で、ＮＯの場合、新規Ｉ／Ｆアイテムの生成となり、Ｉ／Ｆアイテムの追加（ステップＳ５２）、生成したＩ／Ｆアイテムの編集（ステップＳ５３）を経て、登録（ステップＳ５４）を行う。編集の際には各アイテムの属性を指定する。属性としては、名称（表示名称）、初期値、種別、制限、利用（Ｓ／Ｗに関連する情報もしくはＳ／Ｗに関連する情報へのリンク情報）などが上げられる。
また、Ｉ／Ｆ０２及びＩ／Ｆ０３間の変換データの生成の手順については、バイナリ構造非依存機種依存Ｉ／Ｆ０５及びバイナリ構造依存機種依存Ｉ／Ｆ０７間の変換データの生成手順と同じ手順を用いる。
【００４５】
次に、検証用ルールについて説明する。
検証用ルールは、検証情報管理部３７で管理される情報で、アプリケーション側からみると、アプリケーションで想定しているデータ間の制限や条件を記載したものである。また、同様にＦＡ機器側で想定しているデータ間の制限や条件を記載したものも、上記の条件と同様にＩ／Ｆ側に要求する条件として添付する。
リンク情報を辿って上記の制約を集約する。次に、これらの制約を１つの制限及び条件のセットとしてまとめる。まとめられた条件のセットは、各アイテムの制限情報として取扱われる。これにより、これらの制約に係わる情報を、ソフトウェアとＦＡ機器側に互いに交換させることが可能となる。これらの交換した条件に従って、ソフトウェア側のデータ入出力条件チェック処理を行うことが可能となる。
【００４６】
実施の形態１によれば、ＦＡ機器とアプリケーション間のＩ／Ｆの生成及びＩ／Ｆ間の変換ルールの生成や、ＦＡ機器の機種変更や機能更新の際の変換ルールやＩ／Ｆの維持管理を容易にすることができる。
【図面の簡単な説明】
【００４７】
【図１】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置を示す構成図である。
【図２】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＩ／Ｆ定義を生成する手順を示すフローチャートである。
【図３】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のバイナリ構造非依存機種依存Ｉ／Ｆを生成する手順を示すフローチャートである。
【図４】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のバイナリ構造非依存機種依存Ｉ／Ｆ及びバイナリ構造依存機種依存Ｉ／Ｆ間の変換データを生成する手順を示すフローチャートである。
【図５】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のアプリケーション側からみたＩ／Ｆを生成する手順を示すフローチャートである。
【図６】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＩ／Ｆ定義を示す図である。
【図７】この発明の実施の形態１によるＦＡ機器Ｉ／Ｆ統合化装置のＦＡ機器のデータ構造を示す図である。
【符号の説明】
【００４８】
０１  アプリケーション
０２，０４，０５，０７  Ｉ／Ｆ
０３，０６，０８  データ変換装置
０９  ＦＡ機器
１２，１４，１５，１７  Ｉ／Ｆ定義
１３，１６，１８  変換ルール
２１，４５  プロファイル情報維持管理装置
２２，４６  入力（編集）部）
２３，４７  表示部
２４，４８  Ｉ／Ｆ検証部
２５，４９  変換プロファイル生成部
２６，５０  Ｉ／Ｆ定義生成部
２７  共用情報管理装置
２８  検索機能
２９  検証機能
３０  入力部
３１  表示部
３２  データ操作部
３３  Ｉ／Ｆ定義情報管理部
３４  機器情報管理部
３５  アプリケーション情報管理部
３６  動作連係情報管理部
３７  検証情報管理部
３８  変換情報管理部
３９  Ｉ／Ｆ定義情報
４０  機器情報
４１  アプリケーション情報
４２  動作連係情報
４３  検証情報
４４  変換情報
【図１】
2005251120.tif 000003
【図２】
2005251120.tif 000004
【図３】
2005251120.tif 000005
【図４】
2005251120.tif 000006
【図５】
2005251120.tif 000007
【図６】
2005251120.tif 000008
【図７】
2005251120.tif 000009