JP2006179934A - 適応性のある機器状態モデル・ビューを生成するソフトウェア装備品、機器の信頼性を測定するソフトウェア・メカニズム - Google Patents

Abstract

【課題】機器上で、ＳＥＭＩ規格に適合するユーザ固有のビューを提供することを可能とする機器監視及びリソグラフィ処理を提供する。
【解決手段】状態モデル・エンジンは、リソグラフィ処理システムの信頼性、可用性、及び保全性に関連するデータを動的に確定するように構成される。ＳＥＭＩ Ｅ１０は、全ての機器条件及び全ての機器時間が属する６つの基本機器状態、すなわち、生産的状態、スタンドバイ状態、エンジニアリング状態、計画内ダウンタイム状態、計画外ダウンタイム状態、未計画状態を定義する。エンジンは、他の状態モデルによって発行された遷移イベントに基づいて、定義された状態モデルにおいて状態変化が発生するかどうかを評価する。
【選択図】図２

Description

本発明は、機器監視及びリソグラフィ処理に関する。

リソグラフィ装置は、基板の標的部分上に所望のパターンを適用する機械である。リソグラフィ装置は、例えば、集積回路（ＩＣ）の製造で使用する可能性がある。こうした状況では、マスクなどのパターニング構造を使用して、ＩＣの個々の層に対応する回路パターンを生成することができ、このパターンは、放射に敏感な材料（レジスト）を有する基板（例えば、シリコンウェハ）上の（例えば、１つ又はいくつかのダイの一部又は全てを含む）標的部分上にイメージングされる可能性がある。一般に、単一基板は、連続して露光される隣接する標的部分のネットワークを収容するであろう。知られているリソグラフィ装置は、標的部分上に全体のパターンを一度に露光することによって、それぞれの標的部分が照射される、いわゆる、ステッパ、及び、投射ビームを通してパターンを所与の方向（「走査」方向）に走査し、一方、基板を、この方向に平行又は逆平行に同期して走査することによって、それぞれの標的部分が照射される、いわゆる、スキャナを含む。

半導体デバイスが製造される工場（一般に、「ファブ」又は「ファウンダリ」）は、リソグラフィ装置などのリソグラフィ処理機械（又は、「機器」）を含む。それぞれのリソグラフィ装置は、一般に、「トラック」（例えば、ウェハ・ハンドリング・デバイス並びに処理前及び処理後デバイスなどの他のリソグラフィ処理機械又は「機器」を備える）によってグループ化されて、リソグラフィ処理セル又は「リソセル」と一般に呼ばれるリソグラフィ処理システムを形成する。リソグラフィ装置とトラックは共に、それ自体が、さらなる管理制御システムの制御下にある管理制御システムを有することができる。

空白であるか、或いは、１つ又は複数のプロセス又はデバイス層を含むように既に処理されていてもよいウェハは、処理のために、ロット（バッチとも呼ばれる）でリソセルに送出される。ロットは、一般に、リソセルによって同じ方法で処理されることになり、且つ、実行されるプロセスを指定する「レシピ」を伴うウェハのグループである。ロット・サイズは、任意であるか、又は、ファブの周辺で基板を搬送するのに使用されるキャリアのサイズによって決まってもよい。レシピは、塗布されるレジスト・コーティング、露光前及び露光後ベーキングの温度及び継続時間の詳細、露光されるパターン及びそれについての露光設定の詳細、現像継続時間などを含んでもよい。

ファブは、多数のツールを含んでもよく、その中の任意のツールが、ある時に、アイドル状態であるか、又は、その他非生産的状態にある場合がある。例えば、効率、生産量、スループット、及び収益性を最大にするために、機器のアイドル時間を最小にすることが望ましい場合がある。再現性を確実にする、無駄を低減する、且つ／又は、仕様からの逸脱を予想するために、機器を監視することが望ましい場合がある。運転中のファブにおいて、機器の種々のステータスを追跡することは複雑なタスクである。

機器の全体機能を制御するか、又は、全体機能の情報を得るために、業界団体ＳＥＭＩ（Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｅｑｕｉｐｍｅｎｔ ａｎｄ Ｍａｔｅｒｉａｌｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ）は、要求される外部挙動についてのいくつかの規格（例えば、ＳＥＭＩ Ｅ３０、Ｅ４０など）において状態モデル（又は「ビュー」）を規定した。状態モデルはまた、機器の性能を測定するために定義される（例えば、ＳＥＭＩ Ｅ５８）。これらの状態モデルの実施は、通常、それぞれの要求される状態モデルについて、一定の位置においてソフトウェアにトリガーを挿入することによって実現される。これらのモデルの修正は費用がかり、時間がかる場合がある。

結果として、機器上でユーザ固有のビューを提供することは可能でないことになる。

一実施例では、リソグラフィ処理機械を制御する方法は、トリガー・イベントの発生に基づいて、機械の第１状態モデルの遷移を記録すること、及び、遷移に対応する遷移イベントに基づいて、機械の第２状態モデルを更新することを含む。別の実施例では、第２状態モデルは第１状態モデルから導出される。

本発明の実施例は、ＳＥＭＩ Ｅ１０及びＥ５８などの規格を実施するために適用することができる。種々の状態において費やされる時間及び状態間における遷移の頻度などのデータから、平均割り込み時間間隔（ＭＴＢＩ）、平均修理時間（ＭＴＴＲ）、可用性、及び信頼性が求められる可能性がある。

図１は、本発明の特定の実施例によるリソグラフィ装置を概略的に示す。装置は、放射（例えば、ＵＶ放射又はＥＵＶ放射）の投射ビームＰＢを提供する照射システム（照射器）ＩＬ、パターニング構造（例えば、マスク）ＭＡを支持し、パターニング構造をアイテムＰＬに対して正確に位置決めする第１ポジショナＰＭに接続される第１支持構造（例えば、マスク・テーブル）ＭＴ、基板（例えば、レジストをコーティングしたウェハ）Ｗを保持し、基板をアイテムＰＬに対して正確に位置決めする第２ポジショナＰＷに接続される基板テーブル（例えば、ウェハ・テーブル）ＷＴ、フレームＦ上に取り付けられ、パターニング構造ＭＡによって投射ビームＰＢに与えられたパターンを、基板Ｗの標的部分Ｃ（例えば、１つ又は複数のダイを含む）上にイメージングする投射システム（例えば、屈折投射レンズ）ＰＬを備える。

本明細書で示すように、装置は透過タイプである（例えば、透過マスクを採用する）。別法として、装置は、反射タイプ（例えば、先に述べたタイプのプログラム可能なミラー・アレイを採用する）であってよい。

照射器ＩＬは、放射源ＳＯからの放射を受け取る。例えば、放射源がエキシマ・レーザである時、放射源及びリソグラフィ装置は、別々の実体（ｅｎｔｉｔｙ）である。こうした場合、放射源は、リソグラフィ装置の一部を形成すると考えられず、放射ビームは、例えば、適当な誘導ミラー及び／又はビーム・エキスパンダを備えるビーム送出システムＢＤを使用して、放射源ＳＯから照射器ＩＬへ渡される。他の場合では、例えば、放射源が水銀ランプである時、放射源は装置の一体の部品であってよい。放射源ＳＯ及び照射器ＩＬは、必要である場合、ビーム送出システムＢＤと共に、放射システムと呼ばれてもよい。

