JPH07146844A - 製造装置の制御および調整を行う統合オートメーション開発システムおよび方法 - Google Patents

Abstract

(57)【要約】 【目的】 製造装置の制御および調整を行う統合オート
メーション開発システムを提供する。 【構成】 製造装置２４の制御および調整を行う統合オ
ートメーション開発システム１０は複数のサーバプロセ
ス（１４，１６，２２，２８，３４，３６）を使用す
る。各サーバプロセスはＡＳＣＩＩメッセージを受信す
るためのメッセージマネジャー（４５）、および受信さ
れたＡＳＣＩＩメッセージを評価してメッセージ内のコ
マンドを識別するインタプリタ（４３）を含んでいる。
サーバプロセスは更にコマンドを受信して実行するコマ
ンドマネジャー（４１）、およびコマンドマネジャー
（４１）によるコマンド実行の論理フローを管理するロ
ジックコントローラ（４７）を含んでいる。サーバは、
該サーバがキューサーバ（３４）、端末サーバ（２
８）、および他の特定用途サーバプロセスとして動作で
きるようにするための付加的コマンド（４８）を含むこ
とも可能である。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は一般的にオートメーショ
ンシステムの分野に関する。特に本発明は統合オートメ
ーション開発システムおよび方法に関する。

【０００２】

【従来の技術】オートメーションのタスクでは、共通目
標に到達するために、数多くのエンティティ（ｅｎｔｉ
ｔｙ）の調整制御が必要とされる特徴がある。このタス
クは、オートメーション環境および要求の性質から、複
雑なものとなる。オートメーションエンティティは工場
装置、ローカルエリアネットワーク、データベースおよ
びユーザ端末等の実在のものであったり、データ、制御
ソフトウェア、および通信メッセージおよびプロトコル
等の抽象的なものであったりする。

【０００３】

【発明が解決しようとする課題】オートメーション統合
において第１に困難なことは、通信である。典型的に
は、オートメーションエンティティは互いに直接通信を
行うことはできず、エンティティ間通信のためのインタ
ーフェイスが必要である。しかしながら、エンティティ
ＸおよびＹ間の通信のためのインターフェイスα、エン
ティティＹおよびＺ間の通信のためのインターフェイス
β、およびエンティティＺおよびＸ間の通信のためのイ
ンターフェイスγ等を定式化しても解決策とはならない
ことは明白である。このようなシステムでは最初のシス
テム構築と後の再構築のために重複した努力が必要とさ
れる。

【０００４】オートメーション統合タスクはまた頻繁な
システムの再構築および変更を容易にするものでなけれ
ばならない。処理ラインやセルに対して装置がしばしば
付加もしくは省略され、自動化された処理ラインやセル
が頻繁に再構築されることがある。従って、オートメー
ションシステムはこのような変更に容易に対処しなけれ
ばならない。

【０００５】また、典型的なオートメーションシステム
では、多くのエンティティによって実行される複数のタ
スクは並行して実行される。従って、オートメーション
システムはこの要求に応えるために、並行実行の機能を
かね備えていなければならない。

【０００６】

【課題を解決するための手段】本発明により従来技術に
付随する欠点や問題点を実質的に解消もしくは低減する
統合オートメーション開発システムおよび方法が提供さ
れる。

【０００７】本発明の一つの特徴として、製造装置の制
御および調整を行う統合オートメーション開発システム
は、複数のサーバプロセスを使用する。各サーバプロセ
スにはＡＳＣＩＩメッセージを受信するメッセージマネ
ジャーおよび受信したＡＳＣＩＩメッセージを評価して
メッセージ内のコマンドを識別するインタープリタが含
まれている。サーバプロセスにはさらにコマンドを受信
して実行するコマンドマネジャーと、コマンドマネジャ
ーによるコマンド実行の論理フローを管理するロジック
コントローラ（ｌｏｇｉｃ ｃｏｎｔｒｏｌｌｅｒ）も
含まれている。サーバは、該サーバをキューサーバ（ｑ
ｕｅｕｅ ｓｅｒｖｅｒ）、端末サーバ、および他の特
定用途（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ）
サーバプロセスとして使用できるようにする付加的特定
用途コマンドを含むことができる。

【０００８】本発明のもう一つの特徴として、製造装置
の制御および調整を行うオートメーション開発システム
の統合方法が提供される。この方法は他のサーバおよび
クライアントプロセスからのＡＳＣＩＩメッセージを検
査して受信し、テキストベースのプログラミング言語で
表現された少くとも一つのコマンドを含む受信されたＡ
ＳＣＩＩメッセージを評価し、ＡＳＣＩＩメッセージ内
のコマンドを認識する、ステップを含んでいる。コマン
ドが実行された後、サーバプロセスはＡＳＣＩＩメッセ
ージの検査へ戻る。

【０００９】本発明の更にもう一つの特徴として、統合
オートメーション開発システムはコマンドを含むメッセ
ージを発生する制御クライアントを含んでいる。製造装
置とのインターフェイスとして働く装置サーバは制御ク
ライアントプロセスからメッセージを受信し、メッセー
ジ内のコマンドで指示されるように製造装置を制御し、
それに応答してメッセージを発生する。制御クライアン
トと装置サーバとの間でメッセージのルーチング（ｒｏ
ｕｔｉｎｇ）を行えるようにするキューサーバ（ｑｕｅ
ｕｅ ｓｅｒｖｅｒ）も設けられている。

【００１０】

【実施例】図面に関し、図１に一般的に符号１０で示さ
れ、本発明の教示に従って構成されている、統合オート
メーション開発システムおよび方法の実施例を示す。図
示するように、統合オートメーション開発システム１０
は一般的に、システムのモジュール性およびモジュール
間の通信方法を定義するクライアントサーバモデルに基
いている。システム１０はクライアントおよびサーバと
呼ばれる一群の協同タスクにより構成されている。図１
において、グラフィック制御クライアント１４はＳＭＳ
（半導体製造システム）サーバ１６、装置サーバ２２、
および端末サーバ２８と協同機能する。さらに、付加的
サーバである、キューサーバ３４および時間サーバ３６
によりシステムの全体機能に必要なタスクが実行され
る。

【００１１】サーバは一般的にシステム内の実在のもし
くは抽象的なオブジェクトもしくはエンティティ（ｅｎ
ｔｉｔｙ）を管理制御する。サーバは、コマンド要求に
応答することにより、そのクライアントとのハイレベル
なメッセージインターフェイスを提供する。例えば、装
置サーバ２２は工場装置２４とのインターフェイスを提
供し、ＳＭＳサーバ１６は工場ホストシステム（半導体
製造システム２０）とのインターフェイスを提供し、端
末サーバ２８はオペレータ端末３０および端末３０にお
いて実行中のアプリケーションソフトウェアとのインタ
ーフェイスを提供する。

【００１２】一方、グラフィック制御クライアント１４
はサーバより下位に位置するオブジェクトもしくはエン
ティティの機能へアクセスするためにサーバ１６，２
２，２８へコマンド要求を送る、システム１０内のタス
クである。したがって、オートメーションは一群のオブ
ジェクトをそれらのサーバを介して調整および制御する
ことにより行われる。制御オブジェクト自体はクライア
ントプロセスとして実現される抽象的なエンティティで
ある。

【００１３】一般的に、サーバシステム内の高水準オブ
ジェクトを表わす他のサーバに関する情報と予め有して
いない。例えば、装置サーバ２２は工場ホストサーバ１
６へコマンドを送ってはならない。それは、特定の工場
ホスト１６およびそのコマンドシンタクスに関する不要
な依存性が装置サーバ２２内に組み込まれるからであ
る。そのような統合的な機能は、例えばグラフィック制
御クライアント１４等の制御クライアントにより処理さ
れるべきものである。

