JP4694843B2 - 半導体製作プロセスの監視とコンロトールのための装置 - Google Patents

Description

本発明は、半導体プロセスシステム、特に、アドバンストプロセスコントロール（ＡＰＣ）を用いる半導体プロセスシステムに関する。

本出願は、参照によりその全体の内容がここに組み入れられる、２００２年９月３０日に出願された米国仮出願番号６０／４１４，４２５に基づき、同出願の利益を得ている。

本出願は、出願中の、２００２年３月２９日に出願され、「状態とコントロール装置ととの相互作用のための方法」と題された、米国仮出願番号６０／３６８，１６２と、２００２年４月２３日に出願され、「単純化されたシステム設定のための方法と装置」と題された、米国仮出願番号６０／３７４，４８６と、２００２年３月２９日に出願され、「ツールパフォーマンスを監視するための方法と装置」と題された、米国仮出願番号６０／３８３，６１９と、２００２年７月３日に出願され、「動的なセンサ設定とランタイム実行の方法」と題された、米国仮出願番号６０／３９３，０９１と、２００２年７月３日に出願され、「自動的なセンサ設置のための方法と装置」と題された米国仮出願番号６０／３９３，１０４とに関連している。これらの出願の各々は、ここで参照によりその全体において組み入れられる。

コンピュータは、製作プロセスをコントロールし、監視し、初期化するために、一般に用いられている。コンピュータは、内向するウエハの流れと重要なプロセスのステップとプロセスの維持可能性とから半導体製作プラントの複雑さを考慮に入れると、これらの操作に理想的である。様々な入力と出力（Ｉ／Ｏ）の装置が、プロセスのフロとウエハの状態とメインテナンススケジュールとをコントロールし監視するために用いられている。様々なツールが、半導体製作プラントにおいて、エッチングのような重要な操作から、バッチ式プロセスと検査までのこれらの複雑なステップを完了するために、存在している。ほとんどのツールの設置は、インストールソフトウェアを有するコントロールコンピュータのグラフィカルユーザインターフェース（ＧＵＩ）の一部であるディスプレイスクリーンを用いて達成される。半導体プロセスツールの設置は、時間を要する手続きである。

半導体プロセス設備は、定期的な監視を必要とする。プロセスコンディションは、望ましくない結果を与える重要なプロセスパラメータのわずかな変化と共に、時間にわたって、変化する。小さな変化は、エッチングガスの組成もしくは圧力かプロセスチャンバかウエハ温度かにおいて容易に起こることができる。

多くの場合、プロセスの特性の悪化を反映するプロセスデータの変化は、単に表示されているプロセスデータを参照することによっては、検出されることができない。プロセスの異常性と特性の悪化の初期段階を検出することは、難しい。アドバンストプロセスコントロールにより与えられる予測とパターン認識とが、しばしば必要である。

設備のコントロールは、しばしば、様々なコントローラを有する多数の様々なコントロールシステムにより実行される。コントロールシステムの中には、タッチスクリーンのような人と機械のインターフェースを持つことができるものがある、一方で、他のコントロールシステムは、温度のような一変数を収集し表示するだけのことができる。監視システムは、プロセスコントロールシステムのために表になったデータを収集できなければいけない。前記監視システムのデータ収集は、単一変数のデータと多変数のデータと、データの解析と表示とを扱えなければいけず、収集するべきプロセス変数を選ぶ能力がなければいけない。プロセスの様々なコンディションは、各々のプロセスチャンバの中に与えられた様々なセンサによって監視され、監視されたコンディションのデータは、転送され、コントロールコンピュータに蓄積されている。プロセスのデータが自動的に表示され検出されるなら、大量生産ラインの最適なプロセス条件は、設定されることができ、統計的プロセスコントロール（ＳＰＣ）チャートを通してコントロールされることができる。設備の非能率的な監視は、全体として操作コストを増加させる設備の中断時間を導く結果となることができる。

したがって、半導体プロセス環境におけるプロセスツールをコントロールするためのアドバンストプロセスコントロール（ＡＰＣ）システムを与えることが、本発明の目的である。半導体プロセス環境では、前記ＡＰＣシステムは、ＡＰＣに関連した複数のアプリケーションを与えるＡＰＣサーバと、このＡＰＣサーバに結合されたインターフェースサーバ（ＩＳ）と、前記ＩＳとＡＰＣサーバとに結合されたデータベースと、前記ＡＰＣサーバに結合されたＧＵＩ構成成分とを有し、前記ＩＳが、プロセスツールに結合するための手段と、このプロセスツールに結合された複数のプロセスモジュールに結合するための手段とを有する。

加えて、半導体プロセス環境におけるプロセスツールをコントロールするためのアドバンストプロセスコントロール（ＡＰＣ）システムを用いるための方法を与えることは、本発明の目的である。その方法は、複数のＡＰＣに関連するアプリケーションを与えるＡＰＣサーバを与えることと、このＡＰＣサーバに結合されたインターフェースサーバ（ＩＳ）を与えることと、前記ＩＳとＡＰＣサーバとに結合されたデータベースを与えることと、前記ＡＰＣサーバに結合されたＧＵＩ構成成分を与えることとを有し、前記ＩＳは、プロセスツールに結合するための手段と、前記プロセスツールに結合された複数のプロセスモジュールに結合するための手段とを有する。

組み入れられ記述の一部を構成する添付されている図面は、すぐに本発明の好ましい実施の形態を示し、上記の一般的な記述と下記の好ましい実施の形態の詳細な記述と共に、本発明の原理を説明するのに役にたっている。より完全な本発明の評価とそれに付随する有利なことの多くは、特に、添付されている図面と共に考えられた時に、以下の詳細な説明を参照して直ちに明らかとなる。

図１は、本発明の実施の一形態による半導体製作環境におけるＡＰＣシステムの例示的なブロックダイヤグラムを示している。示された実施の形態において、半導体製作環境１００は、少なくとも１つの半導体プロセスツール１１０と、多数のプロセスモジュール１２０、ＰＭ１からＰＭ４までと、前記ツールと前記モジュールとプロセスとを監視するための多数のセンサ１３０と、センサのインターフェース１４０と、ＡＰＣシステム１４５とを有する。ＡＰＣシステム１４５は、インターフェースサーバ（ＩＳ）１５０と、ＡＰＣサーバ１６０と、クライアントワークステーション１７０と、ＧＵＩ構成成分１８０と、データベース１９０とを有することができる。一実施の形態では、ＩＳ１５０は、「ハブ」として見られることができるリアルタイムメモリデータベースを有することができる。

ＡＰＣシステム１４５は、プロセスツールとプロセスモジュールとセンサとの少なくとも１つをコントロールするために、ツールレベル（ＴＬ）コントローラ（図示されていない）を有することができる。

前記図示された実施の形態では、１つのツール１１０が、４つのプロセスモジュール１２０と共に示されているが、これは、本発明に必要とはされていない。前記ＡＰＣシステム１４５は、１つかそれより多いプロセスモジュールを有するクラスターツールを有する多くのプロセスツールのインターフェースとなることができ、このＡＰＣシステム１４５は、１つかそれ以上のプロセスモジュールを有するクラスターツールを有する多くのプロセスツールを形作り監視するために用いられることができる。例えば、前記ツールとそれらの関連するプロセスモジュールは、エッチングと、フィーチャトリミングと、蒸着と、拡散と、クリーニングと、測定と、ポリッシングと、デベロッピングと、トランスファーと、ストレージと、ローディングと、アンローディングと、アライニングと、温度コントロールと、リソグラフィと、インテグレイティドメトロロジ（integrated metrology）（ＩＭ）と、光学データプロファイリング (ＯＤＰ)と、粒子検出と、アーク抑制（arc suppression）と他の半導体製作プロセスとを実行するために用いられることができる。

ＩＭ要素は、プロセスツールに結合したモジュール（インテグレイティドメトロロジモジュール；ＩＭＭ）として配置されることができる。例えば、ＩＭＭは、ウエハのフィーチャの形を測定して解析するＯＤＰシステム（Ｔｉｍｂｒｅ Ｉｎｃ．より）であることができる。

一実施の形態では、前記プロセスツール１１０は、ツールエージェント（図示されていない）を有することができ、ツールエージェントは、ツール１１０の上で走るソフトウェアプロセスであり、ツールエージェントは、イベント情報と、コンテキスト情報と、前記ツールプロセスとデータ取得を同期化するために用いられるスタートストップタイミングコマンドを与えることができる。また、ＡＰＣシステム１４５は、前記ツールエージェントへの接続を与えるために用いられることができるソフトウェアプロセスであることができるエージェントクライアント（図示されていない）を有することができる。例えば、ＡＰＣシステム１４５は、インターネットもしくはイントラネット接続でプロセスツール１１０に接続されることができる。

例えば、エージェントクライアントは、イベントとそれらに関連したメッセージをツールエージェントから受け取り、それらのメッセージを前記ＡＰＣシステムを通してつたえるために用いられることができる。前記クライアントソフトウェアは、コミュニケーションクラスとドライバを有することができる。前記エージェントクライアントのコミュニケーションクラスは、動的にロードできるモジュール(ＤＬＬ)として実行されるリユーザブルなクラスとして設計されることができる。前記ツールエージェントからのメッセージをパーシング処理し、それらのメッセージを要素に分解するために用いられるメッセージクラスが存在することもできる。エージェントのメッセージクラスは、パラメータとして前記ツールエージェントから受け取られたストリングによりインスタンシェーションされることができる。インスタンシェーションの時に、前記ストリングは、パーシング処理され、全てのクラスの属性は、このストリングからのデータにより満たされる。前記エージェントクライアントのコミュニケーションクラスは、前記ツールエージェントとＢＳＤソケットにより通信し、それは、以下の方法を有する。

ａ．スタートエージェント：前記ツールエージェントとの通信を確立し、エージェントにスタートメッセージを送る方法。スタートを承認されたメッセージが、
このエージェントから受け取られると、この接続は閉じられ、イベントレシーブスレッドが作られる。前記エージェントとの初期接続が確立されると、前記ツールを発見したローカルインターフェースは、記憶される。

ｂ．イベントレシーブスレッド：これは、前記エージェントと「イベントリッスン（event listen）」接続を確立する。一度この接続が確立されると、このスレッドは、前記エージェントからのメッセージを際限なく待つ。メッセージが受け取られると、新しいエージェントのメッセージオブジェクトがインスタンシェーションされ、メッセージキューに置かれる。このスレッドは、それから「メッセージを待っている」状態に戻る。

ｃ．ゲットネクストメッセージ：次のオブジェクトを前記メッセージキューから得てこれをコーラ（caller）に渡して返す方法。

ｄ．ストップエージェント：前記ツールエージェントにストップシグナルを送る方法。このツールエージェントが、ストップシグナルを受け取ると、前記ツールは、前記イベントレシーブスレッドとの接続を閉じることができる。このイベントレシーブスレッドが、接続が閉じられたことを感知すると、イベントレシーブスレッドは消去される。

一実施の形態では、プロセスツール１１０は、ソケットを用いるＩＳ１５０と通信する。例えば、インターフェースは、ＴＣＰ／ＩＰソケット通信を用いて実行される。あらゆる通信の前に、ソケットは、確立されている。それからメッセージが、ストリングとして送られる。このメッセージが送られた後、このソケットは、無効にされる。

この代わりに、インターフェースは、ディストリビューティドメッセージハブ（ＤＭＨ）クライアントクラスのような特殊なクラスを用いるＣかＣ＋＋のコードもしくはＣかＣ＋＋のプロセスで拡張されたＴＣＬプロセスとして構造化されることができる。この場合は、プロセスかツールのイベントを上記ソケット接続を通して集める論理は、ＩＳ１５０のテーブルにこのイベントとこれらのコンテキストデータを挿入するために修正されることができる。

前記ツールエージェントは、ＡＰＣシステムにイベントとコンテキストの情報を与えるために、メッセージを送ることができる。例えば、このツールエージェントは、ロットのスタートとストップのメッセージと、バッチのスタートとストップのメッセージと、ウエハのスタートとストップのメッセージと、レシピのスタートとストップのメッセージと、プロセスのスタートとストップのメッセージとを送ることができる。この上、前記ツールエージェントは、セットポイントデータを送り、並びに／もしくは受け取り、メインテナンスカウンタデータを送る、ならびに／もしくは受け取るために用いられることができる。

一実施の形態では、共通のツールエージェントが、複数のプロセスツール上にインストールされることができる。共通のツールエージェントは、インターフェースのメッセージのフォーマットを共通にすることを可能にすることができる。例えば、コミュニケーションメッセージのフォーマットは、メッセージＩＤから終了部分（terminator）のメッセージの長さであるメッセージ長と、コマンドとイベントの特定に用いられるメッセージＩＤと、コマンドもしくはイベントの内容を含んでいるメッセージ本体との３つの部分を有する。この上、このメッセージは、アスキーコードを用いることができ、その長さは可変である。また、各々のメッセージは、コントロールコードにより分けられることができ、終了部分が用いられることができる。代わりの実施の形態では、デュアルエージェントがツール上に確立されることができる。

プロセスツールが、内部センサを有する時、このプロセスツールは、センサと考えられることができ、このデータは、前記ＡＰＣシステム１４５に送られることができる。データファイルは、このデータを送るために用いられることができる。例えば、プロセスツールの中には、作られたときにツールの中に圧縮されているトレースファイルを作ることができるものがある。圧縮された、並びに／もしくは圧縮されていないファイルが、送られることができる。前記プロセスツールの中にトレースファイルが作られる時、トレースデータは、終点検出の（ＥＰＤ）データを含むことも含まないこともできる。このトレースデータは、プロセスについての重要な情報を与える。このトレースデータは、更新されることができ、ウエハのプロセスが完了したときに送られることができる。トレースファイルは、各々のプロセスのための固有のディレクトリに送られる。一実施の形態では、ツールのトレースデータとメインテナンスデータとＥＰＤのデータとは、プロセスツール１１０から得られることができる。

図１では、４つのプロセスモジュールが示されているが、このことは、本発明のためには必要とされていない。半導体のプロセスシステムは、プロセスツールと関連したあらゆる数のプロセスモジュールを有するあらゆる数のプロセスツールと独立したプロセスモジュールを有することができる。前記ＡＰＣシステム１４５（１つかそれより多くのＴＬコントローラを有する）は、プロセスツールと関連したあらゆる数のプロセスモジュールを有するあらゆる数のプロセスツールと独立したプロセスモジュールを形作り、コントロールし、監視するために用いられることができる。このＡＰＣシステムは、プロセスツールとプロセスモジュールとセンサとを伴うプロセスからのデータを集め、与え、処理し、記憶し、表示することができる。

プロセスモジュールは、ＩＤとモジュールタイプとガスパラメータとメインテナンスカウンタとのようなデータを用いて特定されることができ、このデータは、データベースにセーブされることができる。新しいプロセスモジュールが形作られると、ＧＵＩ構成成分１８０におけるモジュール設定パネルもしくはスクリーンをもちいて、このタイプのデータが、与えられることができる。例えば、前記ＡＰＣシステムは、Ｔｏｋｙｏ Ｅｌｅｃｔｒｏｎ Ｌｉｍｉｔｅｄからの以下のツールタイプをサポートすることができる。それは、Ｕｎｉｔｙに関連したプロセスモジュールと、Ｔｒｉａｓに関連したプロセスモジュールと、Ｔｅｌｉｕｓに関連したプロセスモジュールと、ＯＥＳに関連したモジュールと、ＯＤＰに関連したモジュールとである。図２は、Ｔｏｋｙｏ Ｅｌｅｃｔｒｏｎ Ｉｎｃ．からのシステムの例示的なブロックダイヤグラムを示している。この代わりに、このＡＰＣシステムは、他のツールとこれらに関連したプロセスモジュールをサポートすることができる。例えば、前記ＡＰＣシステム１４５は、インターネット接続かイントラネット接続かにより前記プロセスモジュール１２０に接続されることができる。

前記プロセスモジュールのＩＤは、整数であることができる。ガスのパラメータの数は、モジュールタイプに依存することができ、前記メインテナンスカウンタの情報はこのモジュールに依存することができる。例えば、特定のメインテナンスカウンタに新しい名前を割り当てることができ、特別なスケールレートを割り当てることができ、このメインテナンスカウンタにツール休止関数を割り当てることができる。メインテナンスカウンタの一部として、一般的なカウンタを与えられることができ、一般的なカウンタは、ユーザにより設定されることができる。

