WO2006114810A1

WO2006114810A1 - 通信ドライバ

Info

Publication number: WO2006114810A1
Application number: PCT/JP2005/006374
Authority: WO
Inventors: Seiichi Kawano; Kenji Suzuki
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2005-03-31
Filing date: 2005-03-31
Publication date: 2006-11-02
Anticipated expiration: 2007-09-30
Also published as: JPWO2006114810A1; US20090037010A1; DE112005003519T5; CN100524263C; CN101156143A; JP4629729B2

Abstract

　設備機械に管理装置からの指示に基づいて設備機械を制御するデバイスが設けられた設備装置と、設備装置を管理する管理アプリケーションプログラムを有する管理装置とが接続される製造システムで、設備装置と管理装置で使用されるデータフォーマットが異なる場合でも、両装置間でのデータ変換を行う通信ドライバを得ること。　製造システム中のデバイス（２２ａ，２２ｂ）の種類ごとに設けられ、デバイス（２２ａ，２２ｂ）との間の通信を司るデバイスドライバ（５１ａ，５１ｂ）と、製造システム中の設備機械（２１Ａ，２１Ｂ）の種類ごとに設けられ、管理アプリケーションプログラム（３１）からの指示にしたがって、デバイスドライバ（５１ａ，５１ｂ）を使用して対象となる設備機械（２１Ａ，２１Ｂ）にアクセスする装置ドライバ（５２Ａ，５２Ｂ）とを備え、デバイスドライバ（５１Ａ，５１Ｂ）と装置ドライバ（５２Ａ，５２Ｂ）が階層化される。

Description

通信ドライバ

技術分野

[0001] この発明は、たとえば製造工場における搬送設備機械や製造設備機械、検査設備機械などのそれぞれの設備機械とこの設備機械を制御するデバイスを備えた設備装置と、これらの設備装置を管理する管理装置とがネットワークを介して接続された製造システムにお、て、上記設備装置と上記管理装置との間で通信されるデータの変換を行う通信ドライバに関するものである。

背景技術

[0002] 従来、生産設備として実際にワークの加工、洗浄、運搬などに携わる各種の工作機械ゃ段取装置、洗浄装置、作業指示装置、搬送装置などの制御対象設備と、これらの制御対象設備の運用のための加工日程計画や加工順序情報、使用予定治具情報などの基本情報を処理して運転スケジュールを作成しながらこれらの制御対象設備を統括的に運転制御する制御装置とが、ネットワークで接続された構成を有するフレキシブル生産システムが提案され、普及してきている。このようなフレキシブル生産システムの一例として、上記制御装置を上記制御対象設備の機能要素ごとに分割して複数配置して、機能要素ごとに制御対象設備の運転制御を行うようにすると共に、制御対象設備の運転制御に用いられる制御情報伝送用の通信回線と、フレキシブル生産システムの運用管理に用いられる運用情報伝送用の通信回線とを別々に設けて、システム全体としての情報の流れを円滑にそして高効率に行うシステムがある（たとえば、特許文献 1参照)。

[0003] 特許文献 1：特許第 2577600号公報

発明の開示

発明が解決しょうとする課題

[0004] 上記特許文献 1に記載されるようなフレキシブル生産システムでは、制御対象設備や制御装置は異なるベンダのものを組み合わせて構築される場合が多く存在する。このような場合、ベンダごとに制御対象設備に設定されるパラメータの意味や制御対象設備や制御装置で使用されるデータフォーマットが異なるために、制御装置には、該制御装置が運転制御を行う制御対象設備ごとにデータアクセスプログラムが必要となるという問題点があった。さらに、このデータアクセスプログラムを開発するための作業は、制御対象設備ごとに行う必要があるために、データアクセスプログラムの作業者に大きな負荷が掛つてしまうという問題点もあった。

[0005] この発明は、上記に鑑みてなされたもので、製造に関与する設備装置と該設備装置を管理制御する管理装置とがネットワークを介して構成される製造システムにおいて、設備装置と管理装置で使用されるデータフォーマットが異なる場合や、設備装置に設定されるパラメータの意味がベンダごとに異なる場合でも、設備装置と管理装置との間で通信できるようにデータ変換を行う通信ドライバを得ることを目的とする。課題を解決するための手段

[0006] 上記目的を達成するため、この発明にかかる通信ドライバは、所定の処理を行う設備機械に、管理装置力もの指示に基づいて前記設備機械を制御するデバイスが設けられた設備装置と、前記設備装置を管理する管理アプリケーションプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーションプロダラムカの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、前記製造システムに設けられる前記設備機械の種類ごとに設けられ、前記管理ァプリケーシヨンプログラム力の指示にしたがって、前記デバイスドライバを使用して対象となる前記設備機械にアクセスする装置ドライバと、を備え、前記デバイスドライノと前記装置ドライバが階層化されて構成されることを特徴とする。

発明の効果

[0007] この発明によれば、ドライバを、デバイスとの通信を制御するデバイスドライバと、装置を制御する装置ドライバに階層化して構成することにより、デバイスのデバイスドラィバはデバイスメーカが、設備機械の装置ドライバは設備機械メーカが別々に提供することができると!/、う効果を有する。図面の簡単な説明

[図 1]図 1は、この発明が適用される製造システムの一例を模式的に示す図である。圆 2]図 2は、データ変換装置のドライバ構成を模式的に示す図である。

[図 3]図 3は、実施の形態 1でのデバイスドライバと装置ドライバをモデルィ匕して示す図である。

[図 4]図 4は、 UMLのクラス図に基づいた機能オブジェクトモデルの概要を示す図である。

[図 5]図 5は、この発明による通信ドライバの実施の形態 2の構成を模式的に示す図である。

[図 6]図 6は、工程管理にドライバの階層化を適用した場合の通信ドライバの構成を模式的に示す図である。

[図 7]図 7は、工程管理を単位にしてドライバを作成する場合の機能オブジェクトの作成例を示す図である。

[図 8-1]図 8— 1は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 1)。

[図 8-2]図 8— 2は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 2)。

[図 8-3]図 8— 3は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 3)。

[図 8-4]図 8—4は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 4)。

[図 8-5]図 8— 5は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 5)。

[図 8-6]図 8— 6は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 6)。

[図 8-7]図 8— 7は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 7)。

[図 8-8]図 8— 8は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 8)。

[図 8-9]図 8— 9は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である（その 9)。

[図 9]図 9は、設計情報を XMLプロファイルで記述するための XMLデータモデルを UMLクラス図で記述した一例を示す図である。

[図 10]図 10は、図 9の設計情報の XMLデータモデルにインスタンス情報モデルを追加した XMLデータモデルの一例を示す図である。

[図 11]図 11は、図 10の XMLデータモデルに基づ、て設計情報と構成情報を記述した一例を示す図である。