【００１４】図２を参照して、サーバ１６，２２，２
８，３４，３６およびクライアント１４は、サーバ４０
と呼ばれる一般的構造により表現することができる。各
サーバ４０はサーバシェル４２と呼ばれる予め存在する
ソフトウェアに、特定用途コードおよびコマンド４８を
付加して生成される。これらのサーバシェル４２は始動
時にテキストファイルにより構築されて一意的なアプリ
ケーションサーバおよびクライアントを生成する実行可
能ファイルである。スクリプトシェルライクな言語とも
呼ばれる解釈されたテキストベースのプログラミング言
語で表現されたコマンドを実行時にロードするか、もし
くはコンパイル時にＣ＋＋コマンドをリンクすることに
より、サーバシェル４２は好ましくはアプリケーション
プログラムとして構築される。好ましくは、サーバシェ
ル４２は２つの基本的なビルディングブロック、基準コ
ード４４および共通コマンド４６を含んでいる。従っ
て、新しいアプリケーションサーバが必要とされる場合
には、そのインプリメンテーションは、特定用途コード
がその上に形成される、サーバシェル４２から開始され
る。

【００１５】図３を参照して、さまざまな主機能成分を
有するサーバプロセス４０を示す。サーバ４０にはサー
バシェル４２および付加的特定用途コマンドおよびコー
ドマネジャー４８が含まれている。サーバシェル４２自
体が基本的タスクを実行するための多くの機能モジュー
ルを含んでいる。サーバシェル４２はコマンドに対する
プロセスレベルのオペレーティングシステムとして機能
するコマンドマネジャーすなわち共通コマンドモジュー
ル４１を含んでいる。コマンドマネジャー４１はコマン
ド要求の実行を管理制御してデータ記憶およびイベント
記録機能を提供する。サーバシェル４２は装置サーバ２
２、端末サーバ２８、およびキューサーバ３４等の実際
のアプリケーションサーバもしくはクライアントを構築
するための基礎にすぎない。サーバシェル４２には特定
のアプリケーションの開発を容易にするコマンドが含ま
れている。この機構はオートメーション開発システム１
０のモジュール性および再構築性に寄与する。

【００１６】サーバシェル４２にはスクリプトもしくは
シェルライクな言語インタプリタ４３も含まれ、実行中
に、スクリプト言語により新しいコマンドを生成するこ
とができる。スクリプト言語はＵＮＩＸオペレーティン
グシステム環境になじみのある人ならば一般的に理解で
きる、包括的ハイレベルシェルライクコードとすること
ができる。スクリプト言語には条件文、ループ構造、表
現評価（ｅｘｐｒｅｓｓｉｏｎ ｅｖａｌｕａｔｉｏ
ｎ）および環境変数を含むことができる。Ｃ＋＋言語で
はなくスクリプト言語を使用すれば、例えば、スクリプ
ト言語はラインごとに解釈されるため、実行する前にコ
ードを再コンパイルおよび再リンクする必要がなくな
る。解釈中に、スクリプト言語インタプリタ４３は本質
的にスクリプト言語のエントリを受け取ってそれらをサ
ーバが理解可能でアクセス可能な、動的変数の構造体へ
変換する。

【００１７】サーバシェル４２には更にメッセージマネ
ジャー４５が含まれている。メッセージマネジャー４５
はメッセージシンタクス（ｓｙｎｔａｘ）検証およびル
ーチング（ｒｏｕｔｉｎｇ）等のメッセージ通信関連タ
スクを実行する。また、サーバシェル４２によりサーバ
４０の基本制御および論理フローを管理するシェルロジ
ックコントローラ（ｓｈｅｌｌ ｌｏｇｉｃ ｃｏｎｔ
ｒｏｌｌｅｒ）４７も提供される。付加的な、動的変数
マネジャー４９は図４に示す動的変数の構造体の記憶お
よびアクセスを監督するように働く。メッセージマネジ
ャー４５、シェルサーバロジックコントローラ４７、お
よび動的変数マネジャーの機能については後記する。

【００１８】付加的特定用途コマンド４８はサーバやそ
のオブジェクトに対してアクションを実行したりその状
態を変える。同じシェルからスタートした実行可能サー
バは実行時にテキストセグメント又はコードを共有する
ことができ、従って実行時のメモリ使用が低減される。
例えば、実行可能な同じ端末サーバシェルへコンフィグ
レーションファイルをロードして生成される８つのオペ
レータインターフェイスは、実行時に実際の端末サーバ
シェルコードを一つしか使用しない。各プロセスはメモ
リ内に独立したデータエリアを維持することができる
が、メモリ内の同じ実行可能コードブロックを使用す
る。

【００１９】図４に動的変数データ構造体の例を示す。
サーバ４０内で、コマンドは動的記号テキスト変数のこ
の内部階層を介してデータを共有する。取り決めによ
り、サーバ４０の状態はこれらの変数により定義され
る。したがって、統合オートメーション開発システム１
０におけるプログラミングは主として動的変数を操作し
てメッセージを送ることから構成される。アルゴリズム
の複雑度はその下位に位置するデータの構造に依ること
が多い。動的変数４９により、開発者は明確なアルゴリ
ズムのあるデータ表現の構築を奨励される。次にスクリ
プト言語により表現される動的変数の例を示す。

【表１】 上記例は図４にグラフィック表示されている。例えば、
動的変数構造体４９はサーバ名が“ＥＱＵＩＰＡ”であ
り、ある温度もしくは、３つの位置（ＬＯＣＡ，ＬＯＣ
Ｂ，ＬＯＣＣ）の“ＴＥＭＰ”測定値を監視記録してい
ることを示している。また、動的変数４９の状態から、
この装置サーバはその“ＳＹＳ＞ＰＲＯＴＯＣＯＬ”動
的変数の値によりＳＥＣＳ（ＳＥＭＩ Ｅｑｕｉｐｍｅ
ｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒ
ｄ）フォーマットのメッセージを処理できることも判
る。従って、動的変数４９は、各々のサーバプロセス４
０に対して、容易にアクセス可能な、データもしくは変
数の規則正しく階層的な構成を提供する。

【００２０】図５にクライアントとサーバ間の通信方式
を示す。クライアント５２は特定タスクを行うために、
リソース６２を必要としている。クライアント５２はコ
マンド要求メッセージ５６をサーバ５４へ送ってこの要
求を伝え、サーバ５４は応答およびオプショナルなデー
タメッセージ５８もしくは６０により応答する。全ての
メッセージが読取可能なＡＳＣＩＩ文字列により構成さ
れる。データメッセージ６０はコマンドでも応答でもな
いメッセージとして定義される。データメッセージはコ
マンドメッセージ５６に対する応答を送った後で、クラ
イアント５２へデータを送るのに使用される。したがっ
て、サーバ５４はリソースすなわちオブジェクト６２と
のインターフェイスに相当する。このコマンド駆動交換
によりオートメーション開発システム１０内の全てのア
クションが支配される。したがって、メッセージが到来
する結果、リソース６２内もしくはリソース６２により
アクションが発生する。入力されるメッセージは全て一
旦メッセージキュー内に記憶される。メッセージはＦＩ
ＦＯ（ｆｉｒｓｔ−ｉｎ−ｆｉｒｓｔ−ｏｕｔ）形式で
キューから読み取られる。システム１０内のメッセージ
キューの管理はキューサーバ３４により実行され、その
詳細については後記する。

【００２１】図６に別の通信方式７０を示す。クライア
ント７２はコマンド７６を送ってサーバ７４と通信を行
い、サーバ７４は応答７８により応答する。これは、応
答メッセージ５８もしくはデータメッセージ６０として
も良い（図５）。サーバ７４はクライアント７２が要求
するタスクを実行するためのリソース８０を有すること
ができ、あるいは他のサーバ８２に対するクライアント
として動作することができ、サーバ８２はコマンド８６
を受信して応答８８およびそのリソース８４が実行する
適切なアクションにより応答する。更に、サーバ７４は
サーバが使用するメッセージプロトコルを使用しない、
エンティティもしくはサブシステムとのインターフェイ
スを有することもできる。

【００２２】サーバシェル基本機能について説明してき
たので、サーバシェル上に形成されるサーバについて検
討するのが有益である。例えば、キューサーバ３４はオ
ートメーション開発システムの動作にとってきわめて重
大なサーバ４０である。システム１０内の全てのクライ
アントおよびサーバプロセス間でトランスペアレントな
通信を行うために、キューサーバ３４は指定されたメッ
セージキューのテーブルを管理し、統合オートメーショ
ン開発システム１０内の通信を監督する。キューサーバ
３４はクライアントおよびサーバプロセスがより高次レ
ベルの通信を行うことができるようにする低水準メッセ
ージインターフェイスを提供する。

