(57)【特許請求の範囲】
【請求項１】
所定の処理を行う設備機械に、管理装置からの指示に基づいて前記設備機械を制御するデバイスが設けられた設備装置と、前記設備装置を管理する管理アプリケーションプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーションプログラムからの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、
前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、
前記製造システムに設けられる前記設備機械の種類ごとに設けられ、前記管理アプリケーションプログラムからの指示にしたがって、前記デバイスドライバを使用して対象となる前記設備機械にアクセスする装置ドライバと、
が階層化されて構成され、
前記デバイスドライバと前記装置ドライバは、それぞれのドライバに対応する前記デバイスと前記設備機械の有する機能ごとに、所定のパラメータと属性とオペレーションを有する様に作成した機能オブジェクトによって作成され、
前記デバイスドライバまたは前記装置ドライバの有する機能の内容を、前記機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々の前記デバイスドライバまたは前記装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがって、前記機能の内容または前記設定値がマークアップ言語で記述され、
前記デバイスドライバまたは前記装置ドライバの前記機能オブジェクトの通信インタフェースは、インタフェース記述言語で内容が記述されたものであって、
前記デバイスドライバまたは前記装置ドライバは、前記通信インタフェースの前記記述内容をインタフェース記述言語の記述モデルに基づいて分類したクラス情報と前記データモデルのクラス情報とをマッピングし、このマッピング結果と前記データモデルから得られる前記機能オブジェクトに対応するインスタンスを含むコンフィグレーション情報を参照して、通信されるデータの処理を行う
ことを特徴とする通信ドライバ。
【請求項２】
所定の処理を行う複数の設備装置と、前記設備装置を管理する管理アプリケーションプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーションプログラムからの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、
前記管理アプリケーションプログラムに、前記複数の設備装置を１つの仮想的な装置として見せる仮想装置ドライバと、
前記設備装置ごとに設けられ、前記設備装置との間の通信を司るとともに、前記仮想装置ドライバからの指示にしたがって、対象となる前記設備装置にアクセスする実装置ドライバと、
が階層化されて構成され、
前記実装置ドライバは、対応する前記設備装置の有する機能ごとに、所定のパラメータと属性とオペレーションを有する様に作成した機能オブジェクトによって作成され、
前記仮想装置ドライバは、前記製造システムに設けられる前記設備装置の有する機能を抽象化した機能ごとに、所定のパラメータと属性を有する様に作成した機能オブジェクトによって作成され、
前記仮想装置ドライバまたは前記実装置ドライバの有する機能の内容を、前記機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々の前記仮想装置ドライバまたは前記実装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがって、前記機能の内容または前記設定値がマークアップ言語で記述され、
前記仮想装置ドライバまたは前記実装置ドライバの前記機能オブジェクトの通信インタフェースは、インタフェース記述言語で内容が記述されたものであって、
前記仮想装置ドライバまたは前記実装置ドライバは、前記通信インタフェースの前記記述内容をインタフェース記述言語の記述モデルに基づいて分類したクラス情報と前記データモデルのクラス情報とをマッピングし、このマッピング結果と前記データモデルから得られる前記機能オブジェクトに対応するインスタンスを含むコンフィグレーション情報を参照して、通信されるデータの処理を行う
ことを特徴とする通信ドライバ。
【請求項３】
前記仮想装置ドライバは、前記設備装置の仕様に基づいて前記設備装置で実行される処理を、前記製造システムの工程設計情報に基づいて前記製造システムで実行される工程に関連付けて管理することを特徴とする請求項２に記載の通信ドライバ。
【請求項４】
前記設備装置は、所定の処理を行う設備機械と、前記管理装置からの指示に基づいて前記設備機械を制御するデバイスとから構成され、
前記実装置ドライバは、
前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、
前記製造システムに設けられる前記設備機械の種類ごとに設けられ、前記管理アプリケーションプログラムからの指示にしたがって、前記デバイスドライバを使用して対象となる前記設備機械にアクセスする装置ドライバと、
を備え、
前記デバイスドライバと前記装置ドライバまたは前記実装置ドライバの有する機能の内容を、前記機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々の前記デバイスドライバまたは前記装置ドライバまたは前記実装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがって、前記機能の内容または前記設定値がマークアップ言語で記述されることを特徴とする請求項３に記載の通信ドライバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、たとえば製造工場における搬送設備機械や製造設備機械、検査設備機械などのそれぞれの設備機械とこの設備機械を制御するデバイスを備えた設備装置と、これらの設備装置を管理する管理装置とがネットワークを介して接続された製造システムにおいて、上記設備装置と上記管理装置との間で通信されるデータの変換を行う通信ドライバに関するものである。
【背景技術】
【０００２】
従来、生産設備として実際にワークの加工、洗浄、運搬などに携わる各種の工作機械や段取装置、洗浄装置、作業指示装置、搬送装置などの制御対象設備と、これらの制御対象設備の運用のための加工日程計画や加工順序情報、使用予定治具情報などの基本情報を処理して運転スケジュールを作成しながらこれらの制御対象設備を統括的に運転制御する制御装置とが、ネットワークで接続された構成を有するフレキシブル生産システムが提案され、普及してきている。このようなフレキシブル生産システムの一例として、上記制御装置を上記制御対象設備の機能要素ごとに分割して複数配置して、機能要素ごとに制御対象設備の運転制御を行うようにすると共に、制御対象設備の運転制御に用いられる制御情報伝送用の通信回線と、フレキシブル生産システムの運用管理に用いられる運用情報伝送用の通信回線とを別々に設けて、システム全体としての情報の流れを円滑にそして高効率に行うシステムがある（たとえば、特許文献１参照）。
【０００３】
【特許文献１】特許第２５７７６００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記特許文献１に記載されるようなフレキシブル生産システムでは、制御対象設備や制御装置は異なるベンダのものを組み合わせて構築される場合が多く存在する。このような場合、ベンダごとに制御対象設備に設定されるパラメータの意味や制御対象設備や制御装置で使用されるデータフォーマットが異なるために、制御装置には、該制御装置が運転制御を行う制御対象設備ごとにデータアクセスプログラムが必要となるという問題点があった。さらに、このデータアクセスプログラムを開発するための作業は、制御対象設備ごとに行う必要があるために、データアクセスプログラムの作業者に大きな負荷が掛ってしまうという問題点もあった。
【０００５】
この発明は、上記に鑑みてなされたもので、製造に関与する設備装置と該設備装置を管理制御する管理装置とがネットワークを介して構成される製造システムにおいて、設備装置と管理装置で使用されるデータフォーマットが異なる場合や、設備装置に設定されるパラメータの意味がベンダごとに異なる場合でも、設備装置と管理装置との間で通信できるようにデータ変換を行う通信ドライバを得ることを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、この発明にかかる通信ドライバは、所定の処理を行う設備機械に、管理装置からの指示に基づいて前記設備機械を制御するデバイスが設けられた設備装置と、前記設備装置を管理する管理アプリケーションプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーションプログラムからの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、前記製造システムに設けられる前記設備機械の種類ごとに設けられ、前記管理アプリケーションプログラムからの指示にしたがって、前記デバイスドライバを使用して対象となる前記設備機械にアクセスする装置ドライバと、が階層化されて構成され、前記デバイスドライバと前記装置ドライバは、それぞれのドライバに対応する前記デバイスと前記設備機械の有する機能ごとに、所定のパラメータと属性とオペレーションを有する様に作成した機能オブジェクトによって作成され、前記デバイスドライバまたは前記装置ドライバの有する機能の内容を、前記機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々の前記デバイスドライバまたは前記装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがって、前記機能の内容または前記設定値がマークアップ言語で記述され、前記デバイスドライバまたは前記装置ドライバの前記機能オブジェクトの通信インタフェースは、インタフェース記述言語で内容が記述されたものであって、前記デバイスドライバまたは前記装置ドライバは、前記通信インタフェースの前記記述内容をインタフェース記述言語の記述モデルに基づいて分類したクラス情報と前記データモデルのクラス情報とをマッピングし、このマッピング結果と前記データモデルから得られる前記機能オブジェクトに対応するインスタンスを含むコンフィグレーション情報を参照して、通信されるデータの処理を行うことを特徴とする。
【発明の効果】
【０００７】
この発明によれば、ドライバを、デバイスとの通信を制御するデバイスドライバと、装置を制御する装置ドライバに階層化して構成することにより、デバイスのデバイスドライバはデバイスメーカが、設備機械の装置ドライバは設備機械メーカが別々に提供することができるという効果を有する。また、デバイスドライバと装置ドライバの有する機能の内容を、機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々のデバイスドライバまたは装置ドライバについての設定値をクラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがって、機能の内容または設定値をマークアップ言語で記述するようにしたので、抽象的なまたは共通的な内容の処理を個々の設備装置の具体的な内容の処理に変換することが可能となるとともに、ＸＭＬデータモデルを使用することによって、ドライバにおけるデータ変換機能の作成を支援または自動化することができるという効果も有する。
【発明を実施するための最良の形態】
【０００８】
以下に添付図面を参照して、この発明にかかる通信ドライバの好適な実施の形態を詳細に説明する。
【０００９】
実施の形態１．
図１は、この発明が適用される製造システムの一例を模式的に示す図である。製造システム１は、該製造システム１においてある製品の製造に関与する所定の動作を実行する設備装置２と、これらの設備装置２の管理などを行う製造管理システム（Manufacturing  Execution  System,  ＭＥＳ）３と、設備装置２や製造管理システム３の仕様書や設計書などの設計情報を格納する設計情報格納装置４と、設備装置２と製造管理システム３との間でやり取りされるデータの変換を行うデータ変換装置５と、が、データ伝送を行うネットワーク６を介して相互に接続される構成を有している。
【００１０】
設備装置２は、製造における所定の処理を実際に行う設備機械２１と、この設備機械２１を所定のプログラムとパラメータにしたがって動作させると共に製造管理システム３との間で通信を行うデバイス２２と、を備える。なお、デバイス２２には、設備機械２１を制御するコントローラのほかに、センサやアクチュエータなども含まれる。設備装置２として、たとえばある製品を製造するための部品の搬送を行う搬送装置や、搬送された部品を用いて製品を製造する製造装置、製造された装置の検査を行う検査装置などが該当する。
【００１１】
製造管理システム３は、製造実績管理、設備保守保全、作業者管理、プロセス管理、品質管理、製造指示、データ収集、物流制御などの製造管理アプリケーションプログラムを実行し、ネットワーク６を介して各設備装置２との間で通信を行い、データ収集やレシピなどのデータ転送、パラメータ設定などの実行指示を行う装置である。このような製造管理システム３は、製造管理アプリケーションプログラムを格納する記憶手段と、製造管理アプリケーションプログラムにしたがって処理を実行する処理実行手段と、ネットワーク６とのインタフェースとなる通信手段と、を備えるワークステーションやパーソナルコンピュータなどの情報処理端末によって構成される。
【００１２】
設計情報格納装置４は、各設備装置２と各製造管理システム３に関する設計情報を格納する装置であり、データ変換装置５から指示される設計情報を提供する。この設計情報として、設備装置２についての設計書である装置設計書、製造管理システム３の設計書である製造管理システム設計書、設備装置２に設けられるデバイス２２の仕様書であるデバイス仕様書、製造管理システム３に設定されるプログラムの仕様書である設備接続仕様書などを例示することができる。
【００１３】
データ変換装置５は、設備装置２と製造管理システム３との間で通信されるデータについて、プロトコルの違いや、ベンダや機種などの違いによるユーザデータ定義の違いなどを、設計情報格納装置４に格納される設計情報に基づいて吸収し、データ受信側の機器（設備装置２または製造管理システム３）で読込むことが可能な形式のデータフォーマットに変換する機能を有する。
【００１４】
図２は、データ変換装置のドライバの実施の形態１の構成を模式的に示す図である。この図では、データ変換装置５は、１つの製造管理システム３に実装される製造管理アプリケーションプログラム３１と、異なる種類の４つの設備装置２Ａ〜２Ｄに接続される場合が示されている。また、設備装置２Ｂには２つのデバイス２２ａ，２２ｂが備えられ、設備装置２Ｃ，２Ｄには同一のデバイス２２ｃが備えられている。図２に示されるように、このデータ変換装置５は、設備装置２Ａ〜２Ｄのデバイス２２ａ〜２２ｃとの通信を司るデバイスドライバ５１ａ〜５１ｃと、デバイスドライバ５１ａ〜５１ｃを使用して設備装置２Ａ〜２Ｄのデータを製造管理システム３の製造管理アプリケーションプログラム３１に提供する装置ドライバ５２Ａ〜５２Ｄとが、階層化されて構成される。
【００１５】
ここで、データ変換装置５に設けられる階層化されたドライバを作成する一般的なモデルについて説明する。図３は、この実施の形態１でのデバイスドライバと装置ドライバの構成をモデル化して示す図である。ここでは、データ変換装置５は、１つの製造管理システム３に実装される製造管理アプリケーションプログラム３１と、異なる種類の２つの設備装置２Ａ，２Ｂに接続される場合が示されている。設備装置２Ａは、２つの機能２１１Ａ１，２１１Ａ２を有する設備機械２１Ａと１つの機能２２１ａを有するデバイス２２ａとから構成され、設備装置２Ｂは、１つの機能２１１Ｂを有する設備機械２１Ｂと２つの機能２２１ｂ１，２２１ｂ２を有するデバイス２２ｂとから構成される。
【００１６】
データ変換装置５のデバイスドライバ５１ａ，５１ｂは、通信する設備装置２Ａ，２Ｂのデバイス２２ａ，２２ｂに対応する１つ以上のデバイスオブジェクト５１１ａ，５１１ｂを有する。また、デバイスオブジェクト５１１ａ，５１１ｂは、そのデバイス２２ａ，２２ｂが持つ機能に対応する１つ以上の機能オブジェクト５１２ａ，５１２ｂ１，５１２ｂ２を有する。このデバイスオブジェクト５１１ａ，５１１ｂの機能オブジェクト５１２ａ，５１２ｂ１，５１２ｂ２への分類は、機能オブジェクトモデルを用いて行われる。
【００１７】
図４は、ＵＭＬ（Unified  Modeling  Language）のクラス図に基づいた機能オブジェクトモデルの概要を示す図である。図３の設備機械２１やデバイス２２の機能２１１，２２１への設定は、機能オブジェクトのパラメータの設定によって行われる。また、機能２１１，２２１の操作は、機能オブジェクトのオペレーションによって行われる。オペレーションはオプション設定や設定データをパラメータとして設定し、呼び出すことによって行われ、操作の結果は、同じくオペレーションの持つパラメータに設定され返答される。機能オブジェクトには、入出力の属性オブジェクトがあり、入力には機能２１１，２２１に対するモード設定や入力値を設定し、出力には機能２１１，２２１の状態モニタや出力値が読み取られる。属性オブジェクトは機能２１１，２２１の周期的またはサイクリックに更新されるデータに用いられる。
【００１８】
この機能オブジェクトモデルによってモデル化された各デバイスオブジェクト５１１ａ，５１１ｂの機能オブジェクト５１２ａ，５１２ｂ１，５１２ｂ２がデバイスドライバ５１ａ，５１ｂに実装され、アクセスされると、デバイスドライバ５１ａ，５１ｂは対応するデバイス２２ａ，２２ｂと通信を行い、デバイス２２ａ，２２ｂへのデータ書込みやデバイス２２ａ，２２ｂからのデータ取得を行い、さらにデバイス２２ａ，２２ｂのオペレーションを起動することが可能となる。
【００１９】
データ変換装置５の装置ドライバ５２Ａ，５２Ｂは、通信する設備機械２１に対応する１つ以上の装置オブジェクト５２１Ａ，５２１Ｂを有する。また、装置オブジェクト５２１Ａ，５２１Ｂは、設備機械２１が持つ機能２１１Ａ１，２１１Ａ２，２１１Ｂに対応する１つ以上の機能オブジェクト５２２Ａ１，５２２Ａ２，５２２Ｂを有する。この装置オブジェクト５２１Ａ，５２１Ｂの機能オブジェクト５２２Ａ１，５２２Ａ２，５２２Ｂへの分類も、デバイスドライバ５１ａ，５１ｂの場合と同様に、図４のＵＭＬのクラス図に基づいた機能オブジェクトモデルを用いて行われる。機能オブジェクトモデルによってモデル化された各機能オブジェクト５２２Ａ１，５２２Ａ２，５２２Ｂが装置ドライバ５２Ａ，５２Ｂに実装され、アクセスされると、装置ドライバ５２Ａ，５２Ｂは設備機械２１Ａ，２１Ｂの機能２１１Ａ１，２１１Ａ２，２１１Ｂに対応するデバイスドライバ５１ａ，５１ｂの機能オブジェクト５１２ａ，５１２ｂ１，５１２ｂ２への属性の書込みや読出しを行うことができる。これにより、対応するデバイス２２ａ，２２ｂが実装されている設備装置２Ａ，２Ｂとの間のデータの読書きや操作を行うことが可能となる。
【００２０】
より具体的には、図３において、たとえばデバイス２２に注目すると、２つのデバイス２２ａ，２２ｂに対応して２つのデバイスオブジェクト５１１ａ，５１１ｂが作成される。また、デバイス２２ａは１つの機能２２１ａを有するので、デバイスオブジェクト５１１ａは１つの機能オブジェクト５１２ａを有し、デバイス２２ｂは２つの機能２２１ｂ１，２２１ｂ２を有するので、デバイスオブジェクト５１１ｂは２つの機能オブジェクト５１２ｂ１，５１２ｂ２を有している。
【００２１】
さらに、設備機械２１に注目すると、装置オブジェクト５２１Ａは、設備機械２１Ａの有する機能２１１Ａ１，２１１Ａ２に対応して２つの機能オブジェクト５２２Ａ１，５２２Ａ２を有し、装置オブジェクト５２１Ｂは、設備機械２１Ｂの有する機能２１１Ｂに対応して１つの機能オブジェクト５２２Ｂを有している。
【００２２】
なお、図３の例では、デバイスオブジェクト５１１を１つのデバイスドライバ５１とし、装置オブジェクト５２１を１つの装置ドライバ５２としている場合を示しているが、これに限定されるものではない。たとえば、複数の種類のデバイス２２の機能２２１を、上位概念的に抽出することができれば、その複数の種類のデバイス２２に対して１つのデバイスオブジェクトを割当ててもよい。装置オブジェクト５２１の場合も同様に、複数の種類の設備機械２１の機能２１１を、上位概念的に抽出することができれば、その複数の種類の設備機械２１に対して１つの装置オブジェクト５２１を割当ててもよい。これらの場合には、図２のようにデバイス２２や設備機械２１の種類に応じてデバイスドライバ５１や装置ドライバ５２を用意する必要がなくなる。
【００２３】
このように、デバイスオブジェクト５１１と装置オブジェクト５２１について、機能オブジェクトモデルに基づいて機能オブジェクト５１２，５２２を作成することで、デバイスドライバ５１と装置ドライバ５２とを、図２に示すように階層化して構成することが可能となる。つまり、図２に示されるように、データ変換装置５には、設備装置２Ａ〜２Ｄの種類に対応した装置ドライバ５２Ａ〜５２Ｄと、設備装置２Ａ〜２Ｄに実装されるデバイス２２ａ〜２２ｃの種類に対応したデバイスドライバ５１ａ〜５１ｃとを備えるように構成すればよく、必要最小限のドライバで、設備装置２における設備機械２１とデバイス２２の組み合わせに対応することが可能となる。たとえば、設備装置２Ｃ，２Ｄは同じデバイス２２ｃを使用しているが、データ変換装置５には１種類のデバイス２２ｃに対応する１つのデバイスドライバ５１ｃだけ用意すればよい。また、設備機械２１の提供者は、その設備機械２１に対応した図４の機能オブジェクトモデルに基づいた装置ドライバ５２を用意するだけでよく、デバイス２２の提供者は、そのデバイス２２に対応した図４の機能オブジェクトモデルに基づいたデバイスドライバ５１を用意するだけでよい。
【００２４】
つぎに、このような階層的な構造を有するドライバを備えるデータ変換装置５におけるデータ変換の処理手順について説明する。ここでは、図３において、製造管理アプリケーションプログラム３１が設備装置２Ａの機能２１１Ａ１へアクセスする場合を例に挙げる。まず、製造管理アプリケーションプログラム３１は、設備装置２Ａに対して機能２１１Ａ１による処理Ｔを実行するように指示Ｉ0を出す。
【００２５】
処理Ｔを実行する旨の指示Ｉ0は、データ変換装置５の装置ドライバ５２Ａに入力される。設備装置２Ａの機能２１１Ａ１に対応する装置ドライバ５２Ａの機能オブジェクト５２２Ａ１は、この機能オブジェクト５２２Ａ１に対応するデバイスドライバ５１ａに対して、処理Ｔを設備装置２Ａで実行するための指示Ｉ1を出す。つまり、この機能オブジェクト５２２Ａ１では、処理Ｔを実行するために入力される指示Ｉ0を、対応する設備装置２Ａで処理可能な指示Ｉ1に変換して出力する。
【００２６】
デバイスドライバ５１ａに、処理Ｔを設備装置２Ａで実施する旨の指示Ｉ1が入力されると、設備装置２Ａに実装されるデバイス２２ａの機能２２１ａに対応するデバイスドライバ５１ａの機能オブジェクト５１２ａは、指示Ｉ1の内容を、設備装置２Ａのデバイス２２ａで認識可能な形式の指示（信号）Ｉ2に変換して、ネットワークを介して接続される設備装置２Ａのデバイス２２ａに対して送信する。設備装置２Ａのデバイス２２ａでは、この指示（信号）Ｉ2に基づいて、設備機械２１Ａの制御やデータ収集を行う。なお、逆方向のデータの流れも同様にして処理される。
【００２７】
この実施の形態１によれば、従来、設備機械２１とこの設備機械２１に取り付けられるデバイス２２の組合せの種類が異なると、設備装置２ごとに異なるドライバをデータ変換装置５に用意する必要があったが、ドライバを、デバイスとの通信を制御するデバイスドライバ５１と、装置を制御する装置ドライバ５２に階層化して構成することにより、デバイス２２のデバイスドライバ５１はデバイスメーカが、設備機械２１の装置ドライバ５２は設備機械メーカが別々に提供することができるという効果を有する。また、異なるデバイス２２を用いたときでも、ドライバのインタフェースの共通化を図ることができる。
【００２８】
実施の形態２．
実施の形態１では、データ変換装置において、デバイスドライバと装置ドライバとを階層化して構成するようにしていた。しかし、このような分類によるドライバの階層化だけでなく、他の視点からデータ変換装置のドライバを階層化して構成するようにしてもよい。
【００２９】
従来、製造管理アプリケーションプログラムは異なる複数のデバイスから製造工程情報を取得し、製造指示を出していた。しかし、設備装置ごとにプロトコルやデータ構造が異なるため、製造管理アプリケーションプログラムが個々の設備装置との通信制御やデータ変換、製造工程を構成する設備装置２の構成管理をする必要があり、製造管理アプリケーションプログラムの汎用化が困難であった。そこで、この実施の形態２では、製造管理アプリケーションプログラムを汎用化することが可能なドライバの階層化の他の例について説明する。
【００３０】
図５は、この発明にかかる通信ドライバの実施の形態２の構成を模式的に示す図である。ここでは、複数の設備装置２を有する製造システムにおいて、製造管理アプリケーションプログラム３１が複数の設備装置２を１つの仮想的な装置（以下、仮想装置という）として認識して処理を行うことができるように、ドライバを階層化して構成したものである。実施の形態１と同様に、データ変換装置５には、製造管理システムの製造管理アプリケーションプログラム３１と、設備機械にデバイスが備えられた複数の設備装置２Ａ，２Ｂとがネットワークを介して接続される場合が示されている。
【００３１】
データ変換装置５は、設備装置２Ａ，２Ｂへのアクセスと通信を司る設備装置２Ａ，２Ｂごとに設けられる実装置ドライバ５３Ａ，５３Ｂと、製造管理アプリケーションプログラム３１からの指示（処理）を個々の設備装置２Ａ，２Ｂの機能に合わせた指示（処理）に変換して、複数の実装置ドライバ５３Ａ，５３Ｂを用いて装置データを製造管理アプリケーションプログラム３１に提供する仮想装置ドライバ５４とが、階層化されて構成される。
【００３２】
ここで、実装置ドライバ５３は、実施の形態１におけるデバイスドライバ５１と装置ドライバ５２が組み合わされたものであり、設備機械２１とデバイス２２の組み合わせごと、すなわち設備装置２ごとにデータ変換装置５に実装されるものである。この実装置ドライバ５３も、通信する設備装置２に対応する１つ以上の装置オブジェクト５３１を有し、さらに装置オブジェクト５３１は設備装置２が有する機能ごとに機能オブジェクト５３２を有する。この実装置ドライバ５３は、装置オブジェクト５３１の機能オブジェクトのインスタンスと、各設備装置２の機能とを対応付けたものである。そのため、実装置ドライバ５３は、設備装置２と通信を行い、設備装置２へのデータ書込みや設備装置２からのデータの取得を行うことができる。
【００３３】
また、仮想装置ドライバ５４は、製造管理アプリケーションプログラム３１が複数の設備装置２を１つの仮想装置として扱えるように仮想的に作成したドライバであり、通信する設備装置２に対応する１つ以上の仮想装置オブジェクト５４１を有し、さらに仮想装置オブジェクト５４１は、設備装置２（実装置ドライバ５３）の有する機能２１１（機能オブジェクト５３２）に対応する１つ以上の機能オブジェクト５４２を有する。この仮想装置ドライバ５４は、製造管理アプリケーションプログラム３１から設備装置２へ行われる処理を仮想装置オブジェクト５４１の機能オブジェクト５４２のインスタンスと、実装置ドライバ５３の有する機能オブジェクト５３２のインスタンスとを対応付けたものである。そのため、仮想装置ドライバ５４は、設備装置２の機能２１１に対応する実装置ドライバ５３の機能オブジェクト５３２への属性の書込みや読出しを行うことができ、さらに対応するデバイスが実装されている設備装置２のデータの読書きや操作を行うことができる。
【００３４】
なお、このような構成のデータ変換装置５における動作処理は、実施の形態１の場合と同様なので、ここではその概略を説明する。たとえば結果として得たい処理を実行するための指示が製造管理アプリケーションプログラム３１によって出されると、データ変換装置５の仮想装置ドライバ５４のその処理に対応する機能オブジェクト５４２が、その指示をより具体的な指示に解釈し直して実装置ドライバ５３の対応する機能オブジェクト５３２へ渡し、個々の設備装置２で処理可能な形式の指示（信号）にさらに変換される。そして、設備装置２の制御やデータ収集などの所定の処理が実行される。
【００３５】
つぎに、図５で示した通信ドライバの階層化のより具体的な例を示す。図６は、工程管理にドライバの階層化を適用した場合の通信ドライバの構成を模式的に示す図であり、図７は、工程管理を単位にしてドライバを作成する場合の機能オブジェクトの作成例を示す図である。
【００３６】
図７に示されるように、製造システムの設計情報４１には、製造管理の工程設計に関する工程設計情報４１１と製造管理の設備に関する設備仕様４１２とがあり、この段階では相互に関連付けがなされていない。その後、ライン設計ツール４２が、ＵＭＬのクラス図に基づいてクラス化した工程設計情報４１１と設備仕様４１２の内容をインスタンス化し、それぞれの情報のインスタンスをマッピングする。具体的には、工程設計情報４１１は、工程計画４３１としてインスタンス化され、設備仕様４１２は、設備構成４３２としてインスタンス化され、それぞれが工程割付４３３によって対応付けされる。このような製造管理アプリケーションプログラム３１と設備装置２との間の工程間の対応付けを行うことで、設備装置２を工程単位で管理可能なドライバが作成される。また、製造管理アプリケーションプログラム３１からは、複数の設備装置２を１つの仮想装置として捉えることが可能となる。
【００３７】
図６の例では、設備機械とこの設備機械を制御するデバイスとの組み合わせからなる設備装置２Ａ，２Ｂごとに、設備構成４３２に基づいて作成された設備ドライバ５５Ａ，５５Ｂが設けられており、設備ドライバ５５Ａ，５５Ｂには、設備装置２Ａ，２Ｂが有する機能２１１Ａ，２１１Ｂごとに機能オブジェクト５５２Ａ，５５２Ｂが作成されている。また、設備ドライバ５５Ａ，５５Ｂの上位には、工程計画４３１に基づいて作成された工程ドライバ５６が設けられている。この工程ドライバ５６には、所定の工程ごとに工程モデル５６１が作成され、個々の工程モデル５６１内には、工程計画４３１に含まれる機能を実現する機能オブジェクト５６２が作成されている。これらの工程ドライバ５６の機能オブジェクト５６２と設備ドライバ５５Ａ，５５Ｂの機能オブジェクト５５２Ａ，５５２Ｂは、それぞれ工程割付４３３に基づいて対応付けされており、製造管理アプリケーションプログラム３１からの工程を単位とした指示が、工程ドライバ５６と設備ドライバ５５によって、その工程で使用される設備装置２への指示に落とされて伝達され、その指示に対する応答が製造管理アプリケーションプログラム３１に返される。
【００３８】
このように、複数の設備装置２を１つの仮想装置として認識させるようにする例は、上述した例のほかに、工程管理や在庫管理、リソース管理、品質管理などにも適用することができる。
【００３９】
なお、上述した図５における実装置ドライバまたは図６における設備ドライバを、実施の形態１のようにさらにデバイスとの間の通信を司るデバイスドライバと、デバイスドライバを使用して装置データを製造管理アプリケーションプログラム３１に提供する装置ドライバとの階層構造として構成するようにしてもよい。
【００４０】
この実施の形態２によれば、階層化したドライバにより、設備装置２と製造管理アプリケーションプログラム３１とで異なるデータ構造のデータ変換を実現でき、製造管理アプリケーションプログラム３１の汎用化を図ることができるという効果を有する。
【００４１】
なお、上述した実施の形態１，２では、製造管理アプリケーションプログラム３１と設備装置２との間の通信におけるデータ変換を行う機能を有する階層化したドライバをデータ変換装置５に備える場合を例に挙げたが、階層化したドライバを、製造管理アプリケーションプログラム３１を実装する製造管理システム３側に設けてもよいし、設備装置２側に設けてもよい。このようにすることで、製造システムにデータ変換装置５が不要となり、システム構成を簡略化することができる。
【００４２】
実施の形態３．
実施の形態１，２で示した機能オブジェクトへのアクセスを、その種類によらず共通化することによってドライバへのアクセス処理を容易にすることができる。そこで、この実施の形態３では、ドライバの共通インタフェースとそのアクセス手順の一例について説明する。図８−１〜図８−９は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である。このドライバの共通インタフェースは、図３のドライバモデルとドライバの機能を示す図４の機能オブジェクトモデルにアクセスして、オブジェクトを管理したり、データの読書きを行ったり、オペレーションを実行したりする。
【００４３】
ドライバのアクセス手順は、最初にデバイスや装置オブジェクトをドライバＡＰＩ（Application  Program  Interface）：InitiateDeviceObject()で初期化した後（図８−１）、機能オブジェクトのインスタンスをドライバＡＰＩ：CreateFunctionObject()で生成する（図８−２）。これにより、ドライバにアクセスする側は、ドライバの利用可能な機能オブジェクトを得ることができる。ついで、ドライバＡＰＩ：SetParameter()で機能オブジェクトにコンフィグレーションなどのパラメータを設定する（図８−３）。なお、パラメータとオペレーションは機能オブジェクトからアクセスすることができるが、属性については機能オブジェクトから直接アクセスすることができないので、属性にアクセスするため（データ読書きのため）の属性オブジェクトをドライバＡＰＩ：CreateAttributeObject()で生成する（図８−４）。その後、生成した機能オブジェクトのオペレーションを呼び出し（ドライバＡＰＩ：Execute()）、オペレーションを実行したり（図８−５）、属性の値を読書きして（ドライバＡＰＩ：Read(),  Write()）、属性オブジェクトへのアクセスが行われたりする（図８−６）。
【００４４】
その後、ドライバの使用が終了すると、ドライバの終了処理が行われる。まず、属性オブジェクトをドライバＡＰＩ：DeleteAttributeObject()で削除し（図８−７）、ついで、ドライバＡＰＩ：DeleteFunctionObject()で機能オブジェクトを削除して（図８−８）、最後に、ドライバＡＰＩ：Conclude()でデバイス／装置オブジェクトを終了する（図８−９）。図８−９において、ドライバＡＰＩ：Conclude()は、属性オブジェクトや機能オブジェクトが正常に削除されたかを確認するものであり、システム異常などで、属性オブジェクトや機能オブジェクトが正常終了できないときや即座にドライバを終了するときはドライバＡＰＩ：Abort()を用いる。
【００４５】
この実施の形態３によれば、ドライバの共通インタフェースを用いることで、ドライバのアクセス対象に影響しないドライバＡＰＩを実現することができ、ドライバソフトウェアのポータビリティ性が向上する。また、ドライバのアクセス対象への固有のアクセス情報はドライバのプロファイルの機能オブジェクトの情報として提供され、プロファイルの機能オブジェクトの情報を基にドライバを初期化し、個々の機能オブジェクトや属性オブジェクトにアクセスすることができる。
【００４６】
実施の形態４．
実施の形態１，２で示した階層化された通信ドライバは、実施の形態２で説明したように、製造システムの設計情報や構成情報を基にして作成される。これらの設計情報や構成情報は、電子データの形態での保存、データの流用のし易さ、データ使用の汎用性などの点から、ＸＭＬ（eXtensible  Markup  Language）などのマークアップ言語で記述される傾向が強い。また、ＸＭＬ形式で記述されたデータにＵＭＬのクラス図の考えを導入するようにすれば、設計情報や構成情報から容易に機能オブジェクトを作成することが可能となる。そこで、この実施の形態４では、設計情報や構成情報を、ＵＭＬのクラス図にしたがって分類し、それをＸＭＬ形式で保存するＸＭＬデータモデルについて説明する。
【００４７】
上述したように、製造システムの通信ドライバの機能オブジェクトは、図４の機能オブジェクトモデルに基づいて作成されるものである。そこで、設計情報や構成情報を、機能オブジェクトモデルにしたがってその内容を構成し、この構成をＸＭＬで記述したＸＭＬデータモデルを作成する。図９は、設計情報をＸＭＬプロファイルで記述するためのＸＭＬデータモデルをＵＭＬクラス図で記述した一例を示す図である。ここでは、ＸＭＬ構造をＵＭＬのステレオタイプで記述しており、各ステレオタイプの下にはクラス名を記述している。
【００４８】
たとえば、<<XMLDocument>>はＸＭＬデータ全体を表現し、<<XSDElement>>はＸＭＬスキーマ記述（XSD）の要素を表している。したがって、「XMLDCD」クラスは設計情報のＸＭＬデータ全体を表している。「XMLDCD」クラスの下には、「DeviceDriverClass」、「VirtualDeviceClass」、「FunctionObjectClass」の各クラスが階層化されている。これらのクラスはＸＭＬスキーマ記述の要素になる。ここで、「DeviceDriverClass」は、図３のデバイスドライバ５１や装置ドライバ５２、図５の実装置ドライバ５３、仮想装置ドライバ５４などのドライバに相当する。「VirtualDeviceClass」は、図３のデバイスオブジェクト５１１や装置オブジェクト５２１、図５の装置オブジェクト５３１、仮想装置オブジェクト５４１などのドライバ内の仮想デバイスに相当する。この「VirtualDeviceClass」の下位には、「CreateParameterClass」が存在する。「FunctionObjectClass」は、図３や図５の機能オブジェクトを示す。機能オブジェクトは、図４の機能オブジェクトモデルに示されるように、パラメータ、クリエイトパラメータ、属性、オペレーションからなり、それぞれ「ParameterClass」、「CreateParameterClass」、「OperationClass」、「AttributeClass」に対応し、その情報がそれぞれのクラスに格納される。これらのクラスはＸＭＬスキーマ記述の要素になる。さらに、「OperationClass」はパラメータを有し、さらに下位に「OperationParameterClass」を有し、その情報が格納される。このクラスもＸＭＬスキーマ記述の要素になる。
【００４９】
つまり、この図９に示されるように、XMLDCDクラスの下位にはDeviceDriverClass、VirtualDeviceClass、FunctionObjectClassの各クラスが順に階層化して連なっている。このうち、VirtualDeviceClassの下位にはCreateParameterClassが存在し、FunctionObjectClassの下位には、ParameterClass、CreateParameterClass、OperationClass、AttributeClassの４つのクラスが並列して存在する。さらに、このうちのOperationClassの下位には、OperationParameterClassが存在する。このような、階層構造は、ＸＭＬデータの表記方法に基づいて表現することが可能であり、ＵＭＬにおけるクラス図の関係を、ＸＭＬデータに反映させて記述することができる。
【００５０】
図１０は、図９の設計情報のＸＭＬデータモデルにインスタンス情報モデルを追加したＸＭＬデータモデルの一例を示す図である。図中、左側半分は、図９で示したＵＭＬクラス図で記述した設計情報のＸＭＬデータモデルと同一であり、機能オブジェクトのクラス情報を示す。右半分は、機能オブジェクトのインスタンス情報モデルを示している。このインスタンス情報モデルは、機能オブジェクトのクラス情報に対応するインスタンスの情報を記述するものである。具体的には、インスタンス情報モデルは、上述した実施の形態１，２のデバイスドライバやデバイスドライバが持つ仮想デバイスの構成情報を格納し、実際の設備装置２の情報や設備装置２との対応関係を示すものである。また、インスタンス情報モデルは、階層ドライバが下位のドライバのどの機能オブジェクトや属性に対応しているのかも示すものである。
【００５１】
この図１０の例では、「DeviceDriver」、「VirtualDevice」、「FunctionObject」、「CreateParamater」、「Attribute」は、それぞれ「DeviceDriverClass」、「VirtualDeviceClass」、「FunctionObjectClass」、「CreateParamaterClass」、「AttributeClass」のインスタンス情報を示している。ここで、インスタンス情報「DeviceDriver」の自分自身を指す関係はデバイスドライバの階層構成を示す。また、インスタンス情報「VirtualDevice」の自分自身を指す関係は実装置と実デバイスの構成を示す。たとえば、設備装置を構成しているデバイスを示す。さらに、インスタンス情報「FunctionObject」の自分自身を指す関係は階層ドライバにおいて上位のドライバから呼ばれる下位のドライバファンクションを示す。また、インスタンス情報「Attribute」の自分自身を指す関係は階層ドライバにおいて上位のドライバから呼ばれる下位のインスタンス情報「Attribute」を示す。たとえば、デバイスデータを設備装置データに変換したり、設備装置ごとの分散されたデータをまとめたりするデータ変換装置５のデータ変換の構成情報を示す。
【００５２】
図１１は、図１０のＸＭＬデータモデルに基づいて設計情報と構成情報を記述した一例を示す図である。この図１１の全体がXMLDCDクラスに対応している。そして、このXMLDCDタグ内のブロック１１１０では、図９（図１０の左側半分）に示されるクラス間の階層関係（包含関係）が記述されている。ここでは、図９に示されるステレオタイプの下部に記載されたクラス名をタグの名称として使用している。つまり、「DeviceDriverClass」内に、「VirtualDeviceClass」が含まれ、さらにこの「VirtualDeviceClass」内に１つの「CreateParamaterClass」と２つの「FunctionObjectClass」が含まれており、機能オブジェクトのクラスが２つ生成されている。それぞれの「FunctionObjectClass」内には、さらにパラメータや属性に関するクラスが含まれている。
【００５３】
一方、XMLDCDタグ内のブロック１１２０では、ブロック１１１０のクラス情報に対応したインスタンス情報が記述されている。ここでは、図１０の右側半分に記載されたインスタンス情報モデルのステレオタイプの下部に記載された名称がタグの名称として使用されている。つまり、「DeviceDriver」内に、「VirtualDevice」が含まれ、さらにこの「VirtualDevice」内に１つの「CreateParamater」と、２つの「FunctionObject」が含まれている。また、これらの「CreateParamater」や「FunctionObject」には、属性やパラメータに関する内容が含まれている。
【００５４】
この図１１に示されるように、ブロック１１１０に示されるクラス情報の記述では、作成対象のドライバの機能のパラメータや属性、オペレーションの項目が定義され、ブロック１１２０に示されるインスタンス情報の記述では、作成される個々のドライバの種類に応じたパラメータ等の設定が定義される。また、図１０に示されるように、ＸＭＬデータにおけるクラスを示すタグの名称とインスタンス情報を示すタグの名称とが予め対応付けられている。これにより、機能オブジェクトモデルに基づいて分類された設計情報や構成情報のＸＭＬデータは、ドライバによるデータ変換時に参照され、設備装置やデバイスに関して抽象的なまたは共通的な内容のコマンド（処理）が、個々の設備装置またはデバイスに対応した具体的な内容のコマンド（処理）へと変換され、ドライバによる設備装置またはデバイスへのアクセスを可能とする。
【００５５】
この実施の形態４によれば、設計情報と構成情報のＸＭＬプロファイルモデルを利用して通信ドライバのデータ変換を行うようにしたので、抽象的なまたは共通的な内容の処理をここの設備装置２の具体的な内容の処理に変換することが可能となる。また、ＸＭＬデータモデルを使用することによって、ドライバにおけるデータ変換機能の作成を支援または自動化することができる。
【００５６】
実施の形態５．
デバイスドライバと設備装置のデバイスの間のプロトコルインタフェースは、たとえば、ＯＭＧ（Object  Management  Group）のＣＯＲＢＡ（Common  Object  Request  Broker  Architecture）やマイクロソフトのＤＣＯＭ（Distributed  Component  Object  Model）などの通信プロトコルにしたがって、インタフェース記述言語（以下、ＩＤＬ（Interface  Definition  Language）という）によって記述される。しかし、このＩＤＬは、インスタンス情報を記述できず、またインスタンス情報を記述できるように拡張することもできない。そこで、この実施の形態５では、ＩＤＬをＸＭＬとマッピングして、ＸＭＬでインスタンス情報を記述することができる通信ドライバについて説明する。
【００５７】
図１２は、ＩＤＬとＸＭＬデータの設計情報についてのマッピングモデルの一例を示す図である。この図１２の左側半分は図９に示したＸＭＬデータモデルと同一のものであり、右側半分は、ＩＤＬの記述モデルをＵＭＬのクラス図に基づいてクラス化して示したものである。IDLDCDクラスは、設計情報のＩＤＬデータ全体を表している。IDLDCDクラスの下には、「module」クラスが存在し、この「module」クラスの下には「interface」クラスと「CreateParam」クラスが存在する。また、「interface」クラスの下には、「CreateParam」クラス、「parameter」クラス、「Attribute」クラス、「Operation」クラスが存在し、「Operation」クラスの下にはさらに「OperationParameter」クラスが存在する。これらのIDLDCDクラス、「module」クラス、「interface」クラス、「CreateParam」クラス、「CreatePrama」クラス、「paramater」クラス、「Attribute」クラス、「Operation」クラスおよび「OperationParameter」クラスは、ＸＭＬデータモデルの「DeviceDriverClass」、「VirtualDeviceClass」、「FunctionObjectClass」、「CreateParameterClass」、「ParameterClass」、「AttributeClass」、「OperationClass」および「OperationParameterClass」にそれぞれ対応付け（マッピング）される。
【００５８】
この図１２と図８により、ＩＤＬの記述内容は、ＸＭＬデータモデルのクラスへの対応付けを行うことができ、さらにこのＸＭＬデータモデルのクラスから個々の設備装置に対応したインスタンス情報を参照することができる。
【００５９】
つぎに、このような通信ドライバのプロトコルインタフェース部分の作成方法について説明する。図１３は、インスタンス情報を参照することができる通信ドライバのプロトコルインタフェース部分の作成手順と設定手順の一例を示す図である。まず、製造システム（または個々のデバイスや設備装置）の作成者によって、工程や設備装置、デバイスなどのドライバのアクセス対象のモデルのインタフェース情報を基に、アクセス対象の一般的な性質を示す情報であるＸＭＬプロファイルのクラス情報が記述される（ステップＳ１１）。図１４は、インタフェース情報のＸＭＬプロファイルの記述の一例を示す図である。
【００６０】
ついで、記述されたＸＭＬプロファイルのクラス情報を、図１２に示されるＩＤＬとＸＭＬデータのマッピングモデルを実行するプログラムなどによって、自動的にＩＤＬの記述に変換する（ステップＳ１２）。図１５は、ＩＤＬインタフェース部分のＸＭＬプロファイルの記述パターンの一例を示す図であり、図１６は、ＩＤＬデータタイプ宣言のＸＭＬプロファイルでの記述規則の一例を示す図である。これらの図の左側にはＸＭＬプロファイルの記述例が示されており、その右側には、対応する内容を図１２のモデルにしたがってＩＤＬ記述した例が示されている。図１６のデータタイプ宣言はデータの実装に依存するために、ＩＤＬデータタイプ宣言自体をＸＭＬプロファイルで記述できるようにしている。なお、ＷＳＤＬ（Web  Services  Description  Language）などのＸＭＬベースのインタフェース記述言語を使用する場合には、そのままＸＭＬデータタイプを用いるようにすればよい。これらの図１５と図１６に示されるＸＭＬプロファイル−ＩＤＬマッピング規則にしたがって、ＸＭＬプロファイルのクラス情報の記述がＩＤＬ記述に変換される。図１７は、図１４のＸＭＬプロファイルのクラス情報の記述に対応するＩＤＬ記述の一例を示す図である。
【００６１】
その後、従来公知の方法によって、ドライバソフトウェアのプラットフォーム（オペレーティングシステムなど）に合わせて、変換されたＩＤＬ記述からＣ＋＋クラスが生成され（ステップＳ１３）、ドライバが実装される。
【００６２】
一方、実装されたドライバのアクセス対象のコンフィグレーション設定は、ＸＭＬプロファイルのクラス情報の記述をコンフィグレーション設定ソフトウェアなどのコンフィグレーション設定手段によって読込まれ、コンフィグレーション情報のテンプレートが作成される。このテンプレートは、ＸＭＬプロファイルのクラス情報とインスタンス情報とを対応付けた図１０に示されるＸＭＬデータモデルにしたがって作成される。そして、このテンプレートにしたがって、個々の設備装置についてのインスタンス情報を示すコンフィグレーション情報が設定される（ステップＳ１４）。設定されるコンフィグレーション情報は、ＸＭＬプロファイルのインスタンス情報としてＸＭＬで記述され、ドライバ起動時に読込まれる。
【００６３】
以上のようにして、プロトコルインタフェース部分を含む通信ドライバが作成される。以上の手順によって作成され、実装されたドライバは、読込んだコンフィグレーション情報のインスタンス情報から必要とするオブジェクトを生成したり、アプリケーションオブジェクトの情報を提供したりする。また、製造管理アプリケーションプログラムは、コンフィグレーション情報を直接読込むか、ドライバからオブジェクト情報を取得してドライバを初期化し、アクセス対象にアクセスする。
【００６４】
なお、ステップＳ１２のＩＤＬ記述とステップＳ１３のＣ＋＋クラス生成との間は、従来公知の方法で相互に変換可能であり、また、ステップＳ１１のＸＭＬプロファイルのクラス記述と、ステップＳ１２のＩＤＬ記述との間も、上述した図１２や図１５、図１６に示されるＸＭＬプロファイル−ＩＤＬのマッピング規則に基づいて相互に変換することができる。そのため、製造システム（または個々のデバイスや設備装置）の作成者は、ステップＳ１２のＩＤＬ記述を最初に行ってから、ステップＳ１３のＣ＋＋クラスの作成からドライバを実装し、ステップＳ１１，Ｓ１４のＸＭＬプロファイルのクラス記述からＸＭＬプロファイルのインスタンス記述を行ってドライバに読込ませるようにしてもよい。また、既にＣ＋＋クラスで実装されているドライバに関して、ステップＳ１２でＣ＋＋クラスをＩＤＬ記述に変換し、また、ステップＳ１１でＸＭＬプロファイルのクラス情報に記述し、さらに、ＸＭＬプロファイルのインスタンス記述を行って、プロトコルインタフェース部分を含む通信ドライバを作成してもよい。
【００６５】
この実施の形態５によれば、ＩＤＬはオブジェクトのインタフェースのタイプを示しているだけで、インスタンス化したオグジェクトの構成を記述することができないが、ＸＭＬでオブジェクトのインタフェースとインスタンスの構成を記述することで、製造管理アプリケーションに製造システムを構成する設備装置とその機能オブジェクトのインタフェースと構成情報を提供することができ、製造アプリケーションが製造装置へアクセスするための設定を支援、あるいは自動化することができる効果を有する。また、その際に必要となるデータ変換のためのマッピング構成を記述することができる。
【００６６】
また、ドライバの共通化を実現することができ、それによりドライバの開発も効率化される。さらに、従来個別に作成していたコンフィグレーション設定ソフトウェアも共通化することができる。
【００６７】
なお、上述した実施の形態４，５では、ドライバのクラス情報とインスタンス情報を記述するデータモデルとしてＸＭＬを用いたが、ＸＭＬに限られる趣旨ではなく、図１０に示されるデータモデルにしたがってデータ内容を記述することができるものであればよい。
【産業上の利用可能性】
【００６８】
以上のように、この発明にかかる通信ドライバは、たとえば製造工場における搬送設備機械や製造設備機械、検査設備機械などのそれぞれの設備機械を制御する制御部を備えた設備装置との間で通信されるデータの変換に適している。
【図面の簡単な説明】
【００６９】
【図１】図１は、この発明が適用される製造システムの一例を模式的に示す図である。
【図２】図２は、データ変換装置のドライバ構成を模式的に示す図である。
【図３】図３は、実施の形態１でのデバイスドライバと装置ドライバをモデル化して示す図である。
【図４】図４は、ＵＭＬのクラス図に基づいた機能オブジェクトモデルの概要を示す図である。
【図５】図５は、この発明による通信ドライバの実施の形態２の構成を模式的に示す図である。
【図６】図６は、工程管理にドライバの階層化を適用した場合の通信ドライバの構成を模式的に示す図である。
【図７】図７は、工程管理を単位にしてドライバを作成する場合の機能オブジェクトの作成例を示す図である。
【図８−１】図８−１は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その１）。
【図８−２】図８−２は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その２）。
【図８−３】図８−３は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その３）。
【図８−４】図８−４は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その４）。
【図８−５】図８−５は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その５）。
【図８−６】図８−６は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その６）。
【図８−７】図８−７は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その７）。
【図８−８】図８−８は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その８）。
【図８−９】図８−９は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その９）。
【図９】図９は、設計情報をＸＭＬプロファイルで記述するためのＸＭＬデータモデルをＵＭＬクラス図で記述した一例を示す図である。
【図１０】図１０は、図９の設計情報のＸＭＬデータモデルにインスタンス情報モデルを追加したＸＭＬデータモデルの一例を示す図である。
【図１１】図１１は、図１０のＸＭＬデータモデルに基づいて設計情報と構成情報を記述した一例を示す図である。
【図１２】図１２は、ＩＤＬとＸＭＬデータの設計情報についてのマッピングモデルの一例を示す図である。
【図１３】図１３は、インスタンス情報を参照することができる通信ドライバのプロトコルインタフェース部分の作成手順と設定手順の一例を示す図である。
【図１４】図１４は、インタフェース情報のＸＭＬプロファイルの記述の一例を示す図である。
【図１５】図１５は、ＩＤＬインタフェース部分のＸＭＬプロファイルの記述パターンの一例を示す図である。
【図１６】図１６は、ＩＤＬデータタイプ宣言のＸＭＬプロファイルでの記述規則の一例を示す図である。
【図１７】図１７は、図１４のＸＭＬプロファイルのクラス情報の記述に対応するＩＤＬ記述の一例を示す図である。
【符号の説明】
【００７０】
１  製造システム
２  設備装置
３  製造管理システム
４  設計情報格納装置
５  データ変換装置
６  ネットワーク
２１  設備装置
２２  デバイス
３１  製造管理アプリケーションプログラム
５１  デバイスドライバ
５２  装置ドライバ
２１１，２２１  機能
５１１  デバイスオブジェクト
５１２，５２２  機能オブジェクト
５２１  装置オブジェクト
【図１】
0004629729.tif 000002
【図２】
0004629729.tif 000003
【図３】
0004629729.tif 000004
【図４】
0004629729.tif 000005
【図５】
0004629729.tif 000006
【図６】
0004629729.tif 000007
【図７】
0004629729.tif 000008
【図８−１】
0004629729.tif 000009
【図８−２】
0004629729.tif 000010
【図８−３】
0004629729.tif 000011
【図８−４】
0004629729.tif 000012
【図８−５】
0004629729.tif 000013
【図８−６】
0004629729.tif 000014
【図８−７】
0004629729.tif 000015
【図８−８】
0004629729.tif 000016
【図８−９】
0004629729.tif 000017
【図９】
0004629729.tif 000018
【図１０】
0004629729.tif 000019
【図１１】
0004629729.tif 000020
【図１２】
0004629729.tif 000021
【図１３】
0004629729.tif 000022
【図１４】
0004629729.tif 000023
【図１５】
0004629729.tif 000024
【図１６】
0004629729.tif 000025
【図１７】
0004629729.tif 000026