照射器ＩＬは、ビームの角度輝度分布を調整するように構成された調整器ＡＭを備えてもよい。一般に、照射器の瞳面における、少なくとも外部及び／又は内部の放射方向の輝度分布の程度（一般に、それぞれ、σ−外部及びσ−内部と呼ぶ）を調整することができる。さらに、照射器ＩＬは、一般に、積分器ＩＮ及びコンデンサＣＯなどの種々の他の部品を備える。照射器は、その断面において所望の均一性及び輝度分布を有する、投射ビームＰＢと呼ばれる調節された放射ビームを提供する。

投射ビームＰＢは、マスク・テーブルＭＴ上に保持されるマスクＭＡ上に入射する。マスクＭＡを横切って、投射ビームＰＢは、レンズＰＬを通過し、レンズＰＬは、基板Ｗの標的部分Ｃ上にビームＰＢを収束させる。第２ポジショナＰＷ及び位置センサＩＦ（例えば、干渉デバイス）を使用して、基板テーブルＷＴは、例えば、ビームＰＢの経路内の異なる標的部分Ｃを位置決めするために、正確に移動されることができる。同様に、第１ポジショナＰＭ及び別の位置センサ（図１には明示的には示さない）を使用して、例えば、マスク・ライブラリから機械的に取り出した後か、又は、スキャン中に、ビームＰＢの経路に対してマスクＭＡを正確に位置決めすることができる。一般に、オブジェクト・テーブルＭＴ及びＷＴの移動は、ポジショナＰＭ及びＰＷの一部を形成する、ストロークの長いモジュール（粗い位置決め）とストロークの短いモジュール（精密な位置決め）を使用して実現されるであろう。しかし、ステッパの場合（スキャナと対照的に）、マスク・テーブルＭＴは、ストロークの短いアクチュエータのみに接続されるか、又は、固定されてもよい。マスクＭＡ及び基板Ｗは、マスク・アライメント・マークＭ１、Ｍ２、及び、基板アライメント・マークＰ１、Ｐ２を使用して位置合わせ（ａｌｉｇｎ）されてもよい。

示す装置を、以下の好ましいモードで使用することができる。

１．ステップ・モードでは、マスク・テーブルＭＴ及び基板テーブルＷＴは、投射ビームに与えられる全体のパターンが、標的部分Ｃ上に１度で投射される間、実質的に固定したままにされる（即ち、単一静的露光）。基板テーブルＷＴは、その後、異なる標的部分Ｃを露光できるようにＸ及び／又はＹ方向にシフトされる。ステップ・モードでは、露光フィールドの最大サイズは、単一静的露光でイメージングされる標的部分Ｃのサイズを制限する。

２．スキャン・モードでは、マスク・テーブルＭＴ及び基板テーブルＷＴは、投射ビームに与えられるパターンが、標的部分Ｃ上に投射される間、同期して走査される（即ち、単一動的露光）。マスク・テーブルＭＴに対する基板テーブルＷＴの速度及び方向は、投射システムＰＬの（縮小率）拡大率及びイメージ反転特性によって決まる。スキャン・モードでは、露光フィールドの最大サイズは、単一動的露光の標的部分の（走査しない方向の）幅を制限し、走査運動の長さは、標的部分の（走査方向の）高さを決める。

３．別のモードでは、プログラム可能なパターニング構造を保持するマスク・テーブルＭＴは、実質的に固定したままにされ、基板テーブルＷＴは、投射ビームに与えられるパターンが、標的部分Ｃ上に投射される間、移動する、即ち、走査される。このモードでは、一般に、パルス放射源が採用され、プログラム可能なパターニング構造は、基板テーブルＷＴのそれぞれの移動後か、又は、走査中における連続した放射パルスの間に、必要に応じて更新される。この動作モードを、先に参照したタイプのプログラム可能なミラー・アレイなどの、プログラム可能なパターニング構造を利用するマスク無しリソグラフィに容易に適用することができる。

上述した使用モード又は全く異なる使用モードに関する組み合わせ、及び／又は、変形を採用してもよい。

以下の用語が本明細書で使用される。用語が本明細書に現れる文脈と整合性のない、これらの用語が有することができる、任意の他の一般的な意味に加えて、これらの用語は、以下の意味を伝えるものと理解されるであろう。

条件：他の状態モデルの特定の状態への参照。他の状態モデルの現在の状態が、条件において参照された状態である時、条件は真である。

カウンタ：（例えば、機器の履歴をレポートするために）特定の期間の間の特定のイベントの発生をカウントするオブジェクト。

導出された状態モデル：まさしく１つの他の状態モデルから受け取った遷移イベントに基づいて遷移を定義する状態モデル。

イベント：意味のある何かが発生したことを機器に通信すること。発生は、物理的イベントであってよく、本明細書で意味される実際の「イベント」は、イベントを検出するソフトウェア・コンポーネントによる、その物理的イベントの通信である。同様に、内部状態モデル又は他の状態モデルによって発行される遷移の指示。

内部状態モデル：ソフトウェア・コンポーネントによって維持され、且つ、そのコンポーネントの機能性及び／又は挙動を記述することに限定される状態モデル。

状態：その間に、オブジェクトが、ある条件を満たすか、ある活動を実施するか、又は、あるイベントが起こるのを待つ、オブジェクトの使用期間の間の条件又は状況。状態は、状態それ自体であるサブ状態を含んでもよく、スーパー状態に含まれてもよい。状態モデルが状態内にある場合、状態は、その状態の全ての親状態内にある。

状態モデル：状態間の遷移が発生してもよい時を定義する状態のセット及び規則（トリガー）のセット。

状態変数：機器の状態に関する情報を含む変数。変数の値は、機器によって連続して（又は、定期的に）更新され、モニタによって読み取ることができる。

サブ状態：別の状態内の状態。

スーパー状態：別の状態、特に、６つの基本機器状態のうちの１つを含む状態。

遷移イベント：状態モデルにおける状態遷移の発生の通信。遷移イベントが指示する遷移について、遷移イベントが一意であること（すなわち、どの異なる遷移も同じ遷移イベントを発行することができないこと）が望ましい場合がある。

トリガー：ターゲット状態への遷移が起こってもよい時を定義するトリガー。関連するイベントが発生し、（該当する場合）状態モデルがソース状態にあり、（該当する場合）遷移条件が真である場合、状態モデルの現在の状態は、ターゲット状態に変更され、遷移イベント（該当する場合）が発行される。

ＳＥＭＩ規格Ｅ１０は、機器の信頼性、可用性、及び保全性（ＲＡＭ）の定義及び測定についての仕様である。ＳＥＭＩ Ｅ１０は、全ての機器条件及び全ての機器時間が属する６つの基本機器状態、すなわち、生産的状態、スタンドバイ状態、エンジニアリング状態、計画内ダウンタイム状態、計画外ダウンタイム状態、未計画状態を定義する。図２の表は、これらの６つの状態についてのさらなる説明及び実施例を提供する。

６つの基本ＲＡＭ状態のうちの任意の状態は、サブ状態内にさらに定義されてもよく、サブ状態は、サブ状態にさらに分割されてもよい。図３は、生産的状態が、いくつかのレベルのサブ状態に分割される実施例を示す。デフォルト・モデルは、２レベルのみの深さであるが、本発明の実施例による状態モデル・エンジンは、２レベルを超える深さである、すなわち、サブ状態内のサブ状態内のサブ状態などである状態（多レベル状態）を記述するビューを処理することが可能であってもよい。