【００２３】キューサーバの主要な機能は、例えば時間
サーバ３６およびＳＭＳサーバ１６等のＡＳＣＩＩ名
に、ＵＮＩＸや類似のオペレーティングシステム等のオ
ペレーティングシステムにより割り当てられるキュー識
別番号やキーを関連づけることである。これによりシス
テム内のサーバは、キュー識別番号の替りに周知の名称
により、互いに参照することができる。キュー名テーブ
ルおよび対応するオペレーティングシステムキュー識別
番号を記憶する必要があるのはキューサーバ３４だけで
ある。

【００２４】図７にサーバＡ９０およびサーバＢ９１を
有するメッセージプロトコルを示す。サーバＡおよびＢ
は共に、矢符９２および９３で示すように、起動すると
キューサーバ３４に記録もしくは登録を行う。次にキュ
ーサーバ３４は、テーブル内にプロセスもしくはサーバ
名を記録し、必要に応じて各サーバ９０および９１へキ
ューＩＤすなわち識別番号を割り当てる。キューサーバ
３４はまた、各サーバプロセス９０および９１に対する
キュー９４および９５が未だ存在していなければ、それ
らを生成し、次に矢符９６および９７で示すように新た
に始動したプロセス９０および９１へキューの識別番号
を返す。次に新しいプロセスＡ９０およびＢ９１はそれ
ぞれのキュー９４および９５を使用してメッセージを受
信することができる。したがって、キュー識別番号の使
用はシステムに対してトランスペアレントである。

【００２５】サーバＡ９０が例えばサーバＢ９１へメッ
セージを送りたい場合には、矢符９８で示すように、サ
ーバＢのキュー名を与えることによりキューサーバ３４
にサーバＢのキューＩＤをたずねる。次にキューサーバ
３４はそのテーブルでサーバＢの名前を調べ、矢符９９
で示すように対応するキューＩＤをサーバＡ９０へ返
す。次にサーバＡ９０はサーバＢのキューＩＤを使用し
て、矢符１００で示すように、サーバＢのキュー９５へ
メッセージを送ることができる。好ましくは、各サーバ
プロセスは他のサーバプロセスの名前および対応するＩ
Ｄ情報をローカルテーブルに保持し、他のプロセスへメ
ッセージを送るたびにキューサーバ３４に問い合せる必
要をなくすようにする。

【００２６】サーバの終了時にプロセスがシステム１０
からそのキューを削除するようキューサーバ３４に要求
しないかぎり、キューサーバ３４は将来使用するために
キュー名およびＩＤをそのテーブル内に保持する。これ
によりプロセスは一時的に終了ししかも他のプロセスが
そのキューにメッセージを置くことができる。プロセス
が再開してキューサーバにより記録されると、それは既
存のキューＩＤに割り当てられる。次にプロセスはダウ
ン時にそのキューに累積された任意のメッセージを読み
取って、それに応答することができる。したがって、寿
命の短いクライアントだけが終了時にキューを削去する
のが望ましい。

【００２７】キューサーバ３４はシステム１０内の全サ
ーバおよびクライアントに対するキュー管理を行うた
め、任意のプロセスが始動するまでバックグラウンドプ
ロセスとして稼動していなければならない。キューサー
バ３４はコマンドラインを介して適切なコマンドを入力
することにより手動で始動することもできるが、ＣＰＵ
が始動もしくは再ブートする時は常に自動始動すること
が望ましい。

【００２８】図２および図７の他に図８に、コマンドメ
ッセージ処理の基本フローを示す。システム１０内の実
質的に全てのアクションがメッセージ駆動であるため、
例えばサーバＢ９１はブロック１０１に示すように、ま
ずそのキュー９５を調べて到来メッセージを検出する。
メッセージはクライアントや他のサーバから発行され
る、アクションを引き出すためのコマンドを含んでい
る。サーバＢ９１のサーバシェル４２は、ブロック１０
３および１０４に示すように、メッセージをフィールド
へ復号又は構文解析し、コマンドリスト１０２内のメッ
セージに指定されたコマンドを捜し出す。コマンドリス
ト１０２はそのサーバが実行することのできる全コマン
ドすなわちアクションを表わしている。

【００２９】更に、コマンドリスト１０２は、コマンド
のパラメータを含めた正しいシンタクス、および指定さ
れたコマンドのタスクを実施するコードの位置を指定す
る。従って、ブロック１０５に示すように、サーバシェ
ル４２は必要に応じてメッセージ内のコマンドシンタク
スを検証する。前述したように、統合オートメーション
システム１０で使用されるメッセージは明確かつフレキ
シブルなフォーマットの読取可能なＡＳＣＩＩ文字列と
して構成される。次にサーバシェル４２は名前もしくは
特殊ルーチングパラメータに基いてメッセージをコマン
ドコードへルーチングする。ブロック１０６に示すよう
に、メッセージを入力として使用して、コマンドコード
が実行される。コードの実行後、サーバシェル４２はブ
ロック１０７に示すように必要に応じて応答メッセージ
を発生する。応答メッセージはクライアントから送られ
るコマンドメッセージに対する応答としてサーバからク
ライアントへ戻されるメッセージである。

【００３０】サーバ５４およびクライアント５２間のメ
ッセージはキュー名によりルーチングされる。キューサ
ーバ３４（図１）はキュー名の集合を管理し他の全ての
クライアント５２およびサーバ５４が互いにメッセージ
を送るのに使用される。サーバ５４内で、メッセージは
コマンド名やメッセージ文脈によりルーチングされる。
サーバ５４がコマンドメッセージを受信すると、与えら
れるコマンド名に基いてアクションがとられる。

【００３１】メッセージ文脈すなわち“ｃｔｘｔ＝”は
クライアント５２からのコマンドメッセージ内に配置さ
れた一意的な識別子である。このサーバ５４はこのメッ
セージ文脈識別子を保存して、任意の応答やデータメッ
セージに戻さなければならない。２つ以上のサーバ５４
へいくつかの同様なコマンドが送出されていても、応答
およびデータメッセージ内のメッセージ文脈によりクラ
イアント５２は到来する結果を識別することができる。

【００３２】前述したように、好ましくはオートメーシ
ョン開発システム１０内の全メッセージがＡＳＣＩＩテ
キスト文字列である。これらのテキスト文字列は文字列
フォーマットで表現できる任意のデータを含むことがで
きる。メッセージ内のデータの個別アイテムは空白、行
送り、改行、およびタブを含む空白により分離されてい
る。これらのデータ項目は、パラメータ或いはフィール
ドであり、２つのカテゴリーすなわちタグ付き、タグ無
しに分けられる。タグ付パラメータは、等号＝により分
離されたタグとデータ或いは値からなり、タグ無しパラ
メータは等号を含まないデータ項目である。

【００３３】オートメーション開発システム１０の全て
のメッセージは“ｆｒ”タグ付きパラメータで開始しな
ければならない。すなわち、任意のメッセージの最初の
３文字は“ｆｒ＝”でなければならない。これはメッセ
ージ中で固定位置に置かれなければならない唯一のデー
タである。“ｆｒ”タグはメッセージのセンダーを識別
し、かつ他のメッセージフォーマットを理解しなければ
ならないサーバ内のオートメーション開発システムメッ
セージとしてメッセージを識別する。

【００３４】全てのメッセージルーチング情報はメッセ
ージのテキスト内に含まれる。“ｆｒ＝”および“ｔｏ
＝”タグ付パラメータはサーバ５４とクライアント５２
間の通信に対する情報のルーチングを指定し、“ｄｏ
＝”および“ｃｔｘｔ＝”タグ付パラメータはサーバ内
のコードの特定ブロックへのメッセージのルーチングを
行う。要約すれば、予約されるタグ名およびそれらの機
能は下表のようになる。

【００３５】

【表２】