[図 12]図 12は、 IDLと XMLデータの設計情報についてのマッピングモデルの一例を示す図である。

[図 13]図 13は、インスタンス情報を参照することができる通信ドライバのプロトコルインタフエース部分の作成手順と設定手順の一例を示す図である。

[図 14]図 14は、インタフェース情報の XMLプロファイルの記述の一例を示す図である。

[図 15]図 15は、 IDLインタフェース部分の XMLプロファイルの記述パターンの一例を示す図である。

[図 16]図 16は、 IDLデータタイプ宣言の XMLプロファイルでの記述規則の一例を示す図である。

[図 17]図 17は、図 14の XMLプロファイルのクラス情報の記述に対応する IDL記述の一例を示す図である。

符号の説明

1 製造システム

2 設備装置

3 製造管理システム

4 設計情報格納装置

5 データ変換装置

6 ネットワーク 21 設備装置

22 デバイス

31 製造管理アプリケーションプログラム

51 デバイスドライバ

52 装置ドライバ

211, 221 機能

511 デバイスオブジェクト

512, 522 機能オブジェクト

521 装置オブジェクト

発明を実施するための最良の形態

[0010] 以下に添付図面を参照して、この発明にかかる通信ドライバの好適な実施の形態を詳細に説明する。

[0011] 実施の形態 1.

図 1は、この発明が適用される製造システムの一例を模式的に示す図である。製造システム 1は、該製造システム 1においてある製品の製造に関与する所定の動作を実行する設備装置 2と、これらの設備装置 2の管理などを行う製造管理システム（ Manufacturing Execution System, MES) 3と、設備装置 2や製造管理システム 3の仕様書や設計書などの設計情報を格納する設計情報格納装置 4と、設備装置 2と製造管理システム 3との間でやり取りされるデータの変換を行うデータ変換装置 5と、が、データ伝送を行うネットワーク 6を介して相互に接続される構成を有して、る。

[0012] 設備装置 2は、製造における所定の処理を実際に行う設備機械 21と、この設備機械 21を所定のプログラムとパラメータにしたがって動作させると共に製造管理システム 3との間で通信を行うデバイス 22と、を備える。なお、デバイス 22には、設備機械 2 1を制御するコントローラのほかに、センサゃァクチユエータなども含まれる。設備装置 2として、たとえばある製品を製造するための部品の搬送を行う搬送装置や、搬送された部品を用いて製品を製造する製造装置、製造された装置の検査を行う検査装置などが該当する。

[0013] 製造管理システム 3は、製造実績管理、設備保守保全、作業者管理、プロセス管理、品質管理、製造指示、データ収集、物流制御などの製造管理アプリケーションプログラムを実行し、ネットワーク 6を介して各設備装置 2との間で通信を行い、データ収集やレシピなどのデータ転送、ノメータ設定などの実行指示を行う装置である。このような製造管理システム 3は、製造管理アプリケーションプログラムを格納する記憶手段と、製造管理アプリケーションプログラムにしたがって処理を実行する処理実行手段と、ネットワーク 6とのインタフェースとなる通信手段と、を備えるワークステーションゃパーソナルコンピュータなどの情報処理端末によって構成される。

[0014] 設計情報格納装置 4は、各設備装置 2と各製造管理システム 3に関する設計情報を格納する装置であり、データ変換装置 5から指示される設計情報を提供する。この設計情報として、設備装置 2についての設計書である装置設計書、製造管理システム 3 の設計書である製造管理システム設計書、設備装置 2に設けられるデバイス 22の仕様書であるデバイス仕様書、製造管理システム 3に設定されるプログラムの仕様書である設備接続仕様書などを例示することができる。

[0015] データ変換装置 5は、設備装置 2と製造管理システム 3との間で通信されるデータについて、プロトコルの違いや、ベンダや機種などの違いによるユーザデータ定義の違いなどを、設計情報格納装置 4に格納される設計情報に基づいて吸収し、データ受信側の機器 (設備装置 2または製造管理システム 3)で読込むことが可能な形式のデータフォーマットに変換する機能を有する。

[0016] 図 2は、データ変換装置のドライバの実施の形態 1の構成を模式的に示す図である。この図では、データ変換装置 5は、 1つの製造管理システム 3に実装される製造管理アプリケーションプログラム 31と、異なる種類の 4つの設備装置 2A〜2Dに接続される場合が示されている。また、設備装置 2Bには 2つのデバイス 22a, 22bが備えられ、設備装置 2C, 2Dには同一のデバイス 22cが備えられている。図 2に示されるように、このデータ変換装置 5は、設備装置 2A〜2Dのデバイス 22a〜22cとの通信を司るデバイスドライバ 51 _a〜 51 cと、デバイスドライバ 51 a〜 51 cを使用して設備装置 2A 〜2Dのデータを製造管理システム 3の製造管理アプリケーションプログラム 31に提供する装置ドライバ 52A〜52Dとが、階層化されて構成される。

[0017] ここで、データ変換装置 5に設けられる階層化されたドライバを作成する一般的なモデルについて説明する。図 3は、この実施の形態 1でのデバイスドライバと装置ドライバの構成をモデルィ匕して示す図である。ここでは、データ変換装置 5は、 1つの製造管理システム 3に実装される製造管理アプリケーションプログラム 31と、異なる種類の 2つの設備装置 2A, 2Bに接続される場合が示されている。設備装置 2Aは、 2つの機能 211A1, 211A2を有する設備機械 21Aと 1つの機能 221aを有するデバイス 2 2aとから構成され、設備装置 2Bは、 1つの機能 211Bを有する設備機械 21Bと 2つの機能 221bl, 221b2を有するデバイス 22bと力構成される。

[0018] データ変換装置 5のデバイスドライバ 5 la, 51bは、通信する設備装置 2A, 2Bのデバイス 22a, 22bに対応する 1つ以上のデバイスオブジェクト 511a, 511bを有する。また、デバイスオブジェクト 511 a, 51 lbは、そのデバイス 22a, 22bが持つ機能に対応する 1つ以上の機能オブジェクト 512a, 512bl, 512b2を有する。このデバイスォブジェク卜 511a, 5 l ibの機能オブジェク卜 512a, 512bl, 512b2への分類は、機能オブジェクトモデルを用いて行われる。

[0019] 図 4は、 UML (Unified Modeling Language)のクラス図に基づいた機能オブジェクトモデルの概要を示す図である。図 3の設備機械 21やデバイス 22の機能 211, 221 への設定は、機能オブジェクトのパラメータの設定によって行われる。また、機能 211 , 221の操作は、機能オブジェクトのオペレーションによって行われる。オペレーションはオプション設定や設定データをパラメータとして設定し、呼び出すことによって行われ、操作の結果は、同じくオペーシヨンの持つパラメータに設定され返答される。機能オブジェクトには、入出力の属性オブジェクトがあり、入力には機能 211, 221に対するモード設定や入力値を設定し、出力には機能 211, 221の状態モニタや出力値が読み取られる。属性オブジェクトは機能 211, 221の周期的またはサイクリックに更新されるデータに用いられる。

