JP6550623B2 - リソグラフィ機のクラスタのためのネットワークアーキテクチャおよびプロトコル - Google Patents

Description

本発明は、パターンデータに従って基板を独立して露光するために各々が用意された複数のリソグラフィ要素を備えるクラスタ化基板処理システムに関し、より詳細には、このようなクラスタ化基板処理システムのためのネットワークアーキテクチャおよびプロトコルに関する。

半導体業界では、精度および信頼性が高い構造物を製造することが常に望まれている。リソグラフィシステムでは、この要望により、ウエハの生産の量および速さに対する要求が極度に高くなっている。リソグラフィ機は、機械内で様々な機能を実施するための多数のサブシステム、およびサブシステムの動作を制御するための複雑なソフトウェアを有するので、より複雑になっている。現代のリソグラフィ機は通常、大量のデータ演算を生成し、データ管理はますます困難になっている。複数のリソグラフィ機をリソグラフィ要素クラスタにまとめると、より大量の生産が可能になる。制御およびデータ収集のための、このようなリソグラフィ要素のクラスタ内での情報の送信は、送信するべき情報の量が増え、システムの複雑さが増すにつれ、問題になっている。

制御およびデータサービスを単一のネットワークの中に組み合わせ、サービス品質技法を用いて、重要な制御データの適時配信を行うために特定のデータの配信を優先させるネットワークアーキテクチャが存在するが、このアーキテクチャは、この環境では不十分であることが分かっている。本発明は、ネットワークアーキテクチャが、リソグラフィ要素のクラスタについて、重要な制御データの適時配信と、大量のデータの収集とを行うための代替ソリューションを提供する。

複数のリソグラフィ機をクラスタ化し、制御およびデータサービスがクラスタネットワークアーキテクチャおよびプロトコルにおいて対応されることが望ましい。一態様では、本発明は、１つまたは複数のリソグラフィ要素を備えるクラスタ化基板処理システムを提供し、各リソグラフィ要素は、パターンデータに従って基板を独立して露光するために用意される。各リソグラフィ要素は、複数のリソグラフィサブシステムと、リソグラフィサブシステムと少なくとも１つの要素制御ユニットの間の制御情報の通信用に用意された制御ネットワークとを備え、要素制御ユニットは、リソグラフィサブシステムにコマンドを送信するように用意され、リソグラフィサブシステムは、要素制御ユニットに応答を送信するように用意される。各リソグラフィ要素は、オペレータまたはホストシステムへのインターフェース用のクラスタフロントエンドも備え、フロントエンドは、１つまたは複数のウエハを露光するための１つまたは複数のリソグラフィサブシステムの動作を制御するための制御情報を、少なくとも１つの要素制御ユニットに発行するために用意される。フロントエンドは、要素制御ユニットにプロセスプログラムを発行するために用意され、プロセスプログラムは、あらかじめ規定されたコマンドおよび関連パラメータのセットを備え、各コマンドは、リソグラフィサブシステムのうちの１つまたは複数によって実施されるべき、あらかじめ規定された１つのアクションまたは一連のアクションに対応し、パラメータは、１つのアクションまたは一連のアクションがどのように実施されるべきかをさらに定義する。

要素制御ユニットは、リソグラフィサブシステムによって実行するための、対応するプロセスジョブを生成するためのプロセスプログラムをスケジューリングするために用意されてよく、プロセスジョブは、プロセスプログラムのコマンドセットと、コマンドの各々についてのスケジュールされた実行時間とを備える。プロセスジョブは全体が、プロセスジョブの実行が始まる前にスケジュールされ得る。こうすることにより、完了プロセスジョブが始まる前に、完了プロセスジョブの実行のための期間が分かるようになり、固定される。各ステップについての、および完了プロセスの、スケジュールされた開始時間（および完了時間）は、クラスタフロントエンドに報告すればよい。こうすることにより、基板がリソグラフィ要素に渡されるべきとき、およびリソグラフィ要素内での基板の露光が完了されると予想されるときなど、工場内の活動のスケジューリングが大幅に簡単になり、その結果、リソグラフィ要素との間で基板を移動する追跡システムのスケジューリングが円滑になる。

要素制御ユニットは、プロセスプログラムのコマンドセットと、コマンドの各々について、コマンドを実行するようにスケジュールされたリソグラフィサブシステムの識別情報とを備えるプロセスジョブを生成するために用意することができる。要素制御ユニットは、プロセスジョブのコマンドの各々を、コマンドの各々に対してスケジュールされた実行時間に、識別されたリソグラフィサブシステムに送信することによってプロセスジョブを実行するように用意することができる。要素制御ユニットは、プロセスジョブのコマンドの各々を、プロセスジョブに先行するコマンドの実行状況にかかわらず、コマンドの各々に対してスケジュールされた実行時間に、識別されたリソグラフィサブシステムに送信するように用意することができる。プロセスジョブのコマンドの実行時間は、先行または並列ステップの結果を条件とするのではなく、所定の時間スケジュールに従って実行される。ステップが、正しくまたはスケジュールされた時間内に完了しない場合、ステップは、再度実行されるのではなく、代わりに次のスケジュールされたステップが実行される。

プロセスプログラムは、対応するコマンドについての所定の期間を定義することができ、要素制御ユニットは、リソグラフィサブシステムによって実行するためのプロセスジョブを生成するようにプロセスプログラムをスケジューリングするために用意することができ、プロセスジョブは、各コマンドについてのスケジュールされた実行時間を備え、所定の期間は、プロセスジョブ中の対応するコマンドについてのスケジュールされた時間を判断するのに使われる。

プロセスプログラムは、対応する第１のコマンドについての第１の所定の期間を定義することができ、要素制御ユニットは、期間の時間切れまで、第１のコマンドの実行状況にかかわらず、第１のコマンドに続く次のコマンドの開始を遅らせるように用意することができる。プロセスジョブのコマンドの実行のスケジュールされたタイミングは、先行ステップにあるコマンドの完了成功または実行の失敗に関する、サブシステムからのフィードバックに依存しない。サブシステムが、コマンドの実行が完了したと報告した場合、要素制御ユニットは、次のコマンドを実行する前に、次のコマンドについてのスケジュールされた実行時間まで待つように用意される。サブシステムが、コマンドの実行における失敗またはエラーを報告した場合、要素制御ユニットは、次のコマンドについてのスケジュールされた実行時間まで待ち、次いで、次のコマンドの実行を進める。プロセスプログラムのコマンドの実行におけるどのようなタイミング変化も、プロセスジョブのスケジューリングにおいて考慮されるので、コマンドの実行のためのスケジュールされた時間は、最大予想実行時間よりも大きい。時間スケジュールは通常、プロセスジョブの中で定義される。

要素制御ユニットは、１つのアクションまたは複数のアクションについての１つまたは複数のパラメータを、制御ネットワークを介してサブシステムに送り、その後、１つのアクションまたは複数のアクションに対応するコマンドをリソグラフィサブシステムに送ることによって、サブシステムのうちの１つによってアクションまたは一連のアクションを開始するように用意することができる。要素制御ユニットは、コマンドを実行するためのスケジュールされた時間より一定期間だけ前に、サブシステムに１つまたは複数のパラメータを送るように用意することができ、期間は、コマンドがサブシステムに送られる前にサブシステムが１つまたは複数のパラメータを受信したことを保証するのに十分である。１つまたは複数のパラメータは、どの１つのメッセージもサイズが制限されるように、１つまたは複数のメッセージに入れて送信すればよい。パラメータは大量のデータを備え得るので、１つまたは複数のパラメータを含む比較的大きいメッセージは、サブシステムへの送信のタイミングが限界でないときに前もって送られる。コマンドのみを含む（関連パラメータなしの）はるかに小さいメッセージは、コマンドの実行のためにスケジュールされた時間に送ればよい。この措置により、コマンドが送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できるコマンド送信が増える。

要素制御ユニットによって発行されたコマンドに対応する１つのアクションまたは一連のアクションが完了すると、１つのアクションまたは一連のアクションを完了したリソグラフィサブシステムは、要素制御ユニットに完了を通知するために用意され、要素制御ユニットから命令を受信すると、１つのアクションまたは一連のアクションの実行に関するデータを発行するように用意され得る。要素制御ユニットが、１つのアクションまたは一連のアクションの完了の通知をサブシステムから受信すると、要素制御ユニットは、１つのアクションまたは一連のアクションの実行に関するデータを送信するためのリクエストをサブシステムに送ることができる。こうすることにより、完了通知が送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できる送信が増え、データは次いで、後で、タイミングが限界でないときに取り出すことができる。

プロセスプログラムは、条件ステップを含まないようにプログラムすることができる。プロセスプログラムは、代替コマンドとして、プログラムされた条件ステップを含んでよく、代替コマンドは、プロセスジョブ内で並列にスケジュールされ、コマンドの各々には同じ実行時間が割り当てられ、その結果プロセスジョブの実行時間は全体として、どの代替コマンドが実行のために選択されるかによって変わらない。

リソグラフィサブシステムは、要素制御ユニットからのコマンドの受信を肯定応答するための肯定応答を、要素制御ユニットに送信するように用意することができる。肯定応答は、要素制御ユニットによって、予想通りサブシステムが応答を停止したときを検出するのに使うことができる。肯定応答は、サブシステムが関連コマンドを受信しているとともに依然として機能しているという確認、肯定応答を送るサブシステムの識別情報、およびタイムスタンプ以外の、どの他の情報も運ばないように構成することができる。サブシステムは、プロセスジョブ向けのコマンドを実行するためのタイムアウトをもたずに用意することができる。要素制御サブシステム内でのタイムアウトは、サブシステムからの肯定応答に対する予想応答時間よりもはるかに長い時間期間にセットすることができる。このタイムアウトは、サブシステムが機能していないと合理的疑いの余地なく結論づけるのに十分に大きいが、オペレータが通常よりも前に失敗を検出するのには十分に小さい。