【００３６】図９にコマンドメッセージ処理に対するサ
ーバ論理を表わす簡単化されたフロー図を示す。サーバ
５４は任意のクライアントタスク５２から到来するコマ
ンドメッセージに応答しなければならない。どのクライ
アント５２がコマンドを送出できるかについてサーバ５
４は予め判っていない。到来するコマンドメッセージに
は“ｆｒ＝”タグにより指定される送信クライアントタ
スク名が含まれる。したがって、サーバは実行時以前に
は不明の指定されたタスクに応答できなければならな
い。これは指定されたキューを管理するキューサーバ３
４（図１）との通信を介して行われる。始動時にサーバ
５４およびクライアント５２はキューサーバによりその
名前を登録してシステム１０に知らせなければならな
い。これをブロック１２２にチェックインとして示す。
チェックインがうまくいかない場合には、サーバはブロ
ック１２６において終了してメッセージを受けることは
できない。チェックインがうまくゆけば、実行はブロッ
ク１２８へ進みそこで任意のクライアントからのコマン
ドメッセージの到来を待つ。

【００３７】ブロック１３０に示すように、サーバ５４
が応答メッセージやデータメッセージをクライアント５
２へ戻してコマンドメッセージに応答する時、クライア
ントからのコマンドメッセージに文脈が与えられておれ
ばメッセージ文脈を予約しなければならない。次にサー
バ５４はブロック１３２に示すようにそのコマンドリス
トを調べてコマンドを実行できると判断する。ブロック
１３８に示すように、コマンドリストにコマンドが見つ
からない場合にはエラー応答メッセージが生成される。
さもなくば、ブロック１３４および１３６に示すよう
に、コマンドが実行されて応答が生成される。ブロック
１４０および１４２に示すように、次にブロック１３０
で予約されたコマンド文脈は生成された応答メッセージ
に含まれてメッセージが送出される。応答メッセージが
要求されない状況もある。例えば、サーバ５４がタグ無
しパラメータ“ｎｏｒｅｐｌｙ”を含むコマンドメッセ
ージを受信すると、コマンドを正規に処理しなければな
らないが、そのコマンドメッセージに対する応答メッセ
ージを発生してはならない。ブロック１４４および１４
６に示すように、サーバ５４はコマンドメッセージを待
つループにとどまり、コマンドを実行し、終了するまで
応答メッセージを戻す。終了すると、サーバプロセスは
終了し、キューサーバ３４（図１）はオプションとして
そのキューテーブルから対応するキューを削除すること
ができる。

【００３８】図１０にサーバシーケンス制御フローの詳
細表現を示す。最初に始動するとどのサーバ５４もある
アクションを実施する（ブロック１６０）。これらのア
クションにより始動時にサーバ５４を起動することがで
きる。これにより一つの実行可能ファイルをいくつかの
異なる類似アプリケーションに使用することができ、冗
長コードおよびサーバのさまざまなバージョンを再コン
パイルするための時間量が低減される。ブロック１６２
に示すように、特定ユーザコマンドを含む全てのサーバ
共通コマンド４６（図２）が始動時に生成される。これ
らのコマンドは始動直後に生成されるため、サーバシェ
ルコマンドライン、もしくは始動ファイルの任意の点か
ら呼び出すことができる。コマンドリストの生成につい
ても同様である。

【００３９】ブロック１６４に示すように、サーバシェ
ルはサーバがグレースフル終了できるように、サーバに
よって解釈される予め指定されたシグナルに対するソフ
トウェアトラップを設定する。グレースフル終了とはサ
ーバデベロッパもしくはサーバシェルが定義する任意の
終了コードをサーバが実行することである。さらに、ク
ライアントから終了コマンドを受信する時にサーバはグ
レースフル終了を実行する。

【００４０】ブロック１６６において、シェル動的変数
が生成される。サーバシェル４２により構築される各サ
ーバ５４はいくつかの所定の動的変数を含んでいる。動
的変数はサーバへのコマンドライン引数が処理される前
に初期化され、必要に応じてそれらの値はコマンドライ
ンコマンドや始動ファイルにより取消すことができる。
好ましくは、初期化される動的変数はプロセスのコマン
ドライン名から引き出されるサーバ名、プロセスが開始
されるディレクトリのパスを含む現在作動中のディレク
トリ、コマンドライン上に設定してファイル内のある始
動コマンドを実行するようサーバシェルへ告げる始動フ
ァイル名、およびこのサーバを構成するサーバシェルバ
ージョンを反映するサーバシェルバージョン番号であ
る。

【００４１】統合オートメーション開発システムサーバ
は（図示せず）いくつかのデフォルトログも含んでい
る。ブロック１６８に示すように、これらのログの名前
と属性はこの時割り当てられる。好ましくは、ファイル
名およびデフォルト属性はコマンドラインコマンドもし
くは始動コマンドによりリセットすることができる。次
にブロック１７０において、サーバプロセスが始動する
とオペレーティングシステムコマンドラインを介して一
つ以上のコマンドを入力して実行することができる。ブ
ロック１７２および１７４に示すように、コマンドライ
ンコマンドにエラーがあれば、サーバは終了する。

【００４２】ブロック１７６において、サーバシェルは
キューサーバによりチェックインしてメッセージをイネ
ーブルする。チェックインプロセスについては図７に関
して前述した。メッセージはサーバ名により管理および
ルーチングされるため、各サーバはシステム１０に対し
て一意的でなければならない。ブロック１７８および１
８０に示すように、キューサーバが実行されていないか
もしくは何らかの理由によりチェックインに失敗する
と、エラーメッセージがプリントもしくは表示されてサ
ーバが終了する。

【００４３】ブロック１８２に示すように、コマンド名
ｓｒｖ ｉｎｉｔがある場合には、この点において生じ
る。ｓｒｖ ｉｎｉｔコマンドは特定位置および特定サ
ーバ初期化フックコマンドである。一般的に、オートメ
ーション開発システムサーバ５４はサーバシェル４２に
クライアントが呼び出すことができる特定ユーザコマン
ドを加えて生成される。特定ユーザコマンドは入力され
るコマンドメッセージの結果として処理され、サーバシ
ェル制御論理に影響を及ぼすことはない。しかしなが
ら、サーバデベロッパーが制御フローの所定位置のサー
バシェル制御論理にコードを付加する方法として特殊な
タイプのコマンドを設けることができる。デフォルトに
より、これらのコマンドはアクションを実施せず、サー
バの実行に影響を及ぼすこともない。これらの特定コマ
ンドはサーバシェルが制御フローの特定場所に達する時
に実行される。これらの特定位置コマンド、すなわちフ
ックコマンド、は図７〜図１０のフロー図では点線およ
び破線ブロックとして示されれている。

【００４４】ブロック１８４に示すように、始動ファイ
ル名を含む動的変数がコマンドラインを介するかもしく
はｓｒｖ ｉｎｉｔコマンドにより設定されると、サー
バシェルは動的変数により指定される始動ファイルに対
するカレントワーキングディレクトリを調べる。ブロッ
ク１８６および１８８に示すように、次にファイルから
コマンドが読み出され残りが無くなるまで実行される。

【００４５】サーバ内の全てのファイルアクセスはサー
バのカレントワーキングディレクトリに関連して行われ
る。カレントワーキングディレクトリはサーバが開始さ
れたディレクトリへデフォルトする。しかしながら、コ
マンドラインコマンド、ｓｒｖ ｉｎｉｔコマンドもし
くは始動ファイル内のコマンドでＣＷＤ動的変数を設定
することにより、カレントワーキングディレクトリを異
なるディレクトリへ設定することができる。ブロック１
９０に示すように、始動ファイルをローディングした後
で、必要に応じサーバシェルはその実際のカレントワー
キングディレクトリを変えてＣＷＤ動的変数により指定
されるものと一致させる。ブロック１９２および１９４
に示すように、サーバシェルが特定ディレクトリへ変化
できない場合には、サーバは終了してエラーメッセージ
を記録する。

【００４６】ブロック１９６に示すように、サーバはそ
の初期化プロセスを完了するとキューからのメッセージ
を読み出して処理するループへ入り、次に別のメッセー
ジの読み出しへ戻る。図８〜図１０にメッセージ処理ル
ープの制御論理を示す。