図示された実施の形態において、単一のセンサ１３０が、関連されたプロセスモジュールとともに示されているが、これは、本発明のために必要とされていない。あらゆる数のセンサが、プロセスモジュールと結合されることができる。前記センサ１３０は、ＯＤＰセンサとＯＥＳセンサとＶＩＰセンサとアナログセンサとディジタルプローブを有する他のタイプの半導体プロセスセンサとを有することができる。ＡＰＣのデータ管理アプリケーションは、様々なセンサからのデータを集め、処理し、記憶し、表示し、出力するために用いられることができる。

前記ＡＰＣシステムにおいて、センサのデータは、外部と内部のソースの両方により与えられることができる。外部のソースは、外部のデータレコーダのタイプを用いて定義されることができる。データレコーダのオブジェクトが、外部のソースの各々に割り当てられることができ、状態変数の表現が用いられることができる。

センサの設定情報は、センサのタイプとセンサのインスタンスパラメータを結合する。センサのタイプはセンサの機能に対応する一般的な用語である。センサのインスタンスはこのセンサのタイプと特定のプロセスモジュール並びにツールとを対にする。少なくとも１つのセンサインスタンスが、ツールに取り付けられた物理的なセンサの各々に対して設定されている。

例えば、ＯＥＳセンサは、一つのタイプのセンサであることができ、ＶＩプローブは、他のタイプのセンサであることができ、アナログセンサは異なるタイプのセンサであることができる。加えて、追加の一般的なタイプのセンサと追加の特定のタイプのセンサがあることができる。センサのタイプは、運転時に特定の種類のセンサを設定するのに必要とされる全ての変数を有している。これらの変数は、静的（このタイプの全てのセンサは、同じ値を持つ）であることができ、インスタンスにより設定可能である（このセンサのタイプのインスタンスの各々は、独自の値を持つことができる）ことができ、データ収集プランにより動的に設定可能である（このセンサが運転時に作動されている各々の時に、センサは、異なる値を与えられる）ことができる。

「インスタンスにより設定可能な」変数は、センサもしくはプローブのＩＰアドレスである。このアドレスは、インスタンスにより（プロセスチャンバの各々に対して）代わるが、運転から運転で変化しない。「データ収集プランにより設定可能な」変数は、高調波の周波数のリストであることができる。これらは、前記コンテキスト情報に基づいてウエハの各々に対して異なるように設定されることができる。例えば、ウエハのコンテキスト情報は、ツールＩＤとモジュールＩＤとスロットＩＤとレシピＩＤとカセットＩＤとスタート時刻と終了時刻とを有することができる。おなじセンサのタイプの多くのインスタンスがあることができる。センサのインスタンスは、特定のハードウェアに対応し、センサのタイプをツール並びに／もしくはプロセスモジュール（チャンバ）に結びつけている。換言すると、センサのタイプは、一般的であり、センサのインスタンスは、固有である。

図１に示されているように、前記センサインターフェース１４０は、前記センサ１３０と前記ＡＰＣシステム１４５との間のインターフェースを与えるために用いられることができる。例えば、前記ＡＰＣシステム１４５は、インターネットもしくはイントラネット接続によりセンサインターフェース１４０に接続されることができ、このセンサインターフェーズ１４０は、インターネットもしくはイントラネット接続により前記センサ１３０に接続されることができる。また、このセンサインターフェース１４０は、プロトコルコンバータとメディアコンバータとデータバッファととして作用することができる。加えて、このセンサインターフェース１４０は、データ取得やピアトゥピア通信やＩ／Ｏスキャニングのようなリアルタイムな関数を与えることができる。この代わりに、このセンサインターフェース１４０は、消去されることができ、前記センサ１３０は、直接前記ＡＰＣシステム１４５に結合されることができる。

前記センサ１３０は、静的もしくは動的なセンサであることができる。例えば、動的なＶＩセンサは、周波数範囲とサンプリング時間とスケーリングとトリガとデータ収集プランにより与えられたパラメータを用いて実行時間に確立されたオフセット情報とをもつことができる。このセンサ１３０は、静的並びに／もしくは動的であることができるアナログセンサであることができる。例えば、アナログセンサは、ＥＳＣ電圧のためのデータと、マッチャ（matcher）パラメータと、ガスパラメータと、流量と、圧力と、温度と、ＲＦパラメータと、他のプロセスに関連したデータとを与えるために用いられることができる。このセンサ１３０は、ＶＩＰプローブとＯＥＳセンサとアナログセンサとディジタルセンサとＯＤＰセンサと他の半導体プロセスセンサとのうち少なくとも１つを有することができる。

一実施の形態では、生の（raw）データファイルにデータポイントを書くことができる。例えば、前記ＩＳ１５０は、データ取得を開始するためにセンサインターフェースにスタートコマンドを送ることができ、ファイルを閉じさせるためにストップコマンドを送ることができる。前記ＩＳ１５０は、センサのデータファイルを読みパーシング処理をし、そのデータを処理し、データの値をメモリ内のデータテーブルにいれることができる。この代わりに、前記センサインターフェースは、そのデータをリアルタイムで前記ＩＳ１５０に流すこともできる。前記センサインターフェースがファイルをディスクに書くことを可能にするためにスイッチも与えられることができる。このセンサインターフェースは、ファイルを読みオフラインの処理と解析のために前記ＩＳ１５０にデータポイントを流すための方法を与えることもできる。

図１に示されているように、前記ＡＰＣシステム１４５は、データベース１９０を有することができる。ツールのメインテナンスデータは、このデータベース１９０に記憶されることができる。加えて、前記ツールからの生のデータとトレースデータとが、ファイルとしてデータベース１９０に記憶されることができる。データの量は、プロセスが実行されプロセスツールが実行される頻度はもちろん、ユーザにより設定されたデータ収集プランに依存している。例えば、データ収集プランは、どのようにそしていつツールの状態とプロセスに関連したデータを集めるのかを決定するために確立されることができる。前記プロセスツールとプロセスチャンバとセンサとＡＰＣシステムから得られたデータは、テーブルに記憶される。

一実施の形態において、このテーブルは、前記ＩＳ１５０においてはメモリ内テーブルとして、前記データベース１９０においては、持続性のストレージとして実行される。前記ＩＳ１５０は、前記テーブルにデータを置くことはもちろん、カラムとロウの生成にＳｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＱＬ）を用いることができる。このテーブルは、前記データベース１９０の持続性のテーブルにおいて複製されることができ（すなわち、ＤＢ２が使われることができる）、同じＳＱＬのステートメントを用いて設けられることができる。

図示された実施の形態では，前記ＩＳ１５０は、メモリ内リアルタイムデータベースとサブスクリプションサーバの両方であることができる。例えば、クライアントプロセスは、関連のあるデータテーブルのよく知られたプログラムモデルを用いてＳＱＬを使ってデータベース関数を実行することができる。加えて、このＩＳ１５０は、選択基準にあうデータが挿入され、更新され、消去される時はいつでも前記クライアントソフトウェアが非同期の通知を受け取るデータサブスクリプションサービスを与えることができる。サブスクリプションは、未来のデータの変化の通知をフィルタするために、どのテーブルのカラムが関心があり、どのロウの選択基準が用いられているのかを明記するためにＳＱＬの選んだステートメント（ＳＱＬ select statement）を完全に活用する。

前記ＩＳ１５０は、データベースであり、サブスクリプションサーバであるから、存在するテーブルデータが初期化される時に、クライアントは、存在するテーブルデータに「同期化された」サブスクリプションをひらくことができる。このＩＳ１５０は、パブリッシュ／サブスクライブ機構と、メモリ内のデータテーブルと、イベントを整理する監視するためのロジックとを通して、データの同期化を与え、システムを通して警報する。このＩＳ１５０は、ソケットとＵＤＰとパブリッシュ／サブスクライブとを有する技術に基づいたいくつかのメッセージングＴＣＰ／ＩＰを与える。

例えば、このＩＳ１５０の構造は、リアルタイムのデータ管理とサブスクリプション機能とを与えることができる多くのデータハブ（すなわち、ＳＱＬデータベース）を用いることができる。アプリケーションモジュールとユーザインターフェースとは、このデータハブの中の情報にアクセスし、この情報を更新するためにＳＱＬのメッセージを用いている。ランタイムデータを関連のあるデータベースにおくことに関連したパフォーマンスの制限のために、ランタイムデータは、前記ＩＳ１５０により管理されているメモリ内のデータテーブルに置かれている。これらのテーブルの内容は、ウエハプロセスの終わりに関連のあるデータベースにおかれることができる。

図１に示された図示された実施の形態では、単一のクライアントワークステーション１７０が示されているが、そのことは、本発明に必要とされていない。前記ＡＰＣシステム１４５は、複数のワークステーション１７０をサポートすることができる。一実施の形態では、このクライアントワークステーション１７０は、ユーザが、センサを設定することと、ツールとチャンバとセンサとの状態を含む状態を見ることと、プロセスの状態を見ることと、ヒストリカルデータを見ることと、故障（fault）データを見ることと、モデリング関数とチャーティング関数とを実行することとを、可能にしている。

図１に示された図示された実施の形態では、前記ＡＰＣシステム１４５は、前記ＩＳ１５０に結合されることができるＡＰＣサーバ１６０と、クライアントワークステーション１７０と、ＧＵＩ構成成分１８０と、データベース１９０とを有することができるが、このことは、本発明に必要とされていない。このＡＰＣサーバ１６０は、少なくとも１つのツールに関連したアプリケーションと、少なくとも１つのモジュールに関連したアプリケーションと、少なくとも１つのセンサに関連したアプリケーションと、少なくとも１つのＩＳに関連したアプリケーションと、少なくとも１つのデータベースに関連したアプリケーションと、少なくとも１つのＧＵＩに関連したアプリケーションとを有する多くのアプリケーションを有することができる。

前記ＡＰＣサーバ１６０は、多数のプロセスツールをサポートし、ツールとプロセスモジュールとセンサとプローブとからのデータを収集し同期化し、データベース内にデータを記憶しユーザが存在するチャートを見ることを可能にし、並びに／もしくは故障の検出をあたえる少なくとも１つのコンピュータとソフトウェアとを有している。例えば、このＡＰＣサーバ１６０は、Ｔｏｋｙｏ ＥｌｅｃｔｒｏｎからのＩｎｇｅｎｉｏソフトウェアのようなオペレーショナルソフトウェアを有することができる。このＡＰＣサーバは、オンラインシステム設定と、オンラインのロットからロットの（lot-to-lot）故障の検出と、オンラインのウエハからウエハの故障の検出と、オンラインのデータベースの管理とを可能にし、ヒストリカルデータに基づいたモデルを用いてサマリ（summary）データの多変量解析を実行している。加えて、ＡＰＣは、プロセスとプロセスツールのリアルタイムの監視を可能にしている。

例えば、最小で３ギガバイトの利用可能なディスク領域と、少なくとも６００ＭＨｚのＣＰＵ（デュアルプロセッサ）と、最小で５１２メガバイトのＲＡＭ（物理メモリ）と、ＲＡＩＤ ５設定の９ギガバイトのＳＣＳＩハードドライブと、最小で前記ＲＡＭのサイズの２倍のディスクキャッシュと、ソフトウェアのインストールされたＷＩＮＤＯＷＳ（登録商標）２０００サーバと、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）と、ＴＣＰ／ＩＰネットワークプロトコルと、少なくとも２枚のネットワークカードとを有することができる。

テーブルへのソフトウェアインターフェースは、ＴＣＬとＳＱＬとの組み合わせにより与えられている。例えば、バックグラウンドで作動しているローダのプロセスは、ファイルからデータベースにＳＱＬコマンドを送るデータベースにデータをおくことができる。メモリ内テーブルから持続性のテーブルへのデータの移動は、ＳＱＬをファイルに書き、そのファイルをローダのディレクトリに置くことによりなされることができる。このＳＱＬが、実行された後、このファイルは、ローダのディレクトリから自動的に消去されることができる。

システムで収集されたデータは、リアルタイムのセンサの収集とデータベースの記憶との間の一組の段階を通して流れる。システムから収集されたデータは、まず前記ＩＳ１５０のリアルタイムのメモリＳＱＬデータベースにロードされている。ＳＱＬデータベースは、前記ＡＰＣシステムのデータ管理部分におけるプランを通してユーザにより定義された異なるアルゴリズムにより、そしてコントロールジョブにより定義されたスクリプトにより、処理されるべきデータの物理的な位置を与えている。

前記ＡＰＣシステム１４５は、センサからの生のデータを有するファイルとツールからのトレースデータを有するファイルとを記憶する少なくとも１つの記憶装置を有することができる。もし、これらのファイルが、きちんと管理されていないなら（すなわち、定期的に消去されていない）、この記憶装置は、ディスク領域が不足しえて、新しいデータの収集を止めてしまう可能性がある。このＡＰＣシステムは、ユーザに古いファイルを消去することを可能にし、それによりデータ収集が中断することなく続くことができるデータ管理アプリケーションを有することができる。このＡＰＣシステム１４５は、システムを操作するために用いられる複数のテーブルを有することができ、これらのテーブルは、前記データベース１９０に記憶されることができる。加えて、オンサイトかオフサイトのコンピュータまたはワークステーション並びに／もしくはホストのような他のコンピュータ（図示されていない）は、１つもしくは多くのツールに対して、データもしくはチャートを見ること、ＳＰＣチャーティング、ＥＰＤ解析、ファイルアクセスのような機能を与えることができる。

図１に示されているように、前記ＡＰＣシステム１４５は、ＧＵＩ構成成分１８０を有することができる。例えば、ＧＵＩ構成成分は、前記ＡＰＣサーバ１６０とクライアントワークステーション１７０とツール１１０との上のアプリケーションとして走ることができる。

前記ＧＵＩ構成成分１８０は、ＡＰＣシステムユーザに、所望の設定とデータ収集と監視とモデリングと問題解決のための仕事とを、できるかぎりすくない入力で実行することを可能にする。このＧＵＩの設計は、ＳＥＭＩ Ｈｕｍａｎ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄ ｆｏｒ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｅｑｕｉｐｍｅｎｔ（ＳＥＭＩ Ｄｒａｆｔ Ｄｏｃ．＃２７８３Ｂ）と、ＳＥＭＡＴＥＣＨ Ｓｔｒａｔｅｇｉｃ Ｃｅｌｌ Ｃｏｎｔｒｏｌｌｅｒ（ＳＣＣ）Ｕｓｅｒ−Ｉｎｔｅｒｆａｃｅ Ｓｔｙｌｅ Ｇｕｉｄｅ１．０（Ｔｅｃｈｎｏｌｏｇｙ Ｔｒａｎｓｆｅｒ ９２０６１１７９Ａ−ＥＮＧ）とに従う。当業者は、ＧＵＩパネルまたはスクリーンは、左から右への、並びに／もしくは、右から左への、下から上への、上から下への、もしくは組み合わせの選択タブの構造を有することができることを認める。

加えて、例示のために示されたスクリーンは、英語バージョンだが、このことは、本発明のためにひつようではなく、異なる言語が用いられることができる。

また、前記ＧＵＩ構成成分１８０は、前記ＡＰＣシステムとユーザの間の相互作用の手段を与えている。このＧＵＩが始まると、ユーザの識別とパスワードを確認するログオンスクリーンが表示されることができ、それは、第１レベルのセキュリティをあたえている。望ましくは、ユーザは、ログオンする前に、セキュリティアプリケーションを用いて登録されることができる。ユーザの認証のデータベースのチェックは、認証レベルを記述し、それにより、利用可能なＧＵＩ機能を簡素化する。ユーザが認証されていない選択アイテムは、異なることができ、利用不可能になることができる。前記セキュリティシステムは、またユーザが現存するパスワードを変えることを可能にする。例えば、ログオンのパネルまたはスクリーンは、Ｎｅｔｓｃａｐｅ（登録商標）かＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）のようなブラウザツールから開かれることができる。ユーザは、ユーザＩＤとパスワードとをログオンフィールドに入れることができる。

認証されたユーザと管理者は、ＧＵＩのパネルまたはスクリーンをシステム設定とセンサのセットアップパラメータを変更するために用いることができる。前記ＧＵＩ構成成分１８０は、ユーザが、プロセスツールとプロセスモジュールとセンサと前記ＡＰＣシステムとを設定することを可能とするために、設定構成成分を有することができる。例えば、ＧＵＩの設定パネルまたはスクリーンは、プロセスツールとプロセスモジュールとセンサとセンサのインスタンスとモジュールの休止と警報との少なくとも１つのために与えられることができる。設定データは、属性データベーステーブルに記憶されることができ、インストール時においては、デフォルト値で設定されることができる。