ソフトウェアをアップデートまたはアップグレードするための、サブシステム内のソフトウェアの修正は、要素制御ユニット内でプロセスジョブを実行することによって実施される。この修正は、サブシステムの基本オペレーティングシステムソフトウェア、またはサブシステムのどのアプリケーションもしくはユーティリティソフトウェアも修正することを含み得る。この修正により、サブシステムソフトウェアのアップデートまたはアップグレードなど、リソグラフィ動作とサービスアクションの両方のための単一のインターフェース方法が可能になる。

制御ネットワークは、リアルタイム通信プロトコルを使わずに、準リアルタイム性能を提供するように用意することができる。

各リソグラフィ要素は、リソグラフィサブシステムから少なくとも１つのデータネットワークハブへのデータロギング情報の通信用に用意されたデータネットワークをさらに備えることができ、リソグラフィサブシステムは、データネットワークハブにデータロギング情報を送信するように用意され、データハブは、データロギング情報を受信および記憶するために用意され、フロントエンドは、データネットワークハブによって受信されたデータロギング情報の少なくとも一部分を受信するためにさらに用意される。このネットワークアーキテクチャは、制御およびデータ機能を、別個のネットワークに分離させる。制御機能は、双方向データフローを必要とし、制御ネットワークを介した予測可能な情報転送を必要とする。データ収集および管理機能は概して、リソグラフィサブシステムから、データネットワーク内で上方向にデータネットワークハブへ、およびクラスタインターフェースに向かって前方への一方向の流れを必要とし、非常に大量のデータを伴い得る。リソグラフィサブシステムは、第１の送信レートでデータネットワークにデータを送信するように用意することができ、データネットワークハブは、第２の送信レートでデータネットワークからデータを受信するように用意され、第２の送信レートは、第１の送信レートよりもはるかに大きい。

制御ネットワークは、ＴＣＰリンク上でバイト送信プロトコルを使うことができる。要素制御ユニットおよびリソグラフィサブシステムは、制御ネットワーク上でメッセージシーケンスを送信するように用意することができ、メッセージシーケンスの第１のメッセージは２つの要素を備え、第１の要素は、メッセージタイプをもつストリングを含み、第２の要素は、メッセージについての名前付き引数をもつ辞書を含む。メッセージシーケンスの第１のメッセージは、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（ＪＳＯＮ）でエンコードされた制御データ構造を含み得る。メッセージシーケンスの第２のメッセージは、１つまたは複数のエンコードされたデータメッセージを備えることができ、データメッセージのエンコードは、制御ネットワークプロトコルによって設定または制限されない。任意のメッセージを制御メッセージと混合するこの方式により、プロセスジョブコマンドおよび出力が、オペレータに理解されるデータフォーマットで直接生じられ、そのようなメッセージを追加エンコードなしで送信することが可能になる。

制御ネットワークは、制御ネットワーク上で複数のデータ転送が同時に起こることがないように用意されたコントローラも含み得る。

次に、本発明の実施形態を、添付の概略図を参照して、例としてのみ説明する。

本発明によるリソグラフィシステム用のネットワークアーキテクチャの実施形態の概略図。 リソグラフィ要素のクラスタを備えるリソグラフィシステム用ネットワークアーキテクチャの実施形態の概略図。 リソグラフィ要素のクラスタのレイアウトの図。 荷電粒子リソグラフィ要素の電子光学カラムの簡略図。 本発明の一実施形態によるリソグラフィツール用のＯＳＩ階層化モデルにおける要素制御ユニットプロトコルの概略図。 本発明の一実施形態による接続シーケンスの概略図。 本発明の一実施形態による再接続シーケンスの概略図。 本発明の一実施形態によるコマンド実行シーケンスの概略図。 本発明の一実施形態による破棄シーケンスの概略図。 本発明の一実施形態による、競合状態を有する破棄シーケンスの概略図。 本発明の一実施形態による、汎用コマンド中の例外シーケンスの概略図。 本発明の一実施形態による自発的例外の概略図。 本発明の一実施形態による実行コマンド中の例外の概略図。

以下では、単に例として、図面を参照して挙げられる、本発明のいくつかの実施形態について説明する。

図１は、本発明による、制御およびデータインターフェースを有するリソグラフィシステム１の一実施形態の概略図である。この図は、３つのインターフェース、すなわちクラスタインターフェース３、クラスタ要素インターフェース５、およびリソグラフィサブシステムインターフェース７を有する階層的配置を示す。図１は、複数のリソグラフィサブシステム１６を備える１つのリソグラフィ要素１０を備えるリソグラフィシステムクラスタを有する構成を示す。リソグラフィシステムは、たとえば図２の実施形態でのように、複数のリソグラフィ要素１０を備えることができる。

クラスタインターフェース３は、リソグラフィクラスタフロントエンド６と１つまたは複数のホストシステム２との間、ならびに／あるいはクラスタフロントエンド６と１つまたは複数のオペレータコンソール４との間の通信用のインターフェースを備える。

クラスタ要素インターフェース５は、クラスタフロントエンド６と、要素制御ユニット１２および／またはデータネットワークハブ１４を備えるリソグラフィ要素ネットワークとの間の通信用のインターフェースを備える。要素制御ユニット１２は、リンク１０６を介してデータネットワークハブ１４と通信することができ、通信は好ましくは、要素制御ユニット１２からデータネットワークハブ１４への一方向である。

リソグラフィサブシステムインターフェース７は、要素制御ユニット１２とリソグラフィサブシステム１６との間の、ならびにデータネットワークハブ１４とリソグラフィサブシステム１６との間のインターフェースを備える。サブシステム１６は、制御ネットワーク１２０を介して要素制御ユニット１２と通信し、サブシステム１６は、データネットワーク１４０を介してデータネットワークハブ１４と通信する。

図２は、リソグラフィシステムクラスタが複数のリソグラフィ要素１０を備えるリソグラフィシステム１の実施形態の概略図であり、各要素は、複数のリソグラフィサブシステム１６を備える。各要素は、要素向けのリソグラフィサブシステム１６と通信する要素制御ユニット１２とデータネットワークハブ１４とを備えることができる。各要素は、リソグラフィプロセスを用いてウエハを露光するように独立して動作することが可能なスタンドアロンリソグラフィ要素として機能することができる。本実施形態では、複数のリソグラフィ要素１０は各々、単一のフロントエンド６と通信し、フロントエンド６は、クラスタ全体のために機能する１つまたは複数のホストシステム２および／またはオペレータインターフェース４と通信する。

図１および図２の実施形態は好ましくは、リソグラフィ要素のクラスタの効率的制御を円滑にするように設計される。各リソグラフィ要素１０は好ましくは、制御ネットワーク１２０およびデータネットワーク１４０へのネットワークインターフェースを有するだけである。この設計規則に対する例外は、データ経路２０が、荷電粒子ビームの変調または切替えを担うサブシステム（複数）にパターンストリーマ１９を直接接続することである。パターンデータは、最初にパターンデータ処理システム１８内で準備され、データ変換およびサブシステムへのストリーミングのためにパターンストリーマ１９に送られる。この設計は、極度に大量のパターンデータが関連サブシステム（複数）に転送されるためである。パターンデータは通常、サブシステムにおいてローカル記憶するにはデータ量が多すぎるので、ビットマップ形式で関連サブシステムにストリーミングされる。

オペレータインターフェースならびにより高レベルのホスト監視および自動化コンピュータへのインターフェースは、個々のリソグラフィ要素なしではあるが、クラスタフロントエンド６において作られる。こうすることにより、そのようなインターフェースは、リソグラフィ要素１０に対するインターフェースプロトコルについて知る必要なく、ならびに追加要求を行わず、制御ネットワーク１２０およびデータネットワーク１４０にわたる通信と干渉せずに、クラスタ用に開発されることが可能になる。

図３は、リソグラフィシステムクラスタ１の簡略平面図を示す。本実施形態では、クラスタは、５個ずつ２行に連続して用意される、１０個のリソグラフィ要素１０からなるグループを備える。クラスタ１に直接隣接して、床面積がサービスエリア２３として確保される。各リソグラフィ要素は、それ自体の真空室に含まれる電子光学カラムを備え、各真空室の片側は基板受渡しシステム２２とサービスエリア２３とに面する。基板受渡しシステム２２は、基板供給システム２４から基板を受け取り、基板を加工のためにリソグラフィ要素１０に供給し、加工された基板をリソグラフィ要素１０から受け取り、加工された基板を、工場内の他のシステムに転送するために基板供給システム２４に供給する。

荷電粒子リソグラフィ装置のケースでは、真空室は好ましくは、複数の荷電粒子ビームレットを生成するための荷電粒子源および成分と、ビームレットを切り替え、または変調するビーム変調システムと、パターニングされるべき基板上にビームレットを投射するためのプロジェクタシステムと、可動基板台とを封入する。真空室は好ましくは、基板受渡しシステム２２から真空室の中および外に基板を移すためのロードロックシステム、および電子光学カラムへのサービスアクセスのために開けることができるサービスエリア２３に面する点検口も含む。

各リソグラフィ要素１０は、ウエハを受け取り、加工するように独立して動作する。各リソグラフィ要素は、データを処理し、リソグラフィ要素の構成要素とサブシステムとを操作するための独自のコンピュータ処理システムを含む。各リソグラフィサブシステム１６は好ましくは、サブシステムの動作を指示し、サブシステムの動作の結果生じたデータを収集し、制御およびデータネットワークと通信するためのコマンドを実行するために、独自のコンピュータプロセッサとメモリシステムとを有する。制御要素ユニット１２およびデータネットワークハブ１４は好ましくは、各々が、それらの機能を実施するための、独自のコンピュータプロセッサとメモリシステムとを備える。リソグラフィ要素１０用の制御要素ユニット１２、データネットワークハブ１４、およびサブシステム１６のためのコンピュータプロセッサおよびメモリシステムは、リソグラフィ要素用の真空室に極めて近接して、たとえば真空室の上に取り付けられた、真空室の下の下部構造、または各場所の一部にあるキャビネット内に用意すればよい。

