(58)【調査した分野】(Int.Cl.,DB名)
前記要素制御ユニットが、前記複数のリソグラフィサブシステムによって実行するための対応するプロセスジョブを生成するように前記プロセスプログラムをスケジューリングするように構成され、
前記プロセスジョブが、前記プロセスプログラムの前記複数のコマンドからなるセットと、前記複数のコマンドの各々についてのスケジュールされた実行時間とを備える、請求項1に記載のシステム。
前記要素制御ユニットが、前記プロセスプログラムの前記複数のコマンドからなるセットと、前記複数のコマンドの各々について、前記コマンドを実行するようにスケジュールされたリソグラフィサブシステムの識別情報と、を備える前記プロセスジョブを生成するように構成される、請求項2に記載のシステム。
前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、識別されたリソグラフィサブシステムに送信することによって前記プロセスジョブを実行するように構成される、請求項3に記載のシステム。
前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記プロセスジョブの先行コマンドの実行状況にかかわらず、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、識別されたリソグラフィサブシステムに送信するように構成される、請求項4に記載のシステム。
前記要素制御ユニットが、1つのアクションまたは複数のアクションについての前記1つまたは複数のパラメータを、前記制御ネットワークを介して前記サブシステムに送り、その後、前記1つのアクションまたは複数のアクションに対応する前記コマンドを前記サブシステムに送ることによって、前記複数のリソグラフィサブシステムのうちの1つによって前記1つのアクションまたは一連のアクションを開始するように構成される、請求項1に記載のシステム。
前記要素制御ユニットが、前記コマンドを実行するためのスケジュールされた時間より一定期間だけ前に、前記サブシステムに前記1つまたは複数のパラメータを送るように構成され、
前記期間は、前記コマンドが前記サブシステムに送られる前に前記サブシステムが前記1つまたは複数のパラメータを受信したことを保証するのに十分である、請求項8に記載のシステム。
前記要素制御ユニットによって発行されたコマンドに対応する1つのアクションまたは一連のアクションが完了すると、前記1つのアクションまたは一連のアクションを完了した前記リソグラフィサブシステムが、前記要素制御ユニットに前記完了を通知するように構成され、前記要素制御ユニットから命令を受信すると、前記1つのアクションまたは一連のアクションの実行に関するデータを発行するように構成される、請求項1に記載のシステム。
ソフトウェアをアップデートまたはアップグレードするための、リソグラフィサブシステム内の前記ソフトウェアの修正が、前記要素制御ユニット内でプロセスジョブを実行することによって実施される、請求項1に記載のシステム。
【発明を実施するための形態】
【0020】
以下では、単に例として、図面を参照して挙げられる、本発明のいくつかの実施形態について説明する。
【0021】
図1は、本発明による、制御およびデータインターフェースを有するリソグラフィシステム1の一実施形態の概略図である。この図は、3つのインターフェース、すなわちクラスタインターフェース3、クラスタ要素インターフェース5、およびリソグラフィサブシステムインターフェース7を有する階層的配置を示す。
図1は、複数のリソグラフィサブシステム16を備える1つのリソグラフィ要素10を備えるリソグラフィシステムクラスタを有する構成を示す。リソグラフィシステムは、たとえば
図2の実施形態でのように、複数のリソグラフィ要素10を備えることができる。
【0022】
クラスタインターフェース3は、リソグラフィクラスタフロントエンド6と1つまたは複数のホストシステム2との間、ならびに/あるいはクラスタフロントエンド6と1つまたは複数のオペレータコンソール4との間の通信用のインターフェースを備える。
【0023】
クラスタ要素インターフェース5は、クラスタフロントエンド6と、要素制御ユニット12および/またはデータネットワークハブ14を備えるリソグラフィ要素ネットワークとの間の通信用のインターフェースを備える。要素制御ユニット12は、リンク106を介してデータネットワークハブ14と通信することができ、通信は好ましくは、要素制御ユニット12からデータネットワークハブ14への一方向である。
【0024】
リソグラフィサブシステムインターフェース7は、要素制御ユニット12とリソグラフィサブシステム16との間の、ならびにデータネットワークハブ14とリソグラフィサブシステム16との間のインターフェースを備える。サブシステム16は、制御ネットワーク120を介して要素制御ユニット12と通信し、サブシステム16は、データネットワーク140を介してデータネットワークハブ14と通信する。
【0025】
図2は、リソグラフィシステムクラスタが複数のリソグラフィ要素10を備えるリソグラフィシステム1の実施形態の概略図であり、各要素は、複数のリソグラフィサブシステム16を備える。各要素は、要素向けのリソグラフィサブシステム16と通信する要素制御ユニット12とデータネットワークハブ14とを備えることができる。各要素は、リソグラフィプロセスを用いてウエハを露光するように独立して動作することが可能なスタンドアロンリソグラフィ要素として機能することができる。本実施形態では、複数のリソグラフィ要素10は各々、単一のフロントエンド6と通信し、フロントエンド6は、クラスタ全体のために機能する1つまたは複数のホストシステム2および/またはオペレータインターフェース4と通信する。
【0026】
図1および
図2の実施形態は好ましくは、リソグラフィ要素のクラスタの効率的制御を円滑にするように設計される。各リソグラフィ要素10は好ましくは、制御ネットワーク120およびデータネットワーク140へのネットワークインターフェースを有するだけである。この設計規則に対する例外は、データ経路20が、荷電粒子ビームの変調または切替えを担うサブシステム(複数)にパターンストリーマ19を直接接続することである。パターンデータは、最初にパターンデータ処理システム18内で準備され、データ変換およびサブシステムへのストリーミングのためにパターンストリーマ19に送られる。この設計は、極度に大量のパターンデータが関連サブシステム(複数)に転送されるためである。パターンデータは通常、サブシステムにおいてローカル記憶するにはデータ量が多すぎるので、ビットマップ形式で関連サブシステムにストリーミングされる。
【0027】
オペレータインターフェースならびにより高レベルのホスト監視および自動化コンピュータへのインターフェースは、個々のリソグラフィ要素なしではあるが、クラスタフロントエンド6において作られる。こうすることにより、そのようなインターフェースは、リソグラフィ要素10に対するインターフェースプロトコルについて知る必要なく、ならびに追加要求を行わず、制御ネットワーク120およびデータネットワーク140にわたる通信と干渉せずに、クラスタ用に開発されることが可能になる。
【0028】
図3は、リソグラフィシステムクラスタ1の簡略平面図を示す。本実施形態では、クラスタは、5個ずつ2行に連続して用意される、10個のリソグラフィ要素10からなるグループを備える。クラスタ1に直接隣接して、床面積がサービスエリア23として確保される。各リソグラフィ要素は、それ自体の真空室に含まれる電子光学カラムを備え、各真空室の片側は基板受渡しシステム22とサービスエリア23とに面する。基板受渡しシステム22は、基板供給システム24から基板を受け取り、基板を加工のためにリソグラフィ要素10に供給し、加工された基板をリソグラフィ要素10から受け取り、加工された基板を、工場内の他のシステムに転送するために基板供給システム24に供給する。
【0029】
荷電粒子リソグラフィ装置のケースでは、真空室は好ましくは、複数の荷電粒子ビームレットを生成するための荷電粒子源および成分と、ビームレットを切り替え、または変調するビーム変調システムと、パターニングされるべき基板上にビームレットを投射するためのプロジェクタシステムと、可動基板台とを封入する。真空室は好ましくは、基板受渡しシステム22から真空室の中および外に基板を移すためのロードロックシステム、および電子光学カラムへのサービスアクセスのために開けることができるサービスエリア23に面する点検口も含む。
【0030】
各リソグラフィ要素10は、ウエハを受け取り、加工するように独立して動作する。各リソグラフィ要素は、データを処理し、リソグラフィ要素の構成要素とサブシステムとを操作するための独自のコンピュータ処理システムを含む。各リソグラフィサブシステム16は好ましくは、サブシステムの動作を指示し、サブシステムの動作の結果生じたデータを収集し、制御およびデータネットワークと通信するためのコマンドを実行するために、独自のコンピュータプロセッサとメモリシステムとを有する。制御要素ユニット12およびデータネットワークハブ14は好ましくは、各々が、それらの機能を実施するための、独自のコンピュータプロセッサとメモリシステムとを備える。リソグラフィ要素10用の制御要素ユニット12、データネットワークハブ14、およびサブシステム16のためのコンピュータプロセッサおよびメモリシステムは、リソグラフィ要素用の真空室に極めて近接して、たとえば真空室の上に取り付けられた、真空室の下の下部構造、または各場所の一部にあるキャビネット内に用意すればよい。
【0031】
クラスタのリソグラフィ要素の連続レイアウトにより、システムには限られたフットプリントが与えられ、コンピュータプロセッサおよびメモリシステムを真空室のすぐ上または下に用意すると、フットプリントが削減される。工場内の床面積は貴重なので、工場の床面積を効率的に使用することが重要である。
【0032】
図4は、荷電粒子リソグラフィ要素の電子光学カラムの簡略図を示す。そのようなリソグラフィシステムは、たとえば、本発明の所有者にすべて譲渡されているとともにすべて参照により全体が本明細書に組み込まれている米国特許第6,897,458号、第6,958,804号、第7,019,908号、第7,084,414号、および第7,129,502号、米国特許公開第2007/0064213号、ならびに同時係属中の米国特許出願第61/031,573号、第61/031,594号、第61/045,243号、第61/055,839号、第61/058,596号、および第61/101,682号に記載されている。
【0033】
図4に示す実施形態では、リソグラフィ要素カラムは、コリメータレンズシステム113によって平行にされる拡大電子ビーム130を生じる電子源110を備える。平行電子ビームは、開口アレイ114aの上で衝突し、アレイ114aはビームの一部を遮断して複数のサブビーム134を生じ、サブビーム134は、サブビームを集束させるコンデンサレンズアレイ116を通過する。サブビームは、各サブビーム134から複数のビームレット133を生じる第2の開口アレイ114bの上で衝突する。システムは、非常に多数のビームレット133、好ましくは約10,000〜1,000,000個のビームレットを生成する。
【0034】
複数のブランキング電極を備えるビームレットブランカアレイ117は、ビームレットのうち選択されたものを偏向させる。非偏向ビームレットは、ビーム停止アレイ118に届き、対応する開口を通過するが、偏向ビームレットは、対応する開口を通らず、ビーム停止アレイによって停止される。したがって、ビームレットブレーカアレイ117およびビーム停止118は、個々のビームレットをオンおよびオフに切り替えるように、共同で動作する。非偏向ビームレットは、ビーム停止アレイ119と、ビームレットを偏向させて、目標または基板121の表面にわたるビームレットを走査するビーム偏向器アレイ119とを通過する。次に、ビームレットは、投射レンズアレイ120を通過し、基板を載せるための可動台上に位置する基板121の上に投射される。リソグラフィアプリケーションのために、基板は一般に、荷電粒子敏感層または抵抗層が設けられたウエハを備える。
【0035】
リソグラフィ要素カラムは、真空環境において動作する。荷電粒子ビームによってイオン化し、発生源に引きつけることができ、解離し機械構成要素の上に堆積することができ、荷電粒子ビームを分散させることができる粒子を取り除くのに、真空が所望される。少なくとも10
-6バールの真空が通常、必要とされる。真空環境を維持するために、荷電粒子リソグラフィシステムは、真空室内に用意される。リソグラフィ要素の主要要素はすべて、好ましくは、荷電粒子源と、基板上にビームレットを投射するためのプロジェクタシステムと、可動台とを含む共通真空室に収容される。
【0036】
サブシステム
図1および
図2の実施形態において、各リソグラフィ要素10は、ウエハを露光するための独立動作リソグラフィ要素を形成する。各リソグラフィ要素10は、要素に必要とされる機能を実施するように動作する複数のサブシステム16を備える。各サブシステムは、特定の機能を実施する。典型的なサブシステム16には、たとえば、ウエハロードサブシステム(WLS)、ウエハ位置決めサブシステム(WPS)、電子ビームレットを生成するための照明光学サブシステム(ILO)、リソグラフィ要素にビーム切替えデータをストリーミングするためのパターンストリーミングサブシステム(PSS)、電子ビームレットをオンおよびオフに切り替えるためのビーム切替えサブシステム(BSS)、ウエハ上にビームレットを投射するための投射光学サブシステム(POS)、ビーム測定サブシステム(BMS)、計測サブシステム(MES)などがある。各リソグラフィ要素10は好ましくは、ウエハを受け取り、各ウエハをチャックにクランプするとともにクランプされたウエハを露光用に準備し、クランプされたウエハを露光し、露光されたウエハをチャックからクランプ解除し、露光されたウエハを、要素から取り除くために示すために構成される。
【0037】
各サブシステム16は、特定のサブ機能に専用であるとともに好ましくは交換可能構成要素として設計される1つまたは複数のモジュール17を備えることができる。モジュール17は、アクチュエータ19とセンサ21とを備えることができ、アクチュエータ19はコマンドを実施することが可能であり、センサ21は、アクションと結果とを検出し、コマンドの実施の間、前および/または後に測定を行うことができる。そのようなモジュールの例には、露光中の基板を移動するための台、台の制御のための制御コンピュータ、基板の上にビームレットを投射するためのレンズアレイに電圧を供給する投射レンズモジュール、真空室内で真空を生成するための真空ポンプなどがある。
【0038】
各サブシステム16は、独立して動作し、命令を記憶するためのメモリと、命令を実行するためのコンピュータプロセッサとを含む。メモリおよびプロセッサは、各サブシステム内でプラグインクライアント(PIC)15として実装することができる。サブシステムの適切な実施態様は、たとえば、Linux(登録商標)オペレーティングシステムを稼動するパーソナルコンピュータを含み得る。サブシステムは、それらのオペレーティングシステムを記憶するためのハードディスクまたは不揮発性メモリを含むことができ、それにより、各サブシステムは、このディスクまたはメモリからブートする。後で論じるこれらおよび他の特徴により、各サブシステムが、他のサブシステムによって課される制約を検討する必要なく、独立ユニットとして設計、構築および検査され得る自律ユニットである設計が可能になる。たとえば、各サブシステムは、その動作周期中に、他のサブシステムによって行われた、メモリおよび処理容量に対する要求を考慮に入れる必要なく、サブシステムの機能を正しく実施するのに十分なメモリおよび処理容量をもたせて設計すればよい。この設計は、これらの必要条件が流動的であるとき、システムの開発およびアップグレード中は特に有利である。この設計の欠点は、総必要メモリおよび処理容量が増え、これらの構成要素の冗長性が、各サブシステム内で実装されなければならないことである。ただし、これらの欠点よりも、より速い開発およびより簡単なアップグレードにつながる簡略設計が勝る。
【0039】
サブシステム16は、制御ネットワーク120を介してコマンドを受信し、他のサブシステムから独立してコマンドを実行するように設計され、コマンド実行についての結果を報告し、どの生じた実行データもリクエストに応じて転送する。
【0040】
サブシステム16は、自律単位として設計されるが、たとえばデータネットワークハブ上の中央ディスクまたはメモリからブートするように設計され得る。こうすることにより、各サブシステム内の個々のハードディスクまたは不揮発性メモリの信頼性問題およびコストが下がり、中心的場所にサブシステムのブート画像をアップデートすることによって、サブシステムをより簡単にソフトウェアアップグレードすることが可能になる。
【0041】
通信プロトコル
サブシステム16は、制御ネットワークを介して、サポートサブシステム制御またはSUSCとも呼ばれる要素制御ユニット12に接続される。要素制御ユニット12は、メモリと、リソグラフィ要素10用のサブシステムの動作を制御するためのコンピュータプロセッサとを備える。
【0042】
クラスタフロントエンド6とSUSC12との間の通信102は、SUSC12にPPを転送するために設計される。JavaScript(登録商標)オブジェクト表記法(JSON)に基づくプロトコルを使うことができる。JSONは、人間可読データ交換のために設計され、単純データ構造とアレイとを表すために使われる、テキストベースのオープンスタンダードであり、構造化データを直列化し、ネットワーク接続を介して送信するのに適している。プロトコルへのアクセスは好ましくは、クラスタにおけるユーザに制限され、クリーンルーム環境の外のユーザには制限されない。プロトコルは好ましくは、PJの作成、PPファイルおよび任意の関連パラメータの転送のための命令を与えて、SUSC12に、PPに基づいてPJを作成するよう命令する。追加コマンドは、破棄および取消し命令を含み得る。SUSC12からクラスタフロントエンド6への通信は、肯定応答メッセージと、経過報告と、エラーおよびアラームメッセージとを含み得る。
【0043】
制御ネットワーク120を超える、SUSC12とリソグラフィサブシステム16との間の通信101は好ましくは、ネットワーク内での準リアルタイム性能を確実にするように、要素制御ユニットプロトコルのみを使って厳しく制御される。
図5は、OSI(開放型システム相互接続)階層化モデルにおける要素制御ユニットプロトコルの一実施形態を示す。要素制御ユニットプロトコルについては、後でさらに詳しく説明する。
【0044】
SUSD14とクラスタフロントエンド6との間の通信105は、SUSD14からのPJ結果の取出し、ジョブ追跡およびデータロギングのために設計される。ハイパーテキスト転送プロトコル(HTTP)が、この通信リンク用に使われ得る。
【0045】
リソグラフィサブシステム16とSUSD14との間の通信103は、サブシステム16からの単方向のデータ収集のために設計される。データは、たとえばsyslog、HDF5、UDPなど、様々なプロトコルを使って通信され得る。
【0046】
ハンドシェイク、誤り検査および訂正の大きいオーバーヘッドなしでデータを送るためのユーザデータグラムプロトコル(UDP)を使って、高容量データを送ることができる。生じる送信オーバーヘッドが非常に低いので、データは、リアルタイムに受信されると見なしてよい。
【0047】
階層データフォーマットHDF5は、高頻度のデータ送信および記憶に使うことができる。HDF5は、大量の数値データの記憶および体系化に好適であるが、一般に、UDP環境では使われない。特に低レベル(低容量)データには、CSVやTCPなどの他のデータフォーマットを使ってもよい。
【0048】
プロセスプログラム
リソグラフィ要素10の動作は、実施されるべき一連のアクションを備えるプロセスプログラム(PP)11を使って制御される。要素制御ユニット12には、PPがロードされ、オペレータコンソール4を介したホストシステム2またはオペレータによるリクエストに応じて、PP11をスケジュールし、実行する。PP11は、たとえば、SEMI E40標準において定義されるレシピの役割を担うことができる。SEMI標準は、レシピをどのように扱うかに関して多くの必要条件を指定するが、標準は矛盾する場合があるので、レシピは好ましくは回避される。そうではなく、編集可能でありフォーマットされていないPPが、いわゆるバイナリラージオブジェクト(ブロブ)の形で使われる。
【0049】
ウエハの処理環境を決定し、稼動または処理周期の間の変化を被り得る命令、設定およびパラメータのセットの、事前計画された再利用可能部分としてのPP。PPは、リソグラフィツール設計者によって設計し、またはツール使用によって生成することができる。
【0050】
PPは、ユーザによってリソグラフィシステムにアップロードすることができる。PPは、プロセスジョブ(PJ)を作成するのに使われる。プロセスジョブ(PJ)は、リソグラフィ要素10によって1つのウエハまたはウエハセットに適用されるべき処理を指定する。PJは、指定されたウエハセットを処理するとき、どのPPを使うべきか定義し、PPからの(および任意選択でユーザからの)パラメータを含み得る。PJとは、ユーザまたはホストシステムによって開始されるシステム活動である。
【0051】
PPは、ウエハの処理の制御だけでなく、サービスアクション、キャリブレーション機能、リソグラフィ要素検査、要素設定の修正、ソフトウェアのアップデートおよびアップグレードなどにも使うことができる。好ましくは、PJ実行、および予期せぬ電源切断、緊急またはEMO活動化への応答に影響しない限り、モジュールまたはサブシステムの電源起動中の自動初期化、サブシステムの定期的な無条件挙動など、いくつかの認められた追加カテゴリを例外として、PPにおいて規定されるもの以外のどのサブシステム挙動も起こらない。
【0052】
PPは、ステップに分割される。ほとんどのステップは、コマンドを備え、コマンドを実施するためのサブシステムを識別する。ステップはまた、コマンドを実施する際に使われるべきパラメータと、パラメータ制約とを含み得る。PPは、ステップが実施されるべきである、たとえば並行して、順に、または同期されて実施されるべきであるときを示すためのスケジューリングパラメータを含み得る。
【0053】
PJのコマンドステップを実行するために、要素制御ユニット12は、PJ中に示されたコマンドを、PJの関連ステップで示されたサブシステムに送る。要素制御ユニット12は、タイミングをモニタし、結果をサブシステムから受信する。具体的なコマンドの実行例については、
図6〜
図13に示し、後で説明する。
【0054】
プラグインコマンドの概念
要素制御ユニット(SUSC)12は、PP(論理プランを表す)を、サブシステムアクションのスケジュールに変換する。システムは、どのサブシステム16がインストールされるか、およびどのサブシステムコマンドが存在し、コマンドのプロパティがどのようなものであるかについての予備知識をSUSC12がもたないように設計してよい。この場合、この情報は、起動中のサブシステム16によってランタイムにSUSC12に与えられる。
【0055】
各サブシステム16は、サブシステムが電源投入および初期化されるとき、サブシステムの存在と能力とをSUSC12に報告するように設計してよい。サブシステムは、制御ネットワーク120を介して通信を確立し、サブシステムの識別情報と状況とをSUSC12に報告し、また、どのコマンドを実施することが可能かなど、サブシステムの能力を報告すればよい。SUSC12は、PPに必要とされる各サブシステムがサブシステムの存在と即応状況とを報告したPP11の実行の前または実行中に検査を実施することができ、各サブシステムが、PPにおいてサブシステムに必要とされるコマンドを実施するためのサブシステムの能力を報告したということをチェックすることもできる。
【0056】
サブシステムによる、この自己報告により、リソグラフィシステムは、サブシステムへの局所的なソフトウェアアップグレードのみを使う新規機能性で、またはソフトウェアアップグレードなしでも、拡張またはアップグレードされることが可能になる。たとえば、特定のサブシステム16は、そのソフトウェアを、新規コマンドを実行することができるようにアップグレードさせてよい。SUSC12には今では、アップグレードされたサブシステム向けの新規コマンドを含む新規PP11をロードすることができる。アップグレードされたサブシステム16は、電源投入されると、要素制御ユニット12と通信し、ユニット12の識別情報および状況と、新規コマンドを含む、どのコマンドを実行することができるかとを示す。SUSC12は、新規コマンドを実行するようサブシステムに指令するステップを含むPJを生成するように、PPをスケジュールする。SUSC12は、アップグレードされたサブシステムが、新規コマンドを実施可能であると報告した検査を実施することができる。このアップグレードはしたがって、関連サブシステムおよびPPのアップグレードのみを必要とし、SUSC12または他のサブシステム16のうちいずれのアップグレードも必要としない。
【0057】
制御ネットワーク
制御ネットワーク120は好ましくは、リアルタイムの通信プロトコルを使わないが、それにもかかわらず、準リアルタイム性能を可能にするように設計され、高い再現性、たとえば実質的に1ミリ秒以内の再現性を伴うサブシステムとSUSC12との間の通信を可能にして、同じタイミング挙動をもたらす同じ条件下での同じジョブの実行を可能にする。
【0058】
制御ネットワーク120にわたるこの準リアルタイム性能は、以下の措置の一部または全部を実施することによって実現することができる。
【0059】
(a)リソグラフィシステムは、PJの実行を始めるのに先立ってPJを生成するように各PPをスケジュールし、PJの各ステップを始める時間(完了時間も含み得る)を判断する。各ステップについて、および完了PJのスケジュールされた開始時間(および完了時間)は、PJが開始される前に完全に判断することができ、これらの時間は、クラスタフロントエンドに報告すればよい。
【0060】
(b)PP(およびPJ)は、条件ステップもアクションも、および再試行ももたずに設計することができる。PP/PJのステップは、一連のアクションを記述するが、リソグラフィ要素内でのアクションは、並行して実施することができ、たとえばコマンドは、異なるサブシステム上で並行して実行する。条件ステップまたはアクションは、実施するべき2つ(またはそれ以上)の代替ステップを定義することによって、PPにおいてプログラムすることができ、代替ステップは、並列パスとして用意される。代替ステップは、PJにおいて、各々に同じ実行時間が割り当てられる並列パスとしてスケジュールされ、その結果、全体としてPJの実行時間は、サブシステム上での実行のためにどの代替パスが選択されるかによって変わることはない。
【0061】
PJのステップの実行時間は、先行または並列ステップの結果を条件とするのではなく、所定のスケジュールに従って実行される。ステップが、正しくまたはスケジュールされた時間内に完了しない場合、ステップは、再度実行されることはなく(すなわち、再試行はなく)、代わりに次のスケジュールされたステップが実行される。
【0062】
(c)スケジューリングの後、すべてのステップが、所定のスケジュールされた時間に、好ましくは約1ミリ秒のタイミング精度でSUSC12によって実行される。スケジュールされた時間に、SUSC12は、関連ステップを実行し、そのステップのためのどのコマンドも、サブシステムによって実行するために関連サブシステム16に送る。SUSC12におけるスケジュールされたタイミングは、先行ステップからの完了の成功またはコマンドの実行の失敗にさえ関する、サブシステム16からのフィードバックに依存しない。ステップが実行期間を定義する場合、SUSC12は、PJの次のステップに進む前に、その期間が経過するのを待つ。サブシステムが、この期間の時間切れの前にコマンドの実行からの結果を戻す場合、SUSC12は依然として、次のステップに進む前に、期間の時間切れを待つ。サブシステムがエラーメッセージを戻すのに失敗した場合、SUSC12はそれにもかかわらず、期間の時間切れを待ち、次いで、次のステップに進む。サブシステムがコマンドを正しく実行するのに失敗した場合、オペレータまたはホストシステムは、どのような訂正アクションが必要となり得るか判断する。
【0063】
ステップの実行におけるどのようなタイミング変化も、スケジューリングにおいて考慮されるので、ステップの実行のためのスケジュールされた時間は、最大予想実行時間よりも長い。時間スケジュールは通常、PPにおいて定義される。スケジューリングの瞬間は、実行が始まる前の「ジャストインタイム」でも、実行前のどこかの時点、たとえば実行キューにステップを追加するときでもよい。
【0064】
(d)サブシステム16によって送られ、実行されるコマンドは、最大時間が固定されたコマンドの実行を指定する。最大実行時間は、その状況が与えられたうえでの、サブシステムによって判断された所定の最大期間である。この時間を超えた場合、オペレータまたはホストシステムは、どのような訂正アクションが必要となり得るか判断する。
【0065】
(e)サブシステムが実施するべきコマンドと、関連サブシステムに送られるべきコマンドに関連付けられたデータとを有するPJステップを実行するとき、データは、コマンド自体がサブシステムに送られる前に、サブシステムに送信すればよい。データは、どの1つのメッセージもサイズが制限されるように、1つまたは複数のメッセージに入れて送信される。データは、サブシステムによって確実に受信されているように、十分に前もって送られ、すなわち、データの送付とコマンドの送付との間の時間は、予想送信時間よりもはるかに大きく、サブシステムは、データの受信に肯定応答することができる。これにより、タイミングが限界でないとき、データを含む比較的大きいメッセージが前もって送られることが可能になり、コマンド(関連データなし)のみを含むはるかに小さいメッセージを、スケジュールされた時間に送ることができる。この措置により、コマンドが送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できるコマンド送信が増える。
【0066】
(f)同様に、サブシステムは、コマンドの実行を完了すると、コマンドが完了したことを示すショートメッセージをSUSC12に送ることができるが、コマンドの実行の結果として生じたどのデータも、後の時点でSUSC12によって取り出すために保持している。SUSC12は、コマンド完了の指示を受信すると、生じたデータを取り出すためのリクエストをサブシステムに送ることができる。こうすることにより、コマンド完了指示が送られるときの、ネットワークに対する負荷が分散し、輻輳が回避されて、送信時間が短縮し、適時および信頼できる送信が増え、データは次いで、タイミングが限界でないとき、後で取り出すことができる。
【0067】
(g)サブシステム16とSUSC12との間のメッセージ交換は、SUSC12からの命令の受信に肯定応答するための返答メッセージを含む。返答メッセージは、サブシステム16がSUSC12から関連メッセージを受信し、依然として機能しているという確認以外の、どの他の情報も運ばない。これにより、SUSC12は、予想通り、サブシステム16が応答するのをいつ停止したかを検出することが可能になるので、検出内容は、適時にクラスタフロントエンドに報告することができる。ソフトウェア実施態様を単純に保つために、サブシステム16に対してタイムアウトはない。返答メッセージについて予想される総応答時間は通常、短く、たとえば往復で0.5ms未満である。非応答サブシステム16を検出するために、SUSC12には、予想応答時間をはるかに超える、たとえば応答が予想される後に30秒のタイムアウトがある。このタイムアウトは、サブシステム16が機能していないと合理的疑いの余地なく結論づけるのに十分に大きいが、オペレータ4が正常に結論づける前に失敗を検出するのには足りない程小さいので、オペレータ4は、何が起きているかを思案しなくてよい。
【0068】
(h)制御ネットワーク120は、データパッケージの一度の転送、たとえば一度に単一のメッセージシーケンスを安全にするプロトコルコントローラを含む。
【0069】
(i)制御ネットワークは、単純送信プロトコル、たとえばTCPリンクでのバイトプロトコルを使う。複雑であり、または予測不可能な要素を含む送信プロトコルは回避される。制御ネットワークにおいて使われるプロトコルにより、確実に複数のデータ転送が同時には起こり得なくなるので、ネットワーク上での予測不可能なイベントは起こらない。
【0070】
TCP接続は、2つのバイトストリームからなり、各方向に1つのバイトストリームがある。プロトコルは、これらのストリームの両方を別々のメッセージに分解し、各メッセージは、0バイト以上の任意のデータのシーケンスであり、シーケンスの長さを示す4バイトが先行する。この長さは、ネットワークオーダー(「ビッグエンディアン」)で符号なし整数、たとえば32ビット整数としてエンコードすることができ、(232−1)バイトの最大メッセージサイズを与える。このメッセージ分離機構は、Pythonプログラミング言語で「接続オブジェクト」によって実施することができる。標準多重処理接続パッケージを使うことによって、Python自体が、プロトコルのこの部分を扱うことができる。他のプログラミング環境では、この態様を明示的に実施することが必要になる。メッセージは、規定されたシーケンスにメッセージが続くのであれば、どちら側によって開始されてもよい。
【0071】
メッセージシーケンスのすべての第1のメッセージは、JavaScriptオブジェクト表記法(JSON)でエンコードされた制御データ構造を含み得る。SUSCプロトコルJSONメッセージはすべて、同じ一般的構造、すなわち2つの要素のアレイを有してよく、第1の要素は、メッセージタイプをもつストリングを含み、第2の要素は、そのメッセージについての名前付き引数をもつ辞書を含み、たとえば[“<messageType>”,{“param1”:<value1>,“param2”:<value2>,...}]となる。
【0072】
いくつかのメッセージシーケンス、たとえばインターフェースコマンドの入力および出力項目を転送するのに使われるシーケンスでは、この制御/コマンドメッセージのすぐ後に、いくつかのデータメッセージ、たとえば入出力項目ごとに1つのデータメッセージが続く。プロトコルは、これらのメッセージ中で使われるエンコードについて想定しておらず、代わりにサブシステムコマンド、データおよび挙動を指定する翻訳、たとえば「pickleでエンコードされた、2つのフロートのタプルのリスト」、または「画像/pgnとしての圧力曲線プロット」)が設計文書に記載される。
【0073】
任意のメッセージをJSON制御メッセージと混合するこの方式により、プロセスジョブ出力が、CSV、PDF、PNGなど、オペレータに理解されるデータフォーマットで直接書かれているプラグインソフトウェアによって生じられる。このことは、そのようなオブジェクトの送信が、追加エンコードも、データストリームの一部としてのエスケープもなく、たとえばLinuxのsendfile関数を使うことによって行われ得ることも意味する。この自由は、特に特定のインターフェース機能に、より適したエンコードについてサブシステムの間で合意するのに利用することもできる。ただし、すべてのサブシステムが独自のデータエンコード方式を有する場合は賢明ではないので、サブシステムに、特定の必要条件がない場合は、必要条件の中で最良のトレードオフを実施するのに、デフォルト方式が選ばれるべきである。
【0074】
(j)サブシステムは、SUSC12の正しい挙動の検証は担わず、SUSCプロトコルエラーを検出して、PIC15の設計を単純にする。SUSCプロトコルの目的は、ユーザによって作成されたプロセスジョブにおいて、プロセスプログラムからのプロセスステップを実行することである。予期せぬ挙動をユーザに通信するために、例外が使われる。コマンド実行におけるエラーに加え、当然ながら、SUSCプロトコルに準拠しないことによってもエラーが起こり得る。SUSC12は、例外のロギングを担い、PICがSUScプロトコルに従って振る舞っていない(または応答するのを完全に停止した)が、PIC必要条件を単純に保つためにSUSCの正しい挙動の検証をPICが担っていないときはPICへの接続を閉じてよい。PICがプロトコル違反に遭遇した場合、違反には正常に応答してもしなくてもよく、後続メッセージが理解されなければならないという必要条件はない。メッセージを扱うことができないときは、いくつかの診断をロギングし、例外をロギングし、切断および再接続しようと試みることが推奨される。これは、そのような再接続の後、PICが再度、使用可能状態にある(ただし、少なくとも多少は理解できる状態にある)という保証も予想もないので、推奨であって、必要条件ではない。
【0075】
(k)オペレータおよびより高レベルのオートメーションまたは監視工場コンピュータシステム用のインターフェースが、制御ネットワーク120上での通信から削除される。これらのインターフェースは、クラスタフロントエンド6から提供されるので、制御ネットワーク120上で輻輳を生成せず、サブシステム16との通信のタイミングに影響しない。
【0076】
(l)データ収集は、別個のデータネットワーク140内で、制御ネットワーク120上での制御通信とは完全に分離される。この機能分離については、後でより詳しく論じる。
【0077】
同期クロック
リソグラフィシステムは、制御ネットワーク上でクロック信号を提供して、システム内での、およびサブシステムによるアクションの同期を可能にする。システムは、異なる周波数で2つのクロック信号を提供して、異なるタイミング精度に対して、サブシステムにクロックを与えることができ、たとえば1つのクロック信号はミリ秒の精度であり、1つはナノ秒の精度である。たとえば、ビーム切替えデータをストリーミングするためのパターンストリーミングサブシステム、ならびに電子ビームレットをオンおよびオフに切り替えるためのビーム切替えサブシステムは、ビームレットの高頻度切替えを可能にするために、非常に高い頻度でデータを交換する必要があり、ビーム測定サブシステムは、ビーム位置測定値を非常に高い頻度で送ることを必要とされる。高精度クロックを必要とする他の機能には、基板位置決めシステムおよび投射光学システムがある。これらのサブシステムには、同期クロックサブシステムによって与えられるナノ秒クロックパルスによって給電され、そのようなパルスを受信することが可能である。
【0078】
制御ネットワークプロトコルメッセージ
図6A〜
図6Hは、プロトコルによってサポートされるメッセージシーケンス30、40、50、70、80、90、100を示す。シーケンス
図30、40、50、70、80、90、100には、平均的なケースにとって、およびSUSC12が接続を閉じる前に使うタイムアウトにとって必要とされる応答時間が付記されている。記載するタイミングは、原則として、SUSC12、SUSD14およびサブシステム16が関与するラウンドトリップ時間である。
【0079】
SUSC12プロトコルは、TCP接続を介してメッセージを通信する。SUSC12はTCPサーバとして作用し、サブシステム16内のPIC15はTCPクライアントとして作用する。PICは、特定のポート上のSUSC12への接続を行い、SUSC12は、制御ネットワーク120内のIPアドレスを有する。接続が失敗した場合、PICは、成功するまで再試行する。
図6Aは、サブシステム16内の要素制御ユニット(SUSC)12およびPICが互いと接続する接続シーケンス30を示す。メッセージのタイミングを示すために、SUSC12およびサブシステム16からの垂直タイムライン27、29が示されている。ある時点において、接続シーケンスは、TCPプロトコルまたはTCP接続33の標準3者ハンドシェイクで始まって、オペレーティングシステムレベルでの接続をセットアップする。TCP接続33が確立される場合、サブシステム16は、SUSC12に接続メッセージ35を送る。SUSC12は、期間31、好ましくは0.5秒以内に接続返答37を送る。接続返答37は、場所固有情報、たとえば機械が置かれたタイムゾーンを含み得る。この情報は、SUSC12のタイムゾーン39をセットするのに使うことができる。サブシステム16は、さらなる内部サブシステム初期化41を後で行うことができる。
【0080】
原則として、接続は、無期限に、すなわち双方のうちの一方がシャットダウンし、接続が閉じられるまで、開いたまま保たれる。このクローズは、アプリケーションによる明示的ソケットクローズによって、またはオペレーティングシステムのシャットダウンシーケンスの一部として、オペレーティングシステムによって自動的に起こる。PIC15は、接続のクローズを検出すると、再接続しようと試み、再接続が失敗した場合は、成功するまで再試行してよい。SUSC12は、接続のクローズを検出すると、関連PICのすべての情報(登録コマンドや計画された将来のコマンドなど)を破棄し、再接続するまではPIC15および関連サブシステム16がないと見なしてよい。
【0081】
SUSC12が接続のクローズを検出しておらず、PIC15によって重複接続が確立される特殊ケースでは、SUSC12は、以前の接続が閉じられていると見なしてよい。このシナリオは、TCP接続を閉じる機会がカーネルに与えられることなく、PIC15が突然電源オフされ、SUSC12がこのPICとの通信をまだ試みていないときに起こり得る。
【0082】
この挙動により、確実に一方が、他方のリスタートを必要とせずに、リスタートされ得る。
図6Bは、サブシステム16がすでに初期化されているが、SUSC12への接続を失っているときに開始される再接続シーケンス40を示す。SUSC12への再接続は、サブシステム16の責任である。接続メッセージ35をSUSC12に送る繰返しは、サブシステム16によって行われ、接続メッセージ35を受信すると、SUSC12は、サブシステム16に接続返答37メッセージを送り返す。ここでも、期間31、好ましくは0.5秒以内である。再接続シーケンス40は、サブシステム16がSUSC12に接続されるまで繰り返される。
【0083】
図6Cは、SUSC12による、「set」コマンド51をもつ入力引数の、サブシステム16への転送で随意に始まる実行コマンドシーケンス50を示す。setコマンド51の後には、一定量のデータ52がサブシステム16にN回送られる。最終データ52が送られた後、サブシステム16は、SUSC12にset返答53(setReply)を送り返すことによって、受信したコマンド51およびデータ52に肯定応答する。サブシステム16からSUSC12に送られるどの返答も、好ましくは0.5ミリ秒の平均未満を備える返答期間55を有する。set返答53は、好ましくは30.0秒プラスマイナス1.0秒を備えるタイムアウト限度54内に送られなければならない。返答が受信されない場合、SUSC12は、サブシステム16を、接続されていないか、または欠陥があると見なす。SUSC12が実行コマンド57を送った後、サブシステム16は、好ましくは返答期間55以内にexecuteStarted返答58で肯定応答する。サブシステム16は、実行を終了した後、SUSC12にexecuteDone59を送る。出力引数(ある場合)は、SUSC12によって送られる「get」コマンド60で取り出される。サブシステム16は、getReply61で肯定応答し、その後、N量のデータ62または出力引数を送る。
【0084】
今後の実行コマンド57にこれ以上必要とされない入力および出力引数は、消去コマンド63を使ってサブシステム16から削除される。サブシステム16は好ましくは、返答期間55内にdeleteReply64で返答する。プロトコルのあるバージョンでは、入力および出力は、あるインターフェースコマンドから他のインターフェースコマンドに運ばれない。サブシステム16は、次のコマンドに必要とされる以上の入力は送られないと、安全に想定することができ、次のコマンドの入力が送られる前に、すべての入力および出力が消去されると、安全に想定することができる。
【0085】
図6Dは、破棄された実行コマンド71のケースにおける、イベントの順序を示す破棄シーケンス70を示す。破棄シーケンス70は、大域的に、以下の違いはあるが、通常の実行シーケンス50と同じである。SUSC12は、executeStarted58とexecuteDone59メッセージの受信の間の期間中に破棄リクエスト71を送る。サブシステム16は、abortReply72を送る。破棄リクエスト71に対する応答としての、SUSC12へのabortReply72の送付は、90.0秒プラスまたはマイナス1.0秒を備える期間abortReply74内に行われなければならず、90秒は、最大ポーリング間隔のための60秒と、追加の30秒を備える。現在実行中のコマンドに依存して、コマンドは、完了するように稼動し、またはコマンドが終了される前に中断する。コマンドが終了されなかった場合、例外91をロギングすればよい。また、すべての出力引数が利用可能なわけではなく、空のもの(0バイト)はサブシステム16によって置換されてよい。SUSC12は、それらをすべて取り出そうとする。SUSC12からの破棄メッセージ71およびサブシステム16からのexecuteDone59が互いと交差することが可能である。この場合、
図6Eに示すシーケンス80が適用可能である。
【0086】
図6Eは、競合条件80をもつ破棄シーケンスを示す。競合条件81は、2つ以上のメッセージが互いと交差するときに起こる条件である。ここで、破棄メッセージ71は、executeDoneメッセージ59と交差する。
【0087】
図6F、
図6G、および
図6Hは、例外シーケンス90についての3つのケースを示す。例外90が、たとえば、エラーやアラームの形で起こると、例外メッセージが、サブシステム16によってSUSC12に送られる。エラーは、リソグラフィ要素が予想通りに振る舞っていないことをユーザ4に通信するのに使われる。アラームとは、ユーザ4によって肯定応答されなければならない条件である。
【0088】
インターフェースコマンドを実行するコンテキストにおいて起こる例外91は、コンテキスト情報でタグ付けすることができる。そのようなコマンドのコンテキストの外で起こる例外91(自発的例外90)に対して、これらのコンテキストフィールドは空にされてよく、または失敗に関連した、すでに完了されたコマンドの最も適切なコンテキストが供給されてよい。
【0089】
特に自発的例外90のケースでは、ユーザ4に例外を殺到させないように気をつけるべきである。たとえば、高頻度制御ループ中でエラー条件が検出される場合、理想としてはただ1つの例外91が、その条件に対してデータネットワークハブ14によってロギングされるべきであり、ループのすべての反復に対して繰り返しロギングされるべきではない。条件が持続する場合は、例外91を低(好ましくは1分)頻度で繰り返し、または条件が変わり、または消えたとき(やはり予期されないので、依然として例外91と見なすことができる)は、フォローアップ例外91をロギングする方が、より優れているであろう。
【0090】
例外91は、オペレータ4にエラー状況を通知し、オペレータ4を回復手順に誘導し、問題の本質を簡潔に、たとえば電話またはトラブルチケットタイトルによって通信することを意図している。例外91はしたがって、モジュール設計者のためのデバッグ情報チャネルと見なされるべきではない。あるいは、人間可読データフォーマットでのPJ出力が、オフラインでモニタまたは調査することができる情報に使われ得る。
【0091】
例外メッセージ91は、プロトコルシーケンスを終了せず、今後のコマンドを扱うのを停止する理由にはならない。たとえば、インターフェースコマンドが失敗し、例外91がデータネットワークハブ14によってロギングされた後、executeDone59は依然として送られ、出力は「get」可能にされてよい。サブシステム16も、状況から回復するための新規インターフェースコマンドを受諾する準備ができているべきである。
【0092】
例外91は、getReply61シーケンス内を除いて、プロトコルにおいていつでも挿入されることが可能である。いかなる例外91も並列スレッドによって生成することができる場合、PIC16の設計者は、そのような例外91をロギングするためであって、どのコマンドのためでもない、専用のPIC16接続を割り振ることを検討することができる。そうすることにより、この干渉が直接的に回避される。
【0093】
図6Fは、SUSC12から送られる汎用または任意のプロトコルコマンド92中でサブシステム16によって生成される例外91を示す。例外91の後、サブシステム16はまた、任意のプロトコルコマンド返答93をSUSC12に送る。
図6Gは自発的例外91を示し、
図6Hは、実行コマンド57中にサブシステム16からSUSC12に送られる例外91を示す。どのプロトコルコマンド92中でも、例外91が起こされ得る。コマンドは、関連返答メッセージで正常に終了される。
図6Gに示すように、SUSC12からのコマンドの間で、例外91がロギングされることも可能である。たとえば、定期的チェックから、またはハブ初期化シーケンスからである。実行コマンド57中に例外91が送られると、例外91が起こっていなくても、get60および消去63コマンドが実行される。ただし、例外91の出現により、いくつかの出力引数が空(0バイト)になり得ることが可能である。
【0094】
データネットワーク
サブシステム16は、データネットワーク140を介してデータネットワークハブ14に接続される。データ収集、記憶および管理は、データネットワーク140を介して実施される。制御ネットワーク120は、要素制御ユニット12とリソグラフィサブシステム16との間の制御ネットワーク経路を形成し、データネットワーク140は、データネットワークハブ14とリソグラフィサブシステム16との間のデータネットワーク経路を形成する。制御ネットワーク120およびデータネットワーク140は、物理的に別個のネットワークであり、各ネットワークは、配線と、スイッチなどのネットワーク構成要素と、サブシステム16へのネットワーク接続とを含む、独自の別個の物理媒体を有する。このように、制御ネットワーク経路およびデータネットワーク経路は、物理的に別個の媒体を備え、別個の独立通信経路を形成する。
【0095】
各リソグラフィサブシステム16は、制御ネットワークを介して要素制御ユニット12との間で制御情報を受信および送信するように適合された制御ネットワーク140への接続を有する。各リソグラフィサブシステム16は、データネットワークを介してデータネットワークハブ14にデータ情報を送信するように適合された、データネットワーク140への別個の接続を有する。
【0096】
データネットワーク140は、サブシステム16によって使われる送信レートよりもはるかに大きい帯域幅を有して設計される。たとえば、データネットワーク140は、1Gbit/sの帯域幅と、100Mbit/sで送信するように設計されたサブシステムとを有し得る。データネットワークには、ネットワークコントローラもなく、データ転送の調整も行われない。通常、データネットワーク140では、データ交換上限は、サブシステム16とデータネットワーク140との間で140Mbitに設定され、1Gbitの上限が、データネットワーク140とSUSD14との間のデータ交換に対して設定される。トラフィックをマージして、(データ)パッケージ衝突を防止するためのネットワークスイッチが、データネットワーク140に含まれる。
【0097】
データネットワークハブ14は、サブシステム16から受信したデータを連続してロギングするように適合される。このデータは、PJの実行中にサブシステムによってとられた測定データと、サブシステムの設定と、デバッグおよび障害追跡についてのデータとを含み得る。データネットワークハブ14は好ましくは、低レベルの追跡データを含むすべてのデータを常にロギングしているので、データロギングをオンにする必要はない。この継続的データロギングは、問題診断を高速化し、エラーまたは問題を再稼動および再生する必要を減らす。
【0098】
要素制御ユニット12は、データネットワークハブ14によるロギングのために、要素制御ユニット12内で実行するPJの進行に関する情報を送るように、データネットワークハブ14に接続される。データネットワークハブ14は、要素制御ユニット12から受信したデータを連続してロギングする。
【0099】
データネットワークハブ14は、長い動作期間にわたる、たとえば月または年の規模で、すべてのサブシステム16からの非常に大量の低レベルデータの記憶に十分な、非常に大きいデータ記憶容量を含む。データネットワークハブ14によって記憶されたデータは、体系化され、好ましくはタイムスタンプおよびPJ識別子でタグ付けされる。記憶されたデータは、データネットワークハブ14から取り出し、好ましくはオフラインで、分析およびフィルタリングすることができる。
【0100】
データネットワーク140を介したデータ収集を、制御ネットワーク120を介した制御通信とは分離することにより、制御ネットワークにわたる通信を損なうことなく、データネットワークにわたる高容量データの高頻度収集が可能になる。制御ネットワークは、制御ネットワーク120上の輻輳を制御し、データネットワーク140上に存在する高容量トラフィックを回避することによって、準リアルタイムで動作することが可能になる。データネットワークハブ14内でのデータ管理および記憶機能の分離と、要素制御ユニット12内でのPJ実行により、要素制御ユニット12によるPJの処理を損なうことなく、データネットワークハブ14による高容量のデータの処理が可能になる。制御およびデータ収集および管理の分離により、2つのシステムの間の対話を考慮する必要なく、より単純な設計が可能になる。
【0101】
本発明を、上で論じたいくつかの実施形態を参照して説明した。これらの実施形態は、本発明の精神および範囲から逸脱することなく、当業者によく知られている様々な修正および代替形が可能であることが理解されよう。したがって、特定実施形態について説明したが、これらは例にすぎず、添付の請求項において定義される本発明の範囲に対する限定ではない。
以下に、本出願時の特許請求の範囲に記載された発明を付記する。
[1] 1つまたは複数のリソグラフィ要素(10)を備えるクラスタ化基板処理システムであって、各リソグラフィ要素が、パターンデータに従って複数の基板を独立して露光するために用意され、各リソグラフィ要素が、
複数のリソグラフィサブシステム(16)と、
前記複数のリソグラフィサブシステムと少なくとも1つの要素制御ユニット(12)との間の制御情報の通信のために用意された制御ネットワーク(120)であって、前記要素制御ユニットが、前記複数のリソグラフィサブシステムに複数のコマンドを送信するように用意され、前記複数のリソグラフィサブシステムが、前記要素制御ユニットに複数の応答を送信するように用意された、制御ネットワークと、
オペレータまたはホストシステム(2、4)とのインターフェースのためのクラスタフロントエンド(6)であって、前記フロントエンドが、1つまたは複数のウエハの露光のために前記1つまたは複数のリソグラフィサブシステムの動作を制御するための制御情報を、前記少なくとも1つの要素制御ユニットに発行するために用意されたクラスタフロントエンドとを備え、
前記フロントエンドが、前記要素制御ユニットにプロセスプログラムを発行するために用意され、前記プロセスプログラムが、あらかじめ規定されたコマンドおよび関連パラメータのセットを備え、各コマンドが、前記複数のリソグラフィサブシステムのうちの1つまたは複数によって実施されるべき、あらかじめ規定された1つのアクションまたは一連のアクションに対応し、前記複数のパラメータが、前記1つのアクションまたは一連のアクションがどのように実施されるべきかをさらに定義する、システム。
[2] 前記要素制御ユニットが、前記複数のリソグラフィサブシステムによって実行するための対応するプロセスジョブを生成するように前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、前記プロセスプログラムの前記コマンドセットと、前記複数のコマンドの各々についてのスケジュールされた実行時間とを備える、前記[1]に記載のシステム。
[3] 前記要素制御ユニットが、前記プロセスプログラムの前記コマンドセットと、前記複数のコマンドの各々について、前記コマンドを実行するようにスケジュールされたリソグラフィサブシステムの識別情報とを備える前記プロセスジョブを生成するために用意される、前記[2]に記載のシステム。
[4] 前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、前記識別されたリソグラフィサブシステムに送信することによって前記プロセスジョブを実行するように用意される、前記[3]に記載のシステム。
[5] 前記要素制御ユニットが、前記プロセスジョブの前記複数のコマンドの各々を、前記プロセスジョブの先行コマンドの実行状況にかかわらず、前記複数のコマンドの各々に対して前記スケジュールされた実行時間に、前記識別されたリソグラフィサブシステムに送信するように用意される、前記[4]に記載のシステム。
[6] 前記プロセスプログラムが、対応するコマンドについての所定の期間を定義し、前記要素制御ユニットが、前記複数のリソグラフィサブシステムによって実行するためのプロセスジョブを生成するように前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、各コマンドについてのスケジュールされた実行時間を備え、前記所定の期間が、前記プロセスジョブ中の前記対応するコマンドについての前記スケジュールされた時間を判断するのに使われる、前記[1]から[5]のいずれかに記載のシステム。
[7] 前記プロセスプログラムが、対応する第1のコマンドについての第1の所定の期間を定義し、前記要素制御ユニットが、前記期間の時間切れまで、前記第1のコマンドの実行状況にかかわらず、前記第1のコマンドに続く次のコマンドの開始を遅らせるように用意される、前記[1]から[6]のいずれかに記載のシステム。
[8] 前記要素制御ユニットが、1つのアクションまたは複数のアクションについての前記1つまたは複数のパラメータを、前記制御ネットワークを介して前記サブシステムに送り、その後、前記1つのアクションまたは複数のアクションに対応する前記コマンドを前記サブシステムに送ることによって、前記複数のリソグラフィサブシステムのうちの1つによって前記1つのアクションまたは一連のアクションを開始するように用意される、前記[1]から[7]のいずれかに記載のシステム。
[9] 前記要素制御ユニットが、前記コマンドを実行するためのスケジュールされた時間より一定期間だけ前に、前記サブシステムに前記1つまたは複数のパラメータを送るように用意され、前記期間が、前記コマンドが前記サブシステムに送られる前に前記サブシステムが前記1つまたは複数のパラメータを受信したことを保証するのに十分である、前記[8]に記載のシステム。
[10] 前記要素制御ユニットによって発行されたコマンドに対応する1つのアクションまたは一連のアクションが完了すると、前記1つのアクションまたは一連のアクションを完了した前記リソグラフィサブシステムが、前記要素制御ユニットに前記完了を通知するために用意され、前記要素制御ユニットから命令を受信すると、前記1つのアクションまたは一連のアクションの実行に関するデータを発行するように用意される、前記[1]から[9]のいずれかに記載のシステム。
[11] 前記プロセスプログラムが条件ステップを含まない、前記[1]から[10]のいずれかに記載のシステム。
[12] 前記プロセスプログラムが、複数の代替コマンドとしてプログラムされた複数の条件ステップを含み、前記要素制御ユニットが、前記複数のリソグラフィサブシステムによる実行のためにプロセスジョブを生成するように、前記プロセスプログラムをスケジューリングするために用意され、前記プロセスジョブが、各コマンドについてのスケジュールされた実行時間を備え、前記複数の代替コマンドが、前記プロセスジョブ内で並行してスケジュールされ、前記プロセスジョブの前記実行時間が全体として、どの代替コマンドが実行用に選択されるかによって変わらないように、各代替コマンドには、同じ実行時間が割り当てられる、前記[1]から[11]のいずれかに記載のシステム。
[13] ソフトウェアをアップデートまたはアップグレードするための、リソグラフィサブシステム内の前記ソフトウェアの修正が、前記要素制御ユニット内でプロセスジョブを実行することによって実施される、前記[1]から[12]のいずれかに記載のシステム。
[14] 前記制御ネットワークが、リアルタイムの通信プロトコルを使わずに準リアルタイム性能を提供する、前記[1]から[13]のいずれかに記載のシステム。
[15] 各リソグラフィ要素が、前記複数のリソグラフィサブシステムから少なくとも1つのデータネットワークハブ(14)へのデータロギング情報の通信用に用意されたデータネットワーク(140)をさらに備え、前記複数のリソグラフィサブシステムが、前記データネットワークハブにデータロギング情報を送信するように用意され、前記データハブが、前記データロギング情報を受信および記憶するために用意され、前記フロントエンドが、前記データネットワークハブによって受信された前記データロギング情報の少なくとも一部分を受信するためにさらに用意される、前記[1]から[14]のいずれかに記載のシステム。
[16] 前記複数のリソグラフィサブシステムが、第1の送信レートで前記データネットワークにデータを送信するように用意され、前記データネットワークハブが、第2の送信レートで前記データネットワークからデータを受信するように用意され、前記第2の送信レートが、前記第1の送信レートよりもはるかに大きい、前記[1]から[15]のいずれかに記載のシステム。
[17] 前記制御ネットワークが、TCPリンク上でバイト送信プロトコルを使う、前記[1]から[16]のいずれかに記載のシステム。
[18] 前記要素制御ユニットおよび前記複数のリソグラフィサブシステムが、前記制御ネットワーク上で複数のメッセージシーケンスを送信するように用意され、メッセージシーケンスの第1のメッセージが2つの要素を備え、第1の要素が、メッセージタイプをもつストリングを含み、第2の要素が、前記メッセージについての複数の名前付き引数をもつ辞書を含む、前記[1]から[17]のいずれかに記載のシステム。
[19] 前記メッセージシーケンスの前記第1のメッセージが、JavaScriptオブジェクト表記法(JSON)でエンコードされた制御データ構造を含む、前記[18]に記載のシステム。
[20] 前記メッセージシーケンスの第2のメッセージが、1つまたは複数のエンコードされたデータメッセージを備え、前記複数のデータメッセージの前記エンコードが、前記制御ネットワークプロトコルによって設定または制限されない、前記[18]または[19]に記載のシステム。
[21] 前記制御ネットワークが、前記制御ネットワーク上で複数のデータ転送が同時に起こらないようにするように用意されたコントローラを含む、前記[1]から[20]のいずれかに記載のシステム。