[0020] この機能オブジェクトモデルによってモデル化された各デバイスオブジェクト 511a, 5 l ibの機會ォブジェク卜 512a, 512bl, 512b2力 ^デノイスド、ライノ 5 la, 51bに実装され、アクセスされると、デバイスドライバ 51a, 51bは対応するデバイス 22a, 22b と通信を行い、デバイス 22a, 22bへのデータ書込みやデバイス 22a, 22b力らのデータ取得を行い、さらにデバイス 22a, 22bのオペレーションを起動することが可能となる。

[0021] データ変換装置 5の装置ドライバ 52A, 52Bは、通信する設備機械 21に対応する 1 つ以上の装置オブジェクト 521A, 521Bを有する。また、装置オブジェクト 521A, 5 21Bは、設備機械 21が持つ機能 211A1, 211A2, 211Bに対応する 1つ以上の機能オブジェク卜 522A1, 522A2, 522Bを有する。この装置オブジェク卜 521A, 521 Bの機能オブジェクト 522A1, 522A2, 522Bへの分類も、デバイスドライバ 51a, 51 bの場合と同様に、図 4の UMLのクラス図に基づいた機能オブジェクトモデルを用いて行われる。機能オブジェクトモデルによってモデルィ匕された各機能オブジェクト 52 2A1, 522A2, 522Bが装置ドライバ 52A, 52Bに実装され、アクセスされると、装置ドライバ 52A, 52Bは設備機械 21A, 21Bの機能 211A1, 211A2, 211Bに対応するデバイスドライバ 5 la, 5 lbの機能オブジェクト 512a, 512bl, 512b2への属性の書込みや読出しを行うことができる。これにより、対応するデバイス 22a, 22bが実装されている設備装置 2A, 2Bとの間のデータの読書きや操作を行うことが可能となる。

[0022] より具体的には、図 3において、たとえばデバイス 22に注目すると、 2つのデバイス 2 2a, 22bに対応して 2つのデバイスオブジェクト 511a, 511bが作成される。また、デバイス 22aは 1つの機能 221aを有するので、デバイスオブジェクト 51 laは 1つの機能オブジェクト 512aを有し、デバイス 22bは 2つの機能 221bl, 221b2を有するので、デバイスオブジェクト 51 lbは 2つの機能オブジェクト 512b 1 , 512b2を有して!/、る。

[0023] さらに、設備機械 21に注目すると、装置オブジェクト 521Aは、設備機械 21Aの有する機能 211A1, 211A2に対応して 2つの機能オブジェクト 522A1, 522A2を有し、装置オブジェクト 521Bは、設備機械 21Bの有する機能 211Bに対応して 1つの機能オブジェクト 522Bを有して、る。

[0024] なお、図 3の例では、デバイスオブジェクト 511を 1つのデバイスドライバ 51とし、装置オブジェクト 521を 1つの装置ドライバ 52としている場合を示している力これに限定されるものではない。たとえば、複数の種類のデバイス 22の機能 221を、上位概念的に抽出することができれば、その複数の種類のデバイス 22に対して 1つのデバイスオブジェクトを割当ててもよい。装置オブジェクト 521の場合も同様に、複数の種類の設備機械 21の機能 211を、上位概念的に抽出することができれば、その複数の種類の設備機械 21に対して 1つの装置オブジェクト 521を割当ててもよい。これらの場合には、図 2のようにデバイス 22や設備機械 21の種類に応じてデバイスドライバ 51や装置ドライバ 52を用意する必要がなくなる。

[0025] このように、デバイスオブジェクト 511と装置オブジェクト 521について、機能ォブジエタトモデルに基づいて機能オブジェクト 512, 522を作成することで、デバイスドライノ 51と装置ドライバ 52とを、図 2に示すように階層化して構成することが可能となる。つまり、図 2に示されるように、データ変換装置 5には、設備装置 2A〜2Dの種類に対応した装置ドライバ 52A〜52Dと、設備装置 2A〜2Dに実装されるデバイス 22a 〜22cの種類に対応したデバイスドライバ 5 la〜51cとを備えるように構成すればよく、必要最小限のドライバで、設備装置 2における設備機械 21とデバイス 22の組み合わせに対応することが可能となる。たとえば、設備装置 2C, 2Dは同じデバイス 22cを使用して、る力データ変換装置 5には 1種類のデバイス 22cに対応する 1つのデバイスドライバ 51cだけ用意すればよい。また、設備機械 21の提供者は、その設備機械 21に対応した図 4の機能オブジェクトモデルに基づ、た装置ドライバ 52を用意するだけでよぐデバイス 22の提供者は、そのデバイス 22に対応した図 4の機能オブジェタトモデルに基づ、たデバイスドライバ 51を用意するだけでょ、。

[0026] つぎに、このような階層的な構造を有するドライバを備えるデータ変換装置 5におけるデータ変換の処理手順について説明する。ここでは、図 3において、製造管理アブリケーシヨンプログラム 31が設備装置 2Aの機能 211A1へアクセスする場合を例に挙げる。まず、製造管理アプリケーションプログラム 31は、設備装置 2Aに対して機能 2 11 A1による処理 Tを実行するように指示 Iを出す。

0

[0027] 処理 Tを実行する旨の指示 Iは、データ変換装置 5の装置ドライバ 52Aに入力され

0

る。設備装置 2Aの機能 211A1に対応する装置ドライバ 52Aの機能オブジェクト 522 A1は、この機能オブジェクト 522A1に対応するデバイスドライバ 5 laに対して、処理 Tを設備装置 2Aで実行するための指示 Iを出す。つまり、この機能オブジェクト 522

1

A1では、処理 Tを実行するために入力される指示 Iを、対応する設備装置 2Aで処

0

理可能な指示 I

1に変換して出力する。

[0028] デバイスドライバ 51aに、処理 Tを設備装置 2 Aで実施する旨の指示 Iが入力されると、設備装置 2Aに実装されるデバイス 22aの機能 221aに対応するデバイスドライバ 51aの機能オブジェクト 512aは、指示 Iの内容を、設備装置 2 Aのデバイス 22aで認

1

識可能な形式の指示 (信号) Iに変換して、ネットワークを介して接続される設備装置

2

2Aのデバイス 22aに対して送信する。設備装置 2Aのデバイス 22aでは、この指示（信号) Iに基づいて、設備機械 21 Aの制御やデータ収集を行う。なお、逆方向のデ

2

ータの流れも同様にして処理される。