クラスタのリソグラフィ要素の連続レイアウトにより、システムには限られたフットプリントが与えられ、コンピュータプロセッサおよびメモリシステムを真空室のすぐ上または下に用意すると、フットプリントが削減される。工場内の床面積は貴重なので、工場の床面積を効率的に使用することが重要である。

図４は、荷電粒子リソグラフィ要素の電子光学カラムの簡略図を示す。そのようなリソグラフィシステムは、たとえば、本発明の所有者にすべて譲渡されているとともにすべて参照により全体が本明細書に組み込まれている米国特許第６，８９７，４５８号、第６，９５８，８０４号、第７，０１９，９０８号、第７，０８４，４１４号、および第７，１２９，５０２号、米国特許公開第２００７／００６４２１３号、ならびに同時係属中の米国特許出願第６１／０３１，５７３号、第６１／０３１，５９４号、第６１／０４５，２４３号、第６１／０５５，８３９号、第６１／０５８，５９６号、および第６１／１０１，６８２号に記載されている。

図４に示す実施形態では、リソグラフィ要素カラムは、コリメータレンズシステム１１３によって平行にされる拡大電子ビーム１３０を生じる電子源１１０を備える。平行電子ビームは、開口アレイ１１４ａの上で衝突し、アレイ１１４ａはビームの一部を遮断して複数のサブビーム１３４を生じ、サブビーム１３４は、サブビームを集束させるコンデンサレンズアレイ１１６を通過する。サブビームは、各サブビーム１３４から複数のビームレット１３３を生じる第２の開口アレイ１１４ｂの上で衝突する。システムは、非常に多数のビームレット１３３、好ましくは約１０，０００〜１，０００，０００個のビームレットを生成する。

複数のブランキング電極を備えるビームレットブランカアレイ１１７は、ビームレットのうち選択されたものを偏向させる。非偏向ビームレットは、ビーム停止アレイ１１８に届き、対応する開口を通過するが、偏向ビームレットは、対応する開口を通らず、ビーム停止アレイによって停止される。したがって、ビームレットブレーカアレイ１１７およびビーム停止１１８は、個々のビームレットをオンおよびオフに切り替えるように、共同で動作する。非偏向ビームレットは、ビーム停止アレイ１１９と、ビームレットを偏向させて、目標または基板１２１の表面にわたるビームレットを走査するビーム偏向器アレイ１１９とを通過する。次に、ビームレットは、投射レンズアレイ１２０を通過し、基板を載せるための可動台上に位置する基板１２１の上に投射される。リソグラフィアプリケーションのために、基板は一般に、荷電粒子敏感層または抵抗層が設けられたウエハを備える。

リソグラフィ要素カラムは、真空環境において動作する。荷電粒子ビームによってイオン化し、発生源に引きつけることができ、解離し機械構成要素の上に堆積することができ、荷電粒子ビームを分散させることができる粒子を取り除くのに、真空が所望される。少なくとも１０^-6バールの真空が通常、必要とされる。真空環境を維持するために、荷電粒子リソグラフィシステムは、真空室内に用意される。リソグラフィ要素の主要要素はすべて、好ましくは、荷電粒子源と、基板上にビームレットを投射するためのプロジェクタシステムと、可動台とを含む共通真空室に収容される。

サブシステム
図１および図２の実施形態において、各リソグラフィ要素１０は、ウエハを露光するための独立動作リソグラフィ要素を形成する。各リソグラフィ要素１０は、要素に必要とされる機能を実施するように動作する複数のサブシステム１６を備える。各サブシステムは、特定の機能を実施する。典型的なサブシステム１６には、たとえば、ウエハロードサブシステム（ＷＬＳ）、ウエハ位置決めサブシステム（ＷＰＳ）、電子ビームレットを生成するための照明光学サブシステム（ＩＬＯ）、リソグラフィ要素にビーム切替えデータをストリーミングするためのパターンストリーミングサブシステム（ＰＳＳ）、電子ビームレットをオンおよびオフに切り替えるためのビーム切替えサブシステム（ＢＳＳ）、ウエハ上にビームレットを投射するための投射光学サブシステム（ＰＯＳ）、ビーム測定サブシステム（ＢＭＳ）、計測サブシステム（ＭＥＳ）などがある。各リソグラフィ要素１０は好ましくは、ウエハを受け取り、各ウエハをチャックにクランプするとともにクランプされたウエハを露光用に準備し、クランプされたウエハを露光し、露光されたウエハをチャックからクランプ解除し、露光されたウエハを、要素から取り除くために示すために構成される。

各サブシステム１６は、特定のサブ機能に専用であるとともに好ましくは交換可能構成要素として設計される１つまたは複数のモジュール１７を備えることができる。モジュール１７は、アクチュエータ１９とセンサ２１とを備えることができ、アクチュエータ１９はコマンドを実施することが可能であり、センサ２１は、アクションと結果とを検出し、コマンドの実施の間、前および／または後に測定を行うことができる。そのようなモジュールの例には、露光中の基板を移動するための台、台の制御のための制御コンピュータ、基板の上にビームレットを投射するためのレンズアレイに電圧を供給する投射レンズモジュール、真空室内で真空を生成するための真空ポンプなどがある。

各サブシステム１６は、独立して動作し、命令を記憶するためのメモリと、命令を実行するためのコンピュータプロセッサとを含む。メモリおよびプロセッサは、各サブシステム内でプラグインクライアント（ＰＩＣ）１５として実装することができる。サブシステムの適切な実施態様は、たとえば、Ｌｉｎｕｘ（登録商標）オペレーティングシステムを稼動するパーソナルコンピュータを含み得る。サブシステムは、それらのオペレーティングシステムを記憶するためのハードディスクまたは不揮発性メモリを含むことができ、それにより、各サブシステムは、このディスクまたはメモリからブートする。後で論じるこれらおよび他の特徴により、各サブシステムが、他のサブシステムによって課される制約を検討する必要なく、独立ユニットとして設計、構築および検査され得る自律ユニットである設計が可能になる。たとえば、各サブシステムは、その動作周期中に、他のサブシステムによって行われた、メモリおよび処理容量に対する要求を考慮に入れる必要なく、サブシステムの機能を正しく実施するのに十分なメモリおよび処理容量をもたせて設計すればよい。この設計は、これらの必要条件が流動的であるとき、システムの開発およびアップグレード中は特に有利である。この設計の欠点は、総必要メモリおよび処理容量が増え、これらの構成要素の冗長性が、各サブシステム内で実装されなければならないことである。ただし、これらの欠点よりも、より速い開発およびより簡単なアップグレードにつながる簡略設計が勝る。

サブシステム１６は、制御ネットワーク１２０を介してコマンドを受信し、他のサブシステムから独立してコマンドを実行するように設計され、コマンド実行についての結果を報告し、どの生じた実行データもリクエストに応じて転送する。

サブシステム１６は、自律単位として設計されるが、たとえばデータネットワークハブ上の中央ディスクまたはメモリからブートするように設計され得る。こうすることにより、各サブシステム内の個々のハードディスクまたは不揮発性メモリの信頼性問題およびコストが下がり、中心的場所にサブシステムのブートイメージをアップデートすることによって、サブシステムをより簡単にソフトウェアアップグレードすることが可能になる。

通信プロトコル
サブシステム１６は、制御ネットワークを介して、サポートサブシステム制御またはＳＵＳＣとも呼ばれる要素制御ユニット１２に接続される。要素制御ユニット１２は、メモリと、リソグラフィ要素１０用のサブシステムの動作を制御するためのコンピュータプロセッサとを備える。

クラスタフロントエンド６とＳＵＳＣ１２との間の通信１０２は、ＳＵＳＣ１２にＰＰを転送するために設計される。ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（ＪＳＯＮ）に基づくプロトコルを使うことができる。ＪＳＯＮは、人間可読データ交換のために設計され、単純データ構造とアレイとを表すために使われる、テキストベースのオープンスタンダードであり、構造化データを直列化し、ネットワーク接続を介して送信するのに適している。プロトコルへのアクセスは好ましくは、クラスタにおけるユーザに制限され、クリーンルーム環境の外のユーザには制限されない。プロトコルは好ましくは、ＰＪの作成、ＰＰファイルおよび任意の関連パラメータの転送のための命令を与えて、ＳＵＳＣ１２に、ＰＰに基づいてＰＪを作成するよう命令する。追加コマンドは、破棄および取消し命令を含み得る。ＳＵＳＣ１２からクラスタフロントエンド６への通信は、肯定応答メッセージと、経過報告と、エラーおよびアラームメッセージとを含み得る。

制御ネットワーク１２０を超える、ＳＵＳＣ１２とリソグラフィサブシステム１６との間の通信１０１は好ましくは、ネットワーク内での準リアルタイム性能を確実にするように、要素制御ユニットプロトコルのみを使って厳しく制御される。図５は、ＯＳＩ（開放型システム相互接続）階層化モデルにおける要素制御ユニットプロトコルの一実施形態を示す。要素制御ユニットプロトコルについては、後でさらに詳しく説明する。

ＳＵＳＤ１４とクラスタフロントエンド６との間の通信１０５は、ＳＵＳＤ１４からのＰＪ結果の取出し、ジョブ追跡およびデータロギングのために設計される。ハイパーテキスト転送プロトコル（ＨＴＴＰ）が、この通信リンク用に使われ得る。

リソグラフィサブシステム１６とＳＵＳＤ１４との間の通信１０３は、サブシステム１６からの単方向のデータ収集のために設計される。データは、たとえばｓｙｓｌｏｇ、ＨＤＦ５、ＵＤＰなど、様々なプロトコルを使って通信され得る。

