(57)【特許請求の範囲】
【請求項１】
プラズマ処理システム内での基板処理を容易にするよう構成されている処理レベルトラブルシューティングアーキテクチャ（ＰＬＴＡ）であって、
処理モジュール制御部と、
各々が、１または複数の処理パラメータについての検知データを収集するために前記処理モジュール制御部と通信する複数のセンサと、
前記複数のセンサおよび前記処理モジュール制御部と直接通信する処理モジュールレベル解析サーバと、
を備え、
前記処理モジュールレベル解析サーバは、
前記複数のセンサからの前記検知データおよび前記処理モジュール制御部からの処理モジュール・チャンバデータを含むデータを受信し、
前記データを解析し、
前記基板処理中に問題が特定された際に、前記処理モジュール制御部に直接、停止命令データを送信するよう構成される、
処理レベルトラブルシューティングアーキテクチャ。
【請求項２】
請求項１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のセンサの内の第１のセンサは、前記検知データの少なくとも一部を前記処理モジュールレベル解析サーバに送信する前に前処理を実行するための計算モジュールを備える、処理レベルトラブルシューティングアーキテクチャ。
【請求項３】
請求項２に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバはイーサネット（登録商標）スイッチを備え、前記イーサネットスイッチは、前記処理モジュールレベル解析サーバが前記第１のセンサと通信することを可能にする、処理レベルトラブルシューティングアーキテクチャ。
【請求項４】
請求項１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のセンサの内の第２のセンサは、前記検知データの少なくとも一部を前処理することなしに前記第２のセンサから前記処理モジュールレベル解析サーバに直接送信する、処理レベルトラブルシューティングアーキテクチャ。
【請求項５】
請求項４に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバは、前記第２のセンサによって送信された前記検知データをアナログフォーマットからデジタルフォーマットに変換するためのデータ変換器を備える、処理レベルトラブルシューティングアーキテクチャ。
【請求項６】
請求項１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバは、共有メモリバックボーンを備え、前記共有メモリバックボーンは、複数のプロセッサによってアクセスされ、前記複数のプロセッサの各プロセッサは、前記共有メモリバックボーンを介して前記複数のセンサの内の１センサと少なくとも相互作用するよう構成される、処理レベルトラブルシューティングアーキテクチャ。
【請求項７】
請求項６に記載の処理レベルトラブルシューティングアーキテクチャであって、前記共有メモリバックボーンは、前記複数のプロセッサ間の負荷バランシング（load balancing）を実行するよう構成される、処理レベルトラブルシューティングアーキテクチャ。
【請求項８】
請求項７に記載の処理レベルトラブルシューティングアーキテクチャであって、前記共有メモリバックボーンは、前記複数のプロセッサ間に耐障害性を提供するよう構成されている、処理レベルトラブルシューティングアーキテクチャ。
【請求項９】
請求項６に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、セカンダリプロセッサであり、前記セカンダリプロセッサは、少なくとも、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記検知データを処理するように構成されている、処理レベルトラブルシューティングアーキテクチャ。
【請求項１０】
請求項９に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、プライマリプロセッサであり、前記プライマリプロセッサは、
前記処理モジュール制御部から前記処理モジュール・チャンバデータを受信し、
前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、
前記処理モジュール・チャンバデータを前記検知データと相関させ、
直接デジタル出力ラインを介してリアルタイムな停止命令データを前記処理モジュール制御部に送信することの内の少なくとも１つを実行するよう構成されている、処理レベルトラブルシューティングアーキテクチャ。
【請求項１１】
プラズマ処理システム内での基板処理中に評価を行うよう構成されている装置であって、前記装置は、処理モジュール制御部および複数のセンサに直接接続されており、前記装置は、
前記複数のセンサによって収集された検知データおよび前記処理モジュール制御部によって収集された処理モジュール・チャンバデータを含むデータを処理するための複数のプロセッサと、前記処理は、
前記データを受信する工程、
前記データを解析する工程、
データ相関を実行する工程、および、
問題が特定された際に、停止命令データを前記処理モジュール制御部に送信する工程の内の少なくとも１つを含み、
前記複数のプロセッサによってアクセスされる共有メモリバックボーンと、
少なくとも前記データを受信するように構成されているインターフェースと、
前記複数のプロセッサと前記処理モジュール制御部との間の通信パスである直接デジタル出力ラインと、
を備える、装置。
【請求項１２】
請求項１１に記載の装置であって、前記ネットワークインターフェースは、前記複数のセンサの内の少なくとも第１のサブセットのセンサから、前記検知データを受信するよう構成され、前記第１のサブセットのセンサの内の各センサは、前記ネットワークインターフェースを介して前記検知データの少なくとも一部を前記複数のプロセッサに送信する前に前処理を実行するための計算モジュールを備える、装置。
【請求項１３】
請求項１２に記載の装置であって、前記ネットワークインターフェースは、イーサネットスイッチである、装置。
【請求項１４】
請求項１１に記載の装置であって、さらに、前記複数のセンサによって送信された前記検知データを変換するためのデータ変換器を備え、前記データ変換器は、少なくとも、前記検知データの少なくとも一部を前記複数のプロセッサに送信する前に、前記検知データをアナログフォーマットからデジタルフォーマットに変換するように構成されている、装置。
【請求項１５】
請求項１４に記載の装置であって、前記データ変換器は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）である、装置。
【請求項１６】
請求項１１に記載の装置であって、前記共有メモリバックボーンは、前記複数のプロセッサ間の負荷バランシングを実行するよう構成されている、装置。
【請求項１７】
請求項１１に記載の装置であって、前記共有メモリバックボーンは、前記複数のプロセッサ間に耐障害性を提供するよう構成されている、装置。
【請求項１８】
請求項１１に記載の装置であって、前記複数のプロセッサの各プロセッサは、前記複数のセンサの内の少なくとも１つのセンサと直接通信するよう構成されている、装置。
【請求項１９】
請求項１８に記載の装置であって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、セカンダリプロセッサであり、前記セカンダリプロセッサは、少なくとも、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記検知データを処理するように構成されている、装置。
【請求項２０】
請求項１９に記載の装置であって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、プライマリプロセッサであり、前記プライマリプロセッサは、
前記処理モジュール制御部から前記処理モジュール・チャンバデータを受信し、
前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、
前記検知データと前記処理モジュール・チャンバデータとを相関させ、
直接デジタル出力ラインを介して前記停止命令データを前記処理モジュール制御部に送信することの内の少なくとも１つを実行するよう構成されている、装置。
【発明の詳細な説明】
【背景技術】
【０００１】
プラズマ処理における進歩は、半導体業界の成長をもたらした。競争に勝つに、製造会社は、基板を高品質の半導体デバイスに処理することができる必要がある。基板処理中に十分な結果を達成するためには、一般に、処理パラメータの厳密な管理が必要である。処理パラメータ（例えば、ＲＦ電力、圧力、バイアス電圧、イオン束、プラズマ密度など）が所定の窓（ウィンドウ）の範囲外になると、望ましくない処理結果（例えば、質の悪いエッチングプロファイル、低い選択性、基板への損傷、処理チャンバへの損傷など）が生じうる。したがって、処理パラメータが所定の窓の範囲外にある時の条件を特定できることが、半導体デバイスの製造において重要である。
【０００２】
基板処理中、基板を損傷しうる、および／または、処理チャンバの構成要素に対する損傷を引き起こしうる特定の非制御事象が起きる場合がある。非制御事象を特定するために、基板処理中にデータが収集されうる。基板処理中に様々な処理パラメータ（バイアス電圧、反射電力、圧力など）に関するデータを収集するために、センサなどの監視デバイスが利用されうる。本明細書に記載のように、センサとは、プラズマ処理構成要素の条件および／または信号を検出するために利用可能なデバイスを指す。議論を容易にするために、「構成要素」という用語は、処理チャンバ内の単一部品または複数部品のアセンブリを指すために用いることとする。
【０００３】
近年、センサにより収集されるデータの種類および量が増加している。処理モジュールデータおよび処理コンテクストデータ（チャンバイベントデータ）に関してセンサによって収集されたデータを解析することにより、所定の窓の範囲外にあるパラメータを特定できる。したがって、非制御事象を停止するために修正動作（レシピ調整など）を提供することにより、基板および／または処理チャンバ構成要素に対してさらなる損傷が生じることを防止しうる。
【発明の概要】
【０００４】
本発明は、一実施形態において、プラズマ処理システム内における基板処理を容易にするよう構成された処理レベルトラブルシューティングアーキテクチャ（ＰＬＴＡ）に関する。アーキテクチャは、処理モジュール制御部を備える。アーキテクチャは、さらに、複数のセンサを備えており、複数のセンサに含まれる各センサは、１または複数の処理パラメータについての検知データを収集するために処理モジュール制御部と通信する。アーキテクチャは、さらに、処理モジュールレベル解析サーバを備えており、処理モジュールレベル解析サーバは、複数のセンサおよび処理モジュール制御部と直接通信する。処理モジュールレベル解析サーバは、データを受信するよう構成されており、データは、複数のセンサからの検知データと、処理モジュール制御部からの処理モジュール・チャンバデータとの内の少なくとも一方を含む。処理モジュールレベル解析サーバは、データを解析し、基板処理中に問題が特定された際に、停止命令データを処理モジュール制御部に直接送信するよう構成されている。
【０００５】
上述の発明の概要は、本明細書に開示された本発明の多くの実施形態の内の１つのみに関するものであり、特許請求の範囲に記載される本発明の範囲を限定する意図はない。添付の図面を参照しつつ行う本発明の詳細な説明において、本発明の上述の特徴およびその他の特徴を詳述する。
【図面の簡単な説明】
【０００６】
添付の図面では、限定ではなく例示を目的として本発明を図示する。なお、これらの添付図面においては、同様の構成要素には同様の符号が付されている。
【０００７】
【図１】ホストレベルの解析サーバを含む相互接続ツール環境の従来技術を示す全体論理図。
【０００８】
【図２】センサと処理モデル制御部との間でデータを相関させるためのクラスタツールレベルの解決法を備えた相互接続ツール環境を示す概略ブロック図。
【０００９】
【図３】本発明の一実施形態において、処理レベルのトラブルシューティングアーキテクチャを示す概略論理図。
【００１０】
【図４】本発明の一実施形態において、処理モジュールレベル解析サーバを示す概略機能図。
【発明を実施するための形態】
【００１１】
以下では、添付図面に例示されているいくつかの実施形態を参照しつつ、本発明の詳細な説明を行う。以下の説明では、本発明の完全な理解を促すために、数多くの具体的な詳細事項が示されている。しかしながら、当業者にとって明らかなように、本発明は、これらの具体的な詳細事項の一部または全てがなくとも実施することが可能である。また、本発明が不必要に不明瞭となるのを避けるため、周知の処理工程および／または構造については、詳細な説明を省略した。
【００１２】
以下では、方法および技術を含め、様々な実施形態について説明する。本発明は、本発明の技術の実施形態を実行するためのコンピュータ読み取り可能な命令を格納するコンピュータ読み取り可能な媒体を含む製品も含みうることに留意されたい。コンピュータ読み取り可能な媒体としては、例えば、コンピュータ読み取り可能な暗号を格納するための半導体、磁気、光磁気、光学、または、その他の形態のコンピュータ読み取り可能な媒体が挙げられる。さらに、本発明は、本発明の実施形態を実施するための装置も含んでよい。かかる装置は、本発明の実施形態に関するタスクを実行するために、専用および／またはプログラム可能な回路を備えてよい。かかる装置の例は、汎用コンピュータおよび／または適切にプログラムされた専用コンピュータデバイスを含み、本発明の実施形態に関する様々なタスクに適合したコンピュータ／コンピュータデバイスおよび専用／プログラム可能回路を組み合わせたものを含んでもよい。
【００１３】
前述したように、製造者が競争力を獲得するためには、基板処理中に生じうる問題を効果的かつ効率的に解決できなければならない。トラブルシューティングは、一般に、処理中に収集された大量のデータを解析することを含む。議論を容易にするために、図１は、ホストレベルの解析サーバを含む相互接続ツール環境の従来技術の全体論理図を示す。
【００１４】
例えば、製造会社が１または複数のクラスタツール（エッチングツール、洗浄ツール、剥離ツールなど）を有しうる状況を考える。各クラスタツールは、複数の処理モジュールを有してよく、各処理モジュールは、１または複数の特定の処理用に構成される。各クラスタツールは、クラスタツール制御部（ＣＴＣ）、例えば、ＣＴＣ１０４、ＣＴＣ１０６、および、ＣＴＣ１０８などによって制御されてよい。各クラスタツール制御部は、１または複数の処理モジュール制御部（ＰＭＣ）、例えば、ＰＭＣ１１０、１１２、１１４、および、１１６などと相互作用しうる。議論を容易にするために、ＰＭＣ１１０に関連して、例を挙げる。
【００１５】
介入を必要としうる条件を特定するために、センサを用いて、基板処理中に処理パラメータに関するデータ（検知データ）を収集することができる。一例では、基板処理中に、複数のセンサ（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、および、１４０など）が、１または複数の処理パラメータに関するデータを収集するために処理モジュール制御部と相互作用しうる。利用可能なセンサのタイプは、収集されうるデータのタイプによって決まりうる。例えば、センサ１１８は、電圧データを収集するよう構成されてよい。別の例において、センサ１２０は、圧力データを収集するよう構成されてよい。一般に、処理モジュールからデータを収集するために利用可能なセンサは、異なるブランド、型式、および／または、モデルでありうる。結果として、センサは、別のセンサとほとんど、または全く相互作用しえない。
【００１６】
通常、センサは、１または複数の特定のパラメータに関する測定データを収集するよう構成される。ほとんどのセンサは処理を実行するよう構成されないため、各センサは、計算モジュール（コンピュータ、ユーザインターフェースなど）に接続されてよい。計算モジュールは、通常、アナログデータを処理し、アナログ生データをデジタルフォーマットに変換するよう構成される。
【００１７】
一例として、センサ１１８は、センサケーブル１４４を介してＰＭＣ１１０からの電圧データを収集する。センサ１１８によって受信されたアナログ電圧データは、計算モジュール１１８ｂによって処理される。センサによって収集されたデータは、ホストレベルの解析サーバ（データボックス１４２など）に送信される。ネットワーク接続を介してデータボックス１４２にデータを送信する前に、データは、まず、計算モジュールによってアナログフォーマットからデジタルフォーマットに変換される。一例において、計算モジュール１１８ｂは、ネットワークパス１４６を介してデータボックス１４２へデータを送信する前に、センサ１１８によって収集されたアナログデータをデジタルフォーマットに変換する。
【００１８】
データボックス１４２は、センサおよび処理モジュールなど複数のソースから、データを収集、処理、および、解析するよう構成された集中型の解析サーバであってよい。通常、単一の製造会社のクラスタツールのすべてによる基板処理中に収集されたデータを処理するために利用可能なデータボックスは１つである場合がある。
【００１９】
データボックス１４２に伝送されうるデータの実際の量は、センサによって収集された量よりも大幅に少なくなる場合がある。通常、センサは、莫大な量のデータを収集しうる。一例において、センサは、最大で毎秒１メガバイトの速度でデータを収集しうる。しかしながら、データボックス１４２に送信されるのは、センサによって収集されたデータのほんの一部のみである。
【００２０】
センサによって収集されたデータストリーム全体をデータボックス１４２に伝送しない理由の１つは、費用効率のよい商業的に利用可能な通信プロトコルを用いる場合、ネットワーク帯域幅に制限があることである。データボックス１４２へのネットワークパイプラインは、単一のレシーバ（データボックス１４２など）に送信される複数のソース（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、および、１４０など）からの大量のデータを扱うことができない場合がある。換言すると、センサ構成（センサおよび計算モジュール）とデータボックス１４２との間のネットワークパスは、データボックス１４２がセンサ構成すべてから来る莫大な量のデータを受信しようとするので、深刻なトラフィックの混雑を経験する場合がある。以上からわかるように、データボックス１４２が入力トラフィックに対処できない場合、送信されるデータパケットが減少し、再送信されることによって、すでに非常に混雑しているネットワークパイプラインにさらなる負荷をかける可能性がある。
【００２１】
さらに、データボックス１４２は、複数のソースからの大量の入力データを処理しつつ、同時にその他の重要な機能（データの処理および解析など）を実行することができない場合がある。上述のように、データボックス１４２は、入力データパケットを受信するよう構成されるだけでなく、例えば、入力データストリームすべてを処理および解析するようにも構成される。データボックス１４２は、収集された様々なデータストリームのための解析サーバであるため、大量のデータストリームの解析を実行するのに十分な処理能力を必要とする。
【００２２】
データボックス１４２は処理リソースが限られているため、各センサから収集されたデータの一部のみがデータボックス１４２に送信される。一例において、単一のセンサによって収集されうる数千のデータ項目のうち、１〜５ヘルツで１０〜１５のデータ項目のみが、データボックス１４２に転送されうる。一例では、センサ１１８によって収集されたデータの概要（要約）のみが、データボックス１４２に送信されうる。
【００２３】
複数のセンサからデータを受信することに加えて、データボックス１４２は、さらに、処理モジュール制御部からデータを受信してよい。一例において、処理モジュールデータおよび処理コンテクストデータ（チャンバイベントデータ）は、各処理モジュール制御部によって収集され、データボックス１４２に転送されてよい。議論を容易にするために、処理モジュールデータおよび処理コンテクストデータは、処理モジュール・チャンバデータと呼ばれてもよい。例えば、処理モジュールデータおよび処理コンテクストデータは、ＰＭＣ１１０によって収集されて、パス１４８を介してＣＴＣ１０４に送信されてよい。ＣＴＣ１０４は、ＰＭＣ１１０からのデータを管理するだけでなく、クラスタツール（例えば、ＰＭＣ１１２、ＰＭＣ１１４、および、ＰＭＣ１１６）内の他の処理モジュール制御部からのデータを扱ってもよい。
【００２４】
クラスタツール制御部によって収集されたデータは、次に、半導体製造装置通信規格／包括的装置モジュール（ＳＥＣＳ／ＧＥＭ）インターフェースを介して工場ホスト１０２に伝送される。一例において、ＣＴＣ１０４は、パス１５０を介し、ＳＥＣＳ／ＧＥＭ１５６を通して、ＰＭＣ１１０、１１２、１１４、および／または、１１６から収集したデータを工場ホスト１０２に伝送する。工場ホスト１０２は、ＣＴＣ１０４からデータを受信するだけでなく、例えば、その他のクラスタツール制御部（ＣＴＣ１０６および１０８など）からのデータも受信してよい。工場ホスト１０２によって収集されたデータは、次に、パス１５８を介してデータボックス１４２に転送される。莫大な量のデータが収集されているため、工場ホスト１０２に送信されたすべてのデータがデータボックス１４２に転送されるわけではない。多くの例では、データの要約だけが、データボックス１４２に転送されうる。
【００２５】
データボックス１４２は、センサおよび処理モジュール制御部によって収集されたデータを処理、解析、および／または、相関させうる。異常が特定された場合、データボックス１２０は、例えば、ＰＭＣ１１０で実行されるレシピステップに適合しないパラメータなど、問題の原因を決定しうる。問題の原因が特定されると、データボックス１４２は、イーサネット（登録商標）メッセージのフォーマットの停止命令を工場ホスト１０２に送信してよい。メッセージを受信すると、工場ホスト１０２は、ＳＥＣＳ／ＧＥＭ１５６を通してＣＴＣ１０４へメッセージを転送してよい。次いで、クラスタツール制御部は、対象とする処理モジュール制御部（この例ではＰＭＣ１１０）にメッセージを中継してよい。
【００２６】
残念ながら、停止命令は、通常、リアルタイムで提供されない。その代わり、停止命令は、通常、影響を受けた基板が処理された後、または、基板ロット全体が処理モジュールから出た後に、対象の処理モジュールによって受信される。したがって、基板／基板ロットが損傷されるだけでなく、１または複数の処理チャンバ構成要素も悪影響を受ける場合があり、それによって、廃棄と所有コストが増大する。
【００２７】
遅延の理由の１つは、大量のソースから莫大な量のデータが受信されることである。データボックス１４２が、高速のプロセッサを有するよう構成され、大量のデータストリームを扱うのに十分なメモリを有しうる場合でも、データボックス１４２は、収集されるデータすべてを処理、相関、および／または、解析するのに時間を必要としうる。
【００２８】
処理モジュールによる停止命令の受信が遅延する別の理由は、データボックス１４２によって受信されるデータストリームが不完全であることである。データボックス１４２は、多数のソースからデータを受信するため、データボックス１４２に送信される実際のデータは、収集されたデータよりも大幅に少ない。一例では、センサ１１８によって収集される１ギガヘルツのデータストリームを送信する代わりに、実際にはデータの一部のみ（約１〜５ヘルツ）が送信される。結果として、データボックス１４２がその全ソースから大量のデータを受信していても、受信されているデータは通常、不完全である。したがって、データボックス１４２が全ソースからの完全なデータセットにアクセスできないことを考えると、非制御事象を判定するには、時間がかかりうる。
【００２９】
さらに、データボックス１４２にデータを送信するためのパスは、様々でありうる。一例では、データは、アナログデータがデジタルデータに変換された後に、センサ構成（センサおよび計算モジュール）から直接送信される。対照的に、処理モジュールによって収集されたデータは、長いネットワークパスを介して（少なくともクラスタツール制御部および工場ホストを通して）伝送される。したがって、データボックス１４２は、すべての関連データストリームが受信されるまで、解析を完了することができない。
【００３０】
処理モジュールとデータボックス１４２との間のネットワークパスは長いだけでなく、このパスを通して送信されるデータストリームは、通常、少なくとも２つのボトルネックに直面する。第１のボトルネックは、クラスタツール制御部におけるボトルネックである。クラスタツール内の処理モジュールによって収集されたデータは単一のクラスタツール制御部に送信されるため、様々な処理モジュールからのデータストリームを単一のクラスタツール制御部で処理する必要があり、第１のボトルネックが起きる。各処理モジュールから伝送されうるデータが大量であることを考えると、クラスタツール制御部へのネットワークパスは、通常、かなりのトラフィックの混雑を経験する。
【００３１】
データは、クラスタツール制御部によって受信されると、工場ホスト１０２に伝送される。第２のボトルネックは、工場ホスト１０２で起こりうる。工場ホスト１０２が様々なクラスタツール制御部からデータを受信しうることを考えると、大量のデータが受信されるため、工場ホスト１０２へのトラフィックも、混雑を経験しうる。
【００３２】
データボックス１４２は、非制御事象を判定するために様々なソースからのデータを必要とするため、処理モジュールとデータボックス１４２との間のトラフィック状況が、データボックス１４２へのデータストリームのタイムリーな搬送を妨げる。結果として、データボックス１４２が解析を実行するために必要なデータすべてを集めるまでに、貴重な時間が失われる。さらに、停止命令が準備されると、修正動作を実行するために停止命令を適用できるまでに、非常に長い同じパスを通して不具合のある処理モジュールに戻される必要がある。
【００３３】
遅延に寄与する別の要因は、様々なデータソースからのデータを相関させるという課題である。データボックス１４２によって受信されるデータストリームは、通常、各センサおよび／または処理モジュールから収集されたデータの要約であるため、データを相関させることは、利用可能なデータストリームの時間間隔が異なりうることから、困難なタスクでありうる。一例では、センサ１１８からデータボックス１４２に伝送される選択データストリームは、１秒間隔であってよく、ＰＭＣ１１０からのデータストリームは、２秒間隔であってよい。結果として、非制御事象を断定的に決定できるまでに、データストリームを相関させるのに時間が必要になりうる。
【００３４】
データを相関させる際のさらなる難題は、データをデータボックス１４２に送信するためのパスが異なることによるものである。データは、異なるコンピュータ、サーバなどを通して伝送されるため、コンピュータドリフト、ネットワーク待ち時間、ネットワーク負荷などに曝されうる。結果として、データボックス１４２は、様々なソースからのデータを相関させる困難を有しうる。非制御事象を速やかに特定するために厳密な相関が必要であることを考えると、非制御事象を正確に特定できるまでに、より多くの解析を実行する必要がありうる。
【００３５】
図１に提供された解決法の別の欠点は、所有のコストである。クラスタツールシステムの維持コストに加えて、センサ構成に関連して、さらなるコストが掛かる。各センサは、ブランド／型式／モデルが異なりうるため、各センサ構成は、通常、センサおよび計算モジュールを備える。通常、センサ構成の各々を収容するために物理的空間が必要である。したがって、不動産価格が高い可能性がある領域では特に、センサ構成を収容するコストが高くなりうる。
【００３６】
処理モジュール内での非制御事象の実際の発生と、処理モジュールによる停止命令の受信との間の実際の時間的遅延を低減するために、クラスタレベルの解析サーバが提供される。図２は、センサと処理モデル制御部との間でデータを相関させるためのクラスタツールレベルの解決法を備えた相互接続ツール環境を示す概略ブロック図である。
【００３７】
図１と同様に、クラスタツールは、複数の処理モジュール（ＰＭＣ２１０、２１２、２１４、および、２１６など）を備えてよい。解析用のデータを収集するために、各処理モジュールは、複数のセンサ（センサ２１８、２２０、２２２、２２４、２２６、２２８、２３０、２３２、２３４、２３６、２３８、および、２４０など）に接続されてよい。各センサは、処理パラメータデータを収集するために、センサケーブル（センサケーブル２４４など）を介して、対応する処理モジュール制御部と相互作用してよい。センサによって収集されたデータは、アナログフォーマットであってよい。計算モジュール（計算モジュール２１８ｂなど）は、パス２４６を介してクラスタレベル解析サーバ（リモート制御部２４２など）にデータを転送する前に、データを処理してデジタルフォーマットに変換してよい。
【００３８】
図１と同様に、各処理モジュール制御部も、クラスタツール制御部（ＣＴＣ２０４および２０６など）にデータ（処理モジュールデータおよび処理コンテクストデータなど）を伝送してよい。一例では、ＰＭＣ２１０によって収集されたデータは、パス２４８を介してＣＴＣ２０４に伝送されてよい。ＰＭＣ２１０からデータを受信するのに加えて、ＣＴＣ２０４は、その他の処理モジュール制御部（ＰＭＣ２１２、２１４、および、２１６など）からもデータを受信してよい。クラスタツール制御部によって受信されたデータは、次に、パス２５０を介して工場ホスト２０２に転送される。
【００３９】
工場ホスト２０２とＣＴＣ２０４との間には、工場ホスト２０２に転送されるデータを複製するために、シリアルタップがネットワークパス２５０に接続されてよい。一例では、シリアルタップ２０８は、ＣＴＣ２０４によって工場ホスト２０２に転送されるデータを遮断してよい。データは複製され、データストリームのコピーがパス２５４を介してリモート制御部２４２に送信される。工場ホストが、各クラスタツール制御部ではなく、２以上のクラスタツール制御部と接続されている場合、専用のリモート制御部がクラスタツール制御部と関連付けられる。一例では、パス２５２を介してＣＴＣ２０６から工場ホスト２０２に送信されるデータは、別のシリアルタップ（２５６）によって遮断される。データは複製され、ＣＴＣ２０４に関連付けられたリモート制御部（２４２）とは異なるリモート制御部（２６０）にパス２５８を介して送信される。
【００４０】
したがって、様々なクラスタツールからの全データを処理するために単一のデータボックスを用いる代わりに、複数のリモート制御部を用いて、様々なクラスタツールからのデータを扱うことができる。換言すると、各クラスタツールは、独自のリモート制御部に関連付けられる。各リモート制御部は、より少ない数のデータソース（単一のクラスタツールに関連する処理モジュール制御部およびセンサなど）からのデータを扱うため、各ソースについて扱うことのできるデータの量が多くなる。一例では、３０〜１００のデータ項目が送信される代わりに、１０ヘルツで約４０ｋＢ〜１００ｋＢのデータ項目が、各リモート制御部によって受信されうる。
【００４１】
センサおよび処理モジュール制御部から受信されたデータは、リモート制御部によって解析される。問題が特定されると、リモート制御部は、クラスタツール制御部に停止命令を送信してよい。一例において、リモート制御部２４２は、ＰＭＣ２１０内の問題を特定する。停止命令は、パス２５４および２５０を介し、シリアルタップ２０８を通して、ＣＴＣ２０４に送信される。停止命令を受信すると、ＣＴＣ２０４は、対象とする処理モジュール制御部（この例ではＰＭＣ２１０）に停止命令を転送する。
【００４２】
リモート制御部は、（データボックス１４２のように）複数のクラスタツールではなく１つのクラスタツールからのデータを扱うだけでよいため、より多くのデータを解析することが可能であり、より良好な相関が、異なるデータセット間に存在しうる。結果として、リモート制御部は、より良好かつ高速な解析を実行することにより、処理モジュール内の非制御事象を修正するために、よりタイムリーな介入を提供することができる。一例では、特定された非制御事象が次の基板ロットで起こることを防ぐための停止命令（データボックス１４２によって提供された停止命令など）を受信する代わりに、例えば、リモート制御部２４２によって送信された停止命令により、プロセスエンジニアが、処理される予定の基板ロットの少なくとも一部を救出することが可能になる。
【００４３】
リモート制御部による解決法は、データボックスによる解決法よりも良好な解決法であるが、それでも、解析を実行するのに要約データに依存する。結果として、基板処理中に起こっている可能性のある問題が、特定されないまま残る場合がある。さらに、処理モジュールとリモート制御部との間のパスが、直接的なパスではない。結果として、コンピュータドリフト、ネットワーク待ち時間、および／または、ネットワーク負荷により、リモート制御部がセンサからのデータと処理モジュールからのデータを相関させることを困難にしうる時間のずれが起こりうる。
【００４４】
したがって、リモート制御部による解決法は、停止命令の適時性を増大させたとしても、まだ不十分である。最良でも、停止命令は、影響を受けた基板が経験した問題が次の基板の処理中に起こることを防止できるだけである。コストを最小化する必要がある熾烈な競争市場では、基板の損傷による廃棄および／または処理チャンバ構成要素の損傷による休止時間が、市場喪失につながりうる。したがって、非制御事象を特定するためのリアルタイムな解決法が望まれる。
【００４５】
本発明の実施形態によると、トラブルシューティングが処理モジュールレベルで実行される処理レベルトラブルシューティングアーキテクチャ（ＰＬＴＡ）が提供される。本発明の実施形態は、リアルタイム停止命令を備えたリアルタイム解析を提供する処理レベルトラブルシューティングアーキテクチャを備える。本発明の実施形態は、さらに、負荷バランシングおよびフォールトトレランスのための構成をセンサ間に備える。
【００４６】
本発明の一実施形態において、処理レベルトラブルシューティングアーキテクチャは、解析サーバが単一の処理モジュールおよびそれに対応するセンサと通信するためのネットワークシステムである。一実施形態において、ネットワークでやり取りされる情報は双方向である。一例において、解析サーバは、処理モジュールおよびセンサから処理データを連続的に受信してよい。逆に、センサは、処理モジュールからデータを受信してよく、処理モジュールは、解析サーバから命令を受信してよい。
【００４７】
例えば、基板が処理されている状況を考える。基板処理中、複数のデータが収集されてよい。一例では、圧力に関するデータが、１００ミリ秒ごとに収集される。処理が１時間かかる場合、３６，０００のデータ項目が圧力パラメータについて収集される。しかしながら、圧力データに加えて、複数のその他の処理データ（例えば、電圧バイアス、温度など）も収集されてよい。したがって、基板処理が完了するまでに、かなりの量のデータが収集される。
【００４８】
従来技術では、データは、（データボックス１４２のように）複数のクラスタツールから収集したデータでない場合でも、（図２のリモート制御部２４２のように）複数の処理モジュールから収集されたデータを扱うよう構成されうる解析サーバに伝送される。データストリームが複数のソース由来であるため、データの解析および／または相関のために時間が必要になる。さらに、従来技術の解析サーバは、収集されたデータすべてを処理および解析できない場合があるため、各ソースから収集されたデータの一部のみが、解析サーバに伝送される。結果として、データストリームを調整、処理、相関、および／または、解析する複雑なタスクには時間が必要であり、時間は、常に簡単に利用できるとは限らない。
【００４９】
本発明の一態様において、発明者は、より精密なデータを解析に利用できれば、より正確および迅速な解析を実行できることを認識した。１つのソースからのデータをより多く解析するには、解析サーバがデータを解析するソースを少なくする必要がある。一実施形態では、処理モジュールレベルでデータを処理および／または解析するための構成が提供される。換言すると、各処理モジュールおよびそれに対応するセンサの解析を実行するための処理モジュールレベル解析サーバが提供される。
【００５０】
一実施形態において、処理モジュールレベル解析サーバは、１または複数のプロセッサを備えうる共有メモリバックボーンを備える。各プロセッサは、１または複数のセンサと相互作用するよう構成されてよい。一例では、センサ１によって収集されたデータがプロセッサ１によって処理されてよく、センサ２によって収集されたデータがプロセッサ２によって処理されてよい。
【００５１】
従来技術と異なり、プロセッサは、負荷バランシングおよびフォールトトレランスを実現するために、互いに処理能力を共有してよい。従来技術では、計算モジュールが、センサによって収集されたデータを処理するよう構成される。各計算モジュールは個別のユニットであり、通常は互いに相互作用しないため、負荷バランシングは通常、実行されない。従来技術と異なり、処理モジュールレベル解析サーバ内のプロセッサのセットは、負荷バランシングを実行しうる。一例において、プロセッサ１がデータの過負荷を経験しており、プロセッサ２がデータをほとんどまたは全く受信していない場合、プロセッサ２は、プロセッサ１を支援してセンサ１からのデータを処理するように利用されてよい。
【００５２】
さらに、従来技術では、計算モジュールは、異なるブランド／型式／モデルを有する傾向があるため、ある計算モジュールが正常に機能しない場合でも、他の計算モジュールは、正常に機能しない計算モジュールによって実行されていた処理を引き継ぐことができない。従来技術と異なり、作業負荷が、必要に応じてプロセッサ間で再分配されてよい。例えば、プロセッサ２が自身の機能を実行できない場合、その作業負荷は、プロセッサ２が修理されるまで、他のプロセッサに再分配されてよい。以上からわかるように、プロセッサは、個別の計算モジュールの必要性を排除し、それにより、計算モジュールを収容するために必要な物理的空間も削減する。
【００５３】
本発明の一実施形態において、プロセッサは、以下の２つのタイプのプロセッサに分類されてよい：プライマリプロセッサおよびセカンダリプロセッサ。プライマリおよびセカンダリプロセッサは両方とも、センサからのデータを扱うよう構成される。一例において、セカンダリプロセッサ１がセンサ１と関連付けられている場合、セカンダリプロセッサ１は、通常、センサ１からのデータだけを処理する。同様に、セカンダリプロセッサ２がセンサ２および３と関連付けられている場合、セカンダリプロセッサ２は、通常、２つのセンサ（２および３）からのデータだけを処理する。
【００５４】
一実施形態では、共有メモリバックボーンは、１または複数のプライマリプロセッサを備えてよい。プライマリプロセッサのセットは、センサからのデータを扱うだけでなく、処理モジュールからのデータも扱うよう構成されてよい。さらに、プライマリプロセッサのセットは、様々なソース（センサおよび処理モジュールなど）間のデータを相関させ、解析を実行するよう構成される。停止命令が必要である場合、プライマリプロセッサのセットは、処理モジュール制御部に停止命令を送信するよう構成される。
【００５５】
本発明の特長および利点は、図面と以下の説明を参照すれば、よりよく理解できる。
【００５６】
図３は、本発明の一実施形態において、処理レベルのトラブルシューティングアーキテクチャを示す概略論理図である。製造会社は２以上のクラスタツールを有しうるが、本発明の一実施形態の例示として、単一のクラスタツールが用いられている。クラスタツールは様々な数の処理モジュールを有しうるが、図３に示す例は、４つの処理モジュールを備えた単一のクラスタツールを備える。
【００５７】
各処理モジュールによって収集されたデータは、それに対応する処理モジュール制御部（ＰＭＣ３０６、ＰＭＣ３０８、ＰＭＣ３１０、および、ＰＭＣ３１２）によって収集され、クラスタツール制御部（ＣＴＣ）３０４を介して工場ホスト３０２に伝送される。ＰＭＣによって伝送されうるデータは、従来技術で以前から送信されているのと同じタイプのデータ（処理モジュールデータおよび処理コンテクストデータ）であってよい。従来技術と異なり、処理モジュールは、トラブルシューティングを実行する際に、工場ホスト３０２に伝送されるデータに依存しない。その代わり、データは、アーカイブされて、将来の解析のために利用可能な状態にされてよい。
【００５８】
一実施形態では、トラブルシューティングに必要な解析を実行するための処理モジュールレベル解析サーバ（ＡＰＥＣＳ３１４）が提供される。基板がＰＭＣ３０８においてエッチングされている状況を考える。基板処理中、センサ３１６、３１８、および、３２０は、ＰＭＣ３０８からデータを収集する。一例では、センサ３１６は、ＰＭＣ３０８から電圧バイアスデータを収集するよう構成される。ＰＭＣ３０８から収集されたアナログデータは、センサケーブル３２８を介してセンサ３１６に送信される。同様に、センサ３１８および３２０は、それぞれ、センサケーブル３３０および３３２を介してデータを収集してよい。センサによって収集されたデータは、次に、パス３２２、３２４、および、３２６の１つを介して、処理および／または解析のためにＡＰＥＣＳ３１４に伝送されてよい。
【００５９】
従来技術と異なり、センサによって収集されたデータは、解析サーバ（ＡＰＥＣＳ３１４）に伝送される前に、前処理（例えば、要約）される必要はない。一実施形態では、データを処理するための計算モジュールを有する代わりに、各センサは、データをＡＰＥＣＳ３１４に転送する前に、アナログデータをデジタルデータに変換するために用いられてよい単純なデータ変換器を備えてよい。あるいは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのデータ変換器が、一実施形態において、ＡＰＥＣＳ３１４内に組み込まれてもよい。一例では、各プロセッサは、その処理の一部としてデータをデジタルフォーマットに変換するためのデータ変換アルゴリズムを備えてよい。以上からわかるように、計算モジュールの必要性を排除することによって、クラスタツールおよびそのハードウェアを収容するために必要な物理空間が少なくなる。結果として、所有のコストが削減されうる。
【００６０】
ＡＰＥＣＳ３１４は、１つの処理モジュールおよびそれに対応するセンサからのデータのみを専門に処理するため、１つのソースからのデータをより大量に扱うことができる。換言すると、ＡＰＥＣＳ３１４は、各センサから伝送されるデータの量を削減する必要なく、各センサによって収集されたデータを、すべてでなくともほとんどを処理するように構成される。一例では、解析のために送信されるデータ項目が１０〜１５だけである代わりに、各センサからの２０００以上のデータ項目が、ＡＰＥＣＳ３１４によって解析のために利用可能になりうる。結果として、ＡＰＥＣＳ３１４が処理および解析に利用できるデータストリームが、より完全なデータセットになる。
【００６１】
一実施形態において、ＡＰＥＣＳ３１４は、さらに、処理モジュールからのデータを扱うよう構成される。データストリームが解析サーバ（データボックスおよびリモート制御部など）によって受信されるまでに様々なサーバ（例えば、クラスタツール制御部、工場ホストなど）を通して長いデータパスを介して送信される従来技術と異なり、処理モジュールによって収集されたデータは、他のサーバを通る必要なく、ＡＰＥＣＳ３１４に直接送信される。一例において、処理モジュールデータは、パス３３４を介してＰＭＣ３０８からＡＰＥＣＳ３１４に送信されてよい。非制御事象が特定された場合、停止命令は、他のサーバを最初に経由する必要なく、パス３３６を介してＰＭＣ３０８に直接送信されてよい。
【００６２】
処理モジュールレベル解析サーバについて、図４でさらに詳述する。図４は、本発明の一実施形態において、処理モジュールレベル解析サーバを示す概略機能図である。処理モジュールレベル解析サーバ（ＡＰＥＣＳ４００など）が、各処理モジュールに割り当てられてよい。ＡＰＥＣＳ４００は双方向サーバであり、入力データを処理し、非制御事象が特定された時に停止命令を送信するよう構成される。
【００６３】
データは、２つの主要なソースからのデータであってよく、センサによって収集されたデータ、および、処理モジュールによって収集されたデータである。一実施形態において、ＡＰＥＣＳ４００は、複数のセンサ（センサ４１０、４１２、４１４、４１６、４２０、４２２、４２４、および、４２６）からの入力データを受信するよう構成される。一部のクラスタツールの所有者は、すでに、従来のセンサ構成（計算モジュールを備えたセンサ）にかなりの量の金額を投資している場合があることを考えて、ＡＰＥＣＳ４００は、従来のセンサ構成および改良センサ（計算モジュールを必要としないセンサ）の両方からのデータを受け入れるよう構成される。
【００６４】
一実施形態において、ＡＰＥＣＳ４００は、従来のセンサ構成（センサ４１０、４１２、４１４、および、４１６など）と相互作用するためのインターフェース（イーサネットスイッチ４１８など）を備えてよい。一例では、センサ４１０によって収集されたデータは、まず、計算モジュール４１０ｂによってアナログフォーマットからデジタルフォーマットに変換され、その後、デジタルデータは、ＡＰＥＣＳ４００に（パス４３０、４３２、４３４、または、４３６を介して）伝送される。イーサネットスイッチ４１８は、データストリームを受け入れるために従来のセンサ構成と相互作用するよう構成される。次いで、データストリームは、（パス４４６、４４８、４５０、または、４５２を介して）処理のためにＡＰＥＣＳ４００内のプロセッサ（４０２、４０４、４０６、および、４０８）の１つに受け渡される。
【００６５】
処理パラメータの測定に従来のセンサ装置を利用する代わりに、改良センサ（計算モジュールを備えないセンサ）が用いられてよい。収集されたデータが要約される必要がないため、計算モジュールは、もはや処理に必要ではない。その代わり、改良センサは、一実施形態において、アナログフォーマットからデジタルフォーマットにデータを変換するために、データ変換器（図示せず）（安価なＦＰＧＡなど）を備えてよい。あるいは、センサ内部にデータ変換器を組み込む代わりに、データ変換器（図示せず）は、ＡＰＥＣＳ４００の内部に組み込まれてもよい。データ変換器がＡＰＥＣＳ４００の外部に設置されるか内部に設置されるかに関わらず、計算モジュールの排除により、クラスタツールの所有コストが削減される。一例では、計算モジュールの購入、収容、および、維持のコストが、実質的に無くなる。
【００６６】
本発明の一実施形態において、ＡＰＥＣＳ４００は、入力データを処理するための一組のプロセッサ（４０２、４０４、４０６、および、４０８）を備える。一組のプロセッサは、物理的処理ユニット、仮想プロセッサ、または、それらの組み合わせであってよい。各プロセッサは、プロセッサに関連付けられたソースからのデータストリームの処理に関与する。一例では、パス４４０を介してセンサ４２２から流れ込むデータストリームが、プロセッサ４０４によって処理される。別の例では、センサ４２４によって収集されたデータストリームが、処理のためにパス４４２を介してプロセッサ４０６に伝送される。
【００６７】
プロセッサの数、および、プロセッサとセンサとの関連性は、ユーザの構成に依存しうる。一例において、図４は、プロセッサおよびセンサの間の１対１の関係のみを示しているが、他の関係が存在してもよい。一例において、１つのプロセッサが、２以上のソースからのデータを処理するよう構成されてもよい。別の例において、２以上のプロセッサが、１つのセンサからのデータストリームを処理するよう構成されてもよい。
【００６８】
プロセッサの各々は、一実施形態において、共有メモリバックボーン４２８を共有する。結果として、１または複数のプロセッサが過負荷である時に、負荷バランシングを実行できる。一例において、パス４４４を介してセンサ４２６から流れ込むデータストリームがプロセッサ４０８の処理能力を上回る場合、他のプロセッサが、プロセッサ４０８の負荷を軽減する助けとなるように利用されてよい。
【００６９】
負荷バランシング以外に、共有メモリバックボーンは、さらに、フォールトトレランスのための環境を提供する。換言すると、プロセッサの１つが適切に動作していない場合、故障しているプロセッサによって以前に実行されていた処理が、他のプロセッサに再分配される。一例では、プロセッサ４０６が適切に機能しておらず、センサ４２４からのデータストリームを処理できない場合に、プロセッサ４０４が、センサ４２４からのデータストリームを処理するよう指示されてよい。したがって、作業負荷を再分配できることにより、サーバ全体の停止時間を取ることなしに、適切に機能しないプロセッサを交換することが可能になる。
【００７０】
一実施形態では、２つのタイプのプロセッサが、ＡＰＥＣＳ４００内に存在してよい。第１のタイプのプロセッサは、セカンダリプロセッサ（プロセッサ４０４、４０６、または、４０８など）である。各セカンダリプロセッサは、対応する１または複数のセンサから受信したデータストリームを処理するよう構成される。さらに、一実施形態において、各プロセッサは、データを分析し、対応する１または複数のセンサと共に、存在しうる任意の潜在的な問題を特定するよう構成される。
【００７１】
第２のタイプのプロセッサは、プライマリプロセッサ（４０２）として知られる。図４は、１つのプライマリプロセッサのみを示しているが、プライマリプロセッサの数はユーザの構成によって決まりうる。一実施形態において、プライマリプロセッサは、１または複数のセンサからのデータストリームを処理するよう構成されてよい。一例では、センサ４２０によって収集されたデータストリームが、処理のためにパス４３８を介してプライマリプロセッサ４０２に送信される。
【００７２】
プライマリプロセッサに対する別のデータソースは、処理モジュールである。換言すると、処理モジュールによって収集された処理モジュールデータおよび処理コンテクストデータが、プライマリプロセッサによって処理される。一例では、処理モジュールによって収集されたデータは、処理制御バスを通しパス４５４を介してＡＰＥＣＳ４００に送信される。データは、まず、イーサネットスイッチ４１８を通り、その後、パス４４６を介してプライマリプロセッサ４０２に送信される。
【００７３】
データの処理に加えて、プライマリプロセッサは、さらに、複数のソースからのデータを解析するよう構成される。一例では、センサ４２２および４２４からのデータストリーム間のデータ相関が、プライマリプロセッサ４０２によって実行される。別の例では、さらに、１または複数のセンサからのデータストリームと処理モジュールからのデータストリームとの間のデータ相関が、プライマリプロセッサ４０２によって実行される。
【００７４】
データソースの各々のためのデータパスが、およそ同じ長さであるため、データの相関は、従来技術よりも大幅に容易になる。一例では、他のサーバ（クラスタツール制御部および／または工場ホストなど）を通る必要なしに、データが処理モジュールからＡＰＥＣＳ４００に流れるため、処理モジュールからのデータストリームは、図１および図２で述べたようにデータストリームが他のサーバ（クラスタツール制御部、工場ホストなど）を通して伝送される必要がある場合に起こりうるコンピュータおよび／またはネットワークの条件（コンピュータドリフト、ネットワーク待ち時間、ネットワーク負荷など）による変化を経験しない。さらに、相関を実行するには、関連するデータストリームすべてを受信するための待ち時間が必要であり、解析が大幅に削減される。したがって、異なるソースからのデータの相関は、外部条件（コンピュータドリフト、ネットワーク待ち時間、ネットワーク負荷など）が実質的に排除されれば、大幅に単純化される。
【００７５】
データパスに加えて、単一ソースから粒度の高い大量のデータを得られることから、相関を実行するためのデータポイントがより多く提供されるため、より迅速かつ正確な解析を実行できる。従来技術では、解析サーバが多数のデータソースからの大量のデータを処理できないことから、解析に利用できるデータがたいてい不完全であるため、データソース間の相関は通例困難である。従来技術と異なり、各解析サーバは、限られた数のソース（処理モジュールと、処理モジュールに関連するセンサ）からのデータのみを解析すればよいため、データソースの数は大幅に削減される。データソースの数が大幅に削減されるため、解析サーバが１つのソースについて処理できるデータの量が多くなっている。より粒度の高い詳細データが提供されることを考えると、様々なソースのデータストリーム間で、より良好な相関が実現されうる。
【００７６】
問題（非制御事象など）が特定された場合に、プライマリプロセッサは、処理モジュールに停止命令を送信するよう構成される。一実施形態では、ＡＰＥＣＳ４００から処理モジュールに停止命令を送信するために、直接デジタル出力ライン４５６が用いられる。２つのデバイス間に直接デジタル出力ラインが存在することにより、停止命令を伝送する前に、まず停止命令をイーサネットメッセージに最初に変換する必要がなくなる。したがって、停止命令のフォーマットを適切に合わせて、その後に変換し直すために必要な時間は、実質的に排除される。したがって、ＡＰＥＣＳ４００は、非制御事象に対処するために、リアルタイムの停止命令またはリアルタイムに近い停止命令を処理モジュールに提供することができる。
【００７７】
一実施形態において、プライマリプロセッサは、さらに、パス４５８を介して他のデバイスと相互作用するよう構成されてよい。一例では、クラスタツール制御部がＡＰＥＣＳ４００へ要求を送信した場合、その要求は、パス４５８を介して送信され、プライマリプロセッサ４０２によって処理されてよい。別の例では、工場ホストへの通知が、パス４５８およびクラスタツール制御部を介して送信されてよい。
【００７８】
本発明の１または複数の実施形態からわかるように、処理レベルのトラブルシューティングアーキテクチャが提供されている。解析サーバを処理モジュールレベルに限局させることにより、解析にデータの粒度が加わるため、より迅速かつ正確な解析が実現する。様々なデータソースに同様のデータパスが用いられるため、より良好な相関が様々なデータストリーム間に存在する。より迅速かつ正確な解析により、トラブルシューティングは、次の基板が損傷するのを防ぐだけでなく被害基板に影響する非制御事象を修正する修正動作を提供するために利用可能な修正動作を提供するために、停止命令がタイムリーに提供されるため、よりタイムリーにトラブルシューティングを実行することが可能であり、それによって、影響を受けた基板が損傷するのを防ぐ。したがって、無駄になる基板の数が少なくなり、処理チャンバ構成要素への損傷が実質的に低減されうる。
【００７９】
以上、いくつかの好ましい実施形態を参照しつつ本発明を説明したが、本発明の範囲内で、種々の代替物、置換物、および、等価物が可能である。本明細書では様々な例を提供したが、これらの例は、例示を目的としたものであり、本発明を限定するものではない。
【００８０】
また、発明の名称および発明の概要は、便宜上、本明細書で提供されているものであり、特許請求の範囲を解釈するために用いられるべきものではない。さらに、要約書は、非常に簡潔に書かれており、便宜上提供されているものであるため、特許請求の範囲に記載された発明全体を解釈または限定するために用いられるべきではない。「セット（組）」という用語が用いられている場合には、かかる用語は、一般的に理解される数学的な意味を持ち、０、１、または、２以上の要素を網羅するよう意図されている。また、本発明の方法および装置を実施する他の態様が数多く存在することにも注意されたい。したがって、以下に示す特許請求の範囲は、本発明の真の趣旨および範囲内に含まれる代替物、置換物、および、等価物の全てを網羅するものとして解釈される。
適用例１：プラズマ処理システム内での基板処理を容易にするよう構成されている処理レベルトラブルシューティングアーキテクチャ（ＰＬＴＡ）であって、処理モジュール制御部と、各々が、１または複数の処理パラメータについての検知データを収集するために前記処理モジュール制御部と通信する複数のセンサと、前記複数のセンサおよび前記処理モジュール制御部と直接通信する処理モジュールレベル解析サーバと、を備え、
前記処理モジュールレベル解析サーバは、前記複数のセンサからの前記検知データと、前記処理モジュール制御部からの処理モジュール・チャンバデータとの少なくとも一方を含むデータを受信し、前記データを解析し、前記基板処理中に問題が特定された際に、前記処理モジュール制御部に直接、停止命令データを送信するよう構成される、処理レベルトラブルシューティングアーキテクチャ。
適用例２：適用例１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のセンサの内の第１のセンサは、前記検知データの少なくとも一部を前記処理モジュールレベル解析サーバに送信する前に前処理を実行するための計算モジュールを備える、処理レベルトラブルシューティングアーキテクチャ。
適用例３：適用例２に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバはイーサネットスイッチを備え、前記イーサネットスイッチは、前記処理モジュールレベル解析サーバが前記第１のセンサと通信することを可能にする、処理レベルトラブルシューティングアーキテクチャ。
適用例４：適用例１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のセンサの内の第１センサは、前記検知データの少なくとも一部を前処理することなしに前記第１のセンサから前記処理モジュールレベル解析サーバに直接送信する、処理レベルトラブルシューティングアーキテクチャ。
適用例５：適用例４に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバは、前記第１のセンサによって送信された前記検知データをアナログフォーマットからデジタルフォーマットに変換するためのデータ変換器を備える、処理レベルトラブルシューティングアーキテクチャ。
適用例６：適用例１に記載の処理レベルトラブルシューティングアーキテクチャであって、前記処理モジュールレベル解析サーバは、共有メモリバックボーンを備え、前記共有メモリバックボーンは、複数のプロセッサによってアクセスされ、前記複数のプロセッサの各プロセッサは、前記共有メモリバックボーンを介して前記複数のセンサの内の１センサと少なくとも相互作用するよう構成される、処理レベルトラブルシューティングアーキテクチャ。
適用例７：適用例６に記載の処理レベルトラブルシューティングアーキテクチャであって、前記共有メモリバックボーンは、前記複数のプロセッサ間の負荷バランシング（load balancing）を実行するよう構成される、処理レベルトラブルシューティングアーキテクチャ。
適用例８：適用例７に記載の処理レベルトラブルシューティングアーキテクチャであって、前記共有メモリバックボーンは、前記複数のプロセッサ間に耐障害性を提供するよう構成されている、処理レベルトラブルシューティングアーキテクチャ。
適用例９：適用例６に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、セカンダリプロセッサであり、前記セカンダリプロセッサは、少なくとも、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記検知データを処理するように構成されている、処理レベルトラブルシューティングアーキテクチャ。
適用例１０：適用例９に記載の処理レベルトラブルシューティングアーキテクチャであって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、プライマリプロセッサであり、前記プライマリプロセッサは、前記処理モジュール制御部から前記処理モジュール・チャンバデータを受信し、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記処理モジュール・チャンバデータを前記検知データと相関させ、直接デジタル出力ラインを介して実質的にリアルタイムな停止命令データを前記処理モジュール制御部に送信することの内の少なくとも１つのを実行するよう構成されている、処理レベルトラブルシューティングアーキテクチャ。
適用例１１：プラズマ処理システム内での基板処理中に評価を行うよう構成されている装置であって、前記装置は、処理モジュール制御部および複数のセンサに直接接続されており、前記装置は、前記複数のセンサによって収集された検知データと、前記処理モジュール制御部によって収集された処理モジュール・チャンバデータとの内の少なくとも一方を含むデータを処理するための複数のプロセッサと、前記処理は、前記データを受信する工程、前記データを解析する工程、データ相関を実行する工程、および、問題が特定された際に、停止命令データを前記処理モジュール制御部に送信する工程の内の少なくとも１つを含み、前記複数のプロセッサによってアクセスされる共有メモリバックボーンと、少なくとも前記データを受信するように構成されているインターフェースと、前記複数のプロセッサと前記処理モジュール制御部との間の通信パスである直接デジタル出力ラインと、を備える、装置。
適用例１２：適用例１１に記載の装置であって、前記ネットワークインターフェースは、前記複数のセンサの内の少なくとも第１のサブセットのセンサから、前記検知データを受信するよう構成され、前記第１のサブセットのセンサの内の各センサは、前記ネットワークインターフェースを介して前記検知データの少なくとも一部を前記複数のプロセッサに送信する前に前処理を実行するための計算モジュールを備える、装置。
適用例１３：適用例１２に記載の装置であって、前記ネットワークインターフェースは、イーサネットスイッチである、装置。
適用例１４：適用例１１に記載の装置であって、さらに、前記複数のセンサによって送信された前記検知データを変換するためのデータ変換器を備え、前記データ変換器は、少なくとも、前記検知データの少なくとも一部を前記複数のプロセッサに送信する前に、前記検知データをアナログフォーマットからデジタルフォーマットに変換するように構成されている、装置。
適用例１５：適用例１４に記載の装置であって、前記データ変換器は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）である、装置。
適用例１６：適用例１１に記載の装置であって、前記共有メモリバックボーンは、前記複数のプロセッサ間の負荷バランシングを実行するよう構成されている、装置。
適用例１７：適用例１１に記載の装置であって、前記共有メモリバックボーンは、前記複数のプロセッサ間に耐障害性を提供するよう構成されている、装置。
適用例１８：適用例１１に記載の装置であって、前記複数のプロセッサの各プロセッサは、前記複数のセンサの内の少なくとも１つのセンサと直接通信するよう構成されている、装置。
適用例１９：適用例１８に記載の装置であって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、セカンダリプロセッサであり、前記セカンダリプロセッサは、少なくとも、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記検知データを処理するように構成されている、装置。
適用例２０：適用例１９に記載の装置であって、前記複数のプロセッサの内の少なくとも１つのプロセッサは、プライマリプロセッサであり、前記プライマリプロセッサは、前記処理モジュール制御部から前記処理モジュール・チャンバデータを受信し、前記複数のセンサの内の少なくとも１つのセンサから前記検知データを受信し、前記検知データと前記処理モジュール・チャンバデータとを相関させ、直接デジタル出力ラインを介して前記停止命令データを前記処理モジュール制御部に送信することの内の少なくとも１つのを実行するよう構成されている、装置。
【図１】
0005629315.tif 000002
【図２】
0005629315.tif 000003
【図３】
0005629315.tif 000004
【図４】
0005629315.tif 000005