【００４７】図１１において、ブロック２００は図７に
示す初期化プロセスを表わす。ブロック２０２および２
０４に示すように、サーバシェルがメッセージを待って
いる間にコマンドにより発生されるアラーム信号が受信
されると、フックコマンドｓｒｖ ａｌａｒｍが呼び出
される。ブロック２０６に示すように、次にサーバシェ
ルはキューを検査することによりメッセージを待機し続
ける。この時アラーム信号を受信すると、ブロック２０
４へ戻ってｓｒｖ ａｌａｒｍフックコマンドが呼び出
される。ブロック２１０に示すように、キュー内にメッ
セージが無ければ、ブロック２１２に示すようにｓｒｖ
ｒｃｖｅｒｒフックコマンドが呼び出される。デフォ
ルトにより、サーバシェルはキューにメッセージが到着
するのを無限に待機する。メッセージが到着すると、フ
ローが継続され可能ならばメッセージが処理される。

【００４８】しかしながら、サーバは永久にメッセージ
を待機してはならないことを指定する動的変数が定義さ
れると、サーバはメッセージキューを一度検査し、一つ
が待機中であれば受信メッセージを処理する。そうでな
ければ、サーバシェルはｓｒｖ ｒｃｖｅｒｒフックコ
マンドを呼び出そうとする。この手順は、端末サーバ２
８（図１）のように、メッセージキューに加えて、サー
バをデバイスにブロックオン（ｂｌｏｃｋ ｏｎ）でき
るようにするために使用される。この動的変数が定義さ
れずキューからメッセージを読み出そうとしている間に
エラーが生じると、サーバシェルは存在する場合にはｓ
ｒｖ ｒｃｖｅｒｒを呼び出し、メッセージをエラーロ
グへログし、終了するよう告げられなければ別のメッセ
ージの待機へ戻る。好ましくは、特定数のエラーが連続
的に発生する場合にはサーバシェルがエラーログへメッ
セージを書き込んで終止するようにされる。

【００４９】次に、ブロック２１０に示すようにメッセ
ージが受信されると、検査を行って正しいオートメーシ
ョン開発システムフォーマットであるかどうか判断され
る。正しいメッセージフォーマットは好ましくはタグ
“ｆｒ”で始まるメッセージとして定義される。ブロッ
ク２１４において入メッセージは非オートメーション開
発システムメッセージであると判断されると、図１２に
続き後記するブロック２１６において非標準フォーマッ
トメッセージとして処理される。ブロック２１８に示す
ように、メッセージが正しいフォーマットであれば、サ
ーバシェルはメッセージ内の“ｔｏ”タグを捜す。メッ
セージ内に“ｔｏ”タグは存在するが“ｔｏ”パラメー
タの値がこの受信サーバ名と一致しない場合には、ブロ
ック２２０および２２２に示すように、サーバシェルは
定義されている場合にはフックコマンドｓｒｖ ｂａｄ
ｄｒを呼び出す。“ｔｏ”タグ値がサーバ名と同じであ
る、すなわちｓｒｖ ｂａｄｄｒフックが定義されてい
ない場合には、メッセージは正規に処理される。ｓｒｖ
ｂａｄｄｒフックコマンドはキューサーバ３４（図
１）が他のＣＰＵへメッセージをルーチングするのに使
用される。

【００５０】ブロック２２４に示すように、メッセージ
を処理するためにタグ付およびタグ無しパラメータへ構
文解析される。構文解析によりＣ＋＋言語およびスクリ
プト言語で書かれたコマンドはメッセージパラメータへ
アクセスすることができる。引用語句の不整合によりメ
ッセージの構文解析中にエラーが生じると、ブロック２
２６および２２８に示すように、エラーを示す応答メッ
セージがクライアントへ戻される。ブロック２３０に示
すように、次にサーバシェルは定義されておればフック
コマンドｓｒｖ ｐａｒｓｅｅｒｒを呼び出す。

【００５１】ブロック２３４に示すように、エラー無し
でメッセージ構文解析が完了して入メッセージに“ｒｅ
ｐｌｙ”タグが見つかると、それは応答メッセージとし
て処理される。メッセージに“ｃｔｘｔ”パラメータも
含まれる場合には、サーバシェルは待機リストに文脈値
の整合したエントリが無いかを調べる。ブロック２４０
に示すように、エントリが見つかると、このエントリに
関連するコマンドが呼び出される。ブロック２３８に示
すように、メッセージに“ｃｔｘｔ”パラメータが無い
か、メッセージ内の“ｃｔｘｔ”が待機リストに存在し
ない場合には、サーバシェルは存在する場合のフックコ
マンドｓｒｖ ｒｅｐｌｙを呼び出す。存在しない場合
には、メッセージ内のコマンドを実行することなくメッ
セージは廃棄される。

【００５２】コマンドメッセージは“ｄｏ”タグを含み
“ｒｅｐｌｙ”タグを含まないメッセージとして定義さ
れる。したがって、ブロック２３４において“ｒｅｐｌ
ｙ”タグが見つからなければ、ブロック２４２に示すよ
うにサーバシェルは“ｄｏ”タグおよびパラメータを捜
す。“ｄｏ”タグおよびパラメータが存在すれば、それ
はコマンドメッセージであり、その処理をブロック２４
４および図１３に示す。コマンドメッセージ処理につい
ては図１３に関して後述する。

【００５３】メッセージが“ｄｏ”もしくは“ｒｅｐｌ
ｙ”タグを含まない場合には、データメッセージである
と推定される。データメッセージの処理をブロック２４
６に示す。ブロック２４８に示すように、サーバシェル
はメッセージの中の“ｃｔｘｔ”パラメータを捜し、待
機リストに同じ文脈パラメータを有するエントリがある
かどうか調べる。ブロック２５０に示すように、メッセ
ージに“ｃｔｘｔ”タグが無い、すなわち待機リストに
存在しない“ｃｔｘｔ”タグが含まれている場合には、
サーバシェルは存在する場合のフックコマンドｓｒｖ
ｄａｔａを呼び出す。ｓｒｖ ｄａｔａコマンドが存在
しなければ、メッセージは廃棄され無視される。ブロッ
ク２５２に示すように、整合する文脈値を有するエント
リが見つかると、そのエントリに関連するコマンドが実
行される。

【００５４】サーバシェルはクライアントからの終了シ
グナルすなわち“ｅｘｉｔ”コマンドにより終了するま
でメッセージ処理を継続する。好ましくは、終了コマン
ドによりサーバシェル内に終了フラグが設定される。ブ
ロック２５４に示すように、終了フラグは各メッセージ
処理ループの終りに検査される。ブロック２５６に示す
ように、設定されておれば、サーバシェルは存在する場
合のｓｒｖ ｅｘｉｔフックコマンドを呼び出して終了
する。

【００５５】図１２に非標準フォーマットメッセージ２
１６の処理を示す。非標準フォーマットメッセージが受
信されると、好ましくはサーバシェルは特定の動的変
数、例えばＳＹＳ＞ＰＲＯＴＯＣＯＬ（図４）を検査し
てメッセージをどのように処理すべきか判断する。ブロ
ック２６０および２６４に示すように、ＳＹＳ＞ＰＲＯ
ＴＯＣＯＬ動的変数はメッセージが例えばＳＥＣＳ（Ｓ
ＥＭＩ Ｅｑｕｉｐｍｅｎｔ Ｃｏｍｍｕｎｉｃａｔｉ
ｏｎ Ｓｔａｎｄａｒｄ）フォーマットであるかＡＳＣ
ＩＩフォーマットであるかを示す。ブロック２６８に示
すように、この変数が存在しないかもしくは値を持たな
い場合には、メッセージは存在する場合のフックコマン
ドｓｒｖ ｍｓｇへ通される。ｓｒｖ ｍｓｇが存在し
なければメッセージは廃棄され無視される。