ハンドシェイク、誤り検査および訂正の大きいオーバーヘッドなしでデータを送るためのユーザデータグラムプロトコル（ＵＤＰ）を使って、高容量データを送ることができる。生じる送信オーバーヘッドが非常に低いので、データは、リアルタイムに受信されると見なしてよい。

階層データフォーマットＨＤＦ５は、高頻度のデータ送信および記憶に使うことができる。ＨＤＦ５は、大量の数値データの記憶および体系化に好適であるが、一般に、ＵＤＰ環境では使われない。特に低レベル（低容量）データには、ＣＳＶやＴＣＰなどの他のデータフォーマットを使ってもよい。

プロセスプログラム
リソグラフィ要素１０の動作は、実施されるべき一連のアクションを備えるプロセスプログラム（ＰＰ）１１を使って制御される。要素制御ユニット１２には、ＰＰがロードされ、オペレータコンソール４を介したホストシステム２またはオペレータによるリクエストに応じて、ＰＰ１１をスケジュールし、実行する。ＰＰ１１は、たとえば、ＳＥＭＩ Ｅ４０標準において定義されるレシピの役割を担うことができる。ＳＥＭＩ標準は、レシピをどのように扱うかに関して多くの必要条件を指定するが、標準は矛盾する場合があるので、レシピは好ましくは回避される。そうではなく、編集可能でありフォーマットされていないＰＰが、いわゆるバイナリラージオブジェクト（ブロブ）の形で使われる。

ウエハの処理環境を決定し、稼動または処理周期の間の変化を被り得る命令、設定およびパラメータのセットの、事前計画された再利用可能部分としてのＰＰ。ＰＰは、リソグラフィツール設計者によって設計し、またはツール使用によって生成することができる。

ＰＰは、ユーザによってリソグラフィシステムにアップロードすることができる。ＰＰは、プロセスジョブ（ＰＪ）を作成するのに使われる。プロセスジョブ（ＰＪ）は、リソグラフィ要素１０によって１つのウエハまたはウエハセットに適用されるべき処理を指定する。ＰＪは、指定されたウエハセットを処理するとき、どのＰＰを使うべきか定義し、ＰＰからの（および任意選択でユーザからの）パラメータを含み得る。ＰＪとは、ユーザまたはホストシステムによって開始されるシステム活動である。

ＰＰは、ウエハの処理の制御だけでなく、サービスアクション、キャリブレーション機能、リソグラフィ要素検査、要素設定の修正、ソフトウェアのアップデートおよびアップグレードなどにも使うことができる。好ましくは、ＰＪ実行、および予期せぬ電源切断、緊急またはＥＭＯ活動化への応答に影響しない限り、モジュールまたはサブシステムの電源起動中の自動初期化、サブシステムの定期的な無条件挙動など、いくつかの認められた追加カテゴリを例外として、ＰＰにおいて規定されるもの以外のどのサブシステム挙動も起こらない。

ＰＰは、ステップに分割される。ほとんどのステップは、コマンドを備え、コマンドを実施するためのサブシステムを識別する。ステップはまた、コマンドを実施する際に使われるべきパラメータと、パラメータ制約とを含み得る。ＰＰは、ステップが実施されるべきである、たとえば並行して、順に、または同期されて実施されるべきであるときを示すためのスケジューリングパラメータを含み得る。

ＰＪのコマンドステップを実行するために、要素制御ユニット１２は、ＰＪ中に示されたコマンドを、ＰＪの関連ステップで示されたサブシステムに送る。要素制御ユニット１２は、タイミングをモニタし、結果をサブシステムから受信する。具体的なコマンドの実行例については、図６〜図１３に示し、後で説明する。

プラグインコマンドの概念
要素制御ユニット（ＳＵＳＣ）１２は、ＰＰ（論理プランを表す）を、サブシステムアクションのスケジュールに変換する。システムは、どのサブシステム１６がインストールされるか、およびどのサブシステムコマンドが存在し、コマンドのプロパティがどのようなものであるかについての予備知識をＳＵＳＣ１２がもたないように設計してよい。この場合、この情報は、起動中のサブシステム１６によってランタイムにＳＵＳＣ１２に与えられる。

各サブシステム１６は、サブシステムが電源投入および初期化されるとき、サブシステムの存在と能力とをＳＵＳＣ１２に報告するように設計してよい。サブシステムは、制御ネットワーク１２０を介して通信を確立し、サブシステムの識別情報と状況とをＳＵＳＣ１２に報告し、また、どのコマンドを実施することが可能かなど、サブシステムの能力を報告すればよい。ＳＵＳＣ１２は、ＰＰに必要とされる各サブシステムがサブシステムの存在と即応状況とを報告したＰＰ１１の実行の前または実行中に検査を実施することができ、各サブシステムが、ＰＰにおいてサブシステムに必要とされるコマンドを実施するためのサブシステムの能力を報告したということをチェックすることもできる。

サブシステムによる、この自己報告により、リソグラフィシステムは、サブシステムへの局所的なソフトウェアアップグレードのみを使う新規機能性で、またはソフトウェアアップグレードなしでも、拡張またはアップグレードされることが可能になる。たとえば、特定のサブシステム１６は、そのソフトウェアを、新規コマンドを実行することができるようにアップグレードさせてよい。ＳＵＳＣ１２には今では、アップグレードされたサブシステム向けの新規コマンドを含む新規ＰＰ１１をロードすることができる。アップグレードされたサブシステム１６は、電源投入されると、要素制御ユニット１２と通信し、ユニット１２の識別情報および状況と、新規コマンドを含む、どのコマンドを実行することができるかとを示す。ＳＵＳＣ１２は、新規コマンドを実行するようサブシステムに指令するステップを含むＰＪを生成するように、ＰＰをスケジュールする。ＳＵＳＣ１２は、アップグレードされたサブシステムが、新規コマンドを実施可能であると報告した検査を実施することができる。このアップグレードはしたがって、関連サブシステムおよびＰＰのアップグレードのみを必要とし、ＳＵＳＣ１２または他のサブシステム１６のうちいずれのアップグレードも必要としない。

制御ネットワーク
制御ネットワーク１２０は好ましくは、リアルタイムの通信プロトコルを使わないが、それにもかかわらず、準リアルタイム性能を可能にするように設計され、高い再現性、たとえば実質的に１ミリ秒以内の再現性を伴うサブシステムとＳＵＳＣ１２との間の通信を可能にして、同じタイミング挙動をもたらす同じ条件下での同じジョブの実行を可能にする。

制御ネットワーク１２０にわたるこの準リアルタイム性能は、以下の措置の一部または全部を実施することによって実現することができる。

（ａ）リソグラフィシステムは、ＰＪの実行を始めるのに先立ってＰＪを生成するように各ＰＰをスケジュールし、ＰＪの各ステップを始める時間（完了時間も含み得る）を判断する。各ステップについて、および完了ＰＪのスケジュールされた開始時間（および完了時間）は、ＰＪが開始される前に完全に判断することができ、これらの時間は、クラスタフロントエンドに報告すればよい。

（ｂ）ＰＰ（およびＰＪ）は、条件ステップもアクションも、および再試行ももたずに設計することができる。ＰＰ／ＰＪのステップは、一連のアクションを記述するが、リソグラフィ要素内でのアクションは、並行して実施することができ、たとえばコマンドは、異なるサブシステム上で並行して実行する。条件ステップまたはアクションは、実施するべき２つ（またはそれ以上）の代替ステップを定義することによって、ＰＰにおいてプログラムすることができ、代替ステップは、並列パスとして用意される。代替ステップは、ＰＪにおいて、各々に同じ実行時間が割り当てられる並列パスとしてスケジュールされ、その結果、全体としてＰＪの実行時間は、サブシステム上での実行のためにどの代替パスが選択されるかによって変わることはない。

ＰＪのステップの実行時間は、先行または並列ステップの結果を条件とするのではなく、所定のスケジュールに従って実行される。ステップが、正しくまたはスケジュールされた時間内に完了しない場合、ステップは、再度実行されることはなく（すなわち、再試行はなく）、代わりに次のスケジュールされたステップが実行される。

（ｃ）スケジューリングの後、すべてのステップが、所定のスケジュールされた時間に、好ましくは約１ミリ秒のタイミング精度でＳＵＳＣ１２によって実行される。スケジュールされた時間に、ＳＵＳＣ１２は、関連ステップを実行し、そのステップのためのどのコマンドも、サブシステムによって実行するために関連サブシステム１６に送る。ＳＵＳＣ１２におけるスケジュールされたタイミングは、先行ステップからの完了の成功またはコマンドの実行の失敗にさえ関する、サブシステム１６からのフィードバックに依存しない。ステップが実行期間を定義する場合、ＳＵＳＣ１２は、ＰＪの次のステップに進む前に、その期間が経過するのを待つ。サブシステムが、この期間の時間切れの前にコマンドの実行からの結果を戻す場合、ＳＵＳＣ１２は依然として、次のステップに進む前に、期間の時間切れを待つ。サブシステムがエラーメッセージを戻すのに失敗した場合、ＳＵＳＣ１２はそれにもかかわらず、期間の時間切れを待ち、次いで、次のステップに進む。サブシステムがコマンドを正しく実行するのに失敗した場合、オペレータまたはホストシステムは、どのような訂正アクションが必要となり得るか判断する。

ステップの実行におけるどのようなタイミング変化も、スケジューリングにおいて考慮されるので、ステップの実行のためのスケジュールされた時間は、最大予想実行時間よりも長い。時間スケジュールは通常、ＰＰにおいて定義される。スケジューリングの瞬間は、実行が始まる前の「ジャストインタイム」でも、実行前のどこかの時点、たとえば実行キューにステップを追加するときでもよい。