前記ＧＵＩ構成成分１８０は、プロセスツールとプロセスモジュールとセンサと前記ＡＰＣシステムのために現在の状態を表示するための状態構成成分を有することができる。加えて、この状態構成成分は、１つもしくはそれより多くの異なるタイプのチャートを用いるユーザにシステム関連した、そしてプロセスに関連したデータを提供するためのチャート構成成分を有することができる。

また、ＧＵＩ構成成分１８０は、リアルタイムの操作構成成分を有することができる。例えば、ＧＵＩ構成成分は、バックグラウンドのタスクに結合されることができ、分配されたシステムのロジックは、このバックグラウンドのタスクとＧＵＩ構成成分との両方により用いられる共通の機能性を提供する。分配されたロジックは、このＧＵＩ構成成分に返された値が、バックグラウンドのタスクに返された値と同じであることを保証するために用いられることができる。さらに、このＧＵＩ構成成分１８０は、ＡＰＣのファイル管理ＧＵＩ構成成分とセキュリティ構成成分を有することができる。ヘルプのパネルまたはスクリーンもまた利用可能である。例えば、ヘルプファイルは、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）並びに／もしくはＨＴＭＬフォーマットで与えられている。

図１に示されているように、ＡＰＣシステム１４５は、ファクトリシステム１０５並びに／もしくはＥ診断システム１１５に結合されることができる。ファクトリシステム１０５並びに／もしくはＥ診断システムは、前記ツールとモジュールとセンサと半導体プロセスシステムにおけるプロセスを外部から監視するためのならびに外部からコントロールするための手段をあたえることができる。この代わりに、前記ファクトリシステム１０５並びに／もしくはＥ診断システム１１５は、ツールの状態の監視を実行することができる。例えば、ユーザは、ファクトリシステム１０５並びに／もしくはＥ診断システム１１５により半導体プロセスシステムに結合されたターミナルに基づいたウェブを用いてツールの状態を監視するシステムにアクセスすることができる。

加えて、前記ＡＰＣシステムと前記Ｅ診断システムは、リアルタイムに問題を解決するために一緒に作動することができる。例えば、前記ＡＰＣシステム１４５が、故障を検出した時、その問題を診断するために必要な情報は、このＡＰＣサーバにより束ねられ、前記Ｅ診断システムに伝えられるか、後のＥ診断システムによるアクセスのために記憶される。操作方法は、セキュリティの制約並びに／もしくは顧客のビジネスルールを用いて決定されることができる。

また、ＡＰＣは、センサを加えるための、そしてコンテキスト並びに／もしくはイベントに駆動されるデータ収集プランを編集するための手段を有している。例えば、このことは、Ｅ診断の「プローブ」並びに／もしくはソフトウェア構成成分が、Ｅ診断システムがシステムの問題を解決するためにダウンロードされることを可能にすることができる。前記ＡＰＣシステムは、問題を診断し、検出し、並びに／もしくは予測するために用いられることができる追加のデータをあたえることができる軽便な診断のツールを有することができる。例えば、前記ＡＰＣシステムは、これらの診断のツールを追加のセンサとして用いることができる。最低のレベルとしてアナログの入力を有する、多数のプロトコルをサポートする一般的なセンサインタフェースを用いて、局所的な軽便な診断ユニットは、前記ファクトリシステムに結合されることができ、それから前記ＡＰＣシステム、Ｅ診断システム並びに／もしくはファクトリシステムにより遠隔的に用いられることができる。

前記ＡＰＣシステムは、遠隔的に前記ファクトリで開発され、このファクトリもしくは前記Ｅ診断システムからダウンロードされた新しいアプリケーションを与えられることができる。例えば、この新しいアプリケーションは、前記ＡＰＣサーバに局所的に存在することができる。前記ＡＰＣシステムは、新しい手続きを学び、動的にセンサを加え、アプリケーションを加え、カスタムセンサのためにＧＵＩスクリーンを加えることさえする能力を有する。さらに、このＡＰＣシステムは、いつツール並びに／もしくはモジュールがうまく作動しなかったか（すなわち、ウエハを取り扱うシステムのモータかアクチュエータの腕の位置の問題）を理解するためのタイミング解析の割り当てのような非常に特有な手続きを実行することができる。

加えて、このＡＰＣシステムは、ツールパフォーマンスに基づいてサンプリングレートを変化させることができる。例えば、データ収集のサンプリングレートと解析の量は、ツールの状態に基づいて変化されることができる。このＡＰＣシステムは、また、問題を予測するか、ツール並びに／もしくはモジュールが限界状態近くで動いていることを検出することができる。

加えて、アドバンストユーザと管理者は、システム設定とセンサのセットアップパラメータを変更するためにＧＵＩスクリーンを使うことができ、ツールに関連したストラテジとプランを作り編集することができ、並びに／もしくは、ツールとモジュールの数を変更することができる。

前記ＡＰＣシステムは、顧客（エンドユーザ）がプロセスツール、プロセスモジュール、並びに／もしくはセンサを加えることを可能にする設定可能なシステムを用いて実行される。このＡＰＣシステムは、顧客が監視ソフトをカスタマイズし、解析アプリケーションを加え、並びに／もしくは新しいツールとモジュールとセンサを環境にインストールし監視することとを可能にする開発環境と方法とを与える。

前記ＡＰＣシステムソフトウェアの構造は、データ取得構成成分とメッセージシステム構成成分と関連するデータベース構成成分とポストプロセス構成成分との４つの機能上の構成成分を有する。この構造は、またランタイムデータの取得パラメータを記憶するために用いられるメモリ内データテーブルを有する。前記ＡＰＣシステムの外部にはツールエージェントはもちろん前記ツールがあり、このツールは、データ取得とツールプロセスを同期化するために用いられるコンテキスト情報とスタートストップタイミングコマンドを与える。

前記データ取得構成成分は、パラメータと呼ばれるデータポイントをあつめ、ファイルにそれらを書き込んでいる。前記メッセージシステムは、このデータ取得構成成分から受け取ったランタイムデータの一時的な記憶のためにメモリ内データテーブルを用いている。このメッセージシステムは、エージェント並びに／もしくはツールクライアントにより前記データ取得期間のスタートと終了とを通知されている。データ取得期間の終わりには、そのデータは、関連するデータベースにおかれ、メモリ内データテーブルは、次の取得期間のためにクリアされている。前記メッセージシステムにより供給されたデータのポストプロセスは、ランタイムに実行され、前記関連するデータベースに記憶されたデータのポストプロセスは、オフラインで実行される。

前記ＡＰＣシステムの目標は、半導体プロセスシステムのパフォーマンスを改善するためにリアルタイムデータとヒストリカルデータとを用いることである。この目標を成し遂げるために、潜在的な問題は、それが起こる前に予測され、正されることができ、このようにして装置のダウンタイムと生産されるノンプロダクトのウエハを減少させている。これは、データを収集し、そのデータを特定のツール、プロセスモジュール並びに／もしくはセンサの振る舞いをモデル化するソフトウェアアルゴリズムに与えることにより達成されることができる。前記ＡＰＣシステムは、プロセスのパラメータ上の適応を出力し、それは、それからツールパフォーマンスを特定の極限内に保つためにフィードフォワードかフィードバックされている。このコントロールは、様々なレベルで様々な形式で実行されることができる。

前記ＡＰＣシステムの警報管理部分は、故障検出アルゴリズム、故障分類アルゴリズム、並びに／もしくは故障予測アルゴリズムを与えることができる。このＡＰＣシステムは、いつツール、プロセスモジュール、並びに／もしくはセンサがうまく機能しないのかを予測し、機能不全を正し、メインテナンス機能とプロセス機能の間に生産されたノンプロダクトのウエハの数を減少させるために可能な解決策を特定することができる。

故障の予測は、故障の検出と不良のモデル化の組み合わせである。この方法は、チャンバのクリーニングと消耗部分の置き換えを最適化するために用いられることができ、生産に一時的な停滞がある時に、予防的なメインテナンスタスクの「日和見主義のスケジューリング」を容易にすることを意図されている。故障の予測は、複雑な多変量のモデルか単純な一変数関係（すなわちエッチングにおけるウェットクリーニングのためのＡＰＣの角度）の一方に基づくことができる。例えば、故障の予測は、ツール、プロセスモジュール、並びに／もしくはセンサがいつ失敗するのかと、いつツール、プロセスモジュール、並びに／もしくはセンサにメインテナンスを実行するべきかを予測するために用いられることができる。

前記ＧＵＩアプリケーションは、ユーザにセンサがデータを収集しているかどうかを決定する能力を与える。データ収集プランが、センサからのデータを必要としない時、センサの状態は、ユーザにこのセンサはオンになっていることが期待できないという表示を与える。例えば、データ収集プランが、センサからのデータを必要としない時は、そのセンサの状態は「オンライン オフ」のはずであり、ユーザがセンサをシステムレベルで割り込み禁止状態にした時は、状態は、「オフライン オフ」のはずである。

ツール、モジュール、並びに／もしくはセンサのインターフェースは、不良とサービスに関連した妨害に対して耐性がある。加えて、このインターフェースは、セットアップと問題解決の能力がある。例えば、妨害が起こった時、前記ツール、モジュール、並びに／もしくはセンサ、並びに／もしくはＡＰＣシステムは、正しい振る舞いを決定し、機能性の損失を最小化するために、その妨害を検出し、ログ、警報、自動の復元と解析とを初期化することができる。このように、顧客が、ツール、モジュール、センサ、並びに／もしくはＡＰＣシステムが、機能性を減少されて作動している間に、製品を製造する危険は、減少されることができる。

加えて、問題解決、並びに／もしくは、メインテナンスアプリケーションは、サービスとメインテナンスのモードの間に作動することができる。センサのコミュニケーションの問題解決の目的で、センサは、ウエハを実行することなく、テストされることができる。例えば、センサは、ウェブに基づいたＧＵＩから設定され、スタートされ、ストップされることができる。この態様は、センサのセットアップと日常のセンサのメインテナンスにおいてひろく用いられることができる。

前記ＡＰＣシステムは，Ｔｏｋｙｏ Ｅｌｅｃｔｒｏｎ Ｌｉｍｉｔｅｄ，ＩＮＣからのＤｏｃ．Ｎｏ．１Ｄ９７−Ａ５０００３−２１に示されているように設置され設定されることができる。この文書は、「ＡＰＣ Ｉｎｓｔａｌｌａｔｉｏｎ／Ｓｔａｒｔｕｐ Ｍａｎｕａｌ」と題され、参照によりその全体において本発明に組み込まれている。

図３は，本発明の一実施の形態による前記ＡＰＣシステムのための単純化されたデータフローダイヤグラムである。主要なデータフローの道は、図３に示されている。前記ＡＰＣソフトウェアの構造は、データ収集サブシステムとメッセージシステムサブシステムと関連するデータベースサブシステムとポストプロセスサブシステムとの４つの機能上のサブシステムを有する。この構造は、またランタイムデータ取得パラメータを記憶するために用いられるメモリ内のデータテーブルを有している。このＡＰＣソフトウェアの外部に、前記ツールエージェントはもちろん、前記ツールプロセスとデータ取得を同期化するために用いられるコンテキスト情報とスタートストップタイミングコマンドを与える前記ツールがある。

前記データ取得サブシステムは、パラメータとよばれるデータポイントを収集し、それらをファイルに書き込んでいる。前記メッセージシステムは、データ取得サブシステムから受け取ったランタイムデータを一時的に記憶するために、メモリ内データテーブルを用いる。前記エージェントクライアントは、このメッセージシステムにデータ取得期間の始めと終わりを通知している。このデータ取得期間の終わりには、このデータは、関連するデータベースにおかれ、メモリ内のデータテーブルは、次の収集期間のためにクリアされる。前記メッセージサブシステムにより与えられたデータのポストプロセスはランタイムに実行され、前記関連するデータベースに記憶されたデータのポストプロセスは、オフラインで実行される。

データ収集としても知られるデータ取得は、２つのルートを通して達成されている。前記ツールは、ウエハの処理の間にデータを収集し、そのデータをトレースファイルに記憶する。各々のウエハが、前記ツール上で処理された後、このトレースファイルは、前記ツールから前記ＡＰＣファイルシステムにコピーされ、前記ＡＰＣソフトウェアは、このファイルをパーシング処理し、メモリ内データテーブルにそのデータをおいている。メモリ内データは、それから前記関連するデータベースに送られ、最終的には、ポストプロセス構成成分に置かれる。

プロセス関連のデータは、前記ＡＰＣシステムにより、１つもしくはそれより多くのセンサを用いて収集される。各々のセンサは、データレコーダを用いる。ランタイムには、このデータは、前記ツール上のトレースファイルと同様のファイルに送られる。レシピの終わりでは、このファイルは、パーシング処理され、そのデータは、前記ＩＳ１５０により管理されているメモリ内データテーブルに送られる。
ポストプロセスのデータフローは、２つの道の１つに従っている。このポストプロセスが、ランタイムに行われるときは、データは、前記ＩＳ１５０から少なくとも１つのポストプロセス構成成分に流れている。このポストプロセスが、オフラインで行われている時、このデータは、前記関連するデータベースから前記ポストプロセス構成成分に流れている。これらの道は、図３に示され、それぞれ「ランタイム」と「オフライン」とラベルされている。

図４は、本発明の実施の形態による故障の検出と分類のプロセス（ＦＤＣ）のための単純化されたフローダイヤグラムを示している。図示された実施の形態において、ＡＰＣの構造の様々な構成成分とともに、エッチングのプロセスモジュールが示されている。

図４において、入ってくるウエハの状態と出て行くウエハの状態が示されている。例えば、この入ってくるウエハの状態は、ウエハＩＤ、ロットＩＤ、カセットナンバ、スロットＩＤ、プロセスステップもしくはレイヤナンバ、プロセスレシピからなるコンテキストによって特徴付けられることができる。入ってくるレイヤの厚さのような追加の情報も利用することができる。また、前記出て行くウエハの状態は、ウエハＩＤ、ロットＩＤ、カセットナンバ、スロットＩＤ、プロセスステップもしくはレイヤナンバ、プロセスレシピからなるコンテキストによって特徴付けられている。

エッチングプロセスモジュールもしめされているが、他のモジュールが使われることができる。例えば、プラズマエッチングプロセスは、レシピに基づくことができ、１つもしくはそれより多くのステップを有することができる。ステップは、連続して番号付けされることができ、プロセスのセットポイントが一定である時間を参照している。プロセスのセットポイントは、レシピに依存してステップの境界で変えられる。

加えて、モデル導出構成成分が、示されている。例えば、モデル導出構成成分は、プロセスモデルエンジンが、現在のウエハプロセス上での解析を実行するのに必要とされる設定とデータを有することができる。この設定は、ユーザ、普通はプロセスの技術者、から与えられることができ、センサの設定と、集めるべきプロセス変数のリストと、集めるべきセンサ変数のリストと、この変数のそれぞれをどのように処理するかについての指示と、どのタイプのモデルを実行するかという選択とを有している。前記データは、通常作動するプロセスを表すトレーニングセットから抽出された値を有することができる。

図４には、プロセスモジュール（ＰＭ）状態とセンサとプロセスデータとの構成成分が、示されている。ＡＰＣシステムの一つの機能は、様々なセンサからデータを集め、このデータの収集と前記エッチングツールにおけるプロセスを同期化することである。集めるべきデータの数とタイプは、データ収集プランと呼ばれる設定パラメータに依存している。プロセスモジュール（ＰＭ）状態とセンサデータとプロセスデータとは、テーブルの中に集められることができる。データ収集は、ツールエージェントクライアントによって報告されているように、前記ツールエージェントからくるイベントによってエッチングのプロセスと同期化される。

図４に示されているプロセスモデルエンジンは、現在のプロセスを前記トレーニングセットによって表される以前のウエハプロセスと比較する様々な方法はもちろん、生のデータの処理と解析を与えることができる。データ解析プランに基づいて選ばれた変数のサマリが、作られることができ、サマリ化されたデータは、前記モデルエンジンに送られることができる。例えば、このモデルエンジンは、「ＰＣＡ」モデルと「ＰＬＳ」モデルとをサポートすることができる。典型的には、プロセス変数だけが知られているならば、ＰＣＡが、用いられる。もし、プロセス変数と計測データとが利用できるならば、ＰＬＳが用いられる。

データ管理システム構成成分も、図４に示されている。前記ＡＰＣシステムにおいて、データと実行される動きはこのデータ管理システムにおかれている。このデータ管理システムは、センサとプロセスとのデータをセーブするためのファイルシステムはもちろん、持続性の（persistent）データベースからも成り立っている。センサのデータとプロセスのデータとセンサとプロセスのデータの処理の結果は、前記持続性のデータベースと、データ収集プランとデータ解析プランとの設定に依存したファイルシステムとにおかれる。