[0029] この実施の形態 1によれば、従来、設備機械 21とこの設備機械 21に取り付けられるデバイス 22の組合せの種類が異なると、設備装置 2ごとに異なるドライバをデータ変換装置 5に用意する必要があった力ドライバを、デバイスとの通信を制御するデバイスドライバ 51と、装置を制御する装置ドライバ 52に階層化して構成することにより、デバイス 22のデバイスドライバ 51はデバイスメーカ力設備機械 21の装置ドライバ 52 は設備機械メーカが別々に提供することができるという効果を有する。また、異なるデバイス 22を用いたときでも、ドライバのインタフェースの共通化を図ることができる。

[0030] 実施の形態 2.

実施の形態 1では、データ変換装置において、デバイスドライバと装置ドライバとを階層化して構成するようにしていた。しかし、このような分類によるドライバの階層化だけでなく、他の視点カゝらデータ変換装置のドライバを階層化して構成するようにしてもよい。

[0031] 従来、製造管理アプリケーションプログラムは異なる複数のデバイス力製造工程情報を取得し、製造指示を出していた。しかし、設備装置ごとにプロトコルやデータ構造が異なるため、製造管理アプリケーションプログラムが個々の設備装置との通信制御やデータ変換、製造工程を構成する設備装置 2の構成管理をする必要があり、製造管理アプリケーションプログラムの汎用化が困難であった。そこで、この実施の形態 2では、製造管理アプリケーションプログラムを汎用化することが可能なドライバの階層化の他の例について説明する。

[0032] 図 5は、この発明にかかる通信ドライバの実施の形態 2の構成を模式的に示す図である。ここでは、複数の設備装置 2を有する製造システムにおいて、製造管理アプリケーシヨンプログラム 31が複数の設備装置 2を 1つの仮想的な装置（以下、仮想装置という）として認識して処理を行うことができるように、ドライバを階層化して構成したものである。実施の形態 1と同様に、データ変換装置 5には、製造管理システムの製造管理アプリケーションプログラム 31と、設備機械にデバイスが備えられた複数の設備装置 2A, 2Bとがネットワークを介して接続される場合が示されて、る。

[0033] データ変換装置 5は、設備装置 2A, 2Bへのアクセスと通信を司る設備装置 2A, 2 Bごとに設けられる実装置ドライバ 53A, 53Bと、製造管理アプリケーションプログラム 31からの指示 (処理)を個々の設備装置 2A, 2Bの機能に合わせた指示 (処理）に変換して、複数の実装置ドライバ 53A, 53Bを用いて装置データを製造管理アプリケーシヨンプログラム 31に提供する仮想装置ドライバ 54とが、階層化されて構成される。

[0034] ここで、実装置ドライバ 53は、実施の形態 1におけるデバイスドライバ 51と装置ドラィバ 52が組み合わされたものであり、設備機械 21とデバイス 22の組み合わせごと、すなわち設備装置 2ごとにデータ変換装置 5に実装されるものである。この実装置ドラィバ 53も、通信する設備装置 2に対応する 1つ以上の装置オブジェクト 531を有し、さらに装置オブジェクト 531は設備装置 2が有する機能ごとに機能オブジェクト 532を有する。この実装置ドライバ 53は、装置オブジェクト 531の機能オブジェクトのインスタンスと、各設備装置 2の機能とを対応付けたものである。そのため、実装置ドライバ 53は、設備装置 2と通信を行い、設備装置 2へのデータ書込みや設備装置 2からのデータの取得を行うことができる。

[0035] また、仮想装置ドライバ 54は、製造管理アプリケーションプログラム 31が複数の設備装置 2を 1つの仮想装置として扱えるように仮想的に作成したドライバであり、通信する設備装置 2に対応する 1つ以上の仮想装置オブジェクト 541を有し、さらに仮想装置オブジェクト 541は、設備装置 2 (実装置ドライバ 53)の有する機能 211 (機能ォブジェクト 532)に対応する 1つ以上の機能オブジェクト 542を有する。この仮想装置ドライバ 54は、製造管理アプリケーションプログラム 31から設備装置 2へ行われる処理を仮想装置オブジェクト 541の機能オブジェクト 542のインスタンスと、実装置ドライノ 53の有する機能オブジェクト 532のインスタンスとを対応付けたものである。そのため、仮想装置ドライバ 54は、設備装置 2の機能 211に対応する実装置ドライバ 53の機能オブジェクト 532への属性の書込みや読出しを行うことができ、さらに対応するデバイスが実装されている設備装置 2のデータの読書きや操作を行うことができる。

[0036] なお、このような構成のデータ変換装置 5における動作処理は、実施の形態 1の場合と同様なので、ここではその概略を説明する。たとえば結果として得たい処理を実行するための指示が製造管理アプリケーションプログラム 31によって出されると、データ変換装置 5の仮想装置ドライバ 54のその処理に対応する機能オブジェクト 542 力その指示をより具体的な指示に解釈し直して実装置ドライバ 53の対応する機能オブジェクト 532へ渡し、個々の設備装置 2で処理可能な形式の指示 (信号）にさらに変換される。そして、設備装置 2の制御やデータ収集などの所定の処理が実行される。

[0037] つぎに、図 5で示した通信ドライバの階層化のより具体的な例を示す。図 6は、工程管理にドライバの階層化を適用した場合の通信ドライバの構成を模式的に示す図であり、図 7は、工程管理を単位にしてドライバを作成する場合の機能オブジェクトの作成例を示す図である。

[0038] 図 7に示されるように、製造システムの設計情報 41には、製造管理の工程設計に関する工程設計情報 411と製造管理の設備に関する設備仕様 412とがあり、この段階では相互に関連付けがなされていない。その後、ライン設計ツール 42が、 UMLのクラス図に基づ!/ヽてクラス化した工程設計情報 411と設備仕様 412の内容をインスタンス化し、それぞれの情報のインスタンスをマッピングする。具体的には、工程設計情報 411は、工程計画 431としてインスタンス化され、設備仕様 412は、設備構成 432 としてインスタンス化され、それぞれが工程割付 433によって対応付けされる。このような製造管理アプリケーションプログラム 31と設備装置 2との間の工程間の対応付けを行うことで、設備装置 2を工程単位で管理可能なドライバが作成される。また、製造管理アプリケーションプログラム 31からは、複数の設備装置 2を 1つの仮想装置として捉えることが可能となる。

[0039] 図 6の例では、設備機械とこの設備機械を制御するデバイスとの組み合わせ力なる設備装置 2A, 2Bごとに、設備構成 432に基づいて作成された設備ドライバ 55A, 55Bが設けられており、設備ドライバ 55A, 55Bには、設備装置 2A, 2Bが有する機能 211A, 211Bごとに機能オブジェクト 552A, 552Bが作成されている。また、設備ドライバ 55A, 55Bの上位には、工程計画 431に基づいて作成された工程ドライバ 5 6が設けられている。この工程ドライバ 56には、所定の工程ごとに工程モデル 561が作成され、個々の工程モデル 561内には、工程計画 431に含まれる機能を実現する機能オブジェクト 562が作成されている。これらの工程ドライバ 56の機能オブジェクト 562と設備ドライバ 55A, 55Bの機能オブジェクト 552A, 552Bは、それぞれ工程割付 433に基づいて対応付けされており、製造管理アプリケーションプログラム 31からの工程を単位とした指示力工程ドライバ 56と設備ドライバ 55によって、その工程で使用される設備装置 2への指示に落とされて伝達され、その指示に対する応答が製造管理アプリケーションプログラム 31に返される。

[0040] このように、複数の設備装置 2を 1つの仮想装置として認識させるようにする例は、上述した例のほかに、工程管理や在庫管理、リソース管理、品質管理などにも適用することができる。

[0041] なお、上述した図 5における実装置ドライバまたは図 6における設備ドライバを、実施の形態 1のようにさらにデバイスとの間の通信を司るデバイスドライバと、デバイスドライバを使用して装置データを製造管理アプリケーションプログラム 31に提供する装置ドライバとの階層構造として構成するようにしてもょ、。

[0042] この実施の形態 2によれば、階層化したドライバにより、設備装置 2と製造管理アブリケーシヨンプログラム 31とで異なるデータ構造のデータ変換を実現でき、製造管理アプリケーションプログラム 31の汎用化を図ることができるという効果を有する。

[0043] なお、上述した実施の形態 1, 2では、製造管理アプリケーションプログラム 31と設備装置 2との間の通信におけるデータ変換を行う機能を有する階層化したドライバをデータ変換装置 5に備える場合を例に挙げたが、階層化したドライバを、製造管理ァプリケーシヨンプログラム 31を実装する製造管理システム 3側に設けてもよいし、設備装置 2側に設けてもよい。このようにすることで、製造システムにデータ変換装置 5が不要となり、システム構成を簡略ィ匕することができる。

[0044] 実施の形態 3.

実施の形態 1, 2で示した機能オブジェクトへのアクセスを、その種類によらず共通化することによってドライバへのアクセス処理を容易にすることができる。そこで、この実施の形態 3では、ドライバの共通インタフェースとそのアクセス手順の一例について説明する。図 8—1〜図 8— 9は、ドライバの共通インタフェースとそのドライバアクセス手順を模式的に示す図である。このドライバの共通インタフェースは、図 3のドライバモデルとドライバの機能を示す図 4の機能オブジェクトモデルにアクセスして、ォブジェクトを管理したり、データの読書きを行ったり、オペレーションを実行したりする。

[0045] ドライバのアクセス手順は、最初にデバイスや装置オブジェクトをドライバ API (

Application Program Interface)： InitiateDeviceObjectOで初期ィ匕した後（図 8— 1)、機能オブジェクトのインスタンスをドライバ API： CreateFunctionObjectOで生成する（図 8— 2)。これにより、ドライバにアクセスする側は、ドライバの利用可能な機能ォブジェタトを得ることができる。ついで、ドライバ API : SetParameterOで機能オブジェクトにコンフィグレーションなどのパラメータを設定する（図 8— 3)。なお、パラメータとォペレーシヨンは機能オブジェクトからアクセスすることができる力、属性については機能オブジェクトから直接アクセスすることができないので、属性にアクセスするため（データ読書きのため）の属性オブジェクトをドライバ API： CreateAttributeObjectOで生成する（図 8— 4)。その後、生成した機能オブジェクトのオペレーションを呼び出し (ドライノく API : ExecuteO)、オペレーションを実行したり（図 8— 5)、属性の値を読書きして（ドライバ API： ReadO, WriteO)、属性オブジェクトへのアクセスが行われたりする（図 8— 6)。