【００５６】ＳＹＳ＞ＰＲＯＴＯＣＯＬ動的変数がＳＥ
ＣＳに設定されると、サーバシェルはフックコマンドｓ
ｘｄｅｃｏｄｅを呼び出すことによりメッセージを処理
する。ｓｘｄｅｃｏｄｅフックコマンドはＳＥＣＳメッ
セージからデータを抽出して動的変数に記憶する。ＳＹ
Ｓ＞ＰＲＯＴＯＣＯＬ動的変数がＡＳＣＩＩに設定され
ておれば、サーバシェルはｃｕｔフックコマンドを実行
してメッセージを処理する。ｃｕｔコマンドはＡＳＣＩ
Ｉメッセージからデータを抽出して動的変数内に記憶す
る。いずれの場合も、ＳＥＣＳおよびＡＳＣＩＩメッセ
ージのフォーマットは予め定義しなければならない。両
コマンドはまた装置サーバシェルにおいてＳＥＣＳおよ
びＡＳＣＩＩメッセージ処理のために定義される。

【００５７】ブロック２７０に示すように、ｓｘｄｅｃ
ｏｄｅもしくはｃｕｔにより非標準フォーマットメッセ
ージを復号した後で、サーバシェルは処理コマンドへメ
ッセージを向けるエントリが無いか待機リストを調べ
る。エントリが見つかれば、ブロック２７２に示すよう
に対応するコマンドが呼び出される。ブロック２６８に
示すように、文脈エントリが見つからずかつｓｒｖ ｍ
ｓｇが定義されておれば、ｓｒｖ ｍｓｇが呼び出され
てメッセージが処理される。次に図１１のブロック２５
４へ実行が戻される。

【００５８】標準フォーマットメッセージに“ｄｏ”タ
グが含まれているが“ｒｅｐｌｙ”タグが含まれていな
い場合には、コマンドメッセージであると推定される。
図１３にコマンドメッセージ処理２４４を示す。好まし
くは、サーバシェルは“ｄｏ”タグが実行すべきコマン
ドを識別するものと推定する。ブロック２８０に示すよ
うに、名前が“ｄｏ”タグの値と一致するものが無いか
どうかサーバのコマンドリストが調べられる。ブロック
２８２および２８４に示すように、サーバのコマンドリ
ストにコマンドが見つからなければ、サーバは存在する
場合のフックコマンドｓｒｖ ｃｏｍｍａｎｄを実行す
る。ブロック２８６に示すように、ｓｒｖ ｃｏｍｍａ
ｎｄが存在しなければ、サーバシェルはエラー応答メッ
セージを構成してクライアントへ送る。

【００５９】ブロック２８８に示すように、“ｄｏ”タ
グにより識別されるコマンドがコマンドリストで見つか
ると、コマンドメッセージのシンタクスがコマンドリス
トに格納されているシンタック記号列に対して検査され
る。しかしながら、タグ無しパラメータ“ｎｏｓｙｎｔ
ａｘ”が入メッセージ内に存在するか、もしくは動的変
数がｎｏｓｙｎｔａｘが存在する場合には、シクタクス
検査は行われない。ブロック２９０および２８６に示す
ように、シンタクスエラーが検出されると、エラー応答
メッセージがサーバシェルによりクライアントへ戻され
てコマンドは実行されない。ブロック２９２に示すよう
に、コマンドメッセージシンタクスが正しければ、サー
バシェルはコマンドのコードを呼び出す。コマンドコー
ドはＣ＋＋もしくはスクリプト言語で書くことができ
る。Ｃ＋＋コマンドが呼び出されると、コマンドに付随
する予めコンパイルされたＣ＋＋機能が呼び出される。
スクリプト言語コマンドが呼び出されると、スクリプト
言語コードはラインごとに解釈される。

【００６０】Ｃ＋＋で書かれているかスクリプトで書か
れているかにかかわらず、コマンドコードは整数値およ
びオプショナルな文字列データを戻さなければならな
い。戻された整数および文字列データはクライアントへ
戻される応答メッセージを構成するのに使用される。ブ
ロック２９４に示すように、コマンドを呼び出したコマ
ンドメッセージが“ｎｏｒｅｐｌｙ”パラメータを含む
場合には、応答は必要とされずしたがってクライアント
へは送られない。“ｎｏｒｅｐｌｙ”パラメータは特定
コマンドを首尾よく完了させることがクライアントにと
って極めて重要ではない場合に使用される。応答が必要
でかつコマンドを呼び出したコマンドメッセージが“ｃ
ｔｘｔ”パラメータを含む場合には、サーバシェルの結
果的応答メッセージには文脈タグとその値が含まれる。
次に、図１１のブロック２５４へ実行が戻される。

【００６１】オートメーション開発システム１０にはそ
れにより生成されたのではないエンティティと通信を行
う規定も定められる。キューサーバはこれらのキューを
制御しないため、これらのキューにどんな名前を割り当
てるべきか告げられなければならない。したがって、キ
ューサーバは予め定義されたキューの名前と対応するキ
ーすなわちＩＤを記録する固定キーテーブルすなわちフ
ァイル、およびチェックインしたサーバのキュー名とキ
ーを記録する自動キューテーブルを保有している。一つ
のキーテーブルにキューキーが登録されていると、シス
テム内の任意他のキューと同様に名前で参照することが
できる。

【００６２】キューサーバはさらに個別ＣＰＵを介した
クライアントとサーバ間のメッセージ送受信を支援す
る。各ＣＰＵは各々がキューサーバおよびネットサーバ
と呼ばれる付加プロセスを有する個別のオートメーショ
ン開発システムを実行させることができる。キューサー
バはネットワークを介して他のＣＰＵへメッセージを送
るのに使用され、ネットサーバはネットワークからメッ
セージを受信してディスティネーションプロセスへ送出
するのに使用される。

【００６３】図１４に分散メッセージを送出するプロセ
スを示す。ＣＰＵにより実行中のサーバＡはＣＰＵ２で
実行中のサーバＢへメッセージを送りたいものとする。 １．矢符３０１で示すようにサーバＡはサーバＢのキュ
ーＩＤをキューサーバにたずねる。 ２．キューサーバは自動キューリスト内にサーバＢが見
つからないため、固定キーファイルで捜す。 ３．矢符３０２で示すように、キューサーバは固定キー
ファイル内でサーバＢを見つけて、例えば９６５７のキ
ューサーバのキュー値を有するキーをサーバＡへ送る。 ４．矢符３０３で示すように、サーバＡはキュー９６５
７へメッセージを送る。 ５．ＣＰＵ１上のキューサーバはサーバＡからメッセー
ジを受信するが、“ｔｏ”タグがそのキュー値と一致し
ないことを指摘する。 ６．キューサーバはルーチングテーブルでサーバＢを捜
す。好ましくは、ルーチングテーブルはプロセス名およ
びプロセスが存在するリモートマシンを含む動的変数構
造である。 ７．矢符３０４で示すように、キューサーバはルーチン
グテーブルでサーバＢおよびサーバＢのＣＰＵ名を見つ
けてサーバＡからネットワークを介してＣＰＵ２へメッ
セージを送る。 ８．矢符３０５で示すように、ＣＰＵ２上のネットプロ
セスはネットワークからメッセージを受信する。 ９．矢符３０６で示すように、ネットプロセスはＣＰＵ
２のキューサーバによりサーバＡを登録する。 １０．ネットプロセスはＣＰＵ２のキューサーバへサー
バＢのキューＩＤをたずねる。矢符３０７で示すよう
に、キューサーバはサーバＢがチェックインする時に割
り当てられた例えば５００３のキューＩＤを戻す。 １１．矢符３０８に示すように、ネットプロセスはサー
バＢへメッセージを送る。 １２．サーバＢはあたかもローカルプロセスから送られ
たかのようにメッセージを受信する。

【００６４】キューサーバ３４の他に、統合オートメー
ション開発システム１０はサーバおよびクライアントに
対して特定時間もしくは時間依存アクティビティを調整
する時間サーバ３６（図１）が必要な場合もある。例え
ば、タイマを使用して２４時間ごとにメンテナンスコマ
ンドメッセージを送ったり３０秒の“時間限れ”メッセ
ージを送ることができる。時間サーバはクロックやタイ
ムキーピングデバイスへのサーバのリンクである。時間
サーバはキューサーバと同様な背景で実行できなければ
ならない。