図４では、「期待される結果もしくは期待される結果からのずれ」とラベルされているモデルの出力構成成分が、示されている。例えば、プロセスモデルエンジンからの出力は、１つもしくはそれより多くの数値の形の、期待された結果もしくは期待された結果からのずれである。ＰＣＡもしくはＰＬＳ解析の場合、値は、データベースにおける統計的なパラメータとしてサマリ化されるプロセス変数の集まりを表しており、「Ｔ２とＱ」とラベルされている。他のサマリは、データ解析プランにおける設定に基づいてプロセスモデルエンジンにより作られることができる。

構成成分が、図４に示されており、その中で、前記期待された結果もしくは期待された結果からのずれは、「Ｗｅｓｔｅｒｎ Ｅｌｅｃｔｒｉｃ Ｒｕｌｅｓ」と呼ばれるパターン整合ルール（pattern matching rules）のセットはもちろん、上方および下方の数値制限からなるＳＰＣ実行ルール（run-rules）を用いて、比較されている。プロセス制限という用語は、特定のプロセスのために確立された数値のセットに言及している。これらの値は、上方コントロール制限と下方コントロール制限とを有する。プロセスが、この制限の中にない時に実行される動きは、解析ストラテジにおける設定に基づいている。

１において、前記入ってくるウエハの状態が、エッチングプロセスモジュールに与えられている。例えば、この入ってくるウエハは、ウエハＩＤ（スクライブ）と、ロットＩＤと、レイヤナンバもしくはプロセスステップと、カセットナンバと、スロットＩＤと、エッチングレシピネームとにより特徴付けられることができる。この情報は、エッチングプロセスに先立ってエッチングツールにわたされ、「ウエハイン」イベントとともに前記ＡＰＣシステムに渡される。イベントと関連したデータとは、前記ツールエージェントからツールエージェントクライアントに送られる。「ウエハイン」のイベントを受け取るとすぐに、前記ＡＰＣサーバは、メモリ内のテーブルに関連したデータをおき、レシピの名前に基づいて前記データ収集プランにより必要とされるセンサ設定の検査を行い、各々のせんさに設定を送っている。後に、エッチングプロセスは、前記ツールエージェントから前記ツールエージェントクライアントに「レシピ開始」イベントを送り、エッチングプロセスの開始を合図している。前記ＡＰＣサーバは、「取得開始」のコマンドを各々のセンサに送ることにより応答している。加えて、他のイベントが、エッチングウエハプロセスの間に可能である。

２において、前記エッチングプロセスモジュールは、ＰＭ状態とセンサデータとプロセスデータとのようなデータを与えている。例えば、エッチングプロセスが終了するとすぐに、エッチャモジュールは、エッチングプロセスのデータファイルをエッチャ上のローカルディスクドライブに書き込むことができ、「レシピ終了」イベントを前記ツールエージェントからツールエージェントクライアントにおくることができる。「レシピ終了」のイベントを受け取るとすぐに、前記ＡＰＣサーバは、データファイルを前記ツールからＡＰＣサーバファイルシステムに転送している。ファイル転送が終了すると、前記ＡＰＣサーバは、プロセスファイルとセンサデータの各々をパーシング処理し、その結果をメモリ内のテーブルにおく。

３では、エッチングプロセスデータは、出て行くウエハ状態を確立するために用いられることができる。例えば、プロセスの終了とエッチングプロセスからのウエハの除去とは、前記ツールエージェントからツールエージェントクライアントへの「ウエハアウト」イベントにより合図されることができる。前記ＡＰＣサーバは、このイベントと関連するデータをメモリ内のテーブルにおき、ウエハの対象と関連しているあらゆるプロセスルーチンを開始することにより応答することができる。

４では、前記モデルの導出の出力は、前記モデルエンジンに与えられている。例えば、サマリ計算の完了がプロセスモデルの実行のトリガになることができる。この時点で、指示と以前に解析されたトレーニングセットからの入力データとのセットからなる前記モデルの導出は、前記プロセスモデルエンジンに読み込まれている。このモデルの導出は、どのように結果を期待された結果からのずれとして出力するかという指示を有することができる。

５において、前記ＰＭ状態とセンサのデータとプロセスのデータとは、前記モデルエンジンに与えられることができる。例えば、一度プロセスとセンサのデータが、前記メモリ内のテーブルにおかれると、データの処理が始まることができる。プロセスは、サマリの計算をし、エッチングのプロセスのレシピの中の個別のプロセスのステップの統計的なサマリをつくることにより進む。実行するべき統計的な計算のパラメータとタイプの選択は、ユーザにより設定可能である。平均と標準偏差と最小と最大は、各々のパラメータとプロセスのステップに対して計算されることができる。これらの計算の結果は、メモリ内テーブルにさらなるプロセスのためにおかれることができる。サマリ計算の処理の完了は、計量的な結果が必要とされていないと仮定するならば、プロセスモデルの実行のトリガとなる。

６において、前記モデルエンジンは、結果を出力している。例えば、前記プロセスモデルエンジンの実行は、前記モデルの導出における指示に依存して、期待された結果もしくは期待された結果からのずれの形で、１つもしくはそれより多くの数値の結果をつくっている。これらの結果の各々は、設定可能な運転のセットに対する評価のための実行ルール評価プロセスに送られることができる。これらのルールは、プロセスが限界の内側にあるかないかを示す値のセットに対する現在の点の評価を有する。

７から１０において、プロセスが、前記限界の内側にない時の状況に対して、プロセスが示されている。例えば、故障が、検出されている時、システムは、技術者に知らせるように設定されている。これは、電子メイルを送るか、適切な人もしくは人々を呼び出す警報システムを通して実行されることができる。

故障が検出されている時、システムは、ツールを休止するように設定されることができる。これは、特定のツールメインテナンスカウンタに値を送ることにより実行されることができる。故障が、検出されている時、システムは、メインテナンスを示唆するように設定されることができる。これは、電子メイルを送るか、適切な人もしくは人々を呼び出す警報システムを通して実行されることができる。故障が、検出される時、システムは、この故障を分類するように設定されることができる。これは、（もし、前記プロセスモデルが、ＰＣＡかＰＬＳを用いているなら）トレースチャートへのコントリビューションチャートへの警報を記述するＳＰＣチャートからのドリルを含む手動操作であることができる。

１１と１２とにおいて、データが、前記データ管理システムに送られている。例えば、故障が検出されないなら、このイベントは、このデータ管理システムにおかれることができる。また、故障が検出され、もしくは修正が必要とされているときは、故障活動（fault action）が、持続性のデータベースにおかれることができる。

１３と１４とにおいて、データが、前記モデルエンジンと前記データ管理システムの間で交換されている。例えば、プロセスのためのデータが、前記プロセスモデルエンジンによって処理され解析された後に、それは、前記持続性のデータベースにおかれることができる。加えて、特定のシナリオでは、プロセスの現在の状態との比較のために前記プロセスモデルエンジンにおいて再構成される以前のプロセスの運転からのヒストリカルデータを必要としている。また、前記プロセスモデルエンジンは、プロセスとセンサのデータに基づいたＣＤを予測することができる。長い間、このようなモデルは、実際のプロセスパフォーマンスからそれることが知られている。実際の計測的な結果との定期的な比較が、プロセスモデルが、この逸脱から正されることを可能にする。

前記ＡＰＣシステム１４５（図１）は、システムを操作するために用いられる複数のテーブルを有することができ、これらのテーブルは、データベース１９０（図１）に記憶されることができる。

前記テーブルは、入力センサ装置、プロセスツール、解析モジュール、出力インターフェース、装置資源などのようなシステムの構成成分を設定するために用いられることができる。例えば、構成成分テーブルは、独自のモジュールもしくは構成成分ＩＤの割り当て、モジュールもしくは構成成分の記述などのような項目を有することができる。

また、このテーブルは、属性テーブルを有することができ、構成成分テーブルのエッチング構成成分は、装置の位置、クロックのオフセット、最後の較正の時間、所有者の技術者などの事柄を特定するために用いられることができる、この属性テーブルにおける多くの関連する記録を有することができる。例えば、前記属性テーブルは、前記ツール、チャンバなどのための設定情報を有することができる。システムの設定パラメータは、この属性テーブルに、ｔｙｐｅ＝’ｓｙｓｔｅｍ’とＩＤ＝’ｃｏｎｆｉｇｕｒａｔｉｏｎ’で記録されることができる。テーブルの中の残りのカラムである名前と値とは、特定のパラメータとその値とを特定するために用いられる。

加えて、ＡＰＣシステム設定のＧＵＩスクリーンは、前記属性テーブルからデータを得ることができる。例えば、ユーザが、セーブか消去を実行するとき、属性テーブルの操作データは、更新されることができる。

前記ＡＰＣシステムは、また構成成分のための（名前，値）の対と、プロセスの運転と、モデルデータベースと、他のものとの標準化された記憶を管理するために用いられる運転属性テーブルを有することができる。この独立したテーブルでは、対の数に制限がなく、特定の項目が、標準化されインデックスのつけられた表現のためにはやく見つけることができる。テーブルの中には、標準化されていない属性領域をもつものがある。これは、属性の期待される数が小さく、使用パターンが個々の値へのよい直接のアクセスを要求しない場合になされる。

関連テーブルは、また前記ＡＰＣシステムに含まれることができる。それは、関連を記述するために用いられる一般的なテーブルである。例えば、モデルのインプットデータのテーブルをもつモデルの関連は、ｐａｒｅｎｔ ｔｙｐｅ＝‘ｍｏｄｅｌ’、ｐａｒｅｎｔ ＩＤ＝‘ｍｙ ｍｏｄｅｌ１’、ｉｔｅｍ ｔｙｐｅ＝‘ｔａｂｌｅ’、ｉｔｅｍ ＩＤ＝‘ｍｏｄｅｌ ｄａｔａ１’、ａｔｔｒｉｂｕｔｅｓ＝’｛ｌａｓｔ ｅｄｉｔ｛１９９９−０５−１９ ０９：３０：２３｝｝‘を有することができる。

加えて、前記ＡＰＣシステムは、生の運転（raw runs）のためのヘッダテーブルを定義するために用いられることができるプロセス運転テーブルを有することができる。プロセス運転テーブルは、開始時間、ウエハ、材料のタイプなどのような項目を有することができる。コンテキストのロウは、ソフトウェアが、コンテキストを知ることができるようにどんな関連した生のロウよりも前に作られる。運転のほかの関連した属性は、前記属性テーブルに記憶され、運転ＩＤのようなパラメータを用いて結合される。

さらに、前記ＡＰＣシステムは、運転のためにセンサのための設定と操作パラメータを有することができる装置運転テーブルを有することができる。例えば、この装置運転テーブルは、また生の運転データにどんな観測が書かれるのかを記述するヘッダデータを有することができる。これは、設定と収集されたデータが、運転から運転で変えられることを可能にする。

加えて、前記ＡＰＣシステムは、生の観測を収集し発行するために用いられることができる生の運転データテーブルを有することができる。例えば、ウエハの各々は、それに関連した生の運転データテーブルを有することができる。

生のセンサのモデルデータテーブルへの読み込みのマッピングを設定するために、モデルマップテーブルが、使われることができる。例えば、出力テーブルが、値を失うことなく完全なロウを持つように設定されることができ、内挿データもしくは、以前の観測の使用のような設定オプションがあり、出力を構成している間に用いられることができる。テーブルは、また属性テーブルに誰がマップを設定したのか、いつそれが直されたのかなどを記述する属性を有することができる。

また、前記ＡＰＣシステムは、モデルデータテーブル中のカラムを記述するために用いられることができるモデルカラムテーブルを有することができる。例えば、データは、新しいモデルデータテーブルを動的につくるために用いられることができる。モデルデータテーブルは、モデル解析のために入力と出力とのデータを保持するために動的に作られたテーブルであることができる。テーブルの作成と数は、データマップテーブルをモデル化するためにロウにおいて設定されることができる。

前記ＡＰＣシステムは、また運転サマリ情報を有する運転サマリテーブルを有することができる。例えば、運転サマリテーブルは、運転ＩＤと運転タイプと値の名前と開始ステップと終了ステップと値の最小と値の最大とのような情報を有することができる。

前記ＡＰＣシステムは、また警報情報（すなわち、タイムスタンプ、警報コード、記述など）を有することができる少なくとも１つの警報テーブルを有することができる。

多変量解析モデルテーブルも、与えられることができる。例えば、このテーブルと関連するテーブルとは、Ｓｉｍｃａ−Ｐのような多変量モデリングアプリケーションの出力をパーシング処理することにより埋められることができる。設定ダイアローグは、ユーザに、パーシング処理されることができない、もしくは計算されることのできないデータ項目をプロンプトで指示をだして得るために用いられることができる。

前記ＡＰＣシステムは、システム操作の間に用いられる多くのアプリケーションを有することができ、このアプリケーションは、ツールＡＰＣマスタアプリケーションとＡＰＣ警報アプリケーションと１つまたはそれより多くのセンサインターフェースアプリケーションとＡＰＣデータベース管理サポートアプリケーションとＡＰＣデータ収集サポートアプリケーションとＡＰＣイベント管理サポートアプリケーションとプローブインターフェースアプリケーションとＡＰＣプロセスチャンバサポートアプリケーションとＡＰＣストラテジ選択アプリケーションとツールインターフェースアプリケーションとウエハデータアプリケーションとＡＰＣプラン実行アプリケーションとを有することができる。

加えて、前記ＡＰＣシステムは、ソフトウェアがインストールされているネットワーク上のいかなる場所からも実行されることができるデバッグと診断のアプリケーションを有することができ、これらのアプリケーションは、前記ＡＰＣシステムを検査し、診断し、デバッグし、並びに／もしくはこのＡＰＣシステムを変更するために用いられることができる。例えば、前記ＡＰＣサーバ１６０は、ファイルのメインテナンスを実行することができる。この代わりに、ワークステーションが、ファイルのメインテナンスを実行する。ログファイルは、前記データベース１９０に記憶されることができ、前記ＡＰＣシステムの問題の解決をするために用いられる。これらのファイルは、限られただけの時間の間、保持されることができる。システムエラとアプリケーションの故障の他の原因は、ログファイルの中で見つけられることができる。例えば、ログファイルは、システムエラメッセージとイベントタイミングとのような情報を有する警報ログと、イベント情報を有するツールイベントログと、前記ＡＰＣサーバ上での活動の履歴を有するオペレーティングシステムログとを有することができる。これらのログは、メインテナンスが最小になるように、サーキュラログ（一度ファイルがあるサイズに達すると一番古いデータを消去）のために設定されることができる。

また、前記ＡＰＣシステム１４５は、警報とイベント情報とを顧客の製作実行システム（ＭＥＳ）に与えることができるインターフェースアプリケーションを有することができる。

前記インターフェースサーバのメッセージ構成成分は、アプリケーション間の接続とメッセージの流れとを与えるために用いられることができる。例えば、アプリケーションモジュールとユーザインターフェースとは、データハブ中の情報にアクセスし更新するためにＳＱＬメッセージを用いることができる。

ツールＡＰＣマスタアプリケーションは、例えば、シャットダウン時にクリーンアップするために用いられることのできるシャットダウンオールの方法と、パラメータを初期化するために使われることができる初期化の方法と、ロジック管理プロセスの優先度を押し上げるために使われることができるＬｇｍｇｒブーストの方法と、データベースからシステム設定をロードするために使われることができる設定ロードの方法と、データベースからシステム状態変数をロードするために用いられることができる状態ロードの方法と、データベースにシステム設定をセーブするために用いられることができる設定セーブの方法と、前記ＧＵＩの時間変数を更新するために用いられることができるＧＵＩ時間更新の方法とを有する一組の方法を有することができる。

加えて、ツールＡＰＣマスタアプリケーションは、メモリ変数を用いることができ、前記ＡＰＣシステムのログリクエストレコードであるシステムログリクエストと、属性データベーステーブルに入り属性データテーブルから出てくるデータを保持する記録フォーマットである属性フォーマットレコードとの、前記ツールＡＰＣマスタアプリケーションと関連付けられた２つのレコードフォーマットがあることができる。

加えて、前記ＡＰＣシステム１４５は、このシステムからのＡＰＣとツールの警報を処理することができるＡＰＣ警報アプリケーションを有することができる。このＡＰＣ警報アプリケーションは、ＧＵＩディスプレイのために警報のテキストを保持するために用いられることができる少なくとも１つのメモリ変数を用いることができる。警報ファイルの方法が、ＡＰＣとツールの警報をデータベースの警報テーブルに書き込むために用いられることができる。この警報ファイルは、警報メッセージとイベントＩＤとの２つのパラメータを有することができる。この方法は、警報ＴＣＬＡＰＩを呼び出し、警報情報を渡している。この警報は、警報管理手続きを実行することにより処理されることができる。例えば、警報が起こったとき、電子メイルが、送られることができ、エントリは、持続性データベースの警報テーブルに書き込まれることができ、警報のテキストは、ＧＵＩの状態ディスプレイを用いて表示されることができる。また、ユーザは、警報ログＧＵＩスクリーンを通して警報の内容を見ることができる。