（ｄ）サブシステム１６によって送られ、実行されるコマンドは、最大時間が固定されたコマンドの実行を指定する。最大実行時間は、その状況が与えられたうえでの、サブシステムによって判断された所定の最大期間である。この時間を超えた場合、オペレータまたはホストシステムは、どのような訂正アクションが必要となり得るか判断する。

（ｅ）サブシステムが実施するべきコマンドと、関連サブシステムに送られるべきコマンドに関連付けられたデータとを有するＰＪステップを実行するとき、データは、コマンド自体がサブシステムに送られる前に、サブシステムに送信すればよい。データは、どの１つのメッセージもサイズが制限されるように、１つまたは複数のメッセージに入れて送信される。データは、サブシステムによって確実に受信されているように、十分に前もって送られ、すなわち、データの送付とコマンドの送付との間の時間は、予想送信時間よりもはるかに大きく、サブシステムは、データの受信に肯定応答することができる。これにより、タイミングが限界でないとき、データを含む比較的大きいメッセージが前もって送られることが可能になり、コマンド（関連データなし）のみを含むはるかに小さいメッセージを、スケジュールされた時間に送ることができる。この措置により、コマンドが送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できるコマンド送信が増える。

（ｆ）同様に、サブシステムは、コマンドの実行を完了すると、コマンドが完了したことを示すショートメッセージをＳＵＳＣ１２に送ることができるが、コマンドの実行の結果として生じたどのデータも、後の時点でＳＵＳＣ１２によって取り出すために保持している。ＳＵＳＣ１２は、コマンド完了の指示を受信すると、生じたデータを取り出すためのリクエストをサブシステムに送ることができる。こうすることにより、コマンド完了指示が送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できる送信が増え、データは次いで、タイミングが限界でないとき、後で取り出すことができる。

（ｇ）サブシステム１６とＳＵＳＣ１２との間のメッセージ交換は、ＳＵＳＣ１２からの命令の受信に肯定応答するための返答メッセージを含む。返答メッセージは、サブシステム１６がＳＵＳＣ１２から関連メッセージを受信し、依然として機能しているという確認以外の、どの他の情報も運ばない。これにより、ＳＵＳＣ１２は、予想通り、サブシステム１６が応答するのをいつ停止したかを検出することが可能になるので、検出内容は、適時にクラスタフロントエンドに報告することができる。ソフトウェア実施態様を単純に保つために、サブシステム１６に対してタイムアウトはない。返答メッセージについて予想される総応答時間は通常、短く、たとえば往復で０．５ｍｓ未満である。非応答サブシステム１６を検出するために、ＳＵＳＣ１２には、予想応答時間をはるかに超える、たとえば応答が予想される後に３０秒のタイムアウトがある。このタイムアウトは、サブシステム１６が機能していないと合理的疑いの余地なく結論づけるのに十分に大きいが、オペレータ４が正常に結論づける前に失敗を検出するのには足りない程小さいので、オペレータ４は、何が起きているかを思案しなくてよい。

（ｈ）制御ネットワーク１２０は、データパッケージの一度の転送、たとえば一度に単一のメッセージシーケンスを安全にするプロトコルコントローラを含む。

（ｉ）制御ネットワークは、単純送信プロトコル、たとえばＴＣＰリンクでのバイトプロトコルを使う。複雑であり、または予測不可能な要素を含む送信プロトコルは回避される。制御ネットワークにおいて使われるプロトコルにより、確実に複数のデータ転送が同時には起こり得なくなるので、ネットワーク上での予測不可能なイベントは起こらない。

ＴＣＰ接続は、２つのバイトストリームからなり、各方向に１つのバイトストリームがある。プロトコルは、これらのストリームの両方を別々のメッセージに分解し、各メッセージは、０バイト以上の任意のデータのシーケンスであり、シーケンスの長さを示す４バイトが先行する。この長さは、ネットワークオーダー（「ビッグエンディアン」）で符号なし整数、たとえば３２ビット整数としてエンコードすることができ、（２３２−１）バイトの最大メッセージサイズを与える。このメッセージ分離機構は、Ｐｙｔｈｏｎプログラミング言語で「接続オブジェクト」によって実施することができる。標準多重処理接続パッケージを使うことによって、Ｐｙｔｈｏｎ自体が、プロトコルのこの部分を扱うことができる。他のプログラミング環境では、この態様を明示的に実施することが必要になる。メッセージは、規定されたシーケンスにメッセージが続くのであれば、どちら側によって開始されてもよい。

メッセージシーケンスのすべての第１のメッセージは、ＪａｖａＳｃｒｉｐｔオブジェクト表記法（ＪＳＯＮ）でエンコードされた制御データ構造を含み得る。ＳＵＳＣプロトコルＪＳＯＮメッセージはすべて、同じ一般的構造、すなわち２つの要素のアレイを有してよく、第１の要素は、メッセージタイプをもつストリングを含み、第２の要素は、そのメッセージについての名前付き引数をもつ辞書を含み、たとえば［“＜ｍｅｓｓａｇｅＴｙｐｅ＞”，｛“ｐａｒａｍ１”：＜ｖａｌｕｅ１＞，“ｐａｒａｍ２”：＜ｖａｌｕｅ２＞，．．．｝］となる。

いくつかのメッセージシーケンス、たとえばインターフェースコマンドの入力および出力項目を転送するのに使われるシーケンスでは、この制御／コマンドメッセージのすぐ後に、いくつかのデータメッセージ、たとえば入出力項目ごとに１つのデータメッセージが続く。プロトコルは、これらのメッセージ中で使われるエンコードについて想定しておらず、代わりにサブシステムコマンド、データおよび挙動を指定する翻訳、たとえば「ｐｉｃｋｌｅでエンコードされた、２つのフロートのタプルのリスト」、または「画像／ｐｇｎとしての圧力曲線プロット」）が設計文書に記載される。

任意のメッセージをＪＳＯＮ制御メッセージと混合するこの方式により、プロセスジョブ出力が、ＣＳＶ、ＰＤＦ、ＰＮＧなど、オペレータに理解されるデータフォーマットで直接書かれているプラグインソフトウェアによって生じられる。このことは、そのようなオブジェクトの送信が、追加エンコードも、データストリームの一部としてのエスケープもなく、たとえばＬｉｎｕｘのｓｅｎｄｆｉｌｅ関数を使うことによって行われ得ることも意味する。この自由は、特に特定のインターフェース機能に、より適したエンコードについてサブシステムの間で合意するのに利用することもできる。ただし、すべてのサブシステムが独自のデータエンコード方式を有する場合は賢明ではないので、サブシステムに、特定の必要条件がない場合は、必要条件の中で最良のトレードオフを実施するのに、デフォルト方式が選ばれるべきである。

（ｊ）サブシステムは、ＳＵＳＣ１２の正しい挙動の検証は担わず、ＳＵＳＣプロトコルエラーを検出して、ＰＩＣ１５の設計を単純にする。ＳＵＳＣプロトコルの目的は、ユーザによって作成されたプロセスジョブにおいて、プロセスプログラムからのプロセスステップを実行することである。予期せぬ挙動をユーザに通信するために、例外が使われる。コマンド実行におけるエラーに加え、当然ながら、ＳＵＳＣプロトコルに準拠しないことによってもエラーが起こり得る。ＳＵＳＣ１２は、例外のロギングを担い、ＰＩＣがＳＵＳｃプロトコルに従って振る舞っていない（または応答するのを完全に停止した）が、ＰＩＣ必要条件を単純に保つためにＳＵＳＣの正しい挙動の検証をＰＩＣが担っていないときはＰＩＣへの接続を閉じてよい。ＰＩＣがプロトコル違反に遭遇した場合、違反には正常に応答してもしなくてもよく、後続メッセージが理解されなければならないという必要条件はない。メッセージを扱うことができないときは、いくつかの診断をロギングし、例外をロギングし、切断および再接続しようと試みることが推奨される。これは、そのような再接続の後、ＰＩＣが再度、使用可能状態にある（ただし、少なくとも多少は理解できる状態にある）という保証も予想もないので、推奨であって、必要条件ではない。

（ｋ）オペレータおよびより高レベルのオートメーションまたは監視工場コンピュータシステム用のインターフェースが、制御ネットワーク１２０上での通信から削除される。これらのインターフェースは、クラスタフロントエンド６から提供されるので、制御ネットワーク１２０上で輻輳を生成せず、サブシステム１６との通信のタイミングに影響しない。

（ｌ）データ収集は、別個のデータネットワーク１４０内で、制御ネットワーク１２０上での制御通信とは完全に分離される。この機能分離については、後でより詳しく論じる。

同期クロック
リソグラフィシステムは、制御ネットワーク上でクロック信号を提供して、システム内での、およびサブシステムによるアクションの同期を可能にする。システムは、異なる周波数で２つのクロック信号を提供して、異なるタイミング精度に対して、サブシステムにクロックを与えることができ、たとえば１つのクロック信号はミリ秒の精度であり、１つはナノ秒の精度である。たとえば、ビーム切替えデータをストリーミングするためのパターンストリーミングサブシステム、ならびに電子ビームレットをオンおよびオフに切り替えるためのビーム切替えサブシステムは、ビームレットの高頻度切替えを可能にするために、非常に高い頻度でデータを交換する必要があり、ビーム測定サブシステムは、ビーム位置測定値を非常に高い頻度で送ることを必要とされる。高精度クロックを必要とする他の機能には、基板位置決めシステムおよび投射光学システムがある。これらのサブシステムには、同期クロックサブシステムによって与えられるナノ秒クロックパルスによって給電され、そのようなパルスを受信することが可能である。

制御ネットワークプロトコルメッセージ
図６Ａ〜図６Ｈは、プロトコルによってサポートされるメッセージシーケンス３０、４０、５０、７０、８０、９０、１００を示す。シーケンス図３０、４０、５０、７０、８０、９０、１００には、平均的なケースにとって、およびＳＵＳＣ１２が接続を閉じる前に使うタイムアウトにとって必要とされる応答時間が付記されている。記載するタイミングは、原則として、ＳＵＳＣ１２、ＳＵＳＤ１４およびサブシステム１６が関与するラウンドトリップ時間である。