[0046] その後、ドライバの使用が終了すると、ドライバの終了処理が行われる。まず、属性ォブジェクトをドラィバ八？1 : 06 6 1:1：1* 601^ 0で削除し（図8— 7)、ついで、ドラィバ API： DeleteFunctionObjectOで機能オブジェクトを削除して（図 8— 8)、最後に、ドライバ API : Conclude0でデバイス Z装置オブジェクトを終了する（図 8— 9)。図 8— 9において、ドライバ API : Conclude()は、属性オブジェクトや機能オブジェクトが正常に削除されたかを確認するものであり、システム異常などで、属性オブジェクトや機能オブジェクトが正常終了できないときや即座にドライバを終了するときはドライバ API : AbortOを用ヽる。

[0047] この実施の形態 3によれば、ドライバの共通インタフェースを用いることで、ドライバのアクセス対象に影響しな、ドライバ APIを実現することができ、ドライバソフトウェアのポータビリティ性が向上する。また、ドライバのアクセス対象への固有のアクセス情報はドライバのプロファイルの機能オブジェクトの情報として提供され、プロファイルの機能オブジェクトの情報を基にドライバを初期化し、個々の機能オブジェクトや属性オブジェクトにアクセスすることができる。

[0048] 実施の形態 4.

実施の形態 1, 2で示した階層化された通信ドライバは、実施の形態 2で説明したように、製造システムの設計情報や構成情報を基にして作成される。これらの設計情報や構成情報は、電子データの形態での保存、データの流用のし易さ、データ使用の汎用性などの点から、 XML (extensible Markup Language)などのマークアップ言語で記述される傾向が強い。また、 XML形式で記述されたデータに UMLのクラス図の考えを導入するようにすれば、設計情報や構成情報から容易に機能オブジェクトを作成することが可能となる。そこで、この実施の形態 4では、設計情報や構成情報を、 UMLのクラス図にしたがって分類し、それを XML形式で保存する XMLデータモデルについて説明する。

[0049] 上述したように、製造システムの通信ドライバの機能オブジェクトは、図 4の機能ォブジェクトモデルに基づいて作成されるものである。そこで、設計情報や構成情報を、機能オブジェクトモデルにしたがってその内容を構成し、この構成を XMLで記述した XMLデータモデルを作成する。図 9は、設計情報を XMLプロファイルで記述するための XMLデータモデルを UMLクラス図で記述した一例を示す図である。ここでは、 XML構造を UMLのステレオタイプで記述しており、各ステレオタイプの下にはクラス名を記述している。

[0050] たとえば、〈〈XMLDocument》は XMLデータ全体を表現し、〈〈XSDElement》は X MLスキーマ記述（XSD)の要素を表している。したがって、「XMLDCD」クラスは設計情報の XMLデータ全体を表している。「XMLDCD」クラスの下には、「

DeviceDnverClassJ、「VirtualDeviceし lass」、「Function〇bjectClass」の各グフス力 S階層化されている。これらのクラスは XMLスキーマ記述の要素になる。ここで、「 DeviceDriverClass」は、図 3のデバイスドライバ 51や装置ドライバ 52、図 5の実装置ドライバ 53、仮想装置ドライノ 54などのドライバに相当する。「VirtualDeviceClass」は、図 3のデバイスオブジェクト 511や装置オブジェクト 521、図 5の装置オブジェクト 531 、仮想装置オブジェクト 541などのドライバ内の仮想デバイスに相当する。この「 VirtualDeviceClass」の下位には、「CreateParameterClass」が存在する。「