また、前記ＡＰＣシステム１４５は、１つかそれより多いセンサインターフェースアプリケーションを有することができる。例えば、少なくとも１つのＯＥＳデータレコーダが、各々の光学放出センサからのデータを記録するために用いられることができ、プロセスツールと関連付けられた各々のＯＥＳセンサのためのＯＥＳ装置インターフェースがあることができる。データを収集しデータをファイルに書くサンプルを得る方法と、スタートアップ時に走る初期化する方法と、センサを記録のために設定し書き込むためにファイルを開くセットアップの方法と、ＯＥＳ装置の接続をはじめるデバイス開始の方法と、データの記録を開始する記録開始の方法と、ＯＥＳ装置の接続を終了しコントロールレジスタに書き込みファイルを閉じるデバイス終了の方法とを有するＯＥＳデータレコーダアプリケーションと関連付けられた多くの方法があることができる。

加えて、ＡＰＣデータベース管理アプリケーションが、前記ＡＰＣシステム１４５の一部として、日常のデータのバックアップと、データのアーカイブと、ＡＰＣとＳＰＣＤＢデータベースの中のデータ消去とを実行するために与えられることができる。（すなわち、バックアップとアーカイブは、圧縮されジップされている）
例えば、ＢＡＤＲＲユーティリティプログラムが、チャートのヒストリカルデータポイントをバックアップしパージするために設定されることができる。ＢＡＤＲＲＧＵＩモジュールは、どのようにデータが処理されるべきかを決定するために、ユーザが、向かう幾つかのＧＵＩパネルを有することができる。バックアップ機能が、どのデータがバックアップされるべきか決定するために用いられることができる（バックアップデータは、運転されないウエハのデータの設定データからなりたっている）。アーカイブ機能は、アーカイブされるべきデータを決定している。消去機能は、どのデータが消去されるべきか決定し、それらを一度に１つの運転ＩＤごとに処理する。データは、アーカイブされたあとだけ消去されることができる。リストア機能は、記憶されている現在のファイルをバックアップディレクトリに持っていき、それを作業ディレクトリにアンジップし、そのファイル名にしたがって各々のテーブルをリストアすることができる。リトリーブ機能は、アーカイブディレクトリに記憶された選択されたファイルを作業ディレクトリに持っていき、各々のテーブルをそのファイル名にしたがってリトリーブすることができる。リインデックス機能は、テーブルとインデックスとの上の現在の統計を集めることができる。この機能は、最適化プログラムに、データをリトリーブする時に最良のアクセスプランを決定するために用いる最も正確な情報を与えている。リオーグ（reorg）機能は、細分化されたデータを消去するためにロウを再構築し、情報を構成することによりテーブルを再構成している。このリオーグ機能は、前記ＡＰＣシステムが、データを集めていないときだけ実行されることができる。

ＡＰＣデータ収集サポートアプリケーションも、前記ＡＰＣシステム１４５の中に与えられることができる。このＡＰＣデータ収集サポートアプリケーションは、ゲットロストデータ機能とゲットウエハデータ機能とセットアップセンサ機能とスタートセンサ機能とストップセンサ機能とロードデフォルトプラン機能との少なくとも１つを有する多くの方法を有することができる。

前記ＡＰＣシステム１４５において、ＡＰＣイベント管理サポートアプリケーションも、与えられることができる。このＡＰＣイベント管理サポートアプリケーションは、イベントに基づいて方法をディスパッチングするために用いられることができる。このＡＰＣイベント管理サポートアプリケーションは、アクティブイベントの方法とファイルレディの方法とアラームの方法とロットエンドの方法とロットスタートの方法とレシピエンドの方法とレシピスタートの方法とＲＦオフの方法とＲＦオンの方法とウエハインの方法とウエハアウトの方法との少なくとも１つを有する多くの方法を有することができる。さらに、プローブインターフェースアプリケーションが、前記ＡＰＣシステムの一部として与えられることができる。このプローブインターフェースアプリケーションは、プローブとセンサインターフェースの間の連絡を与えるために用いられることができ、ＲＳ−２３２上の独占のテキストベースのプロトコルを用いることができる。

例えば、ＳＣＮｘ＝ｆｒｅｑコマンドが、プローブのセットアップの間に出されることができ、イベント中のウエハによってトリガされることができる。変数ｘは、０から１６の範囲のインデックスナンバであることができる。周波数は、ヘルツで特定されることができる。記録は、レシピのスタートイベントが受け取られた時、始まることができる。この時点で、ＳＣＮコマンドが、ある固定された期間に出されることができ（すなわち、サンプルの間の時間）、コマンドの値は、レジスタに記憶されることができる。前記ＳＣＮコマンドが出されると、プローブは、セットアップコマンドで特定された各々の周波数に対して一連のデータを返すことができる。各々の一連のデータは、周波数と時間と状態と電圧と電流と位相とインピーダンスとを有することができる。

ＡＰＣプロセスチャンバサポートアプリケーションも、前記ＡＰＣシステム１４５に与えられることができる。このＡＰＣプロセスチャンバサポートアプリケーションは、ツールエージェントからイベントを受け取り、グローバルメモリを更新するレシーブツールイベントの方法と、プロセスチャンバのための状態変数を更新するアップデートステートの方法とを有する多くの方法を有することができる。このＡＰＣプロセスチャンバサポートアプリケーションは、プロセスチャンバの状態を記述するために用いられるチャンバ変数と、現在のロットの運転を記述するために用いられるカレントロット変数と、運転ＩＤの一部で各々の時に増加する運転ＩＤカウンタ変数とを有する多くのメモリ変数を有することができる。

また、前記ＡＰＣシステム１４５は、ツールインターフェースアプリケーションを有することができる。このツールインターフェースアプリケーションは、ツールのインターフェースとファイル転送と一般的な状態とを管理することができる。例えば、ツールインターフェースアプリケーションは、前記ツールからイベントＩＤを取り込むチェンジイベントの方法と、装置のインターフェースにより呼び出されるデバイスフェイルドの方法と、装置のインターフェースにより呼び出されるデバイスリカバリの方法と、前記ツールからアクティブなイベントを受け取るアクティブイベントの方法と、前記エージェントのコミュニケーションが失われたときに走るエージェントダウンクリーンアップの方法と、前記エージェントが失敗したかどうかを見るためにアクティブなフラグの状態を検査するチェックアクティブの方法と、固有の方法にイベントをディスパッチングするイベントディスパッチャの方法と、新しい求められていないイベントが前記ツールエージェントから送られてきたときにトリガされるイベントレシーバの方法と、レコードサイズが変化したときにレコードサイズを見つけるゲットツールレコードサイズの方法と、前記ツールからトレースファイルをダウンロードするゲットトレースデータの方法と、前記ツールにコミュニケーションを始めるためにクライアントエージェントをダウンロードするスタートエージェントの方法と、前記エージェントはもちろんエージェントクライアントも停止するストップエージェントの方法とを有する複数の方法を有することができる。

前記ＡＰＣシステム１４５は、またウエハデータアプリケーションを有することができる。このウエハデータアプリケーションは、シミュレートされたウエハのデータの動的な割り当てを与えることができる。このウエハデータアプリケーションと関連付けられたメモリ変数は、プールのアレイのサイズにセットされたウエハプールサイズ変数と、ウエハレコードのプールであるウエハプールアレイとを有する。このウエハデータアプリケーションと関連付けられた方法は、前記ツールインターフェースが止められた後にウエハをクリーンアップするクリーンアップの方法と、ウエハのプールを知られた状態に初期化するイニシャライズウエハの方法とを有する。

加えて、前記ＡＰＣシステム１４５は、ＡＰＣストラテジ選択アプリケーションを有することができる。このＡＰＣストラテジ選択アプリケーションは、各々のチャンバにとってアクティブなストラテジの名前を有することができる。例えば、このＡＰＣストラテジ選択アプリケーションは、どのストラテジを実行するかを決定するコンテキストマッチングのような方法を用いることができる。コントロールストラテジは、コントロールストラテジの名前を特定するか、コントロールストラテジをダウンロードすることにより、ホストコンピュータにより選ばれることができる。

前記ＡＰＣシステムの運転は、コンテキストにより駆動されているストラテジとプランとを用いて確立されることができる。ストラテジは、前記ＡＰＣシステム上で一組のシーケンスの間に何が起こるべきかを定義するためにもちいられる。この組のシーケンスは、ロットかバッチかウエハかレシピか一組の機械の活動かと関連付けられることができる。ストラテジは、プロセスとプリプロセスとポストプロセスの活動の組み合わせを有することができる。ストラテジの各々は、複数のプランを有することができる。プランの運転コントロールかプランのセットは、コントロールジョブと呼ばれることができる。

ストラテジは、イベントに基づいて作動され、無効にされる所定のスクリプトであることができる。例えば、コントロールジョブは、与えられたコンテキスト（ロット、チャンバ、プロセスレシピなど）のためのプロセスチャンバ内でのウエハの運転のための一組のデータ収集と設定プランとを設定することができる。ストラテジは、ウエハのコンテキストによって決定された特定の振る舞いをもつことができる。多数のチャンバの上を走ることができる、ロットのコンテキストと関連付けられたストラテジは、各々のモジュールのためのプランを設定することができる。ストラテジのコンテキストは、高優先度のロットとチャンバの限定（qualification）運転と外来の材料の監視とチャンバの調節とロットナンバとレシピの名前とプロセスチャンバと組み合わせとのためにカスタマイズされることができる。

前記ＡＰＣシステム１４５は、さらにどのストラテジを実行するべきか決めるために用いられることができるＡＰＣプラン実行（ＰＥ）アプリケーションを有することができる。例えば、ストラテジは、あらゆる所定の時にアクティブであるべき一組のプランを記載することができ、イベントは、実行するべき特定のストラテジを決定するために前記ＰＥにより評価されることができ、作用は、プランの形式で実行されることができる。プランは、単一のウエハのためにおきる特定の実行であることができる。作用は、センサのセットアップを管理する所定のスクリプトか与えられたウエハに対するデータ収集とデータ解析かロットかウエハの運転のセットにより指定されることができる。

ＰＥアプリケーションは、多くのプランを同時に始めることができる。例えば、各々のチャンバに対して少なくとも１つのプランが、実行されることができ、各々のツールに対して少なくとも１つのプランが実行されることができる。プランは、チャンバクリーニングの間の時間と同じくらい長く続くことができ、もしくは、単一のウエハを実行する時間と同じくらい短く続くことができる。

図４は、本発明の実施の形態によるイベントコンテキストとストラテジとコントロールジョブとプランとのための例示的な関係のダイヤグラムを示している。内部と外部の両方のイベントは、前記ＡＰＣシステムに与えられ、適切にそれにしたがって実行されることができる。イベントをつくる各々のインターフェースにとって、イベントを受け取り、それらを伝えるシステムアプリケーションがあることができる。

図５は、本発明の実施の形態による単純化されたデータフローのダイヤグラムを示している。前記ツールとセンサとから関連するデータベースへのデータの流れが、図５に示されているように、単純化されたデータフローダイヤグラムによって表されることができる。図示された実施の形態において、矢印は、イベントを表し、各々の矢印は、イベントの名前によりラベルされることができる。この場合、時間は、ダイヤグラムの上からダイヤグラムの下に流れている。例えば、図５に示された単純化されたフローダイヤグラムは、初期化とロットのプロセスとデータベース管理との間の構成成分間のイベントとデータの流れを示すために用いられることができる。イベントは、プロセスと記憶のために直接前記インターフェースサーバに行くことができる。前記インターフェースサーバは、大局的な状態変数のテーブルを維持することができる。イベントと警報の各々は、対応する状態を更新するために用いられることができる。

図６は、本発明の実施の形態によるインターフェースサーバの例示的な簿ロックダイヤグラムを示している。図示された実施の形態において、プロセス間のコミュニケーションは、ディストリビューティッドメッセージハブ（ＤＭＨ）メッセージシステムを用いて実行されることができる。例えば、ＤＭＨシステムは、メイルボックスとして参照される名前のつけられたメッセージキューへの、そしてメイルボックスとして参照される名前のつけられたメッセージキューからのプレインテキストメッセージを利用することができる。メッセージが、特定のメイルボックスに到着する時に、コールバックロジックが実行されることができる。ＤＭＨシステムは、非同時性のメッセージとメッセージキューとをピーク負荷をならし、資源の負荷を減少させるために使うことができる。加えて、センサインターフェースとデータベースインターフェースとは、ＤＭＨメッセージシステムサーバの単純な単一スレッドのクライアントとして書かれることができる。

例えば、ツールに関連したアプリケーションが、１つもしくはそれより多くのプロセスツールのインターフェースとなるために用いられることができる。ツールアプリケーションは、ツールから発生するイベントのためのインターフェースとして使われることができるエージェントクライアントを有することができる。このエージェントクライアントは、イベントが、前記ツール上で走るツールエージェントから受け取られる時、イベントを処理することができる。このツールアプリケーションは、前記エージェントクライアントからの求められていないデータによりトリガされることができるイベントレシーバの方法を有することができる。データは、前記イベントレシーバに、レコードフォーマットに直接マップされることができる塊の形で来ることができる。加えて、前記イベントレシーバは、ツールレコードをプロセスチャンバ内のアレイのレコードにマップすることができ、ディスパッチイベントの方法を呼び出すことができる。このイベントは、それからストラテジとコントロールジョブアプリケーションに伝えられることができる。

イベントが、前記ＡＰＣシステムを伝えられていくと、オブジェクトのなかに状態を変えることによって反応できるものがある。例えば、ロット状態機械かバッチ状態モデルかが使われることができる。ロット状態機械は（ロットプロセスのために）オンになることができ、（ロットのアイドリングのために）オフになることができ、バッチ状態機械は、（バッチプロセスのために）オンになることができ、（バッチのアイドリングのために）オフになることができる。

加えて、ツール状態機械が用いられることができる。例えば、ツール状態は、ツールレディとツールランニングとツールポーズとツールストップとを有することができる。故障が検出された時は、前記ツールは、故障の深刻さに依存して休止されるか停止される。このツールが、休止されたとき、前記ＧＵＩ構成成分は、ＡＰＣのユーザが応答するべき次の行動の選択を表示するために用いられることができる。また、前記ＧＵＩ構成成分は、故障がトリガとなるツールの休止、可能な原因の上位５つのリストへと続くコントロールチャートを表示し、次の行動の選択を提供することができる。次の行動とは、すなわち、故障したウエハの生のデータを見る、故障したウエハのコントリビューションチャートを見る、現在の故障したウエハと同じレシピで処理されたウエハのサマリデータの履歴を見る、検索キーを入力することにより見られることができるデータを指定する、センサをチェックする、解析をスキップしてツールの休止をクリアする、解析をスキップしてメインテナンスのためにツールをオフラインにする、である。ＡＰＣユーザは、休止をクリアする決定をする責任を有する。

さらに、プロセスチャンバ状態機械が、各々のプロセスモジュール（図１ ＰＭ１２０）に対して確立されることができる。例えば、プロセスチャンバのオブジェクトは、使用法状態と使用中状態とレシピ状態との３つの状態変数を有することができる。例示のチャンバ状態は、「アイドリング」と「使用中」と「準備完了」と「プロセス」と「プラズマナットアクティブ」と「プラズマアクティブ」と「レシピ完了」とを有することができる。

一般的な場合に対して、データレコーダオブジェクトの各々は、センサのスタート時に可能にされ、ウエハの完了時にスイッチが切られている。いくつかの場合には、データは、ウエハの間に記録されることができる（環境データ、すなわちトランスファーチャンバ真空、温度、湿度など）。この場合、レコーダオブジェクトは、データをあるサンプルレートでウエハに関連付け、（設定可能な）異なるサンプルレートでマシンオブジェクトに関連付ける多数の出力を有することができる。

加えて、前記ＡＰＣシステム１４５は、ＡＰＣ機能性をもたらすために用いられるメインインターフェースとプロセスコントロールを記述し管理するオブジェクトとを有するコントロール実行構成成分を有することができる。結局、この構成成分は、コントロールストラテジを実行している。