ＳＵＳＣ１２プロトコルは、ＴＣＰ接続を介してメッセージを通信する。ＳＵＳＣ１２はＴＣＰサーバとして作用し、サブシステム１６内のＰＩＣ１５はＴＣＰクライアントとして作用する。ＰＩＣは、特定のポート上のＳＵＳＣ１２への接続を行い、ＳＵＳＣ１２は、制御ネットワーク１２０内のＩＰアドレスを有する。接続が失敗した場合、ＰＩＣは、成功するまで再試行する。図６Ａは、サブシステム１６内の要素制御ユニット（ＳＵＳＣ）１２およびＰＩＣが互いと接続する接続シーケンス３０を示す。メッセージのタイミングを示すために、ＳＵＳＣ１２およびサブシステム１６からの垂直タイムライン２７、２９が示されている。ある時点において、接続シーケンスは、ＴＣＰプロトコルまたはＴＣＰ接続３３の標準３者ハンドシェイクで始まって、オペレーティングシステムレベルでの接続をセットアップする。ＴＣＰ接続３３が確立される場合、サブシステム１６は、ＳＵＳＣ１２に接続メッセージ３５を送る。ＳＵＳＣ１２は、期間３１、好ましくは０．５秒以内に接続返答３７を送る。接続返答３７は、場所固有情報、たとえば機械が置かれたタイムゾーンを含み得る。この情報は、ＳＵＳＣ１２のタイムゾーン３９をセットするのに使うことができる。サブシステム１６は、さらなる内部サブシステム初期化４１を後で行うことができる。

原則として、接続は、無期限に、すなわち双方のうちの一方がシャットダウンし、接続が閉じられるまで、開いたまま保たれる。このクローズは、アプリケーションによる明示的ソケットクローズによって、またはオペレーティングシステムのシャットダウンシーケンスの一部として、オペレーティングシステムによって自動的に起こる。ＰＩＣ１５は、接続のクローズを検出すると、再接続しようと試み、再接続が失敗した場合は、成功するまで再試行してよい。ＳＵＳＣ１２は、接続のクローズを検出すると、関連ＰＩＣのすべての情報（登録コマンドや計画された将来のコマンドなど）を破棄し、再接続するまではＰＩＣ１５および関連サブシステム１６がないと見なしてよい。

ＳＵＳＣ１２が接続のクローズを検出しておらず、ＰＩＣ１５によって重複接続が確立される特殊ケースでは、ＳＵＳＣ１２は、以前の接続が閉じられていると見なしてよい。このシナリオは、ＴＣＰ接続を閉じる機会がカーネルに与えられることなく、ＰＩＣ１５が突然電源オフされ、ＳＵＳＣ１２がこのＰＩＣとの通信をまだ試みていないときに起こり得る。

この挙動により、確実に一方が、他方のリスタートを必要とせずに、リスタートされ得る。図６Ｂは、サブシステム１６がすでに初期化されているが、ＳＵＳＣ１２への接続を失っているときに開始される再接続シーケンス４０を示す。ＳＵＳＣ１２への再接続は、サブシステム１６の責任である。接続メッセージ３５をＳＵＳＣ１２に送る繰返しは、サブシステム１６によって行われ、接続メッセージ３５を受信すると、ＳＵＳＣ１２は、サブシステム１６に接続返答３７メッセージを送り返す。ここでも、期間３１、好ましくは０．５秒以内である。再接続シーケンス４０は、サブシステム１６がＳＵＳＣ１２に接続されるまで繰り返される。

図６Ｃは、ＳＵＳＣ１２による、「ｓｅｔ」コマンド５１をもつ入力引数の、サブシステム１６への転送で随意に始まる実行コマンドシーケンス５０を示す。ｓｅｔコマンド５１の後には、一定量のデータ５２がサブシステム１６にＮ回送られる。最終データ５２が送られた後、サブシステム１６は、ＳＵＳＣ１２にｓｅｔ返答５３（ｓｅｔＲｅｐｌｙ）を送り返すことによって、受信したコマンド５１およびデータ５２に肯定応答する。サブシステム１６からＳＵＳＣ１２に送られるどの返答も、好ましくは０．５ミリ秒の平均未満を備える返答期間５５を有する。ｓｅｔ返答５３は、好ましくは３０．０秒プラスマイナス１．０秒を備えるタイムアウト限度５４内に送られなければならない。返答が受信されない場合、ＳＵＳＣ１２は、サブシステム１６を、接続されていないか、または欠陥があると見なす。ＳＵＳＣ１２が実行コマンド５７を送った後、サブシステム１６は、好ましくは返答期間５５以内にｅｘｅｃｕｔｅＳｔａｒｔｅｄ返答５８で肯定応答する。サブシステム１６は、実行を終了した後、ＳＵＳＣ１２にｅｘｅｃｕｔｅＤｏｎｅ５９を送る。出力引数（ある場合）は、ＳＵＳＣ１２によって送られる「ｇｅｔ」コマンド６０で取り出される。サブシステム１６は、ｇｅｔＲｅｐｌｙ６１で肯定応答し、その後、Ｎ量のデータ６２または出力引数を送る。

今後の実行コマンド５７にこれ以上必要とされない入力および出力引数は、消去コマンド６３を使ってサブシステム１６から削除される。サブシステム１６は好ましくは、返答期間５５内にｄｅｌｅｔｅＲｅｐｌｙ６４で返答する。プロトコルのあるバージョンでは、入力および出力は、あるインターフェースコマンドから他のインターフェースコマンドに運ばれない。サブシステム１６は、次のコマンドに必要とされる以上の入力は送られないと、安全に想定することができ、次のコマンドの入力が送られる前に、すべての入力および出力が消去されると、安全に想定することができる。

図６Ｄは、破棄された実行コマンド７１のケースにおける、イベントの順序を示す破棄シーケンス７０を示す。破棄シーケンス７０は、大域的に、以下の違いはあるが、通常の実行シーケンス５０と同じである。ＳＵＳＣ１２は、ｅｘｅｃｕｔｅＳｔａｒｔｅｄ５８とｅｘｅｃｕｔｅＤｏｎｅ５９メッセージの受信の間の期間中に破棄リクエスト７１を送る。サブシステム１６は、ａｂｏｒｔＲｅｐｌｙ７２を送る。破棄リクエスト７１に対する応答としての、ＳＵＳＣ１２へのａｂｏｒｔＲｅｐｌｙ７２の送付は、９０．０秒プラスまたはマイナス１．０秒を備える期間ａｂｏｒｔＲｅｐｌｙ７４内に行われなければならず、９０秒は、最大ポーリング間隔のための６０秒と、追加の３０秒を備える。現在実行中のコマンドに依存して、コマンドは、完了するように稼動し、またはコマンドが終了される前に中断する。コマンドが終了されなかった場合、例外９１をロギングすればよい。また、すべての出力引数が利用可能なわけではなく、空のもの（０バイト）はサブシステム１６によって置換されてよい。ＳＵＳＣ１２は、それらをすべて取り出そうとする。ＳＵＳＣ１２からの破棄メッセージ７１およびサブシステム１６からのｅｘｅｃｕｔｅＤｏｎｅ５９が互いと交差することが可能である。この場合、図６Ｅに示すシーケンス８０が適用可能である。

図６Ｅは、競合条件８０をもつ破棄シーケンスを示す。競合条件８１は、２つ以上のメッセージが互いと交差するときに起こる条件である。ここで、破棄メッセージ７１は、ｅｘｅｃｕｔｅＤｏｎｅメッセージ５９と交差する。

図６Ｆ、図６Ｇ、および図６Ｈは、例外シーケンス９０についての３つのケースを示す。例外９０が、たとえば、エラーやアラームの形で起こると、例外メッセージが、サブシステム１６によってＳＵＳＣ１２に送られる。エラーは、リソグラフィ要素が予想通りに振る舞っていないことをユーザ４に通信するのに使われる。アラームとは、ユーザ４によって肯定応答されなければならない条件である。

インターフェースコマンドを実行するコンテキストにおいて起こる例外９１は、コンテキスト情報でタグ付けすることができる。そのようなコマンドのコンテキストの外で起こる例外９１（自発的例外９０）に対して、これらのコンテキストフィールドは空にされてよく、または失敗に関連した、すでに完了されたコマンドの最も適切なコンテキストが供給されてよい。

特に自発的例外９０のケースでは、ユーザ４に例外を殺到させないように気をつけるべきである。たとえば、高頻度制御ループ中でエラー条件が検出される場合、理想としてはただ１つの例外９１が、その条件に対してデータネットワークハブ１４によってロギングされるべきであり、ループのすべての反復に対して繰り返しロギングされるべきではない。条件が持続する場合は、例外９１を低（好ましくは１分）頻度で繰り返し、または条件が変わり、または消えたとき（やはり予期されないので、依然として例外９１と見なすことができる）は、フォローアップ例外９１をロギングする方が、より優れているであろう。

例外９１は、オペレータ４にエラー状況を通知し、オペレータ４を回復手順に誘導し、問題の本質を簡潔に、たとえば電話またはトラブルチケットタイトルによって通信することを意図している。例外９１はしたがって、モジュール設計者のためのデバッグ情報チャネルと見なされるべきではない。あるいは、人間可読データフォーマットでのＰＪ出力が、オフラインでモニタまたは調査することができる情報に使われ得る。

例外メッセージ９１は、プロトコルシーケンスを終了せず、今後のコマンドを扱うのを停止する理由にはならない。たとえば、インターフェースコマンドが失敗し、例外９１がデータネットワークハブ１４によってロギングされた後、ｅｘｅｃｕｔｅＤｏｎｅ５９は依然として送られ、出力は「ｇｅｔ」可能にされてよい。サブシステム１６も、状況から回復するための新規インターフェースコマンドを受諾する準備ができているべきである。