FunctionObjectClass」は、図 3や図 5の機能オブジェクトを示す。機能オブジェクトは、図 4の機能オブジェクトモデルに示されるように、パラメータ、クリエイトパラメータ、属'性、オペレーションからなり、それぞれ「ParameterClass」、「CreateParameterClass」、「OperationClass」、「AttributeClass」に対応し、その情報がそれぞれのクラスに格納される。これらのクラスは XMLスキーマ記述の要素になる。さらに、「

OperationClassJはノヽフメータを有し、らに下に「OperationParameterClass」を有し、その情報が格納される。このクラスも XMLスキーマ記述の要素になる。

[0051] つまり、この図 9に示されるように、 XMLDCDクラスの下位には DeviceDriverClass、 VirtualDeviceClass、 FunctionObjectClassの各クラスが順に階層化して連なっている。このつち、 VirtualDeviceClassの下には CreateParameterClassか存 7土し、

FunctionubjectClassのこ ί¾、 ParameterClass、 CreateParameterし lass、

OperationClass、 AttributeClassの 4つのクラスが並列して存在する。さらに、このうちの OperationClassの下位には、 OperationParameterClassが存在する。このような、階層構造は、 XMLデータの表記方法に基づいて表現することが可能であり、 UMLにおけるクラス図の関係を、 XMLデータに反映させて記述することができる。

[0052] 図 10は、図 9の設計情報の XMLデータモデルにインスタンス情報モデルを追加した XMLデータモデルの一例を示す図である。図中、左側半分は、図 9で示した UM Lクラス図で記述した設計情報の XMLデータモデルと同一であり、機能オブジェクトのクラス情報を示す。右半分は、機能オブジェクトのインスタンス情報モデルを示している。このインスタンス情報モデルは、機能オブジェクトのクラス情報に対応するインスタンスの情報を記述するものである。具体的には、インスタンス情報モデルは、上述した実施の形態 1, 2のデバイスドライバやデバイスドライバが持つ仮想デバイスの構成情報を格納し、実際の設備装置 2の情報や設備装置 2との対応関係を示すものである。また、インスタンス情報モデルは、階層ドライバが下位のドライバのどの機能ォブジェクトゃ属性に対応しているの力も示すものである。 [0053] この図 10の例では、「DeviceDriver」、「VirtualDevice」、「FunctionObject」、「 CreateParamaterJ、「Attribute」は、それそれ「DeviceDriverClass」、「

virtualDeviceGlassJ、「runctionObjectし lass」、「CreateParamaterCiass」、「

AttributeClass」のインスタンス情報を示している。ここで、インスタンス情報「 DeviceDriverJの自分自身を指す関係はデバイスドライバの階層構成を示す。また、インスタンス情報「VirtualD_evi_ce」の自分自身を指す関係は実装置と実デバイスの構成を示す。たとえば、設備装置を構成しているデバイスを示す。さらに、インスタンス情報「Fun_Cti₀nObj_ect」の自分自身を指す関係は階層ドライバにお、て上位のドライノくから呼ばれる下位のドライバファンクションを示す。また、インスタンス情報「 Attribute]の自分自身を指す関係は階層ドライバにお、て上位のドライバから呼ばれる下位のインスタンス情報「Attribute」を示す。たとえば、デバイスデータを設備装置データに変換したり、設備装置ごとの分散されたデータをまとめたりするデータ変換装置 5のデータ変換の構成情報を示す。