６つの基本状態に基づいて、ＳＥＭＩ Ｅ１０はまた、機器についての全時間が分割される時間ブロックを定義する（図４を参照されたい）。各ツールについての全時間は、まず、オペレーション時間及び未計画時間に分割される。オペレーション時間はさらに、５つの種類、すなわち、エンジニアリング時間、生産的時間、スタンドバイ時間、計画内ダウンタイム、及び計画外ダウンタイムに分割される。

ＳＥＭＩ Ｅ１０はまた、平均割り込み間隔（ＭＴＢＩ）、平均故障間隔（ＭＴＢＦ）、平均人為的補助間隔（ＭＴＢＡ）、平均割り込み運用サイクル間隔（ＭＣＢＩ）、平均故障運用サイクル間隔（ＭＣＢＦ）、平均人為的補助運用サイクル間隔（ＭＣＢＡ）を含む、機器性能に関連するいくつかのＲＡＭメトリックを定義する。

ＳＥＭＩ Ｅ１０は、上述した機器状態を定義するが、機器状態は、自動化機器によって適用されるように具体的に書かれなかった。ＳＥＭＩ規格Ｅ５８、自動化信頼性、可用性、及び保全性（ＡＲＡＭＳ）規格は、自動化機器のためにＳＥＭＩ Ｅ１０を解釈し、正規の状態モデル方法を通して基本状態の一貫した解釈を提供する。ＳＥＭＩ Ｅ５８は、ＳＥＭＩ Ｅ１０に記載される状態遷移のためのトリガーを指定する。ＳＥＭＩ Ｅ５８はまた、１５のデフォルト遷移規則（図５に列挙される）及びＳＥＭＩ Ｅ１０で定義される６つの基本機器状態のサブ状態を表す標準コードのセットを定義する。

ＳＥＭＩ Ｅ５８は、半導体機器の性能を測定する指針を提供する。これらの指針は、２つの部分、すなわち、機器時間を分類する方法の定義を含む第１部分及び機器性能を測定する方法の定義を含む第２部分に分割される可能性がある。ＳＥＭＩ Ｅ５８は、ＳＥＭＩ Ｅ５８が提供する基本状態モデルを使用して、これらの測定を行うことを要求する。

ＳＥＭＩ Ｅ５８は、機器がそれ自体の状態を確定することを要求するが、機器が確定する方法を指定しない。本発明の実施例によるメカニズムを使用して、自動的に、且つ、リアルタイムに機器の状態を確定することができる。こうしたメカニズムを使用して、ユーザ固有のシステムのビューを作成するためにユーザが適用する可能性がある新しい機能性を適用することができる。

図６は、本発明の実施例によるシステム５０のブロック図を示す。システム５０は、本発明の実施例によるシステム・モニタ１００、システム・バス２０、及び１台又は複数台のリソグラフィ処理装置１０を含む。システム・モニタ１００は、本明細書で述べる方法を実施するための、機械によって実行可能な命令の１つ又は複数のセットを実行する、１つ又は複数のコンピュータ、プロセッサ、及び／又は、サーバを（おそらく、１つ又は複数のデータベースと共に）使用して実施することができる。システム５０はまた、レシピに従って（また、モニタ１００によって出力された情報に従って）処理済みウェハを製造するために、（例えば、バス２０を通じて送信されたコマンドを介して）機器１０を制御する制御システム、及び／又は、バス２０を通じて通信を制御するバス・コントローラなどの、バス２０に結合した他のデバイスを含んでもよい。

システム・バス２０は、ＣＯＲＢＡオブジェクトとしてパッケージされたメッセージを運ぶ共通オブジェクト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）バス、分散共通オブジェクト・モジュール（ＤＣＯＭ）、或いは１つ又は複数の他の標準又は特殊バスなどの標準通信バスを含んでもよい。メッセージが、半導体機器通信規格（ＳＥＣＳ）などの共通規格に従って、バス２０を通じて送信されることが望ましい場合がある。機器１０によってバス２０を通じて送信されたメッセージは、警告メッセージ、イベント・メッセージ、パラメータ更新、トリガーなどを含んでもよい。システム５０の種々の要素の、特定の入力／出力要件に応じて、システムはまた、メッセージ又はオブジェクトを１つの形態から別の形態に（例えば、ＤＣＯＭからＣＯＲＢＡへ）変換する１つ又は複数のインタフェースを含んでもよい。

機器１０の状態当たりの時間を確定することに対する１つの手法は、システム・モニタ５０が、具体的にそうするように書かれたソフトウェア（例えば、機械実行可能部分の１つ又は複数のセット）を実行することであろう。すなわち、システム・モニタ５０は、機器がどの状態にあるか、及び、どれだけの期間かを監視するように構成されることになる。モニタ５０は、情報を記憶し、要求されると、オンラインで読まれる報告書を作成するか、又は、オフライン解析のために、関連するデータをホスト（例えば、別のコンピュータ又は人オペレータ）に送出することになる。

しかし、この手法は、モデルが変わる場合、又は、状態当たりにより多くの詳細が要求される場合に問題を提示する場合がある。こうした変更は、機器のスループットを最適化するために行われることもあるが、機器が、例えば、それほど長い期間、なぜスタンドバイ状態にあるかを判定するために行われる可能性もある。機器のユーザは、ＡＲＡＭＳでない状態モデルを使用して機器のＲＡＭを確定したいと思う可能性もある。こうした要求を処理することができるように、ソフトウェアは、変更されなければならないことになり、それは、非常に費用がかかって、且つ、時間がかかる可能性がある。

当技術分野では、ＳＥＭＩ規格が変わるか、新しい規格が作成されるか、又は、ユーザが、機器に関するユーザ自身のビューを持ちたいと思う時にはいつでも、必要とされる場合があるトリガー及び状態モデルの全てを組み入れるために、機器のソフトウェアを変更することが必要であった。結果として得られる更新は、かなり時間がかかり、高価である場合があり、ＳＥＭＩ規格への準拠は、市場に出るまでにかなりの時間がかかる場合がある。顧客固有のビューを構築することは、費用がかかり過ぎる、且つ／又は、遅すぎる場合があり、新しい機器生成を行う時に、ソフトウェアの再使用が可能でない場合がある。

本発明の一実施例は、機器を制御するのに使用される、既存の、ネイティブな（サブ）システム状態モデル及びイベントを使用するメカニズムを提供する。これらの固有のモデルは、機器の性能を調査するため、又は、要求される外部挙動を示すために、複数のビュー（すなわち、ビュー当たり１つのビュー状態モデル）を作成するようにタップが付けられる。ビューは、機器の既存のソフトウェアに影響を与えることなく、付加され、削除され、変更される可能性がある。これは、機器がその意図する機能（すなわち、ランタイム）を実施する間に起こる可能性がある。複数のビュー（マルチレベル）の上にビューを構築することも可能である。例えば、実施例による状態モデル・エンジンは、複数の「ビュー」を並列に処理するようにも、他の「ビュー」の上に構築された「ビュー」（マルチレベル・ビュー又は積層したビュー）を処理するようにも構成される。