例外９１は、ｇｅｔＲｅｐｌｙ６１シーケンス内を除いて、プロトコルにおいていつでも挿入されることが可能である。いかなる例外９１も並列スレッドによって生成することができる場合、ＰＩＣ１６の設計者は、そのような例外９１をロギングするためであって、どのコマンドのためでもない、専用のＰＩＣ１６接続を割り振ることを検討することができる。そうすることにより、この干渉が直接的に回避される。

図６Ｆは、ＳＵＳＣ１２から送られる汎用または任意のプロトコルコマンド９２中でサブシステム１６によって生成される例外９１を示す。例外９１の後、サブシステム１６はまた、任意のプロトコルコマンド返答９３をＳＵＳＣ１２に送る。図６Ｇは自発的例外９１を示し、図６Ｈは、実行コマンド５７中にサブシステム１６からＳＵＳＣ１２に送られる例外９１を示す。どのプロトコルコマンド９２中でも、例外９１が起こされ得る。コマンドは、関連返答メッセージで正常に終了される。図６Ｇに示すように、ＳＵＳＣ１２からのコマンドの間で、例外９１がロギングされることも可能である。たとえば、定期的チェックから、またはハブ初期化シーケンスからである。実行コマンド５７中に例外９１が送られると、例外９１が起こっていなくても、ｇｅｔ６０および消去６３コマンドが実行される。ただし、例外９１の出現により、いくつかの出力引数が空（０バイト）になり得ることが可能である。

データネットワーク
サブシステム１６は、データネットワーク１４０を介してデータネットワークハブ１４に接続される。データ収集、記憶および管理は、データネットワーク１４０を介して実施される。制御ネットワーク１２０は、要素制御ユニット１２とリソグラフィサブシステム１６との間の制御ネットワーク経路を形成し、データネットワーク１４０は、データネットワークハブ１４とリソグラフィサブシステム１６との間のデータネットワーク経路を形成する。制御ネットワーク１２０およびデータネットワーク１４０は、物理的に別個のネットワークであり、各ネットワークは、配線と、スイッチなどのネットワーク構成要素と、サブシステム１６へのネットワーク接続とを含む、独自の別個の物理媒体を有する。このように、制御ネットワーク経路およびデータネットワーク経路は、物理的に別個の媒体を備え、別個の独立通信経路を形成する。

各リソグラフィサブシステム１６は、制御ネットワークを介して要素制御ユニット１２との間で制御情報を受信および送信するように適合された制御ネットワーク１４０への接続を有する。各リソグラフィサブシステム１６は、データネットワークを介してデータネットワークハブ１４にデータ情報を送信するように適合された、データネットワーク１４０への別個の接続を有する。

データネットワーク１４０は、サブシステム１６によって使われる送信レートよりもはるかに大きい帯域幅を有して設計される。たとえば、データネットワーク１４０は、１Ｇｂｉｔ／ｓの帯域幅と、１００Ｍｂｉｔ／ｓで送信するように設計されたサブシステムとを有し得る。データネットワークには、ネットワークコントローラもなく、データ転送の調整も行われない。通常、データネットワーク１４０では、データ交換上限は、サブシステム１６とデータネットワーク１４０との間で１４０Ｍｂｉｔに設定され、１Ｇｂｉｔの上限が、データネットワーク１４０とＳＵＳＤ１４との間のデータ交換に対して設定される。トラフィックをマージして、（データ）パッケージ衝突を防止するためのネットワークスイッチが、データネットワーク１４０に含まれる。

データネットワークハブ１４は、サブシステム１６から受信したデータを連続してロギングするように適合される。このデータは、ＰＪの実行中にサブシステムによってとられた測定データと、サブシステムの設定と、デバッグおよび障害追跡についてのデータとを含み得る。データネットワークハブ１４は好ましくは、低レベルの追跡データを含むすべてのデータを常にロギングしているので、データロギングをオンにする必要はない。この継続的データロギングは、問題診断を高速化し、エラーまたは問題を再稼動および再生する必要を減らす。

要素制御ユニット１２は、データネットワークハブ１４によるロギングのために、要素制御ユニット１２内で実行するＰＪの進行に関する情報を送るように、データネットワークハブ１４に接続される。データネットワークハブ１４は、要素制御ユニット１２から受信したデータを連続してロギングする。

データネットワークハブ１４は、長い動作期間にわたる、たとえば月または年の規模で、すべてのサブシステム１６からの非常に大量の低レベルデータの記憶に十分な、非常に大きいデータ記憶容量を含む。データネットワークハブ１４によって記憶されたデータは、体系化され、好ましくはタイムスタンプおよびＰＪ識別子でタグ付けされる。記憶されたデータは、データネットワークハブ１４から取り出し、好ましくはオフラインで、分析およびフィルタリングすることができる。

データネットワーク１４０を介したデータ収集を、制御ネットワーク１２０を介した制御通信とは分離することにより、制御ネットワークにわたる通信を損なうことなく、データネットワークにわたる高容量データの高頻度収集が可能になる。制御ネットワークは、制御ネットワーク１２０上の輻輳を制御し、データネットワーク１４０上に存在する高容量トラフィックを回避することによって、準リアルタイムで動作することが可能になる。データネットワークハブ１４内でのデータ管理および記憶機能の分離と、要素制御ユニット１２内でのＰＪ実行により、要素制御ユニット１２によるＰＪの処理を損なうことなく、データネットワークハブ１４による高容量のデータの処理が可能になる。制御およびデータ収集および管理の分離により、２つのシステムの間の対話を考慮する必要なく、より単純な設計が可能になる。