[0054] 図 11は、図 10の XMLデータモデルに基づ、て設計情報と構成情報を記述した一例を示す図である。この図 11の全体力 ¾MLDCDクラスに対応している。そして、この \1し0じ0タグ内のブロック1110では、図 9 (図 10の左側半分）に示されるクラス間の階層関係（包含関係）が記述されている。ここでは、図 9に示されるステレオタイプの下部に記載されたクラス名をタグの名称として使用している。つまり、「

DeviceDriverClassJ内に、「VirtualDeviceClass」が含まれ、さらにこの「

VirtualDeviceClass」内に 1つの「CreateParamaterClass」と 2つの「

FunctionObjectClassJが含まれており、機能オブジェクトのクラスが 2つ生成されている。それぞれの「FunctionObjectClass」内には、さらにパラメータや属性に関するクラスが含まれている。

[0055] 一方、 XMLDCDタグ内のブロック 1120では、ブロック 1110のクラス情報に対応したインスタンス情報が記述されている。ここでは、図 10の右側半分に記載されたインスタンス情報モデルのステレオタイプの下部に記載された名称力 Sタグの名称として使用されている。つまり、「DeviceDriver」内に、「VirtualDevice」が含まれ、さらにこの「 VirtualDevice」内に 1つの「CreateParamater」と、 2つの「FunctionObject」が含まれている。また、これらの「CreateParamater」「FunctionObject」には、属性やパラメータに関する内容が含まれている。

[0056] この図 11に示されるように、ブロック 1110に示されるクラス情報の記述では、作成対象のドライバの機能のパラメータや属性、オペレーションの項目が定義され、ブロック 1120に示されるインスタンス情報の記述では、作成される個々のドライバの種類に応じたパラメータ等の設定が定義される。また、図 10に示されるように、 XMLデータにおけるクラスを示すタグの名称とインスタンス情報を示すタグの名称とが予め対応付けられている。これにより、機能オブジェクトモデルに基づいて分類された設計情報や構成情報の XMLデータは、ドライバによるデータ変換時に参照され、設備装置やデバイスに関して抽象的なまたは共通的な内容のコマンド (処理）が、個々の設備装置またはデバイスに対応した具体的な内容のコマンド (処理)へと変換され、ドライバによる設備装置またはデバイスへのアクセスを可能とする。

[0057] この実施の形態 4によれば、設計情報と構成情報の XMLプロファイルモデルを利用して通信ドライバのデータ変換を行うようにしたので、抽象的なまたは共通的な内容の処理をここの設備装置 2の具体的な内容の処理に変換することが可能となる。また、 XMLデータモデルを使用することによって、ドライバにおけるデータ変 «能の作成を支援または自動化することができる。

[0058] 実施の形態 5.

デバイスドライバと設備装置のデバイスの間のプロトコルインタフェースは、たとえば、OMG (Object Management Group)の CORBA (Common Object Request Broker Architecture)やマイクロソフトの DCOM (Distributed Component Object Model)などの通信プロトコルにしたがって、インタフェース記述言語（以下、 IDL ( Interface Definition Language)という）によって記述される。しかし、この IDLは、インスタンス情報を記述できず、またインスタンス情報を記述できるように拡張することもできない。そこで、この実施の形態 5では、 IDLを XMLとマッピングして、 IDLでもインスタンス情報を記述することができる通信ドライバについて説明する。

[0059] 図 12は、 IDLと XMLデータの設計情報についてのマッピングモデルの一例を示す図である。この図 12の左側半分は図 9に示した XMLデータモデルと同一のものであり、右側半分は、 IDLの記述モデルを UMLのクラス図に基づいてクラス化して示したものである。 IDLDCDクラスは、設計情報の IDLデータ全体を表している。 IDLDCDクラスの下には、「module」クラスが存在し、この「module」クラスの下には「interface」クラスと「CreateParam」クラスが存在する。また、「interface」クラスの下には、「

CreateParam」クラス、「parameter」クラス、「Attribute」クラス、「Operation」クラスが存在し、「Operation」クラスの下にはさらに「OperationParameter」クラスが存在する。これらの IDLDCDクラス、「module」クラス、「interface」クラス、「CreateParam」クラス、「し reatePramaJ ;^フス、「 & ]11& 61¹」クフス、「 ^1^113 6」クフス、「0 6 1：10 クフスおよび「OperationParameter」クラスは、 XMLデータモデノレの「DeviceDriverClass」、「 VirtualDeviceGlassJ、「FunctionObjectし lass」、「CreateParameterし lass」、「

ParameterClass」、「AttributeClass」、「OperationClass」および「

OperationParameterClassJにそれぞれ対応付け（マッピング）される。

[0060] この図 12と図 8により、 IDLの記述内容は、 XMLデータモデルのクラスへの対応付けを行うことができ、さらにこの XMLデータモデルのクラス力も個々の設備装置に対応したインスタンス情報を参照することができる。

[0061] つぎに、このような通信ドライバのプロトコルインタフェース部分の作成方法について説明する。図 13は、インスタンス情報を参照することができる通信ドライバのプロトコルインタフェース部分の作成手順と設定手順の一例を示す図である。まず、製造システム (または個々のデバイスや設備装置)の作成者によって、工程や設備装置、デバイスなどのドライバのアクセス対象のモデルのインタフェース情報を基に、アクセス対象の一般的な性質を示す情報である XMLプロファイルのクラス情報が記述される (ステップ S 11)。図 14は、インタフェース情報の XMLプロファイルの記述の一例を示す図である。

[0062] ついで、記述された XMLプロファイルのクラス情報を、図 12に示される IDLと XML データのマッピングモデルを実行するプログラムなどによって、自動的に IDLの記述に変換する（ステップ S 12)。図 15は、 IDLインタフェース部分の XMLプロファイルの記述パターンの一例を示す図であり、図 16は、 IDLデータタイプ宣言の XMLプロフアイルでの記述規則の一例を示す図である。これらの図の左側には XMLプロフアイルの記述例が示されており、その右側には、対応する内容を図 12のモデルにしたがつて IDL記述した例が示されている。図 16のデータタイプ宣言はデータの実装に依存するために、 IDLデータタイプ宣言自体を XMLプロファイルで記述できるようにしている。なお、 WSDL (Web Services Description Language)などの XMLベースのインタフェース記述言語を使用する場合には、そのまま XMLデータタイプを用いるようにすればょ、。これらの図 15と図 16に示される XMLプロファイル IDLマッピング規則にしたがって、 XMLプロファイルのクラス情報の記述が IDL記述に変換される。図 17は、図 14の XMLプロファイルのクラス情報の記述に対応する IDL記述の一例を示す図である。

[0063] その後、従来公知の方法によって、ドライバソフトウェアのプラットフォーム（ォペレ一ティングシステムなど）に合わせて、変換された IDL記述力 C+ +クラスが生成され (ステップ S13)、ドライバが実装される。

[0064] 一方、実装されたドライバのアクセス対象のコンフィグレーション設定は、 XMLプロファイルのクラス情報の記述をコンフィグレーション設定ソフトウェアなどのコンフィグレーシヨン設定手段によって読込まれ、コンフィグレーション情報のテンプレートが作成される。このテンプレートは、 XMLプロファイルのクラス情報とインスタンス情報とを対応付けた図 10に示される XMLデータモデルにしたがって作成される。そして、このテンプレートにしたがって、個々の設備装置についてのインスタンス情報を示すコンフィグレーシヨン情報が設定される (ステップ S14)。設定されるコンフィグレーション情報は、 XMLプロファイルのインスタンス情報として XMLで記述され、ドライバ起動時に読込まれる。

[0065] 以上のようにして、プロトコルインタフェース部分を含む通信ドライバが作成される。

以上の手順によって作成され、実装されたドライバは、読込んだコンフィグレーション情報のインスタンス情報力必要とするオブジェクトを生成したり、アプリケーションォブジエタトの情報を提供したりする。また、製造管理アプリケーションプログラムは、コンフィグレーシヨン情報を直接読込む力、ドライノくからオブジェクト情報を取得してドラィバを初期化し、アクセス対象にアクセスする。

