制御できない事象をプロセスモジュールレベルで特定するための構成とその方法
【解決手段】基板処理中に処理チャンバ内におけるその場での（in-situ）高速過渡事象を検出するための方法が提供される。方法は、第１のデータセットが潜在的なその場での高速過渡事象を含むかどうかを決定するためにデータセットを基準のセット（その場での高速過渡事象）と比較することを含む。もし、第１のデータセットが潜在的なその場での高速過渡事象を含む場合は、方法は、その潜在的なその場での高速過渡事象が発生する期間中に発生する電気的徴候を保存することも含む。方法は、更に、電気的徴候を、保存されたアーク徴候のセットと比較することを含む。もし、一致が決定された場合は、方法は、尚も更に、電気的徴候を第１のその場での高速過渡事象として分類することと、既定の閾値範囲のセットに基づいて第１のその場での高速過渡事象の深刻度レベルを決定することとを含む。
【発明の詳細な説明】
【背景技術】
【０００１】
プラズマ処理における進歩は、半導体産業に成長をもたらした。競争力を持つためには、メーカは、基板を良質な半導体デバイスに加工することができる必要がある。基板処理中に満足のいく結果を達成するためには、プロセスパラメータの厳密な制御が一般的に必要とされる。処理パラメータ（例えば、ＲＦ電力、圧力、バイアス電圧、イオン束、プラズマ密度など）が既定の窓から外れると、望ましくない処理結果（例えば、不良なエッチングプロフィール、低い感度、基板への損傷、処理チャンバへの損傷など）がもたらされる恐れがある。したがって、半導体デバイスの製造では、処理パラメータが既定の窓から外れるときの状況を特定する能力が重要である。
【０００２】
基板処理中は、基板を損傷させえる及び／又は処理チャンバコンポーネントへの損傷を生じえる何らかの制御できない事象が発生する恐れがある。これらの制御できない事象を特定するために、基板処理中にデータが収集されてよい。基板処理中に（バイアス電圧、反射能、圧力などの）様々なプロセスパラメータに関するデータを収集するために、センサなどの監視機器を用いることができる。本明細書で論じられるセンサとは、プラズマ処理コンポーネントの状態及び／又は信号を検出するために使用されえる機器を言う。議論を容易にするために、「コンポーネント」という用語は、処理チャンバ内の不可分な一パーツ又は複数パーツの組み立て品に言及するために使用される。
【０００３】
センサによって収集されるデータのタイプ及び量は、近年増加を続けている。センサによって収集されたデータをプロセスモジュールデータ及びプロセスコンテクストデータ（チャンバ事象データ）との関連で解析することによって、既定の窓から外れたパラメータを特定することが可能である。したがって、（１つ又は２つ以上の）制御できない事象を止めるための（レシピ調節などの）修正措置を提供し、それによって、基板及び／又は処理チャンバコンポーネントへの更なる損傷の発生を阻止することができる。
【図面の簡単な説明】
【０００４】
添付の図面では、本発明は、限定的なものではなく例示的なものとして示され、図中、類似の参照符号は、同様の要素を指している。
【０００５】
【図１】先行技術による、ホストレベル解析サーバを伴った相互接続ツール環境を示した全体的論理図である。
【０００６】
【図２】センサとプロセスモデルコントローラとの間でデータを関連付けるためのクラスタツールレベルの解決法を伴った相互接続ツール環境を示した簡略ブロック図である。
【０００７】
【図３】発明の一実施形態における、プロセスレベルトラブルシューティングアーキテクチャを示した簡略論理全体図である。
【０００８】
【図４】発明の一実施形態における、プロセスモジュールレベル解析サーバを示した簡略機能図である。
【０００９】
【図５】マイクロアーク事象を示した簡略図である。
【００１０】
【図６Ａ】発明の実施形態における、処理環境を示した簡略ブロック図である。
【図６Ｂ】発明の実施形態における、処理環境を示した簡略ブロック図である。
【００１１】
【図７】発明の一実施形態における、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部ではない生産環境内においてリアルタイム高速過渡事象を検出するための方法を示した簡略フローチャートである。
【発明を実施するための形態】
【００１２】
次に、添付の図面に示されるような幾つかの実施形態を参照にして、本発明が詳細に説明される。以下の説明では、本発明の完全な理解を与えるために、多くの詳細が明記されている。しかしながら、当業者ならば、本発明が、これらの一部又は全部の詳細を伴わずとも実施されえることが明らかである。また、本発明を不必要に不明瞭にしないために、周知のプロセス工程及び／又は構造の詳細な説明は省略されている。
【００１３】
方法及び技術を含む様々な実施形態が、以下で説明される。発明は、発明技術の実施形態を実行に移すためのコンピュータ可読命令を格納されたコンピュータ可読媒体を含む製造品も対象としえることを念頭に置かれるべきである。コンピュータ可読媒体としては、例えば、コンピュータ可読コードを格納するための、半導体、磁気、光磁気、光、又はその他の形態のコンピュータ可読媒体が挙げられる。更に、発明は、発明の実施形態を実施するための装置も対象とすることができる。このような装置は、発明の実施形態に関連したタスクを実行に移すための、専用及び／又はプログラム可能な回路を含んでよい。このような装置の例としては、適切にプログラムされたときの汎用コンピュータ及び／又は専用計算機器があり、コンピュータ／計算機器と、発明の実施形態に関連した様々なタスクに適応された専用の／プログラム可能な回路との組み合わせが挙げられる。
【００１４】
上記のように、競争力を得るためには、メーカらは、基板処理中に発生しえる問題を効果的に且つ効率的にトラブルシューティングできなければならない。トラブルシューティングは、一般に、処理中に収集される夥しい量のデータを解析することを伴う。議論を促すために、図１は、先行技術による、ホストレベル解析サーバを伴った相互接続ツール環境を示した全体的論理図である。
【００１５】
例えば、メーカが（エッチングツール、洗浄ツール、剥離ツールなどの）１つ又は２つ以上のクラスタツールを有しえる状況を考える。各クラスタツールは、１つ又は２つ以上の特定の処理を行うように各自構成された複数の処理モジュールを有してよい。各クラスタツールは、ＣＴＣ１０４、ＣＴＣ１０６、及びＣＴＣ１０８などのクラスタツールコントローラ（ＣＴＣ）によって制御されてよい。各クラスタツールコントローラは、ＰＭＣ１１０、ＰＭＣ１１２、ＰＭＣ１１４、及びＰＭＣ１１６などの１つ又は２つ以上のプロセスモジュールコントローラ（ＰＭＣ）とやり取りしてよい。議論を容易にするために、ＰＭＣ１１０との関連で例が挙げられる。
【００１６】
介入を必要としえる状態を特定するために、センサによって、基板処理中に処理パラメータに関するデータ（感知データ）が収集されてよい。一例では、基板処理中に１つ又は２つ以上の処理パラメータに関するデータを収集するために、（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、及び１４０などの）複数のセンサがプロセスモジュールコントローラとやり取りしてよい。利用可能なセンサのタイプは、収集されえるデータのタイプに依存してよい。例えば、センサ１１８は、電圧データを収集するように構成されてよい。別の例では、センサ１２０は、圧力データを収集するように構成されてよい。一般に、プロセスモジュールからデータを収集するために使用されえるセンサは、ブランド、型、及び／又はモデルに違いがある。したがって、各センサは、その他のセンサとほとんど又は全くやり取りしないであろう。
【００１７】
通常、センサは、１つ又は２つ以上の特定のパラメータに関する測定データを収集するように構成される。センサの大半は、処理を実施するようには構成されないので、各センサは、（コンピュータやユーザインターフェースなどの）計算モジュールにつなぐことができる。計算モジュールは、通常、アナログデータを処理するように及び未加工のアナログデータをデジタル形式に変換するように構成される。
【００１８】
一例では、センサ１１８は、センサケーブル１４４を介してＰＭＣ１１０から電圧データを収集する。センサ１１８によって受信されたアナログ電圧データは、計算モジュール１１８ｂによって処理される。センサによって収集されたデータは、（データボックス１４２などの）ホストレベル解析サーバに送信される。ネットワーク接続を通じてデータボックス１４２に送信される前に、データは、先ず、計算モジュールによってアナログ形式からデジタル形式に変換される。一例では、ネットワーク経路１４６を通じてデータボックス１４２にデータが送信される前に、計算モジュール１１８ｂが、センサ１１８によって収集されたアナログデータをデジタル形式に変換する。
【００１９】
データボックス１４２は、センサ及びプロセスモジュールを含む複数のソースからデータを収集し、処理し、解析するように構成された集中解析サーバであってよい。通常、一メーカの全クラスタツールによって基板処理中に収集されるデータの処理に、１つのデータボックスが使用可能である。
【００２０】
データボックス１４２に伝送されえるデータの実際の量は、センサによって収集される量よりも大幅に少ないであろう。通常、センサは、膨大な量のデータを収集することができる。一例では、センサは、最大１メガバイト毎秒のレートでデータを収集することができる。しかしながら、データボックス１４２に送信されるのは、センサによって収集されたデータの一部のみである。
【００２１】
センサによって収集されたデータストリーム全体をデータボックス１４２に伝送しない理由は、１つには、コスト効率の良い市販の通信プロトコルを使用するときのネットワーク帯域幅限界ゆえである。データボックス１４２へのネットワークパイプラインは、（データボックス１４２などの）１つのレシーバに送信されている（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、及び１４０などの）複数のソースからの大量のデータを扱うことができないであろう。つまり、センサ構成（センサ及び計算モジュール）とデータボックス１４２との間のネットワーク経路は、データボックス１４２が全センサ構成からくる膨大な量のデータを受信しようとする際に、大きなトラフィック渋滞に見舞われる恐れがある。上記からわかるように、もし、データボックス１４２が到着トラフィックを扱うことができないと、送信されているデータパケットが脱落して再送信が必要になり、それによって、既に深刻に渋滞しているネットワークパイプラインに更なる負荷がかかる恐れがある。
【００２２】
また、データボックス１４２は、データの処理及び解析などのその他の重要な機能を実施しつつそれと同時に複数ソースからの多量の到着データを扱うことはできないであろう。上記のように、データボックス１４２は、到着するデータパケットを受信するように構成されるのみならず、例えば、到着する全データストリームを処理及び解析するようにも構成される。データボックス１４２は、収集されている種々のデータストリームのための解析サーバであるので、データボックス１４２は、夥しい量のデータストリームに対する解析を実施するための十分な処理能力を必要とする。
【００２３】
データボックス１４２は、処理リソースに限りがあるので、各センサから収集されたデータの一部のみが、データボックス１４２に送信される。一例では、１つのセンサによって収集されえる幾千ものデータ項目のうち、１〜５ヘルツで１０〜１５のデータ項目のみが、データボックス１４２に転送されえる。一例では、センサ１１８によって収集されたデータの概略のみが、データボックス１４２に送信されえる。
【００２４】
複数のセンサからデータを受信することに加えて、データボックス１４２は、プロセスモジュールコントローラからもデータを受信してよい。一例では、各プロセスモジュールコントローラによって、プロセスモジュールデータ及びプロセスコンテクストデータ（チャンバ事象データ）が収集され、データボックス１４２に転送されてよい。議論を容易にするために、プロセスモジュールデータ及びプロセスコンテクストデータは、プロセスモジュール＆チャンバデータとして言及されてもよい。例えば、プロセスモジュールデータ及びプロセスコンテクストデータは、ＰＭＣ１１０によって収集され、経路１４８を介してＣＴＣ１０４に送信されてよい。ＣＴＣ１０４は、ＰＭＣ１１０からのデータを管理するのみならず、クラスタツール内の（ＰＭＣ１１２、ＰＭＣ１１４、及びＰＭＣ１１６などの）その他のプロセスモジュールコントローラからのデータも扱ってよい。
【００２５】
クラスタツールコントローラによって収集されたデータは、次いで、半導体機器通信規格／汎用機器モジュール（ＳＥＣＳ／ＧＥＭ）インターフェースを介してファブホスト１０２に伝送される。一例では、ＣＴＣ１０４は、ＰＭＣ１１０、１１２、１１４、及び／又は１１６から収集されたデータを、経路１５０を介してＳＥＣＳ／ＧＥＭ１５６を通してファブホスト１０２に伝送する。ファブホスト１０２は、ＣＴＣ１０４からのデータのみならず、例えばＣＴＣ１０６及びＣＴＣ１０８などのその他のクラスタツールコントローラからのデータも受信してよい。ファブホスト１０２によって収集されたデータは、次いで、経路１５８を介してデータボックス１４２に転送される。収集されているデータの量の莫大さゆえに、ファブホスト１０２に送信されている全てのデータがデータボックス１４２に転送されるのではなく、多くの場合、データの概略のみがデータボックス１４２に転送されるであろう。
【００２６】
データボックス１４２は、センサ及びプロセスモジュールコントローラによって収集されたデータを処理、解析、及び／又は関連付けてよい。もし、異常が特定された場合は、データボックス１２０は、例えばＰＭＣ１１０において実施されているレシピ工程に適合しないパラメータなどの、問題の原因を決定してよい。ひとたび問題の原因が特定されたら、データボックス１４２は、イーサネットメッセージ（イーサネットは登録商標）の形式でファブホスト１０２に停止命令を送信してよい。メッセージを受信したら、ファブホスト１０２は、そのメッセージを、ＳＥＣＳ／ＧＥＭ１５６を通してＣＴＣ１０４に転送してよい。クラスタツールコントローラは、次いで、メッセージを、この例ではＰＭＣ１１０である意図したプロセスモジュールコントローラへ取り次いでよい。
【００２７】
あいにく、停止命令は、リアルタイムで提供されないのが通常である。それどころか、停止命令は、影響された基板が処理された後に、又はひいては基板ロット全体がプロセスモジュールから退出された後に、意図したプロセスモジュールによって受信されるのが通常である。したがって、基板／基板ロットが損傷されるのみならず、１つ又は２つ以上の処理チャンバコンポーネントも悪影響を受け、それによって、無駄が増えるとともに所有コストが増す恐れがある。
【００２８】
遅延の理由は、１つには、夥しい数のソースから受信されているデータの量の莫大さゆえである。たとえ、データボックス１４２が、高速プロセッサを伴うように構成され、大量のデータストリームを扱うのに十分なメモリを有するとしても、データボックス１４２は、依然、収集されている全てのデータを処理し、関連付け、及び／又は解析するのに時間を要するであろう。
【００２９】
プロセスモジュールによる停止命令の受信が遅延するもう１つの理由は、データボックス１４２によって受信されているデータストリームの不完全さゆえである。データボックス１４２は、夥しい数のソースからデータを受信しているので、データボックス１４２に送信されている実際のデータは、収集されているデータよりも大幅に少ない。一例では、センサ１１８によって収集されている１ギガヘルツのデータストリームを送信する代わりに、データの一部のみ（約１〜５ヘルツ）が実際に送信されている。このため、データボックス１４２は、その全てのソースから多量のデータを受信してはいるが、受信されているデータは、不完全であるのが通常である。したがって、データボックス１４２が、全てのソースからの完全なデータセットにはアクセスできないゆえに、制御できない事象の決定には、時間がかかるであろう。
【００３０】
また、データがデータボックス１４２に送信される経路には、違いがある。一例では、データは、アナログデータからデジタルデータに変換された後に、センサ構成（すなわちセンサ及びその計算モジュール）から直接送信される。反対に、プロセスモジュールによって収集されたデータは、より長いネットワーク経路を通じて（少なくともクラスタツールコントローラ及びファブホストを通して）伝送される。したがって、データボックス１４２は、全ての関連のデータストリームが受信されるまで、その解析を完了することができない。
【００３１】
プロセスモジュールとデータボックス１４２との間のネットワーク経路が長いのみならず、この経路を通して送信されるデータストリームは、少なくとも２つのボトルネックに直面するのが通常である。１つ目のボトルネックは、クラスタツールコントローラにおけるものである。１つのクラスタツール内の複数のプロセスモジュールによって収集されたデータは、１つのクラスタツールコントローラに送信されているので、１つ目のボトルネックは、様々なプロセスモジュールからのデータストリームが１つのクラスタツールコントローラを通して処理されなければならないゆえに発生する。各プロセスモジュールから伝送されえるデータの量の莫大さゆえに、クラスタツールコントローラへのネットワーク経路は、深刻なトラフィック渋滞に見舞われるのが通常である。
【００３２】
ひとたびクラスタツールコントローラによってデータが受信されたら、そのデータは、ファブホスト１０２に伝送される。２つ目のボトルネックは、ファブホスト１０２において発生しえる。ファブホスト１０２が、様々なクラスタツールコントローラからのデータを受信しているゆえに、ファブホスト１０２へのトラフィックもまた、受信されているデータの量の多さゆえに、渋滞に見舞われるであろう。
【００３３】
データボックス１４２は、制御できない事象を決定するために、種々のソースからのデータを必要とするので、プロセスモジュールとデータボックス１４２との間のトラフィック状態は、データボックス１４２へのデータストリームの適時な送達を阻む。その結果、データボックス１４２が解析の実施に必要な全てのデータを集めるまでに、貴重な時間が失われる。更に、ひとたび停止命令が用意されると、その停止命令は、修正措置をとるべく適用されるまでに、同じく非常に長い経路を通って移動して、影響されたプロセスモジュールまで戻る必要がある。
【００３４】
遅延に寄与しているもう１つの要因は、様々なデータソースからのデータを関連付ける難しさにある。データボックス１４２によって受信されているデータストリームは、通常、各センサ及び／又はプロセスモジュールから収集されたデータの概略であるので、データの関連付けは、利用可能なデータストリームの時間間隔に違いがあるゆえに、難しい作業になる恐れがある。一例では、センサ１１８からデータボックス１４２に伝送される選択されたデータストリームが、１秒間隔である一方で、ＰＭＣ１１０からのデータストリームは、２秒間隔である。したがって、データストリームの関連付けは、制御できない事象が明確に決定されえるまでに、時間を要するであろう。
【００３５】
データを関連付けることの更なる難しさは、データがデータボックス１４２に送信される経路の違いに起因する。データは、種々のコンピュータやサーバなどを通して伝送されているゆえに、コンピュータドリフト、ネットワーク待ち時間、ネットワーク負荷などに見舞われるであろう。その結果、データボックス１４２は、様々なソースからのデータを関連付けるのが困難であろう。制御できない事象を迅速に特定するには、厳密な関連付けが必要であるゆえに、制御できない事象が正確に特定されえる前には、更なる解析の実施が必要であろう。
【００３６】
図１に提供されている解決策のもう１つの欠点は、所有コストである。クラスタツールシステムを維持するコストに加えて、センサ構成には、更なるコストがかかわっている。各センサは、ブランド／型／モデルに違いがあるので、各センサ構成は、センサと計算モジュールとを含むのが通常である。通常は、各センサ構成を収容するための物理的空間が必要とされる。したがって、特に、不動産価格が高いエリアでは、センサ構成の収容コストが高くつく恐れがある。
【００３７】
プロセスモジュール内における制御できない事象の実際の発生と、プロセスモジュールによる停止命令の受信との間の実際の時間遅延を短縮するために、クラスタレベル解析サーバが提供される。図２は、センサとプロセスモデルコントローラとの間でデータを関連付けるためのクラスタツールレベルの解決法を伴った相互接続ツール環境を示した簡略ブロック図である。
【００３８】
図１と同様に、クラスタツールは、（ＰＭＣ２１０、２１２、２１４、及び２１６などの）複数のプロセスモジュールを含んでよい。解析のためのデータを収集するために、各プロセスモジュールは、（センサ２１８、２２０、２２２、２２４、２２６、２２８、２３０、２３２、２３４、２３６、２３８、及び２４０などの）複数のセンサにつながれてよい。各センサは、処理パラメータデータを収集するために、（センサケーブル２４４などの）センサケーブルを介して対応するプロセスモジュールコントローラとやり取りしてよい。センサによって収集されるデータは、アナログ形式であってよい。（計算モジュール２１８ｂなどの）計算モジュールは、経路２４６を介して（リモートコントローラ２４２などの）クラスタレベル解析サーバに転送する前に、データを処理してデジタル形式に変換してよい。
【００３９】
図１と同様に、各プロセスモジュールコントローラは、（プロセスモジュールデータ及びプロセスコンテクストデータなどの）データを（ＣＴＣ２０４及び２０６などの）クラスタツールコントローラにも伝送してよい。一例では、ＰＭＣ２１０によって収集されたデータは、経路２４８を介してＣＴＣ２０４に伝送されてよい。ＰＭＣ２１０からのデータを受信する以外に、ＣＴＣ２０４は、（ＰＭＣ２１２、２１４、及び２１６などの）その他の処理モジュールコントローラからのデータも受信してよい。クラスタツールコントローラによって受信されたデータは、次いで、経路２５０を介してファブホスト２０２に転送される。
【００４０】
ファブホスト２０２とＣＴＣ２０４との間では、ファブホスト２０２に転送されるデータを複製するためのシリアルタップがネットワーク経路２５０につながれてよい。一例において、ＣＴＣ２０４によってファブホスト２０２に転送されるデータは、シリアルタップ２０８によって傍受されてよい。データは、複製され、データストリームのコピーが、経路２５４を介してリモートコントローラ２４２に送信される。もし、ファブホストが２つ以上のクラスタツールコントローラにつながれている場合は、その各クラスタツールコントローラに、専用のリモートコントローラが結び付いている。一例において、経路２５２を介してＣＴＣ２０６からファブホスト２０２に送信されているデータは、別のシリアルタップ（２５６）によって傍受される。データは、複製され、ＣＴＣ２０４に結び付いているリモートコントローラ（２４２）とは異なるリモートコントローラ（２６０）に経路２５８を介して送信される。
【００４１】
したがって、様々なクラスタツールからの全てのデータを１つのデータボックスによって扱う代わりに、様々なクラスタツールからのデータを扱うために、複数のリモートコントローラが利用可能になる。つまり、各クラスタツールが、それ自身のリモートコントローラに結び付いている。各リモートコントローラが、（１つのクラスタツールに結び付いているプロセスモジュールコントローラ及びセンサのように）より少ない数のデータソースからのデータを扱うので、各リモートコントローラは、各ソースから、より多量のデータを扱うことができる。一例では、３０〜１００のデータ項目が送信される代わりに、１０ヘルツで約４０ｋＢ〜１００ｋＢのデータ項目が各リモートコントローラによって受信可能になるであろう。
【００４２】
センサ及びプロセスモジュールコントローラから受信されたデータは、リモートコントローラによって解析される。もし、問題が特定された場合は、リモートコントローラは、クラスタツールコントローラに停止命令を送信してよい。一例では、リモートコントローラ２４２は、ＰＭＣ２１０内における問題を特定する。経路２５４及び経路２５０を介し、シリアルタップ２０８を通してＣＴＣ２０４に停止命令が送信される。停止命令を受信したら、ＣＴＣ２０４は、その停止命令を、この例ではＰＭＣ２１０である意図したプロセスモジュールコントローラに転送する。
【００４３】
リモートコントローラは、（データボックス１４２によってなされているように）複数のクラスタツールからではなく、１つのクラスタツールからのデータを扱う責任のみを担うので、より多くのデータが解析されえるとともに、より優れた関連付けが異なるデータセット間に存在しえる。その結果、リモートコントローラは、より優れた且つより高速な解析を実施することができ、それによって、処理モジュール内における制御できない事象を修正するためのより適時な介入を提供することができる。一例では、特定された制御できない事象を次の基板ロットで発生させないために（データボックス１４２によって提供される停止命令などの）停止命令を受信するのではなく、例えばリモートコントローラ２４２によって送信された停止命令によって、処理を予定されている基板ロットの少なくとも一部をプロセスエンジニアが救出することを可能にすることができる。
【００４４】
リモートコントローラ解決法は、データボックス解決法よりも優れてはいるが、リモートコントローラ解決法は、依然、その解析を実施するために概略データに依存している。したがって、基板処理中に発生しえる問題は、特定されないままになる恐れがある。更に、プロセスモジュールとリモートコントローラとの間の経路は、依然、直接的な経路ではない。その結果、コンピュータドリフト、ネットワーク待ち時間、及び／又はネットワーク負荷が時間的な不一致を招く恐れがあり、これは、リモートコントローラがセンサからのデータをプロセスモジュールからのデータに関連付けることを困難にする恐れがある。
【００４５】
このため、リモートコントローラ解決法は、停止命令の適時性を向上させたとはいえ、依然として不十分である。停止命令は、影響された基板が被った問題を、次の基板の処理中に発生させないようにできるのがせいぜいである。コストを最小限に抑える必要がある競争が熾烈な市場では、基板の損傷ゆえの無駄及び／又は処理チャンバコンポーネントの損傷ゆえのダウンタイムが市場損失につながる恐れがある。したがって、制御できない事象を特定するためのリアルタイムな解決策が望まれている。
【００４６】
本発明の実施形態にしたがって、トラベルシューティングがプロセスモジュールレベルで実施されるプロセスレベルトラベルシューティングアーキテクチャ（ＰＬＴＡ）が提供される。発明の実施形態は、リアルタイムな停止命令を伴ったリアルタイムな解析を提供するプロセスレベルトラブルシューティングアーキテクチャを含む。発明の実施形態は、更に、センサ間における負荷バランス及び耐障害性のための構成を含む。
【００４７】
発明の実施形態において、プロセスレベルトラブルシューティングアーキテクチャは、解析サーバが１つの処理モジュール及びそれに対応するセンサと通信しているネットワークシステムである。一実施形態において、ネットワーク内において交換されている情報は、双方向である。一例では、解析サーバは、処理モジュール及びセンサからプロセスデータを継続的に受信してよい。反対に、センサは、処理モジュールからデータを受信してよく、処理モジュールは、解析サーバから命令を受信してよい。
【００４８】
例えば、基板が処理されている状況を考える。基板処理中は、複数のデータが収集されてよい。一例では、圧力に関するデータが１００ミリ秒ごとに収集される。もし、処理に１時間かかる場合は、圧力パラメータについて３６，０００のデータ項目が収集されている。ただし、圧力データ以外のその他の複数のプロセスデータ（例えば電圧バイアスや温度など）も収集されてよい。したがって、基板の処理が完了した時点では、かなりの量のデータが収集されている。
【００４９】
先行技術では、データは、もし（データボックス１４２のように）複数のクラスタツールから収集されるデータを扱うように構成されるのでないとしても（図２のリモートコントローラ２４２のように）複数の処理モジュールから収集されるデータを扱うように構成されるであろう解析サーバに伝送される。データストリームは、複数のソースから来るので、データの解析及び／又は関連付けは、時間を要する。更に、先行技術の解析サーバは、収集された全てのデータを処理及び解析することはできないので、各ソースから収集されたデータの一部のみが、解析サーバに伝送される。その結果、データストリームの整合、処理、関連付け、及び／又は解析を行う複雑な作業は、必ずしも常に容易に調達可能ではない長さの時間を要する。
【００５０】
発明の一態様において、本願の発明者らは、もし、より粒度の高いデータが解析のために利用可能であれば、より正確で且つより迅速な解析が実施されえることに気付いた。１つのソースから、より多くのデータを解析するためには、解析サーバは、より少ないソースからのデータを解析しなければならない。一実施形態では、プロセスモジュールレベルでデータを処理及び／又は解析するための構成が提供される。つまり、各プロセスモジュール及びその対応するセンサのための解析を実施するためのプロセスモジュールレベル解析サーバが提供される。
【００５１】
一実施形態において、プロセスモジュールレベル解析サーバは、１つ又は２つ以上のプロセッサを含みえる共有メモリバックボーンを含む。各プロセッサは、１つ又は２つ以上のセンサとやり取りするように構成されてよい。一例では、センサ１によって収集されたデータが、プロセッサ１によって処理されえる一方で、センサ２によって収集されたデータは、プロセッサ２によって処理されえる。
【００５２】
先行技術と異なり、プロセッサは、負荷バランス及び耐障害性を実施するために、その処理能力を互いに共有することができる。先行技術において、各計算モジュールは、１つのセンサによって収集されたデータを扱うように構成される。各計算モジュールは、個別のユニットであり、互いにやり取りしないのが通常であるので、負荷バランスは、通常は実施されない。先行技術と異なり、プロセスモジュールレベル解析サーバ内におけるプロセッサのセットは、負荷バランスを実施することができる。一例において、もし、プロセッサ１がデータ過負荷を受けている一方で、プロセッサ２がほとんど又は全くデータを受信していない場合は、プロセッサ１がセンサ１からのデータを処理するのを助けるために、プロセッサ２を充てることが可能である。
【００５３】
更に、先行技術において、計算モジュールは、ブランド／型／モデルが異なる傾向にあるので、もし、１つの計算モジュールが誤動作している場合は、その他の計算モジュールは、その誤動作している計算モジュールによって実施される処理を引き継ぐことができない。先行技術と異なり、プロセッサ間で、必要に応じて作業負荷を再分配することが可能である。例えば、もし、プロセッサ２がその機能を実施することができない場合は、プロセッサ２が修復されるまで、作業負荷をその他のプロセッサに再分配することが可能である。上記からわかるように、プロセッサは、個別の計算モジュールの必要性を排除し、それによって、計算モジュールの収容に必要とされる物理的空間も削減する。
【００５４】
発明の一実施形態において、プロセッサは、２つのタイプのプロセッサ、すなわちプライマリプロセッサとセカンダリプロセッサとに分けられてよい。プライマリプロセッサ及びセカンダリプロセッサは、ともに、センサからのデータを扱うように構成される。一例において、もし、セカンダリプロセッサ１がセンサ１に結び付いている場合は、セカンダリプロセッサ１は、センサ１から来るデータのみを処理するのが通常である。同様に、もし、セカンダリプロセッサ２がセンサ２及びセンサ３に結び付いている場合は、セカンダリプロセッサ２は、これらのセンサ（２及び３）から来るデータのみを処理するのが通常である。
【００５５】
一実施形態において、共有メモリバックボーンは、１つ又は２つ以上のプライマリプロセッサを含んでよい。プライマリプロセッサのセットは、センサからのデータを扱うのみならず、処理モジュールから来るデータを扱うようにも構成されてよい。また、プライマリプロセッサのセットは、（センサや処理モジュールなどの）様々なソース間でデータを関連付けて解析を実施するように構成される。もし、停止が必要な場合は、プライマリプロセッサのセットは、プロセスモジュールコントローラに停止命令を送信するように構成される。
【００５６】
本発明の特徴及び利点は、以下の図面及び議論を参照にして、より良く理解されるであろう。
【００５７】
図３は、発明の一実施形態における、プロセスレベルトラブルシューティングアーキテクチャを示した簡略論理全体図である。メーカは、２つ以上のクラスタツールを有してよいが、発明の一実施形態の説明としては、１つのクラスタツールが使用されるとする。クラスタツールは、様々な数の処理モジュールを有してよいが、図３に示された例は、４つの処理モジュールを伴った１つのクラスタツールを含むとする。
【００５８】
各処理モジュールによって収集されたデータは、その対応する処理モジュールコントローラ（ＰＭＣ３０６、ＰＭＣ３０８、ＰＭＣ３１０、及びＰＭＣ３１２）によって収集され、クラスタツールコントローラ（ＣＴＣ）３０４を介してファブホスト３０２に伝送される。ＰＭＣによって伝送されえるデータは、先行技術において送信されていたのと同じタイプのデータ（プロセスモジュールデータ及びプロセスコンテクストデータ）であってよい。先行技術と異なり、ファブホスト３０２に伝送されるデータは、トラブルシューティングの実施のために処理モジュールが依存するデータではなく、将来の解析に備えてアーカイブに保管されて利用可能にされるデータである。
【００５９】
一実施形態では、トラブルシューティングのために必要とされる解析を実施するために、プロセスモジュールレベル解析サーバ（ＡＰＥＣＳ３１４）が提供される。ＰＭＣ３０８内において基板がエッチングされている状況を考える。基板処理中に、センサ３１６、３１８、及び３２０は、ＰＭＣ３０８からデータを収集している。一例では、センサ３１６は、ＰＭＣ３０８から電圧バイアスデータを収集するように構成される。ＰＭＣ３０８から収集されたアナログデータは、センサケーブル３２８を介してセンサ３１６に送信される。同様に、センサ３１８及びセンサ３２０は、それぞれセンサケーブル３３０及びケーブル３３２を介してデータを収集してよい。センサによって収集されたデータは、次いで、処理及び／又は解析のために、経路３２２、３２４、及び３２６のいずれかを介してＡＰＥＣＳ３１４に伝送されてよい。
【００６０】
先行技術と異なり、センサによって収集されたデータは、解析サーバ（ＡＰＥＣＳ３１４）に伝送される前に（例えば概略化などの）前処理を経る必要がない。一実施形態では、データを処理するための計算モジュールを有する代わりに、各センサは、データをＡＰＥＣＳ３１４に転送する前にアナログデータをデジタルデータに変換するために使用されえる単純なデータコンバータを含んでよい。或いは、一実施形態では、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのデータコンバータが、ＡＰＥＣＳ３１４に組み込まれてよい。一例では、各プロセッサは、その処理の一環としてデータをデジタル形式に変換するためのデータコンバータアルゴリズムを含んでよい。上記からわかるように、計算モジュールの必要性を排除することによって、クラスタツール及びそのハードウェアの収容に必要とされる物理的空間が小さくてすむ。その結果、所有のコストを削減することができる。
【００６１】
ＡＰＥＣＳ３１４は、１つの処理モジュール及びその対応するセンサからのデータのみを処理するのに専念するので、１つのソースから、より多量のデータを扱うことができる。つまり、各センサから伝送されたデータの量を減らさなければならない代わりに、ＡＰＥＣＳ３１４は、各センサによって収集されたデータの、たとえ全部ではなくとも大半を扱うように構成される。一例では、解析のために僅か１０〜１５のデータ項目が送信される代わりに、各センサから二千強のデータ項目がＡＰＥＣＳ３１４による解析のために利用可能になるであろう。したがって、処理及び解析のためにＡＰＥＣＳ３１４によって利用可能なデータストリームは、より完全なデータセットになる。
【００６２】
一実施形態において、ＡＰＥＣＳ３１４は、処理モジュールから来るデータを扱うようにも構成される。データストリームが、（データボックス又はリモートコントローラなどの）解析サーバによって受信される前に（例えばクラスタツールコントローラやファブホストなどの）様々なサーバを通る長いデータ経路を経て送信される先行技術と異なり、プロセスモジュールによって収集されたデータは、その他のサーバを通る必要なくＡＰＥＣＳ３１４に直接送信される。一例では、プロセスモジュールデータは、経路３３４を介してＰＭＣ３０８からＡＰＥＣＳ３１４に送信されてよい。もし、制御できない事象が特定された場合は、停止命令は、先ずその他のサーバを経る必要なく経路３３６を介してＰＭＣ３０８に直接送信されてよい。
【００６３】
プロセスモジュールレベル解析サーバに関する更なる詳細が、図４に提供されている。図４は、発明の一実施形態における、プロセスモジュールレベル解析サーバを示した簡略機能図である。各プロセスモジュールには、（ＡＰＥＣＳ４００などの）プロセスモジュールレベル解析サーバが割り当てられてよい。ＡＰＥＣＳ４００は、双方向サーバであり、到着するデータを処理するように及び制御できない事象が特定されたときに停止命令を送信するように構成される。
【００６４】
データソースは、２つの主なソース、すなわちセンサによって収集されたデータ及びプロセスモジュールによって収集されたデータから来るであろう。一実施形態において、ＡＰＥＣＳ４００は、複数のセンサ（センサ４１０、４１２、４１４、４１６、４２０、４２２、４２４、及び４２６）からの到着データを受信するように構成される。クラスタツール所有者には、従来のセンサ構成（計算モジュールを伴ったセンサ）に既に多額の資金を投じた者がいるかもしれないので、ＡＰＥＣＳ４００は、従来のセンサ構成及び改良されたセンサ（計算モジュールを必要としないセンサ）の両方からデータを受け入れるように構成される。
【００６５】
一実施形態において、ＡＰＥＣＳ４００は、イーサネットスイッチ４１８のような、（センサ４１０、４１２、４１４、４１６などの）従来のセンサ構成とやり取りするためのインターフェースを含んでよい。一例では、センサ４１０によって収集されたデータは、デジタルデータとして（経路４３０、４３２、４３４、及び４３６を介して）ＡＰＥＣＳ４００に伝送される前に、先ず、計算モジュール４１０ｂによってアナログ形式からデジタル形式に変換される。イーサネットスイッチ４１８は、データストリームを受け入れるために、従来のセンサ構成とやり取りするように構成される。データストリームは、次いで、処理のために、（経路４４６、４４８、４５０、又は４５２を介して）ＡＰＥＣＳ４００内のプロセッサ（４０２、４０４、４０６、及び４０８）の１つに引き渡される。
【００６６】
プロセスパラメータを測定するために従来のセンサ構成を用いる代わりに、改良されたセンサ（計算モジュールを伴わないもの）が使用されてよい。収集されたデータは、概略化される必要がないので、処理のための計算モジュールは、もはや必要なくなる。その代わり、一実施形態では、改良されたセンサは、安価なＦＰＧＡのような、データをアナログ形式からデジタル形式に変換するためのデータコンバータ（不図示）を含んでよい。或いは、センサ内にデータコンバータを実装する代わりに、ＡＰＥＣＳ４００内にデータコンバータ（不図示）が実装されてよい。データコンバータがＡＰＥＣＳ４００の外又は内のいずれに実装されるかにかかわらず、計算モジュールの排除は、クラスタツールの所有におけるコスのト節約を可能にする。一例では、計算モジュールを購入、収容、及び維持するためのコストが大幅に削減される。
【００６７】
発明の一実施形態において、ＡＰＥＣＳ４００は、到着データを扱うためのプロセッサのセット（４０２、４０４、４０６、及び４０８）を含む。プロセッサのセットは、物理的処理ユニット、仮想プロセッサ、又はそれらの組み合わせであってよい。各プロセッサは、プロセッサに結び付いているソースからのデータストリームを扱う責任を担っている。一例では、経路４４０を介してセンサ４２２から流入するデータストリームが、プロセッサ４０４によって扱われる。別の一例では、センサ４２４によって収集されたデータストリームが、処理のために、経路４４２を介してプロセッサ４０６に伝送される。
【００６８】
プロセッサの数と、プロセッサとセンサとの間の関係は、ユーザの設定に依存してよい。一例において、図４は、プロセッサとセンサとの間の１対１の関係のみを示しているが、その他の関係も存在することが可能である。一例では、１つのプロセッサが、２つ以上のソースからのデータを扱うように構成されてよい。別の例では、１つのセンサからのデータストリームを、２つ以上のプロセッサが扱うように構成されてよい。
【００６９】
各プロセッサは、一実施形態では、共有メモリバックボーン４２８を共有する。したがって、１つ又は２つ以上のプロセッサが過負荷になったときは、負荷バランシングが実施されてよい。一例において、もし、経路４４４を介してセンサ４２６から流入するデータストリームが、プロセッサ４０８の処理能力を上回る場合は、プロセッサ４０８にかかる負荷の軽減を助けるために、その他のプロセッサを充てることが可能である。
【００７０】
負荷バランシング以外に、共有メモリバックボーンは、耐障害性のための環境も提供する。つまり、もし、プロセッサの１つが正常に動作していない場合は、その誤動作しているプロセッサによってこれまでサポートされていた処理は、その他のプロセッサに再分配される。一例において、もし、プロセッサ４０６が正常に機能しておらず、センサ４２４から来るデータストリームを処理することができない場合は、センサ４２４からのデータストリームを扱うように、プロセッサ４０４を仕向けることが可能である。したがって、作業負荷を再分配する能力は、サーバ全体のダウンタイムを招くことなく正常に機能していないプロセッサが交換されることを可能にする。
【００７１】
一実施形態では、ＡＰＥＣＳ４００内に２つのタイプのプロセッサが存在してよい。第１のタイプのプロセッサは、セカンダリプロセッサ（プロセッサ４０４、４０６、又は４０８）である。各セカンダリプロセッサは、その対応する（１つ又は２つ以上の）センサから受信されたデータストリームを処理するように構成される。また、一実施形態において、各プロセッサは、データを解析するように及び（１つ又は２つ以上の）対応するセンサに存在しえるあらゆる潜在的な問題を特定するように構成される。
【００７２】
第２のタイプのプロセッサは、プライマリプロセッサ（４０２）として知られる。図４は、プライマリプロセッサを１つのみ示しているが、プライマリプロセッサの数は、ユーザの設定に依存してよい。一実施形態では、プライマリプロセッサは、１つ又は２つ以上のセンサからのデータストリームを扱うように構成されてよい。一例では、センサ４２０によって収集されたデータストリームは、処理のために、経路４３８を介してプライマリプロセッサ４０２に送信される。
【００７３】
プライマリプロセッサのもう１つのデータソースは、プロセスモジュールである。つまり、プロセスモジュールによって収集されたプロセスモジュールデータ及びプロセスコンテクストデータが、プライマリプロセッサによって処理される。一例において、プロセスモジュールによって収集されたデータは、プロセス制御バスを通って経路４５４を介してＡＰＥＣＳ４００に送信される。データは、経路４４６を介してプライマリプロセッサ４０２に流入する前に、先ず、イーサネットスイッチ４１８を通る。
【００７４】
データ処理に加えて、プライマリプロセッサは、複数ソースからのデータを解析するようにも構成される。一例では、センサ４２２からのデータストリームとセンサ４２４からのデータストリームとの間の関連付けが、プライマリプロセッサ４０２によって実施される。別の例では、１つ又は２つ以上のセンサからのデータストリームとプロセスモジュールからのデータストリームとの間の関連付けも、プライマリプロセッサ４０２によって実施される。
【００７５】
各データソースのためのデータ経路が、ほぼ同様の長さになるので、データの関連付けは、先行技術におけるよりも、大幅に困難でなくなる。一例において、データは、（クラスタツールコントローラ及び／又はファブホストなどの）その他のサーバを通る必要なくプロセスモジュールからＡＰＥＣＳ４００へ流れるので、プロセスモジュールからのデータストリームは、図１及び図２で説明されたようにデータストリームが（クラスタツールコントローラやファブホストなどの）その他のサーバを通って伝送されなければならないときに発生しえる（コンピュータドリフト、コンピュータ待ち時間、ネットワーク負荷などの）コンピュータ及び／又はネットワークの状態に起因する変化に見舞われない。また、関連付け及び解析の実施に必要とされる全ての関連データストリームを受信するための待ち時間も、大幅に短縮される。このように、（コンピュータドリフト、コンピュータ待ち時間、ネットワーク負荷などの）外部状況が実質的に排除されたとき、異なるソースからのデータの関連付けは、大幅に簡略化される。
【００７６】
データ経路以外にも、１つのソースからの、より粒度が高く且つより多量のデータは、関連付けを実施するためのデータ点をより多く提供するので、より迅速で且つより正確な解析の実施が可能になる。先行技術において、先行技術の解析サーバは、夥しい数のデータソースからの多量のデータを扱うことができないので、解析のために利用可能なデータは、不完全であるのが通常であり、ゆえに、データソース間の関連付けは、困難であるのが通常である。先行技術と異なり、各解析サーバは、限られた数のソース（プロセスモジュール及びそれに結び付いているセンサ）からのデータを解析する責任のみを担うので、データソースの数は、大幅に減少される。データソースの数が大幅に減少されているので、解析サーバは、１つのソースから、より多量のデータを扱う容量を有する。より粒度の高い詳細が提供されれば、様々なソースのデータストリーム間で、より優れた関連付けが達成されるであろう。
【００７７】
もし、（制御できない事象などの）問題が特定された場合は、プライマリプロセッサは、プロセスモジュールに停止命令を送信するように構成される。一実施形態では、ＡＰＥＣＳ４００からプロセスモジュールに停止命令を送信するために、直接的なデジタル出力回線４５６が用いられる。２つのデバイス間の直接的なデジタル出力回線によって、停止命令は、伝送される前に先ずイーサネットメッセージに変換される必要がなくなる。したがって、停止命令を適切な形式にするために及びそれを変換しなおして戻すために必要な時間が、実質的に解消される。このため、ＡＰＥＣＳ４００は、制御できない事象を扱うためにリアルタイムな停止又はほぼリアルタイムな停止をプロセスモジュールに提供することができる。
【００７８】
一実施形態では、プライマリプロセッサは、経路４５８を介してその他のデバイスとやり取りするようにも構成されてよい。一例において、もし、クラスタツールコントローラがＡＰＥＣＳ４００にリクエストを送信した場合は、そのリクエストは、経路４５８を介して送信されてプライマリプロセッサ４０２によって扱われてよい。別の例では、ファブホストへの通知が、経路４５８及びクラスタツールコントローラを介して送信されてよい。
【００７９】
本発明の１つ又は２つ以上の実施形態からわかるように、プロセスレベルトラベルシューティングアーキテクチャが提供される。解析サーバをプロセスモジュールレベルに局在させることによって、解析のためのデータ粒度が提供され、その結果、より迅速で且つより正確な解析がもたらされる。様々なデータソースのためのデータ経路が同様であることによって、様々なデータストリーム間に、より優れた関連付けが存在する。より迅速で且つより正確な解析によって、より適時にトラブルシューティングを実施し、次の基板が損傷されるのを阻止するためだけでなく被害基板に影響を及ぼす制御できない事象を修理するためにも使用されえる修正措置をとらせることによって被害基板を損傷から救出するための停止命令を適時に提供することが可能である。このため、無駄にされる基板の数が少なくてすみ、処理チャンバコンポーネントへの損傷が大幅に低減される。
【００８０】
発明の別の態様では、本願の発明者らは、適時で、迅速で、且つ正確な解析を実施することができるプロセスレベルトラブルシューティングアーキテクチャによって、（マイクロアーク事象、デチャック事象、スパイク事象などの）高速過渡事象をリアルタイムでのその場での検出が特定及び管理されえることに気付いた。本明細書で論じられる高速過渡事象とは、基板処理中に急速に且つ通常は短期間にわたって発生しえる（マイクロアーク事象、デチャック事象、スパイク事象などの）事象を言う。高速過渡事象を特定する作業は、各事象の速さ及び短い持続時間のゆえに、通常は、できる限り、基板ロット全体が処理された後にオフラインで実施されてきた。
【００８１】
一例では、例えば光計測ツールを使用して、１枚又は２枚以上の基板が検査されるとする。あいにく、検査は、リアルタイム検出を提供しない。それどころか、例えばマイクロアーク事象が基板上で発生しているとして特定された時点では、その基板が損傷されているのみならず、その基板ロットの残りも損傷されている恐れがある。また、処理チャンバ内のハードウェアコンポーネントへの損傷も発生している恐れがある。
【００８２】
近年では、（高速過渡事象の結果である）高速過渡の電気的徴候が捕獲されることを可能にする高速過渡センサが開発されている。しかしながら、高速過渡センサの大半は、電気的徴候を分類する能力を有さない。つまり、高速過渡センサは、データを収集することはできるが、そのデータを有害な可能性のある事象の特定に使用されえる意味ある電気的徴候に分類する能力は有さないのが通常である。
【００８３】
例えば、エッチングプロセス中に、電荷が蓄積してマイクロアーク事象を発生させる状況を考える。本明細書で論じられるマイクロアークとは、電力が急激に散逸してその散逸が基板上のパターンに（層の破壊、パターンの破壊、層の融解などの）損傷を及ぼすときに発生する事象を言う。ＶＩプローブを用いることによって、マイクロアークに関するデータが収集されえる。しかしながら、ＶＩプローブなどの高速過渡センサの大半は、データを解釈してマイクロアーク事象などの高速過渡事象がいつ生じたかを特定する知能を欠いている。
【００８４】
それどころか、高速過渡センサによって収集されたデータは、人間であるユーザなどの第三者によって、又はソフトウェアプログラムによって、解析されなければならないであろう。一例では、人間であるユーザが、夥しい量のデータを解析し、基板処理中に高速過渡事象が発生したかどうかの決定を（自身の専門知識に基づいて）下さなければならないであろう。データを解析する作業は、何週間まではいかなくても何時間はかかるであろう。たとえデータ解析がソフトウェアプログラムによって実施されるとしても、何百万ものデータサンプルの解析は、やはり時間を要するであろう。問題が特定されたときには、１つ若しくは２つ以上の基板ロットへの損傷及び／又は処理チャンバのハードウェアコンポーネントへの損傷が既に生じている恐れがある。
【００８５】
マイクロアーク事象は、通常は予測可能な現象ではないので、マイクロアーク事象などの高速過渡事象の検出は、困難な作業である恐れがある。つまり、例えばマイクロアークは、必ずしも全ての基板上で発生するものではない。発明の一態様において、本願の発明者らは、たとえマイクロアーク事象のタイミングが予測不能であっても、マイクロアーク事象の電気的徴候はそうではないことに気付いた。つまり、各マイクロアーク事象は、固有の徴候によって表すことが可能である。
【００８６】
図５は、マイクロアーク事象を示した簡略図（曲線５０２）である。曲線５０２からわかるように、オンウエハマイクロアーク事象が発生するときに、電圧信号及び電流信号は、同時に急降下（５０４）に見舞われる。次いで、電圧信号及び電流信号は、両信号が降下した時点とは異なるレベルかもしれない平坦域（５０６）へ徐々に上昇するのに伴って、逆減衰を経る。
【００８７】
発明の実施形態にしたがって、プラズマ処理システムの処理チャンバ内におけるマイクロアーク事象などの高速過渡事象を扱うための方法と構成とが提供される。発明の実施形態は、高速過渡事象（例えばマイクロアーク）を検出するための方法を含む。発明の実施形態は、また、高速過渡の電気的徴候を、（アーク徴候などの）既知の高速過渡の徴候との徴候の比較の実施によって分類するための方法も含む。発明の実施形態は、更に、高速過渡事象の深刻度を分類するための方法も含む。発明の実施形態は、尚も更に、リアルタイムな生産環境中における損傷を最小限に抑えるために高速過渡事象を管理するための方法も含む。
【００８８】
本文献では、マイクロアークを一例として使用して、様々な実装形態が論じられる。本発明は、しかしながら、マイクロアークに限定されず、基板処理中に発生しえる任意の高速過渡事象を含むことが可能である。むしろ、議論は、例示を意図しており、発明は、提示された例に限定されない。
【００８９】
発明の一実施形態において、潜在的なマイクロアーク事象を検出するための方法と構成とが提供される。前述のように、高いサンプリング率を実施する（例えば１秒間に幾百万又は幾十億ものデータ点を収集する）ことができる（ＶＩプローブなどの）高速過渡センサが、基板処理中にデータを収集するために用いられてよい。一実施形態では、例えばＶＩプローブが基板処理中にデータを収集している間に、高速サンプリング過渡検出アルゴリズムが実行されてよい。一実施形態では、高速サンプリング過渡検出アルゴリズムは、潜在的な高速過渡の電気信号を定義するための基準を含んでよい。一例では、潜在的なオンウエハマイクロアーク事象を特定するために、高速サンプリング過渡検出アルゴリズムを使用して、電圧信号及び電流信号がともに同時に降下する事象を探すことが可能である。別の例では、潜在的なチャンバマイクロアーク事象を特定するために、高速サンプリング過渡検出アルゴリズムを使用して、電圧信号及び電流信号がともに急上昇する事象を探すことが可能である。
【００９０】
一実施形態では、高速サンプリング過渡アルゴリズムは、（ＶＩプローブコントローラなどの）センサコントローラによって実施される。このセンサコントローラは、センサ（例えばＶＩプローブ）につながれてセンサ（例えばＶＩプローブ）とのインターフェースを提供するように及びセンサ（例えばＩＶプローブ）からデータを受信するように構成された計算モジュールである。別の実施形態では、高速サンプリング過渡アルゴリズムは、センサコントローラ（例えばＶＩプローブコントローラ）とやり取りする計算モジュールによって実施される。更に別の実施形態では、高速サンプリング過渡アルゴリズムは、センサ（例えばＶＩプローブ）と直接やり取りする解析モジュールによって実施される。
【００９１】
もし、センサ（例えばＩＶプローブ）又はセンサ（例えばＩＶプローブ）とやり取りしている計算モジュールのいずれかによって、潜在的なマイクロアーク事象が特定された場合は、一実施形態では、その事象の発生の付近で発生する電圧信号及び電流信号（例えば電気的徴候）の波形が保存されて、解析のためにプロセスモジュールレベル解析サーバ（例えばＡＰＥＣＳ３１４）などの解析モジュールに転送されてよい。つまり、センサレベルで検出を実施することによって、（マイクロアークなどの）潜在的な高速過渡の電気的徴候に関するデータのみが、更なる解析のために解析モジュールに転送される。このため、解析のために全てのデータを解析モジュールに送信するのではなく、データ経路に沿って送信されているデータトラフィックの量を減らすためにフィルタリングを実施してよく、それによって、帯域幅要件を減らすとともに解析モジュールのプロセッサ能力を軽減することが可能である。
【００９２】
しかしながら、もし、センサ（例えばＩＶプローブ）と直接やり取りしている解析モジュールによって潜在的なマイクロアーク事象が特定される場合は、一実施形態では、データフィルタリングは不要である。その代わり、プロセスレベルトラブルシューティングアーキテクチャの一部である（ＡＰＥＣＳ３１４などの）解析モジュールは、大量のデータを扱うことができる高速プロセッサを有してよい。発明による固有なプロセスレベルトラブルシューティングアーキテクチャによって、その他のタイプの解析アーキテクチャで発生しえる一般的なデータトラフィック渋滞が大幅に解消されえる。その結果、解析モジュールは、幾百万ものデータサンプルを迅速に且つ効率的に解析することができる。
【００９３】
発明の一実施形態では、潜在的な高速過渡の電気的徴候の分類が実施されてよい。一例において、解析モジュールによって、潜在的な高速過渡事象の波形が受信されたら、同解析モジュールは、潜在的な高速過渡の電気的徴候を（アーク徴候のセットなどの）高速過渡の徴候のセットと比較してよい。一実施形態では、マイクロアークなどの高速過渡事象の例としての種々の既知の波形が、ライブラリに保存されてよい。
【００９４】
もし、潜在的な高速過渡の電気的徴候が、ライブラリに保存されている高速過渡の徴候のセットのなかの１つと一致するならば、一実施形態では、高速過渡事象の深刻度が決定されてよい。一例では、その高速過渡事象は、処理されている基板にほとんど又は全く影響を及ぼさない事象である。したがって、その事象は、低い深刻度レベルを有する事象として分類されるであろう。別の例では、その高速過渡事象は、処理されている現基板を損傷させたかもしれない事象である。このため、その高速過渡事象は、高い深刻度レベルを有するものとして分類されるであろう。
【００９５】
高速過渡事象の深刻度を特定することによって、その高速過渡事象をどのように扱うのが最適であるかについての決定を下すことができる。発明の一実施形態では、高速過渡事象の深刻度に応じて既定の一連の措置がとられてよい。一例では、低い深刻度レベルを有する高速過渡事象が、警告をトリガする一方で、高い深刻度レベルを有する高速過渡事象は、結果として例えばエッチングプロセスを終了させてよい。
【００９６】
議論を容易にするために、図６Ａは、発明の一実施形態における、処理環境を示した簡略ブロック図である。処理システム６００は、基板６０４を中で処理されている処理チャンバ６０２を含んでよい。基板処理中は、基板をエッチングするためのプラズマを発生させるために、ガス（不図示）が、（ＲＦジェネレータのセット６０６を通じて整合器のセット６０８を介して提供される）電力と相互に作用することができる。
【００９７】
基板処理中に、もし、電荷の蓄積が生じて高速過渡事象を発生させた場合は、データは、ＶＩプローブ６１０によって収集されて、高速サンプリング過渡検出アルゴリズムモジュール６１６によって識別されてよい。高速サンプリング過渡検出アルゴリズムモジュール６１６は、一実施形態では、高速過渡事象を定義するための基準を含んでよい。一実施形態では、高速過渡検出アルゴリズムモジュールは、基板処理中に実行されるように構成されてよい。
【００９８】
一実施形態では、収集されたデータは、経路のセット６１４に沿ってＶＩプローブコントローラ６１２に転送されてよい。ＶＩプローブコントローラ６１２は、ＶＩプローブ６１０を管理するように少なくとも構成される。一実施形態では、ＶＩプローブコントローラ６１２は、高速サンプリング過渡検出アルゴリズムモジュール６１６を含んでもよい。
【００９９】
別の実施形態では、高速サンプリング過渡検出アルゴリズムモジュール６１６は、ＶＩプローブコントローラ６１２と通信することができる独立した計算モジュールであってよい。つまり、ＶＩプローブ６１０によって収集されたデータは、ＶＩプローブコントローラ６１２を介して高速サンプリング過渡検出アルゴリズムモジュール６１６に送信されてよい。高速サンプリング過渡検出アルゴリズムモジュール６１６を独立したモジュールにすることによって、ＶＩプローブコントローラ６１２は、たとえそれが追加の処理を扱うことができなくても変更されなくてすむ。
【０１００】
別の実施形態では、ＶＩプローブコントローラ６１２にデータを送信する代わりに、データは、ＶＩプローブ６１０から経路６５０を介して（図６Ｂに示されるように）解析モジュール６１８に直接送信されてよく、解析モジュール６１８は、高速サンプリング過渡検出アルゴリズムモジュール６１６を収容していてよい。データを解析モジュール６１８に直接伝送することによって、ＶＩプローブ６１０によって収集されたデータは、前処理を経なくてすむ。また、（ＶＩプローブコントローラ６１２などの）計算モジュールは、不動産間接費を削減するために、排除することが可能である。その代わりに、解析モジュール６１８を使用して、潜在的な高速過渡の電気的徴候を識別することが可能である。
【０１０１】
既定の基準に基づいて潜在的な高速過渡の電気的徴候が検出されたら、その潜在的な高速過渡の電気的徴候は、プロセスモジュールレベル解析サーバ（例えばＡＰＥＣＳ３１４）などの解析モジュール６１８によって分類されてよい。一実施形態では、解析モジュール６１８は、潜在的な高速過渡の電気的徴候を、ライブラリに保存されているアーク徴候のセットなどの高速過渡の徴候のセットと比較することによって、徴候の比較を実施してよい。もし、一致が確認された場合は、高速過渡事象が発生したとみなされる。
【０１０２】
一実施形態では、解析モジュール６１８は、高速過渡事象の深刻度を決定するように構成される。当業者ならば、高速過渡事象が種々の深刻度（例えば強度）レベルを有しえることを承知している。したがって、各高速過渡事象の深刻度を決定するためのアルゴリズムが提供される。一実施形態では、深刻度レベル／閾値範囲は、事前に定められてよく、ユーザ設定可能であってよい。一例として、電流信号又は電圧信号における４ｄＢを超える降下と、１５マイクロ秒よりも長い持続時間（降下から回復までとして定義される）とが、ウエハ上における損傷を検出するための適切な閾値だとみなされてよい。
【０１０３】
高速過渡事象の深刻度レベルが分類されたら、一連の措置がとられてよい。一実施形態では、一連の措置は、事前に決定されてよく、深刻度レベル／閾値範囲に結び付いていてよい。一実施形態では、一連の措置は、ユーザ設定可能であってよい。一例では、電圧及び電流の降下が小さい（マイクロアークなどの）高速過渡の電気的徴候は、無害だとみなされ、オペレータへの通知の送信のみを必要としてよい。別の例では、電圧及び電流の降下が大きい高速過渡の電気的徴候は、高い深刻度レベルを有する事象だとみなされ、基板プロセスの終了をトリガしてよい。
【０１０４】
図７は、発明の一実施形態における、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部ではない生産環境内においてリアルタイム高速過渡事象を検出するための方法を示した簡略フローチャートである。
【０１０５】
第１のステップ７０２では、基板処理が開始する。例えば、基板６０４が処理チャンバ６０２内で処理されている状況を考える。
【０１０６】
次のステップ７０４では、処理チャンバ内における基板処理が監視される。ステップ７０４ａでは、ＶＩプローブなどの高速過渡センサが電気パラメータ（例えば、種々の位相、基本波、及び調波における電圧信号及び電流信号）を監視していてよい。それとほぼ同時に、ステップ７０４ｂでは、高速サンプリング過渡検出アルゴリズムが実行されていてよい。
【０１０７】
次のステップ７０６では、潜在的な高速過渡事象の存在に関して決定が下される。つまり、高速サンプリング過渡検出アルゴリズムは、例えばマイクロアークなどの潜在的な高速過渡事象を定義するための基準を含んでよい。もし、ＶＩプローブによって収集されたデータが、高速サンプリング過渡検出アルゴリズムによって定義された基準を満たしていない場合は、潜在的な高速過渡事象は発生しておらず、ＶＩプローブは、基板プロセスの監視（ステップ７０４）を続ける。
【０１０８】
しかしながら、もし、潜在的な高速過渡事象が特定されたならば、次のステップ７０８では、その潜在的な高速過渡事象の発生の付近における電圧及び電流の波形が保存されてよい。
【０１０９】
次のステップ７１０では、保存された波形が解析モジュールに伝送される。一実施形態では、潜在的な高速過渡事象の発生に関係したデータのみが保存及び伝送されてよい。潜在的な高速過渡の電気的徴候のみを送信することによって、リソースの枯渇が最小限に抑えられる。また、（ＶＩプローブコントローラなどの）センサコントローラによって前処理が実施されているので、解析モジュールは、データの解析、並びに潜在的な高速過渡事象の分類及びそのための一連の措置の決定を迅速に行うための高速プロセッサを含まなくてすむ。
【０１１０】
次のステップ７１２では、解析モジュールによって徴候の比較が実施される。一実施形態では、解析モジュールは、潜在的な高速過渡の電気的徴候を高速過渡の徴候のセットと比較してよい。一実施形態では、高速過渡の徴候のセットは、ライブラリに保存されてよい。一実施形態では、ライブラリは、関連付けの実施を可能にするために、非高速過渡の徴候も含んでよい。
【０１１１】
次のステップ７１４では、潜在的な高速過渡の電気的徴候の分類に関して決定が下される。もし、徴候の比較の結果、一致が確認されなかった場合は、潜在的な高速過渡の電気的徴候は、意味のある高速過渡の電気的徴候として分類されない（ステップ７１６）。一実施形態では、この潜在的な高速過渡の電気的徴候は、廃棄されてよい。別の実施形態では、この潜在的な高速過渡の電気的徴候は、新しい高速過渡の電気的徴候としてライブラリに追加されてよい（ステップ７１８）。
【０１１２】
しかしながら、もし、徴候の比較の結果、高速過渡の電気的徴候が識別されたならば、次のステップ７２０では、その高速過渡事象の深刻度が決定される。一例では、深刻度は、低から高までの幅があってよい。一実施形態では、深刻度は、既定の閾値範囲のセットに基づいてよい。一実施形態では、高速過渡の電気的徴候は、ライブラリに追加されてよい（ステップ７１８）。ステップ７１８は、随意のステップであり、リアルタイム高速過渡事象の検出に必要なものではない。
【０１１３】
次のステップ７２２では、一連の措置が決定される。深刻度レベルが決定されたら、一連の措置が実行されてよい。一実施形態では、一連の措置は、事前に定められてよい。一例では、低い深刻度レベルを有する高速過渡の電気的徴候が、オペレータへの通知をトリガしてよい。別の例では、中程度の深刻度レベルを有する高速過渡の電気的徴候が、警告をトリガしてよい。更に別の例では、高い深刻度レベルを有する高速過渡の電気的徴候が、基板プロセスの終了をトリガしてよい。上記からわかるように、深刻度レベル及び該深刻度レベルに結び付いている一連の措置は、ユーザ設定可能であってよい。
【０１１４】
図７は、生産環境内においてリアルタイム高速過渡事象を検出する方法を実現するための、１つの実施形態を示しているに過ぎない。別の例では、方法は、一実施形態において、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部であるとしてリアルタイム高速過渡事象を検出するために適用されてもよい。このタイプの環境では、高速サンプリング過渡検出アルゴリズムの実行は、ＶＩプローブコントローラの代わりに（ＡＰＥＣＳ３１４などの）解析モジュールによって実施されてよい。一実施形態では、解析モジュールは、多量のデータを扱うことができる高速処理計算モジュールである。一実施形態では、解析モジュールは、センサに直接つながれる。このため、データは、センサによって収集され、解析モジュールに直接伝送される。
【０１１５】
上記からわかるように、その場でのリアルタイム高速過渡事象を検出するための構成と方法とが提供される。先行技術において、高速過渡事象の検出は、１つの基板ロットに対する基板処理が完了した後に実施されるのが通常である。更に、高速過渡事象の存在を決定するためには、複雑な計測ツールが必要とされるであろう。高速過渡事象の存在は、予測不可能であるので、発生したかもしれない潜在的な損傷を決定するためには、一基板ロットのなかの各基板を測定する必要があるであろう。
【０１１６】
先行技術と異なり、発明の実施形態は、基板処理中における高速過渡事象のリアルタイムな検出を提供し、それによって、基板ロットの残り及び／又は処理チャンバへの損傷を最小限に抑える。また、先行技術と異なり、検出プロセスは、人による干渉をほとんど又は全く必要としない自動化されたプロセスである。それどころか、ユーザ設定可能な条件／基準／閾値がひとたび定義されたら、システムは、高速過渡事象を自動的に検出するように構成される。
【０１１７】
生産環境内において、（マイクロアーク事象などの）高速過渡事象がリアルタイムで特定されえるので、実際の発生と、その発生を管理するためにとられる一連の措置との間の待ち時間は、短縮することが可能である。先行技術では、待ち時間は、何時間、又はひいては何週間にも及ぶ恐れがある。しかしながら、本明細書で説明されている方法及び／又は構成を用いれば、待ち時間は、僅かミリ秒単位まで短縮することが可能であり、それによって、全体の所有コストが削減される。
【０１１８】
本発明は、幾つかの好ましい実施形態の観点から説明されているが、本発明の範囲に入るものとして、代替、置換、及び均等物がある。本明細書では、様々な例が提供されるが、これらの例は、発明に対して例示的であって限定的ではないことを意図している。
【０１１９】
また、名称及び概要は、便宜のために提供されたものであり、特許請求の範囲を解釈するために使用されるべきでない。更に、要約は、極めて省略された形で記載され、便宜のために提供されたものであり、したがって、特許請求の範囲に表された全体的発明を解釈するためにも制限するためにも用いられるべきでない。もし、本明細書において「セット」という用語が用いられる場合は、このような用語は、ゼロの、１つの、又は２つ以上の構成要素を対象とした通常理解の数学的意味を有することを意図している。また、本発明の方法及び装置を実現するものとして、多くの代替的手法があることも留意されるべきである。したがって、以下の添付の特許請求の範囲は、本発明の真の趣旨及び範囲に含まれるものとして、このようなあらゆる代替、置換、及び均等物を含むものと解釈される。
【背景技術】
【０００１】
プラズマ処理における進歩は、半導体産業に成長をもたらした。競争力を持つためには、メーカは、基板を良質な半導体デバイスに加工することができる必要がある。基板処理中に満足のいく結果を達成するためには、プロセスパラメータの厳密な制御が一般的に必要とされる。処理パラメータ（例えば、ＲＦ電力、圧力、バイアス電圧、イオン束、プラズマ密度など）が既定の窓から外れると、望ましくない処理結果（例えば、不良なエッチングプロフィール、低い感度、基板への損傷、処理チャンバへの損傷など）がもたらされる恐れがある。したがって、半導体デバイスの製造では、処理パラメータが既定の窓から外れるときの状況を特定する能力が重要である。
【０００２】
基板処理中は、基板を損傷させえる及び／又は処理チャンバコンポーネントへの損傷を生じえる何らかの制御できない事象が発生する恐れがある。これらの制御できない事象を特定するために、基板処理中にデータが収集されてよい。基板処理中に（バイアス電圧、反射能、圧力などの）様々なプロセスパラメータに関するデータを収集するために、センサなどの監視機器を用いることができる。本明細書で論じられるセンサとは、プラズマ処理コンポーネントの状態及び／又は信号を検出するために使用されえる機器を言う。議論を容易にするために、「コンポーネント」という用語は、処理チャンバ内の不可分な一パーツ又は複数パーツの組み立て品に言及するために使用される。
【０００３】
センサによって収集されるデータのタイプ及び量は、近年増加を続けている。センサによって収集されたデータをプロセスモジュールデータ及びプロセスコンテクストデータ（チャンバ事象データ）との関連で解析することによって、既定の窓から外れたパラメータを特定することが可能である。したがって、（１つ又は２つ以上の）制御できない事象を止めるための（レシピ調節などの）修正措置を提供し、それによって、基板及び／又は処理チャンバコンポーネントへの更なる損傷の発生を阻止することができる。
【図面の簡単な説明】
【０００４】
添付の図面では、本発明は、限定的なものではなく例示的なものとして示され、図中、類似の参照符号は、同様の要素を指している。
【０００５】
【図１】先行技術による、ホストレベル解析サーバを伴った相互接続ツール環境を示した全体的論理図である。
【０００６】
【図２】センサとプロセスモデルコントローラとの間でデータを関連付けるためのクラスタツールレベルの解決法を伴った相互接続ツール環境を示した簡略ブロック図である。
【０００７】
【図３】発明の一実施形態における、プロセスレベルトラブルシューティングアーキテクチャを示した簡略論理全体図である。
【０００８】
【図４】発明の一実施形態における、プロセスモジュールレベル解析サーバを示した簡略機能図である。
【０００９】
【図５】マイクロアーク事象を示した簡略図である。
【００１０】
【図６Ａ】発明の実施形態における、処理環境を示した簡略ブロック図である。
【図６Ｂ】発明の実施形態における、処理環境を示した簡略ブロック図である。
【００１１】
【図７】発明の一実施形態における、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部ではない生産環境内においてリアルタイム高速過渡事象を検出するための方法を示した簡略フローチャートである。
【発明を実施するための形態】
【００１２】
次に、添付の図面に示されるような幾つかの実施形態を参照にして、本発明が詳細に説明される。以下の説明では、本発明の完全な理解を与えるために、多くの詳細が明記されている。しかしながら、当業者ならば、本発明が、これらの一部又は全部の詳細を伴わずとも実施されえることが明らかである。また、本発明を不必要に不明瞭にしないために、周知のプロセス工程及び／又は構造の詳細な説明は省略されている。
【００１３】
方法及び技術を含む様々な実施形態が、以下で説明される。発明は、発明技術の実施形態を実行に移すためのコンピュータ可読命令を格納されたコンピュータ可読媒体を含む製造品も対象としえることを念頭に置かれるべきである。コンピュータ可読媒体としては、例えば、コンピュータ可読コードを格納するための、半導体、磁気、光磁気、光、又はその他の形態のコンピュータ可読媒体が挙げられる。更に、発明は、発明の実施形態を実施するための装置も対象とすることができる。このような装置は、発明の実施形態に関連したタスクを実行に移すための、専用及び／又はプログラム可能な回路を含んでよい。このような装置の例としては、適切にプログラムされたときの汎用コンピュータ及び／又は専用計算機器があり、コンピュータ／計算機器と、発明の実施形態に関連した様々なタスクに適応された専用の／プログラム可能な回路との組み合わせが挙げられる。
【００１４】
上記のように、競争力を得るためには、メーカらは、基板処理中に発生しえる問題を効果的に且つ効率的にトラブルシューティングできなければならない。トラブルシューティングは、一般に、処理中に収集される夥しい量のデータを解析することを伴う。議論を促すために、図１は、先行技術による、ホストレベル解析サーバを伴った相互接続ツール環境を示した全体的論理図である。
【００１５】
例えば、メーカが（エッチングツール、洗浄ツール、剥離ツールなどの）１つ又は２つ以上のクラスタツールを有しえる状況を考える。各クラスタツールは、１つ又は２つ以上の特定の処理を行うように各自構成された複数の処理モジュールを有してよい。各クラスタツールは、ＣＴＣ１０４、ＣＴＣ１０６、及びＣＴＣ１０８などのクラスタツールコントローラ（ＣＴＣ）によって制御されてよい。各クラスタツールコントローラは、ＰＭＣ１１０、ＰＭＣ１１２、ＰＭＣ１１４、及びＰＭＣ１１６などの１つ又は２つ以上のプロセスモジュールコントローラ（ＰＭＣ）とやり取りしてよい。議論を容易にするために、ＰＭＣ１１０との関連で例が挙げられる。
【００１６】
介入を必要としえる状態を特定するために、センサによって、基板処理中に処理パラメータに関するデータ（感知データ）が収集されてよい。一例では、基板処理中に１つ又は２つ以上の処理パラメータに関するデータを収集するために、（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、及び１４０などの）複数のセンサがプロセスモジュールコントローラとやり取りしてよい。利用可能なセンサのタイプは、収集されえるデータのタイプに依存してよい。例えば、センサ１１８は、電圧データを収集するように構成されてよい。別の例では、センサ１２０は、圧力データを収集するように構成されてよい。一般に、プロセスモジュールからデータを収集するために使用されえるセンサは、ブランド、型、及び／又はモデルに違いがある。したがって、各センサは、その他のセンサとほとんど又は全くやり取りしないであろう。
【００１７】
通常、センサは、１つ又は２つ以上の特定のパラメータに関する測定データを収集するように構成される。センサの大半は、処理を実施するようには構成されないので、各センサは、（コンピュータやユーザインターフェースなどの）計算モジュールにつなぐことができる。計算モジュールは、通常、アナログデータを処理するように及び未加工のアナログデータをデジタル形式に変換するように構成される。
【００１８】
一例では、センサ１１８は、センサケーブル１４４を介してＰＭＣ１１０から電圧データを収集する。センサ１１８によって受信されたアナログ電圧データは、計算モジュール１１８ｂによって処理される。センサによって収集されたデータは、（データボックス１４２などの）ホストレベル解析サーバに送信される。ネットワーク接続を通じてデータボックス１４２に送信される前に、データは、先ず、計算モジュールによってアナログ形式からデジタル形式に変換される。一例では、ネットワーク経路１４６を通じてデータボックス１４２にデータが送信される前に、計算モジュール１１８ｂが、センサ１１８によって収集されたアナログデータをデジタル形式に変換する。
【００１９】
データボックス１４２は、センサ及びプロセスモジュールを含む複数のソースからデータを収集し、処理し、解析するように構成された集中解析サーバであってよい。通常、一メーカの全クラスタツールによって基板処理中に収集されるデータの処理に、１つのデータボックスが使用可能である。
【００２０】
データボックス１４２に伝送されえるデータの実際の量は、センサによって収集される量よりも大幅に少ないであろう。通常、センサは、膨大な量のデータを収集することができる。一例では、センサは、最大１メガバイト毎秒のレートでデータを収集することができる。しかしながら、データボックス１４２に送信されるのは、センサによって収集されたデータの一部のみである。
【００２１】
センサによって収集されたデータストリーム全体をデータボックス１４２に伝送しない理由は、１つには、コスト効率の良い市販の通信プロトコルを使用するときのネットワーク帯域幅限界ゆえである。データボックス１４２へのネットワークパイプラインは、（データボックス１４２などの）１つのレシーバに送信されている（センサ１１８、１２０、１２２、１２４、１２６、１２８、１３０、１３２、１３４、１３６、１３８、及び１４０などの）複数のソースからの大量のデータを扱うことができないであろう。つまり、センサ構成（センサ及び計算モジュール）とデータボックス１４２との間のネットワーク経路は、データボックス１４２が全センサ構成からくる膨大な量のデータを受信しようとする際に、大きなトラフィック渋滞に見舞われる恐れがある。上記からわかるように、もし、データボックス１４２が到着トラフィックを扱うことができないと、送信されているデータパケットが脱落して再送信が必要になり、それによって、既に深刻に渋滞しているネットワークパイプラインに更なる負荷がかかる恐れがある。
【００２２】
また、データボックス１４２は、データの処理及び解析などのその他の重要な機能を実施しつつそれと同時に複数ソースからの多量の到着データを扱うことはできないであろう。上記のように、データボックス１４２は、到着するデータパケットを受信するように構成されるのみならず、例えば、到着する全データストリームを処理及び解析するようにも構成される。データボックス１４２は、収集されている種々のデータストリームのための解析サーバであるので、データボックス１４２は、夥しい量のデータストリームに対する解析を実施するための十分な処理能力を必要とする。
【００２３】
データボックス１４２は、処理リソースに限りがあるので、各センサから収集されたデータの一部のみが、データボックス１４２に送信される。一例では、１つのセンサによって収集されえる幾千ものデータ項目のうち、１〜５ヘルツで１０〜１５のデータ項目のみが、データボックス１４２に転送されえる。一例では、センサ１１８によって収集されたデータの概略のみが、データボックス１４２に送信されえる。
【００２４】
複数のセンサからデータを受信することに加えて、データボックス１４２は、プロセスモジュールコントローラからもデータを受信してよい。一例では、各プロセスモジュールコントローラによって、プロセスモジュールデータ及びプロセスコンテクストデータ（チャンバ事象データ）が収集され、データボックス１４２に転送されてよい。議論を容易にするために、プロセスモジュールデータ及びプロセスコンテクストデータは、プロセスモジュール＆チャンバデータとして言及されてもよい。例えば、プロセスモジュールデータ及びプロセスコンテクストデータは、ＰＭＣ１１０によって収集され、経路１４８を介してＣＴＣ１０４に送信されてよい。ＣＴＣ１０４は、ＰＭＣ１１０からのデータを管理するのみならず、クラスタツール内の（ＰＭＣ１１２、ＰＭＣ１１４、及びＰＭＣ１１６などの）その他のプロセスモジュールコントローラからのデータも扱ってよい。
【００２５】
クラスタツールコントローラによって収集されたデータは、次いで、半導体機器通信規格／汎用機器モジュール（ＳＥＣＳ／ＧＥＭ）インターフェースを介してファブホスト１０２に伝送される。一例では、ＣＴＣ１０４は、ＰＭＣ１１０、１１２、１１４、及び／又は１１６から収集されたデータを、経路１５０を介してＳＥＣＳ／ＧＥＭ１５６を通してファブホスト１０２に伝送する。ファブホスト１０２は、ＣＴＣ１０４からのデータのみならず、例えばＣＴＣ１０６及びＣＴＣ１０８などのその他のクラスタツールコントローラからのデータも受信してよい。ファブホスト１０２によって収集されたデータは、次いで、経路１５８を介してデータボックス１４２に転送される。収集されているデータの量の莫大さゆえに、ファブホスト１０２に送信されている全てのデータがデータボックス１４２に転送されるのではなく、多くの場合、データの概略のみがデータボックス１４２に転送されるであろう。
【００２６】
データボックス１４２は、センサ及びプロセスモジュールコントローラによって収集されたデータを処理、解析、及び／又は関連付けてよい。もし、異常が特定された場合は、データボックス１２０は、例えばＰＭＣ１１０において実施されているレシピ工程に適合しないパラメータなどの、問題の原因を決定してよい。ひとたび問題の原因が特定されたら、データボックス１４２は、イーサネットメッセージ（イーサネットは登録商標）の形式でファブホスト１０２に停止命令を送信してよい。メッセージを受信したら、ファブホスト１０２は、そのメッセージを、ＳＥＣＳ／ＧＥＭ１５６を通してＣＴＣ１０４に転送してよい。クラスタツールコントローラは、次いで、メッセージを、この例ではＰＭＣ１１０である意図したプロセスモジュールコントローラへ取り次いでよい。
【００２７】
あいにく、停止命令は、リアルタイムで提供されないのが通常である。それどころか、停止命令は、影響された基板が処理された後に、又はひいては基板ロット全体がプロセスモジュールから退出された後に、意図したプロセスモジュールによって受信されるのが通常である。したがって、基板／基板ロットが損傷されるのみならず、１つ又は２つ以上の処理チャンバコンポーネントも悪影響を受け、それによって、無駄が増えるとともに所有コストが増す恐れがある。
【００２８】
遅延の理由は、１つには、夥しい数のソースから受信されているデータの量の莫大さゆえである。たとえ、データボックス１４２が、高速プロセッサを伴うように構成され、大量のデータストリームを扱うのに十分なメモリを有するとしても、データボックス１４２は、依然、収集されている全てのデータを処理し、関連付け、及び／又は解析するのに時間を要するであろう。
【００２９】
プロセスモジュールによる停止命令の受信が遅延するもう１つの理由は、データボックス１４２によって受信されているデータストリームの不完全さゆえである。データボックス１４２は、夥しい数のソースからデータを受信しているので、データボックス１４２に送信されている実際のデータは、収集されているデータよりも大幅に少ない。一例では、センサ１１８によって収集されている１ギガヘルツのデータストリームを送信する代わりに、データの一部のみ（約１〜５ヘルツ）が実際に送信されている。このため、データボックス１４２は、その全てのソースから多量のデータを受信してはいるが、受信されているデータは、不完全であるのが通常である。したがって、データボックス１４２が、全てのソースからの完全なデータセットにはアクセスできないゆえに、制御できない事象の決定には、時間がかかるであろう。
【００３０】
また、データがデータボックス１４２に送信される経路には、違いがある。一例では、データは、アナログデータからデジタルデータに変換された後に、センサ構成（すなわちセンサ及びその計算モジュール）から直接送信される。反対に、プロセスモジュールによって収集されたデータは、より長いネットワーク経路を通じて（少なくともクラスタツールコントローラ及びファブホストを通して）伝送される。したがって、データボックス１４２は、全ての関連のデータストリームが受信されるまで、その解析を完了することができない。
【００３１】
プロセスモジュールとデータボックス１４２との間のネットワーク経路が長いのみならず、この経路を通して送信されるデータストリームは、少なくとも２つのボトルネックに直面するのが通常である。１つ目のボトルネックは、クラスタツールコントローラにおけるものである。１つのクラスタツール内の複数のプロセスモジュールによって収集されたデータは、１つのクラスタツールコントローラに送信されているので、１つ目のボトルネックは、様々なプロセスモジュールからのデータストリームが１つのクラスタツールコントローラを通して処理されなければならないゆえに発生する。各プロセスモジュールから伝送されえるデータの量の莫大さゆえに、クラスタツールコントローラへのネットワーク経路は、深刻なトラフィック渋滞に見舞われるのが通常である。
【００３２】
ひとたびクラスタツールコントローラによってデータが受信されたら、そのデータは、ファブホスト１０２に伝送される。２つ目のボトルネックは、ファブホスト１０２において発生しえる。ファブホスト１０２が、様々なクラスタツールコントローラからのデータを受信しているゆえに、ファブホスト１０２へのトラフィックもまた、受信されているデータの量の多さゆえに、渋滞に見舞われるであろう。
【００３３】
データボックス１４２は、制御できない事象を決定するために、種々のソースからのデータを必要とするので、プロセスモジュールとデータボックス１４２との間のトラフィック状態は、データボックス１４２へのデータストリームの適時な送達を阻む。その結果、データボックス１４２が解析の実施に必要な全てのデータを集めるまでに、貴重な時間が失われる。更に、ひとたび停止命令が用意されると、その停止命令は、修正措置をとるべく適用されるまでに、同じく非常に長い経路を通って移動して、影響されたプロセスモジュールまで戻る必要がある。
【００３４】
遅延に寄与しているもう１つの要因は、様々なデータソースからのデータを関連付ける難しさにある。データボックス１４２によって受信されているデータストリームは、通常、各センサ及び／又はプロセスモジュールから収集されたデータの概略であるので、データの関連付けは、利用可能なデータストリームの時間間隔に違いがあるゆえに、難しい作業になる恐れがある。一例では、センサ１１８からデータボックス１４２に伝送される選択されたデータストリームが、１秒間隔である一方で、ＰＭＣ１１０からのデータストリームは、２秒間隔である。したがって、データストリームの関連付けは、制御できない事象が明確に決定されえるまでに、時間を要するであろう。
【００３５】
データを関連付けることの更なる難しさは、データがデータボックス１４２に送信される経路の違いに起因する。データは、種々のコンピュータやサーバなどを通して伝送されているゆえに、コンピュータドリフト、ネットワーク待ち時間、ネットワーク負荷などに見舞われるであろう。その結果、データボックス１４２は、様々なソースからのデータを関連付けるのが困難であろう。制御できない事象を迅速に特定するには、厳密な関連付けが必要であるゆえに、制御できない事象が正確に特定されえる前には、更なる解析の実施が必要であろう。
【００３６】
図１に提供されている解決策のもう１つの欠点は、所有コストである。クラスタツールシステムを維持するコストに加えて、センサ構成には、更なるコストがかかわっている。各センサは、ブランド／型／モデルに違いがあるので、各センサ構成は、センサと計算モジュールとを含むのが通常である。通常は、各センサ構成を収容するための物理的空間が必要とされる。したがって、特に、不動産価格が高いエリアでは、センサ構成の収容コストが高くつく恐れがある。
【００３７】
プロセスモジュール内における制御できない事象の実際の発生と、プロセスモジュールによる停止命令の受信との間の実際の時間遅延を短縮するために、クラスタレベル解析サーバが提供される。図２は、センサとプロセスモデルコントローラとの間でデータを関連付けるためのクラスタツールレベルの解決法を伴った相互接続ツール環境を示した簡略ブロック図である。
【００３８】
図１と同様に、クラスタツールは、（ＰＭＣ２１０、２１２、２１４、及び２１６などの）複数のプロセスモジュールを含んでよい。解析のためのデータを収集するために、各プロセスモジュールは、（センサ２１８、２２０、２２２、２２４、２２６、２２８、２３０、２３２、２３４、２３６、２３８、及び２４０などの）複数のセンサにつながれてよい。各センサは、処理パラメータデータを収集するために、（センサケーブル２４４などの）センサケーブルを介して対応するプロセスモジュールコントローラとやり取りしてよい。センサによって収集されるデータは、アナログ形式であってよい。（計算モジュール２１８ｂなどの）計算モジュールは、経路２４６を介して（リモートコントローラ２４２などの）クラスタレベル解析サーバに転送する前に、データを処理してデジタル形式に変換してよい。
【００３９】
図１と同様に、各プロセスモジュールコントローラは、（プロセスモジュールデータ及びプロセスコンテクストデータなどの）データを（ＣＴＣ２０４及び２０６などの）クラスタツールコントローラにも伝送してよい。一例では、ＰＭＣ２１０によって収集されたデータは、経路２４８を介してＣＴＣ２０４に伝送されてよい。ＰＭＣ２１０からのデータを受信する以外に、ＣＴＣ２０４は、（ＰＭＣ２１２、２１４、及び２１６などの）その他の処理モジュールコントローラからのデータも受信してよい。クラスタツールコントローラによって受信されたデータは、次いで、経路２５０を介してファブホスト２０２に転送される。
【００４０】
ファブホスト２０２とＣＴＣ２０４との間では、ファブホスト２０２に転送されるデータを複製するためのシリアルタップがネットワーク経路２５０につながれてよい。一例において、ＣＴＣ２０４によってファブホスト２０２に転送されるデータは、シリアルタップ２０８によって傍受されてよい。データは、複製され、データストリームのコピーが、経路２５４を介してリモートコントローラ２４２に送信される。もし、ファブホストが２つ以上のクラスタツールコントローラにつながれている場合は、その各クラスタツールコントローラに、専用のリモートコントローラが結び付いている。一例において、経路２５２を介してＣＴＣ２０６からファブホスト２０２に送信されているデータは、別のシリアルタップ（２５６）によって傍受される。データは、複製され、ＣＴＣ２０４に結び付いているリモートコントローラ（２４２）とは異なるリモートコントローラ（２６０）に経路２５８を介して送信される。
【００４１】
したがって、様々なクラスタツールからの全てのデータを１つのデータボックスによって扱う代わりに、様々なクラスタツールからのデータを扱うために、複数のリモートコントローラが利用可能になる。つまり、各クラスタツールが、それ自身のリモートコントローラに結び付いている。各リモートコントローラが、（１つのクラスタツールに結び付いているプロセスモジュールコントローラ及びセンサのように）より少ない数のデータソースからのデータを扱うので、各リモートコントローラは、各ソースから、より多量のデータを扱うことができる。一例では、３０〜１００のデータ項目が送信される代わりに、１０ヘルツで約４０ｋＢ〜１００ｋＢのデータ項目が各リモートコントローラによって受信可能になるであろう。
【００４２】
センサ及びプロセスモジュールコントローラから受信されたデータは、リモートコントローラによって解析される。もし、問題が特定された場合は、リモートコントローラは、クラスタツールコントローラに停止命令を送信してよい。一例では、リモートコントローラ２４２は、ＰＭＣ２１０内における問題を特定する。経路２５４及び経路２５０を介し、シリアルタップ２０８を通してＣＴＣ２０４に停止命令が送信される。停止命令を受信したら、ＣＴＣ２０４は、その停止命令を、この例ではＰＭＣ２１０である意図したプロセスモジュールコントローラに転送する。
【００４３】
リモートコントローラは、（データボックス１４２によってなされているように）複数のクラスタツールからではなく、１つのクラスタツールからのデータを扱う責任のみを担うので、より多くのデータが解析されえるとともに、より優れた関連付けが異なるデータセット間に存在しえる。その結果、リモートコントローラは、より優れた且つより高速な解析を実施することができ、それによって、処理モジュール内における制御できない事象を修正するためのより適時な介入を提供することができる。一例では、特定された制御できない事象を次の基板ロットで発生させないために（データボックス１４２によって提供される停止命令などの）停止命令を受信するのではなく、例えばリモートコントローラ２４２によって送信された停止命令によって、処理を予定されている基板ロットの少なくとも一部をプロセスエンジニアが救出することを可能にすることができる。
【００４４】
リモートコントローラ解決法は、データボックス解決法よりも優れてはいるが、リモートコントローラ解決法は、依然、その解析を実施するために概略データに依存している。したがって、基板処理中に発生しえる問題は、特定されないままになる恐れがある。更に、プロセスモジュールとリモートコントローラとの間の経路は、依然、直接的な経路ではない。その結果、コンピュータドリフト、ネットワーク待ち時間、及び／又はネットワーク負荷が時間的な不一致を招く恐れがあり、これは、リモートコントローラがセンサからのデータをプロセスモジュールからのデータに関連付けることを困難にする恐れがある。
【００４５】
このため、リモートコントローラ解決法は、停止命令の適時性を向上させたとはいえ、依然として不十分である。停止命令は、影響された基板が被った問題を、次の基板の処理中に発生させないようにできるのがせいぜいである。コストを最小限に抑える必要がある競争が熾烈な市場では、基板の損傷ゆえの無駄及び／又は処理チャンバコンポーネントの損傷ゆえのダウンタイムが市場損失につながる恐れがある。したがって、制御できない事象を特定するためのリアルタイムな解決策が望まれている。
【００４６】
本発明の実施形態にしたがって、トラベルシューティングがプロセスモジュールレベルで実施されるプロセスレベルトラベルシューティングアーキテクチャ（ＰＬＴＡ）が提供される。発明の実施形態は、リアルタイムな停止命令を伴ったリアルタイムな解析を提供するプロセスレベルトラブルシューティングアーキテクチャを含む。発明の実施形態は、更に、センサ間における負荷バランス及び耐障害性のための構成を含む。
【００４７】
発明の実施形態において、プロセスレベルトラブルシューティングアーキテクチャは、解析サーバが１つの処理モジュール及びそれに対応するセンサと通信しているネットワークシステムである。一実施形態において、ネットワーク内において交換されている情報は、双方向である。一例では、解析サーバは、処理モジュール及びセンサからプロセスデータを継続的に受信してよい。反対に、センサは、処理モジュールからデータを受信してよく、処理モジュールは、解析サーバから命令を受信してよい。
【００４８】
例えば、基板が処理されている状況を考える。基板処理中は、複数のデータが収集されてよい。一例では、圧力に関するデータが１００ミリ秒ごとに収集される。もし、処理に１時間かかる場合は、圧力パラメータについて３６，０００のデータ項目が収集されている。ただし、圧力データ以外のその他の複数のプロセスデータ（例えば電圧バイアスや温度など）も収集されてよい。したがって、基板の処理が完了した時点では、かなりの量のデータが収集されている。
【００４９】
先行技術では、データは、もし（データボックス１４２のように）複数のクラスタツールから収集されるデータを扱うように構成されるのでないとしても（図２のリモートコントローラ２４２のように）複数の処理モジュールから収集されるデータを扱うように構成されるであろう解析サーバに伝送される。データストリームは、複数のソースから来るので、データの解析及び／又は関連付けは、時間を要する。更に、先行技術の解析サーバは、収集された全てのデータを処理及び解析することはできないので、各ソースから収集されたデータの一部のみが、解析サーバに伝送される。その結果、データストリームの整合、処理、関連付け、及び／又は解析を行う複雑な作業は、必ずしも常に容易に調達可能ではない長さの時間を要する。
【００５０】
発明の一態様において、本願の発明者らは、もし、より粒度の高いデータが解析のために利用可能であれば、より正確で且つより迅速な解析が実施されえることに気付いた。１つのソースから、より多くのデータを解析するためには、解析サーバは、より少ないソースからのデータを解析しなければならない。一実施形態では、プロセスモジュールレベルでデータを処理及び／又は解析するための構成が提供される。つまり、各プロセスモジュール及びその対応するセンサのための解析を実施するためのプロセスモジュールレベル解析サーバが提供される。
【００５１】
一実施形態において、プロセスモジュールレベル解析サーバは、１つ又は２つ以上のプロセッサを含みえる共有メモリバックボーンを含む。各プロセッサは、１つ又は２つ以上のセンサとやり取りするように構成されてよい。一例では、センサ１によって収集されたデータが、プロセッサ１によって処理されえる一方で、センサ２によって収集されたデータは、プロセッサ２によって処理されえる。
【００５２】
先行技術と異なり、プロセッサは、負荷バランス及び耐障害性を実施するために、その処理能力を互いに共有することができる。先行技術において、各計算モジュールは、１つのセンサによって収集されたデータを扱うように構成される。各計算モジュールは、個別のユニットであり、互いにやり取りしないのが通常であるので、負荷バランスは、通常は実施されない。先行技術と異なり、プロセスモジュールレベル解析サーバ内におけるプロセッサのセットは、負荷バランスを実施することができる。一例において、もし、プロセッサ１がデータ過負荷を受けている一方で、プロセッサ２がほとんど又は全くデータを受信していない場合は、プロセッサ１がセンサ１からのデータを処理するのを助けるために、プロセッサ２を充てることが可能である。
【００５３】
更に、先行技術において、計算モジュールは、ブランド／型／モデルが異なる傾向にあるので、もし、１つの計算モジュールが誤動作している場合は、その他の計算モジュールは、その誤動作している計算モジュールによって実施される処理を引き継ぐことができない。先行技術と異なり、プロセッサ間で、必要に応じて作業負荷を再分配することが可能である。例えば、もし、プロセッサ２がその機能を実施することができない場合は、プロセッサ２が修復されるまで、作業負荷をその他のプロセッサに再分配することが可能である。上記からわかるように、プロセッサは、個別の計算モジュールの必要性を排除し、それによって、計算モジュールの収容に必要とされる物理的空間も削減する。
【００５４】
発明の一実施形態において、プロセッサは、２つのタイプのプロセッサ、すなわちプライマリプロセッサとセカンダリプロセッサとに分けられてよい。プライマリプロセッサ及びセカンダリプロセッサは、ともに、センサからのデータを扱うように構成される。一例において、もし、セカンダリプロセッサ１がセンサ１に結び付いている場合は、セカンダリプロセッサ１は、センサ１から来るデータのみを処理するのが通常である。同様に、もし、セカンダリプロセッサ２がセンサ２及びセンサ３に結び付いている場合は、セカンダリプロセッサ２は、これらのセンサ（２及び３）から来るデータのみを処理するのが通常である。
【００５５】
一実施形態において、共有メモリバックボーンは、１つ又は２つ以上のプライマリプロセッサを含んでよい。プライマリプロセッサのセットは、センサからのデータを扱うのみならず、処理モジュールから来るデータを扱うようにも構成されてよい。また、プライマリプロセッサのセットは、（センサや処理モジュールなどの）様々なソース間でデータを関連付けて解析を実施するように構成される。もし、停止が必要な場合は、プライマリプロセッサのセットは、プロセスモジュールコントローラに停止命令を送信するように構成される。
【００５６】
本発明の特徴及び利点は、以下の図面及び議論を参照にして、より良く理解されるであろう。
【００５７】
図３は、発明の一実施形態における、プロセスレベルトラブルシューティングアーキテクチャを示した簡略論理全体図である。メーカは、２つ以上のクラスタツールを有してよいが、発明の一実施形態の説明としては、１つのクラスタツールが使用されるとする。クラスタツールは、様々な数の処理モジュールを有してよいが、図３に示された例は、４つの処理モジュールを伴った１つのクラスタツールを含むとする。
【００５８】
各処理モジュールによって収集されたデータは、その対応する処理モジュールコントローラ（ＰＭＣ３０６、ＰＭＣ３０８、ＰＭＣ３１０、及びＰＭＣ３１２）によって収集され、クラスタツールコントローラ（ＣＴＣ）３０４を介してファブホスト３０２に伝送される。ＰＭＣによって伝送されえるデータは、先行技術において送信されていたのと同じタイプのデータ（プロセスモジュールデータ及びプロセスコンテクストデータ）であってよい。先行技術と異なり、ファブホスト３０２に伝送されるデータは、トラブルシューティングの実施のために処理モジュールが依存するデータではなく、将来の解析に備えてアーカイブに保管されて利用可能にされるデータである。
【００５９】
一実施形態では、トラブルシューティングのために必要とされる解析を実施するために、プロセスモジュールレベル解析サーバ（ＡＰＥＣＳ３１４）が提供される。ＰＭＣ３０８内において基板がエッチングされている状況を考える。基板処理中に、センサ３１６、３１８、及び３２０は、ＰＭＣ３０８からデータを収集している。一例では、センサ３１６は、ＰＭＣ３０８から電圧バイアスデータを収集するように構成される。ＰＭＣ３０８から収集されたアナログデータは、センサケーブル３２８を介してセンサ３１６に送信される。同様に、センサ３１８及びセンサ３２０は、それぞれセンサケーブル３３０及びケーブル３３２を介してデータを収集してよい。センサによって収集されたデータは、次いで、処理及び／又は解析のために、経路３２２、３２４、及び３２６のいずれかを介してＡＰＥＣＳ３１４に伝送されてよい。
【００６０】
先行技術と異なり、センサによって収集されたデータは、解析サーバ（ＡＰＥＣＳ３１４）に伝送される前に（例えば概略化などの）前処理を経る必要がない。一実施形態では、データを処理するための計算モジュールを有する代わりに、各センサは、データをＡＰＥＣＳ３１４に転送する前にアナログデータをデジタルデータに変換するために使用されえる単純なデータコンバータを含んでよい。或いは、一実施形態では、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのデータコンバータが、ＡＰＥＣＳ３１４に組み込まれてよい。一例では、各プロセッサは、その処理の一環としてデータをデジタル形式に変換するためのデータコンバータアルゴリズムを含んでよい。上記からわかるように、計算モジュールの必要性を排除することによって、クラスタツール及びそのハードウェアの収容に必要とされる物理的空間が小さくてすむ。その結果、所有のコストを削減することができる。
【００６１】
ＡＰＥＣＳ３１４は、１つの処理モジュール及びその対応するセンサからのデータのみを処理するのに専念するので、１つのソースから、より多量のデータを扱うことができる。つまり、各センサから伝送されたデータの量を減らさなければならない代わりに、ＡＰＥＣＳ３１４は、各センサによって収集されたデータの、たとえ全部ではなくとも大半を扱うように構成される。一例では、解析のために僅か１０〜１５のデータ項目が送信される代わりに、各センサから二千強のデータ項目がＡＰＥＣＳ３１４による解析のために利用可能になるであろう。したがって、処理及び解析のためにＡＰＥＣＳ３１４によって利用可能なデータストリームは、より完全なデータセットになる。
【００６２】
一実施形態において、ＡＰＥＣＳ３１４は、処理モジュールから来るデータを扱うようにも構成される。データストリームが、（データボックス又はリモートコントローラなどの）解析サーバによって受信される前に（例えばクラスタツールコントローラやファブホストなどの）様々なサーバを通る長いデータ経路を経て送信される先行技術と異なり、プロセスモジュールによって収集されたデータは、その他のサーバを通る必要なくＡＰＥＣＳ３１４に直接送信される。一例では、プロセスモジュールデータは、経路３３４を介してＰＭＣ３０８からＡＰＥＣＳ３１４に送信されてよい。もし、制御できない事象が特定された場合は、停止命令は、先ずその他のサーバを経る必要なく経路３３６を介してＰＭＣ３０８に直接送信されてよい。
【００６３】
プロセスモジュールレベル解析サーバに関する更なる詳細が、図４に提供されている。図４は、発明の一実施形態における、プロセスモジュールレベル解析サーバを示した簡略機能図である。各プロセスモジュールには、（ＡＰＥＣＳ４００などの）プロセスモジュールレベル解析サーバが割り当てられてよい。ＡＰＥＣＳ４００は、双方向サーバであり、到着するデータを処理するように及び制御できない事象が特定されたときに停止命令を送信するように構成される。
【００６４】
データソースは、２つの主なソース、すなわちセンサによって収集されたデータ及びプロセスモジュールによって収集されたデータから来るであろう。一実施形態において、ＡＰＥＣＳ４００は、複数のセンサ（センサ４１０、４１２、４１４、４１６、４２０、４２２、４２４、及び４２６）からの到着データを受信するように構成される。クラスタツール所有者には、従来のセンサ構成（計算モジュールを伴ったセンサ）に既に多額の資金を投じた者がいるかもしれないので、ＡＰＥＣＳ４００は、従来のセンサ構成及び改良されたセンサ（計算モジュールを必要としないセンサ）の両方からデータを受け入れるように構成される。
【００６５】
一実施形態において、ＡＰＥＣＳ４００は、イーサネットスイッチ４１８のような、（センサ４１０、４１２、４１４、４１６などの）従来のセンサ構成とやり取りするためのインターフェースを含んでよい。一例では、センサ４１０によって収集されたデータは、デジタルデータとして（経路４３０、４３２、４３４、及び４３６を介して）ＡＰＥＣＳ４００に伝送される前に、先ず、計算モジュール４１０ｂによってアナログ形式からデジタル形式に変換される。イーサネットスイッチ４１８は、データストリームを受け入れるために、従来のセンサ構成とやり取りするように構成される。データストリームは、次いで、処理のために、（経路４４６、４４８、４５０、又は４５２を介して）ＡＰＥＣＳ４００内のプロセッサ（４０２、４０４、４０６、及び４０８）の１つに引き渡される。
【００６６】
プロセスパラメータを測定するために従来のセンサ構成を用いる代わりに、改良されたセンサ（計算モジュールを伴わないもの）が使用されてよい。収集されたデータは、概略化される必要がないので、処理のための計算モジュールは、もはや必要なくなる。その代わり、一実施形態では、改良されたセンサは、安価なＦＰＧＡのような、データをアナログ形式からデジタル形式に変換するためのデータコンバータ（不図示）を含んでよい。或いは、センサ内にデータコンバータを実装する代わりに、ＡＰＥＣＳ４００内にデータコンバータ（不図示）が実装されてよい。データコンバータがＡＰＥＣＳ４００の外又は内のいずれに実装されるかにかかわらず、計算モジュールの排除は、クラスタツールの所有におけるコスのト節約を可能にする。一例では、計算モジュールを購入、収容、及び維持するためのコストが大幅に削減される。
【００６７】
発明の一実施形態において、ＡＰＥＣＳ４００は、到着データを扱うためのプロセッサのセット（４０２、４０４、４０６、及び４０８）を含む。プロセッサのセットは、物理的処理ユニット、仮想プロセッサ、又はそれらの組み合わせであってよい。各プロセッサは、プロセッサに結び付いているソースからのデータストリームを扱う責任を担っている。一例では、経路４４０を介してセンサ４２２から流入するデータストリームが、プロセッサ４０４によって扱われる。別の一例では、センサ４２４によって収集されたデータストリームが、処理のために、経路４４２を介してプロセッサ４０６に伝送される。
【００６８】
プロセッサの数と、プロセッサとセンサとの間の関係は、ユーザの設定に依存してよい。一例において、図４は、プロセッサとセンサとの間の１対１の関係のみを示しているが、その他の関係も存在することが可能である。一例では、１つのプロセッサが、２つ以上のソースからのデータを扱うように構成されてよい。別の例では、１つのセンサからのデータストリームを、２つ以上のプロセッサが扱うように構成されてよい。
【００６９】
各プロセッサは、一実施形態では、共有メモリバックボーン４２８を共有する。したがって、１つ又は２つ以上のプロセッサが過負荷になったときは、負荷バランシングが実施されてよい。一例において、もし、経路４４４を介してセンサ４２６から流入するデータストリームが、プロセッサ４０８の処理能力を上回る場合は、プロセッサ４０８にかかる負荷の軽減を助けるために、その他のプロセッサを充てることが可能である。
【００７０】
負荷バランシング以外に、共有メモリバックボーンは、耐障害性のための環境も提供する。つまり、もし、プロセッサの１つが正常に動作していない場合は、その誤動作しているプロセッサによってこれまでサポートされていた処理は、その他のプロセッサに再分配される。一例において、もし、プロセッサ４０６が正常に機能しておらず、センサ４２４から来るデータストリームを処理することができない場合は、センサ４２４からのデータストリームを扱うように、プロセッサ４０４を仕向けることが可能である。したがって、作業負荷を再分配する能力は、サーバ全体のダウンタイムを招くことなく正常に機能していないプロセッサが交換されることを可能にする。
【００７１】
一実施形態では、ＡＰＥＣＳ４００内に２つのタイプのプロセッサが存在してよい。第１のタイプのプロセッサは、セカンダリプロセッサ（プロセッサ４０４、４０６、又は４０８）である。各セカンダリプロセッサは、その対応する（１つ又は２つ以上の）センサから受信されたデータストリームを処理するように構成される。また、一実施形態において、各プロセッサは、データを解析するように及び（１つ又は２つ以上の）対応するセンサに存在しえるあらゆる潜在的な問題を特定するように構成される。
【００７２】
第２のタイプのプロセッサは、プライマリプロセッサ（４０２）として知られる。図４は、プライマリプロセッサを１つのみ示しているが、プライマリプロセッサの数は、ユーザの設定に依存してよい。一実施形態では、プライマリプロセッサは、１つ又は２つ以上のセンサからのデータストリームを扱うように構成されてよい。一例では、センサ４２０によって収集されたデータストリームは、処理のために、経路４３８を介してプライマリプロセッサ４０２に送信される。
【００７３】
プライマリプロセッサのもう１つのデータソースは、プロセスモジュールである。つまり、プロセスモジュールによって収集されたプロセスモジュールデータ及びプロセスコンテクストデータが、プライマリプロセッサによって処理される。一例において、プロセスモジュールによって収集されたデータは、プロセス制御バスを通って経路４５４を介してＡＰＥＣＳ４００に送信される。データは、経路４４６を介してプライマリプロセッサ４０２に流入する前に、先ず、イーサネットスイッチ４１８を通る。
【００７４】
データ処理に加えて、プライマリプロセッサは、複数ソースからのデータを解析するようにも構成される。一例では、センサ４２２からのデータストリームとセンサ４２４からのデータストリームとの間の関連付けが、プライマリプロセッサ４０２によって実施される。別の例では、１つ又は２つ以上のセンサからのデータストリームとプロセスモジュールからのデータストリームとの間の関連付けも、プライマリプロセッサ４０２によって実施される。
【００７５】
各データソースのためのデータ経路が、ほぼ同様の長さになるので、データの関連付けは、先行技術におけるよりも、大幅に困難でなくなる。一例において、データは、（クラスタツールコントローラ及び／又はファブホストなどの）その他のサーバを通る必要なくプロセスモジュールからＡＰＥＣＳ４００へ流れるので、プロセスモジュールからのデータストリームは、図１及び図２で説明されたようにデータストリームが（クラスタツールコントローラやファブホストなどの）その他のサーバを通って伝送されなければならないときに発生しえる（コンピュータドリフト、コンピュータ待ち時間、ネットワーク負荷などの）コンピュータ及び／又はネットワークの状態に起因する変化に見舞われない。また、関連付け及び解析の実施に必要とされる全ての関連データストリームを受信するための待ち時間も、大幅に短縮される。このように、（コンピュータドリフト、コンピュータ待ち時間、ネットワーク負荷などの）外部状況が実質的に排除されたとき、異なるソースからのデータの関連付けは、大幅に簡略化される。
【００７６】
データ経路以外にも、１つのソースからの、より粒度が高く且つより多量のデータは、関連付けを実施するためのデータ点をより多く提供するので、より迅速で且つより正確な解析の実施が可能になる。先行技術において、先行技術の解析サーバは、夥しい数のデータソースからの多量のデータを扱うことができないので、解析のために利用可能なデータは、不完全であるのが通常であり、ゆえに、データソース間の関連付けは、困難であるのが通常である。先行技術と異なり、各解析サーバは、限られた数のソース（プロセスモジュール及びそれに結び付いているセンサ）からのデータを解析する責任のみを担うので、データソースの数は、大幅に減少される。データソースの数が大幅に減少されているので、解析サーバは、１つのソースから、より多量のデータを扱う容量を有する。より粒度の高い詳細が提供されれば、様々なソースのデータストリーム間で、より優れた関連付けが達成されるであろう。
【００７７】
もし、（制御できない事象などの）問題が特定された場合は、プライマリプロセッサは、プロセスモジュールに停止命令を送信するように構成される。一実施形態では、ＡＰＥＣＳ４００からプロセスモジュールに停止命令を送信するために、直接的なデジタル出力回線４５６が用いられる。２つのデバイス間の直接的なデジタル出力回線によって、停止命令は、伝送される前に先ずイーサネットメッセージに変換される必要がなくなる。したがって、停止命令を適切な形式にするために及びそれを変換しなおして戻すために必要な時間が、実質的に解消される。このため、ＡＰＥＣＳ４００は、制御できない事象を扱うためにリアルタイムな停止又はほぼリアルタイムな停止をプロセスモジュールに提供することができる。
【００７８】
一実施形態では、プライマリプロセッサは、経路４５８を介してその他のデバイスとやり取りするようにも構成されてよい。一例において、もし、クラスタツールコントローラがＡＰＥＣＳ４００にリクエストを送信した場合は、そのリクエストは、経路４５８を介して送信されてプライマリプロセッサ４０２によって扱われてよい。別の例では、ファブホストへの通知が、経路４５８及びクラスタツールコントローラを介して送信されてよい。
【００７９】
本発明の１つ又は２つ以上の実施形態からわかるように、プロセスレベルトラベルシューティングアーキテクチャが提供される。解析サーバをプロセスモジュールレベルに局在させることによって、解析のためのデータ粒度が提供され、その結果、より迅速で且つより正確な解析がもたらされる。様々なデータソースのためのデータ経路が同様であることによって、様々なデータストリーム間に、より優れた関連付けが存在する。より迅速で且つより正確な解析によって、より適時にトラブルシューティングを実施し、次の基板が損傷されるのを阻止するためだけでなく被害基板に影響を及ぼす制御できない事象を修理するためにも使用されえる修正措置をとらせることによって被害基板を損傷から救出するための停止命令を適時に提供することが可能である。このため、無駄にされる基板の数が少なくてすみ、処理チャンバコンポーネントへの損傷が大幅に低減される。
【００８０】
発明の別の態様では、本願の発明者らは、適時で、迅速で、且つ正確な解析を実施することができるプロセスレベルトラブルシューティングアーキテクチャによって、（マイクロアーク事象、デチャック事象、スパイク事象などの）高速過渡事象をリアルタイムでのその場での検出が特定及び管理されえることに気付いた。本明細書で論じられる高速過渡事象とは、基板処理中に急速に且つ通常は短期間にわたって発生しえる（マイクロアーク事象、デチャック事象、スパイク事象などの）事象を言う。高速過渡事象を特定する作業は、各事象の速さ及び短い持続時間のゆえに、通常は、できる限り、基板ロット全体が処理された後にオフラインで実施されてきた。
【００８１】
一例では、例えば光計測ツールを使用して、１枚又は２枚以上の基板が検査されるとする。あいにく、検査は、リアルタイム検出を提供しない。それどころか、例えばマイクロアーク事象が基板上で発生しているとして特定された時点では、その基板が損傷されているのみならず、その基板ロットの残りも損傷されている恐れがある。また、処理チャンバ内のハードウェアコンポーネントへの損傷も発生している恐れがある。
【００８２】
近年では、（高速過渡事象の結果である）高速過渡の電気的徴候が捕獲されることを可能にする高速過渡センサが開発されている。しかしながら、高速過渡センサの大半は、電気的徴候を分類する能力を有さない。つまり、高速過渡センサは、データを収集することはできるが、そのデータを有害な可能性のある事象の特定に使用されえる意味ある電気的徴候に分類する能力は有さないのが通常である。
【００８３】
例えば、エッチングプロセス中に、電荷が蓄積してマイクロアーク事象を発生させる状況を考える。本明細書で論じられるマイクロアークとは、電力が急激に散逸してその散逸が基板上のパターンに（層の破壊、パターンの破壊、層の融解などの）損傷を及ぼすときに発生する事象を言う。ＶＩプローブを用いることによって、マイクロアークに関するデータが収集されえる。しかしながら、ＶＩプローブなどの高速過渡センサの大半は、データを解釈してマイクロアーク事象などの高速過渡事象がいつ生じたかを特定する知能を欠いている。
【００８４】
それどころか、高速過渡センサによって収集されたデータは、人間であるユーザなどの第三者によって、又はソフトウェアプログラムによって、解析されなければならないであろう。一例では、人間であるユーザが、夥しい量のデータを解析し、基板処理中に高速過渡事象が発生したかどうかの決定を（自身の専門知識に基づいて）下さなければならないであろう。データを解析する作業は、何週間まではいかなくても何時間はかかるであろう。たとえデータ解析がソフトウェアプログラムによって実施されるとしても、何百万ものデータサンプルの解析は、やはり時間を要するであろう。問題が特定されたときには、１つ若しくは２つ以上の基板ロットへの損傷及び／又は処理チャンバのハードウェアコンポーネントへの損傷が既に生じている恐れがある。
【００８５】
マイクロアーク事象は、通常は予測可能な現象ではないので、マイクロアーク事象などの高速過渡事象の検出は、困難な作業である恐れがある。つまり、例えばマイクロアークは、必ずしも全ての基板上で発生するものではない。発明の一態様において、本願の発明者らは、たとえマイクロアーク事象のタイミングが予測不能であっても、マイクロアーク事象の電気的徴候はそうではないことに気付いた。つまり、各マイクロアーク事象は、固有の徴候によって表すことが可能である。
【００８６】
図５は、マイクロアーク事象を示した簡略図（曲線５０２）である。曲線５０２からわかるように、オンウエハマイクロアーク事象が発生するときに、電圧信号及び電流信号は、同時に急降下（５０４）に見舞われる。次いで、電圧信号及び電流信号は、両信号が降下した時点とは異なるレベルかもしれない平坦域（５０６）へ徐々に上昇するのに伴って、逆減衰を経る。
【００８７】
発明の実施形態にしたがって、プラズマ処理システムの処理チャンバ内におけるマイクロアーク事象などの高速過渡事象を扱うための方法と構成とが提供される。発明の実施形態は、高速過渡事象（例えばマイクロアーク）を検出するための方法を含む。発明の実施形態は、また、高速過渡の電気的徴候を、（アーク徴候などの）既知の高速過渡の徴候との徴候の比較の実施によって分類するための方法も含む。発明の実施形態は、更に、高速過渡事象の深刻度を分類するための方法も含む。発明の実施形態は、尚も更に、リアルタイムな生産環境中における損傷を最小限に抑えるために高速過渡事象を管理するための方法も含む。
【００８８】
本文献では、マイクロアークを一例として使用して、様々な実装形態が論じられる。本発明は、しかしながら、マイクロアークに限定されず、基板処理中に発生しえる任意の高速過渡事象を含むことが可能である。むしろ、議論は、例示を意図しており、発明は、提示された例に限定されない。
【００８９】
発明の一実施形態において、潜在的なマイクロアーク事象を検出するための方法と構成とが提供される。前述のように、高いサンプリング率を実施する（例えば１秒間に幾百万又は幾十億ものデータ点を収集する）ことができる（ＶＩプローブなどの）高速過渡センサが、基板処理中にデータを収集するために用いられてよい。一実施形態では、例えばＶＩプローブが基板処理中にデータを収集している間に、高速サンプリング過渡検出アルゴリズムが実行されてよい。一実施形態では、高速サンプリング過渡検出アルゴリズムは、潜在的な高速過渡の電気信号を定義するための基準を含んでよい。一例では、潜在的なオンウエハマイクロアーク事象を特定するために、高速サンプリング過渡検出アルゴリズムを使用して、電圧信号及び電流信号がともに同時に降下する事象を探すことが可能である。別の例では、潜在的なチャンバマイクロアーク事象を特定するために、高速サンプリング過渡検出アルゴリズムを使用して、電圧信号及び電流信号がともに急上昇する事象を探すことが可能である。
【００９０】
一実施形態では、高速サンプリング過渡アルゴリズムは、（ＶＩプローブコントローラなどの）センサコントローラによって実施される。このセンサコントローラは、センサ（例えばＶＩプローブ）につながれてセンサ（例えばＶＩプローブ）とのインターフェースを提供するように及びセンサ（例えばＩＶプローブ）からデータを受信するように構成された計算モジュールである。別の実施形態では、高速サンプリング過渡アルゴリズムは、センサコントローラ（例えばＶＩプローブコントローラ）とやり取りする計算モジュールによって実施される。更に別の実施形態では、高速サンプリング過渡アルゴリズムは、センサ（例えばＶＩプローブ）と直接やり取りする解析モジュールによって実施される。
【００９１】
もし、センサ（例えばＩＶプローブ）又はセンサ（例えばＩＶプローブ）とやり取りしている計算モジュールのいずれかによって、潜在的なマイクロアーク事象が特定された場合は、一実施形態では、その事象の発生の付近で発生する電圧信号及び電流信号（例えば電気的徴候）の波形が保存されて、解析のためにプロセスモジュールレベル解析サーバ（例えばＡＰＥＣＳ３１４）などの解析モジュールに転送されてよい。つまり、センサレベルで検出を実施することによって、（マイクロアークなどの）潜在的な高速過渡の電気的徴候に関するデータのみが、更なる解析のために解析モジュールに転送される。このため、解析のために全てのデータを解析モジュールに送信するのではなく、データ経路に沿って送信されているデータトラフィックの量を減らすためにフィルタリングを実施してよく、それによって、帯域幅要件を減らすとともに解析モジュールのプロセッサ能力を軽減することが可能である。
【００９２】
しかしながら、もし、センサ（例えばＩＶプローブ）と直接やり取りしている解析モジュールによって潜在的なマイクロアーク事象が特定される場合は、一実施形態では、データフィルタリングは不要である。その代わり、プロセスレベルトラブルシューティングアーキテクチャの一部である（ＡＰＥＣＳ３１４などの）解析モジュールは、大量のデータを扱うことができる高速プロセッサを有してよい。発明による固有なプロセスレベルトラブルシューティングアーキテクチャによって、その他のタイプの解析アーキテクチャで発生しえる一般的なデータトラフィック渋滞が大幅に解消されえる。その結果、解析モジュールは、幾百万ものデータサンプルを迅速に且つ効率的に解析することができる。
【００９３】
発明の一実施形態では、潜在的な高速過渡の電気的徴候の分類が実施されてよい。一例において、解析モジュールによって、潜在的な高速過渡事象の波形が受信されたら、同解析モジュールは、潜在的な高速過渡の電気的徴候を（アーク徴候のセットなどの）高速過渡の徴候のセットと比較してよい。一実施形態では、マイクロアークなどの高速過渡事象の例としての種々の既知の波形が、ライブラリに保存されてよい。
【００９４】
もし、潜在的な高速過渡の電気的徴候が、ライブラリに保存されている高速過渡の徴候のセットのなかの１つと一致するならば、一実施形態では、高速過渡事象の深刻度が決定されてよい。一例では、その高速過渡事象は、処理されている基板にほとんど又は全く影響を及ぼさない事象である。したがって、その事象は、低い深刻度レベルを有する事象として分類されるであろう。別の例では、その高速過渡事象は、処理されている現基板を損傷させたかもしれない事象である。このため、その高速過渡事象は、高い深刻度レベルを有するものとして分類されるであろう。
【００９５】
高速過渡事象の深刻度を特定することによって、その高速過渡事象をどのように扱うのが最適であるかについての決定を下すことができる。発明の一実施形態では、高速過渡事象の深刻度に応じて既定の一連の措置がとられてよい。一例では、低い深刻度レベルを有する高速過渡事象が、警告をトリガする一方で、高い深刻度レベルを有する高速過渡事象は、結果として例えばエッチングプロセスを終了させてよい。
【００９６】
議論を容易にするために、図６Ａは、発明の一実施形態における、処理環境を示した簡略ブロック図である。処理システム６００は、基板６０４を中で処理されている処理チャンバ６０２を含んでよい。基板処理中は、基板をエッチングするためのプラズマを発生させるために、ガス（不図示）が、（ＲＦジェネレータのセット６０６を通じて整合器のセット６０８を介して提供される）電力と相互に作用することができる。
【００９７】
基板処理中に、もし、電荷の蓄積が生じて高速過渡事象を発生させた場合は、データは、ＶＩプローブ６１０によって収集されて、高速サンプリング過渡検出アルゴリズムモジュール６１６によって識別されてよい。高速サンプリング過渡検出アルゴリズムモジュール６１６は、一実施形態では、高速過渡事象を定義するための基準を含んでよい。一実施形態では、高速過渡検出アルゴリズムモジュールは、基板処理中に実行されるように構成されてよい。
【００９８】
一実施形態では、収集されたデータは、経路のセット６１４に沿ってＶＩプローブコントローラ６１２に転送されてよい。ＶＩプローブコントローラ６１２は、ＶＩプローブ６１０を管理するように少なくとも構成される。一実施形態では、ＶＩプローブコントローラ６１２は、高速サンプリング過渡検出アルゴリズムモジュール６１６を含んでもよい。
【００９９】
別の実施形態では、高速サンプリング過渡検出アルゴリズムモジュール６１６は、ＶＩプローブコントローラ６１２と通信することができる独立した計算モジュールであってよい。つまり、ＶＩプローブ６１０によって収集されたデータは、ＶＩプローブコントローラ６１２を介して高速サンプリング過渡検出アルゴリズムモジュール６１６に送信されてよい。高速サンプリング過渡検出アルゴリズムモジュール６１６を独立したモジュールにすることによって、ＶＩプローブコントローラ６１２は、たとえそれが追加の処理を扱うことができなくても変更されなくてすむ。
【０１００】
別の実施形態では、ＶＩプローブコントローラ６１２にデータを送信する代わりに、データは、ＶＩプローブ６１０から経路６５０を介して（図６Ｂに示されるように）解析モジュール６１８に直接送信されてよく、解析モジュール６１８は、高速サンプリング過渡検出アルゴリズムモジュール６１６を収容していてよい。データを解析モジュール６１８に直接伝送することによって、ＶＩプローブ６１０によって収集されたデータは、前処理を経なくてすむ。また、（ＶＩプローブコントローラ６１２などの）計算モジュールは、不動産間接費を削減するために、排除することが可能である。その代わりに、解析モジュール６１８を使用して、潜在的な高速過渡の電気的徴候を識別することが可能である。
【０１０１】
既定の基準に基づいて潜在的な高速過渡の電気的徴候が検出されたら、その潜在的な高速過渡の電気的徴候は、プロセスモジュールレベル解析サーバ（例えばＡＰＥＣＳ３１４）などの解析モジュール６１８によって分類されてよい。一実施形態では、解析モジュール６１８は、潜在的な高速過渡の電気的徴候を、ライブラリに保存されているアーク徴候のセットなどの高速過渡の徴候のセットと比較することによって、徴候の比較を実施してよい。もし、一致が確認された場合は、高速過渡事象が発生したとみなされる。
【０１０２】
一実施形態では、解析モジュール６１８は、高速過渡事象の深刻度を決定するように構成される。当業者ならば、高速過渡事象が種々の深刻度（例えば強度）レベルを有しえることを承知している。したがって、各高速過渡事象の深刻度を決定するためのアルゴリズムが提供される。一実施形態では、深刻度レベル／閾値範囲は、事前に定められてよく、ユーザ設定可能であってよい。一例として、電流信号又は電圧信号における４ｄＢを超える降下と、１５マイクロ秒よりも長い持続時間（降下から回復までとして定義される）とが、ウエハ上における損傷を検出するための適切な閾値だとみなされてよい。
【０１０３】
高速過渡事象の深刻度レベルが分類されたら、一連の措置がとられてよい。一実施形態では、一連の措置は、事前に決定されてよく、深刻度レベル／閾値範囲に結び付いていてよい。一実施形態では、一連の措置は、ユーザ設定可能であってよい。一例では、電圧及び電流の降下が小さい（マイクロアークなどの）高速過渡の電気的徴候は、無害だとみなされ、オペレータへの通知の送信のみを必要としてよい。別の例では、電圧及び電流の降下が大きい高速過渡の電気的徴候は、高い深刻度レベルを有する事象だとみなされ、基板プロセスの終了をトリガしてよい。
【０１０４】
図７は、発明の一実施形態における、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部ではない生産環境内においてリアルタイム高速過渡事象を検出するための方法を示した簡略フローチャートである。
【０１０５】
第１のステップ７０２では、基板処理が開始する。例えば、基板６０４が処理チャンバ６０２内で処理されている状況を考える。
【０１０６】
次のステップ７０４では、処理チャンバ内における基板処理が監視される。ステップ７０４ａでは、ＶＩプローブなどの高速過渡センサが電気パラメータ（例えば、種々の位相、基本波、及び調波における電圧信号及び電流信号）を監視していてよい。それとほぼ同時に、ステップ７０４ｂでは、高速サンプリング過渡検出アルゴリズムが実行されていてよい。
【０１０７】
次のステップ７０６では、潜在的な高速過渡事象の存在に関して決定が下される。つまり、高速サンプリング過渡検出アルゴリズムは、例えばマイクロアークなどの潜在的な高速過渡事象を定義するための基準を含んでよい。もし、ＶＩプローブによって収集されたデータが、高速サンプリング過渡検出アルゴリズムによって定義された基準を満たしていない場合は、潜在的な高速過渡事象は発生しておらず、ＶＩプローブは、基板プロセスの監視（ステップ７０４）を続ける。
【０１０８】
しかしながら、もし、潜在的な高速過渡事象が特定されたならば、次のステップ７０８では、その潜在的な高速過渡事象の発生の付近における電圧及び電流の波形が保存されてよい。
【０１０９】
次のステップ７１０では、保存された波形が解析モジュールに伝送される。一実施形態では、潜在的な高速過渡事象の発生に関係したデータのみが保存及び伝送されてよい。潜在的な高速過渡の電気的徴候のみを送信することによって、リソースの枯渇が最小限に抑えられる。また、（ＶＩプローブコントローラなどの）センサコントローラによって前処理が実施されているので、解析モジュールは、データの解析、並びに潜在的な高速過渡事象の分類及びそのための一連の措置の決定を迅速に行うための高速プロセッサを含まなくてすむ。
【０１１０】
次のステップ７１２では、解析モジュールによって徴候の比較が実施される。一実施形態では、解析モジュールは、潜在的な高速過渡の電気的徴候を高速過渡の徴候のセットと比較してよい。一実施形態では、高速過渡の徴候のセットは、ライブラリに保存されてよい。一実施形態では、ライブラリは、関連付けの実施を可能にするために、非高速過渡の徴候も含んでよい。
【０１１１】
次のステップ７１４では、潜在的な高速過渡の電気的徴候の分類に関して決定が下される。もし、徴候の比較の結果、一致が確認されなかった場合は、潜在的な高速過渡の電気的徴候は、意味のある高速過渡の電気的徴候として分類されない（ステップ７１６）。一実施形態では、この潜在的な高速過渡の電気的徴候は、廃棄されてよい。別の実施形態では、この潜在的な高速過渡の電気的徴候は、新しい高速過渡の電気的徴候としてライブラリに追加されてよい（ステップ７１８）。
【０１１２】
しかしながら、もし、徴候の比較の結果、高速過渡の電気的徴候が識別されたならば、次のステップ７２０では、その高速過渡事象の深刻度が決定される。一例では、深刻度は、低から高までの幅があってよい。一実施形態では、深刻度は、既定の閾値範囲のセットに基づいてよい。一実施形態では、高速過渡の電気的徴候は、ライブラリに追加されてよい（ステップ７１８）。ステップ７１８は、随意のステップであり、リアルタイム高速過渡事象の検出に必要なものではない。
【０１１３】
次のステップ７２２では、一連の措置が決定される。深刻度レベルが決定されたら、一連の措置が実行されてよい。一実施形態では、一連の措置は、事前に定められてよい。一例では、低い深刻度レベルを有する高速過渡の電気的徴候が、オペレータへの通知をトリガしてよい。別の例では、中程度の深刻度レベルを有する高速過渡の電気的徴候が、警告をトリガしてよい。更に別の例では、高い深刻度レベルを有する高速過渡の電気的徴候が、基板プロセスの終了をトリガしてよい。上記からわかるように、深刻度レベル及び該深刻度レベルに結び付いている一連の措置は、ユーザ設定可能であってよい。
【０１１４】
図７は、生産環境内においてリアルタイム高速過渡事象を検出する方法を実現するための、１つの実施形態を示しているに過ぎない。別の例では、方法は、一実施形態において、高速サンプリング過渡検出アルゴリズムが解析モジュールの一部であるとしてリアルタイム高速過渡事象を検出するために適用されてもよい。このタイプの環境では、高速サンプリング過渡検出アルゴリズムの実行は、ＶＩプローブコントローラの代わりに（ＡＰＥＣＳ３１４などの）解析モジュールによって実施されてよい。一実施形態では、解析モジュールは、多量のデータを扱うことができる高速処理計算モジュールである。一実施形態では、解析モジュールは、センサに直接つながれる。このため、データは、センサによって収集され、解析モジュールに直接伝送される。
【０１１５】
上記からわかるように、その場でのリアルタイム高速過渡事象を検出するための構成と方法とが提供される。先行技術において、高速過渡事象の検出は、１つの基板ロットに対する基板処理が完了した後に実施されるのが通常である。更に、高速過渡事象の存在を決定するためには、複雑な計測ツールが必要とされるであろう。高速過渡事象の存在は、予測不可能であるので、発生したかもしれない潜在的な損傷を決定するためには、一基板ロットのなかの各基板を測定する必要があるであろう。
【０１１６】
先行技術と異なり、発明の実施形態は、基板処理中における高速過渡事象のリアルタイムな検出を提供し、それによって、基板ロットの残り及び／又は処理チャンバへの損傷を最小限に抑える。また、先行技術と異なり、検出プロセスは、人による干渉をほとんど又は全く必要としない自動化されたプロセスである。それどころか、ユーザ設定可能な条件／基準／閾値がひとたび定義されたら、システムは、高速過渡事象を自動的に検出するように構成される。
【０１１７】
生産環境内において、（マイクロアーク事象などの）高速過渡事象がリアルタイムで特定されえるので、実際の発生と、その発生を管理するためにとられる一連の措置との間の待ち時間は、短縮することが可能である。先行技術では、待ち時間は、何時間、又はひいては何週間にも及ぶ恐れがある。しかしながら、本明細書で説明されている方法及び／又は構成を用いれば、待ち時間は、僅かミリ秒単位まで短縮することが可能であり、それによって、全体の所有コストが削減される。
【０１１８】
本発明は、幾つかの好ましい実施形態の観点から説明されているが、本発明の範囲に入るものとして、代替、置換、及び均等物がある。本明細書では、様々な例が提供されるが、これらの例は、発明に対して例示的であって限定的ではないことを意図している。
【０１１９】
また、名称及び概要は、便宜のために提供されたものであり、特許請求の範囲を解釈するために使用されるべきでない。更に、要約は、極めて省略された形で記載され、便宜のために提供されたものであり、したがって、特許請求の範囲に表された全体的発明を解釈するためにも制限するためにも用いられるべきでない。もし、本明細書において「セット」という用語が用いられる場合は、このような用語は、ゼロの、１つの、又は２つ以上の構成要素を対象とした通常理解の数学的意味を有することを意図している。また、本発明の方法及び装置を実現するものとして、多くの代替的手法があることも留意されるべきである。したがって、以下の添付の特許請求の範囲は、本発明の真の趣旨及び範囲に含まれるものとして、このようなあらゆる代替、置換、及び均等物を含むものと解釈される。
【特許請求の範囲】
【請求項１】
基板処理中にプラズマ処理システムの処理チャンバ内における高速過渡事象を検出するための方法であって、
センサのセットによって収集された第１のデータセットを解析することであって、前記第１のデータセットが潜在的なその場での高速過渡事象を含むかどうかを決定するために、前記第１のデータセットをその場での高速過渡事象のセットを定義した基準のセットと比較し、
前記第１のデータセットが前記潜在的なその場での高速過渡事象を含む場合に、前記潜在的なその場での高速過渡事象が発生する期間中に発生する電気的徴候を保存し、
前記電気的徴候を、保存されたアーク徴候のセットと比較し、
一致が決定された場合に、前記電気的徴候を第１のその場での高速過渡事象として分類し、
既定の閾値範囲のセットに基づいて、前記第１のその場での高速過渡事象の深刻度レベルを決定する、
方法。
【請求項２】
請求項１に記載の方法であって、
前記第１のデータセットの解析は、高速サンプリング過渡アルゴリズムの実施を含む方法。
【請求項３】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、センサコントローラによって実行される
方法。
【請求項４】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、計算モジュールによって実行され、前記計算モジュールは、センサ及びセンサコントローラの一方につながれるように少なくとも構成される
方法。
【請求項５】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、前記センサのセットのなかのセンサと直接やり取りするように構成された解析モジュールによって実行される
方法。
【請求項６】
請求項５に記載の方法であって、
前記解析モジュールは、各プロセスモジュール及び前記各プロセスモジュールに結び付いているセンサのセットのための解析を実施するように構成されたプロセスモジュールレベル解析サーバである
方法。
【請求項７】
請求項１に記載の方法であって、更に、
前記第１のその場での高速過渡事象の前記深刻度レベルに基づいて一連の措置を決定することを備える方法。
【請求項８】
請求項１に記載の方法であって、
前記第１のその場での高速過渡事象は、マイクロアーク事象である
方法。
【請求項９】
請求項１に記載の方法であって、
前記第１のデータセットは、高いサンプリング率を実施することができる高速過渡センサによって収集されている
方法。
【請求項１０】
請求項１に記載の方法であって、
前記電気的徴候は、前記保存されたアーク徴候のセットのなかの一アーク徴候と一致しない場合に非高速過渡事象の徴候としてライブラリに追加される
方法。
【請求項１１】
プラズマ処理システムの処理チャンバ内における高速過渡事象を検出するための構成であって、前記処理チャンバは、基板処理中にデータを収集するように構成された複数のセンサを含み、前記構成は、
前記データを既定のその場での高速過渡事象のセットを定義した基準のセットと比較して、前記データから電気的徴候を抽出するように構成された、高速サンプリング過渡アルゴリズムモジュールと、
前記高速サンプリング過渡アルゴリズムモジュールと直接通信する解析モジュールであって、少なくとも、
前記電気的徴候を受信するように、
前記電気的徴候を、保存されたアーク徴候のセットと比較するように、
一致が生じた場合に、前記電気的徴候を高速過渡事象として分類するように、
既定の閾値範囲のセットに基づいて前記高速過渡事象の深刻度レベルを決定するように、
構成された解析モジュールと、
を備える構成。
【請求項１２】
請求項１１に記載の構成であって、更に、
前記保存されたアーク徴候のセットを保存するように構成されたライブラリを備える構成。
【請求項１３】
請求項１２に記載の構成であって、
前記ライブラリは、非高速過渡の徴候を保存するように構成される
構成。
【請求項１４】
請求項１１に記載の構成であって、
解析モジュールは、前記基板処理中に前記高速過渡事象が特定されたときに、前記一連の措置をプロセスモジュールコントローラに直接送信するように構成される
構成。
【請求項１５】
請求項１１に記載の構成であって、
前記解析モジュールは、更に、前記高速過渡事象の前記深刻度レベルに基づいて一連の措置を決定するように構成される
構成。
【請求項１６】
請求項１１に記載の構成であって、
前記高速過渡事象は、マイクロアーク事象である
構成。
【請求項１７】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、前記複数のセンサと直接やり取りするように構成された解析モジュールによって制御される
構成。
【請求項１８】
請求項１１に記載の構成であって、
前記解析モジュールは、各プロセスモジュール及び前記各プロセスモジュールに結び付いているセンサのセットのための解析を実施するように構成されたプロセスモジュールレベル解析サーバである
構成。
【請求項１９】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、センサコントローラによって制御される
構成。
【請求項２０】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、計算モジュールによって実行され、前記計算モジュールは、センサ及びセンサコントローラの一方につながれるように少なくとも構成される
構成。
【請求項１】
基板処理中にプラズマ処理システムの処理チャンバ内における高速過渡事象を検出するための方法であって、
センサのセットによって収集された第１のデータセットを解析することであって、前記第１のデータセットが潜在的なその場での高速過渡事象を含むかどうかを決定するために、前記第１のデータセットをその場での高速過渡事象のセットを定義した基準のセットと比較し、
前記第１のデータセットが前記潜在的なその場での高速過渡事象を含む場合に、前記潜在的なその場での高速過渡事象が発生する期間中に発生する電気的徴候を保存し、
前記電気的徴候を、保存されたアーク徴候のセットと比較し、
一致が決定された場合に、前記電気的徴候を第１のその場での高速過渡事象として分類し、
既定の閾値範囲のセットに基づいて、前記第１のその場での高速過渡事象の深刻度レベルを決定する、
方法。
【請求項２】
請求項１に記載の方法であって、
前記第１のデータセットの解析は、高速サンプリング過渡アルゴリズムの実施を含む方法。
【請求項３】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、センサコントローラによって実行される
方法。
【請求項４】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、計算モジュールによって実行され、前記計算モジュールは、センサ及びセンサコントローラの一方につながれるように少なくとも構成される
方法。
【請求項５】
請求項２に記載の方法であって、
前記高速サンプリング過渡アルゴリズムは、前記センサのセットのなかのセンサと直接やり取りするように構成された解析モジュールによって実行される
方法。
【請求項６】
請求項５に記載の方法であって、
前記解析モジュールは、各プロセスモジュール及び前記各プロセスモジュールに結び付いているセンサのセットのための解析を実施するように構成されたプロセスモジュールレベル解析サーバである
方法。
【請求項７】
請求項１に記載の方法であって、更に、
前記第１のその場での高速過渡事象の前記深刻度レベルに基づいて一連の措置を決定することを備える方法。
【請求項８】
請求項１に記載の方法であって、
前記第１のその場での高速過渡事象は、マイクロアーク事象である
方法。
【請求項９】
請求項１に記載の方法であって、
前記第１のデータセットは、高いサンプリング率を実施することができる高速過渡センサによって収集されている
方法。
【請求項１０】
請求項１に記載の方法であって、
前記電気的徴候は、前記保存されたアーク徴候のセットのなかの一アーク徴候と一致しない場合に非高速過渡事象の徴候としてライブラリに追加される
方法。
【請求項１１】
プラズマ処理システムの処理チャンバ内における高速過渡事象を検出するための構成であって、前記処理チャンバは、基板処理中にデータを収集するように構成された複数のセンサを含み、前記構成は、
前記データを既定のその場での高速過渡事象のセットを定義した基準のセットと比較して、前記データから電気的徴候を抽出するように構成された、高速サンプリング過渡アルゴリズムモジュールと、
前記高速サンプリング過渡アルゴリズムモジュールと直接通信する解析モジュールであって、少なくとも、
前記電気的徴候を受信するように、
前記電気的徴候を、保存されたアーク徴候のセットと比較するように、
一致が生じた場合に、前記電気的徴候を高速過渡事象として分類するように、
既定の閾値範囲のセットに基づいて前記高速過渡事象の深刻度レベルを決定するように、
構成された解析モジュールと、
を備える構成。
【請求項１２】
請求項１１に記載の構成であって、更に、
前記保存されたアーク徴候のセットを保存するように構成されたライブラリを備える構成。
【請求項１３】
請求項１２に記載の構成であって、
前記ライブラリは、非高速過渡の徴候を保存するように構成される
構成。
【請求項１４】
請求項１１に記載の構成であって、
解析モジュールは、前記基板処理中に前記高速過渡事象が特定されたときに、前記一連の措置をプロセスモジュールコントローラに直接送信するように構成される
構成。
【請求項１５】
請求項１１に記載の構成であって、
前記解析モジュールは、更に、前記高速過渡事象の前記深刻度レベルに基づいて一連の措置を決定するように構成される
構成。
【請求項１６】
請求項１１に記載の構成であって、
前記高速過渡事象は、マイクロアーク事象である
構成。
【請求項１７】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、前記複数のセンサと直接やり取りするように構成された解析モジュールによって制御される
構成。
【請求項１８】
請求項１１に記載の構成であって、
前記解析モジュールは、各プロセスモジュール及び前記各プロセスモジュールに結び付いているセンサのセットのための解析を実施するように構成されたプロセスモジュールレベル解析サーバである
構成。
【請求項１９】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、センサコントローラによって制御される
構成。
【請求項２０】
請求項１１に記載の構成であって、
前記高速サンプリング過渡アルゴリズムモジュールは、計算モジュールによって実行され、前記計算モジュールは、センサ及びセンサコントローラの一方につながれるように少なくとも構成される
構成。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【公表番号】特表２０１２−５３２４６４（Ｐ２０１２−５３２４６４Ａ）
【公表日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願番号】特願２０１２−５１８５８９（Ｐ２０１２−５１８５８９）
【出願日】平成２２年６月２９日（２０１０．６．２９）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４０４７８
【国際公開番号】ＷＯ２０１１／００２８１１
【国際公開日】平成２３年１月６日（２０１１．１．６）
【出願人】（５９２０１００８１）ラム リサーチ コーポレーション (467)
【氏名又は名称原語表記】ＬＡＭ ＲＥＳＥＡＲＣＨ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願日】平成２２年６月２９日（２０１０．６．２９）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４０４７８
【国際公開番号】ＷＯ２０１１／００２８１１
【国際公開日】平成２３年１月６日（２０１１．１．６）
【出願人】（５９２０１００８１）ラム リサーチ コーポレーション (467)
【氏名又は名称原語表記】ＬＡＭ ＲＥＳＥＡＲＣＨ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]