本発明を、上で論じたいくつかの実施形態を参照して説明した。これらの実施形態は、本発明の精神および範囲から逸脱することなく、当業者によく知られている様々な修正および代替形が可能であることが理解されよう。したがって、特定実施形態について説明したが、これらは例にすぎず、添付の請求項において定義される本発明の範囲に対する限定ではない。
以下に、本出願時の特許請求の範囲に記載された発明を付記する。
［１］ １つまたは複数のリソグラフィ要素（１０）を備えるクラスタ化基板処理システムであって、各リソグラフィ要素が、パターンデータに従って複数の基板を独立して露光するために用意され、各リソグラフィ要素が、
複数のリソグラフィサブシステム（１６）と、
前記複数のリソグラフィサブシステムと少なくとも１つの要素制御ユニット（１２）との間の制御情報の通信のために用意された制御ネットワーク（１２０）であって、前記要素制御ユニットが、前記複数のリソグラフィサブシステムに複数のコマンドを送信するように用意され、前記複数のリソグラフィサブシステムが、前記要素制御ユニットに複数の応答を送信するように用意された、制御ネットワークと、
オペレータまたはホストシステム（２、４）とのインターフェースのためのクラスタフロントエンド（６）であって、前記フロントエンドが、１つまたは複数のウエハの露光のために前記１つまたは複数のリソグラフィサブシステムの動作を制御するための制御情報を、前記少なくとも１つの要素制御ユニットに発行するために用意されたクラスタフロントエンドとを備え、
前記フロントエンドが、前記要素制御ユニットにプロセスプログラムを発行するために用意され、前記プロセスプログラムが、あらかじめ規定されたコマンドおよび関連パラメータのセットを備え、各コマンドが、前記複数のリソグラフィサブシステムのうちの１つまたは複数によって実施されるべき、あらかじめ規定された１つのアクションまたは一連のアクションに対応し、前記複数のパラメータが、前記１つのアクションまたは一連のアクションがどのように実施されるべきかをさらに定義する、システム。
［２］ 前記要素制御ユニットが、前記複数のリソグラフィサブシステムによって実行するための対応するプロセスジョブを生成するように前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、前記プロセスプログラムの前記コマンドセットと、前記複数のコマンドの各々についてのスケジュールされた実行時間とを備える、［１］に記載のシステム。
［３］ 前記要素制御ユニットが、前記プロセスプログラムの前記コマンドセットと、前記複数のコマンドの各々について、前記コマンドを実行するようにスケジュールされたリソグラフィサブシステムの識別情報とを備える前記プロセスジョブを生成するために用意される、［２］に記載のシステム。
［４］ 前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、前記識別されたリソグラフィサブシステムに送信することによって前記プロセスジョブを実行するように用意される、［３］に記載のシステム。
［５］ 前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記プロセスジョブの先行コマンドの実行状況にかかわらず、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、前記識別されたリソグラフィサブシステムに送信するように用意される、［４］に記載のシステム。
［６］ 前記プロセスプログラムが、対応するコマンドについての所定の期間を定義し、前記要素制御ユニットが、前記複数のリソグラフィサブシステムによって実行するためのプロセスジョブを生成するように前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、各コマンドについてのスケジュールされた実行時間を備え、前記所定の期間が、前記プロセスジョブ中の前記対応するコマンドについての前記スケジュールされた時間を判断するのに使われる、［１］から［５］のいずれかに記載のシステム。
［７］ 前記プロセスプログラムが、対応する第１のコマンドについての第１の所定の期間を定義し、前記要素制御ユニットが、前記期間の時間切れまで、前記第１のコマンドの実行状況にかかわらず、前記第１のコマンドに続く次のコマンドの開始を遅らせるように用意される、［１］から［６］のいずれかに記載のシステム。
［８］ 前記要素制御ユニットが、１つのアクションまたは複数のアクションについての前記１つまたは複数のパラメータを、前記制御ネットワークを介して前記サブシステムに送り、その後、前記１つのアクションまたは複数のアクションに対応する前記コマンドを前記サブシステムに送ることによって、前記複数のリソグラフィサブシステムのうちの１つによって前記１つのアクションまたは一連のアクションを開始するように用意される、［１］から［７］のいずれかに記載のシステム。
［９］ 前記要素制御ユニットが、前記コマンドを実行するためのスケジュールされた時間より一定期間だけ前に、前記サブシステムに前記１つまたは複数のパラメータを送るように用意され、前記期間が、前記コマンドが前記サブシステムに送られる前に前記サブシステムが前記１つまたは複数のパラメータを受信したことを保証するのに十分である、［８］に記載のシステム。
［１０］ 前記要素制御ユニットによって発行されたコマンドに対応する１つのアクションまたは一連のアクションが完了すると、前記１つのアクションまたは一連のアクションを完了した前記リソグラフィサブシステムが、前記要素制御ユニットに前記完了を通知するために用意され、前記要素制御ユニットから命令を受信すると、前記１つのアクションまたは一連のアクションの実行に関するデータを発行するように用意される、［１］から［９］のいずれかに記載のシステム。
［１１］ 前記プロセスプログラムが条件ステップを含まない、［１］から［１０］のいずれかに記載のシステム。
［１２］ 前記プロセスプログラムが、複数の代替コマンドとしてプログラムされた複数の条件ステップを含み、前記要素制御ユニットが、前記複数のリソグラフィサブシステムによる実行のためにプロセスジョブを生成するように、前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、各コマンドについてのスケジュールされた実行時間を備え、前記複数の代替コマンドが、前記プロセスジョブ内で並行してスケジュールされ、前記プロセスジョブの前記実行時間が全体として、どの代替コマンドが実行用に選択されるかによって変わらないように、各代替コマンドには、同じ実行時間が割り当てられる、［１］から［１１］のいずれかに記載のシステム。
［１３］ ソフトウェアをアップデートまたはアップグレードするための、リソグラフィサブシステム内の前記ソフトウェアの修正が、前記要素制御ユニット内でプロセスジョブを実行することによって実施される、［１］から［１２］のいずれかに記載のシステム。
［１４］ 前記制御ネットワークが、リアルタイムの通信プロトコルを使わずに準リアルタイム性能を提供する、［１］から［１３］のいずれかに記載のシステム。
［１５］ 各リソグラフィ要素が、前記複数のリソグラフィサブシステムから少なくとも１つのデータネットワークハブ（１４）へのデータロギング情報の通信用に用意されたデータネットワーク（１４０）をさらに備え、前記複数のリソグラフィサブシステムが、前記データネットワークハブにデータロギング情報を送信するように用意され、前記データハブが、前記データロギング情報を受信および記憶するために用意され、前記フロントエンドが、前記データネットワークハブによって受信された前記データロギング情報の少なくとも一部分を受信するためにさらに用意される、［１］から［１４］のいずれかに記載のシステム。
［１６］ 前記複数のリソグラフィサブシステムが、第１の送信レートで前記データネットワークにデータを送信するように用意され、前記データネットワークハブが、第２の送信レートで前記データネットワークからデータを受信するように用意され、前記第２の送信レートが、前記第１の送信レートよりもはるかに大きい、［１］から［１５］のいずれかに記載のシステム。
［１７］ 前記制御ネットワークが、ＴＣＰリンク上でバイト送信プロトコルを使う、［１］から［１６］のいずれかに記載のシステム。
［１８］ 前記要素制御ユニットおよび前記複数のリソグラフィサブシステムが、前記制御ネットワーク上で複数のメッセージシーケンスを送信するように用意され、メッセージシーケンスの第１のメッセージが２つの要素を備え、第１の要素が、メッセージタイプをもつストリングを含み、第２の要素が、前記メッセージについての複数の名前付き引数をもつ辞書を含む、［１］から［１７］のいずれかに記載のシステム。
［１９］ 前記メッセージシーケンスの前記第１のメッセージが、ＪａｖａＳｃｒｉｐｔオブジェクト表記法（ＪＳＯＮ）でエンコードされた制御データ構造を含む、［１８］に記載のシステム。
［２０］ 前記メッセージシーケンスの第２のメッセージが、１つまたは複数のエンコードされたデータメッセージを備え、前記複数のデータメッセージの前記エンコードが、前記制御ネットワークプロトコルによって設定または制限されない、［１８］または［１９］に記載のシステム。
［２１］ 前記制御ネットワークが、前記制御ネットワーク上で複数のデータ転送が同時に起こらないようにするように用意されたコントローラを含む、［１］から［２０］のいずれかに記載のシステム。

Claims (16)

1. １つまたは複数のリソグラフィ要素を備えるリソグラフィシステムであって、
   各リソグラフィ要素は、パターンデータに従って基板を独立して露光するために用意され、各リソグラフィ要素は、複数のリソグラフィサブシステムを備え、
   前記リソグラフィシステムは、制御情報の通信のために、前記複数のリソグラフィサブシステムと少なくとも１つの要素制御ユニットとの間に制御ネットワーク経路を形成する制御ネットワークをさらに備え、
   前記リソグラフィシステムは、
   １つまたは複数のウエハの露光のために前記リソグラフィサブシステムのうちの１つまたは複数の動作を制御するための制御情報を、前記少なくとも１つの要素制御ユニットに発行し、
   前記要素制御ユニットにプロセスプログラムを発行するために用意され、
   前記プロセスプログラムは、あらかじめ規定されたコマンドおよび関連パラメータのセットを備え、各コマンドは、前記リソグラフィサブシステムのうちの１つまたは複数によって実施されるべき、あらかじめ規定された１つのアクションまたは一連のアクションに対応し、前記パラメータは、前記１つのアクションまたは一連のアクションがどのように実施されるべきかをさらに定義し、
   前記プロセスプログラム中のあらかじめ規定されたコマンドのセットは、前記リソグラフィサブシステムのうちの１つまたは複数の、ソフトウェアをアップデートすることまたはアップグレードすることを備える、システム。
2. 前記リソグラフィシステムは、データを収集し、記憶し、管理するためのデータネットワークと、前記データネットワークを介して前記複数のリソグラフィサブシステムに接続されるデータネットワークハブとをさらに備え、
   前記複数のリソグラフィサブシステムは、前記ネットワークハブからブートするように構成され、したがって、前記データネットワークハブ上の前記リソグラフィサブシステムのためのブートイメージをアップデートすることにより、前記ソフトウェアをアップデートすることまたはアップグレードすることが実施される、請求項１に記載のシステム。
3. 前記要素制御ユニットは、前記プロセスプログラムをスケジュールし、前記リソグラフィサブシステムに送信された先行コマンドの実行状況にかかわらず、前記スケジュールにしたがって、前記プロセスプログラムのコマンドをリソグラフィサブシステムに送信するように用意される、請求項１または２に記載のシステム。
4. 前記要素制御ユニットは、前記リソグラフィサブシステムのうちの１つまたは複数によって実行するための対応するプロセスジョブを生成するように、前記プロセスプログラムをスケジューリングするために用意される、請求項１から３のいずれかに記載のシステム。
5. 前記ソフトウェアをアップデートまたはアップグレードするための、リソグラフィサブシステム中のソフトウェアの修正は、プロセスジョブを実行することによって実施される、請求項４に記載のシステム。
6. 前記複数のリソグラフィサブシステムは、中央ディスクまたはメモリからブートするように構成され、したがって、前記中央ディスクまたはメモリ中の前記リソグラフィサブシステムに対してブートイメージをアップデートすることによって、リソグラフィサブシステム中のソフトウェアの修正が実施される、請求項１から５のいずれかに記載のシステム。
7. 新規機能性による前記リソグラフィシステムの拡張またはアップグレードは、前記リソグラフィシステムのうちの１つまたは複数の中のソフトウェアの修正により、および、アップデートされたプロセスプログラムを発行することにより実施される、請求項１から６のいずれかに記載のシステム。
8. 前記リソグラフィシステムのうちの１つまたは複数の中のソフトウェアの修正の後、前記リソグラフィシステムのうちの１つまたは複数は、実行可能なコマンドの情報を前記要素制御ユニットに送信するように構成されている、請求項７に記載のシステム。
9. 前記リソグラフィシステムの拡張またはアップグレードは、前記要素制御ユニット中のソフトウェアの修正を要求しない、請求項７に記載のシステム。
10. 前記複数のリソグラフィサブシステムの設定を含むデータを収集し、記憶し、管理するためのデータネットワークをさらに備え、前記リソグラフィサブシステムは、前記データネットワークを介してデータネットワークハブに接続される、請求項１から９のいずれかに記載のシステム。
11. 前記制御ネットワークと前記データネットワークは、別個のネットワークを形成する、請求項１０に記載のシステム。
12. 前記データネットワークハブによって記憶される前記データは、タイムスタンプによりタグ付けされる、請求項１０に記載のシステム。
13. パターンデータを生成するパターンデータ処理システムをさらに備え、前記データ処理システムは、前記制御ネットワークおよび前記データネットワークとは別個のデータ経路を介して、前記パターンデータを前記リソグラフィシステムのうちの１つまたは複数に送信するように用意されている、請求項１０に記載のシステム。
14. 前記要素制御ユニットは、一連の繰り返されるコマンドを前記リソグラフィサブシステムに送信するように構成され、シーケンス中のコマンドが時間期間内に実行されない場合、前記リソグラフィサブシステムは、前記シーケンス中のコマンドを破棄する、請求項１から１３のいずれかに記載のシステム。
15. 前記プロセスプログラムは、対応する第１のコマンドについての第１の所定の時間期間を定義し、前記要素制御ユニットは、前記期間の時間切れまで、前記第１のコマンドの実行状況にかかわらず、前記第１のコマンドに続く次のコマンドの開始を遅らせるように用意される、請求項１から１４のいずれかに記載のシステム。
16. 前記制御ネットワークは、リアルタイムの通信プロトコルを使わずに準リアルタイム性能を提供する、請求項１から１５のいずれかに記載のシステム。

Images