一実施例による状態モデル・エンジンは、ＲＡＭデータを動的に確定するように構成される。（システム・モニタ５０の一部であってよい）１つのこうしたエンジンは、その実施が状態モデルを含まないことを除いて、典型的な状態モデル・エンジンと同様に機能する。換言すれば、このエンジンは、関連するタスクを実施するための機能性を含むが、実施するタスクがどれであるかを定義するモデルをそれ自体含まない。

こうしたエンジンは、他の状態モデルによって発行された遷移イベントに基づいて、定義された状態モデル内で状態変化が発生するかどうかを評価するアルゴリズムを実行するように実施されてもよい。

こうしたメカニズムは、機器の状態について確定するのに必要とされるデータが利用可能であるが、機器内の異なるソフトウェア・サブシステムを通して散在しているという仮定に基づいて設計することができる。これらのサブシステムの挙動は、状態モデルによって記述される可能性がある。全てのサブシステムは、現在の状態及び状態遷移が発生する時はいつでも遷移イベントを発行しなければならない。メカニズムは、全てのこれらの遷移データを聞き取り、遷移データを、ＳＥＭＩ Ｅ５８規格に準拠するマスター（「機器」）状態モデルに供給する。割り当てられたタスクをメカニズムが実施するために、なぜ、又は、どんなサブシステム状態モデルの遷移が、機器状態モデルの状態遷移を引き起こすかをメカニズムが判定することが望ましい場合がある。

状態モデルは、例えば、
＜トリガー＞＝＜現在の状態＞＜イベント＞＜条件＞＜次の状態＞＜アクション＞
の形態のトリガーのセットを含む。トリガーは、イベントの発生が状態遷移を引き起こすことになる時を定義する。イベントが発生し、現在の状態が適合し、可能性のある条件が満たされると、イベントによって、トリガーが次の状態への遷移を実行し、アクションが実行されることになる。アクションは、現在の状態から次の状態への遷移が発生したことを合図で知らせるイベントを立ち上げることを含む。

図７は、状態遷移の図を示す。この実施例では、イベントＥ１が発生し（入力イベント）、モデルの現在状態は１１００である。これらの２つのトリガー要件を「満たすことによって、次の状態１２００へのモデルの遷移がもたらされ、同様に、アクションＦ１が生じる（出力イベント）。

状態モデルが、デフォルトのスーパー状態を有することが望ましい場合があり、デフォルトのスーパー状態はモデルの作成後のアクティブなスーパー状態であることになる。デフォルトのスーパー状態は、モデルが最初にアクティブ化され、エントリ・トリガーが存在しない時にアクティブになる状態である。スーパー状態は、履歴を有してもよく、履歴は、機器がスーパー状態から遷移してしまう前にアクティブであった最後のサブ状態を記録する。スーパー状態として＜次の状態＞が定義される遷移の場合、履歴を使用して、対応するサブ状態が定義されてもよい。履歴状態は、前にスーパー状態がアクティブであった時の、スーパー状態内でアクティブであったサブ状態である。スーパー状態が、以前に一度もアクティブでなかった場合、デフォルトのサブ状態が履歴状態になる。

状態モデルがアクティブになって初めて、エントリ・トリガーは、どの状態がアクティブになるかを定義する。エントリ・トリガーは、どの状態がアクティブにならなければならないかが前もって知られていない時に使用される（最初の状態が、デフォルト状態と同様に前もって知られていないソフトウェア・コンポーネントの履歴に依存するために、デフォルト状態は存在しない）。エントリ・トリガーは、指定されたイベントが発生する時にのみであるが、＜未知＞から＜任意の未知状態＞への遷移を指定する。モデルがインスタンス化されると、デフォルト状態は、＜未知＞から＜デフォルト状態＞への遷移を指定する。

エグジット・トリガーは、モデルが終了すべき時を定義する。エグジット・トリガーは、＜任意の未知状態＞から＜未知＞への遷移を定義する。

すべてのスーパー状態がデフォルトのサブ状態を有することが望ましい場合がある。デフォルトのサブ状態は、親スーパー状態がアクティブ化され、特定のサブ状態が指定されなかった時にアクティブになる状態である。デフォルトのサブ状態は、以下の状況で使用することができる。

１．このサブ状態が、デフォルトのスーパー状態内のサブ状態である時に、これは、モデルの作成後にアクティブなサブ状態になるであろう。

２．スーパー状態への初めての遷移の場合、履歴サブ状態が知られていない。デフォルトのサブ状態は、履歴サブ状態として使用することができ、アクティブなサブ状態になるであろう。

３．スーパー状態への遷移の場合、デフォルトのサブ状態は、アクティブな状態になるであろう。

図８は、状態モデルにおいて定義することができる可能なトリガー・タイプを示す。これらのトリガーは、サブ状態、スーパー状態、及び履歴状態間の遷移、並びにデフォルトの遷移を指示することができる。

ある到来するイベントの場合、遷移をトリガーするために、同様に、１つ又は複数の条件が満たされなければならない。条件トリガーは、１つ又は複数の条件を指定する、先に定義されるトリガーである。

シングルトン状態モデルは、いずれの時でも１つのインスタンスのみが存在することになる状態モデルである。シングルトン状態モデルの条件は、他のシングルトン状態モデルを参照することができるだけである。非シングルトン状態モデルとシングルトン状態モデルが共に、同じソフトウェア・コンポーネント又はハードウェアに属する場合、非シングルトン状態モデルは、任意のシングルトン状態モデル、及び、同様に、任意の非シングルトン状態モデルを参照することができる。機械モデル（＝シングルトン、ただ１つの機械）は、ウェハ・ステージ（＝シングルトン、ただ１つのウェハ・ステージ）を参照する可能性がある。ウェハ・モデル（＝非シングルトン、ウェハ当たり１つのインスタンス）は、機械モデル（＝シングルトン）、ウェハ・ステージ（＝シングルトン）、同様に、ウェハ・ロケーション・モデル（＝非シングルトン、ウェハ当たり１つのインスタンス）を参照する可能性がある。

条件は、１つ又は複数の現在の状態の指示及び１つ又は複数の中間ロジック表現によって表現することができる。

＜現在（サブ）状態モデルｘ＞＜ロジック＞＜現在（サブ）状態モデルｙ＞．．．

指示されたモデルの現在（サブ）状態が、条件に規定された状態と同じ時に、各状態指示はＴＲＵＥである。中間＜ロジック＞表現（複数可）に従って条件を評価すると、結果として得られる条件は、ＴＲＵＥ又はＦＡＬＳＥになるであろう。各＜ロジック＞表現は、例えば、ＡＮＤ、ＯＲ、及びＮＯＴの組み合わせであってよい。この実施例では、状態モデルの＜現在状態＞は、モデル自体の各＜遷移＞の一部であるが、モデル自体の任意の＜条件＞の一部ではない。

状態モデル記述のカウンタは、
＜カウンタ＞＝＜イベント＞＜条件＞［，＜イベント＞＜条件＞］．．．．
として表現することができる。こうした表現は、＜カウンタ＞の名前でカウンタを指定し、カウンタは、所与の＜イベント＞が発生するか、各＜条件＞が満たされるかのいずれかが起こると増加することになる。