一実施の形態では、少なくとも１つのアプリケーションが、Ｗｉｎｄｏｗｓ(登録商標)ＮＴのサービスとして実行するために設定されることができる。それ自体、このアプリケーションは、システムブートとともにユーザログインなしでスタートし、このアプリケーションは、ユーザがログオンしログアウトする間実行されつづけ、このアプリケーションは、ユーザのディスプレイと相互作用しないように設定されることができ、このアプリケーションは、ログインされているユーザのログオンアカウントと異なるセキュリティ保証のついた異なるログオンアカウントを用いることができる。

加えて、前記ＡＰＣシステム１４５は、ウィルス防御構成成分を有することができる。例えば、ウィルス防御ソフトウェアが、前記ＡＰＣサーバ１６０とクライアントワークステーション１７０との上にインストールされることができ、ＬＡＮ接続が、スケジュールを基礎とした更新を実行するために用いられることができる。

さらに、前記ＡＰＣシステム１４５は、１つもしくはそれより多くのＧＵＩスクリーンと結合されることができるオンラインヘルプ構成成分を有することができる。例えば、ヘルプスクリーンは、ユーザにアクセスすることができ、ヘルプファイルは、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）並びに／もしくはＨＴＭＬフォーマットで与えられることができる。

ＡＰＣシステムアプリケーションは、故障とサービスに関連した妨害に対して耐性がある。加えて、このアプリケーションは、セットアップと問題解決の能力を与える。例えば、妨害が起こったとき、前記ＡＰＣシステムアプリケーションは、妨害を検出し、データの損失を最小にするために正しい振る舞いを始める。このように、顧客が前記ＡＰＣシステムが、減少した機能性において作動している間に製品を製造する危険は、減少されることができる。

前記ＡＰＣシステムは、顧客（エンドユーザ）がツールとチャンバとセンサとを加えることを可能にする設定可能なシステムを用いて、実行されている。このＡＰＣシステムは、顧客がデータ管理アプリケーションをカスタマイズすることを可能にする開発環境と方法とを与えている。

ＴＥＬ Ｉｎｇｅｎｉｏ ＴＬＡＰＣソフトウェアは、数々の機能すなわち、故障の検出と分類（ＦＤＣ）、Ｅ診断サービスとラントゥラン（Ｒ−２−Ｒ）コントロールを与える。ＦＤＣは、現在のプロセスの結果をヒストリカルデータと比較することにより作用し、検出された故障のレベルに依存して通知と介入を発生している。Ｒ−２−Ｒは、プロセスレシピを調整し、プロセスモデルを長い時間維持するためにフィードフォワードとフィードバックの両方のコントロールループを与える。

図８は、本発明の実施の形態による半導体プロセスシステムにおけるプロセスツールを監視するためのフローダイヤグラムの単純化された図を示している。ソフトウェアと関連付けられたＧＵＩスクリーンは、システムの１つもしくはそれより多くのプロセスツールを監視するための単純でユーザに便利な手続きを与えている。手続き８００は、半導体プロセスシステムの中のプロセスツールによって実行され、各々の生産ステップのために実行されることができる。この代わりに、手続き８００は、半導体プロセスシステムにおけるプロセスモジュールによって実行される一組の生産ステップのために実行されることができる。生産ステップは、エッチングプロセスか蒸着プロセスか拡散プロセスかクリーニングプロセスか測定プロセスかトランスファープロセスか他の半導体製作プロセスであることができる。

８１０において、スタートイベントが、受け取られることができる。例えば、プロセスツールコントローラは、前記ＡＰＣシステムにスタートイベントを送ることができる。この代わりに、ホストのような他のコンピュータがスタートイベントを送ることができる。スタートイベントは、プロセスもしくはレシピステップが開始する時点であることができ、コンテキストベースであることができる。例えば、ウエハインとレシピスタートとプロセススタートとステップスタートとモジュールスタートとが、スタートイベントであることができる。また、ウエハがプロセスチャンバに入る時、スタートイベントが起こることができる。この代わりに、ウエハが、トランスファチャンバに入る時か、ウエハが、プロセスシステムに入る時か、データがホストもしくはＩＭから利用可能な時に、スタートイベントが起こることができる。

コントロールストラテジが、プロセスモジュール並びに／もしくはプロセスツール上の一組のシークエンスの間に何が起こるのかを定義している。コントロールストラテジは、単一のウエハか単一のツールか単一のロットかツール活動の組み合わせのための一組のシークエンスを定義することができる。コントロールストラテジは、プロセスの活動の組み合わせを有することができ、コントロールストラテジは、コンテキストと関連付けられることができる。望ましくは、コンテキスト情報が、ある操作と他の操作を関連付けるために用いられている。特に、このコンテキスト情報は、プロセスのステップもしくはレシピと１つもしくはそれより多くのストラテジ並びに／もしくはプランを関連付けている。

８１５において、コントロールストラテジが、実行されている。前記コントロールストラテジは、ユーザが、いつコントロールストラテジが選択されるのかに影響を与える１つもしくはいくつかのコンテキスト項目を定義することができる。コントロールストラテジは、プロセスモジュールのレベルではなく、システムかツールのレベルで定義されることができる。Ｒ２Ｒコントロールは、たいてい多くのＩＭとプロセスモジュールとを通るウエハを有する。一つのコントロールストラテジが、あるウエハのために実行される。あるウエハのコンテキストが、多くのコントロールストラテジに整合するなら、第一の整合しているコントロールストラテジが選ばれることができる。

コントロールストラテジは、「ウエハごと」を基礎として、評価されることができる。コントロールストラテジは、有効か無効として指定されることができる。コントロールストラテジは、無効にされている時実行されない。コントロールストラテジは、シミュレーションとして指定されることができ、その場合には、全てのそのコントロールプランは、シミュレーションモードにおいて実行されることができ、これは、前記ツール上でレシピが変化されないことを意味している。

前記コントロールストラテジは、多くのコントロールプランを有することができる。このことは、あるウエハのためのいくつかのコントロールモデルの実行を可能にする。しかしながら、単一のコントロールプランは、実際に前記ツール上でレシピの変化を起こすコントロールプランとして指定されなければならない。その他のコントロールプランは、シミュレーションモードで実行されることができる。

コンテキストに敏感なコントロールプランは、プロセスシステムまたはツールがウエハを処理している時にどんなコントロール活動がとられるべきかを定義している。例えば、コントロールプランのコンテキストは、単一のプロセスシステムのレシピだけの選択に限定されることができる。

コントロールプランの情報は、前記メモリ内テーブルとＤＢ２の内部とに記憶されることができる。このコントロールプランは、Ｒ２Ｒコントロールを達成するために用いられることができるモデルを有することができる。システムレシピと他のコンテキストは、親コントロールストラテジから受け継がれる。このコントロールプランは、統合セクションとコントロールセクションとアルゴリズムセクションとを有することができる。この統合セクションは、どのモジュールが、コントロールデータのソースで、Ｒ２Ｒコントロールのターゲットであるのかを決定することができる。前記コントロールセクションは、多くのフィードフォワード変数のサポートを与えることができる。前記アルゴリズムセクションは、異なるタイプのコントロールモデルを与えることができる。

コントロールプランは、前記コントロールモデルを有することができる。多くのコントロールモデルが同時に実行される時、前のモデルからの出力は、第2のモデルの入力として使われることができる。コントロールモデルからの出力が、同じ実行サイクルの前のコントロールモデルによって設定されたパラメータを変化させる場合、警報メッセージが生成されることができ、新しい設定が使われている。プロセスモジュールは、１つもしくはそれより多くのコントロールプランを有することができ、一つのコントロールプランは、プロセスモジュールの、もしくは他のプロセスモジュールの、他のコントロールプランにデータを与えることができる。

前記コントロールプランは、実行されるべきコントロールモデルを選択するのに必要な情報を有する。コントロールプランは、１つそして１つだけのプロセスモジュールと関連付けられている。そのため、コントロールされている各々のプロセスモジュールのためのコントロールプランが必要ある。

前記コントロールプランは、コントロールモデルが使うことができる最小そして最大の範囲を記述している。コントロールモジュールの範囲は、重なることができる。ユーザによって、最小並びに／もしくは最大の範囲が、入力されていない時、欠けている範囲は、制限されないことができる。

コントロールプランは、一般にプロセスモジュールとレシピの組み合わせとに関連している。ツールが、多くのシステムレシピが、同じプロセスレシピを有することを可能にする時、多くのコントロールストラテジは、コントロールプランを共有することができる。異なるプロセスモジュールレシピに対して異なるプロセスモジュールレシピの制限があることができる。各々のコントロールプランは、前記ツールに送られるレシピの変更のために用いられるレシピの制約を独立して設定することができる。

予測モデルは、実験を基礎にしたモデルか、理論を基礎にしたモデルを表現することができる。予測的な指数的に重みのつけられた動平均（Exponentially Weighted Moving Average）（ＥＷＭＡ）の方法は、いくつかの制限のある、理論を基礎にした予測的な方法の１つである。部分最小二乗（Ｐａｒｔｉａｌ Ｌｅａｓｔ Ｓｑｕｑｒｗｓ）（ＰＬＳ）回帰法が、実験に基づいたモデルを生成するために用いられることができる。モデルのフィルタの実行は、モデルの予測される誤差を正すために必要とされることができる。

アウトライアの排除フィルタは、前記コントロールプランの中で定義されることができる。ユーザは、コントロールを実行するために必要とされる点の最少数を設定することができる。点の最少数が、与えられていないか、点が、フィルタリングのために消去されている時、警報がランタイムに生成される。

最小のそして最大のコントロール範囲は、前記コントロールプランに用いられている各々のコントロールモデルのために指定されることができる。この最小値が、指定されていない時、前記コントロールモデルのための最小の範囲はない。この最大値が、指定されていない時、前記コントロールモデルのための最大値の範囲はない。１つかそれより多くのコントロールモデルが、整合し、選択基準を満たす。１つ以上のコントロールモデルが整合するなら、全ての整合コントロールモデルが、ランタイムに用いられる。選択基準をみたすコントロールモデルが１つもない場合には、ランタイム警報が、生成され、プランは、モジュールが休止されるべきか、「ヌル」レシピが用いられるべきか、ノーマルレシピが用いられるべきかを決定する。

コントロールされるべき新しいウエハが、前記システムに入る時、システムレシピとウエハコンテキストとに整合する前記コントロールレシピが、選択される。計測データが受けとられる時、第１の整合コントロールストラテジが、この計測データを処理し、あらゆるアウトライアのデータ点を、選択されたアウトライアの方法（selected outlier method）を用いて除去することができる。前記ＡＰＣシステム（Ｒ２Ｒコントローラ）は、それからこの計測データに対応するコントロールモデルを選ぶことができる。前記コントロールモデルは、その時実行され、前記ツールに送られるパラメータの設定を計算している。これらの設定は、この時前記ツールに送られ、ＤＢ２にセーブされ、このウエハのために用いられる設定としてフラグを立てられることができる。それから、他の整合コントロールストラテジが、処理されることができ、その結果は、ＤＢ２にセーブされるが、前記ツールには送られない。

処理の間に、例外が見つかった時は、警報が、生成され前記ＡＰＣシステム（ＴＬコントローラ）に送られることができる。

例えば、コントロールストラテジは、コントロールストラテジＡ１と名づけられることができ、異なった時間に実行される４つのシークエンスを有することができる。シークエンス１は、第１の計測レシピを用いて計測モジュールにおいて実行されるハードマスクＣＤプロセスであることができ、シークエンス２は、第１のエッチングレシピを用いてプロセスモジュールの中で実行されるハードマスクエッチングプロセスであることができ、シークエンス３は、第２の計測モジュールを用いて計測モジュールで実行されるポリＣＤプロセスであることができ、シークエンス４は、第２のエッチングレシピを用いてプロセスモジュールで実行されるポリエッチングプロセスであることができる。

８２０において、データ収集（ＤＣ）ストラテジが、実行されている。ＡＰＣシステムは、ＤＣプランフィルタを利用し、プロセスコンテキストに基づいたサマリ計算を実行して、前記コントロールストラテジのために定義されたＤＣストラテジを実行している。このプロセスコンテキストは、実行されている生産ステップ並びに／もしくは、監視されているチャンバに依存することができる。コンテキストは、どのストラテジ並びに／もしくはプランが、特定のプロセスレシピのために実行されるのかを決定している。例えば、レシピがコンテキスト用語「ハードマスクＣＤ」を有するなら、「ハードマスクＣＤ」のコンテキスト用語と関連付けられたＤＣストラテジは、プロセスツールが、コンテキスト用語（要素）「ハードマスクＣＤ」を有するあらゆるレシピを用いてプロセスを実行する時に、実行されることができる。

ランタイムの間、スタートイベントは、前記ＡＰＣシステムに現在のコンテキストのデータを調べることと、どのストラテジがコンテキストに整合するのかを決定することと、どのプランを実行するのか決定することと、これらの対応するスクリプトをもたらすこととを引き起こすことができる。コントロールストラテジレコードは、ウエハラン、ツール、チャンバ、レシピ、スロットなどのようなコンテキストに整合する情報を有することができる。例えば、前記ＡＰＣシステムは、ランタイムコンテキスト情報とストラテジのデータベースを比較し、ランタイムコンテキスト情報をストラテジのデータベースに整合しようと試みることができる。各々のコントロールストラテジは、ツールＩＤとロットＩＤとチャンバＩＤとカセットＩＤとスロットＩＤとウエハＩＤとレシピＩＤとコントロールジョブＩＤとプロセスジョブＩＤとスタートタイムとエンドタイムとステップナンバと状態とメインテナンスカウンタバリュとプロダクトＩＤとマテリアルＩＤとののコンテキスト情報の少なくともいくつかを有することができる。

前記プロセスコンテキストは、実行されているプロセスと監視されているツールとに依存していることができる。コンテキスト整合プロセスでは、検索順序が重要であることができる。例えば、この検索は、ＧＵＩテーブルの優先順位を用いることにより実行されることができる。検索は、ＳＱＬのステートメントを用いて実行されることができる。一度ストラテジが特定されると、センサプランとデータのプリプロセスプランと判断プランとを有するデータ収集プランが、自動的に決定される。データ収集プランＩＤとデータプリプロセスプランＩＤと判断プランＩＤとが「コントロールストラテジを実行する」モジュールに送られることができる。コンペアプロセスコンテキスト機能が実行されている時に整合モジュールが存在しないなら、ソフトウェアは、ツール状態ＧＵＩスクリーンの故障フィールドにエラーメッセージを表示し、ユーザが、間違いを正すことを可能にするためにポップアップウィンドが使われる事ができる。

コンテキストは、コンテキスト要素の組み合わせにより定義されることができる。例えば、所定の順序のコンテキスト要素のアレイであることができ、もしくは、コンテキストは、辞書の形式で名前を値にもつ対の組であることができる。

加えて、前記ＤＣストラテジと関連付けられたプランが、実行されている。データ収集プランとデータプリプロセスプランと判断プランとの少なくとも１つが実行されることができる。加えて、センサプランとパラメータ選択プランとトリムプランとがまた実行されることができる。高品質な製品を生産する製造実行の間に集められたデータは、「よいツールの状態」のデータを確立するために用いられることができ、集められたデータは、続いてツールが正しく実行しているのかどうかをリアルタイムに決定するためにこのベースラインデータと比較されることができる。

コントロールストラテジは、品質管理（ＱＣ）テストの一部としてツールヘルス状態を決定するために確立されることができる。コントロールストラテジとこれに関連したプランは、システムもしくはプロセスツールのようなシステムの部分が適当に動作していることを確認するために実行されることができる。例えば、ツールヘルスコントロールストラテジとその関連したプランは、所定の時間にもしくはユーザがスケジュールしたときに実行されることができる。ツールヘルスコントロールストラテジとその関連したプランが実行されている時、診断のウエハデータが収集されることができる。診断かダミか製品かテストかのウエハが、プロセスされることができ、コンテキストは、ツールかモジュールかセンサの診断であることができる。

コントロールストラテジとその関連したプランは、シーズニングに関連したプロセスのようなプロセスモジュール準備プロセスのために確立されることができる。例えば、クリーニングプロセス（すなわちウェットクリーン）の後、シーズニングに関連したストラテジとプランとレシピとを用いて、多くのダミのウエハがプロセスされることができる。ユーザは、ＡＰＣシステムの部分であるストラテジとプランとを用いることができ、もしくは、ユーザは、前記ＡＰＣシステムを用いて簡単にそして早く新しいシーズニングに関連したコントロールストラテジを開発することができる。ユーザは、どのシーズニングレシピが最良の検出力をもつのかを決定するために、様々なシーズニングデータ収集プランとレシピとの組を試すことができる。これらのシーズニング運転は、プロセスとツールのモデリングをさらによくするために用いられることができる。