【００６５】装置サーバ２２（図１）は特定種別の製造
装置とのサーバインターフェイスを定義する方法すなわ
ちサーバコマンドを提供する。装置サーバにはサーバシ
ェルの全てのコードやコマンド、プラス製造装置とのイ
ンターフェイスに必要な機能を提供する付加コマンドが
含まれている。装置サーバの定義および使用を許す装置
サーバコマンドの他に、装置サーバは製造装置から受信
されるＳＥＣＳおよびＡＳＣＩＩメッセージを処理する
前記した２つの特殊コマンドｓｘｄｅｃｏｄｅおよびｃ
ｕｔをも定義する。好ましくは、装置サーバはさらに装
置からのデータの記録を行う。

【００６６】装置サーバが受け持つ各装置片には一意的
な識別番号すなわちＩＤを割り当てなければならない。
ＳＥＣ装置は装置に出入りする全メッセージにこのＩＤ
を配置する必要があるため、装置サーバはそれを使用し
て入ＳＥＣＳメッセージを分離し識別する。装置サーバ
にはルーチング、復号、符号化、およびＳＥＣＳメッセ
ージ送出用のいくつかのコマンドが含まれている。ＳＥ
ＣＳメッセージフォーマットの詳細検討については関連
するＳＥＣＳ文献を参照されたい。

【００６７】図１のグラフィック制御クライアント１４
はＳｅｑｕｅｎｔｉａｌ Ｆｕｎｃｔｉｏｎ Ｃｈａｒ
ｔもしくはＳＦＣ記法を使用したオートメーション制御
サーバとして実現することができる。ＳＦＣ記法は国際
電子技術委員会（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅ
ｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ）
が規定する制御システムのグラフィック表現に対する国
際標準から導かれたものである。グラフィック制御クラ
イアント１４は次にオートメーション開発システムの制
御フローを提供し規定する。それは制御アプリケーショ
ンを定義しデバッグするコマンドを提供する。次に制御
アプリケーション定義を使用してシステム内のサーバお
よびクライアントを調整してアプリケーションが実施さ
れる。

【００６８】統合オートメーション開発システム１０内
に他のサーバプロセスを実現してデータベース等の他の
エンティティとのインターフェイス機能を実施すること
もできる。あるアクションを監視してシステム内のミス
コーディングを検出するように機能するデバッグサー
バ、システム内の他の全てのサーバとのコマンドライン
インターフェイスを開発者へ提供するトークサーバ、お
よびＳＦＣ編集機能を提供するＳＦＣエディタ等の統合
を容易にするようにサーバを実現することができる。前
述したように、このようなサーバは全てサーバシェル４
２（図２）の基本コードおよびコマンドへ特定用途コマ
ンドを加えてインプリメントされ、下位に位置する制御
フロー論理、メッセージ管理、コマンド管理、スクリプ
ト解釈、および動的変数管理は既に適正に配置されてい
る。したがって、オートメーション統合は容易とされ、
実現および修正は迅速に行われる。

【００６９】本発明について詳細説明を行ってきたが、
特許請求の範囲に明記された本発明の意図および範囲内
でさまざまな変更、置換および修正が可能であることを
理解されたい。

【００７０】以上の説明に関して更に以下の項を開示す
る。 （１） 製造装置の制御および調整を行う統合オートメ
ーション開発システムにおいて、前記システムは複数の
サーバプロセスを含み、前記各サーバプロセスが、ＡＳ
ＣＩＩメッセージを受信するメッセージマネジャーと、
テキストベースのプログラミング言語で表現されたコマ
ンドを含む前記受信されたＡＳＣＩＩメッセージを評価
して、前記ＡＳＣＩＩメッセージ内の前記コマンドを認
識するインタプリタと、前記コマンドを受信して実行す
るコマンドマネジャーと、前記コマンドマネジャーによ
る前記コマンド実行の論理フローを管理するロジックコ
ントローラーと、を含むことを特徴とする、統合オート
メーション開発システム。

【００７１】（２） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記インタプリタは更に前記
ＡＳＣＩＩユーザ入力内の動的変数を認識し、前記動的
変数は階層構成とされ、更に前記動的変数が前記コマン
ドマネジャーによるコマンド実行中にデータ値を記憶す
る、或いは、前記コマンドマネジャーがコマンド実行に
必要な値を供給するために使用されることを特徴とす
る、統合オートメーション開発システム。

【００７２】（３） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記ロジックコントローラは
入力メッセージを検査するよう前記コマンドマネジャー
に指令し、前記メッセージを構文解析し、前記メッセー
ジ内のコマンドを獲得し、コマンドのシンタクス（ｓｙ
ｎｔａｘ）を検査し、コマンドを実行し、応答メッセー
ジを発生し、更に前記応答メッセージを送るよう前記メ
ッセージマネジャーに指令することを特徴とする、統合
オートメーション開発システム。

【００７３】（４） 第１項記載の統合オートメーショ
ン開発システムにおいて、各サーバプロセスは更にメッ
セージを受信するためのメッセージキューを含み、前記
ロジックコントローラは入力されるメッセージのための
前記メッセージキューを検査するように、前記コマンド
マネジャーに指令し、前記メッセージを構文解析し、前
記メッセージのフォーマットを識別し、前記識別された
メッセージフォーマットに応じて、前記メッセージを処
理し、メッセージのための前記メッセージキューの検査
を続行することを特徴とする、統合オートメーション開
発システム。

【００７４】（５） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記特定用途コマンドマネジ
ャーは、前記製造装置の制御およびインターフェイス用
特定用途コマンドを実行し、前記ロジックコントローラ
は入力されるメッセージを検査するように前記コマンド
マネジャーに指令し、前記メッセージを構文解析し、前
記メッセージのフォーマットをＳＥＣＳとして識別し、
前記ＳＥＣＳメッセージを処理し、メッセージの検査を
継続することを特徴とする、統合オートメーション開発
システム。

【００７５】（６） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記特定用途コマンドマネジ
ャーは前記サーバプロセス間をルーチング（ｒｏｕｔｉ
ｎｇ）メッセージを管理するための、特定用途コマンド
を実行することを特徴とする、統合オートメーション開
発システム。

【００７６】（７） 第６項記載の統合オートメーショ
ン開発システムにおいて、前記メッセージルーチング
（ｒｏｕｔｉｎｇ）管理特定用途コマンドマネジャーは
既存のサーバプロセス名および対応するメッセージキュ
ーアドレスのリストを維持することを特徴とする、統合
オートメーション開発システム。

【００７７】（８） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記特定用途コマンドマネジ
ャーは、ユーザ端末とインターフェイスするための、特
定用途コマンドを実行することを特徴とする、統合オー
トメーション開発システム。

【００７８】（９） 第１項記載の統合オートメーショ
ン開発システムにおいて、前記特定用途コマンドマネジ
ャーはホスト製造コンピュータシステムとインターフェ
イスするための特定用途コマンドを実行することを特徴
とする、統合オートメーション開発システム。

【００７９】（１０） 製造装置の制御および調整を行
う統合オートメーション開発システムにおいて、前記シ
ステムは、メッセージを発生するための制御クライアン
トと、製造装置に接続されて前記制御クライアントから
前記メッセージを受信し、前記メッセージによって指令
される、前記製造装置の制御を行い、それに応答してメ
ッセージを発生する装置サーバと、開発者インターフェ
イス端末に接続されてデベロッパー入力を受信しシステ
ムの状態を表示し、更にメッセージを発生し受信する端
末サーバと、前記制御クライアント、装置サーバ、およ
び端末サーバ間で前記メッセージのルーチング（ｒｏｕ
ｔｉｎｇ）を可能とするキューサーバ（ｑｕｅｕｅ ｓ
ｅｒｖｅｒ）と、を含むことを特徴とする、統合オート
メーション開発システム。

【００８０】（１１） 第１０項記載のシステムにおい
て、前記各クライアントおよびサーバは、ＡＳＣＩＩメ
ッセージを受信するためのメッセージマネジャーと、テ
キストベースのプログラミング言語で表現されたコマン
ドを有する前記受信されたＡＳＣＩＩメッセージを評価
して、前記ＡＳＣＩＩメッセージ内の前記コマンドを認
識するインタプリタと、前記コマンドを受信して実行す
るためのコマンドマネジャーと、前記コマンドマネジャ
ーによる前記コマンド実行の論理フローを管理するロジ
ックコントローラと、を含むことを特徴とする、統合オ
ートメーション開発システム。