モデルを管理するプロセスは、パワーダウンによって中断されてもよい。したがって、状態及びカウンタ情報が、不揮発性ロケーション（例えば、フラッシュＲＡＭ又は他の不揮発性半導体メモリ、ＭＲＡＭ或いは他の強電性又は磁気ベースのチップメモリ、ハード又は光ディスク）に記憶されることが望ましい場合がある。

メッセージ・センタ：内部状態モデル（モデルはＳＨによって知られていない）について、ＳＨは、メッセージ・センタのように作用し、内部状態モデル（モデルはＳＨによって知られていない）から、入力信号すなわち状態を聞く。内部状態モデルは、最下位の状態のみをＳＨに発行する（すなわち、スーパー状態を発行しない）。

内部状態モデルからの遷移イベントは、システム・モニタ５０によって追跡される状態モデルの状態変化をトリガーしてもよい。遷移イベント又はイベントの任意の発生によって、カウンタをインクリメントすることができる。

システム・モニタ５０は、機器状態モデル（ＥＳＭ）に従って状態累積及びイベント・カウントを実施してもよい。カウンタ及び累算器を有する他のモデル（例えば、ユーザ固有のモデル）は、同時に実行されることができる。

実施されてもよいカウンタ及び累算器は、状態履歴、状態累算器、及びカウンタを含む。状態履歴は、過去に発生した遷移の概要である。各遷移について、ソース及びターゲット状態、遷移、及びタイム・スタンプが記憶される。

状態は、状態が現在状態にあった時間を記録する。サブ状態を有する状態について、累算器は、その直接のサブ状態の累算器の値の和に等しい値を有するように実施されてもよい。この規則は、再帰的に適用されてもよい。ダウンタイム状態がスーパー状態である時、デフォルトのサブ状態に対するダウンタイムを累算することが望ましい場合がある。

カウンタは、特定の対象の遷移の発生数をカウントする。カウンタが、状態モデル内で一意の名前を有することが望ましい場合がある。カウンタが定義されると、この構文に関する静的な検証を行ってもよい。図９は、カウンタ・イベントのフローチャートを示す。

寿命カウンタ（例えば、機械の寿命にわたる発生を追跡するカウンタ）及び状態累算器は、周期に無関係であってよく、連続してカウントし続けるように実施されてもよい。ユーザが、イベント・カウンタを定義し、制御することができることが同様に望ましい場合がある。

本発明の実施例は、他の状態モデルによって発行された遷移イベントに基づいて、定義された状態モデル内で状態変化が起こるかどうかを評価するアルゴリズムを含む、状態モデルを処理するソフトウェアを含む。ソフトウェアが評価しなければならない各状態モデルについて、状態モデル定義が提供される。こうした状態モデル定義は、これらの状態間の遷移が発生する時を定義する、少なくとも状態のセット及び規則のセットを含むべきである。

特定の状態モデル（「ビュー」としても知られる）に従ってエンジンがＲＡＭ時間を確定するようにさせるために、その状態モデルの定義が、最初にファイル内に書き込まれる。例えば、こうした定義は、人が読み取り可能な、スクリプトのような言語を使用して記録されてもよい。こうした状態モデル定義ファイルは、その後、機器にダウンロードされてもよく、機器において、定義ファイルがエンジンによって読み取られることになる。エンジンは、他のソフトウェア部品からの出力（例えば、イベント及び状態）を使用して、読み取り定義に従ってＲＡＭデータを確定してもよい。結果として得られるデータは、機器上で及びホスト上で利用可能にさてもよい。

規則は、人が読み取り可能な定義ファイル内で構成されてもよい。規則は、機器に関する異なるビューを迅速に作成する可能性を与える。例えば、「現在の機器の状態Ｓｅと、サブシステムの状態モデルＭからのイベントＥと、全てのサブシステム状態モデルＳｍ［ｎ］の現在状態のセットが与えられると、機器の状態モデルの遷移Ｔが、新しい状態Ｓｅに対して発生するであろう」又は「現在の複数（サブ）システム状態モデル・ステータスＳｍ［ｎ］の条件下で、ネイティブ（サブ）システム状態モデルＭからのイベントＥが受け取られると、ビュー・モデルが状態Ｓｖ［ｘ］にあるという条件で、ビュー状態モデルにおける遷移Ｔをトリガーする」などの形態で、メカニズムが規則を実行することができる。ユーザは、ユーザの固有のニーズに合った、ユーザ自身の機器状態モデルを構成してもよい。規則はまた、ユーザによって構成可能であってもよく、機器ベンダにとって興味のあるビューの次に、（顧客による）顧客ビューの作成を可能にする。使い易いように、スクリプト及び／又はグラフィカルエディタをこのフレキシブルモデリングのために提供することができる。一実施態様では、メカニズムによって、少なくとも２５の状態モデルが、並列に実行されることが可能であるため、異なるビューは互いを排除しない。

図１２は、本発明の実施例による方法Ｍ１００のためのフローチャートを示す。タスクＴ１１０は、状態変数の値を（例えば、バス２０を通じて）受け取る。タスクＴ１２０は、受け取った値に従って第１状態モデルを更新する。タスクＴ１３０は、更新に基づいて遷移イベントを発行する。タスクＴ１４０は、遷移イベントに従って第２状態モデルを更新する。

図１３は、タスクＴ１３０を有するタスクＴ１２０の一実施例のフローチャートを示す。

本発明の実施例によるメカニズムを使用して、性能解析のため、また、外的に要求された挙動を得るために、ハードコーデッド・ビューを構築する必要をなくしてもよい。これによって、かなり低いソフトウェア開発及びメンテナンス・コストがもたらされる。メカニズムは、（機器を制御するためホストが使用する、外的に要求される挙動をホストに示すために）規格ＳＥＭＩ Ｅ３０、Ｅ４０に関する準拠を得るというタスク、機器の性能を測定するためのＳＥＭＩ Ｅ５８の実装を得るというタスク、及び、ＳＥＭＩ Ｅ１１６性能測定要件を実現するというタスクのような規格関連のタスクのために使用されてもよく、複数のビューに関するビューの使用を明示的に要求する（システム・レベル・ビューは、モジュール・レベル・ビューに基づいて作成される）。メカニズムはまた、定期的に起こる（市場に出すための時間を減らす）これらの規格に関する更新に従う、他の（将来の）ビュー要件を実施する、且つ／又は新しい機器の生成（再使用）に関するビューを作成するのに使用されてもよい。さらに、メカニズムは、システム品質を向上する場合がある、（サブ）システム状態モデル検証のための、モジュール又はシステムのアルファ試験及びベータ試験中に使用されてもよい。

メカニズムは、サブシステムのモジュール性及び試験性を改善し、開発コスト及びメンテナンス・コスト及び市場へ出すための時間を減らす可能性がある。

グローバル・レベルでは、主ソフトウェア機能は、カウンティング、累算、及びレポーティングを含む。ＡＲＡＭＳ状態モデルの追跡は、以下のオペレーション、すなわち、ＡＲＡＭＳ状態モデルの（サブ）状態で費やされる時間を累算すること、ＡＲＡＭＳ状態モデルにおける固有のイベントの発生をカウントすること（寿命カウンタ値）、ＡＲＡＭＳ状態モデルからホスト及びユーザ・インタフェースへ、累算した時間及びカウンタ値をレポートすること、及び／又は、Ｉｎｓｉｇｈｔで使用するためにＡＤＣツールに信頼性報告書をレポートすることを含んでもよい。顧客状態モデルを追跡することは、顧客状態モデルの（サブ）状態で費やされる時間を累算すること、エンド・ユーザによって指定されるイベントの発生をカウントすること、及び／又は、顧客状態モデルからの累算した時間及びユーザが指定したカウンタ値をレポートすることなどのオペレーションを含んでもよい。