コントロールストラテジとその関連するプロセスは、チャンバフィンガプリンティングのような、プロセスモジュール特徴づけプロセスのために確立されることができる。例えば、メインテナンスプロセスの後で、多くのダミウエハが、フィンガプリンティングに関連したデータ収集のプランとレシピを用いて、プロセスされることができる。これらのフィンガプリンティング運転からのデータは、プロセスとツールのモデリングをさらによくするために用いられることができる。このフィンガプリングティングのデータは、ウエハ上のプロセスの結果に影響を与える重大なチャンバの不整合を最小化する最良のモデルを特定するための解析のために用いられることができる。

静的な並びに動的なセンサは、データ収集プランが実行されている時に、セットアップされる。データ収集プランは、センサセットアッププランを有することができる。例えば、センサの開始と終了の時間が、このセンサセットアッププランにより決定されることができる。動的なセンサにより必要とされる動的な変数は、このセンサセットアッププランにより決定される。レシピスタートイベントは、センサに記録の開始を伝えるために用いられることができる。イベントにおけるウエハが、センサをセットアップするために用いられることができる。レシピストップイベントもしくはウエハアウトイベントは、センサに記録の停止を伝えるために用いられることができる。

収集されるデータと使われているセンサとは、前記ＤＣストラテジコンテキストに依存している。望ましくは、製品のウエハと製品ではないウエハとのために異なったセンサが用いられることができ、異なったデータが収集されることができる。例えば、ツール状態データは、製品のウエハのために収集されたデータの小さな部分であることができ、ツール状態データは、非製品のウエハのために収集されたデータの大きな部分であることができる。

前記データ収集プランは、またスパイクの計測とステップのトリミングと閾値と
値のクリップリミットとに関して期待された観測パラメータがどのように処理されるべきかを確立するデータプリプロセスプランを有する。

データプリプロセスプランが、実行されている時、生のデータから時系列のデータが生成されデータベースにセーブされることができ、ウエハのサマリデータが、この時系列のデータから生成されることができ、ロットサマリデータが、このウエハのデータから生成されることができる。データ収集は、ウエハがプロセスされている一方で、実行されることができる。ウエハがこのプロセスステップから出ると、データプリプロセスプランが、実行されることができる。

データ収集プランは、所望のデータを集めるためにユーザによって設定されるリユーザブルなものである。このデータ収集プランは、１つもしくはそれより多い別々のプロセスモジュール上の１つもしくはそれより多いセンサの設定からなっている。このプランは、また関連するセンサによって収集されるべきデータ項目の選択と、データ項目のどれがセーブされるべきかとを有している。

センサは、装置か、道具か、プロセスツールか、プロセスモジュールか、センサか、プローブか、観測データを収集するかソフトウェアのセットアップの相互影響を必要とする他のものかであることができ、もしくは、システムソフトウェアによりまるでセンサであるかのように取り扱われることができる。例えば、プロセスツールとプロセスモジュールとは、あたかもそれらがデータ収集プランにおけるセンサであるかのように扱われることができる。

同じセンサタイプのいくつかの例が、ツール上に同時に設置されることができる。ユーザは、各々のデータ収集プランのために用いるために特定のセンサを選ぶことができる。

システムで収集されたデータは、一組のステップを通してリアルタイムのセンサの収集とデータベースの記憶との間を流れている。収集されたデータは、リアルタイムメモリＳＱＬデータベースを有することができるインターフェースサーバに送られることができる。前記インターフェースサーバは、前記ＡＰＣシステムのプランを通してユーザによって定義されたさまざまなアルゴリズムにより、もしくは、ユーザによって定義されたスクリプトにより、処理されるべきデータの物理的な位置を与えている。

前記ＡＰＣシステムは、各々のプロセスモジュールに対して独立のデータ収集モードとセットアップモードを与えている、すなわち、各々のプロセスモジュールは、いかなる他のプロセスモジュールからも独立であり、一つのプロセスモジュールのセットアップは、他のプロセスモジュールのデータ収集を中断しない。このことは、半導体プロセスシステムの非生産的な時間の量を最小にしている。

ＤＣストラテジが、判断プランを有している時、その判断プランは実行されている。この実行は、規則を基準にしており、ＳＱＬのステートメントを有している。スタートイベント判断プランは、「スタートイベント」が起きたあとに、実行されることができ、エンドイベント判断プランは、「エンドイベント」が起きたあとに実行されることができる。例えば、スタートイベント判断プランが、コントロールストラテジと関連付けられている時、それは、ウエハインイベントかプロセススタートイベントか、レシピスタートイベントかのようなスタートイベントの後で，実行されることができる。スタートイベント判断プランは、ツール状態監視システムの警報管理部分の部分であることができる。

スタートイベントの後で警報が起こる（すなわち、故障が検出される）と、コントロールストラテジと関連付けられた判断プランが、以下のような行動をとるために介入プランにメッセージ並びに／もしくは指示を送ることができる。すなわち、状態スクリーンの上に故障メッセージを表示する、故障メッセージをログファイルに書く、次のウエハは休止のメッセージを送る、次のロットは休止のメッセージを送る、前記ツールに警告メッセージを送る、そして、ツールの所有者に電子メイルを送る、である。

判断プランは、独立に動作している。各々の判断プランは、他の判断プランの中の動作を知る必要がない。結果として、動作にいくらかの余剰分か不一致があることができ、介入プランは、いかなる問題も解決するために用いられることができる。ストラテジとプランの例示の関係のダイヤグラムは、図９と図１０に示されており、判断プランと介入プランの例示的な関係のダイヤグラムは、図１１に示されている。

８２５において（図８）、解析ストラテジが、プロセスコンテキストに基づいて、実行されることができる。このプロセスコンテキストは、実行されている生産ステップと監視されている前記ツールに依存することができる。コンテキストは、どの解析ストラテジ並びに／もしくはプランが、特定のプロセスステップのために実行されているか決定する。例えば、解析ストラテジを「ハードマスクＣＤ」のようなプロセスのタイプと関連付けるために、この解析ストラテジのためのコンテキストは、コンテキスト用語「ハードマスクＣＤ」を有するべきである。

解析ストラテジは、プランのホルダになることができる。解析ストラテジと関連したプランは、収集後にデータを「解析する」。

一実施の形態では、プロセスコンテキストは、解析ストラテジのリストとの比較をされることができる。例えば、ＡＰＣサーバ１６０（図１）は、「プロセススタート」イベントが起きる時、現在のプロセスのコンテキストをストリングとして得ることができる。このプロセスコンテキストは、解析ストラテジのリストと比較されることができ、固有のストラテジが、特定される。

このプロセスにおいて、検索の順番は、重要になりことができる。例えば、検索は、ＧＵＩテーブルの優先順位を用いて実行されることができる。検索は、ＳＱＬのステートメントを用いて実行されることができる。解析のストラテジが、特定されると、統計プロセスコントロール（ＳＰＣ）プランと、部分最小二乗（ＰＬＳ）プランと、主要成分解析（Ｐｒｉｎｃｉｐａｌ Ｃｏｍｐｏｎｅｎｔ Ａｎａｌｙｓｉｓ）（ＰＣＡ）プランと、多変量解析（ＭＶＡ）プランと、故障検出と分類（ＦＤＣ）プランと、判断プランとユーザ定義のプランとが自動的に決定される。解析プランＩＤと判断プランＩＤとは、「解析ストラテジを実行する」モジュールに送られることができる。コンペアプロセスコンテキスト機能が実行されている時、もし整合ストラテジが存在しないなら、ソフトウェアは、ツール状態ＧＵＩスクリーンの故障領域にエラーメッセージを表示することができ、正しいストラテジを使うためにポップアップウィンドがユーザに与えられることができる。

ランコンテキストに整合する多くの解析ストラテジがあることができ、これらの解析ストラテジは、特定の時に特定のプロセスツールに対して実行されている。ユーザは、特定のコンテキストの中でリストの上でストラテジを上か下に動かすことにより、ストラテジの順番を決めている。ストラテジが選ばれる時が来ると、ソフトウェアは、リストの一番上でスタートすることができ、ソフトウェアが、コンテキストによって決められた必要条件に整合する最初のストラテジを見つけるまでリストを下っていき、そのストラテジを最初に実行する。

加えて、各々の解析ストラテジにおいて多数のプランがあることができ、ユーザは、プランをリストの上で上か下に動かすことにより解析ストラテジの中でプランの順番を決めている。プランが実行される時が来ると、ソフトウェアは、リストの一番上でスタートしてリストを降りて行く。

コンテキストベースの実行を用いるための一つの方法は、コンテキスト整合を行うことであることができる。例えば、コンテキスト整合を実行する時、現在プロセスされているウエハのコンテキストが、用いられることができる。この代わりに、基板か、現在プロセスされているほかの半導体製品を用いられることができる。コンテキストが、決定されている時、そのコンテキストは、解析ストラテジのコンテキストと比較されることができる。コンテキスト整合が起こると、１つかそれより多くの解析ストラテジが実行されることができる。

解析ストラテジが、実行されると、解析プランと判断プランとが特定されている。例えば、少なくとも一つの解析ストラテジの動的なセットアップと実行を準備するコンテキスト整合する実行ソフトウェアモジュールが用いられることができる。一つの場合では、ウエハアウトイベントが、システムコントローラが現在のコンテキストのデータを検査し、どの解析ストラテジを実行するか決め、対応するスクリプトが関連するプランを決定するようにさせている。

加えて、前記解析ストラテジと関連のあるプランが実行されている。前記解析プランが、実行されると、ＳＰＣプランとＰＬＳプランとＰＣＡプランとＭＶＡプランとＦＤＣプランと判断プランとユーザ定義のプランとが実行されることができる。高品質の製品を製造している製造運転の間に収集されたデータの上での解析が、「良いツール状態」モデルを確立するために用いられることができ、収集されたデータは、続いてこのベースラインモデルを用いて，ツールが正しく実行しているかをリアルタイムで決めるために、解析されることができる。

解析ストラテジは、ツールヘルス状態を品質管理（ＱＣ）テストの一部として決定するために、確立されることができる。例えば、ツールヘルス解析ストラテジとそれに関連したプランとは、システムもしくはプロセスツールのようなシステムの部分が適当に作動していることを確認するために、実行されることができる。ツールヘルス解析ストラテジとその関連したプランとは、所望の時かユーザがスケジュールした時かに実行されることができる。ツールヘルス解析ストラテジとその関連したプランとが実行されている時、診断のウエハデータは、診断モデルを用いて解析されることができる。ここで、診断モデルは、ＳＰＣチャートとＰＬＳモデルとＰＣＡモデルとＦＤＣモデルとＭＶＡモデルとを有することができる。

解析ストラテジとその関連したプランとは、シーズニングに関連したプロセスのようなプロセスモジュールの準備プロセスのために確立することができる。例えば、クリーニングプロセス（すなわち、ウェットクリーン）の後で、多くのダミウエハから収集されたデータは、シーズニングに関連したモデルを用いて解析されることができる。ユーザは、前記解析ストラテジとプランと前記ＡＰＣシステムの部分であるモデルとを用いることができる、もしくは、ユーザは、簡単にそして早く新しいシーズニングに関連した解析ストラテジとプランとモデルとを、前記ＡＰＣシステムを用いて開発することができる。ユーザは、どのシーズニングに関連するモデルが最良の検出力を持つのかを決定するために、様々な解析モデルを試すことができる。これらのシーズニング運転からの解析結果は、コントロールストラテジとデータ収集プランとをさらに良くするために用いられる（フィードバック）ことができる。

解析ストラテジは、チャンバフィンガプリンティングのようなプロセスモジュールの特徴づけプロセスのために確立されることができる。例えば、メインテナンスプロセスの後で、多くのダミウエハから収集されたデータは、フィンガプリンティングに関連したモデルを用いて解析されることができる。これらのフィンガプリンティング運転からの解析結果は、さらにコントロールストラテジとデータ収集プランとを良くするために用いられる（フィードバック）ことができる。解析結果は、ウエハ上のプロセスの結果に影響を与える重大なチャンバの不整合を最小化する最良のモデルを特定するために用いられることができる。

ストラテジが、判断プランを有している時、その判断プランは、実行されることができる。その実行は、規則を基準としており、ＳＱＬのステートメントを有している。スタートイベント判断プランが、「スタートイベント」が起こった後で実行されることができ、エンドイベント判断プランが、「エンドイベント」が起こった後で実行されることができる。例えば、エンドイベント判断プランが、解析ストラテジと関連付けられている時、それは、ウエハアウトかプロセスストップイベントかレシピストップイベントかバッチアウトイベントかロットアウトイベントかのようなエンドイベントの後に、実行されることができる。エンドイベント判断プランは、ツール状態監視システムの警報管理部分の部分であることができる。

エンドイベントの後で、警報が起こる（すなわち、故障が検出された）時、解析ストラテジと関連付けられた判断プランは、介入プランに以下の動作をとるためにメッセージ並びに／もしくは指示を送ることができる。すなわち、状態スクリーンに故障メッセージを表示する、ログファイルに故障メッセージを書く、次のウエハ休止のメッセージを送る、次のロットは休止のメッセージを送る、前記ツールに警告のメッセージを送る、ツールの所有者に電子メイルをおくる、である。

判断プランは、独立に作動している。各々の判断プランは、他の判断プランにおける動作を知る必要がない。結果として、動作にいくらかの余剰分と不一致があることができ、介入プランが、あらゆる問題を解決するために用いられることができる。判断プランと介入プランとの例示的な関係のダイヤグラムは、図１０に示されている。

８３０において、警報が与えられるかどうか決定するために問い合わせが実行されている。警報が起こった時、手続き８００は、８５０に分岐している。警報が、起こらなかった時、手続き８００は、８３５に分岐している。

８５０において、介入プランが実行されることができる。この介入プランは、以下のプロセスを実行する。各々の判断プランからメッセージ（判断）を得る、様々な判断プランからの動作をカテゴリにわける、電子メイルとログにツールＩＤ、レシピＩＤ、レシピスタートタイムなどのようなプロセス状態を添付する、ログファイルとデータベースをセーブする、介入マネージャに固有のメッセージを送る。

介入ストラテジは、データ解析の結果としてユーザがとることを選ぶ動作として定義されている。例えば、これらの動作は、疑わしいウエハもしくはロットにフラグをたて、システムの所有者並びに／もしくはツールの所有者に知らせる、データを見直し決定をするために技術者を呼び出すか電子メイルを送る、データが見直され禁止が解除されるまで前記ツールがウエハをプロセスするのを禁止する、ツールを停止し、ツールを、残ったウエハをツールから取り除く「オフライン」にする、チャンバのクリーニングもしくはメインテナンスの手続きをトリガする、を有することができる。

望ましくは、それぞれのプロセスのステップの間、ただ一つの介入プランが実行している。介入プランの実行は、前記ＡＰＣサーバにおいて実行されている。例えば、介入プランは、判断プランから情報（ストリング）を得ることができる。この情報は、判断プランＩＤと示唆された動作のメッセージと故障メッセージと回復メッセージと動作のリストとを有することができる。

介入プランが実行される後、固有の動作についてのメッセージは、介入マネージャに送られる。例えば、動作の候補は、故障メッセージを状態スクリーンに表示する、次のウエハの前にプロセスを休止するメッセージを送る、次のロットの前にプロセスを休止するメッセージを送る、１つもしくはそれより多くのツールに休止もしくは停止のメッセージを送る、１つもしくはそれより多くのプロセスモジュールに休止もしくは停止のメッセージを送る、１つもしくはそれより多くのセンサに休止もしくは停止のメッセージを送る、システムの所有者、ツールの所有者、プロセスの所有者に電子メイルを送る、を有する。例えば、「停止」メッセージは、前記ツールにすでにツールの中にあるウエハのプロセスを続けることを伝えるために用いられることができ、「中断」メッセージは、ツールにツールの中のウエハをプロセスしないでウエハをキャリアに戻すことを伝えるために用いられることができる。

前記ＡＰＣシステムが、人間の介入なしで問題に介入し、問題に反応することができる場合もある。他の場合には、人間の介入が必要とされる。例えば、ユーザは、故障の特質を決定するために前記ＡＰＣシステムからのデータにアクセスすることができ、ユーザは、プロセスを続けるか終了するかを決定することができる。ユーザが、プロセスを終了する場合、ツールは、修理状態におかれることができる。ユーザは、ツールスクリーンからこれをトリガすることができる。例えば、ユーザは、チャンバウェットクリーンをすることを決定することができる。ウェットクリーンとチェックとプロセステストとの後で、プロセスは、次のウエハを再開することができる。