[0066] なお、ステップ S12の IDL記述とステップ S13の C+ +クラス生成との間は、従来公知の方法で相互に変換可能であり、また、ステップ S 11の XMLプロファイルのクラス記述と、ステップ S12の IDL記述との間も、上述した図 12や図 15、図 16に示される X MLプロファイル— IDLのマッピング規則に基づいて相互に変換することができる。そのため、製造システム (または個々のデバイスや設備装置）の作成者は、ステップ S1 2の IDL記述を最初に行ってから、ステップ S13の C+ +クラスの作成からドライバを実装し、ステップ Sl l, S 14の XMLプロファイルのクラス記述から XMLプロファイルのインスタンス記述を行ってドライバに読込ませるようにしてもよい。また、既に C+ + クラスで実装されているドライバに関して、ステップ S12で C+ +クラスを IDL記述に変換し、また、ステップ S 11で XMLプロファイルのクラス情報に記述し、さらに、 XML プロファイルのインスタンス記述を行って、プロトコルインタフェース部分を含む通信ドライバを作成してもよい。

[0067] この実施の形態 5によれば、 IDLはオブジェクトのインタフェースのタイプを示しているだけで、インスタンス化したオダジェタトの構成を記述することができないが、 XML でオブジェクトのインタフェースとインスタンスの構成を記述することで、製造管理アブリケーシヨンに製造システムを構成する設備装置とその機能オブジェクトのインタフエースと構成情報を提供することができ、製造アプリケーションが製造装置へアクセスするための設定を支援、あるいは自動化することができる効果を有する。また、その際に必要となるデータ変換のためのマッピング構成を記述することができる。

[0068] また、ドライバの共通化を実現することができ、それによりドライバの開発も効率化される。さらに、従来個別に作成していたコンフィグレーション設定ソフトウェアも共通化することができる。

[0069] なお、上述した実施の形態 4, 5では、ドライバのクラス情報とインスタンス情報を記述するデータモデルとして XMLを用いた力 XMLに限られる趣旨ではなぐ図 10に示されるデータモデルにしたがってデータ内容を記述することができるものであればよい。

産業上の利用可能性

[0070] 以上のように、この発明にかかる通信ドライバは、たとえば製造工場における搬送設備機械や製造設備機械、検査設備機械などのそれぞれの設備機械を制御する制御部を備えた設備装置との間で通信されるデータの変換に適している。

Claims

請求の範囲

[1] 所定の処理を行う設備機械に、管理装置からの指示に基づいて前記設備機械を制御するデバイスが設けられた設備装置と、前記設備装置を管理する管理アプリケーシヨンプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーションプログラムからの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、

前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、

前記製造システムに設けられる前記設備機械の種類ごとに設けられ、前記管理ァプリケーシヨンプログラム力の指示にしたがって、前記デバイスドライバを使用して対象となる前記設備機械にアクセスする装置ドライバと、

を備え、前記デバイスドライバと前記装置ドライバが階層化されて構成されることを特徴とする通信ドライバ。

[2] 前記デバイスドライバと前記装置ドライバは、それぞれのドライバに対応する前記デバイスと前記設備機械の有する機能ごとに、所定のパラメータと属性とオペレーションを有する様に作成した機能オブジェクトによって作成されることを特徴とする請求項 1 に記載の通信ドライバ。

[3] 前記機能オブジェクトは、該機能オブジェクトの有する属性にアクセスするための属性オブジェクトをさらに含むことを特徴とする請求項 2に記載の通信ドライバ。

[4] 前記デバイスドライバと前記装置ドライバは、前記機能オブジェクトの種類によらな V、で、それぞれの前記機能オブジェクトへアクセス可能な抽象化したドライバアプリケーシヨンインタフェースを備えることを特徴とする請求項 2に記載の通信ドライバ。

[5] 前記デバイスドライバと前記装置ドライバは、前記機能オブジェクト中の前記属性ォブジエタトの種類によらな、で、それぞれの前記属性オブジェクトへアクセス可能な抽象化したドライバアプリケーションインタフェースを備えることを特徴とする請求項 3に記載の通信ドライバ。

[6] 前記デバイスドライバまたは前記装置ドライバの有する機能の内容を、前記機能ォブジエタトのモデルにしたがって記述したクラス情報とし、個々の前記デバイスドライバまたは前記装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがってマークアップ言語で記述されることを特徴とする請求項 2に記載の通信ドライバ。

[7] 前記デバイスドライバまたは前記装置ドライバは、前記機能オブジェクトの通信インタフエースをインタフェース記述言語で記述した記述内容をインタフェース記述言語の記述モデルに基づいて分類したクラス情報と前記データモデルのクラス情報とをマッビングし、このマッピング結果と前記データモデル力得られる前記機能オブジェクトに対応するインスタンスを含むコンフィグレーション情報を参照して、通信されるデータの処理を行うことを特徴とする請求項 6に記載の通信ドライバ。

[8] 所定の処理を行う複数の設備装置と、前記設備装置を管理する管理アプリケーションプログラムを有する管理装置と、がネットワークを介して接続され、前記管理アプリケーシヨンプログラムからの出力を、前記設備装置で処理可能な形式に変換して所定の処理を前記設備装置に実行させる製造システムで、前記管理装置と前記設備装置との間で通信されるデータの変換を行う通信ドライバであって、

前記管理アプリケーションプログラムに、前記複数の設備装置を 1つの仮想的な装置として見せる仮想装置ドライバと、

前記設備装置ごとに設けられ、前記設備装置との間の通信を司るとともに、前記仮想装置ドライノからの指示にしたがって、対象となる前記設備装置にアクセスする設備装置ドライバと、

を備え、前記仮想ドライバと前記設備装置ドライバが階層化されて構成されることを特徴とする通信ドライバ。

[9] 前記仮想装置ドライバは、前記設備装置の仕様に基づ!ヽて前記設備装置で実行される処理を、前記製造システムの工程設計情報に基づ、て前記製造システムで実行される工程に関連付けて管理することを特徴とする請求項 8に記載の通信ドライバ

[10] 前記設備装置ドライバは、対応する前記設備装置の有する機能ごとに、所定のパラメータと属性とオペレーションを有する様に作成した機能オブジェクトによって作成され、

前記仮想装置ドライバは、前記製造システムに設けられる前記設備装置の有する機能を抽象化した機能ごとに、所定のパラメータと属性を有する様に作成した機能ォブジェクトによって作成されることを特徴とする請求項 8に記載の通信ドライバ。

[11] 前記機能オブジェクトは、該機能オブジェクトの有する属性にアクセスするための属性オブジェクトをさらに含むことを特徴とする請求項 10に記載の通信ドライバ。

[12] 前記仮想装置ドライバと前記設備装置ドライバは、前記機能オブジェクトの種類によらな、で、それぞれの前記機能オブジェクトへアクセス可能な抽象化したドライバァプリケーシヨンインタフェースを備えることを特徴とする請求項 10に記載の通信ドライバ。

[13] 前記仮想装置ドライバと前記設備装置ドライバは、前記機能オブジェクト中の前記属性オブジェクトの種類によらな、で、それぞれの前記属性オブジェクトへアクセス可能な抽象化したドライバアプリケーションインタフェースを備えることを特徴とする請求項 11に記載の通信ドライバ。

[14] 前記仮想装置ドライバまたは前記設備装置ドライバの有する機能の内容を、前記機能オブジェクトのモデルにしたがって記述したクラス情報とし、個々の前記仮想装置ドライバまたは前記設備装置ドライバについての設定値を前記クラス情報に対応付けて分類したものをインスタンス情報とするデータモデルにしたがってマークアップ言語で記述されることを特徴とする請求項 10に記載の通信ドライバ。

[15] 前記ドライバは、前記機能オブジェクトの通信インタフェースをインタフェース記述言語で記述した記述内容をインタフェース記述言語の記述モデルに基づいて分類したクラス情報と前記データモデルのクラス情報とをマッピングし、このマッピング結果と前記データモデルカゝら得られる前記機能オブジェクトに対応するインスタンスを含むコンフィグレーション情報を参照して、通信されるデータの処理を行うことを特徴とする請求項 14に記載の通信ドライバ。

[16] 前記設備装置は、所定の処理を行う設備機械と、前記管理装置からの指示に基づ V、て前記設備機械を制御するデバイスとから構成され、

前記設備装置ドライバは、前記製造システムに設けられる前記デバイスの種類ごとに設けられ、前記デバイスとの間の通信を司るデバイスドライバと、

を備え、前記デバイスドライバと前記装置ドライバが階層化されて構成されることを特徴とする請求項 8に記載の通信ドライバ。