１分の分解能を有する状態変数レポーティング（例えば、システム・モニタへ）のために、（サブ）状態期間カウンタを設けることが望ましい場合がある。

ユーザが定義した各モデルについて、現在状態及びサブ状態が、状態変数としてシステム・モニタに利用可能であることが望ましい場合がある。

システムが、少なくとも２５の独立したモデル及び少なくとも４００のカウンタを一度に全て実行させることができることが望ましい場合がある。

ソフトウェアが、各顧客状態モデルが少なくとも１つの状態を有すること、及び／又は、顧客状態モデル内の全ての実体（状態、サブ状態、遷移イベント）が一意の名前を有することを調べることが望ましい場合がある。

ソフトウェアが、顧客状態モデル内の各状態が、少なくとも１つの定義されたエントリと１つの定義されたエグジット、少なくとも１つのサブ状態、正確に１つのデフォルト・サブ状態、及び正確に１つの定義されたダウンタイム状態又はサブ状態を有することを調べることが望ましい場合がある。

ソフトウェアが、顧客状態モデル内の各トリガーが、内部状態モデルからの有効なイベント、状態、及びサブ状態に基づくこと、及び、こうした各トリガーが、顧客状態モデル内の定義された状態又はサブ状態の間の遷移を定義することを調べることが望ましい場合がある。

ソフトウェアが、顧客状態モデル内の遷移が明白であること、すなわち、（サブ）状態からの全ての遷移が、異なるイベントに基づくか、又は、互いに排他的な条件を課されていることを調べることが望ましい場合がある。

このアルゴリズムを使用して、ＡＲＡＭＳ状態モデル及び顧客状態モデルが追跡される。しかし、アルゴリズムは、一定の他のタスクについて再使用される可能性がある。２つのこうした機会が以下で述べられる。

本発明のさらなる実施例では、システム・モニタ５０を使用して、導出された状態モデルが作成される、且つ／又は、追跡されてもよい。導出された状態モデルは、内部状態モデルから導出される状態モデルである。導出された状態モデルは、導出された状態モデルがそこから導出される状態モデルの状態のサブセットを含み、したがって、クライアントが興味を持つ場合がある状態及び遷移のみをフィルタリング出力するのに使用される可能性がある。

導出された状態モデルからの遷移イベント及び状態が、内部状態モデルからのものと同様に処理されることが望ましい場合がある。例えば、こうしたイベント及び状態が、ＡＲＡＭＳモデルにおける状態変化をトリガーすることが望ましい場合がある。

内部状態モデルから導出される状態モデルの状態を計算するために、一般的アルゴリズムが、他のコンポーネントによって再利用される可能性がある。アルゴリズムを再使用することは、ロット生産［ｒｅｆ．１．４］に関連する全ての内部状態モデルの管理を簡略化する。これらは、プロセス、ロット、オペレーション、及びシステム状態モデルである。

理論的解釈：ロット生産状態モデルは、深く入れ子状になった状態の構造からなる。モデルを実施するソフトウェアは、最下位レベル（サブ状態を全く有さない状態）で動作する。状態モデルは、「グレー」状態（［ｒｅｆ．１．４］の図のグレーで色付けされた状態）間の遷移のみをホストにレポートしなければならない。結果として、ソフトウェアは、ホワイト状態とグレー状態の間のマッピング及びこれらの間の遷移を作成する必要がある。

このマッピングは、各状態モデルを２つのモデル、すなわち、最下位レベルの状態を含むだけのモデル及びグレー状態を含むモデルに分割することによって、ＳＨによって作られる可能性がある。そのため、第２モデルは、第１モデルに依存するだけである。「ホワイト」モデルにおけるある遷移に関して、「グレー」モデルにおける遷移がトリガーされ、他の遷移に関しては、トリガーされないであろう。

図１０の（架空の）状態モデルでは、グレーとホワイトの両方の状態が描かれる。矢印で接続される全ての状態間で、且つ、矢印の方向にだけ、遷移が発生することができる。ホストは、グレー状態間の遷移に興味があるだけである。これらは、上側ケースに表示された矢印である。標識「Ｊ」は、ホストの観点から２回現れ、これは同じ遷移であることに留意されたい。

この状態モデルは、図１１において２つの状態モデルに分割される可能性がある。左側の状態モデルは、ここで、所有コンポーネントによって実施することができる。右側の状態モデルは、ＳＨにおいて実施されるアルゴリズムを使用して導出される可能性がある。必要とされる全ては、右側のモデルについての状態モデル定義である。この定義は、「モデルが状態’１’にあり、遷移イベント’ｋ’が、状態モデル’ホワイト’によって発行される場合、状態’２’へ変化し、遷移イベント’Ｋ’を発行する」などの規則を含まなければならない。こうした規則のセットは、まさしく、状態モデルがＳＨにおいて定義される方法であるため、グレー・モデルは、ＡＲＡＭＳ状態モデルと共に追跡される、まさに別の導出された状態モデルとして認識されるであろう。

状態モデル評価アルゴリズムのこうした再使用を可能にするために、一部の付加的な要件、すなわち、システムが導出された状態モデルを追跡することができること、導出された状態モデルがユーザによって編集されることができないこと、及び、導出された状態モデルからの遷移イベント及び状態が、内部状態モデルからの遷移イベント及び状態と同じ方法で処理されることを課すことが望ましい場合がある。（すなわち、それらはＡＲＡＭＳ状態モデル及び顧客状態モデル又は他の導出されたモデルの状態変化をトリガーすることができる。）

導出された状態モデルは、ＡＲＡＭＳ状態モデル及び顧客状態モデルからの状態又は遷移に依存してはならない。これは、導出された状態モデルのインスタンス化の前に調べられなければならない。

非シングルトン・タイプ状態モデルについて、識別可能な導出された状態モデル・インスタンスを有することが可能でなければならない。

導出された状態モデルにおける循環的関係を禁止することが望ましい場合がある。定義によれば、状態モデルの１つ又は複数のトリガーが、別の状態モデルからの状態及び／又はイベントに依存し、別の状態モデルの１つ又は複数のトリガーが、第１状態モデルの状態及び／又はイベントに依存する場合に、状態モデルにおける循環的関係が存在する。循環的関係は、たとえ、依存が間接的であっても存在する（すなわち、第３状態モデルを通して）。循環的依存に関する１つの可能性のある問題は、循環的依存が、状態モデル上のイベントの作用が処理の順序に依存する状況を作る可能性があることである。したがって、状態モデル・レベルでのインスタンス化の前に動的関係を調べることが望ましい場合がある。循環的関係に関する制限とは別に、導出された状態モデルが、他の導出された状態モデルに依存することが可能であってもよい。