前記介入プランと解析プランとの実行の間、前記ＡＰＣシステムは、「ツールヘルス」チャートをユーザに表示している。例えば、このチャートは、マノメータのデータと質量流データと漏出量データとポンプデータとガスシステムデータとカセットシステムデータとトランスファシステムデータとを有することができる。このチャートは、１つかそれより多くのツールと１つかそれより多くのモジュールと１つかそれより多くのウエハと１つかそれより多くのプロセスステップの様々な時間のためのリアルタイムデータとヒストリカルデータとリアルタイムデータとヒストリカルデータの組み合わせとを表示することができる。

８３５において、プロセスが、終了したのかどうか決定するために問い合わせが実行されている。プロセスが、終了した時、手続き８００は、８４０に分岐し、手続き８００は終了する。プロセスが、終了していない時、手続き８００は、８１５に分岐し、手続き８００は、図８に示されているように続いている。

前記ＡＰＣシステムは、ツールが生産中でない時にツールのエラを検出し分類するためと、生産の間にツールのエラを検出し分類するためと、生産の間にツールのエラを検出し修正するためと、生産の前にツールのエラを予測するためと、生産の後にツールのエラを予測するためとに、用いられることができる。例えば、ツール状態監視システムは、自動セットアップ機能と自動チェック機能と自己チェック機能とのような多くの自己監視機能を実行するプロセスツールのインタフェースとなることができる。前記ツールが、マシンイベントをリアルタイムで送る時、前記監視システムは、データをリアルタイムで監視し、ツールが、データをノンリアルタイムで送る時、この監視システムは、データを、ツールがデータを送るとすぐに処理している（すなわち、マシンログに記憶されたデータを）。ツールデータは、漏出率チェックとゼロオフセットとヒストリイベントと警報情報とプロセスログデータとを有することができる。

前記ＡＰＣシステムは、一般的な故障検出と分類アプリケーションとチャンバフィンガプリンティングアプリケーションとシーズニング完了アプリケーションとコンシューマブルライフ予測とウェットクリーンサイクルアプリケーションと部品集合体のための診断アプリケーションとの中で用いられることができるストラテジとプランとベースラインモデルとを有することができる。加えて、前記ＡＰＣシステムは、プロセスツールからのＡＲＡＭＳ（Ａｕｔｏｍａｔｅｄ Ｒｅｌｉａｂｉｌｉｔｙ，Ａｖａｉｌａｂｉｌｉｔｙ ａｎｄ Ｍａｉｎｔａｉｎａｂｉｌｉｔｙ Ｓｔａｎｄａｒｄｓ）ログを収集し、解析することができる。このＡＰＣシステムは、このデータ収集をデータ収集プランの一部として実行している。

前記ＡＰＣシステムは、メインテナンスデータを収集し解析するためのストラテジとプランとを有することができる。前記データ収集プランは、消耗する部分とメインテナンスできる部分とを有する。例えば、これらの部分は、フォーカスリング、シールドリング、上側電極などを有することができる。メインテナンスデータストラテジとプランとは、ツールタイプとプロセスモジュールのタイプ並びに数などに依存している。デフォルトのメインテナンスデータストラテジとプランとは、前記ツールのセットアップとプロセスモジュールのセットアップと付加したセンサのセットアップ情報との一部として自動的に設定されることができる。ユーザは、デフォルトの設定を変えることができる。

前記ＡＰＣシステムは、ウエハからウエハの介入（intervention）かバッチからバッチからの介入かロットからロットからの介入を与えるために用いられることはできる。

前記ＡＰＣシステム１４５は、プロセスかウエハの何らかの特性に対する様々なセンサから収集されたデータを相関させるために用いられることができる解析とモデリングのアプリケーションも有することができる。例えば、アプリケーションは、多変量解析と部分最小二乗と主要成分解析とのために与えられることができ、解析とモデリングからの出力は、さらなる操作とＳＰＣ規則の評価（SPC rule evaluation）のためのＳＰＣチャート処理に与えられることができる。

解析とモデリングのアプリケーションは、異常性とウエハプロセスの間におこる正常なドリフトを見るために用いられることができる。異常性とドリフトが発見された時は、プロセスを通常のレベルの範囲に戻すためにプロセスを止めるか調節をするために処置を講じることができる。単一変数の監視と違って、故障が検出された後は、技術者は、現在のデータをモデルに持っていき、プロセスを制御下に戻すための誘導を得ることができる。ＡＰＣを用いて収集されたデータは、第三者のデータを使ってモデルを作るためのモデリングプログラムに直接インポートされることができる。このモデルは、このＡＰＣサーバに、故障検出とパラメータ予測とのためにエクスポートされることができる。

本発明の一態様において、状態データは、少なくとも１つのＧＵＩスクリーンを用いて表示されることができる。例えば、ツールの状態データは、ＧＵＩスクリーンを用いて図１２に示されているように表示されることができる。この代わりに、他の状態データは、他のＧＵＩスクリーンを用いて表示されることができる。一つのパネルには、各々のプロセスチャンバに対してこのスクリーン上に現在の情報が表示されることができる。チャンバの情報は、少なくとも一つのプロセスチャンバの名前を有することができる。現在プロセスチャンバ内のウエハについての情報は、個別の領域に表示されることができる。プランの情報は、現在のウエハ上で実行されているデータ収集プランの名前を有することができる。プロセスチャンバのパネルは、チャンバの重要な要素の状態を表示するためにテキストとグラフィクスを有する。

この文書で紹介されたソフトウェアと関連するＧＵＩとは、また多数の言語で利用できる。ＧＵＩスクリーンのレイアウトは、大局的なツールの設置において補助となるように設計されている。多くの国のユーザは、使うのも理解も容易なコンテキストベースのデータ管理ソフトウェアとであうだろう。システムがインストールされているか、システム設定が変えられている時は、ソフトウェアは、ユーザのために全ての必要なデータベースとファイルとをつくる。コンテキストベースのデータ管理ＧＵＩスクリーンは、システムと様々なレベルのエンドユーザの間の相互作用の手段を与えている。

ソフトウェアは、マシンタイプとハードウェアの設定とをインストール時に設定し、後に設定変更としてマシンタイプとハードウェアの設定とを行う。例えば、ユーザのプロファイルは、言語と、タッチスクリーンのみ、キーボードとマウスのサポート、日本語、台湾語、中国語、英語、フランス語、ドイツ語などの多言語、ユーザクラスシステム、クラスレベル、ＰＥ、ＥＥ、オペレータ、グレースケールとパターンのカラーブラインドもしくはカラー、左から右へのワークフロ、上から下へのワークフロ、アイコン、図、もしくは言葉、静的なタブのような態様を与えるビューのためのユーザの選択とのためにつくられることができる。

本発明の数多くの変更と変形が、上記の示唆の下で可能である。このため、添付された請求項の範囲内で，本発明は、ここで具体的に記述したのと違う方法で実施されることができることが理解されるべきである。

本発明の一実施の形態による、半導体製作環境におけるアドバンストプロセスコントロールド（ＡＰＣ）システムの例示的なブロックダイヤグラムを示す。 Ｔｏｋｙｏ Ｅｌｅｃｔｒｏｎ Ｉｎｃからのシステムの例示的なブロックダイヤグラムを示す。 本発明の一実施の形態による、ＡＰＣシステムのための単純化されたデータフロダイヤグラムである。 本発明の実施の形態による、単純化されたインターフェースのダイヤグラムを示す。 本発明の実施の形態による、イベントコンテキストとストラテジとコントロールジョブとプランとの例示的な関係のダイヤグラムを示している。 本発明の実施の形態による単純化されたデータフロダイヤグラムを示している。 本発明の実施の形態によるインターフェースサーバの例示的なブロックダイヤグラムを示している。 本発明の一実施の形態による半導体プロセスシステムにおけるプロセスツールのためにプロセスを監視するためのフロダイヤグラムの単純化された図を示している。 ストラテジとプランとの例示的な関係のダイヤグラムを示している。 ストラテジとプランとの他の例示的な関係のダイヤグラムを示している。 本発明の一実施の形態による判断プランと介入プランとのための例示的な関係のダイヤグラムを示している。 本発明の一実施の形態によるツール状態スクリーンの例示的な図を示している。

Claims (33)

1. 半導体プロセス環境におけるプロセスツールをコントロールするためのアドバンストプロセスコントロール（ＡＰＣ）システムであり、
   ＡＰＣに関連した複数のアプリケーションを与えるＡＰＣサーバと、
   このＡＰＣサーバに結合されたインターフェースサーバ（ＩＳ）と、
   前記ＩＳとＡＰＣサーバに結合されたデータベースと、
   前記ＡＰＣサーバに結合されたグラフィカルユーザインターフェース（ＧＵＩ）構成成分とを具備し、
   前記ＩＳは、プロセスツールに結合するための手段と、複数のプロセスモジュールに結合するための手段と、複数のセンサに結合するための手段とを有する、ＡＰＣシステム。
2. 前記複数のセンサに結合するための手段は、光学放射スペクトラム（ＯＥＳ）センサに結合するための手段を有する、請求項１のＡＰＣシステム。
3. 前記ＯＥＳセンサに結合するための手段は、ＴＣＰ／ＩＰ接続を有する、請求項２のＡＰＣシステム。
4. 前記複数のプロセスモジュールに結合するための手段は、光学データプロファイル（ＯＤＰ）モジュールに結合するための手段を有する、請求項１のＡＰＣシステム。
5. 前記ＯＤＰモジュールに結合するための手段は、ＯＤＰライブラリに結合するための手段を有する、請求項４のＡＰＣシステム。
6. 前記複数のセンサに結合するための手段は、電圧／電流（Ｖ／Ｉ）プローブに結合するための手段を有する、請求項１のＡＰＣシステム。
7. 前記Ｖ／Ｉプローブに結合するための手段は、ＴＣＰ／ＩＰ接続を有する、請求項６のＡＰＣシステム。
8. Ｅ診断システムに結合するための手段をさらに具備する、請求項１のＡＰＣシステム。
9. ファクトリシステムに結合するための手段をさらに具備する、請求項１のＡＰＣシステム。
10. アナログプローブに結合するための手段をさらに具備する、請求項１のＡＰＣシステム。
11. 前記アナログプローブに結合するための手段は、ＴＣＰ／ＩＰ接続を有する、請求項１０のＡＰＣシステム。
12. 前記複数のプロセスモジュールに結合するための手段は、エッチングモジュールに結合するための手段を有する、請求項１のＡＰＣシステム。
13. 前記複数のプロセスモジュールに結合するための手段は、蒸着モジュールに結合するための手段を有する、請求項１のＡＰＣシステム。
14. 前記複数のセンサに結合するための手段は、ディストリビューティドメッセージハブ（ＤＭＨ）クライアントを形成するセンサレコーダベースクラスに結合するための手段を有する、請求項１のＡＰＣシステム。
15. 前記プロセスツールに結合するための手段は、前記プロセスツール内のツールエージェントと、前記ＡＰＣシステム内のエージェントクライアントとを有し、このエージェントクライアントは、エージェントクライアントコミュニケーションクラスとドライバとを有する、請求項１のＡＰＣシステム。
16. 前記エージェントクライアントコミュニケーションクラスは、前記ツールエージェントとＢＳＤソケットにより通信し、また、スタートエージェントの方法とイベントレシーブスレッドとゲットネクストメッセージの方法とストップエージェントの方法との少なくとも１つを有する、請求項１５のＡＰＣシステム。
17. 前記ＡＰＣサーバは、少なくとも３Ｇバイトの利用可能なディスク領域を有する記憶装置と、少なくとも２つの６００ＭＨｚのＣＰＵを有するプロセッサと、少なくとも５１２ＭバイトのＲＡＭを有する物理メモリとを有する、請求項１のＡＰＣシステム。
18. 前記ＡＰＣサーバは、少なくとも１つのツールに関連したアプリケーションと、少なくとも１つのモジュールに関連したアプリケーションと、少なくとも１つのセンサに関連したアプリケーションと、少なくとも１つのＩＳに関連したアプリケーションと、少なくとも１つのデータベースに関連したアプリケーションと、少なくとも１つのＧＵＩに関連したアプリケーションとを有する複数のアプリケーションを与える、請求項１のＡＰＣシステム。
19. 前記ＡＰＣサーバは、ツールＡＰＣマスタアプリケーションと、ツールＡＰＣ警報アプリケーションと、１つかそれより多くのセンサインターフェースアプリケーションと、ＡＰＣデータベース管理サポートアプリケーションと、ＡＰＣデータ収集サポートアプリケーションと、ＡＰＣイベント管理サポートアプリケーションと、プローブインターフェースアプリケーションと、ＡＰＣプロセスチャンバサポートアプリケーションと、ＡＰＣストラテジ選択アプリケーションと、ツールインターフェースアプリケーションと、ウエハデータアプリケーションと、ＡＰＣプラン実行（ＰＥ）アプリケーションとのうち少なくとも１つを有する、複数のアプリケーションを与える、請求項１のＡＰＣシステム。
20. 前記ツールＡＰＣマスタアプリケーションは、シャットダウンオールの方法と、初期化の方法と、ロジックマネジャブーストの方法と、設定ロードの方法と、状態ロードの方法と、設定セーブの方法と、ＧＵＩ時間更新の方法との少なくとも１つを有する複数の機能を実行する、請求項１９のＡＰＣシステム。
21. 前記ＡＰＣイベント管理サポートアプリケーションは、イベントに基づいて方法をディスパッチングするように設定されている、請求項１９のＡＰＣシステム。
22. 前記ＡＰＣイベント管理サポートアプリケーションは、アクティブイベントの方法と、ファイルレディの方法と、アラームの方法と、ロットエンドの方法と、ロットスタートの方法と、レシピエンドの方法と、レシピスタートの方法と、ＲＦオフの方法と、ＲＦオンの方法と、ウエハインの方法と、ウエハアウトの方法との少なくとも１つを有する複数の方法を実行する、請求項１９のＡＰＣシステム。
23. 前記ＡＰＣデータ収集サポートアプリケーションは、ゲットロストデータ機能と、ゲットウエハデータ機能と、セットアップセンサ機能と、スタートセンサ機能と、ストップセンサ機能と、ロードデフォルトプラン機能との少なくとも１つを有する多くの方法を実行する、請求項１９のＡＰＣシステム。
24. 前記ツールインターフェースアプリケーションは、ツールインターフェースと、ファイル転送と、状態と、の管理をおこなうように設定さけている、請求項１９のＡＰＣシステム。
25. 前記ツールインターフェースアプリケーションは、チェンジイベントの方法と、デバイスフェイルドの方法と、デバイスリカバリの方法と、アクティブイベントの方法と、チェックアクティブの方法と、イベントディスパッチャの方法と、イベントレシーバの方法と、ゲットトレースデータの方法と、スタートエージェントの方法と、ストップエージェントの方法とのうち少なくとも１つを有する複数の方法を実行する、請求項１９のＡＰＣシステム。
26. 前記ＡＰＣＰＥアプリケーションは、どのストラテジを実行するかを決定し、そのストラテジは、所定の時にアクティブなプランの一組を指定している、請求項１９のＡＰＣシステム。
27. 前記ＡＰＣＰＥアプリケーションは、どのストラテジを実行するべきか決定するためにコンテキスト情報を用いる、請求項１９のＡＰＣシステム。
28. 前記データベースは、構成成分テーブルと、属性テーブルと、運転属性テーブルと、関連テーブルと、プロセス運転テーブルと、装置運転テーブルと、生の運転データテーブルと、モデルデータテーブルと、運転サマリテーブルと、警報テーブルとの少なくとも１つを有する複数のテーブルを有し、この構成成分テーブルは、前記ＡＰＣシステムの構成成分の設定をするために用いられ、構成成分テーブルの各々の構成成分は、前記属性テーブルに多数の関連した記録をもつことができる、請求項１のＡＰＣシステム。
29. 前記プロセス運転テーブルは、開始時間と、ウエハと、材料のタイプとを有するコンテキスト項目を有している、請求項２８のＡＰＣシステム。
30. 前記装置運転テーブルは、センサのための設定と、操作パラメータとを有する、請求項２８のＡＰＣシステム。
31. 前記生の運転データテーブルは、生の観測データを有する、請求項２８のＡＰＣシステム。
32. 前記モデルデータテーブルは、モデル解析のために入力データと、出力データとを保持する動的に形成されるテーブルであることができる、請求項２８のＡＰＣシステム。
33. 前記運転サマリテーブルは、運転ＩＤと、運転タイプと、値の名前と、開始ステップと、終了ステップと、値の最小と、値の最大とを有する運転サマリ情報を有する、請求項２８のＡＰＣシステム。

Images