【００８１】（１２） 第１１項記載のシステムにおい
て、前記インタプリタは更に、前記ＡＳＣＩＩユーザ入
力内の動的変数を認識し、前記動的変数は階層構成とさ
れ、更に前記動的変数が前記コマンドマネジャーによる
コマンド実行中にデータ値を記憶する或いは、前記コマ
ンドマネジャーがコマンド実行に必要な値を供給するた
めに使用されることを特徴とする、統合オートメーショ
ン開発システム。

【００８２】（１３） 第１１項記載のシステムにおい
て、前記ロジックコントローラは入力されるメッセージ
を検査するよう前記コマンドマネジャーに指令し、前記
メッセージを構文解析し、前記メッセージ内のコマンド
を獲得し、コマンドのシンタクス（ｓｙｎｔａｘ）を検
査し、コマンドを実行し、応答メッセージを発生し、更
に、前記応答メッセージを送るように前記メッセージマ
ネジャーに指令することを特徴とする、統合オートメー
ション開発システム。

【００８３】（１４） 第１１項記載のシステムにおい
て、各クライアントおよびサーバは更に、メッセージを
受信するメッセージキューを含み、前記ロジックコント
ローラは、入メッセージに対して前記メッセージキュー
を検査するように前記コマンドマネジャーに指令し、前
記メッセージを構文解析し、前記メッセージのフォーマ
ットを識別し、前記識別されたメッセージフォーマット
に応じて前記メッセージを処理し、メッセージのための
前記メッセージキューの検査を続行することを特徴とす
る、統合オートメーション開発システム。

【００８４】（１５） 製造装置の制御および調整を行
うオートメーション開発システムの統合方法において、
前記システムは複数のサーバプロセスを含み、前記方法
は、他のサーバプロセスからのＡＳＣＩＩメッセージを
検査して受信し、テキストベースのプログラミング言語
で表現された少くとも一つのコマンドを構成する前記受
信されたＡＳＣＩＩユーザ入力を評価して、前記ＡＳＣ
ＩＩメッセージ内の前記コマンドを認識し、前記コマン
ドを実行し、ＡＳＣＩＩメッセージの検査を続行する、
ステップを含むことを特徴とする、オートメーション開
発システムの統合方法。

【００８５】（１６） 第１５項記載の方法において、
更に、前記ＡＳＣＩＩメッセージ内の動的変数を認識
し、前記動的変数を階層構成とし、前記動的変数を使用
してコマンド実行中にデータ値を記憶する或いは前記動
的変数を使用して、コマンド実行に必要な値を供給す
る、ステップを含むことを特徴とする、オートメーショ
ン開発システム統合方法。

【００８６】（１７） 第１５項記載の方法において、
更に前記メッセージの構文解析を行い、前記メッセージ
内のコマンドを獲得し、コマンドのシンタクス（ｓｙｎ
ｔａｘ）を検査し、コマンドを実行し、応答メッセージ
を発生し、前記応答メッセージを適切な転送先へ向け
る、ステップを含むことを特徴とする、オートメーショ
ン開発システム統合方法。

【００８７】（１８） 第１５項記載の方法において、
更に、入力メッセージのためのメッセージキューを検査
し、前記メッセージを構文解析し、前記メッセージのフ
ォーマットを識別し、前記識別されたメッセージフォー
マットに応じて前記メッセージを処理し、メッセージの
ための前記メッセージキューの検査を続行する、ステッ
プからなることを特徴とする、オートメーション開発シ
ステム統合方法。

【００８８】（１９） 第１５項記載の方法において、
更に前記製造装置の制御および前記製造装置とのインタ
ーフェイス用特定用途コマンドを実行し、入力されるメ
ッセージを検査し、前記メッセージの構文解析を行い、
前記メッセージのフォーマットをＳＥＣＳとして識別
し、前記ＳＥＣＳメッセージを処理し、メッセージに対
する検査を続行する、ステップを含むことを特徴とす
る、オートメーション開発システム統合方法。

【００８９】（２０） 第１５項記載の方法において、
更に前記サーバプロセス間のメッセージルーチング（ｒ
ｏｕｔｉｎｇ）を管理するための、特定用途コマンドを
実行し、既存のサーバプロセス名のリストおよび対応す
るメッセージキューアドレスのリストを維持する、ステ
ップからなるオートメーション開発システム統合方法。

【００９０】（２１） 製造装置２４の制御および調整
を行う統合オートメーション開発システム１０は複数の
サーバプロセス１４，１６，２２，２８，３４，３６を
使用し、各サーバプロセスにはＡＳＣＩＩメッセージを
受信するためのメッセージマネジャー４５、および受信
されたＡＳＣＩＩメッセージを評価してメッセージ内の
コマンドを識別するインタプリタ４３が含まれ、サーバ
プロセスには更にコマンドを受信して実行するコマンド
マネジャー４１と、コマンドマネジャー４１によるコマ
ンド実行の論理フローを管理するロジックコントローラ
４７が含まれて、更に、サーバは該サーバがキューサー
バ３４、端末サーバ２８、および他の特定用途サーバプ
ロセスとして動作できるようにするための付加的コマン
ド４８を含むことも可能である。

【図面の簡単な説明】

【図１】本発明の実施例の簡単化した最上位システムブ
ロック図。

【図２】サーバシェルモジュールの実施例の成分を示す
図。

【図３】主サーバ成分の略図。

【図４】動的変数のデータ構造を示す略図。

【図５】メッセージベース通信プロトコルを示す略図。

【図６】メッセージベース通信プロトコルを示すもう一
つの略図。

【図７】メッセージベース通信プロセスを示す略データ
フロー図。

【図８】コマンドメッセージを処理する略フロー図。

【図９】基本サーバ制御フローの略フロー図。

【図１０】サーバ初期化の略フロー図。

【図１１】サーバメッセージ処理の略フロー図。

【図１２】サーバ非標準メッセージ処理の略フロー図。

【図１３】サーバコマンドメッセージ処理の略フロー
図。

【図１４】分散メッセージ通信の略データフロー図。

【符号の説明】 １０ 統合オートメーション開発システム １４，１６，２２，２８，３４，３６ サーバプロセス ２４ 製造装置 ２８ 端末サーバ ３４ キューサーバ ４１ コマンドマネジャー ４３ インタプリタ ４５ メッセージマネジャー ４７ ロジックコントローラ ４８ 付加コマンド

Claims (2)

【特許請求の範囲】
1. 【請求項１】 製造装置の制御および調整を行う統合オ
   ートメーション開発システムにおいて、前記システムは
   複数のサーバプロセスを含み、前記各サーバプロセス
   が、 ＡＳＣＩＩメッセージを受信するメッセージマネジャー
   と、 テキストベースのプログラミング言語で表現されたコマ
   ンドを含む前記受信されたＡＳＣＩＩメッセージを評価
   して前記ＡＳＣＩＩメッセージ内の前記コマンドを認識
   するインタプリタと、 前記コマンドを受信して実行するコマンドマネジャー
   と、 前記コマンドマネジャーによる前記コマンド実行の論理
   フローを管理するロジックコントローラーと、 を含むことを特徴とする、統合オートメーション開発シ
   ステム。
2. 【請求項２】 製造装置の制御および調整を行うオート
   メーション開発システムの統合方法において、前記シス
   テムは複数のサーバプロセスを含み、前記方法は、 他のサーバプロセスからのＡＳＣＩＩを検査して受信
   し、 テキストベースのプログラミング言語で表現された少く
   とも一つのコマンドを構成する前記受信されたＡＳＣＩ
   Ｉユーザ入力を評価して前記ＡＳＣＩＩメッセージ内の
   前記コマンドを認識し、 前記コマンドを実行し、 ＡＳＣＩＩメッセージの検査を続行する、 ステップを含むことを特徴とする、オートメーション開
   発システムの統合方法。