ＳＥＣＳホストは、いわゆる、収集イベントの形態で、特定のサブシステム状態遷移を通知されなければならない。導出された状態モデルは、レポートされなければならない遷移を含むだけである状態モデルである。メカニズムを使用して、収集イベントが関連する遷移が発生する時を確定するために、導出された状態は、サブシステム状態遷移を使用する。

図１４は、本発明の実施例による方法Ｍ２００のためのフローチャートを示す。この方法では、タスクＴ２１０は、第１状態モデルに基づいて第２状態モデルを導出する。

本発明のさらなる実施例では、システム・モニタ５０を使用して、検証状態モデルが追跡されてもよい。内部状態モデルは、その状態遷移を発行する。内部状態モデルについて状態モデル定義が利用可能である場合、一般的アルゴリズムは、内部状態モデルのために「シャドウ状態モデル」を評価し、両者が同期したままであるかどうかを調べる可能性がある。

さらなる実施例による状態モデル・エンジンはまた、いわゆる、検証状態モデルを使用することによって、機器の他のソフトウェア部品の実施（挙動）を検証することが可能である。

メカニズムは、検証状態モデルの作成を可能にする。ビュー状態モデルは、予想される機器のネイティブ（サブ）システム状態モデルと同様に定義される。これらの、いわゆる、検証状態モデルは、実際の物理的機器の（サブ）システム状態挙動と並列に実行されることができる。違法な遷移（例えば、ビュー・モデルにおいて定義されない遷移）は、容易に追跡され、実際に実施する時の問題を正すのに（例えば、デッドロックを解決するのに）使用される可能性がある。

サブシステム状態モデルについての状態モデル定義を使用して、これらの状態モデルの状態遷移は、検証状態モデルによって、正確さを求めて実行時に検証される可能性がある。これは、信頼性監視機能の試験性を向上させる。

内部状態モデルは、ＡＲＡＭＳ状態モデル、顧客状態モデル、又は導出された状態モデルのための入力である場合があるため、その状態を発行しなければならない。結果として、これらの状態モデルを評価するプロセスは、各内部状態モデルがそこを通って移動する状態経路（及び、状態間の遷移）についての知識を有することになる。内部状態モデルの状態モデル定義は、このプロセスに知られていない。しかし、プロセスは、定義を知る場合、経路が、正当な遷移（すなわち、状態モデル定義において定義される遷移）を含むかどうかを検証する可能性がある。状態遷移の動的検証が可能であるために、内部状態モデルの定義は、状態評価プロセスに利用可能にされなければならない。

こうした動的検証は、実施される状態モデルがその仕様に従って振舞うことを調べるために、開発及び統合中に使用される可能性がある。顧客サイトにおいてこの動的検証が続く。

例えば、図１６に示す状態モデルを考える。状態モデルが最初に状態１にあり、この事実が発行されていると仮定する。そのため、状態モデル定義を使用して、発生する可能性がある唯一の有効な状態変化は、’ａ’から状態’２’への遷移であることがわかる。この状態モデルについて、任意の他の状態／遷移の組み合わせが発行される場合、それは、エラーであることになる。

動的状態モデル検証についての挙動は、内部状態モデルが違法な遷移を実施する時はいつでもエラーがログされることである。レポートされるデータは、検出された違法な遷移のために不正確である場合があるため、これらのエラーもまた、レポーティングに含まれなければならない。検証メカニズムは検証が失敗した理由がわからないため、こうした状況から回復することは実行時には可能でない。

以下のもの、すなわち、違法な遷移（その間に遷移が定義されていないソースからターゲット状態への遷移）、間違った遷移（発行された遷移は、状態モデル内で定義されていないか、又は、ソースとターゲット状態との間の遷移ではない）及び、違法な状態（ターゲット状態が、状態モデル定義内で定義されていないか、又は、ターゲット状態が知られていないターゲット状態への遷移）のうちの１つ又は複数を追跡するために、検証モデルが適用されてもよい。

各内部状態モデルは、動的検証のために、状態モデル定義ファイルを供給すべきである。内部状態モデルを所有するコンポーネントは、動的検証のために、状態モデル定義を供給しなければならない。動的検証は、状態モデル定義が供給される時で、また、その時だけに実施される。

検証は、（Ａ）状態モデル・インスタンスが作成され、（Ｂ）検証状態モデル定義ファイルが、状態モデル・クラスについて利用可能である時の、状態モデルのインスタンスについて開始される。検証は、インスタンスが破壊される時の、状態モデルのインスタンスについて停止する。

ソフトウェアは、全ての検出された違法な遷移、全ての検出された間違った遷移、及び、全ての検出された違法な状態についての警告をログするであろう。全てのログされた検証エラーは、機器状態履歴報告に含まれる。エラー・ログにおける発行された警告は、モデル及び遷移、したがって、＜モデル＞＜現在状態＞＜遷移＞＜次の状態＞の情報を含まなければならない。ロギング汚染を防止するために、インスタンス当たり最大２０の警告が、ログされるのを許可される。それ以上の警告が発生すると、そのインスタンスの動的検証が、ディセーブルされなければならず、動的検証がディセーブルされる１つ又は複数の警告がログされなければならない。

検証状態モデルが、そのソースに従うよう強制されることが望ましい場合がある。到来する遷移がエラーを有する時、例えば、検証状態モデルが、遷移に定義される次の状態にジャンプすることが望ましい場合がある。こうした行動を強制することは、検証状態モデルが、「マスター」の間違った遷移の後に同期はずれになる条件をなくす（例えば、警告を発行する連続ループを防止する）。

図１５は、本発明の実施例による方法Ｍ３００のためのフローチャートを示す。この方法では、タスクＴ１４５は、タスクＴ１３０によって発行された遷移イベントに従って検証状態モデルを更新する。タスクＴ１５０は、更新された検証状態モデルに基づいて、第１状態モデルによって違法な遷移を指示する。

本明細書において、ＩＣの製造におけるリソグラフィ装置の使用が特に参照されるが、本明細書で述べるリソグラフィ装置が、集積化光システム、磁気ドメイン・メモリ用の誘導及び検出パターン、フラットパネル・ディスプレイ、液晶ディスプレイ（ＬＣＤ）、薄膜磁気ヘッドなどの製造のような他の用途を有してもよいことが理解されるべきである。こうした代替の用途において、本明細書の「ウェハ」又は「ダイ」という用語のいずれの使用も、それぞれ、「基板」又は「標的部分」と言う、より一般的な用語と同意語として考えられてもよいことを、当業者は理解するであろう。本明細書で言及される基板は、露光の前か、又は、後に、例えば、トラック（通常、レジスト層を基板に塗布し、露光したレジストを現像するツール）、測定ツール、及び／又は、検査ツールにおいて処理されてもよい。適用可能である場合、本明細書の開示は、こうした、又は、他の基板処理ツールに適用されてもよい。さらに、基板は、例えば、多層ＩＣを作成するために、２回以上処理されてもよく、それによって、本明細書で使用される基板という用語もまた、複数の処理済み層を既に含む基板のことを指してもよい。

前文で、光リソグラフィにおける本発明の実施例の使用が特に参照されたが、本発明は、他の用途、例えば、インプリント・リソグラフィにおいて使用され、状況が許す場合、光リソグラフィに限定されなくてもよいことが理解されるであろう。インプリント・リソグラフィでは、パターニング・デバイスのトポグラフィが、基板上に作成されるパターンを画定する。パターニング・デバイスのトポグラフィは、基板に供給されるレジスト層内にプレス加工され、その後、レジストは、電磁放射、熱、圧力、又は、その組み合わせを適用することによって硬化する。レジストが硬化した後、パターニング・デバイスが、レジストから除去され、レジスト内にパターンが残る。

本明細書で使用される「放射」及び「ビーム」という用語は、紫外（ＵＶ）放射（例えば、３６５、３５５、２４８、１９３、１５７、又は１２６ｎｍの波長を有する）、及び、極紫外（ＥＵＶ）放射（例えば、５〜２０ｎｍの範囲の波長を有する）、並びに、イオンビーム又は電子ビームなどの粒子ビームを含む全てのタイプの電磁放射を包含する。

「レンズ」という用語は、状況が許す場合、屈折、反射、磁気、電磁気、及び静電光学部品を含む、種々のタイプの光学部品の任意の１つ又は組み合わせを指してもよい。

述べた実施例の先の提示は、当業者が本発明を作成するか、又は、使用することを可能にするために提供される。これらの実施例に対して、種々の変更が可能であり、本明細書で提示した一般的な原理は、同様に、他の実施例に適用されてもよい。例えば、本発明は、部分的に、又は、全体が、実配線され回路として、特定用途向け集積回路内に作製される回路構成として、或いは、機械読み取り可能コードとして、不揮発性記憶装置にロードされるファームウェア・プログラム又はデータ記憶媒体から、又は、記憶媒体へロードされるソフトウェア・プログラムとして実施されてもよく、こうしたコードは、マイクロプロセッサ又は他のデジタル信号処理ユニットなどのロジック要素のアレイによって実行可能な命令である。

本発明の実施例は、先に開示した方法を記述する機械読み取り可能命令の１つ又は複数のシーケンスを含むコンピュータ・プログラム、或いは、こうしたコンピュータ・プログラムを中に記憶するデータ記憶媒体（例えば、半導体メモリ、磁気又は光ディスク）を含む。そのため、本発明は、先に示した実施例に限定されることを意図されるのではなく、本明細書で任意の方法で開示される原理及び新規な特徴と整合する最も広い範囲に一致することが意図される。

本発明の実施例によるシステムで使用することができるリソグラフィ装置を示す図である。 ＳＥＭＩ Ｅ１０に定義される６つの基本機器状態を示す表である。 サブ状態のレベルに分割された基本状態の実施例を示す図である。 ＳＥＭＩ Ｅ１０の基本状態に基づいて、全時間を６つの基本ブロックに分割する図である。 ＳＥＭＩ Ｅ５８のデフォルト遷移規則を示す表である。 本発明の実施例によるシステム５０のブロック図である。 状態遷移図である。 エントリ・トリガーの図である。 カウンタ・イベントのフローチャートである。 状態間の２つのレベルの相互作用を示す状態モデルの図である。 図１０のモデルによる２つの状態モデルを示す図である。 本発明の実施例による、方法Ｍ１００のフローチャートである。 タスクＴ１３０を有するタスクＴ１２０の実施態様のフローチャートである。 本発明の実施例による、方法Ｍ２００のフローチャートである。 本発明の実施例による、方法Ｍ３００のフローチャートである。 本発明による状態モデルを示す図である。

符号の説明

ＰＢ 放射ビーム
ＩＬ 照射システム
ＭＡ パターニング・デバイス
ＭＴ マスク・テーブル
ＰＬ 投射システム
ＰＭ 第１位置決めデバイス
ＷＴ 基板テーブル
Ｗ 基板
ＰＷ 第２位置決めデバイス
ＳＯ 放射源
ＢＤ ビーム送出システム
ＡＭ 調整デバイス
ＣＯ 積分器ＩＮ及びコンデンサ
Ｃ 標的部分
ＩＦ 位置センサ
Ｍ１、Ｍ２ マスク・アライメント・マーク
Ｐ１、Ｐ２ 基板アライメント・マーク

Claims (19)

1. リソグラフィ処理機械を制御する方法であって、
   トリガー・イベントの発生に基づいて、前記機械の第１状態モデルの遷移を記録すること、及び、
   前記遷移に対応する遷移イベントに基づいて、前記機械の第２状態モデルを更新することを含むリソグラフィ処理機械を制御する方法。
2. 前記第１状態モデルは規格によって指定される請求項１に記載のリソグラフィ処理機械を制御する方法。
3. 前記規格はＳＥＭＩ規格を含む請求項２に記載のリソグラフィ処理機械を制御する方法。
4. 前記ＳＥＭＩ規格は、ＳＥＭＩ Ｅ１０、Ｅ３０、Ｅ４０、又はＳＥＭＩ Ｅ５８を含む請求項３に記載のリソグラフィ処理機械を制御する方法。
5. 前記トリガー・イベントは状態変数の変化に基づく請求項１に記載のリソグラフィ処理機械を制御する方法。
6. 前記第１状態モデルから前記第２状態モデルを導出することを含む請求項１に記載のリソグラフィ処理機械を制御する方法。
7. 前記第１状態モデル及び前記第２状態モデルは、サブ状態、スーパー状態、及び履歴状態を含む請求項１に記載のリソグラフィ処理機械を制御する方法。
8. リソグラフィ処理機械を制御する方法を実施するために、機械によって実行可能な機械実行可能命令を有するコンピュータ製品であって、前記方法は、
   トリガー・イベントの発生に基づいて、前記機械の第１状態モデルの遷移を記録すること、及び、
   前記遷移に対応する遷移イベントに基づいて、前記機械の第２状態モデルを更新することを含むコンピュータ製品。
9. 前記第１状態モデルは規格によって指定される請求項８に記載のコンピュータ製品。
10. 前記規格はＳＥＭＩ規格を含む請求項９に記載のコンピュータ製品。
11. 前記ＳＥＭＩ規格は、ＳＥＭＩ Ｅ１０、Ｅ３０、Ｅ４０、又はＳＥＭＩ Ｅ５８を含む請求項１０に記載のコンピュータ製品。
12. 前記トリガー・イベントは状態変数の変化に基づく請求項８に記載のコンピュータ製品。
13. 前記第１状態モデルから前記第２状態モデルを導出することを含む請求項９に記載のコンピュータ製品。
14. 前記第１状態モデル及び前記第２状態モデルは、サブ状態、スーパー状態、及び履歴状態を含む請求項９に記載のコンピュータ製品。
15. リソグラフィ処理機械を制御するように構成されたシステム・モニタであって、
    トリガー・イベントの発生に基づいて、前記機械の第１状態モデルの遷移を記録し、前記遷移に対応する遷移イベントに基づいて、前記機械の第２状態モデルを更新するように構成されたプロセッサを備えるシステム・モニタ。
16. 前記処理機械の信頼性、可用性、及び保全性に関連するデータを動的に確定するように構成された請求項１５に記載のシステム・モニタ。
17. 前記プロセッサは、人が読み取り可能な言語で定義された状態モデルを記録し、読み取るように構成される請求項１５に記載のシステム・モニタ。
18. 前記第１状態モデルにおいて経過した時間を記録するように構成された累算器をさらに備える請求項１５に記載のシステム・モニタ。
19. 前記発生をカウントするように構成されたカウンタをさらに備える請求項１５に記載のシステム・モニタ。

Images